The finality gadget

Putting eth2.0 to work…

Alex Stokes
May 14 · 16 min read
Successive spans of proof-of-work blocks finalized by the proof-of-stake consensus

As we get closer to the launch of Ethereum 2.0, you may be wondering about the fate of the existing Ethereum blockchain. A number of ideas aimed at increasing scalability of the existing network in the short-term have been proposed under the umbrella term “Ethereum 1.x.” The goal of these efforts is to ensure continued, smooth operation of the current blockchain to promote the sustainability of the ecosystem at large.

This post introduces one of these initiatives known as the “finality gadget.” The finality gadget leverages the consensus of Phase 0 of Ethereum 2.0 to enhance the security of the existing 1.0 chain; this initiative represents a way the Ethereum community can get value from the 2.0 deployment from day one. After introducing the concept at a high-level, we discuss how it works, how the community benefits and what deployment looks like. We conclude by reflecting on some outstanding risks and open questions.

Introduction

The aim of the finality gadget is to use this process in the beacon chain to finalize Ethereum 1.0 blocks. If we can feed Ethereum 1.0 block data into Casper’s “finality engine”, then we can utilize the enhanced security of the proof-of-stake protocol on the existing proof-of-work network. Greater security opens up several avenues for improvement like reducing the mining subsidy (therefore decreasing supply issuance) and exposing the finalized block data to the EVM leading to more robust user-level applications. Leveraging Phase 0 for the finality gadget means we immediately get tangible benefits for the existing network from the launch of Ethereum 2.0, even though the full, phased deployment of 2.0 is expected to take more time.

The idea to use proof-of-stake consensus to finalize a proof-of-work blockchain has been floating around the ecosystem for some time (e.g. refer to EIP-1011 https://eips.ethereum.org/EIPS/eip-1011 or the Casper FFG publication https://arxiv.org/abs/1710.09437) and there is a nice presentation by Alexey Akhunov (beginning of the slides here: https://drive.google.com/file/d/16KLZKAutK79NxMh8L7B6hpNKuoOaAPZT/view) that goes into some of the recent history of the finality gadget in the context of Ethereum 2.0.

How it works

To build the finality gadget, we need two things: (i) a finality engine and (ii) a way to feed Ethereum 1.0 block data into this engine. It turns out that both tasks are achieved via the normal operation of the beacon chain. The beacon chain uses the Casper protocol for its consensus so any data included on-chain will be finalized in the course of normal activity. The second task is a little trickier as it implies that the beacon chain needs to be a light client of the Ethereum 1.0 chain. Luckily, Ethereum 2.0 will be bootstrapped from the Ethereum mainnet and by this process of bootstrapping we end up with Ethereum 1.0 block hashes included in the Ethereum 2.0 beacon chain.

A light client tracking deposits

A validator becomes active on Ethereum 2.0 after inclusion of a valid deposit from the 1.0 chain and a queuing period.

In order to determine the validity of these deposit proofs, the beacon chain has to keep a record of the current state of the deposit smart contract on the Ethereum 1.0 chain. The relevant state at the time of writing is (i) the root of a Merkle tree of all deposits to date and (ii) the total number of deposits made to date (refer to the Eth1Datastructure in the current spec https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md). Inclusion proofs are made against this Merkle root in the usual way and the count of total deposits is used to ensure any deposits included in this Merkle tree are in fact processed (blocks are invalid if they lack the maximum number of possible outstanding deposits). Importantly for the finality gadget, the block hash of the Ethereum 1.0 block corresponding to the state of this contract is also included.

The beacon chain maintains the state of the deposit contract on the 1.0 chain to verify deposit proofs. The block hash for the block resulting in the recorded state is also stored.

Validators are required to submit their view of the state of this contract in each beacon block produced. If a majority of all submissions match in a given period of time, the protocol deems consensus on this Ethereum 1.0 data and it is recorded in the beacon chain’s state as such. As the beacon chain blocks are finalized, the corresponding state for each block becomes finalized; once a given Ethereum 1.0 data has been included in a finalized state, we can say that the corresponding Ethereum 1.0 block has been finalized. This is the basic construction of the finality gadget.

The process of voting for a particular proof-of-work block. Each block has a unique hash; the color is a shorthand for the hash. The small squares represent votes for a particular 1.0 block made by a validator. The voting process starts over in each period of time (described below), demarked by the ticks on the solid black line. Only the first two periods have finalized on the beacon chain, so only part of the 1.0 chain has been finalized in this diagram. Credits to Alexey for the coloring scheme idea :)

Parameters to the finality gadget

The first parameter is the number of SLOTS_PER_ETH1_VOTING_PERIOD which indicates how many slots (a slot is just a duration of time, e.g. 6 seconds) occur before pending votes to update the Ethereum 1.0 data are removed from the state. This length of time is the period during which a running tally of each unique 1.0 vote is kept in the state. The rolling set of pending votes is cleared in every slot that is a multiple of SLOTS_PER_ETH1_VOTING_PERIOD. The Ethereum 1.0 data used for deposit proofs can only be updated by having a majority of validators indicating the same data in this period of time. If a majority is not reached, then the pending votes are cleared and the process starts over leaving the existing 1.0 data unchanged.

This diagram shows some parameters relating to timing in Ethereum 2.0. Current numbers are: 6 seconds for a slot, and 1024 slots per voting period (~1.4 hrs).

The second important parameter is the ETH1_FOLLOW_DISTANCE. This number indicates how far behind the tip of the 1.0 chain a validator should look for candidate blocks to update the beacon chain’s state. Validators are directed to watch the chain for new 1.0 data candidates coming in and pick the majority candidate if one exists. If there is no such candidate (for example, because we just went through another aligned cycle of SLOTS_PER_ETH1_VOTING_PERIOD slots), then the validator should go to the tip of their 1.0 chain and find the block that is ETH1_FOLLOW_DISTANCE behind. For example, if the follow distance is 1024, and the tip of the chain is at block 8M, then we should find the state of the deposit contract at block 7,998,976 and include it along with that block’s hash in our beacon chain block.

Diagram showing the follow distance. There are three voting periods, each a distinct chunk of time. We can see the candidate blocks (shaded) for each period, based on their distance from the tip of the chain. This number of blocks is the ETH1_FOLLOW_DISTANCE. Here it is two blocks; it is currently set to 1024 blocks in the 2.0 specification.

This parameter is not enshrined in the beacon chain consensus but is provided as a guideline for an honest validator to follow. This constant helps validators coordinate around increasingly higher Ethereum 1.0 blocks (making progress on the deposit mechanism) and has the side effect of fixing a maximum height (at a given point in time) at which the Ethereum 1.0 chain could become finalized.

Aren’t we skipping a lot of blocks?

Coming full circle

Improving the finality gadget with the finality ratchet

The ideal scenario is having a follow distance of just a few blocks (to account for baseline latency in block propagation). Ethereum 2.0 starts out with a much larger follow distance (currently1024blocks) in part because the finality gadget doesn’t exist (yay, bootstrapping!). The way this works has to do with the deposit mechanism. Deposits are required to be processed in the order of their creation and are required to be submitted in the next available block once the chain learns of their existence. In the event that a reorg of the proof-of-work chain occurs about a block that the beacon chain has considered canonical, the stream of deposits from the 1.0 chain would become invalidated (invalidating the 2.0 validator set) and would likely break the potential for any future deposits (by breaking the machinery that ensure deposits are processed sequentially) and could even halt the 2.0 chain (as no validators could propose valid blocks). A large follow distance makes this outcome unlikely as the locus of finality will effectively have 1024 proof-of-work confirmations on top of it. If 2.0 clients can count on 1.0 clients to respect finality (avoiding reorgs past a certain depth), then the follow distance can be shortened. At a high level, you can imagine the “highest possible” candidate for finality to “ratchet” towards the tip of the Ethereum 1.0 chain in a progressive manner as the follow distance is lowered, until a safe minimum is reached. How short the follow distance can get is a subject for future research/discussion.

Why do we want it?

Reducing issuance

While the exact plans are still up for discussion, reducing issuance via the finality gadget is a concrete first step to migrate the 1.0 chain to the 2.0 system. A smooth transition will happen gradually over time and the process can begin with the gradual issuance reduction here. We as a community can support the larger migration into the future by supporting this initiative today.

Finality for applications

Smart contracts can take advantage of finality, too. Prediction markets are an example where waiting for finality at some height is useful before determining the outcome of an event. The deployment of this benefit looks like a fork (possibly the same one reducing issuance) adding a set of opcodes so that the EVM can determine if a particular block hash or block height is finalized. A similar EIP to this feature would be the addition of new opcodes like the bitwise shifting instructions in EIP-145 (https://eips.ethereum.org/EIPS/eip-145).

Putting eth2.0 to work…

With the launch of Phase 0, we can introduce the finality gadget to 1.0 and get all of the benefits laid out in this article. With Phase 1, Ethereum 2.0 gains shard chains that hold arbitrary data. Implementing the finality gadget means that 1.0 clients are now light clients of Ethereum 2.0. With light client functionality, proofs can be made in 1.0 smart contracts against this data in the shard chains. This functionality unlocks a number of interesting use cases for layer 2 scaling techniques like high-performance Plasma chains or privacy-enabling zk-SNARKs applications. I’ll refer you to Vitalik’s recent presentation on “Scalable blockchains as data layers” for more on this: https://www.youtube.com/watch?v=mOm47gBMfg8.

How do we get it?

The first step is to refine the idea of the finality gadget as given here in the form of proof-of-concept prototypes and simulations to better understand the ramifications of coupling the two systems in this way. A good outcome here would be the implementation of the finality gadget in one of the popular mainnet clients. This way we can start collecting live data on the operation of the finality gadget to gain confidence it follows the consensus of the existing clients.

In parallel to the work on the finality gadget, we need to develop and launch the beacon chain; needless to say, we need the beacon chain finalizing blocks before we can deploy the finality gadget.

Once we have a clear understanding of exactly what we want to deploy, we can author an EIP to specify the process and move through the steps to get the change included in an upcoming fork. I think it is sensible to deploy the finality gadget itself before discussing a reduction to the mining subsidy or the introduction of new EVM semantics. This suggestion is in the spirit of “make one change at a time” and makes it clear at each stage which parts of the finality gadget have which effects. We wouldn’t want to reduce the block reward when it turns out that the finality gadget doesn’t work quite how we thought leading to a loss of security on mainnet.

Risks to the finality gadget

The main liability of the finality gadget is the process of getting new 1.0 data into the beacon chain. Validators on the beacon chain are required to be light clients of Ethereum 1.0; any beacon chain blocks that form consensus around a 1.0 block hash that is not in a particular validator’s view of the 1.0 chain is considered invalid. This validity condition ensures that as long as a majority of the 2.0 validators are honest, no invalid data with respect to the 1.0 chain will become finalized. In the case where more than 2/3 of the validators are malicious, it will be possible for them to collude towards finalizing a 1.0 block that may or may not follow the underlying proof-of-work consensus. This concern is mitigated by having a large initial validator set and taking a conservative approach to the deployment of the finality gadget. If the beacon chain launches and it becomes clear that the validator set does not have an honest majority then we have an opportunity to rethink our approach. The design of 2.0 and the finalty gadget ensure that if this happens, no changes or impact are made to the Ethereum 1.0 blockchain.

There is another concern given the way validators are expected to coordinate around the next block for a voting period that would not affect the correctness of the finality gadget, but affects the performance. The current specification states that validators choose the majority block suggested by previous block proposers if that block is in their view of the chain. In practice this means that honest validators should pick the very first valid suggestion with each round of voting and all coalesce on that one value. The block in this suggestion would be the next candidate for finalization so a failure to coordinate around the highest possible block (given the allotted SLOTS_PER_ETH1_VOTING_PERIOD) suggests the finality gadget is not finalizing 1.0 blocks as quickly as is possible. This concern can be mitigated by further research into better voting strategies to encourage expedient finalization of the 1.0 chain.

A final category of risks concerns the behavior of the 1.0 fork choice when the follow distance is very short and the 1.0 chain is under attack resulting in (possibly many) short-range forks. There is a trade-off between the quality of finality (determined by the distance between the finalized head and the GHOST head of the chain) and risk of an unstable fork choice on the proof-of-work chain. Future research can try to get a better understanding of this trade-off via simulations and can inform the ultimate finality gadget proposal.

Attacks like these have the effect of reducing or even halting the finalization of the 1.0 chain, degrading the finality gadget’s performance and being particularly risky in the case where we rely on finality for the chain’s security.

Open questions

  • How small can the follow distance be? How should it be adjusted? Slowly over time or is it safe to reduce it near the minimum after deploying the finality gadget?
  • Is the voting process for Ethereum 1.0 block data on the beacon chain sufficient for a performant functioning of the finality gadget?

Conclusion

If you are interested in helping, Alexey and I are starting a working group to organize efforts towards making the finality gadget a reality. You can get involved here:

I would like to say thanks to Danny Ryan for many helpful discussions in better understanding the beacon chain and how we can employ its finality in Ethereum 1.0 and to Alexey Akhunov for getting things started on the working group. Thanks to Terence Tsao for feedback on this article.

Update July 2019: translation to Chinese at https://ethfans.org/posts/the-finality-gadget-by-alex-stokes

Alex Stokes

Written by

building the eternal from the ephemeral