The Optimism Monorepo
TL;DR
This is the primary place where Optimism works on stuff related to Optimistic Ethereum.
Documentation
Extensive documentation is available here.
Community
Directory Structure
packages: Contains all the typescript packages and contractscontracts: Solidity smart contracts implementing the OVMcore-utils: Low-level utilities and encoding packagescommon-ts: Common tools for TypeScript code that runs in Nodedata-transport-layer: Event indexer, allowing thel2gethnode to access L1 databatch-submitter: Daemon for submitting L2 transaction and state root batches to L1message-relayer: Service for relaying L2 messages to L1replica-healthcheck: Service to monitor the health of different replica deployments
l2geth: Fork of go-ethereum v1.9.10 implementing the OVM.integration-tests: Integration tests between a L1 testnet,l2geth,ops: Contains Dockerfiles for containerizing each service involved in the protocol, as well as a docker-compose file for bringing up local testnets easily
Contributing
Read through CONTRIBUTING.md for a general overview of our contribution process. Follow the Development Quick Start to set up your local development environment.
Good First Issues
You can find good first issues by filtering for the "good first issue" tag on our issues page or alternatively by taking a look at our Good First Issues project board. If you'd like to tackle one of these issues, please leave a comment and assign yourself to the issue. This helps prevent two people accidentally working on the same task at the same time.
Changesets
We use changesets to manage releases of our various packages. You must include a changeset file in your PR when making a change that would require a new package release.
Adding a changeset file is easy:
- Navigate to the root of the monorepo.
- Run
yarn changeset. You'll be prompted to select packages to include in the changeset. Use the arrow keys to move the cursor up and down, hit thespacebarto select a package, and hitenterto confirm your selection. Select all packages that require a new release as a result of your PR. - Once you hit
enteryou'll be prompted to decide whether your selected packages need amajor,minor, orpatchrelease. We follow the Semantic Versioning scheme. Please avoid usingmajorreleases for any packages that are still in version0.y.z. - Commit your changeset and push it into your PR. The changeset bot will notice your changeset file and leave a little comment to this effect on GitHub.
- Voilà, c'est fini!
Rebasing
We use the git rebase command to keep our commit history tidy. Rebasing is an easy way to make sure that each PR includes a series of clean commits with descriptive commit messages See this tutorial for a detailed explanation of git rebase and how you should use it to maintain a clean commit history.
Development Quick Start
Dependencies
You'll need the following:
Setup
Clone the repository, open it, and install nodejs packages with yarn:
git clone [email protected]:ethereum-optimism/optimism.git
cd optimism
yarn install
Building the TypeScript packages
To build all of the TypeScript packages, run:
yarn clean
yarn build
Packages compiled when on one branch may not be compatible with packages on a different branch. You should recompile all packages whenever you move from one branch to another. Use the above commands to recompile the packages.
Building the rest of the system
If you want to run an Optimistic Ethereum node OR if you want to run the integration tests, you'll need to build the rest of the system.
cd ops
export COMPOSE_DOCKER_CLI_BUILD=1 # these environment variables significantly speed up build time
export DOCKER_BUILDKIT=1
docker-compose build
This will build the following containers:
builder: used to build the TypeScript packagesl1_chain: simulated L1 chain using hardhat-evm as a backenddeployer: process that deploys L1 smart contracts to the L1 chaindtl: service that indexes transaction data from the L1 chainl2geth: L2 geth node running in Sequencer modeverifier: L2 geth node running in Verifier moderelayer: helper process that relays messages between L1 and L2batch_submitter: service that submits batches of Sequencer transactions to the L1 chainintegration_tests: integration tests in a box
If you want to make a change to a container, you'll need to take it down and rebuild it. For example, if you make a change in l2geth:
cd ops
docker-compose stop -- l2geth
docker-compose build -- l2geth
docker-compose start l2geth
For the typescript services, you'll need to rebuild the builder so that the compiled files are re-generated, and then your service, e.g. for the batch submitter
cd ops
docker-compose stop -- batch_submitter
docker-compose build -- builder batch_submitter
docker-compose start batch_submitter
Source code changes can have an impact on more than one container. If you're unsure about which containers to rebuild, just rebuild them all:
cd ops
docker-compose down
docker-compose build
docker-compose up
Finally, if you're running into weird problems and nothing seems to be working, run:
cd optimism
yarn clean
yarn build
cd ops
docker-compose down -v
docker-compose build
docker-compose up
Viewing docker container logs
By default, the docker-compose up command will show logs from all services, and that can be hard to filter through. In order to view the logs from a specific service, you can run:
docker-compose logs --follow <service name>
Running tests
Before running tests: follow the above instructions to get everything built.
Running unit tests
Run unit tests for all packages in parallel via:
yarn test
To run unit tests for a specific package:
cd packages/package-to-test
yarn test
Running integration tests
Follow above instructions for building the whole stack. Build and run the integration tests:
cd integration-tests
yarn build:integration
yarn test:integration
Branching Model and Releases
Active Branches
| Branch | Status |
|---|---|
| master | Accepts PRs from develop when we intend to deploy to mainnet. |
| develop | Accepts PRs that are compatible with master OR from regenesis/X.X.X branches. |
| regenesis/X.X.X | Accepts PRs for all changes, particularly those not backwards compatible with develop and master. |
Overview
We generally follow this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository (e.g., people working at/with Optimism).
The master branch
The master branch contains the code for our latest "stable" releases. Updates from master always come from the develop branch. We only ever update the master branch when we intend to deploy code within the develop to the Optimistic Ethereum mainnet. Our update process takes the form of a PR merging the develop branch into the master branch.
The develop branch
Our primary development branch is develop. develop contains the most up-to-date software that remains backwards compatible with our 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/contracts are usually NOT considered backwards compatible and SHOULD be made against a release candidate branch. Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a release candidate branch 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 the latest release candidate branch. See below for info about release candidate branches.
Release new versions
Developers can release new versions of the software by adding changesets to their pull requests using yarn changeset. Changesets will persist over time on the develop branch without triggering new version bumps to be proposed by the Changesets bot. Once changesets are merged into master, the bot will create a new pull request called "Version Packages" which bumps the versions of packages. The correct flow for triggering releases is to re-base these pull requests onto develop and merge them, and then create a new pull request to merge develop onto master. Then, the release workflow will trigger the actual publishing to npm and Docker hub.
Release candidate branches
Branches marked regenesis/X.X.X are release candidate branches. Changes that are not backwards compatible and all changes to contracts within packages/contracts/contracts MUST be directed towards a release candidate branch. Release candidates are merged into develop and then into master once they've been fully deployed. We may sometimes have more than one active regenesis/X.X.X branch if we're in the middle of a deployment. See table in the Active Branches section above to find the right branch to target.
Additional Reference Material
Running contract static analysis
We perform static analysis with slither. You must have Python 3.x installed to run slither. To run slither locally, do:
cd packages/contracts
pip3 install slither-analyzer
yarn test:slither
License
Code forked from go-ethereum under the name l2geth is licensed under the GNU GPLv3 in accordance with the original license.
All other files within this repository are licensed under the MIT License unless stated otherwise.
0 Jan 4, 2022
9 Jan 7, 2023
10 Apr 19, 2022
0 Jan 2, 2022
3 May 1, 2022
0 Nov 24, 2021
40.8k Jan 8, 2023
1 Oct 14, 2022
0 Jan 3, 2022
18 Sep 20, 2022
2 Sep 28, 2021
7 May 24, 2022
239 Dec 31, 2022
73 Dec 15, 2022
74 Dec 15, 2022
60 Nov 11, 2021
2.9k Jan 1, 2023
15 Nov 29, 2022
14 Apr 28, 2022