How do validators join the Ethereum network?
Contents:
Aim of this article
Changes as a result of The Merge
Steps to become a validator
Hardware requirements
Expected minimum requirements
Running clients
Execution client
Consensus client
Deposit data
Activation queue to become a validator
Responsibilities as a validator
Roles to perform
Impact on users and the network
Aim of this article
Years of research and development has seen a complete overhaul of the Ethereum consensus layer, the layer which determines how blocks are created and validated, which first came into effect in September 2022 (The Merge). Due to these recent rapid changes it is difficult to find resources explaining what has changed - terms including ‘miners’ and ‘proof-of-work’ had now been substituted with ‘validators’ and ‘proof-of-stake’. In this article a deeper analysis will be provided of how users can partake in this updated Ethereum to either build on the infrastructure provided or invest and see returned yields. Or, more succinctly, how do users join the Ethereum network as validators?
While aim will be given to provide a sufficient magnitude of information to explain how to become a validator it is important to emphasise that this is a task that involves technical knowledge including setting firewalls, managing cryptographic keys and running command line tools. This article is intended to give readers a deep understanding of what is involved in becoming and operating as a validator but it is not intended to be a manual that can be relied on solely for such technical knowledge. Instead it should be possible to use understandings gained today to be able to digest and differentiate concepts introduced by manuals that at a surface level may appear confusing or indistinguishable.
Changes as a result of The Merge
Traditionally, Ethereum has relied on similar mechanisms to those employed by Bitcoin (proof-of-work) to create and validate blocks. Miners would build blocks containing transactions and solve a mathematical ‘puzzle’ that required large amounts of computational resources. This proved that a significant investment of computational devices was serving as collateral for the honesty of the miner. If a miner was attempting to act dishonestly, perhaps in the form of a double-spend attack, then they risked losing necessary income.
These mechanisms however resulted in an ‘arms race’ that locked a majority of users from being able to partake in the consensus layer of the Ethereum network. It was also realised that this was an opaque abstraction of the underlying principle that was intended; that miners should be discouraged from dishonest actions by the risk of financial loss. Such limitations necessitated The Merge, the finalisation of changes that moved Ethereum from proof-of-work to proof-of-stake. Ethereum’s revision of the consensus layer allowed for capital instead of computational devices to act as collateral to the honesty of validators (proof-of-stake). Attempts by a validator to act dishonestly results in both the loss of income and a portion of initial capital. It is through the form of ‘slashing’, which will be detailed further in a later article, that the latter occurs. Perhaps most importantly becoming a validator is significantly more accessible as a result of The Merge.
You may have heard of the terms ETH 2.0 or the Beacon Chain in previous research. These terms are now obsolete and historical references only. Language such as ETH 2.0 was abandoned to avoid a perception that this was an entirely new Ethereum, rather than simply one step in its gradual evolution. The Beacon Chain referred to what is now the main Ethereum chain (where all valid blocks exist) at a time prior to The Merge. It was The Merge that allowed for the proof-of-stake Beacon Chain to subsume the main proof-of-work Ethereum chain.
Steps to become a validator
Hardware requirements
It is important to note that while becoming a validator is more accessible than becoming a miner prior to The Merge, it is not the case that all computational devices can operate the necessary software. Minimum requirements are always changing and this article cannot be relied upon to necessarily have an updated estimation of these requirements. As future developments are incorporated into Ethereum it is feasible that many validators will need to update the devices they use. However, there are some minimum recommendations that can be made to provide a rough outline.
Expected minimum requirements
| Storage | 1.5TB of SSD storage to store all important data as a consequence of the execution of all blocks ever published to the main chain |
|---|---|
| Memory | 8GB of RAM to support the performing of operations such as executing blocks to test for their validity at speeds that an SSD storage could not support |
| CPU | 3GHz dual-core to perform operations such as executing blocks to test for their validity |
| Internet | 16Mb/s download/upload capacity network card to fetch all necessary blocks (it is typically a user’s internet plan rather than their network card that is the limiting factor) |
| OS | 64-bit operating system can be used but Windows and MacOS tends to include large overheads that will reduce performance and push updates that can bring a validator offline |
Most laptops sold currently with these requirements are often more expensive, so to save on costs it may be prudent to investigate desktops. To emphasise the point further, do not consider the purchase of a device on this resource alone though. As explanation is given in this article to the execution and consensus clients that users will need to run follow-up research should be conducted on what specifications are suggested by the clients themselves (as it is these clients that primarily dictate what device is required).
Running clients
Each validator is required to run two clients that are more or less equivalent to standard applications; an execution and consensus client (there are also validator clients, but these are typically packaged together with the consensus client). Failure to correctly operate one client or the other will result in either being inactive (which incurs minimal financial penalty) or unintentionally acting dishonestly (which incurs significant financial penalty). Execution clients were used by miners but are still used to collect transactions to include in a proposed block or to execute transactions within a block to ensure the block is valid. Consensus clients handle all processes involved with a validator signing to and coming to agreement together with other validators on a block’s validity. Both apps will need to interact with each other regularly through cryptographically secure channels (which will be explained through instructions provided by the installed clients).
Execution client
Popular execution clients include Geth, Nethermind and Besu. These are some of the applications that have existed for longer periods and have maintained relatively stable releases, reducing the chance for bugs. Greater than two-thirds of all validators are running Geth on their device which means that a super-majority is using the same software. Ethereum relies on ensuring that at least a super-majority of validators are active and honest to maintain the expected level of security. Therefore, if Geth was to ever come across any bugs that caused disruption to clients this could potentially pose a problem. It is recommended that users should aim to use alternatives such as Nethermind or Besu unless this is otherwise not possible as this will allow greater security for Ethereum (protecting the investments and business of all equally).
When your chosen client is installed it will begin syncing with the main chain, downloading all necessary data to bring the device up-to-date with the current block. Such a download will involve hundreds of gigabytes and will likely take days to complete (though you can proceed with the next steps in becoming a validator during the wait). Even when all remaining requisites are fulfilled though this sync will still need to complete before one can officially begin as a validator.
Consensus client
As the need for consensus clients have not existed for as long their diversity is limited to a selection of popular applications including Lighthouse, Prysm and Teku. Similar to Geth as discussed above, both Lighthouse and Prysm are used by over one-third of all validators which while neither a super-majority of clients on their own are capable of reducing the number of remaining validators to beneath that of a super-majority in the case of bugs. Therefore, it is once again recommended that users should aim to use alternatives such as Teku or Nimbus unless this is otherwise not possible.
Any client installed should be setup with a fee recipient address - an Ethereum address that transaction fees earned from proposing blocks are directed to. Additionally, these clients will require key management on the part of the user to ensure that attestations to blocks can be performed. There are a number of approved tools to assist with the generation of these keys when on-boarding as a validator. If a user ever migrates devices it is crucial that keys are removed from the old consensus client installation to the new installation as ‘slashing’ can occur if two devices are operating the same validator. When generating keys a mnemonic will be provided that is necessary to continue as a validator or to withdraw invested funds.
If you lose access to your keys and mnemonic it will be impossible to prove your identity as a validator. If you lose access to your keys and mnemonic it will be impossible to withdraw any investment or returned yields. Unfortunately individuals have lost access to their mnemonic before. Understand the consequences, reduce your risk and be prepared for any eventuality.
Deposit data
With a computational device running an execution and consensus client, wherein the consensus client holds the necessary keys, it is now possible to prepare for the deposit requirements. After completing this step validators will join the activation queue. Each user must stake at least 32 ETH to be sent to and stored in Ethereum’s deposit contract alongside other data, known as the ‘deposit data’, in the form of a transaction. This process cannot be conducted manually and can only be done through approved tools. The deposit data is expected to stipulate the address from where the ETH is being received from, details about the keys being used by the validator and the address where all withdrawals will be directed to.
It is intended that any initial deposit and returned yields will be directed to the withdrawal address once one ceases being a validator. In the meantime though there will be a waiting period following the sending of all necessary deposit data before being able to participate as a validator and earn yield. Through querying the beacon chain explorer using the keys associated with one’s consensus client it can be found if a validator has progressed from the activation queue. While active as a validator it is still a good idea to keep an eye for other status updates.
Activation queue to become a validator
There is a cap on users that are allowed to join as validators (or withdraw) every 6.4 minutes (also known as an epoch, further clarified in the section Responsibilities as a validator) as a percentage of total active validators. This limit has been conceptualised as an assurance of stability across the network where too many dishonest users joining or honest users withdrawing simultaneously makes attacks more feasible. Figures for the size of the queue waiting to be activated and count of active validators that are current to the time of the reader of this article will be readily available online; below is presented some examples of possible time spans that a new user will wait.
| Active validators | Churn limit | Queue size | Minimum expected wait |
|---|---|---|---|
| 500,000 | 7 | 76,000 | 48 days |
| 590,000 (June 2 ‘23) | 9 (June 2 ‘23) | 76,000 (June 2 ‘23) | 37 days (June 2 ‘23) |
| 1,000,000 | 15 | 76,000 | 23 days |
| 2,000,000 | 30 | 100,000 | 14 days |
| 3,000,000 | 45 | 500,000 | 49 days |
Responsibilities as a validator
Roles to perform
Blocks are published to the main chain periodically every 12 seconds in what is known as a slot. In a given slot a randomly determined validator collects a set of transactions and proposes the block to be published which other validators are then expected to ‘attest’ to. One block assigned by the network must be attested to (claiming that the block is valid) by a validator per a series of 32 slots (an epoch). Some are also chosen to ‘aggregate’ the attestations of a subset of the validators allowing for a reduction of the overall impact on the network that would result from processing all individual attestations at once.
Therefore, there are three possible roles that may be expected to be fulfilled in a given slot: proposing, attesting to or aggregating attestations for a block. These roles require computational effort to perform in terms of remaining actively connected to the network, keeping blocks stored in memory and executing transactions to confirm their validity. Assuming that all steps to become a validator have been satisfied these responsibilities will be performed automatically as long as the device hosting the clients remain connected to the network. It is in the performing of these responsibilities that validators see returned yield.
Impact on users and the network
It is the publishing of and attestations to the validity of blocks that ensure the functioning of the Ethereum network. Otherwise no transactions would be published or finalised meaning that no activity could occur within Ethereum; and as such why there is reward for the performing of these responsibilities. Some reward is derived from fees paid by those submitting transactions to be published in blocks and the remainder is derived from inflation (new ETH issued regularly). In a future article more information will be presented as to how users can withdraw the latter rewards, derived from inflation, and start spending them on the Ethereum network in their own transactions.
An often overlooked benefit of being a validator is the privilege to have a view of the blockchain that is guaranteed to be current and valid, without having to rely on APIs that can be delayed or faulty. These guarantees are often necessary to build significant infrastructure that sits on the Ethereum network. Examples might include POS software or stock markets where demand for current and valid data is a necessity to be viable against competitors. If one intends to operate a project on the blockchain as a business or provide APIs to support other businesses in their pursuits then it is important to consider the benefits of becoming a validator.
