The finality gadget

Putting eth2.0 to work…

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


The idea behind the finality gadget is to leverage a property, called finality, of the Casper proof-of-stake consensus protocol to be deployed in Ethereum 2.0. Phase 0 of Ethereum 2.0 is the deployment of the beacon chain, the main system-level chain in the sharded blockchain. Validators participating in the beacon chain consensus generate finality on this data after some conditions have been met according to the Casper algorithm. We call this property finality because once a certain block is finalized, that block is in the canonical blockchain for all time; a reversion can only occur with the provable burning of more than 1/3 of the validating ETH at stake. Assuming a healthy level of 10M ETH participating in the system, a successful attack would result in the burning of around 3.3M ETH which at the time of writing is a cost of over $600M. I’ve written a bit more about finality here if you are curious for more detail:

How it works

Let’s now look at how the first version of the finality gadget works, given the current status of the Ethereum 2.0 project. Note that while we are getting close to a final specification of the beacon chain, some details (particularly around parameters in the system) are still being discussed and are subject to change.

A light client tracking deposits

To become a validator in the new Ethereum 2.0 system you send your collateral along with some registration data to a smart contract on the existing mainnet which then emits a log. This is a one-way deposit that can only be recovered by submitting a proof of the registration on the beacon chain. Once this deposit event has been processed, you enter into an activation queue which ultimately results in your inclusion in the set of active validators on the Ethereum 2.0 network.

Image for post
Image for post
A validator becomes active on Ethereum 2.0 after inclusion of a valid deposit from the 1.0 chain and a queuing period.
Image for post
Image for post
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.
Image for post
Image for post
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

There are two important parameters relating to the timing and frequency of this process to update the beacon chain with new Ethereum 1.0 data. They are integral to the quality of the finality gadget.

Image for post
Image for post
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).
Image for post
Image for post
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.

Aren’t we skipping a lot of blocks?

Realize that given the “chain” nature of the 1.0 blockchain, finalizing a block at height N implicitly finalizes every block in that chain below height N all the way back to the genesis block. This means that the set of finalized blocks on the 1.0 chain will suddenly jump some number of blocks according to a periodic cycle determined by the previous two parameters and the time to finality on the beacon chain. Given the existing constants for the beacon chain, this period of time works out to about every 2 hours in the optimal case. As we will see below, progress can be slowed or even stopped under adversarial conditions.

Coming full circle

As described so far, the existing 1.0 chain doesn’t have to know anything about the new system. To fully implement the finality gadget, we have to go one step further. This last step involves a fork in which the Ethereum 1.0 fork choice is altered to respect finality. Concretely, Ethereum 1.0 would still use GHOST to find the canonical chain, but it would start this search from the most recent finalized block (as determined by the beacon chain validators), not the genesis block as happens today. The fork to enable the finality gadget is where most of the work (from the 1.0 perspective) comes into play, as 1.0 clients now have to be aware of the 2.0 consensus. However, modification of the fork choice rule lets the security of finality extend to the proof-of-work chain, allowing the realization of all of the benefits allotted by this extra security.

Improving the finality gadget with the finality ratchet

Clients can get a big increase in quality from the finality gadget if the device sketched above is successfully deployed. This gain in quality comes from shrinking the 2.0 ETH1_FOLLOW_DISTANCE to as small a number as possible. The closer finality can trail behind the tip of the 1.0 chain, the greater the additional security margin and the higher the quality of finalized data exposed to users.

Why do we want it?

Reducing issuance

Finalizing the 1.0 chain has a number of benefits. A big one is that the mining subsidy could be reduced assuming a well-functioning finality gadget. By sharing security from the beacon chain to the proof-of-work chain, the proof-of-work chain can retain the same level of security while reducing dependency on the miner’s hashrate. Because we wouldn’t need as much hashpower to secure the chain, we are safe to lower the mining subsidy (therefore offering a less attractive incentive for miners and reducing aggregate mining activity). An immediate side-effect here is lowering the issuance rate of ETH and the corresponding total supply, a goal that generally seems to be supported by the community. After successfully deploying the finality gadget on mainnet with a modified fork choice, this benefit could be achieved via another fork that gradually lowers the block reward like described in EIP-1011 here:

Finality for applications

Once 1.0 clients are aware of finality, this data can be exposed to smart contracts and related applications utilizing the EVM. Finality is a useful property to have as the current state-of-the-art involves waiting a “good enough” number of “confirmations” where it becomes unlikely (but still possible) for a proof-of-work reorg to occur. Picture an exchange that currently waits for a large number of confirmations before releasing user funds in a withdrawal operation. If this exchange instead waits for finality, it can shorten this length of time giving a better user experience.

Putting eth2.0 to work…

The finality gadget represents a benefit we can get as soon as Phase 0 of Ethereum 2.0 is launched. Ethereum 2.0 is being deployed in a series of phases: Phase 0, Phase 1, and Phase 2. Each phase introduces another layer of complexity to the sharded system and while the 2.0 teams are working to launch Phase 0 by the end of 2019, the remaining phases are expected to take more time. Given that user-level accounts resembling those found in Ethereum 1.0 today are not available until Phase 2, it is worth pointing out that the community stands to realize substantial benefits at each phase of the 2.0 deployment.

How do we get it?

The path to deployment of the finality gadget involves several moving pieces and may take more than a few upgrades to enhance its effect; in short, it is a complex initiative that will take a lot of work :)

Risks to the finality gadget

In broad strokes, the finality gadget represents a bidirectional coupling between the 1.0 chain and the 2.0 beacon chain. The more coupled the systems are, the greater the attack surface and therefore greater cause for concern. We will want to do a thorough analysis of the coupling in each direction before suggesting a specific design for the finality gadget.

Open questions

  • Assuming we have a functioning finality gadget, how do we want to change the mining subsidy (if at all)? Should it be a flat reduction in one hard fork? Should the issuance be a function of the follow distance? Can we map the economic security of finality (denominated in ETH) to the security derived from hashrate on mainnet today?
  • 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?


Hopefully you better understand what the finality gadget is, why we want it and a path forward to get it. There are a number of open questions we need to work through and any help on that front would be great!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store