27
loading...
Ethereum 2.0 For Dummies — Part 2: How Does Staking Actually Work?
_This is second part of a 2-part series. You can read Part 1 [_here](https://tobyornottoby.medium.com/ethereum-2-0-for-dummies-part-1-why-upgrade-112d8f5b6d88).
Ethereum 2.0 (Serenity) is an upgrade to Ethereum’s economic infrastructure in order to allow new avenues for gains in scalability, security, and efficiency. In Part 1 we discussed the overarching ideas and rationale behind the network upgrade and its transition from Proof of Work to Proof of Stake. We touched upon sharding and its anticipated effects on increasing scalability, as well as the use of validators in lieu of miners — allowing for more efficient network security. I also introduce a quick glossary of terms, which will be helpful to read/review before continuing with this section¹ (actually I really recommend it). Some of this stuff can get a little dry, so I’ve sprinkled in some memes to keep you going :)
We begin with an overview of the planned phases of the Eth 2.0 Upgrade, which is really a set of interconnected upgrades²:
Phase 0 — Beacon Chain & Proof of Stake
Phase 0 of the Serenity update package is live as of December 1, 2020 and includes the introduction of the Beacon Chain and the Proof of Stake Protocol (discussed in detail below). It will run separate and parallel to the PoW Eth 1.0 chain, and serves as the central point of truth (the main chain) for Eth 2.0 and broadcasts and receives from the rest of the system, including shard-chains. Each node will maintain it’s own local copy of the Beacon Chain, much like chain now. The Beacon Chain will maintain the set of validators and their balances, and essentially administer the new Proof of Stake Protocol.
Phase 1 — Sharding / Shard Chains
Phase 1 will implement shard-chains, which is a scaling solution (explained in Part 1 and below) that breaks up the Ethereum network into 64 smaller shards to increase capacity and speed of transactions. It will also provide the framework for roll-ups which is another scaling solution that includes processing and aggregating transactions off-chain to be executed and confirmed on-chain. This is estimated to be introduced late this year or early 2022.
Phase 1.5 — Merging the original Proof of Work Chain with the new Proof of Stake Chain
Phase 1.5 will bridge the gap between the current PoW chain and the new PoS chain. The current proof of work chain will be folded into the new Beacon chain by becoming one of the shard-chains. This ETH 1.0 mainnet shard will provide the history and current state of Ethereum to the new Beacon Chain, and serve as the transition from the old network to the new. This transition will mean that Ethereum 2.0 is officially live.
Phase 2.0 — Enable Transaction Processing on Shards (Smart Contract Execution)
Phase 2.0 will bring about the final touches on the Serenity upgrade. This includes introducing different execution engines to the shards, meaning they will then be able to support smart contracts and become fully operational. In this phase the Ethereum Virtual Machine (EVM), which is responsible for processing contract code, will be replaced with Ethereum Web Assembly (eWASM) which will provide efficiency gains in transaction processing and contract execution.
Now that you have any idea of the general game plan, let’s dive into specifics. But before we do that, let’s take a meme break.
To gain a good understanding of the Beacon Chain, we first need to dip our toes into what sharding is. As discussed in Part 1, part of Ethereum’s scalability issue is each node having to verify and execute every transaction. We mentioned that by splitting the blockchain into pieces for a subset of validators/nodes to process in parallel , the chain is processed much, much faster. This is great and all, but at this point the shard-chains all still need to be aggregated and verified in a single canonical source of truth. This is where the Beacon Chain comes in.
For simplicity’s sake we can consider the Beacon Chain to be the Eth 2.0’s main chain, the heart of the system. Shard-chains will be reconciled with the main chain through cross-links which we will explore in a bit. In the initial stages of Ethereum 2.0, there will be 64 shard-chains (there is capacity for a total of 1024 which can be added later).
The Beacon chain is processed in regular time windows called slots and epochs. An epoch is made up of 32 slots , and each slot is 12 seconds — so each epoch is 6.4 minutes (12sec x 32 slots). Each slot is a chance for a block to be added to the chain. Every 12 seconds (slot), one beacon chain block and 64 shard blocks are added. You can picture each epoch as a cycle in the blockchain validating process.
So how are the blocks processed within slots and epochs on the Beacon Chain?
This is done through a combination of proposing blocks and voting (or attesting) to them. The proposals and votes are made by validators, who are the virtual equivalent of what PoW miners are today. A block proposer is a validator that has been pseudorandomly selected to build a block , which is then attested (voted) by other validators. Most of the time, validators will take on an attester role as they vote on beacon and shard blocks. Validators are split/grouped into committees and these votes are aggregated (more below). These aggregated votes will determine the most recent valid beacon chain block, as well as the most recent valid shard-chain blocks, aka “ head of chain”.
There is a semantic difference between a staker and a validator. In Eth 2.0, users (stakers) stake ETH to activate and run validators. For every 32 ETH staked, 1 validator is activated. Stakers can stake as much ETH as they like, but a validator has a maximum balance of 32 ETH. A staker can run multiple validators. Validators use validator clients make use of a beacon (chain) node to follow and read the blockchain. One validator client can execute one or more validators. You can run a beacon node without running a validator. Confused yet? Here is a more concrete example to help:
Staker stakes 64 ETH > this activates (2) validators > validators use the same client (computer program/node) to participate > the client uses a Beacon Node (usually their own but can be a 3rd party) > the Beacon Node reads the blockchain and provides data back to the (validator) client > the validator client uses that data so that the (2) validators can run > the (2) validators run and generate staking rewards for the _ **_Staker**
Crosslinks are how the shard-chain blocks are reconciled into the Beacon Chain. During each 12-second slot, a Beacon Chain block is proposed. A Beacon Chain block can contain up to 64 crosslinks, one for each shard. As long as validators have voted and proposed a block for the shard during that 12-second slot, it can be cross-linked to the corresponding Beacon Chain block.
A committee is essentially a group of at least 128 validators (but can and will usually be more).
A proposer is a validator that is pseudorandomly selected for each slot. They temporarily take on the role of proposing or building a block for that slot, so that the other validators (grouped into committees) can vote on it.
During each 6.4 minute epoch, the validators on the network are evenly divided across 12-second slots and then subdivided into committees, from which the validators can cast their vote. Each committee within a specific slot attempts to crosslink a particular shard. This means that a single validator is only be allowed to attest/vote once per epoch. Each attestation is a two-part vote, one for the validator’s assigned shard, and one for the head of the Beacon Chain.
For example, say we have 32,032 validators (not a real number — currently there are ~185,000). 1001 validators are assigned to Slot #1, 1001 to Slot #2, ….. 1001 to Slot #32 (*32,032 validators / 32 slots). The 1001 validators in Slot #1 are subdivided into 7 committees and pseudorandomly assigned shards. For the sake of simplicity we say that Shards 1 2, 3, 4, 5, 6, & 7 (in reality, these would be a very random selection) were selected as shard assignments. All 1001 validators in Slot #1 cast a vote for the Beacon Chain head (called an LMD GHOST vote⁴, more on that in a sec). The 143 validators in the one of the 7 committees (*1001 / 7 = 143) attempts to crosslink Shard 1. 143 validators from another one of the 7 committees attempts to crosslink Shard 2, and so on and so forth.
For Slot #2, the process repeats. The 1001 validators in Slot #2 are subdivided into 7 committees which are assigned to shards 10, 15, 20, 25, 30, 35, 40. All 1001 validators cast a vote for the Beacon Chain head, and then each committee of 143 validators attempts to crosslink shards 10, 15, 20, 25, 30, 35, 40.
This process repeats for the rest of the 32 slots (epoch). Committees are shuffled around each epoch. Again, a validator can only vote once per epoch, which means it can only be in one committee per epoch. The minimum committee size of 128 is intentional — there is a statistical rationale behind it that requires a bit of high school math, which you can read about here⁵ . The gist is that 128 (or more accurately 111) is the number at which as long as 2/3 of all validators are honest it is extremely improbable for any one committee to be 2/3 dominated by dishonest validators (which means they’d have the majority and be able to act maliciously).
Each epoch block contains a checkpoint block and serves as the last point where the blockchain is finalized or agreed upon by all parties, as the name implies. You can think of them roughly as save points within a video game. If you’re character dies, you can go back to where you had last saved the game. They are also referred to elsewhere as Epoch Boundary Blocks (EBB), but we’ll stick with “checkpoint” here.
During each epoch, a validator will cast an LMD Ghost vote and a Casper FFG vote, as part of the 2-part vote I mentioned earlier. I’ll explain what these are here:
An LMD GHOST Vote is a vote for the Beacon head of chain (usually the block at their current assigned slot). LMD GHOST stands for “Last Message Delivered Greediest Heaviest Observed SubTree”. If this seems like a daunting concept to fully grasp, that’s because it totally is. Simply speaking, the LMD-GHOST protocol selects the head of the chain by choosing which fork has the most votes (let’s say one of the validators missed a block and votes on the previous block as the block head, while everyone else votes for the current block. The Ghost protocol would choose the current block as it has more votes).
A Casper FFG vote is a vote for the checkpoint within the current epoch (called the target ), and a vote for the prior checkpoint (called the source ).
A block or a checkpoint must have votes made by 2/3 of the total balance of all active validators. This is called a supermajority.
In essence, each checkpoint is voted on twice, once as the target and once as the source. When a target checkpoint receives a supermajority, it is considered justified. Once the checkpoint has received a supermajority in both instances, it has achieved finality and is considered finalized. Most of the time, finality is achieved in a little over two epochs. This is much like the required block confirmations that we see today in PoW.
You may be wondering how committees, proposers, validators are randomly assigned, and why this article makes use of the word “pseudorandom” as opposed to just “random”. This is because computers cannot generate true random numbers. A computer can be considered a deterministic system, which means that given the same input it always generates the same output (this is debated, but we won’t blow that dynamite here). In the same way a calculator will always give you 2 for the sum of 1 + 1, a computer cannot give you an unrepeatable output for the same input. This means that at best, a computer can simulate randomness, or a reasonably “random” number. In order to do this the computer needs a seed , a semi-random input or starting point to do calculations — like the position of the bubbles in your lava lamp at any particular point in time (this is a real thing , check it out). In the case of Eth 2.0, the “random validator selection” simulation is two-fold. First, validators select a random number of their choosing when depositing their 32 ETH, which gets hashed. In each block each validator’s random number is revealed one at a time. Once all the numbers are revealed the numbers will be put together to form a new random number which will determine the next block’s random selections. This paradigm is coupled with a mechanism called Verifiable Delay Function (VDF) which is essentially a check mechanism on the random process. I’ll try and keep it simple here but if you want to get more in depth with he logic behind Eth 2.0’s random generator, you can find out more here.
The obvious motivation for staking your ETH are the rewards you can generate by running a validator. There is however also a risk of losing some or all of your stake if you fail perform the expected tasks or are acting maliciously. Both the rewards and the punishments are proportional to the validator’s actions and form the basis of Ethereum 2.0’s incentive structure.
Let’s start with the good stuff. How are these rewards issued?
Validators are rewarded for making attestations, for proposing a block that gets finalized, or for raising an alarm that another validator that has committing a slashable offense (in ETH 2.0 snitches don’t get stitches, they get rewards). In each epoch, a validator can earn rewards to making LMD Ghost/Casper FFG votes that that the majority of other validators agree with. For each slot, a validator has the chance of being selected to be a proposer of a block. Should that happen, and the validator proposes a block that gets finalized, they will obtain a sizeable reward. Validators that are consistently doing their job attesting accrue a ~ 1/8 boost to their total rewards for proposing a valid block. A validator that provides proof that another validator is acting maliciously is rewarded.
Validators can also be penalized, but this can happen in several ways and in varying degrees. You can be penalized for not attesting or for attesting to blocks that do not get finalized (i.e. your validator goes offline). These are relatively minor and if you were to be offline or simply didn’t attest for an entire year, you would stand to lose about ¾ of the amount you’d stand to gain that year (e.g. if the reward rate averages out to 10% annualized, you would lose about 7.5% if you didn’t attest the entire time). This means that being offline for a few days or even weeks is still a relatively small penalty — especially compared to the next penalty method, slashing.
Validators can be slashed by maliciously or intentionally acting against the system. This is known as a slashable offense and is defined in 3 ways: a double proposal, an FFG surround vote, and an FFG double vote.
In a double proposal , a selected proposer tries to propose more than one block for their assigned slot.
In an FFG surround vote you are casting a vote for a target and source (current and prior checkpoint blocks) that is surrounded by a previous FFG vote that you made. This basically discounts the validity of your previous vote, and is disallowed. For example you voted for slots 32 as a source and 64 as a target in your previous vote, but in the current epoch vote for Slot 0 and Slot 96. Your current vote would surround the previous one.
In a double vote , you are casting two FFG votes in the same epoch, instead of the allowed one.
If you are slashed, you stand to lose up to your entire stake (32 ETH). You will lose at least 1/32 of your balance and deactivated (forced to exit as a validator). *As a side note, in the normal course of operation if a validator’s balance were to drop below 16 ETH, it is automatically forced to exit through deactivation.
There is also a rare but severe penalty known as the inactivity leak penalty. This is designed as a backstop against the entire system not finalizing checkpoints. Essentially if more than 4 epochs have passed since a validator has finalized a checkpoint, then an inactivity penalty is assessed that increases quadratically until a checkpoint is finalized. This leak ensures that problematic validators are forced to exit so that validators that are operating optimally maintain a 2/3 majority and the blockchain’s finality mechanisms function as normal.
Rewards in ETH 2.0 are normally calculated as annualized interest rates and follow an inverse square root function. In layman’s terms this means that as more total ETH is staked, the lower the rewards will be per validator. At current ETH deposit levels, a validator will make ~7% — 7.5% return annualized. There is a long formula that calculates the different rewards for different actions (e.g. attestations vs proposing) and factors in whether the validator is performing duties on time, etc. It looks something like this:
It’s a bit too technical for this conversation and it’s a lot easier to simply use a rewards calculator⁸.
In order for an honest (unslashed) validator to voluntarily exit, it needs to have served for 2,048 epochs — around 9 days. Validators, on the other hand need to wait fo 2⁸ epochs (~27 hours) in order to become withdrawable. This ensures that if a validator has misbehaved there is still a period of time that they can be caught and slashed. The ETH 2.0 protocol ultimately limits the number of validators that can be activated or exit within an epoch. This makes it more difficult for an attacker to quickly ramp up and attack the system.
Solo Staking — You can stake on your own by setting up a validator client (and probably a Beacon Node too) and depositing 32 ETH into the deposit contract. Once a valid transaction has been submitted to this contract, your validator client will now be in the “deposited” state. Your deposit will then be processed over the span of a few hours, before it gets assigned an index number and put into a queue to be activated. Once the validator reaches the front of the queue, it is assigned an activation epoch from where the validator is activated and assigned the responsibilities mentioned above.
Staking Pools / Derivatives — This will be a subject of much literature as the upgrade unfolds. The Ethereum PoS protocol does not provide some of the functionality that PoW or other PoS implementations have — namely liquidity. As such the market has and will continue to step in to make staking more convenient and efficient. This has taken the form of staking pools which allow participants to pool their ETH together and delegate the operational aspects of running validators to the pool. The pools may offer additional services like maintaining a reserve of liquid ETH to satisfy withdrawal demand, or insurance against slashing. One expected feature will be the tokenization of your claim on the staking pool in the form of ERC-20 tokens which can be used in other applications, such as Defi. The pools can be centralized (e.g. Coinbase or Binance ) or decentralized (e.g. RocketPool or Lido) and each will have it’s own Pros and Cons that you should look carefully into before interacting or depositing any tokens. Some argue that this pooling or introduction of staking derivatives lowers the security of PoS and incentivizes centralization in it’s own right, as they separate the staking/slashing aspect from block production aspect (principal-agent problem). However, others argue that derivatives lower both the explicit and the opportunity cost of staking, leading to more participation and more ETH being staked. This is a debate that we can only speculate on at the moment, and it will be interesting to see how it plays out.
The Ethereum 2.0 Serenity Upgrade is schedule to be implemented in phases. Phase 0 has introduced the Beacon Chain and Proof of Stake. Phase 1 will introduce sharding and shard-chains. Phase 1.5 will merge the existing Proof of Work chain with the new Proof of Stake chain, as one of the latter’s shard-chains. Phase 2.0 will bring about the execution engine on the shard-chains allowing for smart contracts to be executed on the shard chains. The Ethereum Virtual Machine (EVM) will be replaced with Ethereum Web Assembly (eWASM), which will allow for faster transaction processing and throughput. The Beacon Chain will serve as the main ETH 2.0 blockchain and administer the validators and the Proof of Stake protocol. Shard-chains will run concurrently and be reconciled with the Beacon Chain in lockstep. A Beacon Chain block and up to 64 shard-chain blocks (1 block for each) are processed every 12-second slot. Every 32 slots constitutes an epoch , which analogize to a cycle within the block validation process. Each validator is allowed to cast a vote, called an attestation, on what the chain heads are for the Beacon and the shard-chains (LMD Ghost Vote), and on a on the current and prior checkpoint blocks (the target and the source , respectively). This vote on checkpoints is the Casper FFG Vote portion of the attestation. When the current or target checkpoint block achieves 2/3s of the votes, ( supermajority ), it is considered justified. If after another epoch passes and it achieves the supermajority vote as a source, it is considered finalized ( finality ). Validators are pseudorandomly selected and shuffled between committees of at least 128 validators, using a pseudo-random number generation process called RANDAO. These randomized committees are partitioned in order to vote on head of blocks, attempt to cross-link shard chains with the beacon chain, and are designed to help thwart malicious activity on chain. Validators earn rewards by attesting to blocks that become finalized, and by proposing blocks (when they are selected as proposers) that become finalized. They can also earn rewards by providing proof that someone has committed a slashable offense. Validators can be penalized as well, by going offline or not attesting (relatively minimal penalty) or more seriously penalized by committing a slashable offense, which include double voting, proposing two blocks in the same epoch, or casting a Casper FFG vote that conflicts with their previous one. You can lose your entire stake for committing a slashable offense. People can be involved by solo staking — putting up 32 ETH and your own validator node, or by committing some amount of ETH to a staking pool. Staking Pools allow you to pool your ETH with other participants to bypass the 32 ETH minimum requirement. The pool handles the operational aspects of staking and may tokenize your stake in the pool to provide you liquidity to use in other applications. All in all, we should be super excited to see the activation of the Serenity upgrade. ETH 2.0 aims to provide an even more scalable decentralized platform for applications and computing and I personally can’t wait to see it happen :)
REFERENCES
[1] Tobias Fan (Jun 25, 2021) Ethereum 2.0 For Dummies — Part 1: Why Upgrade? https://tobyornottoby.medium.com/ethereum-2-0-for-dummies-part-1-why-upgrade-112d8f5b6d88
[2] Cryptopedia (Jun 21, 2021) The 3 Phases of Ethereum 2.0’s Serenity Upgrade https://www.gemini.com/cryptopedia/ethereum-2-0-blockchain-roadmap-proof-of-stake-pos
[3] ethos.dev (May 23, 2020) The Beacon Chain Ethereum 2.0 explainer you need to read first https://ethos.dev/beacon-chain/
[4] Carl Beekhuizen (Feb 12, 2020) Validated, Staking on eth2 : #2 — Two Ghosts in a Trenchcoat https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat/
[5] Chi-Cheng Liang (Jul 12, 2019) Minimum Committee Size Explained https://medium.com/@chihchengliang/minimum-committee-size-explained-67047111fa20
[6] Amanda Shendruk, Quartz (Aug 19, 2020) CloudFlare Uses Lavalamps to Generate a Fundamental Resource: Randomness https://qz.com/1642628/cloudflare-uses-lava-lamps-to-generate-a-crucial-resource/#:~:text=Cloudflare%20uses%20lava%20lamps%20to%20generate%20a%20fundamental%20resource:%20Randomness&text=In%20Cloudflare's%20San%20Francisco%20office,lamps,%20but%20the%20office%20environment.
[7] Nimbus (May 7, 2019) Two Point Oh: Randomness https://our.status.im/two-point-oh-randomness/
[8] Staking Rewards Rewards Calculator https://www.stakingrewards.com/earn/ethereum-2-0
Join Coinmonks Telegram Channel and learn about crypto trading and investing
27