Practical information | Simulation of rewards and penalties in Ethereum 2.0 Phase 0

Author: ConsenSys

Translation & Proofreading: Min Min & A Jian

Source: Ethereum Enthusiasts

Introduction

ConsenSys Codefi is building a blockchain operating system for trade and finance, facilitating the global market into the era of "Finance 2.0". To achieve this goal, the most critical part is how to create and utilize native digital assets, and use them as an incentive to maximize the decentralization of the network, becoming a reliable pillar for new financial products and markets. Achieving "Ethereum 2.0" and the transition to proof of stake is our top priority. We are happy to share relevant experiences, knowledge, and discuss related topics including token economics.

The huge demand for the Ethereum 1.0 blockchain has sometimes resulted in a poor user experience, such as transactions taking a while to be posted and transaction fees (Gas) fluctuating wildly. High scalability — increasing the ability to process thousands of transactions per second from the current rate of about 15 — has long been one of Ethereum’s goals.

We are currently in the first phase of Ethereum 2.0, Phase 0. Once all phases of 2.0 are deployed, transaction volume will increase dramatically. To achieve this goal, Ethereum will take two major upgrades: sharding and proof of stake. After the upgrade, the economic mechanism, consensus mechanism, and operation mechanism of the Ethereum network will change. We will give a detailed introduction below.

excitation

Ethereum 1.0 is a blockchain that uses a proof-of-work mechanism: miners must calculate the solution to a computational problem to mine a block. The probability of solving the problem is proportional to the computing power of the computer they provide, and inversely proportional to the difficulty of the problem on the entire chain. If the miner successfully mines a block, he can get a reward of 2 ETH and transaction fees. This is the core of proof of work. You can estimate the computing power of the entire network based on the difficulty value of the previous block, and then further deduce the probability of you mining the next block, so as to predict your own costs.

In terms of consensus mechanism, Ethereum 2.0 is more technical.

If you want a rough guide here, please skip to the “Practical Network Issuance Rate Estimation Method” section below.

The purpose of this article is to give readers an overview of Ethereum 2.0's proof-of-stake implementation and its rewards and penalties. We will break down the economic incentives and quickly assess the return on investment (ROI) that staking can bring. Finally, we will introduce the simulation that the Codefi Staking-as-a-Service team is building so that readers can understand this topic in more detail.

Honest Validator

As long as you deposit funds into the deposit contract deployed on the Ethereum 1.0 blockchain, either one or more times, and the total amount is equal to or greater than 32 ETH, you will be eligible to become a validator on the Ethereum 2.0 beacon chain.

You can deposit an unlimited amount of money into the margin contract. However, the effective balance, that is, the amount of equity the beacon chain determines when it is running, is capped. In other words, your balance can be as high as 1000 ETH, but the rewards and penalties you can receive only depend on your effective balance, which is capped at 32 ETH.

On the other hand, if you as a validator are punished and your balance drops below 16 ETH, a forced/involuntary exit will be triggered.

An honest validator is an individual who runs a client that is written according to the beacon chain specification and avoids taking actions that violate the protocol.

It is important to emphasize that penalty is completely different from slashing. The former refers to the deduction of part of the validator's balance due to (within certain parameters) voting incorrectly or being offline. If a validator is found to have violated the penalty conditions when generating a witness message, it will be forced to withdraw from the validator team. During the period of queuing for withdrawal, part of the balance will be deducted as a penalty in each epoch (period).

On the Block Production and Consensus of Ethereum 2.0

The basic time unit for the beacon chain to run is called a slot. Just like a heartbeat, every 12 seconds is a slot, and a validator is selected to propose a block. Once a block is generated and broadcast, the witness committee composed of some validators will vote on the block to decide whether to include it in the blockchain.

The "committee" is designed to assign validators to different validation tasks, so that each validator can vote once during each epoch (i.e., 32 slots). The validators in the committee communicate with each other and can aggregate their voting messages ("witness messages") together. If the selected block proposer in a slot does not propose a block, the slot is considered a skipped slot. In this case, further proposals and witness messages are created based on the last block in the previous slot.

The proposer's job is to generate a block that he/she thinks can be added to the top of the chain. As for which chain is the main chain, it is determined by the LMD GHOST fork selection algorithm: among all the forks that have received votes, the one with the largest weight is found recursively, and then this fork is selected. When validators witness a block, they are actually voting for the fork where the block is located.

To achieve blockchain finality (ensuring that the state does not roll back), honest validators provide two additional votes in their attestation messages to drive Ethereum 2.0’s Casper the Finality Gadget (FFG) algorithm: one for the latest justified epoch (as the source checkpoint), and another for the latest epoch boundary (as the target checkpoint).

- Source: ConsenSys Codefi Analysis -

At the beginning of each epoch, the votes in the witness message are calculated. If there is a latest rationalization epoch that has received an absolute majority (2/3 or more) of votes, the checkpoint will be advanced to that epoch. According to certain rules, the parent epoch and even the ancestor epoch of this epoch will be finalized.

If the system fails to achieve finality within several consecutive epochs (the current specification is 4), all validators on the beacon chain will suffer an inactivity penalty. There is a lot to expand on here! If you want to know more details, you can refer to "Combining GHOST with Casper" written by Vitalik et al., the Phase 0 beacon chain technical specification released by the Ethereum Foundation, Danny Ryan's article on Phase 0, and Joseph Chow's article on the beacon chain (Editor's note: See the hyperlink at the end of the article "Eth2 Beacon Chain: What You Should Know First", which describes the operation of the beacon chain in more detail than this article).

Reward and Punishment Measures

Confiscation

Being slashed means that the validator will be forced to exit the beacon chain at some point in the future and will continue to be punished before exiting.

If any of the following three situations occur, the validator will be fined:

1. As a block proposer, propose two different beacon chain blocks in the same slot.

2. As a witness, in FFG voting, the two epochs pointed to by the new witness message just "surround" the two epochs pointed to by the previous witness message (called "surround voting").

3. As a witness, the multiple witness messages sent clearly point to the same target checkpoint, but the source checkpoints are different (called "double voting").

The slashing process will only be triggered if the validator is discovered. The validator who acts as a whistleblower needs to create and spread a special message containing evidence of the violation so that the block proposer can include it in the block. Both the packaged block proposer and the whistleblower will receive rewards.

This is not obvious in the spec, but in Phase 0, only the proposer gets the whistleblower reward — that is, the proposer gets the full slashing reward (8/8).

• Constant minimum penalty factor = 32

• Constant whistleblower reward factor = 512

• Constant proposer reward system = 8

Validators who violate the rules will be fined and can get their balance back within the next 36-day epoch set (8192 epochs).

In addition, slashed validators will suffer the following penalties:

1. When the proposer packages the reporting information into the block, the validator will be deducted the basic penalty.

2. At the beginning of each epoch, the validator will be penalized for not being able to participate in head/FFG voting until he passes the exit queue waiting period.

3. During the period from when the report information is packaged into the block to when the balance can be retrieved, the validator will be deducted a special penalty.

The special penalty is proportional to the number of other validators that were slashed during the same period. The special penalty can be up to the same amount as the effective balance of the offending validator.

• Constant penalty factor = 32

• Constant base bonus factor = 64

• Constant base reward per epoch = 4

• Constant effective balance increment = 1

Epoch processing

Each epoch (except the Genesis epoch, which contains 32 slots) needs to complete the following tasks at the beginning:

1. Confirm the legitimacy and finality of the previous blockchain

2. Reward and Penalty Amounts for Settlement Witnesses

3. Update the validator registry

4. Settle special penalties for slashed validators (see above)

5. Complete some final updates (calculate effective balance, reset, etc.)

A validator must be active in the previous epoch to receive rewards and/or penalties. Before exiting the system, a validator that is penalized will also enter this process, but will only be penalized when the FFG corresponding settlement is performed.

If a validator was active in the previous epoch but did not vote, they will be penalized for not being able to match their FFG vote. Validators will not be penalized for being offline.

- Source: ConsenSys Codefi Analysis -

Assumptions

• Finality delay = previous epoch - finalized epoch

• Witness balance = the sum of witness balances that have not been slashed.

• Constant base bonus factor = 64

• Constant base reward per epoch = 4

• Constant proposer reward factor = 8

• Minimum epoch span value for constant not to be used as penalty = 4

• Constant not used as penalty factor = 2^25

- Source: ConsenSys Codefi Analysis -

Practical method for estimating network issuance

Let's use our new knowledge to make a rough estimate of the amount of rewards and penalties for any epoch. We want to keep it simple, so let's start with two parameters.

The first parameter is easy to understand. The second parameter refers to the probability that a randomly selected validator can participate in the beacon chain (host is turned on) if the network or other conditions are met.

- Source: ConsenSys Codefi Analysis -

If we assume that the balance and effective balance of all validators on the beacon chain are equal to 32 ETH, and use the online probability above, we get the following data:

- Source: ConsenSys Codefi Analysis -

Now we can calculate the rewards and penalties for each validator, as shown in the following table:

- Source: ConsenSys Codefi Analysis -

There is still some work to do to calculate the last two incentives: block witnesses are assumed to be online validators in slots, evenly distributed in each epoch; to calculate validator incentives, we first need to define the expected value probability tree and then converge the resulting geometric series, since the reward is inversely proportional to the difference between the time the witness message is sent and the time it is uploaded to the chain.

We can see that the proposer incentive far exceeds the other three values. Let’s review the knowledge point: each slot will select a proposer from all validators on the beacon chain. As the total stake increases, the probability of becoming a proposer will decrease. In other words, in an epoch, only 32/n validators can become proposers.

Also note that we do not make any assumptions or calculations about slashed validators and their whistleblowers, or delays due to inaction.

If we multiply each value by the number of online/offline validators and add the resulting values ​​together, we can get an estimate based on the initial conditions.

Therefore, the net increase from all rewards minus all penalties in one epoch is 1,247,117,399 Gwei.

That is to say, when the total stake is 500,000 ETH and the online probability is 95%, approximately 1.25 ETH rewards will be generated in each epoch (6.4 minutes).

Based on the 95% online probability, we can further calculate the changes in rewards generated in each epoch when the total stake amount is different, and draw a chart.

- Source: ConsenSys Codefi Analysis -

Summarize

Should we use the rewards generated in each epoch to calculate an estimated annual reward?

Before we answer in the affirmative, let us consider the following factors:

Balance

In each epoch, the balance affects the creation of ETH in various ways. For example, if the validator's effective balance reaches the upper limit (32 ETH) and is rewarded with it, the excess balance will not affect the calculation of the next epoch. In addition, due to the hysteresis of the change of effective balance, each validator will actually "lose" some ETH.

The following situations should also be considered: a validator may be expelled because the effective balance is lower than the lower limit (16 ETH), someone may send a deposit to the Ethereum 1.0 margin contract to become a validator, and a staker may trigger a voluntary exit mechanism.

Confiscation

It takes a lot of time to model the slashing operation. First, we need to consider the understanding of the slashing conditions and the avoidance mode adopted by the developers of Ethereum 2.0 clients and staking service providers. On the other hand, we can only guess the proportion of honest participants in the system; and the probability that the violation will be discovered, broadcasted and packaged into the block.

possibility

We have already mentioned the proportion of honest participants and the probability of violators being reported. Let’s think about the different ways we can measure and infer whether a node is online, well connected and working properly, whether its witness messages are gathered and included in the block on time, and whether it sees the slot that most nodes see.

The beacon chain is a complex adaptive system. Even if we understand the individual parts of this system well, this does not guarantee that we understand the entire system well.

The first step to gaining a deep understanding of something is to choose the methods and tools to study it. By modeling and simulating validators and their interactions with the beacon chain under some initial conditions, assumptions, and constraints, we can gain a deeper understanding of the complexity of proof-of-stake implementations.

Acknowledgements

This article was written by Herman Junge, Architect and Technical Director of ConsenSys Codefi Staking-as-a-Service Platform.

We would like to thank Joseph Chow, Ben Edgington, Sylvain Laurent, Diederik Protolambda Loerakker, Tim Lowe, Danny Ryan, Alex Stokes, and Kuhan Tharmananthar for comments on the manuscript.

Original article: https://codefi.consensys.net/blog/rewards-and-penalties-on-ethereum-20-phase-0