Nashqueue 🛸 Exploring Attacks in the Modular Rollup World

[Music] I am a research engineer at Celestial Labs I'm a contributor to rollit my name is Nash and the motivation for this talk is basically before ethereum did everything um we could rely on sensorship resistance for transaction inclusion approv verification ordering but now we realized and we have specialized protocols that can do those things right we will have da layers that specialize in data availability we have shared sequencers which do sequencing we will have Prov markets right and using all those softwares we now have the realization that oh we now inherit their censorship resistance and how does the this affect the um the rollup itself and basically we'll go through some examples some attacks and I'll start off with how I Define rollup uh rollups are blockchains that post their transaction data to another blockchain and inherit its consens and data availability and rollup blocks are consists of rollup data and rollup headers the rollup data is a bat of transactions or the state difference I will only focus on the batch of transactions and rollup headers is metadata about the block which at minimum includes the commitment of the transaction so this could be a basic rollup a user submits a transaction to a sequencer the sequencer batches it the rollup full note sees the batch and has finality the roll up light node doesn't get the batch by definition so it will need someone to produce the header with some cryptographic uh commitment or some guarantee and it will now trust that guarantee and it's final and in that process we had a bunch of steps that we were able to delegate right we were able to delegate um data availability like we already did that but also inclusion which means what transactions are inside the block ordering means which order the transactions are the execution is what this the the state Ro will be after I execute um the say transition function and basically produce the header and proving is using some cryptographic primitive to confirm the validity of the metadata like uh ZK proofs or validity proofs uh for approves so back to that basic rollup the the sequencer can do inclusion or ordering um it will can be an ordered batch or an unordered batch we could have the header producer do the execution and also probably the proving and we have a mix on Match right we start off with the most basic rollup the the most basic rollup is a base rollup I post my transactions directly to the DA layer then I as a full note can read from that da layer what that means is that the da layer gets all the me I can extract it I can reorder it censor it whatever I want I'm leaking m to the vase layer that's the most uh easy attack now maybe I don't want to leak the m to the base layer maybe I want to leak it to a shed sequencer right but the shed sequencer can do the same thing the shed sequencer can give you soft confirmations for faster block time but the finality will in the end be through the da layer and the audit batch that the r of full not can actually read so the Shar sequencer is also incentivized to extract value and get bribes now another attack is when the shared sequencer does not provide those soft commitments right we have a um why we read from the da layer is basically to force them to post it because it won't be final until we get it and what the the layer Now can do is to collude and censor the sequencer blocks batches on the da layer so the roll of full note will not be able to get the canonical chain it's not that the da layer can reorder the the transactions the transactions are already already fixed but they're not posted on the da layer yet it's now a a symmetry of knowledge between those two full noes and a delay of finality okay now imagine we have two shed sequencer schemes one through the Shar sequencer one through the base layer we have some kind of escape hatch um we have a fortress rule where we say if in a DA layer block there's a shed sequencer batch and base batch uh we always prioritize the shed sequencer batch now we might have um we we think we we figured it out we can use both but the da layer still has the control now because they can censor the shed sequencer batches and now because they're only base batches they can reorder those and basically we are back to square one one where we can trigger the fall back and extract the M right we covered sequencing now let's go to execution um so far we only had Roll Up full noes which means they were only in pessimistic mode I need to execute all the transactions to confirm the validity the roll up light nodes do not execute transactions they don't get the batches they need some commitment the header producer will get the transaction batch from a DA layer and be able to commit over that header uh and the stage rout with some economic guarantee and if the roll of full note sees that there's fraud it can send a fraud proof to the rollup light note now the difference between this diagram and the diagram before is that we ignore the ordering right it's the same transaction badge living on the da layer but we say hey I don't care I'm going to reorder it again because why not the centralized header producer can reorder it and then maximize it in some kind of function but maybe we don't want that this this header producer maximizes it um for themself so let's try to create a competition and have permissionless header production now we can reorder transactions to maximize some objective function The Fortress rule it could be the most M extracted the most gas burned the most user welfare whatever that means and the most funds uh transfer to the community pool but here the we have the next attack where if you have more than one heter producer per roll up height then you leak me to the DA layer again uh profitable censorship again where the Fortress rule will be again highest bribe because the header producer can bribe the da layer to say hey I produced the biggest MV I'll give you a cut please sendor the other ones okay this was the optimistic case let's try to do it with the ZK case we have a ZK rollup and we now have a decentralized proval market Pro of Market is basically to incentivized that we can create proofs for the da layer the da layer does ordering and inclusion again and the had a producer execution this attack is where we censor proof generation and propagation where because the light node finality um depends on the correctness of the validity proof and we can imagine an end game where an end user will run the light node does the availability sampling creates a um gets a validity uh proof and gets the whole correction um the end user will wait and basically have a delay it's a um a sensorship method to delay light noes but light noes are offchain at the user subjective and I do think with good Prov Market incentives and because we propagate through pedop and we assume no Eclipse attack this can be solved the problem comes here when it's not an offchain light note but an onchain light Noe right if I want to have bridging and we have to realize currently we talked about Sovereign rollups we we talked about rollup designs that had that didn't bridge yet but we want to have a bridge and a bridge equals a onchain light client to execute to basically create that that transaction um initialize that bridge I have to create a transaction which includes the ZK proof so me creating a transaction with the ZK proof will go through the whole pipeline of the second rollup or the second blockchain and now maybe something controversial if this roll up um imagine this is ethereum did we now create a s roll up that Bridges to ethereum is it now an L2 are those two the same thing maybe okay and this attack basically now says that because we're dependent on the sensorship resistance of the other blockchain um and maybe the relayer but he can probably get obstructed away we all we have the attacks that I previously mentioned again but for that blockchain and controlling the funds and message unlock might give you access to me you could imagine that um a person is trying to bridge collateral to save themselves from a liquidity and if you are now the other blockchain you can censor the unlock of the ZK proof to make sure that he gets liquidated and then he misses out and capture that uh attack all right um optimistic bridging is very difficult in that sense because the sensorship resistance is tightly dependent on how you generate how you calculate the fra proof window if you go here and look at the the bridge um depending on what kind of sensorship properties there are you need to increase or decrease the fra prooof window and depending on which kind of Stack you're using you might have different kind of properties going through the whole pipeline so you need to now be careful how do you even calculate that fra prooof window and so far those seven days if I remember correctly were just set arbitrarily um if we now have more um protocols in between it will be more difficult to set those uh fraud prooof Windows correctly so there needs to be more research on that topic okay so now let's see all of the things together in a big mesh a user submitting to a shed sequencer the shed sequencer publishing the order block to the DA layer the header producer getting the um AUD badge and basically executing it creating a ZK proof propagating that and then we also going to bridge with that ZK proof and in all of those little things we have uh possible attack vectors of sensorship resistance so what is the solution here um basically have strong set of resistance at each layer especially the da layer um it's very important to realize that because there are so many protocols now we really have to make sure that we try to maybe mitigate some things right if I enforce um a shared sequencer batch and I ignore all base batches I am mitigating uh the extraction of the base layer and the only thing that the da layer can do is um delay finality but maybe that's also bad so we want to have very strong sensorship resistance at the da layer and maybe you can achieve that through threshold encryption where there proposer doesn't even know what they are um putting or what's also very interesting um an idea I think from Elijah um have multiple proposers per block where you could imagine that having um multiple proposals for the da layer can be very additive um and depending on who proposed what you can basically split censorship resistance and have much higher guarant guarantees uh to get included and if you have those guarantees for the da layer you don't have to worry a lot of the about a lot of the things building on top of that um if you want to research more about this I recommend you to talks one is about exploring M capture and modular systems it was at the modular Summit which is talking about multiple proposers per block and the other talk is profitable censorship me um which talks about different kind of sequencer schemes and how those sequencer schemes uh could extract or mitigate um me league and I left some time so I'm happy to answer some questions