Metis is a Layer 2 scaling protocol for Ethereum applications. I.e., it makes transactions faster and cheaper. We aim to make transactions on Ethereum affordable and accessible to anyone.
This document is intended for people looking for a deeper understanding of how the protocol works 'under the hood'. If you just want to skip straight to integrating your smart contract application with OE, check out the Development Docs.
Metis is meant to look, feel and behave like Ethereum but cheaper and faster. For developers building on Metis, we aim to make the transition as seamless as possible. With very few exceptions, existing Solidity smart contracts can run on L2 exactly how they run on L1. Similarly, off-chain code (ie. UIs and wallets), should be able to interact with L2 contract with little more than an updated RPC endpoint.
The smart contracts in the Metis protocol can be separated into a few key components. We will discuss each component in more detail below.
Messaging: Contracts which facilitate message passing from layer-1 to layer-2.
Rollup: Contracts on layer-1, which hold the ordering of layer-2 transactions, and commitments to the associated layer-2 state roots.
Messaging: Contracts which facilitate message passing from layer-2 to layer-1.
Predeploys: A set of essential contracts which are deployed and available in the genesis state of the system. These contracts are similar to Ethereum's precompiles, however they are written in Solidity, and can be found at addresses prefixed with 0x42.
L1 Messaging is composed of the following contracts.
L1 Cross Domain Messenger
The L1 Cross Domain Messenger contract sends messages from L1 to L2, and relays messages from L2 onto L1. If a message sent from L1 to L2 is rejected for exceeding the L2 epoch gas limit, it can be resubmitted via this contract's replay function.
L1 Standard Bridge
The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard tokens that are in use on L2. It synchronizes with a corresponding L2 Bridge, informing it of deposits and listening to it for newly finalized withdrawals.
Layer-1 Rollup Contracts
is composed of a set of contracts running on the Ethereum Mainnet. These contracts store ordered lists of:
1. An ordered list of all transactions applied to the L2 state.
2. The proposed state root which would results from the application of each transaction.
3. Transactions sent from L1 to L2, which are pending inclusion in the ordered list.
The chain is composed of the following concrete contracts:
Canonical Transaction Chain (CTC)
The Canonical Transaction Chain (CTC) contract is an append-only log of transaction which must be applied to the rollup state. It defines the ordering of rollup transactions by writing them to the 'CTC:batches' instance of the Chain Storage Container. The CTC also allows any account to 'enqueue' an L2 transaction, which will require that the Sequencer eventually append it to the rollup state.
State Commitment Chain (SCC)
The State Commitment Chain (SCC) contract contains a list of proposed state roots whose Proposers assert to be a result of each transaction in the Canonical Transaction Chain (CTC). Elements here have a 1:1 correspondence with transactions in the CTC, and should be the unique state root calculated off-chain by applying the canonical transactions one by one.
Chain Storage Container
The Chain Storage Container provides its owner contract with read, write and delete functionality. This provides gas efficiency gains by enabling it to overwrite storage slots which can no longer be used in a fraud proof due to the fraud window having passed, and the associated chain state or transactions being finalized.
Three distinct Chain Storage Containers will be deployed on Layer-1:
1. Stores transaction batches for the Canonical Transaction Chain
2. Stores queued transactions for the Canonical Transaction Chain
3. Stores chain state batches for the State Commitment Chain
For now, a stub of the "real" BondManager that does nothing but allow the"OVM_Proposer" to submit state root batches.
L2 Cross Domain Messenger
The L2 Cross Domain Messenger contract sends messages from L2 to L1, and is the entry point for L2 messages sent via the L1 Cross Domain Messenger.
L2 Standard Bridge
The L2 Standard Bridge is a contract which works together with the L1 Standard bridge to enable ETH and ERC20 transitions between L1 and L2. This contract acts as a minter for new tokens when it hears about deposits into the L1 Standard bridge. It also acts as a burner of the tokens intended for withdrawal, informing the L1 bridge to release L1 funds.
L2 Standard Token Factory
Factory contract for creating standard L2 token representations of L1 and working on the standard bridge.
The Deployer Whitelist is a temporary predeploy used to provide additional safety during the initial phases of our mainnet roll out. It is owned by the Metis team, and defines accounts which are allowed to deploy contracts on Layer2. The Execution Manager will only allow an ovmCREATE or ovmCREATE2 operation to proceed if the deployer's address whitelisted.
The ETH predeploy provides an ERC20 interface for ETH deposited to Layer 2. Note that unlike on Layer 1, Layer 2 accounts do not have a balance field.
This contract exposes the current L2 gas price, a measure of how congested the network currently is. This measure is used by the Sequencer to determine what fee to charge for transactions. When the system is more congested, the L2 gas price will increase and fees will also increase as a result.
All public variables are set while generating the initial L2 state. The constructor doesn't run in practice as the L2 state generation script uses the deployed bytecode instead of running the initcode.
The L2 to L1 Message Passer is a utility contract which facilitates an L1 proof of a message on L2. The L1 Cross Domain Messenger performs this proof in its _verifyStorageProof function, which verifies the existence of the transaction hash in this contract's 'sentMessages' mapping.
Simple holding contract for fees paid to the Sequencer. Likely to be replaced in the future but "good enough for now".
A set of contracts which implement the Metis Virtual Machine.
The Fraud Verifier contract coordinates the entire fraud proof verification process. If the fraud proof is successful, it prunes any state batches from State Commitment Chain which were published after the fraudulent state root.