Finance

Information from Etherscan.io (December 24th, 2019):

by Jim McDonald

When creating a staking deposit for Ethereum 2 two keys are used to generate the information in the deposit agreement: a validator key and a withdrawal key. This article discusses what these keys are, what they are used for, and the levels of protection that should be applied to each of them.

Ethereum 2 keys:

Ethereum 2 keys are similar to Ethereum 1 keys in principle, in that they are generated using elliptic curve cryptography. However, to enable some advanced operations, in Ethereum 2 the parameters of the curve used to generate the keys is different. As a result, Ethereum 1 keys cannot be used in Ethereum 2. This means that until wallet software and hardware are updated to provide support for Ethereum 2 keys, users will need to be more aware of the keys they generate, how best to safeguard them, and the consequences if they are lost or stolen.

The validator key:

The validator key is used to sign all on-chain operations that the validator carries out. These include proposing blocks and attesting to others’ blocks (hereafter just called “attesting” for brevity).

It is not possible to use the same validator key for different validators. If multiple deposits are made with the same validator key they will accrue to a single validator (but bear in mind that any balance over 32Ξ will be ignored; see this post for details).

Loss/theft of the validator key:

If the validator key is lost the validator can no longer attest. Over time, the validator’s balance will reduce as the validator is punished for lack of participation in the consensus process. Eventually the validator’s balance will be reduced to 16Ξ, at which point it will be ejected from the validator pool. The remaining balance will become eligible for withdrawal after a delay of just over 1 day.

If the validation key is stolen the thief could carry out one of two malicious actions. The first would cause the validator to exit the validation pool through a process known as “voluntary exit”; a voluntary exit results in the validator ending its validation work and its entire balance being returned, becoming eligible for transfer.

The second, more extreme, action would cause a slashing condition. Describing the full technicalities of slashing is beyond the scope of this post, but if attesting is equivalent to voting then a slashing condition can be created by voting twice in the same election for different candidates. When the network detects this condition it will eject the validator from the validator pool through a process known as “forced exit”, and also apply a slashing penalty to the balance before returning it. The cost of the penalty is dependent on a number of network factors, but could be anything up to the entire balance.

The withdrawal key:

The withdrawal key is used to sign any request made by a user to transfer funds from the validator once it has exited (either voluntarily or forced).

It is possible to use the same withdrawal key for multiple deposits. In general it is better to have a single withdrawal key, unless the keys are stored in separate locations or be otherwise dispersed.

Loss/theft of the withdrawal key:

If the withdrawal key is lost there is no way to obtain access to the funds held by the validator. The funds can continue to be used by the validator, attesting and earning rewards, but without any way of retrieving the balance there is little point to do so beyond an altruistic desire to support the network.

If the withdrawal key is stolen the thief can transfer the validator’s balance, but only once the validator has exited. If the validator key is not under the thief’s control there is a possibility that a user could quickly exit the validator and subsequently transfer their funds before the thief can do so.

Protection and management of keys:

The very different functions of the validator and withdrawal keys result in very different security recommendations.

Validator keys must be available for signing at all times, which limits their protection via the traditional means of taking them offline. Validators currently have their own key management systems, however over time it is expected that the development and use of remote signers and standardized wallets will allow the keys to be stored more securely, along with the possibility of using hardware wallets that never disclose private keys. Backups of validator keys should also be available for recovery in relatively short order, to counteract the fact that an offline validator will lose funds all the time it is not attesting.

Withdrawal keys should be stored in a secure location, preferably offline and if not then behind multiple layers of encryption. There is no immediate requirement for withdrawal keys to be available as they have no use until transfer operations are added to Ethereum 2. Multi-party security systems such as Shamir’s secret sharing can be used to provide additional security for the key(s) if required.

As new wallets and custody schemes become available for Ethereum 2 their usefulness for storing validator and withdrawal keys can be evaluated using the above information. Attestant will assess these as they become available, so watch out for updates in the new year.

by Jim McDonald

Ethereum 2 uses proof of stake to secure its network, but to do so requires each active participant (known individually as a validator) to have funds to stake. Ethereum 1 accounts hold funds, and these funds needs to move to Ethereum 2 validators, where they can be staked.

The validator carries out the work of proposing blocks and attesting to others’ blocks (hereafter just called “attesting” for brevity), whereas the staker provides the funds to stake. They may be the same or different entities; best practice recommends that these roles are separated for highest security of funds.

The process of sending funds from Ethereum 1 to Ethereum 2, along with defining the staker and validator, is known as staking and the first step of staking is to send a staking deposit transaction on Ethereum 1. The staking deposit transaction contains the details of who is staking, who is validating, how much is being validated etc. and is cumulatively known as a deposit agreement. This article looks at staking deposits in detail, and explains the process of using Ether on Ethereum 1 to fund a validator on Ethereum 2.

Creating the deposit agreement:

The deposit agreement defines the roles of the staker and validator, and forms the basis of the transaction sent to start the deposit process.

Figure 1: The deposit agreement and its participants

Validator identification:

Validator identification is required to ensure the deposit is credited to the correct validator. The validator identifies themself by adding their public key to the agreement:

Figure 2: Validator identification

Note that the validation identification uses an Ethereum 2 public key rather than Ethereum 1 public key, as it is used in Ethereum 2 to identify the validator.

Amount staked:

The amount staked needs to be included to ensure that both parties (and both networks) agree on the amount to be staked. The staker adds the amount they wish to stake to the agreement:

Figure 3: Amount staked

Withdrawal identification:

Withdrawal identification is required to provide the account to which withdrawals from the validator are sent. The staker identifies the withdrawal account by adding a manipulated public key to the agreement:

The public key is hashed to reduce its size; and The first byte of the hash is replaced with a type identifier (currently just ‘0’).

Figure 4: Withdrawal identification

Note that the withdrawal identification uses an Ethereum 2 public key rather than Ethereum 1 public key, as it is used in Ethereum 2 when it comes time to withdraw the stake. As such, it must be supplied directly by the staker rather than recovered from the transaction signature as is commonly the case with Ethereum 1 smart contracts.

Also note that if the validator and staker are the same entity different keys should be used for validator identification and withdrawal identification. This allows the withdrawal key to be held safely offline until the staker is ready to withdraw their funds.

Validator authorization:

Validator authorization is required to show that the validator agrees to validate within the terms of the agreement. The validator provides their authorization by signing the agreed terms with the same key as used to provide the validator identification, and adding that signature to the agreement:

Figure 5: Validator authorization

Submitting the deposit agreement:

At this point the deposit agreement has four pieces of information in it: the validator identification, the amount to be staked, the withdrawal identification and the validator authorization. If the staker wishes to proceed with the deposit they send a transaction to the Ethereum 1 deposit contract containing the agreement and the funds:

Figure 6: Submission of deposit agreement

There are two important points that need to be made here:

There is no explicit authorization in the deposit agreement by the staker. Instead, the staker adds their signature to the transaction prior to broadcast, providing the required authorization; and The transaction must be accompanied by the exact amount of Ether stated in the deposit agreement; any other amount will cause the transaction to be rejected by the deposit contract.

The transaction is received and processed by the Ethereum deposit contract; if all is in order the deposit contract creates a deposit receipt event. This deposit receipt event contains all of the data in the deposit agreement, and acts as notification that the deposit contract has accepted the deposit agreement and received the appropriate funds.

Activating the deposit agreement:

Activating the contract moves the focus from Ethereum 1 to Ethereum 2.

Ethereum 2 listens to updates on Ethereum 1 for deposit receipts. Each Ethereum 2 node includes the latest deposit receipts in its proposed blocks; as these blocks are finalized the deposit becomes part of the overall state of Ethereum 2. Deposit receipts are stored on Ethereum 2 as validator state.

The validator, in turn, listens to updates on Ethereum 2 for changes in validator state. When it sees an entry in the validator state with its public key it knows the deposit has occurred on Ethereum 1 and been recognized by Ethereum 2, and it is time to start its work of attesting.

Figure 7: Activation of deposit agreement

The full process:

Putting the submission and activation pieces together provides the full process of staking Ethereum 1 network funds on Ethereum 2, with information from the validator and staker passing from Ethereum 1 to Ethereum 2 and allowing secure activation of the validator with the appropriate funds:

Figure 8: Staking deposit process

Nuances:

Although they are not shown, this process involves a number of delays for added security. For example, there is a delay between Ethereum 2 finding a deposit receipt event and adding its information to the validator state, to ensure there is effectively no chance of an Ethereum 1 network chain reorganization that would invalidate the deposit.

The latest on the inner workings of eth2 and on the concrete requirements, incentives and experience of being a validator.

This article will provide a high-level overview of eth2 which will form the basis for a series on all aspects of eth2 relevant to validators. eth2 has been in the works for a long time now and has improved dramatically over the years. What were initially separate sharding and Proof of Stake (PoS) efforts managed via smart contracts has transmogrified into a highly interconnected design which yields dramatic improvements regarding efficiency, scalability and security.

The phases:

As parts of eth2 have become more interconnected, other pieces have been separated out into phases to allow for better pipelining of the different aspects of eth2. Phase 0 is nearing launch as developers put the finishing touches on the client software. Meanwhile, the specification for Phase 1 is being completed, and Phase 2 is under active R&D.

Phase 0 is concerned with the beacon chain, the core of eth2, which manages validators and the coordination of shards. The beacon chain is the source of ground truth from which all other aspects of eth2 are bootstrapped.

Phase 1 builds upon this by allowing data to be put into shards. The implementation complexity of this component is much smaller than the others as phase 0 lays most of the ground work for the shards.

Phase 2 adds execution to eth2 basically upgrading eth2 from a robust database to a fully decentralised computing platform.

What exactly is Phase 0?

As mentioned previously, the beacon chain tracks the state of both the set of validators and the shards. In practice this means that if you (periodically) follow what is happening on the beacon chain, you will know enough to verify anything said to be happening within eth2. Trust, but verify.

In order for a PoS system to function, there needs to be consensus on who the validators are, and on what each of their stakes are in order to know how much their votes are worth, and to appropriately reward and/or punish them for their behaviour. The beacon chain also manages the sharding aspects of eth2 by assigning validator duties in the shards as well as tracking the current state of each shard.

Part of what differentiates eth2 from other PoS systems is the sheer number of validators that can participate in the protocol. In contrast to the 10s, 100s, and 1000s of participants that are possible in other systems, eth2 scales to hundreds of thousands or even millions of validators. This level of decentralisation is only possible due to the intermediate levels of consensus achieved by groups of validators called committees. The beacon chain uses the eponymous random beacon at its core to assign validators to committees which are tasked with evaluating what is and isn’t a part of the beacon and shard chains. A committee’s votes are then cryptographically aggregated into an attestation meaning that verifying an entire committee’s votes is only marginally more effort than checking a single vote. Therefore, to check the validity of the beacon chain, only a few aggregated signatures need to be considered to evaluate the votes of many validators.

The beacon chain also tracks the eth1 chain and the deposits thereupon so that new validators can join eth2 by sending 32 Ether to the deposit contract on eth1. As a result of the beacon chain voting on the eth1 chain, eth2 will, at some point in the future, enhance the security of eth1 by providing an economic guarantee that blocks that are a part of the canonical eth1 chain.

Nodes vs. Clients:

eth2 makes the distinction between beacon nodes and validator clients, and validators will need both in order to perform their duties. A beacon node (or just node) concerns itself with maintaining a view of the beacon chain as well as whichever shards may be needed by a user or validator.

As their name suggests, validator clients (or just clients) handle the logic of a single validator. This is achieved by communicating with the beacon node to understand the current state of the chain, by attesting to and proposing blocks as well when appropriate, and finally by asking the beacon node to send this information on to its peers.

If you are not running a validator, a beacon node contains all of the information you need to trustlessly interact with eth2, much like a full node in eth1.

Below are some of the many arguments for this separation:

Each validator needs to be initiated with a deposit of exactly 32 Ether and therefore people who wish to stake more ETH will need to run multiple validator instances. The node-client separation allows such users to only run a single beacon node with multiple validators connected to it thereby reducing computation, memory, and storage requirements.

By having validator nodes be separate modules, they will likely be more secure as it is easier to write, reason about, and audit smaller code modules.

For users particularly worried about redundancy, multiple nodes can be run in parallel, thus reducing the chance of a validator going offline.

Because validator clients can only interact with the rest of the eth2 network via a beacon node, and even then via a restricted API, the attack surface of a validator node is greatly reduced.

For users who wish to interact with eth2, but don’t want to be a validator, they need only operate a beacon node which will grant them access to the beacon chain and all the shards they require.

Design Philosophy:

The design philosophy of eth2 provides useful context for all the decisions made within eth2 and in many instances encapsulate the differences between eth2 and other protocols.

Protocol über alles: With the acknowledgement that everything is a trade off, the protocol’s safety and liveness take precedence over other design desiderata.

Hope for the best, but expect the worst: eth2 assumes validators will be lazy, take bribes, and that they will try to attack the system unless they are otherwise incentivised not to. Furthermore, the network is assumed not to be entirely reliable and that catastrophic events could force large numbers of validators to go offline. For these reasons, eth2 should be capable of surviving World War 3.

Minimally viable complexity: Wherever possible, eth2 has been simplified as this makes it easier to reason about, explain to others, audit, write bug free clients, and generally avoid edge cases.

Maximally decentralised: Proof of stake protocols commonly compromise on the number of validators that can participate, eth2 is designed to scale to millions of validators while encouraging these validators to work independently of one another.

Expect the unexpected: All components of eth2 are resistant to quantum computers or can be swapped out for those that are in the event of a quantum apocalypse.

By the people for the people: eth2 must be able to run on a consumer laptop. The lower the barrier to entry, the more people who can participate which translates into a higher degree of decentralisation.

The next posts in this series will tackle the juicy details of what makes eth2 tick.

Understanding validator effective balance by Jim McDonald.