This is where [Optimism](https://optimism.io) gets built.
Optimism is a low-cost and lightning-fast Ethereum L2 blockchain, **but it's also so much more than that**.
Optimism is the technical foundation for [the Optimism Collective](https://app.optimism.io/announcement), a band of communities, companies, and citizens united by a mutually beneficial pact to adhere to the axiom of **impact=profit** — the principle that positive impact to the collective should be rewarded with profit to the individual.
We're trying to solve some of the most critical coordination failures facing the crypto ecosystem today.
**We're particularly focused on creating a sustainable funding stream for the public goods and infrastructure upon which the ecosystem so heavily relies but has so far been unable to adequately reward.**
We'd love for you to check out [The Optimistic Vision](https://www.optimism.io/vision) to understand more about why we do what we do.
## Documentation
Extensive documentation is available [here](http://community.optimism.io/).
If you want to build on top of Optimism, take a look at the extensive documentation on the [Optimism Community Hub](http://community.optimism.io/).
If you want to build Optimism, check out the [Protocol Specs](./specs/).
## Community
Come hang on our very active [discord](https://discord.optimism.io) 🔴✨
General discussion happens most frequently on the [Optimism discord](https://discord.optimism.io).
Governance discussion can also be found on the [Optimism Governance Forum](https://gov.optimism.io/).
## Contributing
Read through [CONTRIBUTING.md](./CONTRIBUTING.md) for a general overview of our contribution process.
Use the [Developer Quick Start](./CONTRIBUTING.md#development-quick-start) to get your development environment set up to start working on the Optimism Monorepo.
Then check out our list of [good first issues](https://github.com/ethereum-optimism/optimism/contribute) to find something fun to work on!
## Security Policy and Vulnerability Reporting
Please refer to our canonical [Security Policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md) document for detailed information about how to report vulnerabilities in this codebase.
Bounty hunters are encouraged to check out [our Immunefi bug bounty program](https://immunefi.com/bounty/optimism/).
We offer up to $2,000,042 for in-scope critical vulnerabilities and [we pay our maximum bug bounty rewards](https://medium.com/ethereum-optimism/disclosure-fixing-a-critical-bug-in-optimisms-geth-fork-a836ebdf7c94).
## The Bedrock Upgrade
Optimism is currently preparing for [its next major upgrade called Bedrock](https://dev.optimism.io/introducing-optimism-bedrock/).
Bedrock significantly revamps how Optimism works under the hood and will help make Optimism the fastest, cheapest, and most reliable rollup yet.
You can find detailed specifications for the Bedrock upgrade within the [specs folder](./specs) 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.
## Directory Structure
<pre>
root
~~ Production ~~
├── <ahref="./packages">packages</a>
│ ├── <ahref="./packages/common-ts">common-ts</a>: Common tools for building apps in TypeScript
│ ├── <ahref="./packages/contracts">contracts</a>: L1 and L2 smart contracts for Optimism
...
...
@@ -38,12 +59,9 @@ root
│ ├── <ahref="./packages/data-transport-layer">data-transport-layer</a>: Service for indexing Optimism-related L1 data
│ ├── <ahref="./packages/drippie-mon">drippie-mon</a>: Service for monitoring Drippie instances
│ ├── <ahref="./packages/fault-detector">fault-detector</a>: Service for detecting Sequencer faults
│ └── <ahref="./packages/contracts-bedrock">contracts-bedrock</a>: Bedrock smart contracts. To be merged with ./packages/contracts.
├── <ahref="./op-bindings">op-bindings</a>: Go bindings for Bedrock smart contracts.
├── <ahref="./op-batcher">op-batcher</a>: L2-Batch Submitter, submits bundles of batches to L1
├── <ahref="./op-e2e">op-e2e</a>: End-to-End testing of all bedrock components in Go
...
...
@@ -68,9 +88,7 @@ root
└── <ahref="./specs">specs</a>: Specs of the rollup starting at the Bedrock upgrade
</pre>
## Branching Model and Releases
<!-- TODO: explain about changesets + how we do npm publishing + docker publishing -->
## Branching Model
### Active Branches
...
...
@@ -85,14 +103,15 @@ root
We generally follow [this Git branching model](https://nvie.com/posts/a-successful-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
### Production branch
Our production branch is `master`.
The `master` branch contains the code for our latest "stable" releases.
Updates from `master`always come from the `develop` branch.
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 Optimism mainnet.
Our update process takes the form of a PR merging the `develop` branch into the `master` branch.
### The `develop` branch
### Development branch
Our primary development branch is [`develop`](https://github.com/ethereum-optimism/optimism/tree/develop/).
`develop` contains the most up-to-date software that remains backwards compatible with our latest experimental [network deployments](https://community.optimism.io/docs/useful-tools/networks/).
...
...
@@ -103,12 +122,6 @@ Some exceptions to this rule exist for cases in which we absolutely must deploy
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 update the base branch of these pull requests onto `develop` and merge them, and then create a new pull request to merge `develop` into `master`. Then, the `release` workflow will trigger the actual publishing to `npm` and Docker hub.
Be sure to not merge other pull requests into `develop` if partially through the release process. This can cause problems with Changesets doing releases and will require manual intervention to fix it.
### Release candidate branches
Branches marked `release/X.X.X` are **release candidate branches**.
...
...
@@ -117,9 +130,31 @@ Release candidates are merged into `develop` and then into `master` once they've
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.
### Releasing new versions
## Releases
### Changesets
We use [changesets](https://github.com/changesets/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 `yarn 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 with in changeset files will be automatically included in the changelog of the package.
### Triggering Releases
Releases can be triggered using the following process:
1. Create a PR that merges the `develop` branch into the `master` branch.
2. Wait for the auto-generated `Version Packages` PR to be opened (may take several minutes).
3. Change the base branch of the auto-generated `Version Packages` PR from `master` to `develop` and merge into `develop`.
4. Create a second PR to merge the `develop` branch into the `master` 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.
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.
**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.
require.Equal(t,verifier.L2Safe(),sequencer.L2Safe(),"verifier and sequencer see same safe L2 block, while only verifier dealt with the orphan and replay")
//t.Logf("l2 unsafe head %s with origin %s", ref, ref.L1Origin)
//require.NotEqual(t, verifier.L2Unsafe().Hash, ref.ParentHash, "TODO off by one, engine syncs A0 after reorging back from B, while rollup node only inserts up to A0 (excl.)")
//require.Equal(t, verifier.L2Unsafe(), ref, "verifier safe head of engine matches rollup client")
// now sync the verifier: some of the batches should be ignored:
// The safe head should have a genesis L1 origin, but past genesis, as some L2 blocks were built to get to A0 time
verifier.ActL1HeadSignal(t)
verifier.ActL2PipelineFull(t)
require.Equal(t,sd.RollupCfg.Genesis.L1,verifier.L2Safe().L1Origin,"expected to be back at genesis origin after losing A0 and A1")
require.NotZero(t,verifier.L2Safe().Number,"still preserving old L2 blocks that did not reference reorged L1 chain (assuming more than one L2 block per L1 block)")
require.Equal(t,verifier.L2Safe(),verifier.L2Unsafe(),"head is at safe block after L1 reorg")
checkVerifEngine()
// and sync the sequencer, then build some new L2 blocks, up to and including with L1 origin B2
sequencer.ActL1HeadSignal(t)
sequencer.ActL2PipelineFull(t)
sequencer.ActBuildToL1Head(t)
require.Equal(t,sequencer.L2Unsafe().L1Origin,blockB2.ID(),"B2 is the unsafe L1 origin of sequencer now")
// submit all new L2 blocks for chain B, and include in new block B3
// note: we do not clear the unsafe payloadds queue; if the payloads are not applicable anymore the parent hash checks will clear out the old payloads.
This README describes how to use the actor testing library to write new tests. If you're just looking for how to run test cases, check out the README [in the root of the repo](../README.md).
The token and governance smart contracts for the Optimism DAO. Built using [OpenZeppelin libraries](https://docs.openzeppelin.com/contracts/4.x/) with some customisations. The token is an [ERC20](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) that is [permissible](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC20Permit) and allows for [delegate voting](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC20Votes). The token is also [burnable](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC20Burnable). See more in the [Specification section](#specification).
`@eth-optimism/contracts` contains the various Solidity smart contracts used within the Optimism system.
Some of these contracts are [meant to be deployed to Ethereum ("Layer 1")](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/contracts/L1), while others are [meant to be deployed to Optimism ("Layer 2")](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/contracts/L2).
Within each contract file you'll find the network upon which the contract is meant to be deloyed, listed as either `EVM` (for Ethereum) or `OVM` (for Optimism).
The Optimism Data Transport Layer is a long-running software service (written in TypeScript) designed to reliably index Optimism transaction data from Layer 1 (Ethereum). Specifically, this service indexes:
The `fault-detector` is a simple service for detecting discrepancies between your local view of the Optimism network and the L2 output proposals published to Ethereum.
`replica-healthcheck` is an express server to be run alongside a replica instance, to ensure that the replica is healthy. Currently, it exposes metrics on syncing stats and exits when the replica has a mismatched state root against the sequencer.
![mergify[bot]'s avatar](https://secure.gravatar.com/avatar/e3df20cd7a67969c41a65f03bea54961?s=48&d=identicon "mergify[bot]")