How to Architect Infrastructure for Layer 2 Rollups

Rollup infrastructure is the off-chain execution environment that processes transactions before submitting compressed proofs or data to a Layer 1 (L1) blockchain like Ethereum. The primary architectural goal is to maximize throughput and minimize user costs while inheriting the L1's security. This requires several coordinated components: a sequencer for transaction ordering, a state manager for execution, a data availability (DA) solution for publishing transaction data, and a prover (for ZK-Rollups) or fraud prover (for Optimistic Rollups). Each component's design directly impacts the rollup's performance, decentralization, and security model.

The sequencer is the most critical real-time component. It receives user transactions, orders them into a batch, and executes them against the current rollup state. Architecting a sequencer involves decisions on its decentralization—whether it's a single operator, a permissioned set, or a decentralized network using consensus like Tendermint. It must also be highly available and include mechanisms for censorship resistance, such as allowing users to force-include transactions via the L1. For high performance, sequencers often use in-memory state trees and optimized execution clients like a modified Geth or Reth.

Data availability is a foundational security requirement. The architecture must guarantee that transaction data is published and accessible so anyone can reconstruct the rollup state and verify proofs or challenge invalid state transitions. The default is to post calldata to Ethereum L1, but this is expensive. Alternatives include EigenDA, Celestia, or Avail, which are specialized DA layers offering lower costs. The infrastructure must reliably submit data to the chosen DA layer and provide archival access via data availability committees (DACs) or light client networks for verification.

For ZK-Rollups, the proving infrastructure is a major engineering challenge. A separate prover network generates cryptographic validity proofs (SNARKs/STARKs) for each batch. This involves distributing computational workloads across specialized hardware (GPUs, FPGAs) to generate proofs efficiently. The architecture must manage proof generation pipelines, aggregate proofs for efficiency, and handle circuit management for different transaction types. For Optimistic Rollups, the infrastructure requires fraud proof systems, where full nodes can detect invalid state roots and submit challenges during the dispute window.

Finally, the architecture must integrate with the L1 via a set of smart contracts. These include the main bridge contract for deposits/withdrawals, the verifier contract (for ZK proofs), and the data contract for storing batch data. The off-chain components must maintain constant synchronization with these contracts, monitoring for L1 finality and submitting batches or proofs at optimal intervals to balance cost and latency. A well-architected system uses modular components that can be upgraded independently, following patterns like Ethereum's rollup-centric roadmap for future enshrined rollups.

The foundational layer of a rollup infrastructure is the execution client. This is the software that processes transactions, executes smart contracts, and generates new blocks. For an Optimistic Rollup, you typically run a modified Geth or Erigon client. For a ZK Rollup, you need a prover service (like those from RISC Zero or SP1) alongside a sequencer. These components demand significant CPU resources, especially for ZK proof generation, which is computationally intensive. A minimum of 16 CPU cores and 64GB RAM is recommended for development, with production setups requiring scalable, multi-core servers or dedicated proof-generation hardware.

Data availability is critical. You must run a full node for the underlying Layer 1 (e.g., an Ethereum Geth or Nethermind node) to submit transaction data and verify L1 state. For production, consider a high-availability cluster of L1 nodes to prevent single points of failure. Additionally, you need reliable storage for the rollup's own state. While a local SSD (2TB NVMe minimum) works for the chain data, using a decentralized data availability layer like Celestia, EigenDA, or Ethereum's calldata requires configuring your node client to post and retrieve data from these networks, impacting your bandwidth and gas cost calculations.

The sequencer is the heart of the system, responsible for ordering transactions. It must be a highly available service with low latency. Architect it as a redundant, auto-scaling group behind a load balancer. For decentralization, you may later integrate with a shared sequencer network like Espresso or Astria. The RPC layer is your public interface. Use a reverse proxy (Nginx, Caddy) to manage traffic to your RPC nodes, and implement rate limiting and authentication. Services like QuickNode or Alchemy provide managed solutions, but self-hosting requires configuring nodes with the --http and --ws flags and ensuring they are synced to the latest rollup block.

Monitoring and alerting are non-negotiable for production. Implement a stack using Prometheus to collect metrics (block production time, CPU/memory usage, RPC error rates) from your nodes and sequencer, Grafana for dashboards, and Alertmanager for notifications. Use structured logging with Loki or ELK Stack to trace transaction flow and debug issues. For a ZK Rollup, specifically monitor proof generation times and verification success rates. Infrastructure as Code (IaC) tools like Terraform or Pulumi are essential for reproducible deployments on cloud providers (AWS, GCP, Azure) or bare metal, allowing you to spin up identical testnets and manage configurations consistently.

Finally, consider the bridging and interoperability infrastructure. You will need to deploy and maintain a set of smart contracts on the L1 for your rollup's bridge, which handles deposits and withdrawals. This requires a separate deployment process and monitoring for contract events. You may also need relayer services to listen for events on L1 and L2 and forward messages, which should be built with redundancy in mind. The entire system should be designed to handle variable load, with clear procedures for upgrades, disaster recovery, and responding to chain reorganizations.

A sequencer is the primary node responsible for ordering transactions, batching them, and submitting compressed data to the base layer (L1). It requires high availability and low latency to maintain network performance. In contrast, a prover (or ZK-prover) is a computationally intensive node that generates cryptographic validity proofs for zero-knowledge rollups. Its primary requirement is powerful hardware, specifically high-core-count CPUs and substantial RAM, to perform complex cryptographic operations efficiently. Architecting for these roles involves fundamentally different infrastructure priorities.

For a production-grade sequencer, focus on redundancy and reliability. Deploy multiple instances behind a load balancer, using a consensus mechanism (like a BFT consensus among sequencers) to prevent single points of failure. Key infrastructure includes: a high-performance database (e.g., PostgreSQL) for state storage, a robust message queue for transaction ingestion, and a connection to a full L1 node (like an Ethereum Geth or Erigon client). Network latency to the L1 is critical, so colocation in a data center with low-latency links to L1 node providers is often necessary.

Prover node infrastructure is dominated by computational power. ZK-proof generation, especially for circuits like those in zkEVMs, is massively parallelizable. Optimal hardware includes servers with AMD EPYC or Intel Xeon CPUs featuring 64+ cores and 256GB+ of RAM. GPU acceleration (with NVIDIA A100/H100) is becoming standard for specific proof systems like PLONK or STARKs. The software stack involves the prover binary (e.g., from Scroll, zkSync, or Polygon zkEVM), a witness generator, and coordination with the sequencer or a separate coordinator service to receive proof tasks.

Both node types require robust monitoring and alerting. Implement metrics collection for: transaction throughput (TPS) and batch submission latency for sequencers; proof generation time, CPU/RAM utilization, and proof queue depth for provers. Use tools like Prometheus, Grafana, and structured logging (e.g., via Loki). Security is paramount: run nodes in a private VPC, use firewall rules to restrict access, and ensure all node software is regularly updated. For ZK-provers, the setup often includes a trusted setup ceremony contribution for the circuit's proving and verification keys.

A practical deployment workflow involves infrastructure-as-code. Use Docker containers to package node software and dependencies for consistency. Orchestrate with Kubernetes for automated deployment, scaling, and management, defining separate deployments and resource requests for sequencer and prover pods. For bare metal, use configuration management with Ansible or Terraform. Always test your deployment on a testnet (like Sepolia or a rollup's specific testnet) to validate configuration, performance, and integration with the network's contracts before mainnet deployment.

A data availability (DA) layer is the foundational component that ensures transaction data for a Layer 2 rollup is published and accessible. For optimistic rollups like Arbitrum and Optimism, this data is posted to Ethereum's calldata. For newer architectures like validiums and certain zk-rollups, it can be offloaded to specialized DA layers like Celestia, EigenDA, or Avail. The primary goal is to guarantee that anyone can reconstruct the L2 state and verify its correctness, which is a prerequisite for trustless security. Architecting this infrastructure requires decisions on data publishing, retrieval, and attestation mechanisms.

The core architectural components are the sequencer, the DA writer, and the DA verifier. The sequencer batches L2 transactions. The DA writer is responsible for posting this batch data to the chosen availability layer, which involves formatting the data, paying associated fees (e.g., gas on Ethereum), and submitting the transaction. The DA verifier, often run by nodes or a decentralized network of attesters, continuously monitors the DA layer to confirm that data for each batch is available and can be downloaded. If data is missing, the verifier must be able to produce a fraud proof (for optimistic systems) or halt state transitions.

Choosing a DA protocol involves evaluating trade-offs between security, cost, and throughput. Using Ethereum L1 for DA offers the highest security alignment but incurs significant gas costs, limiting scalability. External DA layers like Celestia provide lower-cost data publishing with cryptoeconomic security through separate validator sets. EigenDA offers restaked security leveraging Ethereum's validator set via EigenLayer. Integration typically involves using the protocol's SDK or API. For example, posting to Celestia requires constructing a Blob and submitting it via its light nodes, while EigenDA integration uses its dedicated EigenDAServiceManager smart contract on Ethereum for data attestation.

A practical integration for a custom rollup involves several steps. First, modify your rollup node's batch submitter to interface with your chosen DA layer's client library. The data must be encoded according to the layer's specification—often as a list of raw transactions or a state diff. After posting, you must store and broadcast the data commitment (e.g., a Merkle root or KZG commitment) and the location proof (like a transaction hash or blob ID) to your rollup's L1 bridge contract. This commitment allows verifiers to know exactly what data to fetch and validate. Robust error handling for posting failures and monitoring for data liveness is critical.

Developers must also implement the data retrieval and syncing logic for their rollup's full nodes. These nodes must be able to connect to the DA layer's RPC endpoints or peer-to-peer network to fetch batch data using the stored commitments. For Ethereum-based DA, this means querying an archive node for historical calldata. For Celestia, nodes run a light client that samples data availability. The syncing process verifies the data's integrity against the published commitment before processing it to update the local L2 state. This ensures all nodes converge on the same canonical chain.

Finally, consider the long-term evolution of the DA landscape. Proto-danksharding (EIP-4844) on Ethereum introduces blob transactions, drastically reducing DA costs for L2s and becoming the new standard. Architectures should be modular to allow switching DA providers or utilizing multiple providers for redundancy. Monitoring tools should track key metrics: data posting latency, cost per byte, and DA layer uptime. By decoupling execution from data availability, rollups can achieve greater scalability while maintaining the security guarantees required for decentralized applications.

The foundation of a rollup's infrastructure is its node architecture. You need to run at least two primary node types: a sequencer node for ordering and batching transactions, and a verifier node (or full node) for state derivation and fraud/validity proof generation. These should be deployed as separate, isolated services. For high availability, run multiple sequencer instances behind a load balancer with a consensus mechanism (like a leader election service) to prevent double-signing. Use containerization (Docker) and orchestration (Kubernetes) for consistent deployment and scaling. All nodes must connect to the Layer 1 (L1) Ethereum node via a reliable provider or your own dedicated node cluster to submit batches and verify proofs.

Data availability is non-negotiable. Your sequencer must post transaction data (calldata or blobs) to the L1 chain reliably. Architect for redundancy: implement multiple, independent L1 RPC endpoints with automatic failover. For cost-efficient data posting, use EIP-4844 blob transactions where supported. You must also maintain a long-term data archival solution, such as a decentralized storage network (like Arweave or Filecoin) or a highly available internal database, to ensure data is retrievable for future state reconstructions. The system should continuously monitor data posting success rates and gas prices to optimize submission timing.

A comprehensive monitoring stack is essential. Instrument every component to emit metrics (using Prometheus), structured logs (to Loki or Elasticsearch), and distributed traces (with Jaeger). Key metrics to track include: batch submission latency and success rate, L1 gas costs, sequencer block production time, verifier proof generation time, and RPC endpoint health. Set up alerts for critical failures, such as missed batches, sequencer downtime, or a growing transaction mempool. Use dashboards (Grafana) to visualize system health and performance trends in real-time.

Design your system for graceful upgrades and maintenance. For the sequencer, implement a mechanism for safe handover, where a new version can sync to the latest L1 state before taking over production duties. For smart contract upgrades on L1 (like your rollup contract), use a proxy pattern (Transparent or UUPS) controlled by a multi-signature timelock contract. This ensures upgrade logic is transparent and gives users time to react. Maintain a staging environment that mirrors mainnet, including a forked L1 testnet, to rigorously test all upgrades and node software changes before deployment.

Security architecture must be defense-in-depth. Isolate critical private keys (sequencer, proxy admin) in hardware security modules (HSMs) or cloud KMS services. Implement strict network security groups, allowing only necessary communication between nodes and external services. Regularly conduct security audits on your node software and smart contracts. Furthermore, plan for disaster recovery. Have documented procedures and automated scripts for scenarios like sequencer failure, L1 chain reorgs, or malicious transaction floods. Your ability to quickly recover defines the network's resilience.

The architecture you choose directly impacts your rollup's performance, cost, and security profile. A centralized sequencer offers simplicity and low latency for early-stage projects, but a decentralized sequencer set is essential for censorship resistance and liveness guarantees. Your data availability solution—whether an Ethereum calldata, a dedicated DA layer like Celestia or EigenDA, or a validium—is the most critical decision, determining your security model and transaction costs. The prover system (e.g., a zkEVM circuit or a fraud proof verifier contract) defines your trust assumptions and finality speed.

For practical next steps, begin by instrumenting your existing infrastructure with detailed monitoring. Use tools like Prometheus and Grafana to track sequencer health, batch submission latency, L1 gas costs, and bridge withdrawal times. Establish alerting for failed batch submissions or stalled proof generation. Simultaneously, engage with the community on forums like the Ethereum Magicians or relevant project Discords to discuss design trade-offs. Review the source code and audits of the core infrastructure components you plan to use, such as the OP Stack, Arbitrum Nitro, or zkSync's ZK Stack.

To deepen your understanding, experiment in a testnet environment. Deploy a local devnet using a framework like Foundry or Hardhat with a rollup stack. Practice submitting transactions, forcing batches to L1, and simulating a challenge in an optimistic rollup context. Study real-world incident reports, such as post-mortems from network outages, to learn how other teams handle failures. Finally, consider the long-term roadmap: how will your architecture evolve to incorporate decentralized sequencers, multi-proof systems, or shared sequencing layers like Espresso or Astria? A modular, upgradeable design is key to adapting to this rapidly advancing ecosystem.