Spark is an Ethereum L2 setup for experiments and tests.
├── docs: A collection of documents including audits and post-mortems ├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1 ├── op-bootnode: Standalone op-node discovery bootnode ├── op-chain-ops: State surgery utilities ├── op-challenger: Dispute game challenge agent ├── op-e2e: End-to-End testing of all bedrock components in Go ├── op-heartbeat: Heartbeat monitor service ├── op-node: rollup consensus-layer client ├── op-preimage: Go bindings for Preimage Oracle ├── op-program: Fault proof program ├── op-proposer: L2-Output Submitter, submits proposals to L1 ├── op-service: Common codebase utilities ├── op-ufm: Simulations for monitoring end-to-end transaction latency ├── op-wheel: Database utilities ├── ops: Various operational packages ├── ops-bedrock: Bedrock devnet work ├── packages │ ├── contracts-bedrock: OP Stack smart contracts ├── proxyd: Configurable RPC request router and proxy ├── specs: Specs of the rollup starting at the Bedrock upgrade
Please read this section carefully if you're planning to fork or make frequent PRs into this repository.
Production releases are always tags, versioned as <component-name>/v<semver>.
For example, an op-node release might be versioned as op-node/v1.1.2, and smart contract releases might be versioned as op-contracts/v1.0.0.
Release candidates are versioned in the format op-node/v1.1.2-rc.1.
We always start with rc.1 rather than rc.
For contract releases, refer to the GitHub release notes for a given release which will list the specific contracts being released. Not all contracts are considered production ready within a release and many are under active development.
Tags of the form v<semver>, such as v1.1.4, indicate releases of all Go code only, and DO NOT include smart contracts.
This naming scheme is required by Golang.
In the above list, 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.
See the Node Software Releases page of the documentation for more information about releases for the latest node components.
The full set of components that have releases are:
ci-builderop-batcherop-contractsop-challengerop-heartbeatop-nodeop-proposerop-ufmproxyd
All other components and packages should be considered development components only and do not have releases.
The primary development branch is develop.
develop contains the most up-to-date software that remains backwards compatible with the latest experimental network deployments.
If you're making a backwards compatible change, please direct your pull request towards develop.
Changes to contracts within packages/contracts-bedrock/src are usually NOT considered backwards compatible.
Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a tag has already been fully deployed.
If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using a feature branch.
Feature branches are typically used when there are conflicts between 2 projects touching the same code, to avoid conflicts from merging both into develop.
All other files within this repository are licensed under the MIT License unless stated otherwise.