# How long non-finality could kill Ethereum by Dapplion | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 16:03
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-z2jafwPFLaQ
- YouTube: https://www.youtube.com/watch?v=z2jafwPFLaQ

## Description

After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?

Speaker(s): Dapplion
Skill level: Intermediate
Track: Core Protocol
Keywords: Consensus, Decentralization, Security

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] [Applause] hello hello and thank you let me drop the water so hello everyone I'm d lion ethereum cep at consensus at Sigma Prime and today I'm going to talk about how long FTI could kill ethereum or some healthy dose of fear mongering to get all the cevs here to care a little bit more about this issue so just to start let's get everyone on the same page this talk is not labeled as an expert so we'll start with what the hell is finality so ethereum has a strong cryptoeconomic guarantee where if a block is finalized it will not get reverted and less 2/3 of the stake so an insane amount of money gets destroyed for the purpose of today what you have to know is when we' analyze something everything that descends from it is a possible block or state everything else we get about so when the network fails to reach finality in other words 2/3 of the chain agree on something then this section of blocks and States just keeps growing because the finalized checkpoint doesn't get updated and it just keeps going in the past and in the past so today we're going to run through an experiment I'm going to show a hypothetical failure mode of the bco chain on Nority and we'll talk on all these POS possible Concepts and how they tie together into something that could actually kill ethereum so let's start with some finalized checkpoint and here are some descendant block a but this could this is a longer chain I'm just representing here shortly for Suess next oops some client has a bu with more one one third of the state say like a consensus issue where they reject a block that they shouldn't and this causes a chain split so the faulty client cannot produce on top of a so it just goes on its own fork and mines B Prime X Prime so on and so on everyone else stays on the majority Fork so B and x and with these three dots I'm representing a long chain if we're talking about one day of nonf finality this could be 7,200 blocks so quite a lot the first thing that happens is most clients spend not significantly but a decent amount more this space during nonf finality as the the amount of blocks and states that they have to keep for fast access is higher then now it's when things get interested let's assume that one of the faulty clients for some reason be another back or some Network problem they lose out of sync or they crash and they think that b Prime is the head they will act on it and produce this block X prime prime which forks from B Prime this block is very expensive to process and we'll show now why and everyone else must process everyone in the fork X Prime and everyone in the fork X so these blocks are expensive because in ethereum states are not only dependent on the parent but also on time when you want to process block X Prime you have to load the state at B Prime and perform something that's called a state Advance you have to run this code which is relatively expensive and increases linearly with State size a lot of times so in this case if it's one day of nonf finality you have to do this 225 times plus hashing so I don't know the numbers but we are talking a few minutes potentially and we can have many of these blocks and these blocks are very expensive and what they can cause is that now some nodes get overwhelmed they trigger resource exhaustion so let's consider now one of the non faulty nodes at X they have to ingest these expensive blocks and now they also fall out the sync so they start to produce these annoying blocks that again are expensive to process and here you can start to see how things spiral out of control now that we have a decent amount of forking this space really shoots up because again we are extending the space of possible blocks and and and States not only in the dimension of time but also in the dimension of forking and now clients can start again depending on the client and how they run to run out of space if a if a cent Cent has no space it stalls it cannot progress it needs manual intervention so because of that let's consider one of these Forks now doesn't have enough participation because clients are losing dis and going out of sync then you have rears which are expensive and another interesting failure mode is that some Els can not handle reorgs past a certain death if that happens they stall because they don't have enough state to process the chain so more clients going offline y y y y uh also things to consider clients could crash with om depending on how their state cache on memory works and again triggering sync issues so in this accidental again accidental failure modes any sort of back can spiral out of control as it causes resource of exhaustion which causes faulty blocks which causes exhaustion and so on and this behavior is quadratic with time to final like the longer finality goes on the more expensive these operations can become but that can be triggered by an attacker all of this so far has been accidental and accidental failure mode is problematic because it has a lot of stake but if an attacker wants to exploit this and has significantly less stake potentially like some 100 Keys it can truly wreck havoc so the the problem as I was saying is these very expensive blocks that do a lot of Skips and you can create a lot of objects that exploit this so for blocks you need stake you need to have a valid proposal signature but you can Brute Force valid proposal slots if you have maybe like a 100 so like the the Crusader the low car Crusader could easily attack the chain in a finality of like one day and create about some hundreds of blocks which again consider each one takes one or two minutes to process you can dos the network like that aggregated stations also require stake you have to Brute Force theator Duty and unaggregated stations you don't require stake as you can just produce an invalid attestation and it will still Force nodes to compute the shuffling the good news is that we are fixing this last attack Vector on Electra and you will also require stick so look at some history we have had some issues with finality in the past the most relevant one happened in 2023 where we lost finality for about four epochs what happened is something very close to this failure case where some nodes consider to be synced and they propose a very a very expensive not not as expensive as the ones we're talking about but some attestations that take some time to process unfortunately prism had uh sorry uh some caching issue where it did this work over and over and and it didn't had a well structured queuing system to protect themselves against clogging so any relevant work to progress the chain like blocks and attestations just didn't happen and that resulted in the in the loss of finality also medala is the quential event of nonf finality I'm not going to talk in detail here but we can talk it later also gly suffer a very brutal death with a bunch of cascading effects and funny enough the pier DEET that we run recently had a massive reor of 130,000 blocks that triggered this Edge case where none of the Els could continue because they stalled without state so yeah what's woring about failure modes regarding non finality is that it's very spirally things cause things and it gets pretty out of hand so so far we have talked about accidental issues that relate to client bus Network partitions these sort of things but the worst case that we should consider is what's the possible longest non-f finality that we could see on the Bon chain and that's related to this failure case where say that we have super majority gu they have a consensus issue where they mint infinite e so it's not a for that we that we can canalize in that case if they finaly the wrong Fork they will be stuck there so on the correct fork in this case chain B we will have to wait for them to leak out that's going to take a long time so if G is like 70% we are looking at 32 days so that's in my opinion that's the worst case that we should aim for and this is realistically something that could happen if for some reason G gets a significant amount of market share so what can we do what can we do uh easy just don't do bugs just don't release clients with bugs then we don't have non finality and easy that not a problem uh now for real there are no strong mitigations it's just we need to harden the client so don't run out of this space don't run out of memory don't get exhausted and third we're going to look and explore if we can actually reject some of these useless Network objects to protect against the most uh blatant cases of those and yeah all of these solutions they work on this it's not actually a trilemma but it's a tradeoff space where in eum we work really really hard to preserve liveness that's why we have this hybrid consensus mechanism where the chain goes into this nonf mode just because we want to preserve liveness we don't want want to be in a situation where not operator intervention is mandatory to rec to recuperate the chain at the same time we don't want to die and we want to process everything in a timely fashion so the first point and the most dangerous is running out of this space here there are a bunch of easy rules that I think most clients follow I'm sure I think Lighthouse is one of the ones that don't follow all of them but we are working on that and in Lighthouse we are now introducing this very interested optimization which is storing everything as THS that's commonly known uh in consensus folklore as three states and that's going to be rolled out in the next version but it only affects the freezer database what we want to do next is apply the same principles but for unfinalized States and that's going to be massive because now every time we want to store a state instead of spending 200 Mees we can just spend half and we have really good compute and apply times for a bunch of different divs how this is going to look like we'll have this uh hierarchical div structure where if you want to recuperate say the state in red you load snapshot and then iteratively load the diff apply load apply this is very very efficient in terms of dig space and as you saw the numbers here it's actually um pretty fast and even faster than replay the complic ation with the unfinalized section of the chain is that we have moving finality which complicates a bit the design but if we just extend the diffs into some finalized range keeping at least one per layer uh the design works and pruning is not that complicated for memory there is not much you can do you just have to make sure that your uh State cache doesn't blow up in these circumstances and and again three states memory helps a lot and this is already in production in Lighthouse and the last one and I think this is the most important you need to have some strong queuing system where you you don't let yourself get exhausted from this garbage that can come from the network looking at the madala the main incident that we talk about if instead of having this que you split it in two sections one that has higher priority for things that are useful to you in this case let's say descendant of heads and then everything else gets processed with lower priority we should be safe in this case Lighthouse at the moment is working on Reb bumping all our queuing system and we're going to do something with this also with fairness so P0 doesn't exhaust P1 and the last point is okay we know that these blogs are really bad can we just ignore it that would be really nice and unfortunately no if we want to preserve fless there are a lot of edge cases where if we start to ignore blocks then the chain could stall so I think this is the only one I've seen that I like and it's on prism in production this is by POTUS if you get things that uh extend something privious to justify it it's more complex than this but just to simplify you can ignore them and this would have protected prism from the issue that we saw uh before unfortunately this is just one of the many failure cases that the chain can have so it's not like a a bulletproof so what are the next steps well testing testing testing and testing the issue with non-f finality is that you know we have to do pectra we have to do pias we have to do so many things that unfortunately dealing with non just just goes like priority number three or four uh I talk with the ethereum devs team the panda OBS and what we should do is have some cyclic tests either continuously or maybe like quarterly where we test non-f finality we want to uncover these bugs ahead of time and not when finality dies either in a important defet or mainnet also in Sigma Prime we have a tool that we have been using with great success in this source of attack Nets and it's insanely good at killing networks so we are with Michael in the process of revamping this tool and we'll definitely use it in uh in these tests so yeah but yeah I mean just to not be to to to feel Ming here um the Bon chain has been exceptionally stable through its lifetime and the only time it lost finality was for for EPO which is nothing uh we have a robust set of operators who are very diligent hands on the same for ceps we have triage and fixed issues really quickly so again we have to work on this it's my mission as a cep to make sure that ethereum never loses liess um but yeah we've been doing great so far and we should be proud of it