Empirical Analysis of TEE-Enabled Rollup Designs

Empirical Analysis of TEE-Enabled Rollup Designs Claudiu-Nicu Bărbieru Corentin Libert Alexandru Ioan Cuza University UCLouvain Iaşi, Romania Louvain-la-Neuve, Belgium claudiu.barbieru@gmail.com corentin.libert@uclouvain.be Matthieu Bettinger UCLouvain Louvain-la-Neuve, Belgium matthieu.bettinger@uclouvain.be

Peterson Yuhala Andrei Arusoaie The University of British Columbia Alexandru Ioan Cuza University Vancouver, BC, Canada Iaşi, Romania pyuhala@cs.ubc.ca andrei.arusoaie@uaic.ro

Oana-Otilia Captarencu Alexandru Ioan Cuza University Iaşi, Romania oana.captarencu@info.uaic.ro

Etienne Rivière UCLouvain Louvain-la-Neuve, Belgium etienne.riviere@uclouvain.be

Pascal Felber University of Neuchâtel Neuchâtel, Switzerland pascal.felber@unine.ch

Emanuel Onica Alexandru Ioan Cuza University Iaşi, Romania emanuel.onica@uaic.ro

Valerio Schiavoni University of Neuchâtel Neuchâtel, Switzerland valerio.schiavoni@unine.ch

much computation as possible off-chain, aggregating blocks of transactions into batches that are then submitted to L1 to inherit its decentralized-consensus guarantees. A central component of a rollup is the sequencer [5], which orders and executes transactions and assembles them into L2 blocks. These blocks are compressed, batched, and posted to the underlying L1 blockchain by a batcher component, which is sometimes integrated with the sequencer. In most existing rollups, the sequencer is run by a single administrative entity, e.g., The Optimism Foundation [6] or Arbitrum [7]. This centralization introduces risks of censorship [8]. Blockchains are increasingly used beyond decentralized finance, including in e-government [9] and supply chain management [10]. Transaction censorship can therefore severely affect the safety of such applications: censored orders can disrupt financial exchanges, dropped votes can corrupt electronic polling, and missing shipment registrations can alter supply pipelines. Beyond directly blocking transactions to or from specific parties, sequencers may also act for financial gain by launching frontrunning attacks [11] or manipulating transaction ordering to extract profit, known as maximum extractable value (MEV) [12]. Proposer–builder separation (PBS) [8], [13] emerged as a solution to mitigate the security and scalability challenges in L1 by separating block construction (performed by builders) from block validation (performed by proposers). MEV-Boost [14], I. I NTRODUCTION Ethereum L1’s dominant PBS implementation, enables a Ethereum [1] is a widely popular blockchain, the first to competitive builder market that allows builders to capture MEV support rich applications beyond simple financial transactions. transparently. Builders compete to assemble high-quality blocks Its core technology, the Ethereum Virtual Machine (EVM), is that maximize MEV and priority fees legitimately, retaining now used by more than 40 other blockchains [2]. The Ethereum the surplus after bidding to proposers, while proposers earn Mainnet, also known as the Layer-1 (L1) Ethereum network, revenue from builder bids in addition to staking rewards. has faced scalability limitations in recent years, primarily due to Looking ahead, an L2 builder market is envisioned as a rising transaction processing loads, which affect throughput and possible future direction that could reduce the censorship power finality [3]. To address these limitations, Layer-2 (L2) chains, currently concentrated in sequencers. However, today’s rollup and in particular rollups [4], have emerged as the primary deployments remain far from this model: they do not expose scaling solution for Ethereum. Rollups seek to perform as an L1-style PBS mechanism with an open, competitive builder

Abstract—Layer 2 (L2) rollups have become the dominant scaling solution in Ethereum. At the core of these systems lies the rollup sequencer, a component that orders, executes, and submits L2 transaction blocks to the main Ethereum blockchain. The centralization of this sequencer introduces security risks, including censorship and malicious manipulation of transactions to extract maximum extractable value (MEV). Trusted execution environments (TEEs) provide strong hardwareenforced confidentiality and integrity guarantees for code and data. TEEs are strong candidates for strengthening security and ensuring verifiable neutrality in rollup sequencer operations, but multiple TEE-based designs are possible, offering different tradeoffs among modularity, performance, and security guarantees. Among them, the separation of proposer and builder logic (PBS) into independent services is a strong contender against the monolithic approach that bundles all sequencer logic. Despite several proposed theoretical frameworks, there is a lack of experimental evaluation of the practicality and security tradeoffs of integrating TEEs into rollup sequencers. This work addresses this gap through a comprehensive empirical study of TEE-enabled rollup designs under both PBS and monolithic sequencer models. Our experimental evaluations show that the impact of TEEs on rollup performance is small and that PBS does not significantly amplify it. We also show that PBS can lead to significant performance improvements by enabling more specialized, efficient builder logic implementations. Index Terms—Layer-2 blockchains, Rollups, Performance, Trusted Execution Environments, Censorship

market. What has been adopted so far, following the Rollup II. BACKGROUND Boost proposal [15], is a limited 1-to-1 sequencer–builder In what follows, we provide details on the major rollup separation in several rollups [16]–[18]. In this configuration, categories, elaborate on the centralized state of PBS in L2, and the sequencer remains logically centralized, while a single summarize the different types of TEEs. builder is used de facto to support performance-oriented functionality, such as precomputing partial blocks (flashblocks) A. L2 rollups and leveraging faster modular implementations [19]. Thus, Rollups are categorized into ZK-rollups and optimistic rollups current L2 deployments should be understood as PBS-inspired based on the transaction validity verification mechanism. ZKarchitectures rather than as fully fledged PBS implementations rollups submit zero-knowledge proofs to the L1 layer attesting with an open or competitive builder market. to the correctness of transaction execution. Instead, optimistic While PBS may, in the future, support fairer MEV distribu- rollups, assume L2 blocks to be correct by default, relying tion, stronger decentralization, and improved performance in L2 on a deferred fraud-proof mechanism to detect invalid states systems, in the current 1-to-1 setting, the relevant censorship resulting from execution. In the general case, when no dispute risks are essentially transferred from the sequencer to the occurs, the optimistic approach yields lower costs and faster builder side [8], thereby preserving similar safety concerns. soft confirmation times for transactions (pending finality after Trusted execution environments (TEEs) are hardware-based the fraud-proof interval) compared to ZK-rollups. Consequently, mechanisms ensuring code and data confidentiality and integrity optimistic rollups dominate in terms of transacted volume [2]. during execution. Notable examples include Intel Software In most rollups, either optimistic or ZK-based, the seGuard Extensions (SGX) [20], Intel Trust Domain Exten- quencer [5] is a centralized component. This maintains a private sions (TDX) [21], and AMD Secure Encrypted Virtualization memory pool (i.e., mempool for short) of user transactions, (SEV) [22]. These TEEs provide attestation capabilities [23], ordering, executing, and including them in L2 blocks, which allowing remote parties to verify the executing code and are further compressed in batches submitted to L1. authenticate the underlying hardware. This enables verifying B. Proposer-builder separation in L2 if a block builder’s code complies with stated ordering rules, The current prevalent use of a centralized sequencer in thereby averting censorship by malicious nodes. rollups undermines the decentralization principle of blockchain Prior work explored TEE-enforced transaction ordering systems and allows the sequencer to engage in censorship in L1 [24] or TEE-enabled sequencer networks in L2 [25]. practices, for economic reasons, e.g., unregulated MEV extracHowever, we lack a thorough analysis of the performance tion [12], or political/regulatory reasons [29]. Besides tampering implications of integrating VM-level TEEs into PBS-based L2 with legitimate block building, a monolithic sequencer is also designs that have gained traction in production [16]–[18]. We a potential single point of failure and performance bottleneck. present the first experimental study of such TEE-enabled rollup Proposer-builder separation (PBS) [13] is a design paradigm designs in both PBS and non-PBS settings. Our evaluations first adopted in L1 networks [14] to mitigate such issues, with VM-based TEEs show that their performance impact is accounting for the vast majority of blocks on Ethereum (≈ small for lightweight ERC-20 [26] based workloads, the most 90% [8]). In contrast, PBS is not currently implemented in L2 implemented Ethereum token for fungible assets, with more rollups in the same sense as in L1. Existing rollup deployments than 1.7M tracked instances [27] and close to 2 billion trades experiment with a limited form of separation in which a single executed between 2015 and 2024 [28]. builder is used de facto alongside the sequencer [16]–[18]. Overall, our key findings include the following: This PBS approach in L2 separates block construction, 1) VM-based TEEs have a negligible impact on transaction including transaction ordering, from the other operations, such time to inclusion in both PBS and non-PBS designs; as block compression and batching, rollup state root derivation 2) PBS enables more specialized, efficient block builders with following the new block, ZK-proof computation for ZK-rollups, significant performance gains over a monolithic sequencer; and posting these results to L1. Depending on the rollup 3) TEEs increase CPU usage by about 17% and 25% for architecture, some of these tasks are either still performed by non-PBS and PBS setups, mainly due to hardware-based the sequencer or are delegated to other nodes. As in L1 [24], cryptographic operations in TEEs; nonetheless, transaction ordering into blocks is delegated to 4) In PBS settings, communicating with an external builder a builder, as it is highly sensitive to censorship and requires increases CPU usage for block construction; protection [15], [30]. For this reason, deployed PBS rollup 5) RAM utilization is largely dominated by the block builder implementations [16]–[18] adopt the Rollup Boost [15] design, implementation rather than PBS and TEE usage. in which the builder operates the mempool, ordering logic, Roadmap. We structure our paper as follows. Section II and execution engine within a TEE. The foreseen L2 PBS discusses background concepts like L2 rollups, PBS and TEEs. roadmap includes legitimate MEV pipelines similar to L1, and Section III explores the rollup designs our paper focuses on, further decentralization to multiple builders [15]. However, at while Section IV presents our empirical evaluation of these the time of writing, these implementations adopt only a 1-to-1 designs and provides useful takeaways. Section V discusses separation between the sequencer and the builder, focusing related work, and Section VI concludes our paper. mainly on optimizing builder performance [19].

Check & store transactions

Transaction or der ing & block creation

Validate block & update L2 chain

designers of zk-rollups, as it focuses on securing the operational integrity of the private mempool, which is centralized in the majority of optimistic rollups and in many zk-rollups. We consider two categories of systems: monolithic sequencer designs that do not use PBS, and PBS-based designs that use external block builders for block construction. Fig. 1 provides a high-level description of TEE-enabled rollup designs. A. Threat model

We consider a rollup design, where the mempool is private to a node in charge of constructing L2 blocks (i.e., a builder or sequencer). Each node has control over the full software stack, including the OS, hypervisor, and hardware (e.g., DRAM, secondary storage, etc.). An adversarial node could aim to Fig. 1: L2 rollup designs with and without PBS. In a PBS design, engage in (dishonest) censorship actions such as strategically orthe builder can be run within a TEE for censorship resistance. dering, including, excluding, or frontrunning client transactions that are present in the mempool. In short, the node privately We set our practical experience report in this logically operating the transaction mempool is capable of and interested centralized, albeit modular setting, currently met in production in arbitrary changes to the mempool content, deviating from environments. Despite the gap towards a truly decentralized publicly agreed-upon transaction ordering criteria within and context, this builder separation facilitates a first step in enhanc- across blocks. For further analysis of censorship actions, we ing the performance of a censorship-resistant implementation. refer the reader to the formal definitions of Arusoaie et al. [30]. C. Trusted execution environments Assumptions. We assume that a TEE-enabled sequencer or A TEE enables code to be executed in isolation from its builder is pre-attested before sending transactions, using TEEoperating environment. It provides confidentiality of runtime specific attestation mechanisms. We also assume an adversary data, and integrity, ensuring code and data cannot be tampered cannot physically open and manipulate the TEE-enabled with, not even by privileged software like the OS or hypervisor. processor package, and that the TEE (e.g., enclave or VM) code This is backed by remote attestation of the underlying hardware does not intentionally leak sensitive data. Denial-of-service and code integrity. In the context of L2 rollups, a TEE can and side-channel attacks are considered out of scope. ensure that the underlying algorithms, e.g., transaction ordering B. Non-PBS designs and block-building logic, adhere to predefined rules. Here, we consider a monolithic sequencer that may or may TEE technologies generally fall into two categories: process- not be TEE-enabled. In the non-TEE architecture (assumed as level isolation, where a portion of a process’s memory is the baseline), the sequencer can exclude, reorder, or include protected at runtime (Intel SGX [20]), or virtual machine transactions in the private mempool, altering the produced (VM)-level isolation, where an entire VM is protected for its blocks. A TEE-enabled sequencer cannot perform these aclifetime (Intel TDX [21], and AMD SEV [22]). VM-based tions, because clients cryptographically verify the mempool TEEs mitigate the performance and usability issues associated management and ordering code via remote attestation. with process-level TEE, but lead to a larger trusted computing base (TCB), i.e., the set of software and hardware that must C. Designs with PBS be trusted. Current L2 rollups rely on Intel TDX for protection In PBS designs, separate nodes handle the block-building and through the Rollup Boost implementation [15]. All TEEs can -proposing logic: the block builder and the sequencer (acting introduce variable overheads to protected processes. as the block proposer). We consider two cases: one where the builder runs inside a TEE, preventing tampering with mempool III. TEE- ENABLED ROLLUP DESIGNS operations and transaction ordering [30], and exporting blocks Our objective is to identify the performance and security that can be integrity-checked; and one where the builder does tradeoffs in TEE-enabled rollup designs, whether or not based not run inside a TEE, thus allowing such tampering. on PBS. Independent and systematic measurements of these IV. E VALUATION tradeoffs are lacking in the scientific literature. We now The evaluation seeks to answer the following questions: systematically detail these designs. RQ-1: What is the impact of PBS on metrics such as We choose to target optimistic rollups, the dominant rollup transaction time to inclusion (TTI), i.e., time from category by usage and transaction volume [2]. The only submission until inclusion in an L2 block? (§IV-C) production-ready PBS approach, currently deployed in L2 RQ-2: What is the impact of TEEs on the above metrics with systems, is Rollup Boost. It integrates with OP Stack, the and without a PBS configuration? (§IV-C) leading framework for implementing optimistic rollups, making RQ-3: How does CPU utilization (§IV-D) and RAM (§IV-E) the study of optimistic rollups more immediately relevant resource consumption vary across the different designs? to practitioners. Nonetheless, our study is also of interest to

A. Evaluation setup

that op-rbuilder is the external builder used for the corresponding PBS setting (e.g., “PBS-TEE-rb”). Otherwise, the builder implementation is op-geth (same as used in the monolithic sequencer setting). In addition to L2 chain metrics, we measure system-level metrics such as CPU usage and RAM usage of the block builders in all setups, collected with Prometheus.

We emulate a full Optimism rollup network on top of an emulated Ethereum node acting as the L1 chain. The setup is based on Flashbots Builder Playground [31], an opensource framework for deploying full blockchain testing environments, that we adapted for Kubernetes compatibility. Builder Playground provides PBS support via Rollup-Boost [15], a C. Impact of PBS and TEEs on L2 performance middleware component that enables the rollup sequencer to We start by observing in Fig. 2 the distribution of TTIs outsource block construction to an external block builder. (i.e., time to inclusion). The plots depict the results obtained We use a Kubernetes cluster with 4 VM nodes on a host with an ERC-20 workload at 30 and 210 TPS, running for 10 server. The VM host server has a single-socket 16-core Intel(R) minutes. The Uniswap workload provided highly similar results. Xeon(R) Gold 5515+ CPU clocked at 2.70GHz with Intel TDX The main difference in our tests was inflicted by the type of support, and uses the KVM hypervisor. The VMs, running builder used. We observe in all runs that use op-geth, that the Ubuntu 24.04 LTS, have 4 vCPUs and 4GB of memory each, time-to-inclusion of transactions is near-identical for both the and one of them is TDX-enabled. We distribute the work using node affinity rules as follows: one node for metrics collection non-PBS and PBS variants, regardless of whether TEEs are and load injector, sequencer components on a second node, used or not. Similarly, we do not observe a significant effect and the external builder on the third or fourth node, depending of TEE in the tests run with op-rbuilder. The very small TTI overhead introduced by VM-based on whether the TEE is enabled or not. TEEs reflects the results in [35], which evaluates both TDX B. Evaluation methodology and SGX. That work implies that the impact of TEEs on We benchmark the different blockchain designs with Con- operational performance is generally small for CPU-intensive tender [32], a high-performance transaction generator developed workloads. In contrast, highly I/O-intensive operations tend by Flashbots. Contender generates large volumes of transactions to incur higher overhead due to TEE-related context switches. from a client VM towards the blockchain’s RPC endpoint Block building in the studied L2 chain setup is predominantly and measures various metrics, including TTI. We evaluate CPU-intensive, with comparatively limited I/O. This explains the different designs by repeatedly performing ERC-20 token the minimal performance impact of Intel TDX on the blocktransfer [26] transactions from a set of test pre-funded building operation and, hence, on TTI, in our experiments. accounts to a random recipient address. ERC-20 transactions are among the most common in Ethereum blockchains [28]. Take-away 1 : When using the same builder implementation for Additionally, we also observe the median results for simulated non-PBS and PBS designs, VM-based TEEs have a negligible loads of Uniswap transactions. Uniswap is currently the most- impact on transaction time to inclusion. This is mainly because deployed decentralized exchange protocol, enabling trading of block building is CPU-intensive, incurring minimal overhead ERC-20 tokens, with a presence on 44 chains and 747 forks when run in a VM-based TEE. for Uniswap V2 [33]. We provide results for both low (30, 90) Regarding PBS, given that the external builder runs on a and high (210, 270) input transaction-per-second (TPS) levels. VM on the same host, network latency’s impact is small. In We note that the daily average volume in real-world layer-2 a real-world PBS setting, the external builder will typically rollups such as Optimism is in the range of 20 to 30 TPS. be on a separate node, leading to higher network latency. The With monolithic sequencer configurations, we use Opti- latter is expected to increase the TTI of transactions in blocks. mism’s reference builder implementation for the L2 stack However, we also observe that when op-rbuilder is used as (op-geth) [34]. For the PBS setups, we use op-geth as an the external builder in PBS settings, the TTI is twice as fast as external builder connected to the L2 stack through Rollupin PBS setups using op-geth. We attribute these performance Boost. We also evaluate our PBS designs with op-rbuilder [19], differences primarily to the architectural and implementation Flashbots’ block builder implementation for the L2 stack. This differences between the two builder implementations op-geth allows us to evaluate PBS performance across different builder and op-rbuilder. On the one hand, op-rbuilder is a lightweight implementations. All our PBS designs use a single external and more specialized Rust-based block builder comprising builder, which, to our knowledge, is the common practice in ≈ 14K lines of code (LoC). On the other hand, op-geth is deployments using Rollup Boost as of the date of writing. a significantly more complex Go-based system comprising In our evaluations, we adopt the following naming: ≈ 352K LoC. In addition to block building, op-geth also 1) Monolithic sequencer without a TEE: noPBS-noTEE participates in block validation. 2) Monolithic sequencer running in a TEE: noPBS-TEE Take-away 2 : PBS enables the use of more specialized and 3) PBS with a non-TEE enabled builder: PBS-noTEE efficient block builder implementations, which can lead to 4) PBS with a TEE-enabled builder: PBS-TEE PBS systems are further compared with respect to the significant performance improvements when compared to a integrated builder implementation: the suffix “-rb” indicates monolithic sequencer setting.

30 TPS 140

noPBS−noTEE noPBS−TEE PBS−noTEE

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

100 80 60 40

noPBS−noTEE noPBS−TEE PBS−noTEE

120

Included Txs (%)

Included Txs (%)

120

210 TPS 140

20

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

100 80 60 40 20

0

0 0

500 1000 1500 2000 2500 3000 3500 4000 4500

TTI (ms)

0

500 1000 1500 2000 2500 3000 3500 4000 4500

TTI (ms)

Fig. 2: Cumulative distribution function (CDF) of Tx TTI for different TPS values using ERC-20 workload. We note the almost-overlapping results for each of the two builders, op-geth (the first four lines in the legend) and op-rbuilder (the last two lines with the -rb suffix).

This increase can be attributed to the additional network communication introduced by PBS, in which transactions must We now look at the impact of the different designs on CPU be forwarded to an external builder. Handling these extra utilization. The top plots in Fig. 3 depict the CPU usage for network interactions adds computational work for the node, the components involved in block building in both PBS and thereby increasing overall CPU usage. This overhead becomes non-PBS settings, with and without TEEs, under ERC-20 load. dominant once the processing stabilises with the incoming The results for the Uniswap workload are presented in Fig. 4. transactions, reaching a plateau. In a brief initial part of the tests We observe that CPU usage increases in TEE-based setups interval, it can be observed that the non-PBS CPU utilization compared to non-TEE settings. For example, with a load of is generally higher due to the concentration of processing logic 210 TPS, noPBS-TEE uses about 16.7% more CPU compared in the monolithical setting. to noPBS-noTEE, while PBS-TEE uses approximately 25.3% more CPU compared to PBS-noTEE. We observe a similar Take-away 4 : In PBS settings, the required network commutrend for the 270 TPS Uniswap workload, albeit more stable nication with an external builder increases CPU utilization in the first part of the interval. We believe this variation by the components responsible for block construction. stems from differences in the processing logic of the two types of transactions in the load. We attribute the higher E. Impact of PBS and TEEs on RAM utilization CPU utilization of the TEE-based designs to underlying Finally, we look at the impact on memory usage. The bottom hardware-based cryptography. In VM-based TEEs such as plots in Fig. 3 and Fig. 4 show RAM usage for the components Intel TDX, cryptographic operations, e.g., memory encryption involved in block building for lower TPS ERC-20 loads and and decryption of pages between the CPU and main memory, higher TPS Uniswap loads, respectively. incur additional processing cost. Even though block building In general, for the same builder implementation, we observe is primarily CPU-bound, some data is still copied between no clear variation in RAM usage between PBS and non-PBS memory and the processor, which requires additional CPU settings, regardless of TEE usage. This can be explained cycles for cryptographic operations. Consequently, the TEE- by the fact that all evaluated designs maintain similar inbased configurations exhibit moderately higher CPU utilization. memory data structures regardless of whether PBS or TEEs Nonetheless, this CPU usage overhead has a negligible impact are used, resulting in comparable RAM usage in the guest on TTI, as previously illustrated in Fig. 2. VM. However, we note that TEEs such as Intel TDX store D. Impact of PBS and TEEs on CPU utilization

additional cryptographic metadata in a separate memory region rather than the guest VM’s memory. Notably, for input loads of 30 TPS and 210 TPS, the RAM usage of op-rbuilder is, respectively, about 1.927× and 1.597× higher on average than that of op-geth in the PBS From Fig. 3, we also observe that under the higher ERC- setting. Again, we observe a similar tendency for the Uniswap 20 load of 210 TPS, PBS-based setups exhibit higher CPU workloads at 90 TPS and 270 TPS. We attribute this difference utilization than their non-PBS counterparts. For instance, PBS- primarily to implementation-level design differences rather than noTEE uses 10.9% more CPU than noPBS-noTEE. This CPU the programming language itself (i.e., Rust-based programs, usage trend is also observed with the Uniswap workload in e.g., op-rbuilder, generally use less memory than Go-based Fig. 4, stabilising after about 3 minutes of the tests duration. ones, e.g., op-geth). In particular, the two builders rely on Take-away 3 : TEEs increase CPU usage by about 17% and 25% for non-PBS and PBS setups, respectively. This can be attributed to the additional CPU cycles required to perform hardware-based cryptographic operations in TEEs.

CPU: 30 TPS 0.25

noPBS−noTEE noPBS−TEE PBS−noTEE

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

0.15

0.1

0.05

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

0.6

0.4

0.2

0

0

0

250

100

200

300

400

500

600

700

0

100

200

300

400

Timestamp (s)

Timestamp (s)

RAM: 30 TPS

RAM: 210 TPS

noPBS−noTEE noPBS−TEE PBS−noTEE

200

400

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

noPBS−noTEE noPBS−TEE PBS−noTEE

350

500

600

700

PBS−TEE PBS−noTEE−rb PBS−TEE−rb

300

RAM (MB)

RAM (MB)

noPBS−noTEE noPBS−TEE PBS−noTEE

0.8

CPU (millicores)

CPU (millicores)

0.2

CPU: 210 TPS 1

150

100

250 200 150 100

50

50 0

0

0

100

200

300

400

Timestamp (s)

500

600

0

100

200

300

400

500

600

700

Timestamp (s)

Fig. 3: CPU and RAM usage for block builder across different setups using ERC-20 workload (1 CPU = 1000 millicores). The suffix "-rb" indicates that the builder used is op-rbuilder; otherwise, the default builder, op-geth is used.

different internal mechanisms to manage the transaction pool, Lastly, similar to the CPU usage patterns under higher loads, cache execution state, and maintain intermediate EVM data we also observe higher RAM usage across all setups at the structures during block construction. These differences can higher input loads of 210 and 270 TPS than at the lower input affect how aggressively state or transaction data are cached loads of 30 and 90 TPS. The higher loads increase RAM in memory, resulting in higher RAM usage for op-rbuilder in usage because more transaction data is processed per unit our experiments. A detailed breakdown would require fine- time compared to the lower loads. We also note a gradual grained memory profiling of the respective implementations, increase in overall RAM consumption over time for each which we leave for future investigation. Nonetheless, the RAM executed test, more noticeable in the higher TPS runs. We usage is the same across all setups using op-rbuilder i.e., believe this is mainly caused by the increase in blockchain PBS-noTEE-rb and PBS-TEE-rb, which is consistent with size: new transactions result in new blocks and changes to the the results with op-geth and equally explained by the fact that blockchain state, which are typically kept, at least temporarily, the in-memory data structures and how much memory they in memory by implementations such as op-geth and op-rbuilder occupy in the guest VM are the same when the input load and to optimize new block additions and transaction execution. block builder implementation remain constant. We also note F. TEE Integration Discussion that TDX uses AES-XTS [36] as a symmetric block cipher for We observe that a baseline TDX integration with a block memory encryption, where the ciphertext does not expand on builder does not cause a major overall performance degradation, the plaintext size, which is in line with the observed results. favoring the use of the TEE in rollup solutions. Therefore, we Take-away 5 : RAM utilization is largely independent of discuss TEE integration aspects beyond this baseline. PBS and TEE usage and instead dominated by the block Choice of TEE. VM-based TEEs like Intel TDX and AMD builder implementation. While TDX introduces additional SEV-SNP are the growing trend in confidential computing cryptographic metadata, it resides outside the guest VM due to better usability and improved performance compared memory and does not increase the observed RAM footprint. to process-based TEEs like Intel SGX. The complexity of

CPU: 90 TPS noPBS−noTEE noPBS−TEE

PBS−noTEE PBS−TEE

CPU: 270 TPS PBS−noTEE−rb PBS−TEE−rb

1.2

0.3 0.2 0.1

PBS−noTEE−rb PBS−TEE−rb

0.8 0.6 0.4

0

0

100

200

300

400

500

600

700

0

100

200

300

400

500

Timestamp(s)

Timestamp (s)

RAM: 90 TPS

RAM: 270 TPS

noPBS−noTEE noPBS−TEE

PBS−noTEE PBS−TEE

PBS−noTEE−rb PBS−TEE−rb

1200

500

1000

400

800

RAM (MB)

RAM (MB)

PBS−noTEE PBS−TEE

0.2

0

600

noPBS−noTEE noPBS−TEE

1

0.4

CPU (millicores)

CPU (millicores)

0.5

300 200 100

noPBS−noTEE noPBS−TEE

PBS−noTEE PBS−TEE

600

700

PBS−noTEE−rb PBS−TEE−rb

600 400 200

0

0

0

100

200

300

400

Timestamp (s)

500

600

700

0

100

200

300

400

500

600

700

Timestamp (s)

Fig. 4: CPU and RAM usage of the block builder across different setups using Uniswap workload. The suffix "-rb" indicates that the builder used is op-rbuilder; otherwise, the default builder, op-geth is used.

builder implementations, e.g., op-rbuilder [19] (≈ 14K lines be leveraged. IMA records measurements of executed binaries of code (LoC)), op-geth (≈ 352K LoC), suggests VM-based and maintains an integrity measurement log in TEE-protected TEEs as the appropriate solution for TEE-assisted security in memory, enabling verification of runtime components. Since this domain, as opposed to the process-based TEE solutions measurements can be limited to the first execution of binaries which require extensive code refactoring and which impose via IMA policy rules, the runtime overhead introduced by IMA large performance hits. Nonetheless, reducing the larger TCB for components such as the builder is not significant. of VM-based TEE designs remains an open research problem. V. R ELATED WORK TCB reduction. TCB reduction in VM-based TEEs remains a fundamental requirement for improving security. One promising PBS. Most prior work on PBS focuses on L1 blockchains. direction is the use of unikernel-based designs, where the Heimbach et al. [8] analyze PBS in L1 across several VM image is specialized for a single application or service, dimensions, including decentralization in transaction validation eliminating unnecessary OS components and thus reducing the and censorship resistance. Yang et al. [40] investigate L1 attack surface. Recent work [37] explored this direction. A PBS, highlighting the implications of MEV centralization in complementary approach is to use a LibOS architecture within block builders. Our work tackles PBS in L2, evaluating the VM-based TEEs, such as Gramine-TDX [38], which could performance impact of both TEEs and PBS in rollup designs. also provide specialized VM images for the block builder. TEE-based censorship solutions. To our knowledge, Flashbots’ Code attestation with VM-based TEEs. In VM-based TEE Rollup Boost [15] is the only deployed solution that combines designs like Intel TDX, attestation mechanisms primarily TEEs with PBS in the context of L2, and no prior work has focus on boot-time components such as the kernel and provided a thorough experimental evaluation of this PBS design. firmware. As a result, boot-time attestation alone may not This is currently integrated with OP Stack, the framework used capture the integrity of application-level software such as in the OP Mainnet rollup [17], and also adopted in several the builder or sequencer, unlike process-based TEEs like other rollups [16], [18]. Some past studies have explored TEE Intel SGX. To address this limitation in VM-based TEE in the context of censorship in L2: TEE Rollup [25] proposes a attestation, technologies such as the Integrity Measurement network of TEE-enabled monolithic sequencers to address both Architecture (IMA) [39], introduced in the Linux kernel, can censorship and fault tolerance at the Rollup sequencer level. The

empirical evaluation of their system shows that TEEs decrease transaction throughput by 15.74% and increase transaction latency by 20.17%. However, this evaluation is performed in the context of multiple heterogeneous sequencers, both VM-based and process-based, that also run a quorum-based coordination process to choose the block proposer. Cristiano et al. [41] propose a TEE-enabled sequencer design equipped with a decentralized attestation mechanism. Their performance evaluation with Intel SGX shows that Intel SGX increases transaction confirmation time by ≈ 614%−740%. Li et al. [24] propose TEE-based mempools as a means to achieve transaction fairness in L1 blockchains, using again only Intel SGX. VI. C ONCLUSION In this paper, we empirically evaluate TEE-enabled rollup designs under both PBS and non-PBS configurations. Our work provides insights into the separate impact of TEEs and PBS, not previously evaluated comparatively, in the context of rollup designs currently deployed in practice, i.e., based on Rollup Boost. Our results show that PBS introduces some network communication overhead, whose performance impact can be further amplified by TEEs, albeit moderately, and is mainly limited by CPU usage. Nonetheless, the TEE-integrated PBS case is the main step towards a safe, censorship-resilient rollup. In this architecture, our evaluations show that PBS can improve performance by enabling more specialized and efficient builder implementations. PBS can also mitigate any performance impact of TEEs on other complex operations, such as batching and state computation at the sequencer, which runs outside a TEE in PBS designs. We consider finer-grained benchmarking, covering the externalization of other sequencer functionalities, as future work. R EFERENCES [1] G. Wood et al., “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper, pp. 1–32, 2014. [2] “L2Beat Rollups Summary,” https://l2beat.com/scaling/summary, 2025. [3] Ethereum Foundation, “What is Layer 2? Scaling Ethereum for mass adoption.” https://ethereum.org/layer-2/learn/, 2025. [4] L. T. Thibault, T. Sarry, and A. S. Hafid, “Blockchain Scaling Using Rollups: A Comprehensive Survey,” IEEE Access, vol. 10, 2022. [5] S. Motepalli, L. Freitas, and B. Livshits, “SoK: Decentralized sequencers for rollups,” https://arxiv.org/pdf/2310.03616, 2023. [6] Optimism, “Optimism documentation - Rollup protocol overview,” https: //docs.optimism.io/op-stack/protocol/overview, 2025. [7] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and E. W. Felten, “Arbitrum: Scalable, Private Smart Contracts,” in 27th USENIX Security Symposium, ser. USENIX Security, 2018. [8] L. Heimbach, L. Kiffer, C. Ferreira Torres, and R. Wattenhofer, “Ethereum’s Proposer-Builder Separation: Promises and Realities,” in ACM Internet Measurement Conference, ser. IMC, 2023. [9] The Illinois Blockchain Initiative, “Blockchain in government tracker,” https://www.airtable.com/universe/expsQEGKoZO2lExKK/ blockchain-in-government-tracker, 2018. [10] M. Chen, “Blockchain for supply chain: Uses and benefits,” https://www.oracle.com/sa/blockchain/what-is-blockchain/ blockchain-for-supply-chain/, 2024. [11] C. F. Torres et al., “Frontrunner Jones and the Raiders of the Dark Forest: An Empirical Study of Frontrunning on the Ethereum Blockchain,” in 30th USENIX Security Symposium, ser. USENIX Security, 2021. [12] Z. Alipanahloo, A. S. Hafid, and K. Zhang, “Maximum Extractable Value (MEV) Mitigation Approaches in Ethereum and Layer-2 Chains: A Comprehensive Survey,” IEEE Access, vol. 12, 2024.

[13] Ethereum Foundation, “Proposer-builder separation,” https://ethereum. org/roadmap/pbs/, 2023. [14] Flashbots, “MEV-Boost,” https://github.com/flashbots/mev-boost, 2025. [15] ——, “Introducing Rollup-Boost,” https://writings.flashbots.net/ introducing-rollup-boost, 2024. [16] A. Hayden et al., “Unichain,” https://docs.unichain.org/whitepaper.pdf, 2024. [17] OP Mainnet, “OP Stack Flashblocks,” https://docs.optimism.io/op-stack/ features/flashblocks, 2025. [18] Base Rollup, “Flashblocks overview,” https://docs.base.org/base-chain/ flashblocks/overview, 2025. [19] Flashbots, “op-rbuilder,” https://github.com/flashbots/op-rbuilder, 2025. [20] V. Costan and S. Devadas, “Intel SGX explained,” IACR Cryptol. ePrint Arch., p. 86, 2016. [21] P.-C. Cheng, W. Ozga, E. Valdez, S. Ahmed, Z. Gu, H. Jamjoom, H. Franke, and J. Bottomley, “Intel TDX Demystified: A Top-Down Approach,” ACM Computing Surveys, vol. 56, no. 9, 2024. [22] AMD, “AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More,” White Paper, 2020. [23] J. Ménétrey, C. Göttel, A. Khurshid, M. Pasin, P. Felber, V. Schiavoni, and S. Raza, “Attestation Mechanisms for Trusted Execution Environments Demystified,” in IFIP International Conference on Distributed Applications and Interoperable Systems, ser. DAIS, 2022. [24] R. Li, X. Hu, Q. Wang, S. Duan, and Q. Wang, “Transaction Fairness in Blockchains, Revisited,” IEEE Transactions on Dependable and Secure Computing, vol. 23, no. 1, 2026. [25] X. Wen, Q. Feng, H. Lyu, J. Niu, Y. Zhang, and C. Feng, “TeeRollup: Efficient Rollup Design Using Heterogeneous TEE,” IEEE Transactions on Computers, vol. 74, no. 10, 2025. [26] F. Vogelsteller and V. Buterin, “ERC-20: Token standard,” https://eips. ethereum.org/EIPS/eip-20, 2015. [27] Ethereum Foundation, “ERC-20 tracker,” https://etherscan.io/tokens, 2025. [28] S. Somin, Y. Altshuler, and A. Pentland, “Crypto-asset Trading on Top of Ethereum Blockchain: Comprehensive Dataset,” Scientific Data, vol. 12, 2025. [29] A. Wahrstätter et al., “Blockchain Censorship,” in ACM Web Conference 2024, ser. WWW, 2024. [30] A. Arusoaie, C.-N. Bărbieru, O.-O. Captarencu, P. Felber, C. Libert, E. Onica, E. Rivière, V. Schiavoni, and P. Yuhala, “Where to Place Your TEE? In Search of a Censorship-Resilient Design for Rollup Sequencers,” in 29th International Conference on Principles of Distributed Systems, ser. OPODIS, 2025. [31] Flashbots, “Builder playground,” https://github.com/flashbots/ builder-playground, 2025. [32] ——, “Contender,” https://github.com/flashbots/contender, 2025. [33] DefiLlama, “Uniswap (uni) protocol stats,” https://defillama.com/protocol/ uniswap, 2026. [34] Optimism, “op-geth,” https://github.com/ethereum-optimism/op-geth.git, 2025. [35] L. Coppolino, S. D’Antonio, G. Mazzeo, and L. Romano, “An Experimental Evaluation of TEE Technology: Benchmarking Transparent Approaches based on SGX, SEV, and TDX,” Computers & Security, vol. 154, 2025. [36] Security in Storage Working Group of the IEEE CS Committee, “IEEE P1619/D16 standard for cryptographic protection of data on blockoriented storage devices,” 2007. [37] K. D. Duy, J. Kim, H. Lim, and H. Lee, “INCOGNITOS: A Practical Unikernel Design for Full-System Obfuscation in Confidential Virtual Machines,” in IEEE Symposium on Security and Privacy, ser. S&P, 2025. [38] D. Kuvaiskii, D. Stavrakakis, K. Qin, C. Xing, P. Bhatotia, and M. Vij, “Gramine-TDX: A Lightweight OS Kernel for Confidential VMs,” in ACM Conf. on Computer and Communications Security, ser. CCS, 2024. [39] I. Xia et al., “Runtime integrity measurement and attestation in a trust domain,” https://www.intel.com/content/www/us/en/developer/articles/ community/runtime-integrity-measure-and-attest-trust-domain.html, 2025. [40] S. Yang, K. Nayak, and F. Zhang, “Decentralization of Ethereum’s Builder Market,” in IEEE Symposium on Security and Privacy, ser. S&P, 2025. [41] G. M. Cristiano, S. D’Antonio, J. Giglio, G. Mazzeo, and L. Romano, “Enhancing the Security of Rollup Sequencers using Decentrally Attested TEEs,” IEEE Transactions on Emerging Topics in Computing, vol. 14, no. 2, 2026.

Related documents

• Empirical Analysis of TEE-Enabled Rollup Designs#1388850
• Vers une gestion collaborative et sécurisée des chaînes d’approvisionnement : intégration d’une blockchain permissionnée et de l’apprentissage fédéré#151855
• Privacy Law Issues in Blockchains: An Analysis of PIPEDA, the GDPR, and Proposals for Compliance#964653
• El impacto de la adopción de la blockchain en la educación virtual desde las percepciones de los profesores y estudiantes#187439
• NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters#2935