# Explaining finality

By [Daniel Ramírez-Chiquillo](https://paragraph.com/@danielrachi-2) · 2023-06-17

---

When interacting with a consensus client via the [Beacon API](https://ethereum.github.io/beacon-APIs/), you’ll get a _finalized_ field as part of the response in some endpoints. [I implemented](https://github.com/sigp/lighthouse/pull/3753) that in [Lighthouse](https://github.com/sigp/lighthouse), and in this essay I will explain what finality is, and how it works.

Ben Edgington wrote a great definition of [finality](https://eth2book.info/capella/part2/consensus/preliminaries/#finality) in _Upgrading Ethereum_:

> _Finality is the idea that there are blocks that will never be reverted. When a block has been finalized, all the honest nodes on the network have agreed that the block will forever remain part of the chain's history, and therefore that all of its ancestors will remain in the chain's history. Finality makes your payment for pizza as irrevocable as if you'd handed over cash. It is the ultimate protection against double-spending._

In practice, finality is defined based on the concept of slots and epochs. 

Time in the beacon chain is split in 12 second periods. Each of those periods is a slot, and in each slot a block can be built. An epoch is 32 slots.

The epoch previous to the current epoch is considered to be _justified_. The epoch previous to the justified epoch is _finalized._ When an epoch is finalized, it only finalizes the 0th slot of the epoch and all prior slots. If epoch 1 is finalized, then slots <= 32 are finalized, but slot 33 is not.

![Slots, Epochs, Justification and Finality](https://storage.googleapis.com/papyrus_images/80c0301773640cda07262ab5ce79c66393b12d57994056da74e14f451afecb17.png)

Slots, Epochs, Justification and Finality

When communicating with Lighthouse via the Beacon Node HTTP API, the value of the _finalized_ field for endpoints related to blocks, e.g. [_/eth/v2/beacon/blocks/{block\_id}_](https://ethereum.github.io/beacon-APIs/#/Beacon/getBlockV2), is computed by calling [_is\_finalized\_block_](https://github.com/sigp/lighthouse/blob/c547a11b0da48db6fdd03bca2c6ce2448bbcc3a9/beacon_node/beacon_chain/src/beacon_chain.rs#LL431C1-L449C6)_._ \[1\]

The function takes a slot and the root of a block, and returns a bool indicating if the block is finalized. It is implemented for the [_BeaconChain_](https://github.com/sigp/lighthouse/blob/c547a11b0da48db6fdd03bca2c6ce2448bbcc3a9/beacon_node/beacon_chain/src/beacon_chain.rs#L309) struct, which:

> _Represents the "Beacon Chain" component of Ethereum 2.0. Allows import of blocks and block operations and chooses a canonical head._

What is important for finalization is that last part, the canonical head. In Lighthouse, the canonical head stores the _finalized\_checkpoint_, and the checkpoint stores an epoch. Having that epoch, we just have to ask for its first slot to know what the latest finalized slot is.

We could just check if the number of the given slot is less or equal than the number of the latest finalized slot. However, this has a big flaw, how do we know if the given block is actually an ancestor of the block in the finalized slot? We have to check if the given block is part of the chain.

This is done like this: 

*   Ask the beacon chain what the block root is at a given slot.
    
*   Check if the root given by the beacon chain is the same as the one given in the function call.
    

With this, we can know if the given block is finalized. Being older than the latest finalized block AND an ancestor of the finalized block. In boolean terms:

    block_slot <= finalized_slot && is_canonical
    

Notes
=====

\[1\] This field is also returned for endpoints related to _States_. In that case, [is\_finalized\_state](https://github.com/danielrachi/lighthouse/blob/693886b94176faa4cb450f024696cb69cda2fe58/beacon_node/beacon_chain/src/beacon_chain.rs#LL448C1-L466C6) is called. The implementation for states and blocks is almost identical, so I’ll only explain blocks in this essay.

---

*Originally published on [Daniel Ramírez-Chiquillo](https://paragraph.com/@danielrachi-2/explaining-finality)*