# What Happens After Finality in ETH2? A fundamental property of blockchains is the notion of "finality", which roughly means that after a certain period of time, transactions that have been included in the canonical chain are extremely difficult, or almost impossible, to revert. Eth2 has an "explicit" mechanism of chain finality enshrined within the protocol, which is different than the "probabilistic" finality found in proof of work chains such as Ethereum or Bitcoin today. In proof of work, consensus is fundamentally a global race that a lucky miner wins by being the first to produce a valid block: a result of finding a mathematical solution to a computationally difficult problem. As such, block times are probabilistic. The more blocks are added to the chain, the harder it is to revert, as each represents a cumulative sum of electrical and computational power required to create it. Given there are real, physical guarantees that would prevent an attacker from being able to revert the Bitcoin and Ethereum blockchains today, we can consider transactions past a certain amount of time included on chain as "finalized". Ethereum proof of stake, however, does not function on the concept of probabilistic finality. Instead, it enshrines finality into the protocol by saying "If > 2/3s of validators have voted correctly on the chain head for a long period of time, we can consider everything before a specific checkpoint as finalized". Finality is explicit, and nodes that follow the protocol will not be able to revert the finalized checkpoint as it is fundamentally impossible regardless of consensus weight. ## How Finality Works in ETH2 ETH2 is a synchronous protocol that operates on a "checkpoint" mechanism for bookkeeping. Essentially, a set of validators is assigned to either produce blocks or vote on blocks in a window of 32 potential **slots**. Each slot is a period of 12 seconds. Those 32 slots constitute an **epoch**. In an epoch, there are 32 assigned block proposers and everyone else is known as an **attester**, assigned to vote on proposed blocks once per epoch. > There is only one block proposer assigned per slot, but many "attesters" can be assigned per slot For example, Alice is selected as a block proposer for slot 4 in the epoch and Bob, James, Charlie, and Susan are assigned as attesters at slot 4, meaning they should be voting on Alice's produced block as canonical. ETH2 uses Casper Proof of Stake, specifically, something called a "finality gadget". The ETH2 finality process is defined as follows: 1. If > 2/3rds of validators vote correctly on the chain head during an epoch, we call the last epoch **justified** 2. If two epochs in a row are justified, the `current_epoch - 2` is considered **finalized** In normal operation, the chain is meant to always be finalizing. If more than 4 epochs have passed since a finalized epoch, all active will start being penalized to incentivize quick recovery of finality. ### What happens at the end of an epoch At the end of an epoch in eth2, the state transition function performs important bookkeeping to figure out exactly what happened at the consensus layer during the time period and prepare for the next epoch. Validators are shuffled every epoch into new assignments, and we are able to know assignments for 2 epochs in advance, unless there is a chain reorg. During an epoch transition, we tally up all the votes for the head of chain. Validators vote using the **effective balance**, which is measured in **gwei**. When chatting about eth2, we typically mention **validator participation**, which is defined as the amount of total gwei at stake that was used to correctly vote on chain heads during the epoch versus the total gwei of all active validators. ### Consequences of determining a new, finalized checkpoint Determing a finalized checkpoint is very important in eth2 because it serves as the lower bound for many things that are defined explicitly in the protocol. Namely, all messages received via p2p gossipsub that are from *before* the finalized checkpoint are ignored and thrown away. Moreover Here are the things that happen upon a new finalized checkpoint in eth2: - All incoming gossipsub messages from before the new finalized checkpoint are ignored - The **fork choice rule** is updated to only consider votes starting from the finalized checkpoint. Meaning, it is impossible for a node following the protocol to revert the finalized checkpoint - Stored data earlier than the finalized checkpoint is **safe to prune** ## Incentives and reorgs There is a strong incentive to maintain what we call "chain liveness" from protocol rewards. Since mainnet of eth2 launched this past December 1st, 2020, the chain has had perfect liveness, essentially finalizing as expected, every single epoch. The chain participation, meaning the percent of staked ETH that is correctly voting on the chain head vs. the total available, has remained in the high 90s the entire time. ![beaconcha.in](https://i.imgur.com/jR3rv6y.png) From https://beaconcha.in Unless major validators go offline, or if there is a serious bug in a popular client implementation, the incentive to always finalize the `current_epoch - 2`. Given epochs in eth2 are 6.4 minutes long, the epoch 12.8 minutes ago should always be finalized in ideal conditions. For MEV purposes, we have not seen a reorg > 12.8 minutes in the blockchain, of course. So then, is it possible we can get a probabilistic estimate of *transaction* finality via data from the beacon chain itself? ### MEV Every block in eth2 contains metadata about consensus. Namely, a block contains information about: - New validators joining the chain (eth1 validator deposits) - Attestations, which is the name for votes from other validators on previous blocks in the chain - Proof of validators wanting to exit their responsibilities - Proof of validators being slashed and forcefully ejected from their responsibilities For our purposes, the most important are **attestations**. Since blocks are meant to happen every **slot**, which is a period of exactly 12 seconds, upon every block we receive, we can calculate what percentage of staked ETH has correctly voted on the chain head so far compared to the total active validator count's staked ETH. For example, if we have already reached > 2/3rds before an epoch is over, and we did > 2/3rds last epoch, it is fairly safe to assume that chain finality will follow very soon. That is, we can get confidence in finality happening before 6.4 minutes pass. Although this "confidence" can be useful, it is still possible there could be a chain reorg within an epoch, even a 1 block or 2 block reorg, if enough voting power is on a fork of the canonical chain. As far as we have seen, minor forks with significant voting power on eth2 are rare, and have never happened in current chain conditions. Question about MEV: how soon could we know about finality for it to be useful to MEV-geth? ## Philosophical discussion on finality ### Can nodes go against the protocol? Finality, at the end of the day, is an abstract concept enforced by a social consensus on the rules of a protocol. There is an honesty assumption that nodes are indeed following the protocol. This means that even a few rogue nodes trying to modify their client software to ignore the rules around finality will not affect the network as whole, because all other nodes are following the protocol. Given fork choice, which decides _reorgs_, begins at the last finalized epoch, it is impossible for a reorg to occur unless a large majority of nodes go against the protocol. ## References - [eth2 specs](https://github.com/ethereum/eth2.0-specs) - [beaconcha.in](https://beaconcha.in)
Last changed by  
 
Prysmatic Labs
eth2 development team
33154

Read more

Migrating Prysm to Slog

Contextual logging:

12/6/2023
Running BOLD Challenges on Sepolia

This guide will set up

11/17/2023
Generalized History Commitment

Today in BOLD, challenges can have subchallenges, and we have a total of 3 levels. We do this because at each challenge, validators have to commit to N state roots of a block’s history, which can be very expensive to compute. For example, computing 2048 machine hashes for the execution of a block and collecting them takes around 5 minutes on a modern MacBook Pro.

8/16/2023
If I Had a Reset Button...

If you knew what you know now, and you were starting a new CL from scratch, what structures would you use? Let me start myself to set the tone, you can make it language specific (for example Go and avoid templated methods) but I am not really interested in the small details but rather the main components of the critical parts of code. Typical questions I’m thinking about areWould you use a custom allocator for the beacon-state/validators/attestations structures?Would you use a struct like object for them or would you use a functional style object. The typical situation is this:We have a buffer with 8192 roots in the BeaconState, but these roots are sequential, if state for N had up to root r, the state for N+1 will share essentially all of the roots as that for N except at one point where it would have changed one. If you store vectors and then you want to share the common part then you are lead to structures like the multi-value slice or similar structures, where you have a base slice and then somewhere else you store the diffs (or some mathematically equivalent statement). Another way to store the object is as a linked list (with some additions to make it into a round buffer) and when you change one element you just change a single node on that list, someone that holds the pointer to the current node will resolve to the current full round buffer, while someone that holds the pointer to the previous-to-modified node, will resolve (by traversing the links from it) to the previous full round buffer. If you have a fork this still works, you just need to add a few pointers on either side of the fork. The point is that from the point of view of the structure itself, there’s no “base state” and some diffs, and rather you can just delete the pointer and let GC in Go, or the Destructuror in C++ deal with the rest. No need to be pruning yourself from a multi-value slice for example. On the other side, the multi-value slice would incur in way less memory fragmentation if you are dealing with a single state in the happy case.There are variations of this for all structures in the Beacon State and there are benefits and cons for each one of them.What sort of thread management would you use? (I think here there won’t be a disagreement and just relying on the Go runtime is fine)What sort of fork management would you use? I originally thought about templating, something like having the Fork being the template parameter for a BeaconBlock structure. In C++ at least, the best structure seems to be vertical polymorphism in the structures themselves like having class AltairBlock : public Phase0Block but not use methods of these structures, but rather pure functions like attestations(block Block) []Attestations and just let AltairBlock and Phase0Block satisfy the concept Block, which in this case would mean they both have a member attestations so you can just simply implement that function as return block.attestations. In Go this seems to be quite complicated, templates as far as I could read do not allow us to do this, and interfaces themselves we have them, but we still are forced to repeat the underlying structures completely for AltairBlock and Phase0Block instead of invisibly inheriting and obscuring the changed ones.Would you trade security and correctness for performance? I think this is a funny one: if you’re coding for 0.1% of the market, then you can do lots of shit like only keeping the last two states and break if there’s a depth 3 reorg. That’s an extreme case, but that’s probably not so far away from what Erigon’s CL may be, I would bet that they just follow blindly whatever is voted. But besides the extreme cases, how about Optimistic sync? I am pretty sure we are the only ones that considered a recursive system in which a bunch of branches turned out to be invalid. I am convinced that you can simplify a lot the optimistic status dealing if you just ignore correctness in a bunch of cases, with no real danger to the network.How would you deal with the engine? Would you change the interaction with the engine if you knew that ALL your users are using MEV-Boost? would you optimize the builder code in detriment of the local code? for example, it could be perfectly valid to not wait for local blocks and not request them in advance until it’s late in the block in case we know we are not resource-heavy. Not wait for the result of FCU is also good, since we are guaranteed already from a VALID response from NewPayload (this is something we could do right now on Prysm).

8/2/2023
Read more from Prysmatic Labs
Published on HackMD