Crypto Notebook

MetisDAO

What is Metis?

Based on the spirit of Optimistic Rollup, Metis is building an easy-to-use, highly scalable, low-cost, and fully functional Layer 2 framework (Metis Rollup) to fully support the application and business migration from Web 2.0 to Web 3.0. Its scalable protocol supports a wide range of use cases, including yield farming, DEX trading, and powering the gig economy via dApps that offer cheap and fast micropayments.

Metis integrates the Decentralized Autonomous Company (DAC) framework within its Layer 2 infrastructure, a differentiating factor that makes it easy for developers, builders, or community leaders to build their applications and communities. It also makes it easy to use the pre-set tools to facilitate their development, manage collaboration, and enjoy the network effects of the world’s largest decentralized finance ecosystem, without the costs and bottlenecks normally associated with Ethereum.

Metis is meant to look, feel and behave like Ethereum but cheaper and faster. For developers building on Metis, they 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. This is achieved through its L2 Main net, Andromeda, which feature EVM Equivalence.

Note, EVM Equivalence makes it impossible to perform the on-chain fraud proofs that have until now been a hallmark of Optimistic Rollups. To handle this issue, Metis introduced MVMs, Sequencer Pool, Rangers, and Peer Nodes to circumvent this impossibility.

MetisDAO Funding

MetisDAO Funding

Name

Date

Round

Amount

MetisDAO funding

Apr 1, 2021

Seed

Feb 3, 2021

Seed

There are no rows in this table

⁠

DAC: Decentralized Autonomous Companies

One of the key features of Metis. DACs (or Decentralized Autonomous Companies) are a type of DAO that not only solve the governance problem, but also tackle management and incentives of autonomous and decentralized communities (i.e. who is to build the core protocol to help them govern the system?).

Metis DACs work like the DAOs. Namely, holders of the DAC token are entitled to participate in the decisions and day-to-day operations of the organization, with the slight difference that in order to join the DAC, members need to also stake some of their own tokens in advance. This prevents “destructive members” from joining the organization. Right now, anyone could buy some UNI and try to harm Uniswap by voting for harmful proposals. To prevent this from happening, members willing to join a DAC must have some stake in the DAC.

Protocol in Detail

System Overview

The smart contracts in the Metis protocol can be separated into a few key components. We will discuss each component in more detail below.

Layer-1

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.

Verification

Layer-2

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.

MVM

Verifier

Layer-1 Messaging

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. For meaning of roles (sequencer, proposer, etc) please refer to later part of this page

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

Layer-1 Verification

Bond Manager

For now, a stub of the "real" BondManager that does nothing but allow the "OVM_Proposer" to submit state root batches.

Layer-2 Messaging

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.

Layer-2 Predeploys

OVM_DeployerWhitelist

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.

OVM_ETH

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.

OVM_GasPriceOracle

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.

OVM_L2ToL1MessagePasser

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.

OVM_SequencerFeeVault

Simple holding contract for fees paid to the Sequencer. Likely to be replaced in the future but "good enough for now".

MVM

A set of contracts which implement the Metis Virtual Machine. MVM supports the basic principles of microservice framework. Providers such as oracles, delivery service, or legal can register as a microservice provider in the MVM ecosystem. They serve as toolkits to all DACs to help fulfill the mission and visions. MVM supports automatic payment collection. The service providers will be given an SDK to easily interact with the smart contract on any Metis Layer 2 constructs, including payment collection, to lower entry barriers.

⁠

Screen Shot 2021-12-22 at 4.21.36 PM.png

⁠

MVM_Verifier

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.

Transaction Fee

Transaction fees on Metis are handled a little differently than on Ethereum but end users won’t notice much difference.

Users will be taking three primary actions when interacting with Metis:

Layer 2 transactions

Layer 1 to Layer 2 transactions

Layer 2 to Layer 1 transactions

I will only provide information on Layer 2 transaction here as it is non-trivial. For the other two, please refer to

https://docs.metis.io/protocol-in-detail/transaction-fees⁠

fyi.

Fees for Layer 2 transactions

Fees on Metis are denominated in METIS. The formula for gas cost on Ethereum is:

fee = transaction.gasPrice * gasUsed

However, the formula for gas cost on Metis is:

fee = transaction.gasPrice * transaction.gasLimit

The exact reason for this difference is a little hard to explain. In a nutshell, it has to do with the fact that the majority of the cost of running a Layer 2 system comes from the gas cost of publishing transaction data to Layer 1. Practically speaking, this shouldn't have much of an impact on the user experience. You should still use eth_gasPrice to figure out the appropriate gas price and eth_estimateGas to find an appropriate gas limit.

Fraud proof window

Of course, since MetisDao is based on Optimistic Rollups, it inherently has a fraud proof window. You don't want to be making decisions about Layer 2 transaction results from inside a smart contract on Layer 1 until this fraud proof window has elapsed. Otherwise you might be making decisions based on an invalid transaction result. As a result, L2 → L1 messages sent using the standard messenger contracts cannot be relayed until they've waited out the full fraud proof window.

Roles

Depositing

When depositing, the L1 User calls the L1StandardBridge directly.

⁠

Sequencer

The Sequencer is a semi-privileged service provider in Optimistic Ethereum which enables instant transactions. The sequencer is given the role of assigning an order to L2 transactions, similarly to miners on L1.

There is only one sequencer at a time, allowing consensus on transactions to be reached extremely rapidly. Users can send transactions to the sequencer, and (within seconds) receive confirmation that their transaction was processed and will be included in the next rollup batch. These instant confirmations have weaker security than confirmed L1 transactions, but stronger security than 0-conf L1 transactions.

Once the sequencer's batch is confirmed on L1, the security is the same.

L2 Transaction

L2 User posts a transaction to the Sequencer, the Sequencer records the transaction on it's local blockchain

The Sequencer periodically posts the transactions that it has received to the CanonicalTransactionChain. This defines the ordering of the transactions as well as ensures data availability

⁠

Sequencer Witholding Data

If the Sequencer is unavailable or malicious, the L2 User can directly post their Transaction to the CanonicalTransactionChain. In detail

In the event that a malicious Sequencer censors user's transactions, the user should enqueue() their transactions directly to the L1 Queue, forcing the sequencer to include them in the L2 chain within the FORCE_INCLUSION_PERIOD

If any transaction in the queue are more than FORCE_INCLUSION_PERIOD blocks old, those transactions MUST be added to the Chain before the protocol will allow the Sequencer to add any other transactions.

In the event that the Sequencer stops submitting transactions entirely, the protocol will allow users to add transactions to the CTC by calling appendQueueBatch()

Note: In order to prevent an edge-case where the user includes a transaction that may invalidate the batch, a time delay is put in place

⁠

State Commitment

L2 User posts a transaction to the Sequencer, the Sequencer records the transaction on it's local blockchain

The Sequencer periodically posts the transactions that it has received to the CanonicalTransactionChain. This defines the ordering of the transactions as well as ensures data availability. The Sequencer then grabs the batch of transactions located in the CanonicalTransactionChain including the user published transactions.

The Sequencer processes the batch of transactions and produces a State Batch and appends the generated merkle root. This merkle root is needed in order for Verifiers to verify the validity of the processing that occurred.

⁠

Proposers

Proposers evaluate the transactions in the CTC, and 'commit' to the resulting state by writing them to the SCC. They must deposit a bond for the privilege of this role. This bond will be slashed in the event of a successful fraud proof on a state root committed by the Proposer.

In a nutshell, proposers

Process transactions from the CTC, and propose new state roots by posting them to the SCC.

MUST be collateralized by depositing a bond to the BondManager .

Future note: The Proposer is currently identical to the Sequencer. This is expected to change.

Verifier (L2 Ranger)

Like Proposers, Verifiers evaluate the transactions in the CTC, in order to determine the resulting state root following each transaction. If a Verifier finds that a proposed state root is incorrect, they can prove fraud, and earn a reward taken from the Proposer's bond.

In a nutshell, verifiers

Read transactions from the CTC, process them, and verify the correctness of state roots in the SCC.

If an invalid state root is detected: initiate and complete a fraud proof.

Note that multiple accounts may contribute to a fraud proof and earn the reward.

⁠

Screen Shot 2021-12-22 at 4.17.58 PM.png

⁠

Users

Any account may transact on OE.

MAY post L2 transactions via the Sequencer's RPC endpoint, to be appended in sequencer batches

MAY submit an L2 transaction via the CTC's queue on L1

Can be used to circumvent censorship by the Sequencer

Can be used to send a cross domain message from an L1 contract account.

Bibliography

⁠

https://www.metis.io/⁠

⁠

https://docs.metis.io/⁠

⁠

https://www.crunchbase.com/organization/metis-24c0/company_financials⁠

⁠

https://metisdao.medium.com/daos-the-operating-system-of-communities-7286efb8e430⁠

⁠

https://drive.google.com/file/d/1LS7CmKFt-FkfVXxSNu06hNgoZXxMzTC-/view⁠

← Metis whitepaper

⁠

https://twitter.com/plebonacci/status/1471119402368176128⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.