Table of Contents
Fetching ...

Specular: Towards Secure, Trust-minimized Optimistic Blockchain Execution

Zhe Ye, Ujval Misra, Jiajun Cheng, Wenyang Zhou, Dawn Song

TL;DR

Specular presents an L2-native, interactive fraud-proof ORU for Ethereum that decouples the on-chain verifier from a single L2 client by enabling opportunistic $1$-of-$N$ version programming (1-NVP). By targeting high-level EVM semantics with an L2-native IFP, Specular enables permissionless participation across multiple L2 clients and reduces the trusted computing base to a more auditable verifier, improving robustness against monoculture bugs. The implementation demonstrates feasibility by adapting two Ethereum EL clients (Geth and Erigon) with modest code changes and showing practical one-step proof sizes (roughly 558 bytes without contract bytecode) and verification costs (~109k gas per step, ~629k with contract bytecode), while attaining sub-millisecond proof generation (0.739 ms for SpecGeth) and viable cross-client interoperability. This work advances scalable Ethereum with secure, transparent upgrades and a reduced TCB, enabling more resilient and accessible L2 ecosystems through L2-native proofs and diverse client participation.

Abstract

An optimistic rollup (ORU) scales a blockchain's throughput by delegating computation to an untrusted remote chain (L2), refereeing any state claim disagreements between mutually distrusting L2 operators via an interactive dispute resolution protocol. State-of-the-art ORUs employ a monolithic dispute resolution protocol that tightly couples an L1 referee with a specific L2 client binary--oblivious to the system's higher-level semantics. We argue that this approach (1) magnifies monoculture failure risk, by precluding trust-minimized and permissionless participation using operator-chosen client software; (2) leads to an unnecessarily large and difficult-to-audit TCB; and, (3) suffers from a frequently-triggered, yet opaque upgrade process--both further increasing auditing overhead, and broadening the governance attack surface. To address these concerns, we outline a methodology for designing a secure and resilient ORU with a minimal TCB, by facilitating opportunistic 1-of-N-version programming. Due to its unique challenges and opportunities, we ground this work concretely in the context of the Ethereum ecosystem--where ORUs have gained significant traction. Specifically, we design a semantically-aware proof system, natively targeting the EVM and its instruction set. We present an implementation in a new ORU, Specular, that opportunistically leverages Ethereum's existing client diversity with minimal source modification, demonstrating our approach's feasibility.

Specular: Towards Secure, Trust-minimized Optimistic Blockchain Execution

TL;DR

Specular presents an L2-native, interactive fraud-proof ORU for Ethereum that decouples the on-chain verifier from a single L2 client by enabling opportunistic -of- version programming (1-NVP). By targeting high-level EVM semantics with an L2-native IFP, Specular enables permissionless participation across multiple L2 clients and reduces the trusted computing base to a more auditable verifier, improving robustness against monoculture bugs. The implementation demonstrates feasibility by adapting two Ethereum EL clients (Geth and Erigon) with modest code changes and showing practical one-step proof sizes (roughly 558 bytes without contract bytecode) and verification costs (~109k gas per step, ~629k with contract bytecode), while attaining sub-millisecond proof generation (0.739 ms for SpecGeth) and viable cross-client interoperability. This work advances scalable Ethereum with secure, transparent upgrades and a reduced TCB, enabling more resilient and accessible L2 ecosystems through L2-native proofs and diverse client participation.

Abstract

An optimistic rollup (ORU) scales a blockchain's throughput by delegating computation to an untrusted remote chain (L2), refereeing any state claim disagreements between mutually distrusting L2 operators via an interactive dispute resolution protocol. State-of-the-art ORUs employ a monolithic dispute resolution protocol that tightly couples an L1 referee with a specific L2 client binary--oblivious to the system's higher-level semantics. We argue that this approach (1) magnifies monoculture failure risk, by precluding trust-minimized and permissionless participation using operator-chosen client software; (2) leads to an unnecessarily large and difficult-to-audit TCB; and, (3) suffers from a frequently-triggered, yet opaque upgrade process--both further increasing auditing overhead, and broadening the governance attack surface. To address these concerns, we outline a methodology for designing a secure and resilient ORU with a minimal TCB, by facilitating opportunistic 1-of-N-version programming. Due to its unique challenges and opportunities, we ground this work concretely in the context of the Ethereum ecosystem--where ORUs have gained significant traction. Specifically, we design a semantically-aware proof system, natively targeting the EVM and its instruction set. We present an implementation in a new ORU, Specular, that opportunistically leverages Ethereum's existing client diversity with minimal source modification, demonstrating our approach's feasibility.
Paper Structure (79 sections, 1 equation, 8 figures, 2 tables, 1 algorithm)

This paper contains 79 sections, 1 equation, 8 figures, 2 tables, 1 algorithm.

Figures (8)

  • Figure 1: Proof system toolchain comparison. (Top) state-of-the-art ORUs suffer from a large and complex TCB. The binary toolchain of the compiled approach is inherently resistant to TCB simplification. (Bottom) the native approach, instantiated with $1$-NVP, enables a simpler TCB.
  • Figure 2: Opportunistic 1-NVP in Specular. Specular opportunistically reuses an Ethereum EL client for its own execution-layer. (Purple) Components are minimally modified to enable finer-grained control over payload creation, and expose sufficient trace state to the prover. (Green) All other components are fully reused.
  • Figure 3: Compilation-based KNVP in ORUs. Components of independent CL and EL clients are composed as a single program. Programs are compiled to multiple targets. Each binary is committed to on-chain (not shown).
  • Figure 4: Abstract L2 trace segment. The L2 abstract trace includes state transitions between the following types of steps: (1) instruction execution, (2) transaction-level initiation & finalization, (3) block-level initiation & finalization, and (4) consensus-layer batch validation.
  • Figure 5: Emulation. An illustration of the flow of inputs and outputs within the one-step EVM emulator.
  • ...and 3 more figures