Table of Contents
Researcher
Related Projects
Key Takeaways
The Ethereum network is continuously being upgraded according to its roadmap to improve scalability and decentralization.
Single Slot Finality (SSF) is an upgrade that allows a block to be proposed and finalized simultaneously in a single slot. It is an upgrade that is part of the long-term plans for "The Merge."
1. Introduction
1.1 Ethereum Roadmap
Source: Vitalik Buterin
Ethereum's network is evolving. The roadmap above is the Ethereum network roadmap introduced by Vitalik Buterin at the end of 2021. The roadmap consists of The Merge, Surge, Verge, Purge, and Splurge - a total of 5 parts. These aren't being implemented in a sequential manner; instead, upgrades are taking place in parallel across the different areas. The upgrade we will discuss in this article is the Single Slot Finality (depicted as Single-slot confirmations in the graphic), which is included in the long-term plans for The Merge. However, before we delve into that, let's briefly examine the objectives of the other upgrades:
The Merge - It refers to the transition of the Ethereum network from the previous PoW to the PoS. On September 15, 2022, The Merge was successfully implemented. The merging process is described below, where the Execution Layer of the PoW Ethereum gets some modifications and merges as a part of the Beacon Chain. The final step of the PoS transition is the Shapella upgrade, which allowed the withdrawal of ETH staked on the Beacon Chain, successfully completed on April 12, 2023. In the long run, alongside Single Slot Finality, there are plans for a Secret leader election that hides block proposer information via cryptography and Better signature aggregation, aggregating Ethereum network signatures more efficiently.
Source: Danny Ryan
The Surge - This upgrade relates to Danksharding, enabling rollup networks to store transaction data on the Ethereum network efficiently. In Danksharding, a new data structure, Blob, is introduced. Given the large size of Blobs compared to the current calldata, the PBS (Proposer-Builder Separation) from The Splurge must be introduced first to avoid network centralization issues. Implementing PBS and Danksharding is expected to take a significant amount of time. Hence, EIP-4844 (Proto-Danksharding), which introduces easily implementable components of Danksharding, is currently being actively discussed. With only the introduction of EIP-4844 before Danksharding, scalability improvements for various rollup networks are anticipated.
Source: Vitalik Buterin
The Verge - This upgrade relates to the concept of weak statelessness. Currently, nodes in the Ethereum network need to store information about the entire state of the Ethereum network to verify the validity of blocks. However, as the Ethereum user base grows and more dApps emerge, the size of the total state continuously increases, potentially leading to issues of network centralization. To address this, The Verge plans to replace the current Merkle Patricia Tree with a Verkle Tree. Using the Verkle Tree can significantly reduce the size of witnesses needed to prove the inclusion of a particular state in a block. As a result, nodes only need to store the state affected by the block and witness information to prove the block, allowing nodes with lower hardware specifications to participate in verifying Ethereum blocks. This is expected to enhance the network's decentralization.
Source: Vitalik Buterin
The Purge - Focuses on alleviating the burdens of past data in the Ethereum network. As time passes, the volume of historical data stored on the Ethereum network continues to grow. This can become a burden for nodes joining in the future, posing a risk for network centralization. To address this, The Purge introduces History Expiration via EIP-4444, allowing data older than one year to be pruned. Beyond this, The Purge also includes a State Expiry upgrade, allowing for the removal of older states from the tree structure that haven't been accessed for a certain duration.
The Splurge - It consists of upgrades not specifically included in the previous four. It includes the much-discussed Account Abstraction (AA), but the most noteworthy upgrade is PBS related to the decentralization of MEV. PBS divides the current validator into a block proposer and block builder, embedding the MEV-Boost mechanism into the Ethereum protocol. Currently, MEV profits are quite decentralized through MEV-Boost. The introduction of PBS is expected to resolve censorship issues, further paving the way for the introduction of Danksharding.
2. Single Slot Finality
Single Slot Finality (SSF) refers to an upgrade where the proposal and finalization of a block can occur simultaneously within a single slot. This upgrade is part of the long-term plan of "The Merge". For reference, a slot is a timeframe in which one block can be proposed, equivalent to 12 seconds. Furthermore, one epoch consists of 32 slots, amounting to a total of 6.4 minutes.
2.1 Finality
Currently, it takes about 15 minutes (64-95 slots) for an Ethereum block to be finalized. When a block is finalized, it essentially means that unless willing to risk a massive token slashing due to an attack at the network level, the block can never be changed or deleted. In other words, it's like awarding a medal to the block, stating, "This block is finalized, and we can all trust it safely."
However, the time taken for an Ethereum block to be finalized is too slow. Until a block is finalized, there is a chance it might change. Hence, during this period, it's risky to consider transactions as 100% confirmed. This delay poses a significant inconvenience for services where block finality is critical, such as bridges or centralized exchanges. Some centralized exchanges even find waiting 15 minutes for a block to achieve finality too slow. As a result, just like during the PoW Ethereum days, they consider around 12-20 confirmations (roughly 2-4 minutes) as finalized and proceed with deposits and withdrawals based on this timeframe.
Interestingly, this 15-minute window achieves equilibrium. It offers individual validators ample opportunity to engage in the consensus process, all while maintaining a reasonable service experience. So, why is finality for Ethereum blocks granted so late? This is because Ethereum's consensus algorithm uses the LMD-GHOST and Casper FFG methods. It has a nature that compromises between chain-based consensus and traditional BFT consensus methods. There are several technical terms mentioned here, so let's examine them one by one.
2.2 Two Types of Consensus Algorithms
According to the FLP Impossibility theorem, which states that it's impossible to satisfy both Safety and Liveness in an asynchronous network perfectly, the consensus algorithms of existing blockchains can be broadly divided into two categories:
Chain-based consensus - It prioritizes Liveness over Safety. As the number of messages exchanged between nodes for consensus is few, the minimum hardware specifications required to participate in the network are low. This means there's an advantage in that many nodes can participate in the consensus process. However, a drawback is that the concept of block finality doesn't exist, leading to frequent forks. The Bitcoin network is a prime example. Conventionally, a block in the Bitcoin network is probabilistically assumed to be finalized after 6 confirmations.
Traditional BFT consensus - It prioritizes Safety over Liveness. Due to the large number of messages exchanged between nodes for consensus, the minimum hardware specifications required to participate in the network are high. This means there's a drawback in that the number of nodes participating in the consensus process is very limited. However, the advantage is that block finality is determined through the exchanged messages, and finality can be granted to a block before the next block is created. The Tendermint BFT consensus algorithm is a notable example, and blocks on app-chains based on the Tendermint core are granted finality shortly after creation.
2.3 Ethereum's Current Position
After The Merge, transitioning to the PoS algorithm, the Ethereum network uses the LMD-GHOST and Casper FFG consensus algorithms, characterizing a midpoint between the abovementioned types. The Ethereum network primarily uses a chain-based consensus based on LMD-GHOST, similar to the Bitcoin network. However, it resembles traditional BFT consensus in that it grants block finality by sharing thousands of messages (precisely, attestations) per slot among nodes. Essentially, one could say that Ethereum has struck a balance by capturing the best of both consensus methods.
So, what exactly is an attestation? LMD-GHOST is a consensus algorithm that determines which chain is canonical when a fork occurs in the network. In contrast, Casper FFG is a consensus algorithm that grants block finality periodically. In both these algorithms, attestations play a vital role. An attestation is the process where validators vote on a block they believe valid.
Source: eth2book
Every epoch, all validators are assigned to one of the 32 slots, with each slot having 64 committees and each committee consisting of 256 validators. This means assuming you are an Ethereum validator, you get one opportunity to make an attestation each epoch. You can verify and, if deemed valid, sign an attestation for the proposed block in your assigned slot. Within a committee, validators make attestation signatures for a block, and a few randomly selected aggregators collect these signatures and pass them on to the block proposer.
If a fork occurs in the Ethereum blockchain, the canonical chain is determined by the block that has received more than 51% of attestations through LMD-GHOST. The Casper FFG algorithm, which grants finality, also provides finality to blocks that have received attestations from more than 2/3 of the validators. This underscores the importance of the attestation process in the Ethereum network, where validators vote for valid blocks.
2.4 Trade-off between Decentralization / Time / Overhead
The current 15-minute time frame in the Ethereum network is a compromise between the two consensus methods. It provides enough time for validators, including individual ones, to attest to a particular block, covering 2/3 of the staked ETH. Might it be possible to grant finality faster than 15 minutes, say in 15 seconds? If the minimum hardware requirements for validators increased, they could process more messages quickly. However, this could undermine decentralization.
Source: Vitalik Buterin
This means a trade-off relationship exists between the network's decentralization, the time it takes for a block to finalize, and the overhead on the network. As we increase the number of validators to enhance decentralization or process the finality of a block faster, the number of messages that the network has to handle increases, hence necessitating higher hardware specifications. This ultimately undermines the decentralization of the network. As can be seen in the diagram, a chain-based consensus emphasizes very high decentralization but does not grant finality to blocks. On the other hand, traditional BFT consensus grants finality quickly but increases network overhead, reducing decentralization.
The ideal system must balance decentralization, time, and overhead. Modern Ethereum has found a compromise by setting the minimum staking amount to 32 ETH to prevent an infinite number of validators and by setting the finality time to 15 minutes, ensuring individual validators can adequately participate in the consensus process.
However, examining the chart, it's evident that today's Ethereum, as indicated by Vitalik, doesn't sit exactly on the 45-degree diagonal line; even though network overhead has increased, its decentralization is rated higher. Despite the clear trade-offs, how is this possible? The answer lies in the BLS signature aggregation. This method efficiently aggregates numerous validators' signatures into a single one. By introducing this efficient signature system, an environment has been established where over 500,000 validators can participate while granting finality, as seen in today's Ethereum network.
2.5 Single Slot Finality (SSF)
15 minutes is still a considerable time for a block to achieve finality. Currently, an Ethereum block requires a minimum of 2 epochs (equivalent to 64 slots) to be finalized. Why can't we grant finality immediately right after a block is proposed in a single slot? This is precisely what the upcoming SSF upgrade in the Ethereum roadmap aims to achieve.
For a block to be proposed and finalized within a single slot, over 2/3 of a tremendous number of validators must provide their attestations for that slot. Currently, validators in the Ethereum network are assigned only to a specific slot within an epoch, allowing for just one attestation, making this scenario impossible. But can we handle and process the numerous attestations from countless validators within the short duration of a single slot (12s)?
Fortunately, this is feasible. Over the past three years, the efficiency of the BLS signature aggregation has significantly increased. Furthermore, much knowledge has been accumulated regarding handling and collecting vast amounts of messages and data on the network level. Consider a scenario with 1,000,000 validators. It takes 500 ns to verify a single signature, meaning verifying 1,000,000 signatures takes only 500 ms. So, while signature verification is not the issue, the real challenge is signature aggregation.
Source: Vitalik Buterin
Today's Ethereum uses committees comprised of 256 validators for each slot, with 64 committees existing per slot. Since signatures are aggregated within a committee and submitted, there isn't a significant issue with signature aggregation. However, if SSF (Single-Slot Finality) is applied, all the signatures of numerous validators within a slot must be collected. To do this, the number of committees could be significantly increased from 64, the number of validators within a committee could be increased from 256, or an additional layer to aggregate signatures could be introduced. These methods could place a heavier load on the P2P network and increase latency. Hence, it's a topic currently under research.
A prominent solution proposed for this is 'Super-committees'. For instance, if we assume there are 500,000 validators in the current Ethereum network, not all of them would perform attestations in a single slot; only a subset would. While this reduces the load on the network, participating in fewer numbers could reduce economic security. Vitalik Buterin reportedly heard opinions during internal Ethereum researcher discussions, suggesting that, on average, network security would be adequate with around 125,000 validators. While this number may vary depending on ETH's price, since Ethereum uses PoS, compromising this level of security might be feasible if SSF is achieved.
Lastly, when looking at SSF, the role of LMD-GHOST must be considered. To recap, LMD-GHOST is the consensus algorithm that determines the canonical chain in the Ethereum network when a fork occurs, and Casper FFG determines the finality of an Ethereum block. However, if SSF is applied, each block would be finalized immediately, making forks unlikely. Does this mean LMD-GHOST is no longer necessary?
In an Ethereum network with SSF, if more than 2/3 of attestations are regularly performed per slot, there's no need for LMD-GHOST. However, if, due to a bug or attack, more than 2/3 of attestations aren't performed, a block won't be finalized, leading to a potential fork where the LMD-GHOST consensus algorithm becomes necessary. In essence, while the current Ethereum network coexists with LMD-GHOST and Casper FFG, a future Ethereum network with SSF would use both consensus algorithms, but not simultaneously - only one would be used depending on the situation.
3. Final Thoughts
To summarize, SSF aims to reduce the time to achieve block finality from over 2 epochs to a single slot. This will bring about tremendous UX improvements at the service layer. With a quicker block finalization time, there will be a dramatic reduction in the time taken for deposits and withdrawals on exchanges and bridges, offering immense convenience to users.
The Ethereum network continues to evolve. From its power-hungry PoW beginnings, it successfully transitioned to the eco-friendly PoS. Now, its focus is on increasing the scalability of rollup networks through EIP-4844 and focusing on data sharding. Several upgrades, like the Verkle trees, await in the future. The SSF discussed in this article is a topic for the distant future after all the aforementioned upgrades have been implemented. Nonetheless, the direction proposed by SSF, of swiftly handling finality despite numerous validators seems to be the ultimate path all blockchains should pursue. Let's continue to watch Ethereum's journey.
Thanks to Kate for designing the graphics for this article.
