OP Stack deployment overview
When deploying a standard OP Stack chain, you'll be setting up several key components. It's useful to understand what each of these components does before you start deploying your chain. The following information assumes you're deploying a Rollup on Ethereum, but most concepts apply generally to any standard OP Stack deployment.
Smart contracts
The OP Stack uses a set of smart contracts on the L1 blockchain to manage aspects of the Rollup. Each OP Stack chain has its own set of L1 smart contracts that are deployed when the chain is created.
Standard OP Stack chains should only use governance approved and audited
smart contracts. The monorepo has them tagged with the following pattern
op-contracts/vX.X.X and you can review the release notes for details on the
changes. Read more about the details in our Smart Contract Release Section.
Sequencer node
OP Stack chains use a Sequencer node to gather proposed transactions from users and publish them to the L1 blockchain. OP Stack chains rely on at least one of these Sequencer nodes. You can also run additional replica (non-Sequencer) nodes.
Consensus client
OP Stack Rollup nodes, like Ethereum nodes, have a consensus client. The
consensus client is responsible for determining the list and ordering of blocks
and transactions that are part of your blockchain. Several implementations of
the OP Stack consensus client exist, including op-node (maintained by the
Optimism Foundation), magi (opens in a new tab) (maintained by
a16z) and hildr (opens in a new tab) (maintained by OptimismJ).
Execution client
OP Stack nodes, like Ethereum nodes, also have an execution client. The
execution client is responsible for executing transactions and maintaining the
state of the blockchain. Various implementations of the OP Stack execution
client exist, including op-geth (maintained by the Optimism Foundation),
op-erigon (opens in a new tab) (maintained by Test
in Prod), and op-nethermind (opens in a new tab).
Batcher
The Batcher is a service that publishes transactions from the Rollup to the L1 blockchain. The Batcher runs continuously alongside the Sequencer and publishes transactions in regular batches.
Proposer
The Proposer is a service responsible for publishing transactions results (in the form of L2 state roots) to the L1 blockchain. This allows smart contracts on L1 to read the state of the L2, which is necessary for cross-chain communication and reconciliation between state changes.
Challenger
The Challenger enforces network security by disputing invalid state roots (if any) that have been posted by the Proposer. It monitors on-chain data and, in the event of a suspected fraud, triggers a fault proof or another dispute mechanism to invalidate the erroneous data.
Software dependencies
| Dependency | Version | Version Check Command |
|---|---|---|
| git (opens in a new tab) | ^2 | git --version |
| go (opens in a new tab) | ^1.21 | go version |
| node (opens in a new tab) | ^20 | node --version |
| pnpm (opens in a new tab) | ^8 | pnpm --version |
| foundry (opens in a new tab) | ^0.2.0 | forge --version |
| make (opens in a new tab) | ^3 | make --version |
| jq (opens in a new tab) | ^1.6 | jq --version |
Notes on specific dependencies
node
We recommend using the latest LTS version of Node.js (currently v20).
nvm (opens in a new tab) is a useful tool that can help you
manage multiple versions of Node.js on your machine. You may experience
unexpected errors on older versions of Node.js.
foundry
It's recommended to use the scripts in the monorepo's package.json for
managing foundry to ensure you're always working with the correct version.
This approach simplifies the installation, update, and version checking
process.
Next steps
- Discover how to deploy the smart contracts.
- Find out how to create your genesis file.
- Explore some chain operator best practices.