Tutorial: Deploy Your Own Layer 2 with the OP Stack
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.
| Component | Primary Role |
|---|---|
| `op-geth` | L2 Execution Client |
| `op-node` | L2 Consensus Client |
| `op-batcher` | Batch Aggregation and Publication |
| `op-proposer` | State Root Submission |
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.
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.