Network Governance

Security Model and Roles

Mantle v2 Tectonic has been released, please move to the new documentation!

Background

Mantle Network is a work in progress. During the Mainnet Alpha phase, the protocol operates with a high level of centralization and relies on a trusted core contributor team to ensure optimal performance and security. There are two key points to note:

  • Fraudproofs are currently in development. We are working in collaboration with Specular Network with the latest progress available on Testnet and GitHub.

  • Data availability through Mantle DA (powered by Eigen DA technology) is currently a permissioned node network, with all nodes selected and approved by the core team. We plan to migrate to EigenDA after EigenDA mainnet launches.

The development roadmap for the protocol includes several stages aimed at enhancing the user experience and transitioning various protocol components to decentralized and trustless systems, and simplified architecture. The team intends to discuss the decentralization pathway with Mantle Governance, involving the community in decision-making processes.

Purpose

This article serves as a guide for semi-technical readers and users of Mantle Network to help them make informed decisions about the security model, potential risks and mitigations associated with using the product. The information provided here is presented in a succinct manner to aid understanding. For more comprehensive and technical details, interested parties are encouraged to refer to the project's GitHub repository and available audit reports.

Architecture

System Components

Permission Management

Lib Address Manager

  • This component is used to manage permissions and addresses for important L1 smart contracts.

  • The Lib Address Manager can reset the following addresses: Sequencer, Proposer, Mt-batcher, L1StandardBridge, L1Crossdomainmanager, SCC, CTC, Mantle DA contracts, and various TSS Stake related addresses.

  • Lib Address Manager can not reset the following addresses: Mantle DA, Fraud Proof

Lib_AddressManager: 0x6968f3F16C3e64003F02E121cf0D5CCBf5625a42 Type: Smartcontract, non-upgradable Owner Role: Mantle Security Msig

Offchain Systems

Note: The term "Sequencer" often refers to the aggregated sequencer, proposer, mt-batcher components in our diagram. These are offchain systems administered by the core team. These services need to have their private key online (Hot Wallet) for the required system performance. The private key is protected by industry standard cloudHSM.

Proposer

  • The proposer submits new state roots to the SCC (L1).

  • State roots are used for state validation, and determine the ability to withdraw from the L1 Bridge.

Proposer: 0x6667961f5e9C98A76a48767522150889703Ed77D Key manager: Mantle Engineering HSM In the event of a compromise of the Proposer component:

  • Roles with write permissions for the SCC can deleteStateBatch (see SCC section below).

  • The owner of the LibAddress Manager can reset the address of the proposer.

  • Note that as withdrawals are configured to a 7 day challenge period, as long as those fixes can be completed within that time, the effect of the compromise can be minimized.

Sequencer, mt-batcher

  • The sequencer submits a small portion of rollup transaction data to the CTC (L1) such as a count of transactions, batches, and elements for the purposes of enqueuing via L1. More details in the CTC section below.

  • The mt-batcher submits all rollup transaction data to the DA solution.

  • Rollup transaction data is relied upon for L2 State Validation by various components including the Fraud Proof component and Verifier Node component.

Sequencer: 0x2F6AFE2E3feA041b892a6e240Fd1A0E5b51e8376 Key manager: Mantle Engineering HSM

Mt-Batcher: 0x2f40D796917ffB642bD2e2bdD2C762A5e40fd749 Key manager: Mantle Engineering HSM

In the event of a compromise of the Sequencer component:

  • The owner of the CTC can correct the data.

  • The owner of the LibAddress Manager can reset the address of the Sequencer.

DTL Service

  • The DTL Service is a critical system which provides L1 data, L1 enqueued tx, and DA data to the various L2 systems (Replica Nodes, L2geth, verifier nodes). It can be considered a source of truth relay service.

  • The current DTL does not relay messages accompanied by L1 signatures, which is an area of risk, especially as fraud proofs are still in development. This issue has been addressed in https://community.optimism.io/docs/developers/bedrock/ which we are assessing for the next upgrade.

In the event of a compromise of the DTL Service component:

  • The DTL Service is an offchain system which feeds data to other offchain systems. If the DTL Service is compromised, all data receiving systems such as Replica Nodes, Verifier Nodes, and L2geth can update their nodes to connect to a backup DTL Service.

Rollup Smart Contracts

(SCC) StateCommitmentChain

  • The SCC stores the L2 state roots on L1. State roots are submitted using the appendStateBatch method, by the Proposer via the FraudProofRollup contract.

  • The SCC manages the length of time before user withdrawals are permitted on L1, also known as the 'Challenge Period', via the setFraudProofWindow method.

  • The state roots determine the ability for users to withdraw to L1, after waiting for the fraud proof window.

  • The SCC deleteStateBatch method can be called in an emergency where L2 and SCC state are no longer in sync, such as a 64+ block L1 reorganization, or a compromise of the Proposer component.

SCC: 0x89E9D387555AF0cDE22cb98833Bae40d640AD7fa

  • smart contract, non-upgradable, with the following write permissions:

  • appendStateBatch - via 'FraudProof.Rollup' by the Proposer

  • deleteStateBatch - via 'BVM_FraudVerifier' by the Mantle Engineering Msig

  • rollBackL2Chain - via 'FraudProof.Rollup' by the Proposer

  • setFraudProofWindow - Mantle Security Msig

If the SCC is compromised:

  • The LibAddressManager owner (Mantle Security Msig) can reset the SCC address.

  • If the component is recovered within the setFraudProofWindow (currently 7 days), the risk of invalid L1 asset withdrawals is minimized.

(CTC) CanonicalTransactionChain

  • The CTC stores a small portion of rollup transaction data, whereas Mantle DA stores all rollup transaction data.

  • The CTC is required to facilitate L1-->L2 transactions. The CTC is the only way to enqueue transactions to L2. It can not be done through Mantle DA.

  • The CTC manages L1 to L2 transactions through the enqueue method, including deposit requests. For example, the call path for an ERC20 deposit is L1StandardBridge._initiateERC20Deposit -> L1CrossDomainMessenger.sendMessage -> CanonicalTransactionChain.enqueue.

  • The CTC needs to store some L2 transaction data such as a count of elements, batches, and transactions. These provide reference indexes for the purposes of enqueue transactions.

  • Enqueued transactions via CTC are sent to the DTL Service after ~30 seconds, and the DTL Service waits for 64 L1 block confirmations before relaying to other L2 nodes.

CTC: 0x291dc3819b863e19b0a9b9809F8025d2EB4aaE93

  • smart contract, non-upgradable, with the following write permissions:

  • appendSequencerBatch() - via 'BVM_Sequencer', namely Sequencer (Mantle Engineering HSM)

  • enqueue() - anyone can call

  • resetIndex() - owner of Lib_AddressManager, namely Mantle Security Msig

  • setGasParams() - owner of Lib_AddressManager, namely Mantle Security Msig

If the CTC is compromised:

  • The LibAddressManager owner (Mantle Security Msig) can reset the CTC address.

  • The DTL Service can reject CTC data or pause itself.

Fraud Proof

Fraudproofs are currently in development. While placeholder smart contracts are deployed, there are no whitelisted challengers, subverifiers registries which handle one-step-proofs and outcomes are currently empty. Most write permission roles are effectively managed by the core team systems and msigs. Some OP code related challenge assertions are not yet available.

FP.Rollup

  • The FP.Rollup component stores state batches to facilitate fraud proof challenges. In our current setup, this data is submitted regularly by the Proposer via the createAssertionWithStateBatch method in sync with state root submissions to the SCC.

  • Note there are some overlaps with the SCC.appendStateBatch method which is also triggered by Proposer submissions: 1) both methods are related to the same event and so there is limited gas cost duplication, 2) the FP.Rollup only stores the final block's stateroot whereas the SCC stores all blocks' state roots, 3) FP.Rollup stores additional information to facilitate fraud proof challenges such as the L2 blockheight. One benefit of storing state information across within the SCC and FP.Rollup components is that the SCC can continue to operate without the FP component (if we decide to not use FP type state validation mechanisms in the future).

  • The FP.Rollup createAssertion method facilitates future fraud proof challenges, and is an independent channel from the regular submissions by the Proposer via createAssertionWithStateBatch.

  • The FP.Rollup components contain various permission and parameter control such as operator (challenger, defender) whitelists and stake handling. These functions can be considered placeholders for now as fraud proof challenges have not been enabled.

  • The rollbackL2Chain method, although callable, is not intended to be used in the current Mainet Alpha version. Even if called, the full execution of this rollback on L2 requires manual processing by the core contributor team. One risk is deep reorganizations occurring on L1. To compensate for this, our L1 to L2 messaging effectively waits for 64 L1 block confirmations.

FP.Rollup

FP.AssertionMap

  • The AssertionMap is data handling contract used to store and retrieve data associated with assertionIDs (such as NumStakers, ProposalTime, status of Stakers, etc.).

  • The AssertionMap functions can only be called by the Proxy__Rollup contract (section above), and this is enforced by the modifier rollupOnly.

AssertionMap

FP.VerifierEntry

  • The VerifierEntry is a register of various subverifiers for different types of proofs (stack verifier, memory verifier, etc.). These subverifiers enable onchain one-step-proofs to discover the fraud step and determine the outcome of any challenges.

  • Each subverifier is a stateless smart contract.

  • Note: we have not enabled fraud proof challenges, and so this register is currently empty.

FP.VerifierEntry

Bridge

L1StandardBridge

  • The L1StandardBridge components are used to store deposited L1 tokens that are to be bridged to L2, and facilitate future withdrawals of such tokens on L1.

Proxy__BVM_L1StandardBridge

If the L1StandardBridge component is compromised:

  • The LibAddressManager owner (Mantle Security Msig) can reset the address, however existing tokens held in the L1StandardBridge may become inaccessible.

L1CrossDomainMessenger

  • The L1CrossDomainMessenger component is used to send messages from L1 to L2. This is triggered through the sendMessage method of L1CrossDomainMessenger, and routed to the enqueue method in the CTC contract. After the verification is successful, the TransactionEnqueued event is thrown and caught by the DTL Service for relaying to other L2 nodes.

  • The L1CrossDomainMessenger component is used to facilitate L2 to L1 communication. This is initiated through the sendMessage method of L2CrossDomainMessenger which will be rolled up to L1. After the challenge period, a user can call the relayMessage method of the L1CrossDomainMessenger and the legitimacy of the message will be verified and executed.

  • The main fields of messages include: address_target which is the address of the contract to be interacted with, and bytes memory_message which includes the parameters for calling the contract. Additional L2 to L1 messages will include address_sender.

L1CrossDomainMessenger

If the L1CrossDomainMessenger is compromised:

  • The LibAddressManager owner (Mantle Security Msig) can reset the address.

TSS

  • TSS nodes - which provide an additional check on state validity prior to batch submission - is currently a permissioned node network, with all nodes selected and approved by the core team. The future direction of TSS will be a major decision for the next significant upgrade of Mantle Network, and will be evaluated among other mechanisms that aim to enhance confidence in State Validity.

  • If the TSS components are compromised, stateroots can not be submitted by the Proposer to the SCC, and the L2 chain may need to be paused depending on the duration of TSS downtime and the establishment of a new TSS group.

  • Key TSS components are owned by a combination of Mantle Engineering Msig and Mantle Security Msig.

Data Availability (DA)

  • Data availability through Mantle DA (powered by Eigen DA technology) is currently a permissioned node network, with all nodes selected and approved by the core team, and can be considered an offchain system.

  • We plan to migrate to EigenDA after EigenDA mainnet launches.

  • Mantle DA stores the majority (~90%) of the rollup transaction data in place of the CTC. The CTC is where this data would be stored if our data availability was "Onchain L1".

  • Mantle DA provides data to the DTL Service (an offchain system). This is for various internal verification purposes and future fraud proof construction purposes.

  • Mantle DA receives data from the mt-batcher (a centralized service, considered a component of the sequencer). The mt-batcher will post init data to MantleDA, and after some time there will be a confirm data with a validity certificate posted into the MantleDA related smart contracts on L1. The frequency of confirmations will be ~15 minutes frequency at its slowest setting.

  • The smart contracts are owned by Mantle Security Msig and are upgradable.

Proxy__BVM_EigenDataLayrFee: 0xF037ba8B0e82439Ad82325D986E097fD19E994ef

Proxy__BVM_EigenDataLayrChain: 0x50fa427235c7c8caa4a0c21b5009f5a0d015b23a

If the Mantle DA component is compromised:

  • The mt-batcher component can post data to, and DTL Service can read data from, a backup DA solution.

Other Concepts

Choices for system components

Generally range from:

  • Non-upgradable smart contracts - while the key logic can not be modified, some parameters or variables may be modified by permissioned roles.

  • Upgradable smart contracts - Upgradability allows for the modification of logic, which is useful for adding features, but essentially allows the upgrade owner to do anything. Upgradable smart contracts can optionally have a time lock function (delay prior to upgrade coming to effect), which may allow users to exit the system prior to the upgrade. See the following link for more details.

  • Distributed node networks - which may have various degrees of permissioning, decentralization, consensus, and economic trust assumptions. These systems can be upgraded through a synchronized process with node operators.

  • Centralized systems - which are generally used to handle advanced logic with high performance and low cost requirements. These systems can modify their internal logic at any time.

Smart Contracts and Roles

Smart contract methods write permissions can be assigned to various roles (owner, operator, etc.). These roles are typically either: a multisignature wallet (msig), single signer (EoA), online private key (HotWallet), multi-party computation (MPC), DAO smart contract module, or other smart contracts.

Proxy and Upgradable Contracts

  • The proxy contract is the contract users and other system components interact with, all data is stored in the proxy contract.

  • The implementation contract (without proxy name) is the core logic, but stores no data.

  • Upgrading involves deploying a new logic contract, and pointing the proxy contract to the new implementation contract. The proxy contract address is preserved.

Core Multisigs

Core team multisigs will maintain anonymous signers for security reasons.

Other Details

SCC rollBackL2Chain() Method

Key points:

  • The rollBackL2Chain() method is a placeholder function intended to be used for future Fraud Proof and TSS mechanisms.

  • In the current implementation, if the TSS signature verification does not pass, the Proposer will be unable to post stateroots to the SCC. Instead, the sequencer will attempt to resequence the relevant blocks. If multiple attempts to re-sequence fail, there will need to be manual processing by the core team (for example in the case that there is a >64 block L1 reorg).

Future Purpose:

  • Fraud Proof: When the Fraud Verifier submits a Fraud Proof and the challenge is successful, the SCC status must be rolled back to a historical batch prior to the challenged batch. The corresponding Layer 2 block needs to be rolled back, which is triggered by the rollBackL2Chain() method.

  • TSS: When the set of TSS nodes is unable to have their signature verified, they can use the rollBackL2Chain() method to the last verified Layer 2 block. They can then attempt the re-execution of subsequent blocks.

Current code:

1\ BvmRollbackAddress Variable Declaration

2\ Call Entrance Summary

3\ Off Chain Handling

PreviousArchitecture and RoadmapNextTransaction Lifecycle

Last updated