Circle Research explores “A Fast Confirmation Rule for Ethereum Consensus,” including its assumptions and performance when applied to mainnet activity.
TLDR:
We explore recent research into developing a fast confirmation rule for Ethereum, including its assumptions, intuition, and performance when applied to Ethereum mainnet activity.
- Ethereum currently takes ~2.5 epochs, or ~15 minutes, to finalize blocks, which may be too long for some applications.
- A confirmation rule can help determine how likely a given transaction or block is to be permanently included in a blockchain prior to achieving finality.
- Circle conducted mainnet testing of a proposed fast confirmation rule recently, and saw that blocks were confirmed in ~1 minute and subsequently achieved finality on-chain. The research also indicates that an optimized implementation could confirm blocks even faster.
Background
Blockchain users need to have confidence that their transactions will remain in the chain long-term, especially if there are follow-on off-chain effects.
For Ethereum, blocks are proposed and voted on by validators who stake ETH. As blocks are built upon each other, they go through a gradual finalization process according to the Ethereum consensus protocol. Once a block is finalized by the network, it is extremely unlikely that it would be reverted without catastrophic effects to the Ethereum network.
Users who require maximum Ethereum security may choose to wait for a given block to be finalized by the Ethereum protocol before they're considered confirmed and safe to act upon. On average, it's necessary to wait 2.5 epochs, or ~15 minutes, for a block to be finalized. This is due to the fact that, on average, a transaction may fall towards the middle of an epoch, and it is only considered finalized once the next epoch checkpoint succeeding it is finalized through two successive epochs of voting (reminder: an epoch checkpoint is the block contained in the first slot of that epoch).
However, waiting 15 minutes may be too long for some applications. As a result, some developers may adopt different criteria that balances latency with safety. For instance, a “k-depth” confirmation rule could be used, which may be familiar to those coming from a proof-of-work background. In a k-depth policy, a block is considered confirmed once it is k-blocks deep in the chain.
K-depth rules are easy to reason about and provide a consistent user experience, especially in Ethereum with its fixed rate of block production. However, in proof-of-stake systems, such as today’s Ethereum network, block depth itself does not explicitly mean that the block is hard to reorganize. It is rather the votes, and the staked ETH associated with those votes, that imply a block may be safe. In other words, a given k-depth policy does not necessarily guarantee that a block will always remain within the canonical chain.
For deeper dive into Ethereum consensus, we encourage you to check out these additional resources:
A Fast Confirmation Rule
The confirmation rule in A Fast Confirmation Rule for the Ethereum Consensus Protocol works a bit differently than a k-depth rule.
Rather than considering only depth, the rule counts the votes observed for a given block to determine whether it will stay in the canonical chain under certain assumptions. It incorporates the votes observed into an algorithm to determine, at any given moment, if a given block is confirmed under the parameters the rule is applied with. If certain additional assumptions about the Ethereum network hold, a confirmed block under the rule should eventually be incorporated into the canonical chain. These assumptions, and the intuition behind the rule, are explored further in this post.
To test its performance, we implemented the confirmation rule in a research prototype and applied it over a 6-day period. The results showed that the confirmation rule confirmed blocks relatively quickly and that all confirmed blocks remained in the chain long-term. For instance, assuming an adversary controls at most 30% of the total stake of Ethereum and is willing to have 10% of the total stake slashed, the average confirmation time is 69 seconds. Note that this is likely a pessimistic estimate of its performance, as the prototype is unoptimized and includes several approximations to ease its implementation (discussed below). However, this still compares favorably to k-depth policies where k is 6 blocks or more. And most importantly, all blocks confirmed under the rule remained in the canonical chain, despite experiencing a 2-block reorg.
Lastly, it is important to mention that efforts are underway to change the Ethereum protocol itself so that a block can be finalized in a single slot. While “single-slot finality” would provide dramatically faster finality, significant changes to the Ethereum protocol are required before this could be implemented.
Exploring the rule’s assumptions
The network is synchronous
Usually, when we say "network is synchronous", we mean that messages sent by honest nodes arrive at their receivers by at most ∆ time later.
Is this a reasonable assumption to make? There have been some previous empirical studies about the attestation inclusion delay in Ethereum, as well as measurements for message propagation. Although network synchrony seems a reasonable assumption to make in normal activity for the Ethereum network, a network outage or denial-of-service attack may happen to make the network asynchronous. An interesting area to research would be running several nodes in the Ethereum network (in different positions of the network) and to try and measure any network asynchrony.
The stake controlled by the adversary is bounded
In the paper, the adversarial portion of validator stake is denoted by 𝞫, and it is a key parameter that users can tune as they apply the confirmation rule in different ways (a larger 𝞫 indicates a more conservative application of the rule, and vice-versa).
Given that users relying on Ethereum finality are already assuming a total malicious stake less than ⅓, it is reasonable to assume that across a smaller range of slots within a given epoch or crossing an epoch boundary (i.e. where we might be applying the confirmation rule) that malicious validators are also similarly bounded with high probability. The practicality of this assumption is further discussed in section 3.1 of the paper.
Additionally, in the proof of security in the paper, it is assumed that all honest validators will vote, and therefore non-voting validators are included under the malicious stake. The good news is that the voting rate in Ethereum is high with around 98%+ of validators voting per slot (see the ethresear.ch blog here).
The validator set remains fixed
One of the assumptions originally presented in the paper is that the validator set is unchanged from genesis (i.e. no validator additions or exits). The algorithm is then revisited and modified in Section 5 where this assumption is relaxed.
In practice, validator set changes are bounded by modest “churn limits” for both validator entry and exit at epoch boundaries (you can see realtime data on entry and exit queues here). Since most practical applications of the confirmation rule would focus on the intervening period from the finalized block up until the chain tip, it is reasonable to assume a fixed validator pool for the purposes of the confirmation rule, given the relatively small churn limits and Ethereum’s overall validator population size.
Intuition and Terminology
It’s helpful to develop a rough intuition for how the confirmation rule works, using the terminology from the paper. We won’t go into the why for how the confirmation rule may be safe, as the proofs are lengthy and complex, and better explained in the paper itself. If you are interested in the proof of security, please refer to the references at the end of this blog.
LMD-GHOST safety
For a block, if none of its siblings have any chance of outcompeting it in the LMD-GHOST fork-choice rule, then it is referred to as “one-LMD-GHOST” safe.
Let’s illustrate with a concrete example:
As shown in the picture above, the current slot is 6. We want to check whether block b4 (proposed in slot 4) is one-LMD-GHOST safe.
We first define the following notation:
- W: maximum support for b4 and any potential sibling of b4, which is the weight of all the committee members from slot [parent(b4) + 1] to the current slot, inclusive. In this case, the current slot is slot 6, and slot [parent(b4) + 1] is slot 2 (since b4 was built on b1). Let’s suppose the stake of committee members from one slot is n, so we have W = 5n.
- S: support for b4, which is the stake that voted for b4.
- H: honest support for b4, which is the stake that voted for b4 and is held by honest validators. A key observation is that honest validators, by virtue of being honest, will not equivocate on their LMD-GHOST votes.
- Wp: proposer boost weight. This is an added LMD “boost” given to blocks proposed “earlier” in a slot. In Ethereum, it is currently 40% of the total weight of the committees from one slot.
When determining whether b4 has enough support so that no siblings of it can outcompete it in the LMD-GHOST fork-choice rule, we first want to determine the support for b4 that will not change (i.e. switched to a sibling block).
Then, we want to determine the maximum possible support gained by its siblings: maximum support for b4 and its siblings, subtracted by the honest votes for b4, plus the proposer boost weight (W - H + Wp). The maximum support for b4 and its siblings includes committee members from slot [parent(b4) + 1] to the current slot, even though b4 itself cannot receive votes from committee members in slot 2 and 3.
If:
H > W - H + Wp (1)
then b4 will definitely beat any potential siblings in the current slot. Simplifying equation (1) by isolating H, we have:
H > (W + Wp) / 2 (2).
However, in practice, we cannot identify honest votes and aggregate them as we only see votes from both honest and dishonest validators (S). This is where the estimation for dishonest validators kicks in, as we believe that the dishonest validators comprise at most 𝞫 of the total stake. Therefore, the votes from the dishonest validators in S are at most 𝞫W (reminder: W is the maximum support for b4 and its siblings). We have:
H > S - 𝞫W (3).
By (3), we know that if
S - 𝞫W > (W + Wp) / 2 (4),
then we can definitely know that H > (W + Wp) / 2, which means b4 will win.
By simplifying (4) we get:
S / W > ½ * (1 + Wp / W) + 𝞫 (5),
which is the equation for checking whether a block is one-LMD-GHOST safe in the paper.
We have built the intuition for the one-LMD-GHOST safety rule so far. When (5) is satisfied, we know that the block will beat all its siblings in the current slot. Given the synchrony assumption, by the end of a slot, any honest validator receives all the votes sent by any other honest validator. This means that (2) will be satisfied in the view of any honest validator and, therefore, all of them will vote for b4 or a descendant of b4 in the future slot. Therefore, b4 will always be favored by the LMD-GHOST fork-choice rule, now and in the future.
Extending one-LMD-GHOST safety further, we get the idea of “LMD-safety”: if a block is one-LMD-GHOST safe, and all of its ancestors are one-LMD-GHOST safe, then it is considered LMD-safe.
FFG Safety
A block that is LMD-safe means that it will always be favored by the LMD fork-choice rule within its epoch. As the epoch progresses, all the honest validators in the remaining slots will cast LMD votes favoring the block or its descendents, as well as cast FFG votes for the checkpoint of the epoch which is the ancestor of the block.
However, the LMD-confirmed block b4 may be filtered out if the checkpoint of the epoch containing b4 is not justified in the next epoch. Therefore, after confirming that a block is LMD-safe, we also need to check the FFG safety of the block to make sure the checkpoint will eventually be justified.
Let’s define some notation:
- Wt is the total weight of all validators.
- Wf is the weight of validators yet to vote in the epoch.
- Sffg is the weight of FFG votes casted for the checkpoint of b4.
Similar to the LMD-safety rule above, since we cannot easily identify honest (non-equivocating) validators, we need to come up with a threshold that allows us to determine FFG-safety based on total observed votes and our parameters 𝞫 (fraction of malicious stake) and 𝞪 (fraction of total stake Wt an adversary is willing to have slashed).
Since (Wt-Wf) corresponds to the total weight of validators who have voted, we can say that at most 𝞫(Wt-Wf) of the vote supporting checkpoint of b4 was cast by the adversary.
Therefore, the FFG support for the checkpoint that will remain unchanged is at least Sffg - min(𝞪Wt, 𝞫(Wt-Wf)). Since the honest validators will vote for the checkpoint of b4, this checkpoint will get at least (1-𝞫) Wf FFG support in the remaining slots of the epoch. Therefore, the rule for FFG-safety is:
Sffg - min(𝞪Wt, 𝞫(Wt-Wf)) + (1-𝞫) Wf > ⅔ Wt.
Applying the Confirmation Rule to Mainnet
We measured the performance of the confirmation rule against Ethereum mainnet over a period of 6 days, using a sample reference implementation, based on these code snippets and the draft Ethereum consensus specs.
To apply the rule, we first collected fork-choice data using Ethereum Beacon Client APIs approximately every 10 seconds. It was necessary to poll and persist data, as there is limited historical data on reorged blocks available for one-off querying through standard consensus client APIs.
There are two specific approximations made in the implementation worth highlighting:
Approximation 1
All the validators are assumed to have exactly 32 ETH as their effective balances. To determine whether this was a reasonable assumption, we analyzed the effective balance of the validators (data queried at slot 9745793). 279 out of 1059607 validators have an effective balance != 32 ETH, and their effective balances range from 28 ETH to 31 ETH. Therefore, this assumption seems reasonable.
Approximation 2
The LMD weight of the checkpoint is assumed to be a proxy for the FFG support for the checkpoint in the current epoch.
In Ethereum, the LMD-GHOST votes and FFG votes are bundled together. There is a constraint that enforces that the FFG checkpoint validators vote for is an ancestor of the LMD-GHOST head they voted for. Therefore, whenever the descendant of the checkpoint receives an LMD-GHOST vote in the current epoch, the checkpoint will also receive the corresponding FFG support. That's why the LMD-GHOST weight of the checkpoint in the current epoch is also the FFG support they receive.
Results
We collected the fork-choice data for over 6 days. The average confirmation times, for various 𝞪 (portion of stake adversary is willing to have slashed) and 𝞫 (maximum portion of stake adversary controls) parameters:
This same data in box plot format:
All blocks confirmed under the rule were eventually finalized in the canonical chain. During this ~6 day period, 56 blocks were detected as re-orged, including a 2-block re-org. Importantly, none of these re-orged blocks were confirmed under the rule, no matter how the adversarial thresholds were tuned.
Polling for data with higher frequency than 10s would also likely reduce the confirmation times recorded, as the votes would be received faster. Even better would be executing the confirmation rule right at the beginning of each slot as per the theoretical algorithm.
The conclusion from this limited data collection period is that the confirmation rule confirmed blocks quickly and that all confirmed blocks remained in the chain long-term. It is important to emphasize though that the confirmation rule is not a substitute for Ethereum finality. Additionally, while looking at historical data is a helpful reference, actually utilizing a fast confirmation rule for sensitive applications may create new and surprising incentives for malicious validators that would not be observed in the historical analysis.
Looking Ahead
We hope that this synopsis was helpful, and invite you to share any feedback on the proof-of-concept implementation on GitHub.
While exploring this topic, a few questions emerged that would make for interesting further research, such as:
- Can we devise a network synchrony indicator that provides us with some probabilistic estimate of the likelihood of the network being synchronous?
- What would performance look like if the confirmation rule were directly integrated into Ethereum clients and executed at the beginning of each slot, calculating FFG support as described in the paper?
- What’s the best approach to estimating or identifying potentially adversarial stake?
- What new use cases does the confirmation rule enable?
While single-slot finality may eventually be supported in Ethereum, research like A Fast Confirmation Rule for the Ethereum Consensus Protocol is helpful to bridge the gap and provide more tools that balance safety with specific application requirements.
Acknowledgements
First and foremost, we’d like to thank Lulu Zhou, summer 2024 intern and Ph.D. candidate at Yale, for leading this exploration during her internship.
We’d additionally like to thank the following people for their advice, knowledge, and conversations while researching this domain, including:
- Roberto Saltini (co-author of the paper)
- Francesco D’Amato (co-author of the paper)
- Luca Zanolini (co-author of the paper)
- Chenyi Zhang (co-author of the paper)
- Thanh-hai Tran
- Joachim Neu
- Lioba Heimbach
