When the Eth 2.0 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 processing of staking on the beacon chain.
Let’s start with the requirement: A single transaction on Eth 1.0 with the valdiator’s credentials and 32 Eth. For most this initial stage will be the most frightening part, especially if this mysterious transaction is not fully understood.
I will seek to demystify this deposit transaction, address its challenge and the logic behind its construction.
The Deposit Contract
The way we deposit the 32 ETH and set our validation and withdrawal keys are through an Eth 1.0 transaction to a specific contract that contains the function signature below:
The function takes 4 arguments:
- pubkey – is the validator’s validation BLS12-381 public key
- withdrawal_credentials – is 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 – is 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”.
The Rogue Key Attack
If we break down the contract above it’s basically a method to map an Eth 1.0 account that deposits 32 ETH and a BLS12-381 validation key, which will be then used on the beacon-chain for validating blocks.
The Eth 1.0 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 validation key? How can we know the user controls their private key?
Why is it even important?
ETH 2.0 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 individual.
The way signatures are aggregated is pretty straightforward, they are simply added to one another like so:
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 validation 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 Signature
Going through the code for the deposit contract, the actual signature is not verified there but rather on the beacon-chain nodes, instead. 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.
Check out our blog later to learn more about staking and Ethereum 2.0.
It’s important to shed light and clear the air on how deposit transactions and validators operate in the new age of “Serenity” and Eth 2. By informing and educating, better decisions can be made when seeking the right staking solution, following the launch of Ethereum 2.0 mainnet!
By: Alon Muroch
CEO & Co-Founder of Blox