# Understanding post-merge rewards

BY Jim McDonald ON Mar 31, 2022

# Introduction

The upcoming merge of the Ethereum consensus and execution chains has resulted in confusion over rewards: where they come from, what happens to them, and how to access them. This article looks at rewards on both consensus and execution chains, providing information about the source of rewards for each chain and how they can be accessed both immediately after the merge and with later upgrades.

# The consensus chain blocks and state

The consensus chain, also known as the beacon chain, is Ethereum’s proof of stake mechanism. The main actors on the consensus chain are validators. These are logical entities that help secure the chain by providing an initial 32Ξ deposit, and then attesting to the state of the chain. Very briefly, and much simplified, the chain is secured by validators attesting to the head block of the chain, and when enough validators have attested to a given block it is considered final.

The structure of a block in the consensus chain is shown below:

In the above figure, “Operations” are various consensus chain activities, including the previously mentioned attestations.

Ordering of blocks in the chain is managed by the “parent root” field. Each block can be identified by its root, the root being a relatively small but unique identifier calculated using the SSZ hash_tree_root method. The parent root is the root of the immediately preceding block; by including the parent root of the previous block in the current one a link from one block to the next is formed. The linkage from each block to its parent results in a chain of blocks, hence the term “blockchain”.

The state of the consensus blockchain at a given point in time contains various pieces of information such as the time the blockchain was started, the impact and effectiveness of recent votes, and a list of validators. The state also, critically for the purposes of this article, contains the balance for each of the validators. The state of the blockchain at a point in time can be calculated from the initial state (known as the “genesis state”) plus the intermediate blocks. States and blocks are deeply related, with each successive state being the previous state plus the changes as described in the block, and each block being built based on information held in the current state. Similar to the parent root, a state root in each block is included that defines the state upon which the block is built.

Blocks are built upon a given state, and the application of a block to the state on which it is built generates a new state from which the next block can be built. This interaction between blocks and states is the “tick” and “tock” heartbeat of a blockchain, and is common to all such systems.

With this basic understanding of the relationship between blocks and states, we now examine validator rewards. Validators are rewarded (or punished) depending on their actions: proposing blocks, attesting to the state of the chain, and generating sync committee messages. All of these operations can be ascertained from the contents of the block, and the net change that occurs from these operations is added to the relevant validators’ balances.

Rewards for consensus operations are issued by the protocol when it processes the operations in the block, and credited to the validator. This flow of rewards as a result of operations is shown in blue in the above figure 4.

# The Merge

The execution (Ethereum 1) chain processes user-submitted transfers with its own execution engine to run smart contracts, but uses the proof of work mechanism. The consensus chain provides a working blockchain based on a proof of stake mechanism, however it does not process user-submitted transfers or have its own execution engine with which to run smart contracts. The combination of the features of the former with the security of the latter is colloquially known as “the merge”. The merge is provisionally expected to arrive in the middle of 2022, and will provide a combination of the high levels of security and low levels of energy usage available with the consensus chain, and the state and execution capabilities of the execution chain. It is very much worth exploring how this will be achieved.

With the merge, validators will include additional data in the consensus blocks they build. In addition to the consensus data, consensus blocks will include execution data as shown below:

Many parts of the execution data mirror those in the consensus data. The state root in the execution data is a direct equivalent of the state root in the consensus data in terms of form and function, and the parent hash in the execution data is similar to the parent root in the consensus data. Balances for validators exist in the consensus state, and balances for accounts exist in the execution state. The critical difference, though, is the addition of transactions in the execution data. Transactions are the user-submitted requests to transfer value or interact with smart contracts, and give the blockchain its function.

The inclusion of this information in the block built by validators means that validators completely replace the function currently undertaken by miners, creating blocks containing transactions that will be executed for transfers and smart contract functions, and enabling the shift of Ethereum from proof of work to proof of stake. The execution data has the same level of security as the consensus data, as it forms part of the consensus block secured by the proof of stake mechanism. This means that execution state can be built from the execution data in the same way as the consensus state built today.

Above, we see the structure of the Ethereum chain after the merge: a single blockchain with two parallel states, one for consensus and one for execution. And in the same way that rewards that are obtained for including consensus operations in the block, rewards are also obtained for including transactions in the block (see figure 7 below).

Rewards for transactions are transferred from the entity submitting the transaction to the validator1. Because the execution chain is where these transactions take place, it is also to where the rewards are transferred, and the flow of rewards can be seen in green on the above figure.

As seen above, rewards resulting from transactions are accrued to accounts on the execution chain. Because they are on the execution chain they can be treated like any other Ether: transferred, traded, used for smart contracts etc. These rewards are available as soon as the block created by the validator has been incorporated into the chain.

Rewards resulting from consensus operations are slightly different. Because they are on the consensus chain they accrue to the validator directly, and because there is no execution on the consensus chain it is not possible to access them at current.

# Withdrawals

Although rewards on the consensus chain are not currently available, work is underway to make them accessible. The full process is still undergoing design, however the current plan is to add more information to the execution data:

The additional field “withdrawals” in the execution data provides details of reductions in balances to validators on the consensus chain as a result of withdrawals. This information is processed on the execution chain in the same way as a transaction, and results in the amount removed from the validator on the consensus chain being added to an account on the execution chain. In this way, the Ether generated by validators is unlocked and made available.

Once implemented, withdrawal operations will allow both full withdrawal of an exited validator’s 32Ξ deposit and the accrued rewards, and withdrawal of just the accrued rewards of an active validator without requiring it to exit (a process known as “skimming”). Withdrawals will complete the journey that started in December 2020, unlocking long-held rewards and making validator rewards an active part of the Ethereum chain.

1. Technically speaking, to the fee recipient but the validator has the opportunity to set the fee recipient when it is building its own block so they will commonly be under the control of the same entity.↩︎