This repo is a fork for ethereum-optimism/optimism, in which the Espresso Systems team has integrated the Espresso Sequencer as an option for decentralized sequencing of OP Stack rollups. To learn more about the integration, read our documentation. To try it out for yourself, follow the instructions below.
Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software for running L2 blockchains and aims to address key governance and economic challenges in the wider cryptocurrency ecosystem. Optimism operates on the principle of impact=profit, the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.
In this repository, you'll find numerous core components of the OP Stack, the decentralized software stack maintained by the Optimism Collective that powers Optimism and forms the backbone of blockchains like OP Mainnet and Base. Designed to be "aggressively open source," the OP Stack encourages you to explore, modify, extend, and test the code as needed. Although not all elements of the OP Stack are contained here, many of its essential components can be found within this repository. By collaborating on free, open software and shared standards, the Optimism Collective aims to prevent siloed software development and rapidly accelerate the development of the Ethereum ecosystem. Come contribute, build the future, and redefine power, together.
Espresso helps rollups scale, decentralize, and interoperate.
The Espresso Sequencer offers rollups credible neutrality and enhanced interoperability, without compromising on scale. Consisting of a data availability solution and a decentralized network of nodes that sequences transactions, layer-2 rollups can leverage the Espresso Sequencer to give developers and end users fast confirmations, low (and fair) fees, and robust infrastructure.
-
Install nix if itβs not installed yet: https://nixos.org/download
- On OSX run
sh <(curl -L https://nixos.org/nix/install)
- On Linux run
sh <(curl -L https://nixos.org/nix/install) --daemon
- On OSX run
-
If docker is not yet installed or running, install docker and start it
-
On OSX: If you already have docker desktop installed and running you can keep using docker desktop and skip this step. Otherwise the quickest way to get docker is:
brew update brew install colima docker docker-compose # The number of CPUs and GBs of RAM will be reserved for running the demo # If you have RAM to spare consider using 4 or 8 GB instead. colima start --cpu 4 --memory 2 --vm-type=vz
-
On Linux follow for example the instructions here: https://docs.docker.com/engine/install/
-
-
Download the demo source code
# Takes about 1 minute git clone --recursive https://github.com/EspressoSystems/op-espresso-integration
-
Run the demo
cd op-espresso-integration git pull # Activate the development env # Takes about 1.5 minutes the first time (with fast network connection), # Should only take a few seconds when activated again afterwards. # All the `make` commands below need to be run in a terminal where the # nix-shell is activated. nix-shell # Setup the repo # Takes about 2 minutes the first time make # Takes about 1 minute, **only needs to be run once** make cannon-prestate # Build and launch the first rollup, L1, and sequencer # Takes about 5 minutes the first time. make devnet-up-espresso # After that finishes to deploy the second rollup on the existing L1 and sequencer make devnet-up-espresso2 # To run tests to check if it's working (these must be run in serial, since both tests make use # of the same L1 account). make devnet-test-espresso make devnet-test-espresso2 # To stop the demo make devnet-clean
-
Navigate to http://localhost:14000 to see the block explorer. If you started the second rollup, its block explorer can be found at http://localhost:24000. If the bock explorers are successfully syncing, a new block appears every few seconds.
-
Setup metamask
π‘ If the demo is restarted metamask nonces need to be reset: Settings β Advanced β Clear activity tab data-
Open chrome (other chrome based browsers such as chromium, brave; firefox should work too).
-
[optional, but suggested] create a new browser profile
-
Add the metamask extension
-
One the βLetβs get started pageβ Click βImport an existing walletβ
-
Restore from mnemonic
test test test test test test test test test test test junk
The whole mnemonic can be copy pasted at once by pasting it into the field of the first word.
-
As the mnemonic is not secret, feel free to use a dummy password such as 12341234.
-
-
Connect metamask to the L2s. Custom networks needs to be added for each of the OP rollups.
-
In metamask, go to
Settings -> Networks -> Add a network -> Add a network manually
Parameter Value for OP node 1 Value for OP node 2 Notes Network name Espresso OP 1 Espresso OP 2 Set as desired RPC URL http://localhost:19090 http://localhost:29090 Chain ID 901 902 Currency Symbol OP1 OP2 For display purposes only. It can be chosen freely, but note this will show in the metamask UI Block explorer http://localhost:14000 http://localhost:24000 -
Your settings should look something like this:
-
Note that metamask wonβt let one save this custom network if the demo is not running.
-
-
Use metamask as usual to send ETH
-
When a transaction is confirmed in your MetaMask Activity tab, you can click on it and click βView on block explorerβ to see the transaction.
-
To add the ERC20 token click on "Tokens" -> "Import tokens" and paste the address
0xfbfbfDdd6e35dA57b7B0F9a2C10E34Be70B3A4E9
. The address is the same for both L2s. To mint tokens, send ether to this contract addresses.
-
- If you want to build on top of OP Mainnet, refer to the Optimism Community Hub
- If you want to build your own OP Stack based blockchain, refer to the OP Stack docs
- If you want to contribute to the OP Stack, check out the Protocol Specs
General discussion happens most frequently on the Optimism discord. Governance discussion can also be found on the Optimism Governance Forum.
Read through CONTRIBUTING.md for a general overview of the contributing process for this repository. Use the Developer Quick Start to get your development environment set up to start working on the Optimism Monorepo. Then check out the list of Good First Issues to find something fun to work on!
Please refer to the canonical Security Policy document for detailed information about how to report vulnerabilities in this codebase. Bounty hunters are encouraged to check out the Optimism Immunefi bug bounty program. The Optimism Immunefi program offers up to $2,000,042 for in-scope critical vulnerabilities.
OP Mainnet is currently preparing for its next major upgrade, Bedrock. You can find detailed specifications for the Bedrock upgrade within the specs folder in this repository.
Please note that a significant number of packages and folders within this repository are part of the Bedrock upgrade and are NOT currently running in production. Refer to the Directory Structure section below to understand which packages are currently running in production and which are intended for use as part of the Bedrock upgrade.
βββ docs: A collection of documents including audits and post-mortems βββ op-bindings: Go bindings for Bedrock smart contracts. βββ 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-exporter: Prometheus exporter client βββ 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-wheel: Database utilities βββ ops-bedrock: Bedrock devnet work βββ packages β βββ chain-mon: Chain monitoring services β βββ common-ts: Common tools for building apps in TypeScript β βββ contracts-ts: ABI and Address constants β βββ contracts-bedrock: Bedrock smart contracts β βββ core-utils: Low-level utilities that make building Optimism easier β βββ sdk: provides a set of tools for interacting with Optimism βββ proxyd: Configurable RPC request router and proxy βββ specs: Specs of the rollup starting at the Bedrock upgrade
Branch | Status |
---|---|
master | Accepts PRs from develop when intending to deploy to production. |
develop | Accepts PRs that are compatible with master OR from release/X.X.X branches. |
release/X.X.X | Accepts PRs for all changes, particularly those not backwards compatible with develop and master . |
This repository generally follows this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository.
The production branch is master
.
The master
branch contains the code for latest "stable" releases.
Updates from master
always come from the develop
branch.
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 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.
Branches marked release/X.X.X
are release candidate branches.
Changes that are not backwards compatible and all changes to contracts within packages/contracts-bedrock/src
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 release/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.
We use changesets to mark packages for new releases.
When merging commits to the develop
branch you MUST include a changeset file if your change would require that a new version of a package be released.
To add a changeset, run the command pnpm changeset
in the root of this monorepo.
You will be presented with a small prompt to select the packages to be released, the scope of the release (major, minor, or patch), and the reason for the release.
Comments within changeset files will be automatically included in the changelog of the package.
Releases can be triggered using the following process:
- Create a PR that merges the
develop
branch into themaster
branch. - Wait for the auto-generated
Version Packages
PR to be opened (may take several minutes). - Change the base branch of the auto-generated
Version Packages
PR frommaster
todevelop
and merge intodevelop
. - Create a second PR to merge the
develop
branch into themaster
branch.
After merging the second PR into the master
branch, packages will be automatically released to their respective locations according to the set of changeset files in the develop
branch at the start of the process.
Please carry this process out exactly as listed to avoid develop
and master
falling out of sync.
NOTE: PRs containing changeset files merged into develop
during the release process can cause issues with changesets that can require manual intervention to fix.
It's strongly recommended to avoid merging PRs into develop during an active release.
All other files within this repository are licensed under the MIT License unless stated otherwise.