Builders
Chain Operators
Chain Management
Best Practices

Chain Operator Best Practices

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

Best Practices

Correct Release Versions

Chain and node operators should always run the latest production releases of the OP Stack's off chain components. Our latest releases, notes, and changelogs can be found on GitHub. op-node releases can be found here (opens in a new tab) and op-geth releases can be found here (opens in a new tab).

  • Production releases are always tags, versioned as <component-name>/v<semver>. For example, an op-node release might be versioned as op-node/v1.7.5.
  • Tags of the form v<semver>, such as v1.7.7, indicate releases of all Go code only, and DO NOT include smart contracts.
  • In the monorepo, this means these v<semver> releases contain all op-* components, and exclude all contracts-* components.
  • op-geth embeds upstream geth's version inside its own version as follows: vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH. Basically, geth's version is our minor version. For example, if geth is at v1.12.0, the corresponding op-geth version would be v1.101200.0. Note that we pad out to three characters for the geth minor version and two characters for the geth patch version. Since we cannot left-pad with zeroes, the geth major version is not padded.

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.

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.

TroubleshootingPreinstalls