Breaking Rollups: How Sequencer Design Shapes Your L2's Attack Surface - Adria Torralba Agell

Transcript

[music] >> Okay. Thank you everyone for coming. I'm Adria Balaguer. I'm a PhD candidate at the Open University of Catalonia. And today I'm here to present my most recent research. Which is about breaking rollups and how sequencer design shapes your L2s attack surface. And this is a joint work with Muytran, which is at the Chalmers University of Technology in Gothenburg in Sweden.

One year ago, I stayed there for 3 months doing a research stay and we mixed my expertise on rollups with his expertise on network attacks to come up with this study. And also Cristina Pérez Solà is my PhD supervisor and it's also part on this study. So, before diving into that, let's let me explain who who I am. I'm a PhD candidate at the on applied and I'm doing a PhD on applied cryptography on blockchain and recently I've been working as a zero knowledge cryptographer and blockchain security researcher at OpenZeppelin.

And my research focus are on zero knowledge cryptography and proving systems. Also, I'm really interested on Ethereum and rollup security. Today I'm here to talk about that. And also, I'm really interested on the uses of cryptography to improve privacy and censorship resistance online. And also, I would like to tell me tell you one more thing about me, that is that on my free time I dance Lindy Hop and I'm really happy because yesterday the EthPrague organization had the wonderful idea to mix the Eth Prague uh opening party with uh social dance swing Lindy Hop in Prague.

And I had the chance of dancing a little bit with the crowds here, which was amazing. I haven't uh danced in Prague yet. Yeah. But, back to the topic. Uh this is the outline for the presentation today. Um I will start presenting the motivation for this study. Then, I will explain briefly how do rollups work. And then, I'm going to present the two main contributions of this of this article, which is uh the first one is a taxon we come up with a taxonomy of the different rollup architectures in terms of uh sequencers.

And the second contribution is on that taxonomy of the sequencers architectures, we present and propose which are the network attacks that are more are more feasible or are more probable to be happening depending on on this taxonomy. And finally, I will draw some conclusions on that. So, um it just stopped working that, so the motivation. Uh why do we need this study?

Ethereum was not scaling properly. And well, we had years ago, Ethereum was really slow and was not competent enough with uh traditional payment systems, let's say Visa, which processes way more transactions per second on average. When Ethereum got congested, we have a problem because with high high demand, it comes uh guy high gas fees and a slow confirmation times. >> [sighs] >> However, uh no, sorry. Um the problem about that is the Well, the problem why do why do we have this setup is because we have what's known as the blockchain trilemma,

which says that you cannot achieve simultaneously scalability while maintaining security and decentralization. But, to solve that, we have shifted the Ethereum roadmap to adopt a roll-up-centric roadmap. And in this setup, we are using L1 as a secure settlement and as a data availability layer, and we are keeping the off-chain uh sorry, the heavy computation part of the transactions on L2 systems.

So, we use that cheaper systems to perform the computation, and we use L1 as a settlement and data availability layer. And roll-ups, to be fair, have emerged as the dominant L2 paradigm to solve this issue because if we look at the metrics, we see over 55 billion dollars in total value locked right now, and it is estimated that around 65% of all the Ethereum ecosystem transactions are processed through some kind of roll-up.

But, with high stakes comes high risk. And I want you to see that I'm pretty sure that you cannot see anything, but I will explain what's what it is. These are the top 100 most lucrative hacks that happened on L2. The source is from reg.news. And here we can see the number one up to I don't see that, but number 10 and one number number 100. And now, in orange, you see highlighted the hacks that happened in 2023.

In blue, 2024. In green, 2025. And in red, 2026. We even see right over there the Kelp DAO recent hack. So, the motivation for this study, at the end of the day, is with this landscape where the most relevant hacks are happening really recently, we think that we have to contribute to the community by studying what's going on, what can go wrong, what can go good, and and and to present this systematic study.

So, the contributions for this article are two. The first one is we want to present a taxonomy of the Ethereum rollups architecture based on the on the sequential design. And the second one is a security analysis of the different attack surfaces that these different architecture um design sequential design enables on on each class. But before doing that, let me briefly explain how a rollup work. Uh this is a figure summarizing how the transaction workflow of a rollup more or less looks like.

And I suppose that you can see that in red. >> [snorts] >> Okay. So, the journey begins when an L2 user wants to an L2 transaction. And what usually uh he does is it submits that to a set of relayers that usually run by the same company that the the rollup is uh running, or by some third party that is also running these relayers. The relayers take the these transactions and send that to the sequencer.

And the sequencer is the rollup itself, the L2. This is another chain built on top of a layer one chain. The sequencer handles every handles the transaction from taking the transaction from the RPC to order the transaction to execute the transaction to compress the result of the transaction to send that to send the data availability to L1 and to send the the data to the prover to create a zero-knowledge proof in the case of a zero-knowledge roll up or to provide with some kind of fraud proof mechanism in the case of optimistic roll ups.

And once all this process is done in the L2 world, then we have an interaction with the L1 world. In our case, we'll be we'll always be be this will always be an Ethereum network and typically the sequencer on L2 interacts with the roll up smart contract or contracts that are deployed on L1. So, with that, let me present the first contribution, which is a taxonomy of the roll up architecture types in terms of the sequencer design.

We have identified three different sequencer architectures being the first one what we call the standalone sequencer, which is simply a single sequencer, a single trusted operator that handles everything from taking the transaction to order that to execute that to post the data availability to being responsible to send the data to the prover to create a zero-knowledge proof etc. And here we also wanted to highlight a variant, which is the high availability variant. In and in this case, instead of having a single

replica of this single sequencer we have and centralized sequencers sync synchronized all together usually behind a CDN for load balance purposes and here interestingly we have another actor which is the coordinator that is responsible to handle the synchronization between the the replicas and to decide which which replica is the active one at any given moment for instance. The second architecture pipeline sequencer.

In this case we have splitted this single all powerful sequencer into different actors. We have a sequencer that takes the transactions and order them. We have an entity that is only responsible for generating the trace. We have a conflator that usually compresses the result and the conflator sends that to the coordinator that is responsible for approver or a set of provers to generate the proofs. With that what we want it decouples the transaction latency from the proof latency in the sense that we have near instance near instance of confirmation because if you rely in this

set of actors usually centralized actors then you can have near near instance of confirmation and you can start you can continue right away presenting placing transactions on top of non settled transactions on L1. The last architecture distributed sequencer. And here we have a committee of any independent sequencers that are running some kind of coordination via Byzantine fault tolerant consensus mechanism or proof of stake rotation.

What's cool about that is that since we have N independent sequencers, we are more resilient against liveness attacks since we don't have we don't rely on us on a single operator for the liveness of L2. Well, having said that, let's move to the second contribution, which is about the security analysis of all the attacks that we thought that are possible from a network point of view uh given these architectures that I just presented.

Um for the attacks, we have classified them on three different phases, okay? The first phase is attacks that may be happening before the transaction submission. This only involves typically the L2 user and the relayers. So, attacks here will be tightly related to RPC access, RPC censorship, and this kind of attacks. The second is during the transaction processing.

Here, depending on the architecture that we have of those of the sequencer, we have different kind of attacks. And lastly, we have attacks that may be possible after the batch is submitted to L1. So, here you can see the summary table of what we have found. And let me go slowly over this table. The first column is the phase: before the transaction, during the transaction, or before the processing, during the processing, after the processing.

The second column corresponds to the threat or the network attack that we consider possible. And here, at the end, we have three different columns. Um SA stands for standalone architecture, PL for pipeline, and DS for distributed. And a black dot means that this attack is directly applicable in this case. A partially filled dot means that this attack is partially applicable, and a dash means that this attack does not make any sense in this setup.

With that, for attacks before the processing, as I said, we have attacks related to the RPC availability and censorship. If an actor, a malicious actor, is trying to censor censor your access to the RPC, and you have a single standalone sequencer or a pipeline sequencer, you most probably are in are in trouble because since you are really centralized and you don't have that many inputs to to access the input routes to access the the rollup, then you might be in trouble.

However, on the decent on the distributed sequencer, since you are starting to be decentralized, if you are decentralized enough in the sense that you don't have maybe eight 12 nodes, but you have thousand of nodes and sequencers that are synced and talking together, it may be unfeasible to hijack and to well, flood or RPC attack all these nodes at the same time. The case of routing attacks, either BGP hijacking or packet dropping, this is something that if you are targeted in this way, your script, you cannot do anything

on any case. This is something that applies across the board on all the architecture sequencers. Regarding the during phase. Uh flooding and resource exhaustion. This is a particular kind of attack that consists of uh either a spamming relentlessly the network and or sending a particular kind of transaction, especially on CK rollups, that are known to uh hijack to be able to hijack the rollup.

In this case, if you're running a standalone sequencer of or a pipeline sequencer, you most probably will be able to halt the network, but if you have a distributed sequencer, then even uh in the case that you can flood uh most of them, maybe you won't be able to uh halt the network. Or in the case in the ideal case that uh you are having a distributed sequencer with different kind of clients, maybe even different kind of implementations, maybe uh transaction that hijacks the implementation in Python doesn't doesn't hijack or halts the the implementation in Rust, which could be really cool in this case.

For the high availability um particular case, we have since we have another actor, if you remember, you have a coordinator, you have another attack vector, which is uh the replica divergence and coordination compromise. So, instead of attacking the all n uh replicas of the single sequencer, you can try to attack the coordinator. So, if the coordinator is malicious or is down or is not responsive, you can uh halt the network effectively. On the pipeline uh on and and only in this particular case, the we we can also consider or we can

also find that we have an estate overload and proper saturation because even though the pipeline you have this kind of fast finality and well near near instance of finality at the end of the day it is a cascade uh system in the sense that if you had if you are able to bring to a halt um an actor inside the chain you will have the whole chain because you don't have any other road to road the transaction. And on the distributed uh sequencers we have a new kind of attack which can be consensus disruption and partitioning which

uh would mean that if you for instance can try to perform a civil attack over overtaking the control of the network and causing consensus disruption and partitioning of the network. And uh on regarding after the transaction after the processing phase uh we have studied a post the possibility of instead of instead of attacking the L2 network you can attack the L1 network by flooding the blob market which is related to EP 4844. So here instead of attacking the sequencers you don't have

anything to do with the sequencers. What you're trying to do here is to flood uh the blob market uh directly so you are effectively attacking the L2 because L2s rely on this kind of blob market to post the data availability cheaply. So that's uh all the contributions that we have for this article and let me present the conclusions. So, we have proposed a taxonomy of the Ethereum roll-up architectures based on the sequencer design, and we have found three different architectures: standalone with the high-availability variant, pipeline, and distributed.

We have mapped attack surfaces across these three phases on of the transaction workflow, and with together with the taxonomy of the first contribution, we have found that no single architecture simultaneously optimizes through throughput decentralization and resilience. And we have we have also found that centralized design dominate today because they are simple and more performant, but they come at the significant liveness and censorship risks.

And we also found that distributed sequencers are promising, but face practical challenges in consensus design, in incentive in implementing the correct incentives to promote good behavior and MEV. So, security of L2s, and in particular some roll-ups, is still a largely open problem with high real-world stakes. That's all from my side. Thank you for your attention and happy to take questions.

>> [music]