How to Design Execution for Shared Sequencing

Shared sequencing decouples transaction ordering from execution, creating a neutral marketplace for block space. This architectural shift requires a re-evaluation of execution layer design. The execution layer is responsible for state transitions—taking an ordered list of transactions from the shared sequencer and computing the resulting changes to the blockchain's state. Key design goals include deterministic execution, high throughput, and seamless interoperability with the sequencer's data availability layer. Unlike traditional monolithic chains, the execution engine must be agnostic to the source of its transaction stream.

The core component is the execution client (or node). It receives sequenced transaction batches, often via a dedicated API or a data availability solution like Celestia or EigenDA. The client must then process these transactions against its local copy of the state. This involves running the Ethereum Virtual Machine (EVM) or another runtime, validating signatures, calculating gas, and updating the state trie. Crucially, the execution logic must be deterministic; given the same ordered batch and starting state, all honest nodes must arrive at an identical final state root to maintain consensus.

State management is a critical challenge. The execution layer must maintain a full state database (accounts, balances, contract code, storage). To optimize performance, implementations often use state pruning to discard old state data and employ caching layers. The execution client must also produce execution traces and receipts, which are essential for cross-chain messaging protocols and Layer 2 validity proofs. For optimistic rollups, this means generating fraud proofs, while zk-rollups require the client to produce ZK-SNARK or STARK proofs that attest to the correctness of the state transition.

Interfacing with the shared sequencer requires robust APIs. A typical setup involves the execution client subscribing to a stream from the sequencer's block builder. Transactions are often encoded in a standard format like SSZ or simple RLP. The client must handle reorgs gracefully; if the sequencer finalizes a different branch of the chain, the execution layer must be able to revert its state and re-execute transactions from the new canonical branch. This necessitates efficient state management and potentially a fork-choice rule that follows the sequencer's finality gadget.

For developers building on this stack, the primary interface is the JSON-RPC API. The execution client must expose standard endpoints like eth_call, eth_sendRawTransaction, and eth_getLogs to allow wallets and dApps to interact with the chain. However, the eth_sendRawTransaction endpoint typically submits transactions to the shared sequencer's mempool, not directly to the execution layer. This separation ensures that the sequencer maintains a global view of transaction ordering across multiple rollups or execution environments.

In practice, projects often fork existing execution clients like Geth (Go-Ethereum) or Reth to integrate with a shared sequencer. The modifications involve replacing the native networking and consensus logic with calls to the sequencer's API and implementing the necessary state synchronization mechanisms. The end goal is a system where multiple independent execution layers can process the same ordered stream, enabling a modular blockchain landscape where security, data availability, and execution are provided by specialized providers.

Shared sequencing is a core component of the modular blockchain stack, sitting between the data availability (DA) layer and the execution layer. A shared sequencer receives, orders, and batches transactions from multiple rollups before submitting them to the DA layer. Your execution design must therefore understand its inputs: a stream of pre-ordered transaction batches from the sequencer network and the corresponding data blobs published to a DA layer like Celestia, EigenDA, or Ethereum.

You must be familiar with the core properties a shared sequencer aims to provide: censorship resistance, atomic composability across rollups, and fast pre-confirmations. The execution layer's job is to faithfully process the sequence it receives. This requires a robust understanding of state transition functions, fraud proofs (for optimistic rollups), or validity proofs (for zk-rollups). Your execution logic must be deterministic and reproducible by any verifier on the network.

Key technical prerequisites include proficiency with a virtual machine like the Ethereum Virtual Machine (EVM) or alternatives such as SVM or the Move VM, depending on your rollup's target environment. You'll need to design how this VM interacts with a state tree (e.g., a Merkle Patricia Trie) and a batch processor that consumes the sequenced data. Knowledge of interoperability standards like IBC or generic message passing is also crucial for enabling atomic cross-rollup transactions, which is a primary value proposition of shared sequencing.

Finally, you must consider the proving stack if building a zk-rollup. This involves selecting a proof system (e.g., PLONK, STARK, RISC Zero), designing efficient circuit logic for your state transitions, and integrating a prover/verifier workflow. For optimistic designs, you need a mechanism for fraud proof challenge games and a dispute resolution layer. The execution logic you write will be the subject of these verification processes, so clarity and correctness are paramount.

A shared sequencer provides a canonical, cross-rollup ordering of transactions, but it does not execute them. The execution layer is the component responsible for taking this ordered list and computing the resulting state changes. Its primary job is to deterministically process the sequence, validate state transitions, and produce execution proofs. This separation allows for modularity—different execution clients can be optimized for specific virtual machines (e.g., EVM, SVM, Cairo VM) while relying on a single, neutral source of ordering.

The core architectural decision is between a monolithic executor and a modular executor network. A monolithic design runs a single, highly optimized execution client (like a modified Geth or Reth) that processes all batches. A modular network uses multiple, potentially heterogeneous executors that specialize in different VMs or tasks, coordinated by a manager. The modular approach improves resilience and specialization but adds complexity in synchronizing state roots and proof aggregation across different systems.

Execution must be deterministic and verifiable. Given the same pre-state and ordered transaction batch, every honest executor must produce an identical post-state root. This is achieved by using a state transition function defined by the VM specification. For Ethereum L2s, this means strict EVM compliance. The output isn't just a new state; it's also a zk-proof (for ZK-rollups) or a fraud proof (for optimistic rollups) that attests to the correctness of the execution, which is then posted to the settlement layer.

Design the execution layer's state management carefully. It must efficiently read the current world state, apply transactions, and write the new state. For high throughput, consider a stateful execution model that keeps a hot database in memory, as seen in clients like Reth. The interface with the shared sequencer is critical: the executor subscribes to a stream of ordered transaction batches, often via a broadcast channel or by pulling from a data availability layer like Celestia or EigenDA.

Here is a simplified conceptual interface for an executor service:

codeCopy
struct ExecutionRequest {
    batch_id: u64,
    pre_state_root: Hash,
    transactions: Vec<Transaction>,
}

struct ExecutionResult {
    post_state_root: Hash,
    gas_used: u64,
    logs: Vec<Log>,
    proof: ExecutionProof, // zk or fraud proof
}

fn execute_batch(request: ExecutionRequest) -> Result<ExecutionResult>;

The executor validates the pre-state root against its own database, processes the transactions, generates the proof, and outputs the result. This service can be exposed via RPC for integration with a sequencer or a proving network.

Finally, consider prover coordination and fault tolerance. In a ZK-rollup stack, the execution layer may need to hand off execution traces to specialized provers. Design for retry logic and slashing conditions in case of faulty execution. The system should be able to detect a stalled or malicious executor and re-route the batch, ensuring liveness. Successful designs, like those in the Espresso Systems or Astria ecosystems, treat execution as a scalable, redundant service that faithfully computes the sequence provided by the shared sequencer.

A shared sequencer provides a canonical, pre-consensus ordering of transactions for multiple rollups. The execution layer's primary job is to deterministically process these ordered batches. This requires a clear separation of concerns: the sequencer handles availability and ordering, while the execution layer handles state transitions. You must design your execution client to accept a stream of sequenced transaction batches, typically via a data availability layer like Celestia, EigenDA, or Avail, or directly from a sequencer network like Espresso or Astria.

Execution design centers on a stateless verifier model. The core execution engine, such as a modified Geth, Erigon, or a custom EVM-compatible runtime, processes batches without maintaining persistent state. Instead, it relies on a separate state provider (like a database or a state trie service) to supply the pre-state required for each transaction. This separation allows for horizontal scaling of execution nodes. The output is a new state root and a set of execution traces or state diffs that prove the validity of the state transition.

To ensure deterministic execution across all nodes, you must pin specific dependencies. This includes locking the EVM version (e.g., Shanghai, Cancun), the precompiles available, and the gas schedule. Any non-determinism, such as reliance on local timestamps or random number generators, will cause nodes to derive different state roots, breaking consensus. Your execution client should run in a sandboxed environment and fetch all external data (like block hashes for BLOCKHASH) from the sequenced input data.

After processing a batch, the execution layer must produce verifiable outputs. The primary output is the post-state root, which is committed to L1 as part of the rollup's validity or fraud proof. Additionally, you should generate witness data (like Merkle proofs) or zk-SNARK/STARK proofs if building a zk-rollup. For optimistic rollups, you must meticulously log execution traces for the fraud proof challenge period. Tools like Cannon or custom MIPS/RISC-V emulators can be integrated to generate these dispute game traces.

For production systems, consider parallel execution. Transactions within a batch that do not conflict (access disjoint state slots) can be executed concurrently using frameworks like Block-STM or Ethereum's PBS-based designs. This significantly improves throughput. You'll need a scheduler that analyzes transaction dependencies from their access lists. Finally, the execution layer must interface with a settlement layer (like Ethereum mainnet) to post commitments and handle withdrawals, completing the modular stack.

Integrating with a shared sequencer like Espresso, Astria, or Radius requires designing your execution environment to process ordered transaction batches. The core architectural shift is separating sequencing (ordering) from execution (processing). Your rollup's execution client must be modified to accept a stream of pre-ordered transactions from the shared sequencer's Data Availability (DA) layer, rather than building its own mempool and proposing blocks. This involves implementing a new block builder module that subscribes to the sequencer's API or chain, fetches the canonical transaction order, and then executes transactions against your rollup's state.

The execution logic must handle soft confirmation and finalization states. When the shared sequencer proposes a block, it provides a soft commitment (e.g., via a signature). Your execution node can begin processing immediately for low-latency pre-confirmations. Finalization occurs later when the sequencer's consensus finalizes the block, often posted to a base layer like Ethereum. Your state transition function must be deterministic and capable of re-executing from the finalized order if necessary. Implement a fallback mechanism to switch to a local sequencer if the shared network is unavailable, ensuring liveness.

Key integration points include the Block Production API and DA Bridge. For example, with Espresso, you would configure your node to poll the espresso.cash sequencer RPC for new blocks. Your execution client uses this ordered list to construct a block, run the EVM (or other VM), and update the Merkle state root. The resulting block data—state roots and proofs—is then published to your designated DA layer (e.g., Celestia, EigenDA, Ethereum). Code changes are typically minimal if you're using a modular stack like the OP Stack or Arbitrum Nitro, which have pluggable sequencer interfaces.

You must also design for MEV management. Shared sequencers can offer fair ordering or encrypted mempools (like Radius), which impacts how transactions are revealed to your executor. If using encrypted transactions, your execution environment needs a decryption step before processing. Furthermore, consider fee distribution; transaction fees may be split between the shared sequencer network and your rollup's treasury. Your execution client's economic logic should account for this, potentially routing a portion of fees to a designated sequencer payment address.

Finally, rigorous testing is required. Deploy a local testnet with a mock shared sequencer (many provide local development kits) to validate: transaction ordering correctness, state transition consistency under reorgs, block production latency, and fallback procedures. Monitor key metrics like time-to-inclusion (from user tx to execution) and finality time. Successful integration delegates network security and consensus complexity, allowing your team to focus on optimizing the execution environment and application-layer innovation.

Designing a shared sequencer requires a series of deliberate technical choices. Start by defining your sequencer set and consensus mechanism. Will you use a permissioned set of known validators for higher throughput, or a permissionless, stake-based set for greater decentralization? The consensus choice—be it a BFT variant like Tendermint, HotStuff, or a DAG-based protocol—directly impacts finality time and resilience. Next, architect the execution layer. This involves deciding whether to run a full EVM execution client, a custom VM, or integrate with an existing rollup stack like the OP Stack or Arbitrum Nitro. The execution engine must be tightly coupled with the consensus layer to process ordered transactions and produce state roots.

The data availability (DA) and bridge components are critical for security. You must decide where sequencer batches are published. Options include using a high-throughput L1 like Celestia or Avail, an Ethereum data availability layer like EigenDA, or directly to Ethereum calldata. The bridge contract on the destination chain (e.g., Ethereum) must be designed to verify batch inclusion proofs from your chosen DA layer and validate state transitions, often using fraud proofs or validity proofs (ZK). This contract is the ultimate arbiter of canonical chain state, so its security is paramount. Reference implementations like the Arbitrum bridge provide a solid starting point.

For practical development, begin with a local testnet. Use frameworks like foundry or hardhat to deploy your bridge and rollup contracts. Implement a minimal sequencer node that can ingest transactions, participate in consensus (you can simulate this initially with a single node), and produce batches. Tools like the OP Stack offer a modular codebase where you can replace the default sequencer module. Focus on the core lifecycle: transaction pooling, batch creation, DA submission, and state root generation. Instrument comprehensive logging and metrics from day one to monitor performance and identify bottlenecks.

The final phase involves testing and security auditing. Develop a rigorous test suite covering normal operation, sequencer failure, DA withholding attacks, and bridge verification. Consider using a fault injection framework to test network partitions and byzantine behavior among sequencers. Before any mainnet deployment, your entire system, especially the bridge and consensus logic, must undergo multiple professional audits. The shared sequencing landscape is rapidly evolving, with new research on MEV distribution mechanisms and decentralized validator sets emerging regularly. Engaging with the community through forums like the EthResearch forum is essential to stay current.