Package Exports

@eth-optimism/contracts-bedrock
@eth-optimism/contracts-bedrock/deployments/goerli/L2OutputOracleProxy.json
@eth-optimism/contracts-bedrock/deployments/goerli/OptimismPortalProxy.json
@eth-optimism/contracts-bedrock/deployments/mainnet/L2OutputOracleProxy.json
@eth-optimism/contracts-bedrock/deployments/mainnet/OptimismPortalProxy.json
@eth-optimism/contracts-bedrock/dist/index.js

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (@eth-optimism/contracts-bedrock) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

Optimism Smart Contracts (Bedrock)

This package contains the smart contracts that compose the on-chain component of Optimism's upcoming Bedrock upgrade. We've tried to maintain 100% backwards compatibility with the existing system while also introducing new useful features. You can find detailed specifications for the contracts contained within this package here.

A style guide we follow for writing contracts can be found here.

Contracts Overview

Contracts deployed to L1

Name	Proxy Type	Description
`L1CrossDomainMessenger`	`ResolvedDelegateProxy`	High-level interface for sending messages to and receiving messages from Optimism
`L1StandardBridge`	`L1ChugSplashProxy`	Standardized system for transfering ERC20 tokens to/from Optimism
`L2OutputOracle`	`Proxy`	Stores commitments to the state of Optimism which can be used by contracts on L1 to access L2 state
`OptimismPortal`	`Proxy`	Low-level message passing interface
`OptimismMintableERC20Factory`	`Proxy`	Deploys standard `OptimismMintableERC20` tokens that are compatible with either `StandardBridge`
`ProxyAdmin`	-	Contract that can upgrade L1 contracts

Contracts deployed to L2

Name	Proxy Type	Description
`GasPriceOracle`	`Proxy`	Stores L2 gas price configuration values
`L1Block`	`Proxy`	Stores L1 block context information (e.g., latest known L1 block hash)
`L2CrossDomainMessenger`	`Proxy`	High-level interface for sending messages to and receiving messages from L1
`L2StandardBridge`	`Proxy`	Standardized system for transferring ERC20 tokens to/from L1
`L2ToL1MessagePasser`	`Proxy`	Low-level message passing interface
`SequencerFeeVault`	`Proxy`	Vault for L2 transaction fees
`OptimismMintableERC20Factory`	`Proxy`	Deploys standard `OptimismMintableERC20` tokens that are compatible with either `StandardBridge`
`L2ProxyAdmin`	-	Contract that can upgrade L2 contracts when sent a transaction from L1

Legacy and deprecated contracts

Name	Location	Proxy Type	Description
`AddressManager`	L1	-	Legacy upgrade mechanism (unused in Bedrock)
`DeployerWhitelist`	L2	`Proxy`	Legacy contract for managing allowed deployers (unused since EVM Equivalence upgrade)
`L1BlockNumber`	L2	`Proxy`	Legacy contract for accessing latest known L1 block number, replaced by `L1Block`

Installation

We export contract ABIs, contract source code, and contract deployment information for this package via npm:

npm install @eth-optimism/contracts-bedrock

Development

Dependencies

We work on this repository with a combination of Hardhat and Foundry.

Install Foundry by following the instructions located here. A specific version must be used.
```
foundryup -C da2392e58bb8a7fefeba46b40c4df1afad8ccd22
```
Install node modules with yarn (v1) and Node.js (16+):
```
yarn install
```

Build

yarn build

Tests

yarn test

Running Echidna tests

You must have Echidna installed.

Contracts targetted for Echidna testing are located in ./contracts/echidna Each target contract is tested with a separate yarn command, for example:

yarn echidna:aliasing

Deployment

Configuration

Create or modify a file <network-name>.ts inside of the deploy-config folder.
Fill out this file according to the deployConfigSpec located inside of the [`hardhat.config.ts](./hardhat.config.ts)
Optionally: Run npx hardhat generate-deploy-config --network <network-name> to generate the associated JSON file. This is required if using op-chain-ops.

Execution

Copy .env.example into .env
Fill out the L1_RPC and PRIVATE_KEY_DEPLOYER environment variables in .env
Run npx hardhat deploy --network <network-name> to deploy the L1 contracts
Run npx hardhat etherscan-verify --network <network-name> --sleep to verify contracts on Etherscan

Tools

Layout Locking

We use a system called "layout locking" as a safety mechanism to prevent certain contract variables from being moved to different storage slots accidentally. To lock a contract variable, add it to the layout-lock.json file which has the following format:

{
  "MyContractName": {
    "myVariableName": {
      "slot": 1,
      "offset": 0,
      "length": 32
    }
  }
}

With the above config, the validate-spacers hardhat task will check that we have a contract called MyContractName, that the contract has a variable named myVariableName, and that the variable is in the correct position as defined in the lock file. You should add things to the layout-lock.json file when you want those variables to never change. Layout locking should be used in combination with diffing the .storage-layout file in CI.