How does the NEW Ethereum work?

Written On

January 4, 2023

When Ethereum swapped out Proof-of-Work consensus with Proof-of-Stake, we called it "the Merge." Ever since, Ethereum hasn't needed miners to execute Proof-of-Work and add new blocks to the blockchain. Instead, it uses "validators," which are people who stake ETH to gain the right to validate and append new blocks to the blockchain.

By replacing Proof-of-Work with Proof-of-Stake, Ethereum has become more energy-efficient. In fact, Proof-of-Stake reduced Ethereum's energy consumption by 99.95%. This implies a global energy cut of 0.2%. That's huge!

The Merge was Vitalik's vision for Ethereum from the beginning. He's written about it for years, sharing his ideas about what the transition to Proof-of-Stake would look like. Finally, after six years of research, experimentation, and persistence, the Merge happened.

What's truly amazing is that it happened without any users noticing the shift. To explain how this was possible, we need to start from the top…

We can think of a blockchain as having three layers: networking, consensus, and application.

In this case, the networking and consensus layers were upgraded, but the application layer was left untouched. That made it possible for transactions, smart contracts, and applications to continue working just as they always had — meanwhile, Ethereum's entire backend engine was being changed.

The popular analogy for this is swapping a plane's engine in mid-air.

Remarkably, Ethereum's core devs were able to pull this off. Swapping Proof-of-Work to Proof-of-Stake without halting the network was a massive technical feat.

But what's Proof-of-Stake in the first place? That's what we'll explore in the rest of the blog post, along with how the Merge was architected and executed and what long-term impacts it'll have on Ethereum.

Here's an overview of what we'll cover:

Bonus: Misconceptions about the Merge.

Buckle up. It's going to be a long ride.

How Does Proof-of-Stake Work?

Proof-of-Stake is a “consensus mechanism”; that is, an algorithm that's used when a distributed set of nodes want to agree on something. In the case of blockchains, a consensus algorithm is used by the decentralized nodes to agree on the next valid block of transactions that will be appended to the blockchain.

For a more in-depth explanation of consensus algorithms, you can brush up by reading my blog post — the rest of this section assumes you have a basic understanding of consensus algorithms and how they’re used.

While Proof-of-Work and Proof-of-Stake are often called "consensus algorithms," this is technically inaccurate. They're actually Sybil resistance mechanisms, which are an important part of consensus algorithms but not the whole thing. Another very important part is the fork-choice rule, which we’ll touch on later.

Sybil resistance is how a consensus algorithm ensures that a malicious user cannot create multiple accounts and subvert the network with fraudulent votes, known as a Sybil attack. Proof-of-Work uses compute power as a Sybil resistance mechanism.

In other words, you need hardware to solve the Proof-of-Work hash, so each "vote" is backed by hardware units. Proof-of-Stake, on the other hand, uses money as a Sybil resistance mechanism. So, in this case, each vote is backed by money.

Fork-choice rule is how a consensus algorithm chooses the "correct" chain.

Bitcoin uses the "longest chain" rule, which means that whichever blockchain is the longest will be the one the rest of the nodes accept as the valid chain. The longest chain is determined by the cumulative Proof-of-Work difficulty on that chain.

With the transition to Proof-of-Stake, Ethereum now looks at the “weight” of the chain, which is determined by the accumulated sum of validator votes.

In addition to Sybil resistance and the fork-choice rule, the Ethereum consensus algorithm also needs to define how validators get rewarded and punished and which blocks to accept and reject.

With Proof-of-Work, the rewards are the block rewards resulting from new coins being generated in each block. The penalties are the compute power that nodes expend for solving a proof-of-work puzzle incorrectly. If a node doesn't solve for the hash, it loses the money it spent in computing that hash.

With Proof-of-Stake, validators "vote" for what they believe the next valid block will be. But votes are free to make (unlike in Proof-of-Work), so if a validator is wrong, there need to be explicit penalties. This is what makes Proof-of-Stake more complicated — its penalties have to be explicitly defined in the algorithm using game theory.

As you can imagine, this is challenging to do right.

"Gasper" is the name of the algorithm which does all this. It defines how validator incentives work, how new blocks are added to the chain, and how to decide on the canonical chain.

Here's what you need to know about Gasper.

How Does Gasper Work?

Gasper creates a mechanism for all the nodes in the Ethereum network to agree on a block of transactions to append to the blockchain next. The “nodes” in this case are called “validators,” and the way these validators decide on the next block is by casting votes, which are called “attestations.”

1. Validators and Attestations

"Validators" are the users that are responsible for voting on which block to add next. Anyone can become a validator by depositing 32 ETH into the "deposit contract" (which is a special contract designated to collect and track validators) and then running two separate pieces of software: an execution client and a consensus client.

After depositing their ETH into the deposit contract, the user joins an "activation queue" where they are basically in line to become a validator.

This is done to limit the rate of new validators entering the network at any one time. The goal of rate-limiting entry and exit is two-fold:

The communication overhead of validators casting their votes is very high, and there's a limit to how many validators the protocol can handle while ensuring votes are propagated on time.
To prevent a large number of malicious validators from performing some malicious action and then leaving the network to escape penalties.

Once a validator is activated, the validator's responsibilities begin.

Every consensus algorithm needs a sense of time to order events in the network, such as votes. For Gasper, the algorithm divides time into "slots" and "epochs." Slots are 12 seconds long, and each epoch consists of 32 slots (thus 6.4 minutes).

Note: Although not used as much, a period of 2048 epochs (~9.1 days) is called an eek ("Ethereum week"). Operations that take a long time can be measured in eeks.

For every slot, one validator is randomly selected to be a "block proposer." The block proposer validator is responsible for constructing a new block out of pending transactions. It then sends the block out to other validators in the network, which vote on whether that block is valid.

Not every validator votes for every block, though. Instead, for each epoch, a validator is assigned to a "committee." Each committee is randomly assigned one slot where they need to attest to determine whether the proposed block is valid.

Committees are spread among the 32 slots in an epoch, which means 1/32 of the total validator set attests to the validity of each slot or block, with the maximum allowed validators per committee being 2048. In other words, each validator only attests one block per epoch for the slot their committee was assigned to.

‍Note that a small set of validators are also randomly chosen to join sync committees, which are different from the committees mentioned above. Being in a sync committee requires validators to help light clients sync up and determine the head of the chain, which they earn additional rewards for. However, as a validator, you are only part of a sync committee once every ~22 months, so it’s not a responsibility carried on a daily basis.

Validators don't only attest to the current head block. They also attest to two others called "checkpoint" blocks. Every epoch has one checkpoint block that identifies the latest block at the start of that epoch.

Validators attest to their view of two checkpoints every epoch: the "source" and "target" blocks.

In addition to the head, source, and target blocks, validators also include the following information in their attestation:

aggregation_bits: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the data (i.e., whether they are active and agree with the block proposer)
data: details relating to the attestation (defined below)
signature: a BLS signature that aggregates the signatures of individual validators

The data contains the following information:

slot: the slot number that the attestation refers to
index: the committee # that the validator belongs to in a given slot
beacon_block_root: root hash of the block the validator sees at the head of the chain
source: what the validators see as the most recent justified block
target: what the validators see as the first block in the current epoch

Once the data is built, the validator can flip the bit in aggregation_bits corresponding to their own validator index from 0 to 1 to show that they participated in the vote.

Finally, the validator signs the attestation using a private key and broadcasts it to the network.

But wouldn’t passing attestation data created by every validator to every other validator in the network create a lot of overhead? Yes. That’s why, instead of having every validator listen to every other validator, attestations from individual validators are aggregated within "subnets" before they’re broadcasted.

If you divide a network into smaller, individual networks, those networks become subnets. It’s just a network in a network. Subnets make communication much more efficient by collecting and shortening the route that data has to travel to get to its destination.

Remember when we learned that validators are divided into committees? Each of those committees is further divided into 64 subnets. This lets aggregation happen.

In each epoch, a validator in each subnet is selected to be the aggregator. The aggregator collects all the attestations that have equivalent data to its own. The sender of each matching attestation is recorded in the aggregation_bits. That means a single signature is formed by combining the signatures of all validators that agree with the aggregator's data. The aggregator then broadcasts the aggregate attestations to the broader network.

When a validator is selected to be a block proposer, they package aggregate attestations from the subnets up to the latest slot in the new block.

So, in summary, the responsibilities of a validator include the following:

Attesting on a block (once per epoch)
Aggregating attestations from validators in the same committee (occasionally when selected to be an aggregator)
Creating blocks when selected (infrequently when selected to be a validator)

As a result of these attestations, the blockchain comes to a consensus.

2. Finality

A quick recap: validators vote on blocks that a block proposer creates — if they believe it's a valid block. But at what point do we determine that a block should be included in the chain?

This is what we mean when we talk about "finality." If a block reaches "finality," it cannot be reverted unless there has been a critical consensus failure.

In Bitcoin, we know a block is "final" by waiting for six confirmations. In other words, if six blocks get built on top of the current block, we assume the current block is finalized. The probability of a block being reorged after six confirmations is so small that it’s statistically negligible.

In Gasper, we determine a finalized block (or "finality") differently. Rather than using six confirmations, we use the following logic:

If ⅔ of the total staked ether votes in favor of that block, then it becomes "justified." Justified blocks are unlikely to be reverted, but they can be under certain conditions.
When another block is justified on top of a justified block, it's upgraded to "finalized." Finalizing a block is a commitment to include the block in the canonical chain. It can't be reverted unless an attacker destroys millions of ether.

Blocks do not reach the "justified" and "finalized" states in every slot. Instead, they happen to the first block in every epoch, which is called a "checkpoint" block.

When a checkpoint block gets upgraded to justified, it must have a link to the previous checkpoint. That is, two-thirds of the total staked ether must vote that checkpoint B is the correct descendant of checkpoint A. As a result, the previous checkpoint block becomes finalized, and the more recent block is justified.

Therefore, an attacker cannot create an alternative finalized chain without:

Owning or manipulating ⅔ of the total staked ether (because ⅔ of total ether is required to finalize a chain)
Destroying at least ⅓ of the total staked ether (because if ⅔ of total ether was used to finalize two different chains, that means ⅓ of the ether voted maliciously, which would be slashed)

Now that you understand how validator votes help determine which blocks reach finality, we can move on to the fork-choice rule.

3. Fork-choice rule

Since nodes communicate in a decentralized manner, some nodes will hear from different blocks at different times. As a result, different nodes will build atop different blocks. This creates a "fork."

When forks arise, it's the validator's job to choose the "right" fork. This is called the "fork-choice" rule.

In Bitcoin, the right fork is whichever one has the most hash power.

In Gasper, the fork-choice rule is called "LMD-GHOST," which stands for "latest message-driven greedy heaviest observed sub-tree." This means we select the fork with the greatest accumulated weight of attestations to be the canonical one.

So far, we understand how blocks are voted on, how they become "finalized," and how validators know which fork to build on top of. This gets us a blockchain where a decentralized set of actors can create and agree on what block to add to the blockchain next.

But the big issue with Proof-of-Stake consensus mechanisms is that they're susceptible to "long-range attacks" — that is, to a group of attackers can build a fork from genesis, hide it from users for a while, and then suddenly publish it. This could lead to two different chains with "finalized" blocks and end users wouldn’t know which is the correct chain.

This wouldn’t be possible in the Proof-of-Work protocol because it would require an insurmountable amount of hash power to generate all of the previous blocks and outpace the main chain. But in Proof-of-Stake, there's no such thing as hash power since votes are just digital representations of data, so it's entirely possible for a subset of validators to create a new blockchain that looks and acts like the main chain and deceive others into believing in this alternative blockchain.

How does Ethereum prevent this? Enter: "Weak subjectivity."

4. Weak Subjectivity

There are certain checkpoints where every node in every network agrees that a block (and each that came before it) belongs in the canonical chain. This is called a "weak subjectivity checkpoint." If a node sees a block that conflicts with a weak subjectivity checkpoint, then it rejects that block. The latest weak subjectivity checkpoint is like a new genesis block for the entire network.

Recall that in any blockchain, the genesis block is typically the first block that everyone builds future blocks on top of. Similarly, weak subjectivity checkpoints are like genesis blocks that everyone agrees belongs to the canonical chain — as such, everyone builds on top of that weak subjectivity point.

New nodes that are trying to sync to the canonical head of the Beacon chain must use the latest weak subjectivity checkpoint as the starting point of their sync.

This is where the major criticism of weak subjectivity comes in: that nodes just have to trust that they're hearing about the latest weak subjectivity checkpoint from trusted sources (e.g., block explorers or other nodes). For those interested, Vitalik goes into his rationale for why he’s okay with this in this post.

5. Rewards and Penalties

The final piece of the puzzle is rewards and penalties. If you made it this far, then take a break and come back to this section. When you’re ready, let’s go:

Since the consensus mechanism is employed in a decentralized setting, we can't trust that the nodes (i.e., validators) will perform their duties honestly. So, we introduce incentives to reward good behavior and punish bad behavior. As a result, the only way the network can be subverted is if a majority of the nodes waste millions of ether trying to perform malicious activity.

One great feature of Proof-of-Work is its simplicity. Miners earn block rewards if they find the winning hash, and they also receive transaction fees for the transactions included in their winning block. The block rewards come from newly created coins, and transaction fees come from fees a user pays for using the network. There are no explicit in-protocol penalties or punishments.

Now that Ethereum transitioned to Proof-of-Stake, the economics are much more complex. This is because the penalties have to be integrated into the protocol, unlike Proof-of-Work, where the penalty is wasted energy spent by miners.

Before we understand how rewards and penalties work in Gasper, we should clarify how the protocol defines validator "balances."

The Beacon chain maintains two separate records of each validator's balance:

Actual balance: This is the actual balance of each validator. This includes the deposit they made to the deposit contract, plus rewards they earned for participating in the protocol, minus penalties for inactivity. The actual balance starts at 32 ETH, but it changes frequently based on rewards and penalties incurred by the validator.
Effective balance: This is a number derived from the actual balance, but it's designed to only change once per epoch and is denominated in whole ether (no decimals), which makes it more efficient while calculating rewards within an epoch. It's also capped at 32 ETH, so a validator's actual balance could be 100 ETH, but his rewards and penalties are a function of his effective balance, which is capped at 32 ETH.

Effective balance is also used to determine the probability of being selected to propose blocks or participate in sync committees. The higher your effective balance, the more likely you are to be selected to propose blocks or participate in sync committees (and hence, earn additional rewards).

The actual calculation is complex and out of scope for this post, but you can read about it here.

Rewards

Rewards are straightforward. Validators get rewarded in ether when they:

Now that we understand what a validator is rewarded for, let's see how their rewards are calculated.

The amount that a validator receives is based on a parameter called "base reward" — this parameter comes from the average reward a validator receives per epoch under optimal conditions. The function to calculate the base reward is:

Base reward factor is 64
Base rewards per epoch is 4
sum(active balance) is the total staked ether across all active validators

So, the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. In other words, as more validators enter the network, more rewards are issued at lower values per validator.

Moreover, validators with an effective balance below 32 ETH (due to penalties for going offline or being slashed for malicious behavior) will have their rewards scaled downward versus validators with a max effective balance of 32 ETH.

These are the five major components used to calculate validator rewards:

In the table above, you can also see that each component has a respective weight.

The final reward is calculated by multiplying the base reward by the sum of the weights applicable to that validator and then dividing by 64.

Let's take a closer look at what these components mean.

Source, Target, & Head Vote Rewards

Recall that an attestation contains three votes (source, target, head). Each vote is eligible for a reward. Validators only receive rewards for "correct" attestations — meaning their votes agree with the current block proposer. Moreover, there is an additional weight based on how quickly a validator makes attestations after a block has been proposed, where the base reward gets divided by the “inclusion delay.”

‍

For example, if the validator makes the attestation within one slot of the block being proposed, the attestor receives base reward * 1/1. If the attestation arrives in the next slot, the attestor receives base reward * ½, and so on.

It's important to note that attestation rewards are scaled in proportion to participation. So, for each source, target, or head vote, the validator's reward is scaled by the proportion of the total stake that made the same vote. This is done to incentivize one validator to help other validators by forwarding gossip messages and aggregating votes.

Block Proposer Rewards

The fourth component is the block proposer reward. Block proposers receive the proposer's portion of the reward, which is (8 / 64) * Base reward, for each valid attestation that they include in the block, as well as for including the sync committee's outputs in the block. That means as more validators attest to the block, more rewards are given to the block proposer.

Or, as Vitalik put it:

‍"The proposer reward for a duty is the attester reward for that duty, multiplied by the proposer reward as a fraction of everything but the proposer reward."

In other words, the block proposer gets rewards for including the source, target, head, and sync committee votes in the block, just like a validator gets rewards for making a source, target, head, and sync committee vote for a block. Except the reward for including a vote is a fraction of the reward for making the vote. For example, a validator would get (base reward * (14 / 64)) for making a source vote, while a proposer would get (base reward * (14 / 64)) * (8 / (64 - 8)). This means the proposer gets 1/7th of what the attestor gets for making the vote.

Sync Committee Rewards

The fifth component is the sync committee reward. Once every 256 epochs (27.3 hours), 512 validators are selected to participate in a sync committee. To put that in perspective, if we assume that there are a total of 300,000 validators, we can expect a validator to be chosen every 22 months.

When a validator is selected for this duty, the rewards for performing it are very large. A detailed breakdown of sync committee rewards are out of scope for this post but definitely check out the eth2book if you are interested in learning more.

Here's a great visual that breaks down the rewards for the various duties we described above:

Penalties

But that's enough reward talk. How do we slap wrists to dissuade irresponsible, or worse, malicious validator activity? This is where penalties and slashing come in.

As we discussed, a validator's responsibilities are to make attestations, propose blocks, and participate in sync committees.

Attestation Penalties

Validators are penalized for missing, late, or incorrect attestations. The math is easy here; their penalty is the same as the reward would have been if they participated.

But what happens if most validators don't participate in making attestations? If the Beacon chain has gone more than four epochs without finalizing, then it enters an "inactivity leak" mode. Recall that we need ⅔ of validators to finalize blocks, so if too many validators are absent, then we can't finalize blocks.

It becomes an emergency, and the inactivity leak is instantiated to fix it. How? By removing all rewards for active attestors and penalizing inactive validators. The penalties for being inactive increase quadratically over time. The idea is that this would gradually reduce the stake that inactive validators have in the network until they control less than ⅓ of the total stake. This allows remaining active validators to finalize the chain.

The ultimate aim of the inactivity leak is to recover finality.

Proposer penalties

Block proposers don't have explicit penalties. If a block proposer fails to propose a block, we just don't have a block in that slot, and we move on to the next slot.

Sync committee penalties

Sync committee validators are rewarded in each slot they perform their duty. If they sign the wrong head or don't participate, they're penalized the same amount as they would have been rewarded if they were active and correct.

Before we wrap up the penalty section, we should make two things clear. First, all penalties are subtracted from a validator's balances on the Beacon chain and effectively burned, reducing the net issuance of ether. Second, penalties don't scale with participation as rewards do.

Slashing

Slashing is a special kind of penalty that deserves its own section. If a validator engages in malicious behavior, they're heavily penalized through slashing — that is, by forcing them to leave the network and dealing out a steep penalty.

There are three ways a validator can be slashed:

Being a proposer and signing two different beacon blocks for the same slot
Being an attester and signing an attestation that "surrounds" another one
Being an attester and signing two different attestations having the same target

The validator needs to be caught in order for the slashing to be triggered. The whistleblower would need to create a special message and propagate it to the network, and the proposer would need to include it in the a block.

If the accusation is correct, then the proposer and the whistleblower are entitled to a reward. If a block proposer includes evidence that results in a slashing, they will be rewarded with the slashed validator's effective balance divided by 512. The whistleblower rewards are not yet incorporated into the protocol, so they don't receive any reward. At least not yet.

As for the validator, once slashed, it gets an initial penalty, and then it's queued to exit the protocol in ~36 days (8192 epochs). The validator continues to receive attestation penalties until it's due to exit the protocol. It's like a jail cell — they can't participate in attestations, but since they are technically still a validator, they're penalized for not participating. If an inactivity leak happens during these 36 days, they're subject to the penalties as if they were participating in it. It's pretty harsh!

Just like penalties, slashed amounts are effectively burned, reducing the overall net issuance of ether.

Anti-Correlation Penalties

One of the more interesting parts of slashing is the anti-correlation penalty — if many validators perform the same offense at the same time, then they get penalized more for the same offense.

There are two types of anti-correlation penalties:

Inactivity Leak: If you fail to produce an attestation, you normally get a small penalty. But if you fail during an inactivity leak, the penalties become much larger.
Slashing: Halfway through their withdrawal period, a validator gets penalized a second time. This second penalty is based on the total amount of stake slashed during the 18 days before and after the validator was slashed. This scales the punishment such that if the validator was slashed for a one-off event, they would only be lightly punished, but if a lot of validators were slashed during that period, they all lose a lot of money.

This is done for a few reasons:

Setting a penalty that is proportional to the harm caused by an action disincentivizes validators from wanting to collectively subvert the network.
It creates incentives for validators to try to de-correlate their failures from other validators; for example, not running the same client, not being part of the same staking pool, or not running on the same cloud service.

Let's take a look at an example of anti-correlation penalties in practice.

Let's assume there are three staking pools, one with a 5% stake, one with a 10% stake, and one with a 20% stake. Let's also assume that all have the same reliability (i.e., the same chance of going down in any given time period).

Since the inactivity leak scales based on how many validators go offline, the validator that's part of the pool with a 20% stake would get penalized 4x more than the validators that are part of the pool with a 5% stake and 2x more than the pool with a 10% stake. In other words, validators are incentivized to join the pool with less stake due to anti-correlation penalties rather than jumping on the bandwagon and joining the pool with the most stake.

Validators Can Exit at Anytime

Validators earn rewards until they exit the protocol by either:

Voluntarily choosing to exit
Being forced to exit due to slashing
Having a balance below 16 ETH due to penalties

That said, validators can leave whenever they want. To voluntarily exit, all they have to do is sign a "VoluntaryExit" message included on-chain. The exit queue is processed similarly to the activation queue with a four-epoch delay.

If they exit without being slashed, they can withdraw their ether balance after one day of exiting. But if they were slashed, they would need to wait four eeks.

How Did the Merge Work?

Although the official Merge happened in September 2022, the Merge really began way back in October 2020 when the deposit contract was launched. The deposit contract is the address for the Ethereum staking contract, which marked the first step in making Proof-of-Stake a reality. Users were able to begin depositing ETH in order to participate as validators on the Beacon chain once it was launched.

A couple of months later, in December 2020, the Beacon chain was officially launched, running alongside the mainchain the whole time as it produced and validated empty blocks. So really, the Beacon chain had been up and running for about a year and nine months before the Ethereum mainchain merged with it.

This allowed Ethereum core devs to battle-test the new consensus engine and make various upgrades to prepare for the official Merge. Meanwhile, Ethereum users could continue to use Ethereum as is.

We use the term "difficulty bomb" to refer to a sudden increase in mining difficulty such that it becomes uneconomical to mine new blocks. This increase leads to longer block times, which in turn leads to fewer ETH rewards. Before Ethereum was ready to make Proof-of-Stake live, there were multiple upgrades to the difficulty bomb, the goal being to transition miners to Proof-of-Stake when it was ready.

In fact, the difficulty bomb has always been a part of the Ethereum protocol because they always envisioned a transition to Proof-of-Stake. It just took much longer than originally anticipated for the change to happen. As such, there were multiple upgrades to the protocol that delayed the difficulty bomb from going off until Proof-of-Stake was ready for launch.

There were other upgrades too, such as requiring node operators to update their client software and merging various test networks once they've been tested.

To test the Beacon chain, there were also twenty "shadow forks" that were run. A shadow fork is a fork that uses historical blockchain data (unlike testnets which use test data) to simulate what the shift from Proof-of-Work to Proof-of-Service would look like in a controlled environment. In other words, the goal was to run simulations and account for issues that might arise when the Ethereum mainchain merged with the Beacon chain.

After fixing the bugs, the Merge was officially triggered when the chain reached the pre-specified terminal total difficulty (TTD). Once the chain reached the TTD, no additional proof-of-work blocks were added to the chain from that point on.

What Changed with Ethereum?

The Merge is a significant upgrade to Ethereum. Although users won't notice any differences, plenty has changed "under the hood," where developers and node operators spend their time.

Let's walk through the biggest changes.

1. Testnets

Ethereum 1.0's testnets (such as Rinkeby and Ropsten) were replaced by Goerli and Sepolia. As such, developers who were working with the previous testnets had to switch over to one of the newer ones.

2. Clients

Before the Merge, node operators on mainnet only needed to run one client software (e.g., Geth). This changed in the new Beacon chain — now, node operators have to run two different client software: Execution layer (EL) and Consensus layer (CL).

The Execution Layer Client listens to new transactions and executes them, while the Consensus Layer Client implements the PoS algorithm. While this is more cumbersome for node operators, the positive side is that both types of clients now exist in a variety of programming languages, which means we have more client diversity.

There are four EL client implementations and four CL client implementations (if we ignore ones that have less than 1% of the market share). This is far better than before when Geth was the client that a vast majority of nodes used, which led to the risk of a single point of failure.

Having multiple client implementations makes the network more resilient. And remember, the Beacon chain explicitly incentivizes client diversity via the correlation penalty, as we discussed.

3. Block Field Changes

After the Merge, blocks that were generated in the Proof-of-Work chain will no longer exist. Instead, the contents of those blocks become a component of blocks created on the Beacon chain.

Blocks on the Beacon chain will contain "ExecutionPayloads," which will represent the blocks on the old Proof-of-Work chain in the new Proof-of-Stake chain.

There are also some fields in the old block structure that just aren't relevant in the new chain. Rather than removing them, which would cause disruptions, the irrelevant fields will simply be set to their data structure's zero value.

‍

These are the four fields in question with their associated zero value:

1) Ommers: Since Proof-of-Stake does not produce ommers (i.e. uncle blocks), the list of these in each block’s ommers is now empty.

2) ommersHash: The hash of this list of ommers is now an RLP-encoded hash of an empty list.

3) Difficulty: Not relevant to Proof-of-Stake; will be set to 0

4) Nonce: Not relevant to Proof-of-Stake; will be set to 0

"mixHash" is another field only relevant to mining, but rather than setting it to 0, the field will now contain the Beacon chain's "RANDAO" value (which we will explain in the section below).

4. Opcode changes

As for OPCODE changes, the first is "BLOCKHASH," which was important for application developers who used it as a source of randomness. Since so many smart contracts use it, it won't be removed. Instead, it will now have a weaker randomness value to encourage the adoption of the next change.

The "DIFFICULTY" opcode is also irrelevant in Proof-of-Stake. It'll be renamed "PREVRANDOA." The value of this opcode will be the output of the randomness beacon provided by the Beacon chain, which will make it a much stronger source of randomness than BLOCKHASH. This should encourage application developers to use PREVRANDOA instead of BLOCKHASH.

The value provided by PREVRANDAO will be stored where mixHash was stored in Proof-of-Work blocks, and the "mixHash" field will also be renamed "prevRandao."

To see this in practice, take a look at this diagram.

5. Block Time

Another noteworthy change is the slight reduction in block times from an average of ~13 seconds in Proof-of-Work to 12 seconds in Proof-of-Stake.

As we learned, the slot times are 12 seconds, and each slot produces one block. The only exception is if a block producer is too late or not online to produce a block in that slot, in which case the slot is missed. But this happens less than 1% of the time, so we can assume that block times are 12 seconds.

6. Finalized Blocks & Safe Head

The final noteworthy change is how users know whether a block is confirmed and included in the canonical blockchain or not. In Proof-of-Work, we use the six confirmations rule, in which we wait for six blocks to be built on the current head block before we assume the block is final. This gives us a probabilistic guarantee, but it isn't 100% reliable, and there's still a chance of a reorg happening, though it's unlikely.

In Proof-of-Stake, determining if a block will be included in the canonical chain is done by checking if the block is "finalized" or "justified." As such, in Proof-of-Stake, the Ethereum JSON RPC will return the finalized block under the "finalized" flag and the justified block under the "justified" flag. In contrast, Proof-of-Work had no such thing as a finalized vs. justified block. Instead, it had “confirmed” and “head” blocks.

Long-Term Impact on Ethereum

Now that we've explained the Merge, let's talk about big-picture impacts. Currently, Ethereum's annual inflation is about ~4.62%, which is mostly given to miners for mining. After the Merge, ETH's annual inflation will be reduced by 90% to ~0.49%.

These shifts will put positive pressure on Ether price, which in turn may help increase the security of the network. On the flip side, this reduction in issuance can lead people to hoard ETH. This would not be a great outcome because while it may increase the price, it would harm the utility of the underlying Ethereum platform.

Time will tell what this reduction in the issuance of ETH has on the longer-term success of the Ethereum platform.

Conclusion

Phew! If you made it this far, you're a trooper. If you have any questions about anything you read, or if you have corrections to anything I have written, please share them in the comments. I look forward to hearing from you!

But before you go, let's cover some useful bonus material.

Bonus: Mythbusting Four Merge Misconceptions

While the Merge was an elegant technical feat, this post is a testament to just how complicated it can be to wrap your head around it. This complexity has lent itself to a lot of misconceptions among users. So, before we wrap up, I want to quickly dispel some of the most common ones.

Misconception #1: The Merge will reduce transaction fees

Not quite. The Merge merely changes the consensus mechanism that determines how new blocks get validated and added to the chain. It doesn't increase the network throughput, and hence the transaction fees remain nearly the same.

Misconception #2: The Merge increased transaction speeds substantially

The shift to Proof-of-Stake just made the block times consistent, from 13 - 14 seconds to 12 seconds. This is not a substantial improvement in speed.

Misconception #3: Users can only participate in Proof-of-Stake if they have 32 ETH

Users with less than 32 ETH can still participate in the consensus by joining a staking pool.

Misconception #4: The Merge enabled staking withdrawals

As many of you know, it was possible for users to begin staking on the Beacon chain since it was first launched in 2020. However, people who staked were not allowed to withdraw their ETH until after the Merge. It was assumed that the Merge would allow stakers to finally withdraw, but that's not the case. Staking withdrawal is scheduled for the Shanghai upgrade.

Sources

Story tags:

Bitcoin

Cryptocurrency

Ethereum