Learn about the stages of the OP Deployer deployment pipeline.
OP Deployer is architected as a pipeline where each stage is responsible for a single piece of the deployment process.
The pipeline consumes a configuration called an intent which describes the desired state of the chain, and
produces a file called the state which describes the current state of the chain during and after the deployment.
The steps of the pipeline are:
Initialization
Superchain Deployment
Implementations Deployment
OP Chain Deployment
Alt-DA Deployment
Dispute Game Deployment
L2 Genesis Generation
Setting Start Block
State is written to disk after each state. This allows the pipeline to be restarted from any point in the event of a
recoverable error.We’ll cover each of these stages in more detail below.
During this step, OP Deployer sets initial values for the pipeline based on the user’s intent. These values will be
used by downstream stages. For example, if the user is deploying using an existing set of Superchain contracts,
those contracts will be inserted into the state during this step.
Next, the base contracts for the chain are deployed. This includes Superchain-wide contracts like the
SuperchainConfig and ProtocolVersions, as well as implementation contracts that will be used for the OP Chain
deployment in the future like the OP Contracts Manager (OPCM).Most chains will be configured to use existing implementations. In this case, these steps will be skipped.
The OP Chain itself is deployed during this step. Multiple chains will be deployed if they are specified in the
intent. The deployment works by calling into the OPCM, which will emit an event for each successfully-deployed chain.
The next two steps (Alt-DA and Dispute Game) deploy customizations. As their names imply, they deploy Alt-DA and
additional dispute game contracts. Typically, these steps will be skipped as they are mostly useful in testing.
This step generates the L2 Genesis file which is used to initialize the chain. This file is generated by calling
into L2Genesis.sol, and dumping the outputted state.
Lastly, the start block is set to the current block number on L1. This is done last to ensure that the start block
is relatively recent, since the deployment process can take arbitrarily long.