Learn how to send ETH to the deposit contract and become an Eth2 validator
When the Eth2 mainnet launch date is announced, the entire crypto community will be buzzing with excitement. But the spotlight will be on becoming a validator and the process of staking on the Beacon Chain.
Let’s start with the requirements: a single transaction on Eth1 with the validator’s credentials and 32 ETH.
The Deposit Contract
The way we deposit the 32 ETH and generate our validator and withdrawal keys are through an Eth1 transaction to a specific contract that contains the function signature below:
The Eth2 deposit function takes 4 arguments
The function takes 4 arguments:- pubkey – the validator’s validator BLS12-381 public key
- withdrawal_credentials – a hash of the validator’s withdrawal BLS12-381 key. It’s hashed to preserve privacy.
- signature – signature over hash_tree_root of di_0 (see below) and domain bytes
- deposit_data_root – the hash_tree_root of di_1 (see below)
The first 2 inputs (pubkey, WithdrawlCredentials) of the deposit contract are self explanatory, while the later 2 require a more detailed background explanation. To explain the signature we need to first explain and define a “rogue key attack”.
An Eth2 private key attack
The Rogue Key AttackIf we break down the contract above it’s basically a method to map an Eth1 account that deposits 32 ETH and a BLS12-381 validator key, which will be then used on the Beacon Chain for validating blocks.
The Eth1 address that facilitated the deposit is clearly controlled by someone who owns its corresponding private key, otherwise he could not have sent the transaction. But what about the validator key? How can we know the user controls their private key?
Why is it even important?Eth2 uses BLS signature aggregation extensively for adding efficiency. This results in many validator signatures getting compressed into a single signature. All of which could be validated using only 2 pairing operations. It is much more efficient than verifying each signature individually.
The way signatures are aggregated is pretty straightforward, they are simply added to one another like so:
If the signature itself is over the same message, than the actual verification takes the form of:
For more info read Vitalik’s blog post (highly technical)
When viewing the equations above, a vector attack pops up to a trained eye. Essentially, if someone broadcasts a signature with a public key, designed like the below (pk2), he can commit an unsuspecting validator to a signature (and a commitment) unwillingly as that signature will verify the pairing equation above. This is not ideal.
This type of “rogue key attack” needs to be solved by every validator proving they have possession of the private key that compiles to his published public key. If we look at the deposit address again, it’s now clear why it requires a signature using the validator BLS12-381 key. If it’s not clear, essentially, the signature provides the proof that the validator possesses the private key to prevent a rogue key attack.
Verifying the BLS12-381 key signature
Verifying the SignatureGoing through the code for the deposit contract, the actual signature is not verified there but rather on the Beacon Chain nodes. The reason for this is that EVM did not support BLS curve operations, but things have changed!
EIP-2537 which was recently merged, will offer the main curve operations that will enable the deposit contract to verify the actual signature and reject any attempts to create an invalid validator right on chain! This will protect these unwilling participants from forcing a validator to sign incorrectly, harming their reward potential.
These EIP curve operations are a major milestone which will enable a lot of innovation like decentralized staking pools based on distributed-key-generation.
An example of how this could be used is provided by the authors of EIP-2537:
To reiterate and conclude, the deposit transaction transfers the necessary staking funds into a locked contract to activate a validator. However, I discovered that there are still some security issues for keeping deposits safe, which will be addressed in a future technical blog post.
By: Alon Muroch
CEO & Co-Founder of Blox
