Tutorial: Deploy Your Own Layer 2 with the OP Stack

Crypto & Blockchainwritten by Zephyr
5 min read
Developer configuring an OP Stack-based Layer 2 rollup on their computer

Layer 2 scaling solutions are transforming the Ethereum ecosystem. Optimism's OP Stack stands out as a modular infrastructure allowing any developer to create their own rollup. If you're looking to understand how an optimistic rollup concretely works, this tutorial will guide you through the complete deployment of a functional testnet.

This hands-on approach not only provides a deep understanding of Layer 2 architecture but also lays the groundwork for potential production deployment. Ready to launch your own chain?

Prerequisites and Environment Setup

Before diving into deployment, your development environment must be properly configured. The OP Stack relies on several essential technologies that need to be installed.

Start by ensuring your system has the following tools: Git for cloning repositories, Go 1.20+ for compiling binaries, Node.js 16+ for managing JavaScript dependencies, and Docker for containerizing certain services. You will also need the Ethereum client op-geth, the Solidity compiler solc, the development tool Foundry (specifically forge), and the task runner just.

ComponentPrimary Role
`op-geth`L2 Execution Client
`op-node`L2 Consensus Client
`op-batcher`Batch Aggregation and Publication
`op-proposer`State Root Submission
Illustration: Tutoriel : Déployer votre propre Layer 2 avec l'OP Stack - Crypto & Blockchain

On macOS, install system dependencies with Homebrew:

```bash brew install jq gnu-sed ```

Create a dedicated working directory, then clone the official Optimism repository:

```bash cd ~/Documents git clone https://github.com/ethereum-optimism/optimism.git cd optimism ```

Switch to the appropriate branch (usually `tutorials/chain` or the latest stable Bedrock release) and verify your tool versions by running the check script:

```bash git checkout tutorials/chain ./packages/contracts-bedrock/scripts/getting-started/versions.sh ```

Once this step is validated, execute `just install` to automatically download the essential binaries: op-deployer, op-node, op-batcher, and op-proposer. These four components form the core of your rollup.

Network Configuration with op-deployer

op-deployer is the tool that initializes your rollup by generating essential configuration files: `genesis.json` and `rollup.json`. These files define the fundamental parameters of your Layer 2 chain.

To create these files, you need to specify several key parameters: a unique chain name, a network ID (chain ID), the RPC URL of the Layer 1 chain your rollup will rely on (e.g., Sepolia for a testnet), as well as the sequencer addresses and data availability parameters.

Regarding data availability, two options are available. You can choose Ethereum as the settlement layer, in which case your transaction data will be published directly on Layer 1. Alternatively, you can opt for an external solution like Celestia, which potentially offers reduced costs.

The OP Stack allows for remarkable architectural flexibility: each component can be configured independently according to the specific needs of your application.

Once the configuration files are generated, the next step is to deploy the L1 bridge contract. This smart contract is crucial as it manages asset transfers between your Layer 1 (Ethereum) and your new Layer 2.

Use Foundry to deploy this contract:

```bash forge script scripts/Deploy.s.sol:Deploy --rpc-url $L1_RPC --private-key $PRIVATE_KEY ```

Copy the deployed contract address and integrate it into your `rollup.json` file. This address will serve as the anchor point for all cross-chain communications.

Initializing Rollup Components

Your rollup requires four distinct services running in parallel. Each plays a specific role in the overall architecture.

Op-geth: The Execution Client

Op-geth is a modified version of Geth adapted for rollups. It handles transaction execution and maintains the state of your Layer 2 blockchain.

Initialize the client with the previously generated configuration files:

```bash op-geth --datadir=./data --rollup.config=rollup.json --genesis=genesis.json ```

This client functions similarly to a classic Ethereum node but communicates with other OP Stack components to coordinate transaction processing.

Op-node: The Consensus Client

The op-node acts as a bridge between your Layer 1 and your Layer 2. It derives Layer 2 blocks from data published on Layer 1 and coordinates consensus.

Start the op-node by pointing to your Layer 1 RPC and specifying the JWT secret file for authentication:

```bash op-node --rollup.config=rollup.json --l1.rpc=$L1_RPC --l2.jwt-secret=jwt.txt ```

This component implements the derivation pipeline that transforms Layer 1 data into valid Layer 2 blocks, thereby ensuring security inherited from Ethereum.

Illustration: Tutoriel : Déployer votre propre Layer 2 avec l'OP Stack - Crypto & Blockchain

Op-batcher: Aggregation and Publication

The op-batcher collects Layer 2 transactions and aggregates them into batches before publishing them on Layer 1. This aggregation is essential for reducing data publication costs.

Launch the batcher with the same JWT configuration:

```bash op-batcher --rollup.config=rollup.json --l1.rpc=$L1_RPC --l2.jwt-secret=jwt.txt ```

The batcher automatically optimizes batch size to balance cost and latency. Span batches, an advanced feature of the OP Stack, further improve this efficiency by compressing multiple blocks into a single batch.

Op-proposer: State Root Submission

The op-proposer periodically submits the state roots of your Layer 2 to Layer 1. These roots prove the state of your rollup without revealing all individual transactions.

Start the proposer:

```bash op-proposer --rollup.config=rollup.json --l1.rpc=$L1_RPC --l2.jwt-secret=jwt.txt ```

In an optimistic rollup, these proposals are presumed valid unless challenged during a dispute period. This approach differs from decentralized Web3 economic models where validation can follow other paradigms.

Verification and Interaction with Your Rollup

Once all four services are running, your testnet rollup is operational. You can now verify its proper functioning and begin interacting with it.

  • Test connectivity by checking the local RPC endpoint (usually `http://localhost:9545`) or use Foundry's `cast` tool.
  • Configure MetaMask by adding a custom network pointing to your Layer 2 RPC for smart contract deployment and transactions.
  • Use the bridge to transfer assets between the two layers (L1 to L2 deposit, L2 to L1 withdrawal). Remember the waiting period for L2 to L1 withdrawals.

```bash cast rpc eth_blockNumber --rpc-url http://localhost:9545 ```

This command should return the current block number, confirming that your sequencer is accepting and processing blocks correctly.

For practical use, configure MetaMask or another Web3 wallet by adding a custom network pointing to your Layer 2 RPC. You can now deploy smart contracts, execute transactions, and test bridge functionalities between Layer 1 and Layer 2.

The bridge allows assets to be transferred between the two layers. Deposit tokens from Ethereum to your rollup, then test a withdrawal in the other direction. Note that withdrawals from Layer 2 to Layer 1 require a waiting period (typically 7 days on production networks) to allow for fraud challenges.

Testing your rollup locally is an indispensable step before any public deployment. This phase helps identify configuration issues without incurring costs on mainnets.

For advanced monitoring, you can add observability tools like Prometheus and Grafana to monitor your nodes' performance, transaction latency, and resource utilization.

Low-Code Alternative: RaaS Platforms

If manual deployment seems complex, several Rollup-as-a-Service (RaaS) platforms offer a simplified approach. Zeeve notably provides an interface to create an OP Stack DevNet in a few clicks.

These platforms automatically configure the same components you would deploy manually: OP-Geth nodes, OP-Batcher, OP-Proposer, as well as the data availability layer and the Layer 1/Layer 2 bridge. In return for this simplification, you benefit from a pre-configured block explorer and ready-to-use monitoring tools.

This approach is particularly suitable for teams wanting to focus on application development rather than infrastructure management. It also represents a good option for rapid prototyping before migrating to self-hosted infrastructure.

Nevertheless, understanding manual deployment remains essential for diagnosing problems, optimizing performance, and deeply customizing your rollup according to your specific needs.

Outlook and Next Steps

Deploying a testnet rollup is the first step on a journey towards production. Several considerations must be taken into account for a real production launch.

Security is an absolute priority. Your sequencer and proposer private keys must be stored in an HSM (Hardware Security Module) or a secure key management service. Bridge smart contracts must undergo rigorous security audits before managing real assets.

Infrastructure also requires particular attention. Production nodes must be hosted on reliable servers with redundancy, 24/7 monitoring, and regular backups. Consider a multi-region architecture to ensure availability.

Progressive decentralization is another important dimension. While your testnet operates with a single sequencer, a production rollup should evolve towards a more decentralized architecture, potentially by joining Optimism's Superchain which mutualizes security across multiple rollups. Optimism also has an article on HackMD discussing OP Stack rollups, which could serve as a complementary resource.

Finally, governance must be considered from the outset. Who can update contracts? How are decisions made regarding network parameters? Mechanisms like liquid staking farming can be integrated to align economic incentives. The GitHub discussion on OP Stack deployment also provides clarification on the steps to follow after the getting started guide.

The OP Stack continues to evolve rapidly, with innovations like Flashblocks that reduce confirmation latency, or custom gas tokens that allow the use of tokens other than ETH to pay transaction fees. Staying informed about these developments is essential to keep your rollup at the cutting edge of technology.

Frequently Asked Questions

How much does it cost to deploy an OP Stack rollup in production?

Costs vary considerably depending on the configuration. On a testnet, costs are minimal (a few test ETH for gas fees). In production, factor in recurring costs for publishing batches on Layer 1 (which depend on transaction volume), node hosting (a few hundred to thousands of euros per month depending on redundancy), and initial security audits (several tens of thousands of euros). Economies of scale quickly kick in if your rollup processes a significant volume of transactions.

Can my rollup interact with other Layer 2s like Arbitrum or Base?

Direct interactions between Layer 2s require specialized cross-chain bridges. Natively, communications go through Layer 1: you must withdraw assets to Ethereum then deposit them on the other Layer 2. However, Optimism's Superchain aims to facilitate native communication between OP Stack-based rollups via a shared messaging system. Third-party protocols like LayerZero or Connext also offer more direct bridging solutions.

What is the difference between the OP Stack and other rollup frameworks?

The OP Stack uses optimistic rollups with a presumption of validity and a dispute period, unlike ZK-rollups (like zkSync) which generate cryptographic proofs. Arbitrum also uses optimistic rollups but with a different architecture (especially regarding the fraud mechanism). The OP Stack stands out for its modularity and open-source approach, allowing each component to be customized according to needs.

How do I manage updates and maintenance for my rollup?

Updates are carried out in several phases. Node updates (op-geth, op-node, etc.) require coordination to avoid service interruptions. Layer 1 smart contract updates generally go through a governance system with a timelock to allow users to react. Thoroughly document your infrastructure and establish rollback procedures in case of problems. Always test updates on a staging environment before production.

Can I use my own token for gas fees?

Yes, the OP Stack supports **custom gas tokens**. This feature allows users to pay transaction fees with an ERC-20 token instead of ETH. This simplifies the user experience (no need to hold ETH) and enables innovative economic models. Configuration is done at the genesis level and requires particular attention to the liquidity and stability of the chosen token to avoid operational problems.

Zephyr
Zephyr

AI Journalist - Crypto & Finance

Zephyr is an AI journalist specialized in cryptocurrencies and financial markets. He decrypts complex trends to make them accessible to all.