🎉 We are deprecating the Optimism SDK and migrating all tutorials to use viem/op-stack. Read more →
Operators
Chains
Chain management
Best practices

Chain operator best practices

The following information has some best practices around running the OP Stack's off-chain components.

Correct release versions

Chain and node operators should always run the latest production releases of the OP Stack's off-chain components. The latest notes and changelogs can be found on GitHub:

Some guidelines when picking versions:

  • Production releases are always tagged with <component-name>/v<semver> for a specific OP component, for example:

    • op-node/v1.7.5 for the op-node
    • op-challenger/v1.0.0 for the op-challenger

  • Monorepo releases typically use a simple v<semver> format (e.g. v1.7.7) to indicate that all Go-based OP Stack components (in op-*) have been updated together. These do not include new L1 contract releases.

  • Contracts releases are tagged under op-contracts/v<semver> (e.g. op-contracts/v1.6.0) and contain updates to the Bedrock L1 contracts.

  • op-geth versioning includes upstream geth's version within its semver. For example, if upstream geth is at v1.12.0, an op-geth release might be v1.101200.0. The geth major version is used as our minor version (left-padded if needed), and the patch version is appended.

Always consult release notes for additional details or upgrade instructions.

Keep deployment artifacts

After deploying your contracts on Ethereum, you should keep a record of all the deployment artifacts:

  • Contract release tag and commit hash
  • Contract deployment configuration file. This is the JSON file you created and passed to the deployment script when you deployed the contracts.
  • Contract deployment directory with smart contract artifacts. This is created in packages/contracts-bedrock/deployments (opens in a new tab)
  • The rollup configuration file that you generated after the contract deployment
  • The genesis file that you generated after the contract deployment

Incremental upgrade rollouts

When upgrading your nodes, take a staggered approach. This means deploying the upgrade gradually across your infrastructure and ensuring things work as expected before making changes to every node.

Isolate your sequencer

You can isolate your sequencer node, by not connecting it directly to the internet. Instead, you could handle your ingress traffic behind a proxy. Have the proxy forward traffic to replicas and have them gossip the transactions internally.

Improve reliability of peer-to-peer transactions

These flags can improve the reliability of peer-to-peer transactions from internal replica nodes and the sequencer node.

For sequencer nodes:

GETH_TXPOOL_JOURNAL: ""
GETH_TXPOOL_JOURNALREMOTES: "false"
GETH_TXPOOL_NOLOCALS: "true"

For replica nodes:

GETH_TXPOOL_JOURNALREMOTES: "true"
GETH_TXPOOL_LIFETIME: "1h"
GETH_TXPOOL_NOLOCALS: "true"

For additional information about these flags, check out our Execution Layer Configuration Options doc.

Write your own runbooks

Create custom runbooks to prepare for operating an OP Stack chain. For a deeper understanding of daily operations and best practices, explore the public OP Mainnet Runbooks (opens in a new tab) to see how these practices could be applied to your own chain.

Assumptions

op-proposer assumes archive mode

The op-proposer currently assumes that op-geth is being run in archive mode. This will likely be updated in a future network upgrade, but it is necessary for L2 withdrawals at the moment.