The Merge
The Merge
.
launch
(Altair)
No more
PoW
validators
election
participant
selection
specification
slot finality
(SSF)
validator count
safe signatures
Beacon Chain Launch
December 1, 2020
Ethereum's Beacon Chain genesis was triggered after the deposit contract received 524,288 ETH from 16,384 validators.
This specific threshold was initially chosen with an eye towards Ethereum's future transition to execution sharding,
requiring a robust, decentralized group of validators. In retrospect, this large number of validators was not necessary since sharding has been abandoned at the execution layer.
Nevertheless, this threshold successfully ensured a decentralized and secure initiation of the Beacon Chain,
marking a crucial step in Ethereum's shift to a proof of stake consensus mechanism.
This newly formed consensus chain ran mostly independently of Ethereum’s proof of work chain (execution layer) until The Merge.
Resources
Altair Warmup
October 27, 2021
The first upgrade to the Beacon Chain. It introduced several improvements:
- Sync committees to support light clients
- Incentive accounting reforms to reduce spec complexity
- Penalty parameter updates towards their planned maximally punitive values
These upgrades, particularly the latter two, were critical precursors to The Merge. Altair also demonstrated Core Devs ability to collectively ship upgrades to the Beacon Chain.
Resources
The Merge!
September 15, 2022
The Merge was executed through a mechanism called Total Terminal Difficulty (TTD).
This process involved setting a specific TTD value, which represented the cumulative difficulty of all Ethereum blocks mined under the proof of work system.
After this theshold was reached, Ethereum's execution layer merged with the Beacon Chain (consensus layer),
effectively ceasing proof of work activities and shifting the network's consensus mechanism to proof of stake.
Technically, post-Merge Ethereum is still two tightly coupled blockchains.
However the block trees of the execution layer and consensus layer have a 1:1 mapping, meaning that every EL block has one,
and only one CL block which corresponds to it, and vice versa. This 1:1 mapping of EL and CL blocks means that we can think of post-Merge
Ethereum as a single blockchain consisting of two layers.
Resources
Distributed Validators
Extra-Protocol
Distributed Validator Technology allows multiple participants to collaboratively manage the responsibilities of a single validator.
The goal of distributing validator execution across multiple nodes is to improve the resilience of the validator (safety, liveness, or both), compared to running a validator on a single machine.
So long as at least ⅔ of the validators in a DVT setup are functional, the others can go offline, perform poorly, or even be hacked without as severe, or any, penalties being incurred.
More than just increasing a validator's resilience via redundancy, a significant advantage of DVT is that it facilitates staking with less than the standard requirement of 32 ETH by pooling resources from multiple stakeholders.
This makes participation in the validation process more accessible to individuals with smaller amounts of ETH, further democratizing the process and broadening network participation.
DVT did not require changes to mainnet, and similar to liquid staking, is an extra protocol innovation.
Resources
Withdrawals
April 12, 2023
While the Merge joined Ethereum’s execution layer (EL) and consensus layer (CL), it did not include a mechanism for validator withdrawals.
In other words, there was no way for the 32 ETH “locked” in each validator balance on the CL to be withdrawn and credited to an address on Ethereum’s EL.
EIP-4895, included in the Shanghai-Capella hard fork, enabled support for validator withdrawals from the Beacon chain (consensus layer) to the EVM (execution layer) via a new "system-level" operation type.
This EIP completed the three part process of Ethereum's transition to a proof of stake consensus mechanism.
Resources
Secret Leader Election
Ongoing Research
Single Leader Election (SLE) and Secret Single Leader Election (SSLE) are used somewhat interchangeably, and both attempt to resolve the same issue:
a block proposer is known to the network slightly in advance of proposing the block. There is therefore a security vulnerability during this window where the proposer may be targeted by attackers.
Under this new framework, nobody would know the leader in advance except for the leader themselves.
Resources
Per Slot Participant Selection
Ongoing Research
Per Slot Participation Selection: determine the most effective, SSF-compatible approach for selecting validators to attest to slots and aggregate signatures.
By exploring potential optimizations in how validators are selected, the aim is to efficiently manage the significant load of signatures per slot.
This would involve theoretical enhancements to attestation propagation and signature verification mechanisms to support Ethereum’s core principles of decentralization and security, without overburdening the network’s technical capacities. No concrete method has been finalized, and more research and discussion is required.
Resources
SSF Specification
Ongoing Research
A slot is a fixed period of time (12 seconds), during which a new block can be proposed.
A given slot will not necessarily contain a block, as some are missed or otherwise not included.
There are 32 slots per epoch. Therefore, a given epoch is ~ 6.4 minutes. As it exists today, Ethereum finalizes after two epochs (or roughly every 12.8 minutes).
Single slot finality would attempt to drastically lower finality times to a single 12 second slot. There are many benefits to faster finality, but generally speaking, providing
stronger guarantees and settlement clarity is of benefit to some finance applications.
SSF is an area of active research and debate, and it shouldn't be expected in the short term.
Resources
SSF Implementation
Ongoing Research
More validators means processing a greater volume of signatures and data in each slot,
which can slow down the finality process. Ethereum faces the technical challenge of efficiently coordinating numerous validators to achieve SSF (a potential boon for security)
without sacrificing the network's decentralization (a high number of validators). Put another way, SSF would be much easier with small validator count,
but this would lessen one of Ethereum's primary strengths.
The technical advancements of SSF must be balanced with the risks they pose.
For instance, faster finality could amplify the impacts of network partitions
or lead to increased centralization if only the most technically advanced (or economically robust)
nodes can keep up with the speed of block creation and propagation
Resources
SSF!
Ongoing Research
Per Slot Participant Selection, SSF Specification, and SSF Implementation collectively form the foundation for achieving Single Slot Finality.
Per Slot Participant Selection focuses on optimizing validator selection to handle a large volume of signatures efficiently, crucial for maintaining network performance under SSF.
The SSF Specification defines the technical parameters for achieving finality within a single 12-second slot, aiming to provide quicker transaction confirmation and improved security.
SSF Implementation addresses the practical challenges of coordinating a high number of validators without sacrificing decentralization, ensuring that the network can sustain rapid finality across diverse operating conditions.
SSF is an area of active research and debate, and it shouldn't be expected in the short term.
Resources
Ideal Quantum Safe Signatures
Ongoing Research
Ethereum, and other blockchains, face potential security risks from the advancement of quantum computing,
which could theoretically break the cryptography fundamental to their security. To mitigate this looming threat, Ethereum's roadmap includes proactive research and integration of quantum-resistant cryptographic algorithms.
Current initiatives involve exploring and potentially adopting cryptographic methods like lattice-based and STARK-based systems.
Resources
Increase Validator Count
Ongoing Research
From the perspective of decentralization and network health,
increasing the number of validators on the Beacon Chain presents a paradox.
Ideally, more validators mean greater redundancy and decentralization. However, the reality is more complex, as a high number of validators can also lead to state-size bloat,
placing additional strain on each node as they strive to keep track of their peers. As the consensus client software is currently written,
Prysm, Lighthouse, etc., struggle to maintain adequate performance past 2 million validators.
The validator entry churn limit was capped at 8 per-epoch in the Cancun-Deneb hard fork via EIP-7514.
However, as this roadmap item implies, there is ongoing research, and several live proposals being debated, as to how to best expand the validator set.
Solutions like EIP-7251, which would increase the MAX_EFFECTIVE_BALANCE of validators, could allow for some consolidation of the existing validator set, and therefore allow additional 'new' validators to come online.