# Impossibility within Dynamically Available Protocols

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 14:08
- Watch: https://streameth.org/watch/yt-bMdgQbD5v3E
- YouTube: https://www.youtube.com/watch?v=bMdgQbD5v3E

## Description

This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. 
I also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.

## Transcript

[Music] thank you okay so hello everyone um uh really appreciate uh all of you uh coming here to today to listen to this talk and uh in this talk basically I want to talk about the state of dynamic availability um the state of basically what has been going on in in the industry and what I have been you know working on for the past few months on this uh so basically I started uh I started the fellowship by basically understanding um uh like consensus algorithms and uh looking into single slot finality but as uh the time went on I basically focused more on U Dynamic availability in particular so uh for starters definitely the question is uh what is dynamic availability so it is basically any protocol that is uh live under what is called Dynamic participation which means that basically nodes can come and go into the protocol and you know it still works it does it's not like a static uh a static validator set where you know the protocol is already aware of what nodes there are so like the dynamic participation a few examples is definitely the Nakamoto consensus like Bitcoin coin uh lmd ghost that is used in ethereum currently and a few of protocols you know that I will be talking about today like goldfish and R lmd ghost um so uh a little bit primer about lmd ghost if anyone is unaware uh it is uh it is the folk Choice rule that is used in ethereum uh it basically uses uh the weights of WS to decide the tip of the blockchain so like uh if there is a block proposal and it wants to propose a block on top of a previous block it calculates all the VES uh all the VES that basically any particular tree has and uh so as you can uh see in this diagram perhaps that the block F has 20 e has 25 so like when you are at a you're going to take a step at C because it seems to be like seems to be like the heavier sub tree and then you can you know take a step at e and that way you can you know decide uh which block to uh which block to choose as a tip now currently lmd ghost as it exists uh has some problems it has problems with Dynamic availability in particular uh and it has a problem with ROK so a particular attack Vector that I want to talk about is an xand attack so how to execute it so let's say you have a block at slot n and uh then it's time for slot n plus one now the Val data here is malicious and uh it proposes the block but it does not like releases it into the network and uh uh and it has control over a set of malicious uh attests that attest to the block privately so for the majority of the network they think that the slot is empty so in the next slot when a new block is proposed they tend to vote to that slot but as you can see that uh in the next slot the uh malicious uh the malicious proposer then releases uh it to to some of the network and then some of the testers might see block n plus1 before the block n plus2 and then attest to that and then uh you know this cycle can continue in um uh for like as many slots as the uh as the malicious uh malicious proposal wants if it has like some sort of control over the network delay and uh then it can like release um release the entire thing to the network and like as more and more slots uh as more and more slots uh like a part of those slots attach to this Mal block it gets more and more weight so like if it then releases a new block that is tied directly on it you can see that the weight of the N plus1 block would then be more than you know the other blocks so the chain will then reor and that's how basically honest proposers blocks will not be included in the canonical chain because you know the chain has Reed and U that is obviously an undesirable uh property so how do you solve this well uh there is a one approach and uh and that approach is basically goldfish so goldfish is a protocol which uh uh as you can see like whenever slot is someone proposes a block they vote uh the the attests basically vote for that block and all those votes are then you know aggregated and that's what the tip is like uh what goldfish basically does different from uh uh lmd ghost is what's called like vote expiry and vote buffering so vot buffering is basically you know like whenever you whenever you see a Blog whenever you send a message into the network uh that you know Network messages are called like vot buffering and uh it's also called view merge so like by view you mean like you view you view something in your local View and by merge you mean that you know you merge what you see uh into what you think is the current state of the network because you as an individual validator you cannot know the state of the entire network you only know you know what your local view is by the nodes that you're connected to the thing that it introduces it's vote expiry and uh that basically means that it does not it does not uses the votes of uh it does not uses the votes from the previous slot so it only uses the votes that are casted in this particular slot so you know previous uh Val vators basically if they vote on something you know if uh if there's some sort of uh if they're trying to withheld votes and they uh they publish it later then it will not be you know counted so that way you know they could nobody can you know withhold hes and they will not be counted they would be discarded so you don't have attacks anymore but it does raise uh another problem and that's the problem of asynchrony so what if there is a network delay right because uh because because if a L basically votes for a block and the vote does not reach in time in the in the particular slot duration then that attester vs will not be counted and that is not the fault of the attester it's just some network is just a period of asynchrony right and the Goldfish protocol would would just not work in asynchron so that is a particular problem that faces another way to think about the reorg attacks is should think about subcommittees so subsampling or subcomittees is basically crucial in the success of these pror attx and because you know it is easier to like have a control of you know a small set of validators and easier to have like control over the network delayer you know if there's like a committee because like a committee has like 30,000 validators but like the entire set of ethereum has like a million so like you know you cannot have control over the entire network but you know it's practical like somewhat possible to have what about let's say 30,000 noes so like if you just remove subsampling completely and you know you just have like the entire million validator set you know a test in every slot then well the problem of reor attacks you know will be solved but uh I mean obviously that's not you know practically possible in like 12 or 13 or like so seconds it's going to take a long time to you know get all those vots get the um aggregate the signatures and stuff like that uh so R rlmd ghost which is like a a version of this um protocol that I'm describing uh introduces a concept of relaxed V expiry and that is basically uh uh what what I mean by relaxed V expiry is that in goldfish you remember the uh the votes expire by after just one single slot but in this you can basically uh balance between uh asynchrony resilience and dynamic availability what that means is that you can basically uh chew uh the votes from the most recent end slots can be considered and the reason I say that it's a balance is because is because uh it's because Dynamic Avail availability basically means Dynamic participation like validators can go in and go out and like if a validator like is part of the network votes and its votes is either withheld or like through Network delay it's stuck and then the validators goes offline the vote can still you know affect the protocol which is not you know a property of dynamic availability so like uh goldfish is a perfectly dynamically available protocol but through rlmd by choosing this uh parameter you can balance between both these factors but uh as you see that it also has a problem of not having subsampling so is there like an impossibility between these three properties uh Rog resilience subsampling and a in green resilience and the answer seems to be yes like uh I didn't get a chance to work particularly on a formal proof of this um of this relation but uh based on you know what I have U studied and researched so far it seems to be the case because if you think uh if you think about it in uh from a view of a of a validator if you do not receive an attestation from another validator there could could be two reasons for that either that validator is malicious or adversary and it's withholding the vote or you know there is just a network delay but and you as a validator cannot you know differentiate between the two so uh so is there a way to basically combine all these properties together in a fashion you know that can be useful for the protocol and uh well a disclaimer this uh this particular slide uh needs to like U needs a lot of like academic review and like a lot of validation from like people much smarter than me uh so just take it with a pinch of salt but uh a possible solution could be that you know we can use goldfish as the current uh as our Fork Choice algorithm and we can try to figure out a way to deterministically identify a period of asynchrony so let's say that a committee has 30,000 votes everyone you know votes for a particular block so like there are around 30,000 votes per slot and if let's say the number of votes you know drops suddenly that could could be a condition of asynchrony when uh when the protocol will dissolve the Committees and shift to an rlmd model where the where the vote expiry period would get relaxed it will expand and you know Network and uh you know the votes of votes from previous networks will then be allowed to you know be considered into the into the folk Choice rule then uh based on how quickly the votes are coming in we can determine if synchrony has has has been like achieved again and then we can reestablish committees and the protocol will be back to normal so uh that is uh roughly it about the talk I want to uh thank the etherum foundation and Mario and Josh for giving me the opportunity to study about this and I also want to thank uh my mentor Franchesco who's uh doing consensus research at ethereum and also Lincoln who was uh the uh ethereum fellow in the last cohort uh he also worked on uh single slot finality so yeah that's it about my do thank you all right thank you Yash any questions for Yash so so I'll raise one it's just if you're swapping between modes mhm do you think that that increases the complexity of your vulnerability and attack surface analysis because what starts happening is that a malicious attacker can influence the network so you switch from one mode to the other Etc so that they can take advantage of of of that situation Etc and and amongst other things that just makes it much harder to to reason about it and people forget you know can't forget that actually the Network's not always operating this Mo in this mode they need to consider that it changes uh yeah of course so like uh okay so like uh the uh the basically the model that I talked about is obviously like if you know we do more research on it it's going to be incredibly complicated and switching between like con basically consensus protocols on the Fly is going to be very difficult uh the reason for like uh for my research is just like exploring what are all the possible designs you know that can be uh implemented into the consensus and uh of course like ethereum itself is moving more towards the single slot finality model so uh it would be interesting to just see like how Dynamic uh like what are the properties of dynamic availability and how you know it could be like obviously this is not something that I would you know propose to actually put into eum but like it's still interesting to like research about it all right thanks Yos thank you guys one more [Applause]