Step 4.4 ETH2 - Consensus client selection
Last updated
Last updated
A consensus client plays a pivotal role within the Ethereum network, facilitating the establishment and maintenance of consensus among network participants. This client is responsible for validating and verifying transactions, ensuring agreement on the state of the blockchain across the entire network. Commonly known as the Beacon Node, CL client, or formerly the Eth2 client, the consensus client implements the proof-of-stake consensus algorithm. This algorithm enables the network to reach consensus by leveraging validated data from the execution client. Consensus clients synchronize with other network nodes to propagate and validate transactions, thereby bolstering the security and integrity of the Ethereum blockchain. Through active participation in the consensus process, these clients enable decentralized decision-making and enhance the overall trustworthiness of the Ethereum network. Learn more
System-recommended: Let Stader node arbitrarily choose from a wide range of network clients . This will enhance the network diversity and resilience of the Ethereum ecosystem.
Lighthouse: Lighthouse is a software client for the Ethereum 2.0 blockchain that is developed by Sigma Prime, a blockchain engineering firm based in Australia. It is written in the Rust programming language and is designed to be fast, efficient, and secure. Learn more
Nimbus: Nimbus is an Ethereum consensus client that prioritizes minimal resource usage, and is written in Nim - a language with Python-like syntax that compiles to C. Its efficiency enables it to perform well on any system. Learn more
Prysm: Prysm, an Ethereum proof-of-stake client written in Go, is developed by Prysmatic Labs. It prioritizes usability, security and reliability in the implementation of its consensus protocol. Learn more
Teku: Teku is an Ethereum consensus client developed by PegaSys, a branch of ConsenSys that focuses on building high-quality clients for Ethereum. Written in Java, Teku offers impressive security and scalability features, although it requires substantial RAM and CPU resources to operate efficiently. Learn more
Since each consensus client has its own unique behavior, Stader Node must be informed of the specific client you are using externally. This way, it can adjust its behavior accordingly. Select the consensus client that you are managing externally. If your preferred client is not listed here, it may not be compatible with the Hybrid mode of Stader node.
After choosing the externally managed Consensus client, input the appropriate HTTP URL or JSON RPC URL according to your client selection. Keep in mind that if you are running this client on the same machine as the Stader Node, utilize your machine's LAN IP address instead of using "localhost" or "127.0.0.1".