Where to Place Your TEE? In Search of a Censorship-Resilient Design for Rollup Sequencers

Blockchain networks provide decentralized trust by replicating an immutable ledger of transaction blocks. Transactions sent by users propagate through the network and are kept by nodes in a mempool. A consensus algorithm selects nodes to propose new blocks. Blocks are assembled from mempool transactions to maximise producer profit, sometimes through advanced strategies known as maximum extractable value (MEV) [37]. Proposed blocks are then broadcast, validated, and appended to the blockchain.

Ethereum reshaped the blockchain landscape by introducing general-purpose smart contracts. These are small programs, where functions that change the system state are triggered by transactions. This enabled a variety of decentralised applications. The growing popularity of Ethereum caused congestion and rising operational costs. This led to the development of layer 2 (L2) networks designed to enhance scalability [23]. The most prominent L2 solutions are rollups [32, 14, 27]. These networks operate as separate blockchains with their own ledgers and state. They provide a decentralised trust anchor by sharing transaction data and committing L2 state roots through contracts on the main Ethereum network (L1).

A central component of rollups is the sequencer, responsible for ordering and executing transactions and forming L2 blocks. In most rollups, the sequencer is implemented as a centralised component that maintains a private mempool of transactions. This centralisation provides a good user experience by offering low transaction confirmation latencies at the L2 network level. However, this design is detrimental to the core purpose of provisioning decentralised trust. Centralised sequencers still provide safety guarantees, such as the immutability of the block’s content and the legitimacy of state changes. However, centralisation can also impact liveness as it enables sequencers to censor transactions by manipulating their inclusion and ordering in L2 blocks. Other downsides of the centralised sequencer design are its vulnerability as a single point of failure and the concentration of economic power by acting as a single MEV beneficiary in the network.

In this work, we focus on L2 censorship and show that it can take various forms. Censorship can span from the simple exclusion of a transaction from a block to more nuanced variations. The sequencer can take advantage of its private mempool view to perform stealthy reordering of transactions. Within this context, we remark the absence of a formal setting able to capture the possible censorship actions, and in particular the interaction with the mempool.

Trusted Execution Environments (TEEs) are often used to provide integrity guarantees in potentially adversarial settings, making them well-suited to mitigating L2 censorship. TEEs are implemented in processor hardware to offer a secure, isolated area for executing code and loading data into an encrypted memory space at runtime. Integrating TEEs with rollups allows specific components and operations to use authenticated code, ensuring the integrity of produced information and averting censorship actions. However, determining which parts of a rollup should leverage TEEs remains a challenge.

We differentiate between censorship resistance and censorship resilience, as considered also in the context of L1 by previous work [34]. In the censorship resistance case, the system design denies censorship attempts altogether. In the censorship resilience case, while the system design may allow censorship attempts, it can detect and counter these attempts. Simply running a centralised monolithic sequencer within a TEE primarily ensures censorship resistance. While resistance might seem stronger, it is a more rigid property of a design and can be suppressed by shutting down the TEE by a malevolent owner. Obtaining fine-grained information about censorship attempts enables the system to respond specifically by applying punitive measures proportionate to the offense; for instance, treating an excluded vote differently from a delayed currency exchange. Such observability fosters censorship resilience in the design and is also influential for a competitive market environment, where rollup implementations may adopt distinct reputation systems. In our work, we show that integrating TEEs at precise places in the architecture facilitates this observability property.

Furthermore, Proposer-Builder Separation (PBS) is one alternative to the monolithic sequencer design, which introduces a new dimension in addressing censorship. Adopted by Ethereum L1 [22], PBS decouples block proposal from construction: distinct proposer and builder nodes handle these roles, with proposers selecting the most profitable block via relays without prior knowledge of included transactions. While the primary purpose of PBS on L1 is decoupling the costly operation of block preparation and creating a competitive block building market [26, 7, 36], it also influences the blockchain’s resilience to censorship, by preventing proposers from censoring specific transactions from the mempool. Yet, some authors criticise PBS as mostly shifting the censoring capability to builders and relays [22, 34]. We note that L1 PBS was integrated into an already decentralized setting, with blocks produced by numerous validator nodes [31], far exceeding the number of active builders [22].

L2 rollups provide a centralised setting, with a single sequencer producing each block. Here, PBS expands the builder set, offering the context to increase protection against an untrusted sequencer. While recent L2 PBS works [18, 11, 21] focus on scalability and MEV distribution, anti-censorship has not been systematically studied. Notably, from the perspective of censorship resilience, PBS expands the places in the system where TEEs can be integrated. To date, Rollup Boost [18] is the only L2 PBS in production that uses TEEs.

Our work is set in the context of Ethereum rollups and leverages the security provided by trusted execution environments (TEEs). In this section, we first elaborate on the generic architecture of a rollup network. Then, we present the principles of TEEs and the guarantees they provide that matter for the design of censorship-resistant and censorship-resilient rollups.

In this section, we describe in detail the threat model and the analysis context specific to a rollup operation. First, we introduce several notations that we use in the paper. Then, we identify and define a set of possible censorship actions. We further define a censorship observability property that a rollup design may or may not offer. Afterwards, we identify the possible censorship vectors. We follow by describing several generic facts that apply in our model and can be considered in the analysis of sequencer designs. Finally, we formulate some general security assumptions.

We consider the mempool private to a node, sequencer or builder, which constructs a block. We note that multiple builders are essentially part of a competitive market. While some part of the mempool can be shared, builders can receive transactions via a private order flow, resulting in distinct mempool views.

In this section, we present several generic variations of sequencer designs: some monolithic (non-PBS) and others that obtain blocks from a separate builder (PBS). In a distributed setting with multiple builders, a variation is how blocks (and therefore, the providing builder) are selected at runtime. Typical selection algorithms simply choose the most profitable blocks. This diminishes the impact on preventing censorship provided by running a distributed builder set, irrespective of the percentages of honest and malicious builders. As long as a malicious builder censors transactions and prioritises a block to be picked by the sequencer, the difference is made by anti-censorship measures included by the builder and sequencer designs. In these designs, we find that TEEs play a fundamental role. Therefore, we focus on the sequencer-builder interaction, representative for the analysis of the censorship actions considered in Section 3. We start from the typical nonsecured monolithic sequencer, and we advance through several designs up to a novel variant that we propose in Section 5.

In this section, we introduce a novel variation for a TEE-integrating PBS design, where, at the builder side, we restrict the TEE protection to the ordering only.

In this section, we complement our design analysis with insights into their differences. Table 1 summarizes the possible censorship actions and observability in analysed designs. For designs where both sequencer and builder may produce blocks, we only cover builder-produced blocks variation in the table. The variant of sequencer blocks in these designs serves only as a failsafe.

We know from previous work [34, 22] that PBS without using TEEs can be prone to censorship at different stages of the block building flow, as observed in L1. On the other hand, using TEEs without PBS to provide trust in the sequencer’s logic can still be subject to sequencer failures and downtime, which are often documented in practice [19, 3, 33], leading to indistinguishable effects from transaction censorship. Therefore, we find that a mixture of TEEs with PBS is appropriate in deterring censorship in generic L2 rollup architectures.

By running the sequencer within a TEE or using PBS with TEEs, where the builder is run entirely within the secured space, the designs mainly obtain censorship-resistance. While this arguably seems the best outcome in terms of security, a malicious builder could simply shut down the TEE [35], e.g., after observing information that could lead to this decision from the prior blocks. Deciding on builders accountability for such actions and applying penalties is limited, as shutdowns are indistinguishable from censorship and other failures. This indistinguishability is strengthened by the fact that in typical L2 rollups escape hatches are designed to address both failures and censorship without distinction [20, 17, 9, 2].

Achieving censorship resilience requires precise observability of actions. Identifying censorship at transaction granularity, essentially CObs, enables resubmission of censored transactions, though without guaranteeing they will not be censored again.

Linking CObs to the particular block where transaction censorship occurs is a powerful result, since the block producer can be held accountable for the censorship action, e.g., penalised and potentially excluded temporarily from block production. In our centralised rollup setting, this is of importance in PBS designs, in the context of multiple builders.

To our knowledge, our work is the first to provide a thorough analysis of the possible censorship actions in the centralised L2 context, capturing the censoring entity’s interaction with the mempool. With respect to defining censorship, Wahrstätter et al.[34] differentiate at a simplified higher level between strict and weak censorship in the context of L1, where the first represents transaction exclusion and the latter transaction delaying. In particular, [34] does not take into account the mempool view of the censor and does not consider specific ordering nuances on delaying, as we do. This latter issue is further discussed in Appendix A.3.

Chaliasos et al. [13] takes a formal approach at addressing censorship in zk-rollups, using Alloy, a declarative modelling language. This focuses on the use of escape hatch smart contract mechanisms via L1 and not on addressing censorship in L2 at the sequencer operations level. Koegl et al. [25] discuss the case when the state proposer could be independent of the sequencer and refuse to consider transactions effect in the state submitted to L1. The authors conclude as we do in §3 that this would fail due to typical rollup validations.

Rollup Boost [18] is the only sequencer solution that we are aware of, which combines the use of TEEs with PBS, deployed in practice, for the Unichain rollup [11]. It uses the non-TEE sequencer and TEE-enabled builder design described in §4 to ensure verifiable priority ordering of transactions, but assumes the sequencer to be trusted. The implementation focus is on performance, producing high frequency partial blocks for fast confirmation.

Li [28] proposes a fairness solution for L1, where each node operates a TEE secured mempool, focused on maintaining a verifiable ordering predicate. However, the solution does not use a separate lightweight TEE-secured mempool component, as in our proposed design. It requires access to the complete blockchain state and implies a preliminary trusted broadcast of the transaction to accept it into the node’s mempool.

Other solutions that address the L2 sequencer censorship resort to variants of distributed protocols, assuming a trusted peers quorum. TeeRollup [35] proposes a network of sequencers, implemented using different TEEs. This represents a replicated variation of the TEE-enabled monolithic sequencer design. The motivation is to tolerate TEE corruption, including intentional crashing. This illustrates the rigidity of a design where the entire sequencer operates within the TEE. The system does not differentiate censorship actions, using a generic slashing mechanism. To our knowledge, we are the first to propose a solution that leverages TEEs at a finer granularity, resulting in precise observability of censorship details.

Han et al. [21], propose an L1 PBS based shared sequencer for multiple rollups, which uses weighted leader election to reduce the censoring builders selection probability. Capretto et al. [12] propose decentralising the sequencer by using a protocol based on Setchain, a decentralised Byzantine fault tolerant (BFT) data structure for grow-only sets. The solution combines a sequencer node with a data availability service and prevents censorship under BFT, assuming fewer than one-third of nodes are malicious. Motepalli et al. [30] provide a SoK that explores decentralised sequencer designs, including censorship prevention as a desirable property and referring to BFT solutions for ordering guarantees and block proposer selection. While our work is set in the dominant centralised sequencer context, we consider it complementary to the decentralised approaches. These could benefit from a lightweight TEE-enabled ordering component adapted from our design to enhance censorship resilience.

Sequencers are the primary component of rollup networks, their usual centralised implementation posing inherent censorship risks. Our work addresses this issue by leveraging TEEs. We first introduce a formal setting to capture precise censorship actions that a sequencer could exert on its private mempool. We highlight the importance of observing these actions for providing censorship resilience. We then explore TEE integration with PBS in rollups, which delegates block construction to a larger set of builder peers than the single sequencer. Using our formal framework, we analyse designs with TEEs in different spots of the PBS setting. Although integrating full node functionality with TEEs offers censorship resistance, we find this approach too rigid to observe fine-grained details of censorship attempts, like the censored transaction, the blocks where it was censored or the censoring action. In a dynamic market environment, adversarial by nature, these details can be used to apply tailored penalties and build a reputation system that promotes a robust service.

To this end, we propose a novel design which confines TEE use to protect just the ordering component in the block building process. We rigorously prove that this permits identifying a censored transaction, linking it with a specific censorship action, and to the block where the censorship occurred, directly pointing to the block creator as the censor. Although our current contribution focuses on having a solid theoretical ground, we did not ignore the practical dimension. We already took into account limiting the TEE’s TCB, by restricting an initial transaction validation, and covered this in our formal proofs. although this would require a more solid probabilistic analysis. As future work, we intend to implement a prototype of the design proposed here, specifically validating it against off-the-shelf TEE technology (i.e., Intel TDX or SGX) and further to perform comparisons with other implementations using similar TEEs (e.g., Rollup Boost).