Skip to content

Files

op-chain-ops

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
May 2, 2025
Jun 13, 2024
May 1, 2025
Dec 23, 2024
Nov 7, 2024
Apr 2, 2025
May 6, 2025
May 5, 2025
May 1, 2025
Apr 24, 2025
Oct 30, 2024
Sep 12, 2024
Jan 13, 2025
Mar 27, 2025
Jan 13, 2025

op-chain-ops

Issues: monorepo

Pull requests: monorepo

This is an OP Stack utils package for chain operations, ranging from EVM tooling to chain generation.

Packages:

  • clients: utils for chain checker tools.
  • cmd: upgrade validation tools, debug tools, attributes formatting tools.
  • crossdomain: utils to interact with L1 <> L2 cross-domain messages.
  • devkeys: generate OP-Stack development keys from a common source.
  • foundry: utils to read foundry artifacts.
  • genesis: OP Stack genesis-configs generation, pre OPCM.
  • interopgen: interop test-chain genesis config generation.
  • script: foundry-like solidity scripting environment in Go.
  • solc: utils to read solidity compiler artifacts data.
  • srcmap: utils for solidity source-maps loaded from foundry-artifacts.

Usage

Upgrade checks and chain utilities can be found in ./cmd: these are not officially published in OP-Stack monorepo releases, but can be built from source.

Utils:

cmd/
├── check-canyon                  - Checks for Canyon network upgrade
├── check-delta                   - Checks for Delta network upgrade
├── check-deploy-config           - Checks of the (legacy) Deploy Config
├── check-derivation              - Check that transactions can be confirmed and safety can be consolidated
├── check-ecotone                 - Checks for Ecotone network upgrade
├── check-fjord                   - Checks for Fjord network upgrade
├── check-prestate                - Checks a fault proof absolute prestate's chain compatibility. e.g: go run cmd/check-prestate --prestate-hash <HASH>
├── deposit-hash                  - Determine the L2 deposit tx hash, based on log event(s) emitted by a L1 tx.
├── ecotone-scalar                - Translate between serialized and human-readable L1 fee scalars (introduced in Ecotone upgrade).
├── op-simulate                   - Simulate a remote transaction in a local Geth EVM for block-processing debugging.
├── protocol-version              - Translate between serialized and human-readable protocol versions.
├── receipt-reference-builder     - Receipt data collector for pre-Canyon deposit-nonce metadata.
└── unclaimed-credits             - Utility to inspect credits of resolved fault-proof games.

Product

Optimization target

Provide tools for chain-setup and inspection tools for deployment, upgrades, and testing. This includes op-deployer, OP-Contracts-Manager (OPCM), upgrade-check scripts, and op-e2e testing.

Vision

  • Upgrade checking scripts should become more extensible, and maybe be bundled in a single check-script CLI tool.
  • Serve chain inspection/processing building-blocks for test setups and tooling like op-deployer.
  • interopgen is meant to be temporary, and consolidate with op-deployer. This change depends largely on the future of op-e2e, where system tests may be replaced in favor of tests set up by op-e2e.
  • script is a Go version of forge script, with hooks and customization options, for better integration into tooling such as op-deployer. This package should evolve to serve testing and op-deployer as best as possible, it is not a full forge replacement.
  • genesis will shrink over time, as more of the genesis responsibilities are automated away into the protocol through system-transactions, and tooling such as op-deployer and OPCM.

Design principles

  • Provide high-quality bindings to accelerate testing and tooling development.
  • Minimal introspection into fragile solidity details.

There is a trade-off here in how minimal the tooling is: generally we aim to provide dedicated functionality in Go for better integration, if the target tool is significant Go service of its own. If not, then op-chain-ops should not be extended, and the design of the target tool should be adjusted instead.

Testing

  • Upgrade checks are tested against live devnet/testnet upgrades, before testing against mainnet. Testing here is aimed to expand to end-to-end testing, for better integrated test feedback of these tools.
  • Utils have unit-test coverage of their own, and are used widely in end-to-end testing itself.