Security Model and Roles
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:
- 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.
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.
Mantle Network Architecture
- 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
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.
- 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.
- 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.
- 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.
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.
- 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.
- The SCC stores the L2 state roots on L1. State roots are submitted using the
appendStateBatchmethod, 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
- The state roots determine the ability for users to withdraw to L1, after waiting for the fraud proof window.
- The SCC
deleteStateBatchmethod 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.
- 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.
- 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
enqueuemethod, 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.
- appendSequencerBatch() - via 'BVM_Sequencer', namely Sequencer (Mantle Engineering HSM)
- enqueue() - anyone can call
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.
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.
- 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
createAssertionWithStateBatchmethod in sync with state root submissions to the SCC.
- Note there are some overlaps with the
SCC.appendStateBatchmethod 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
createAssertionmethod 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)
stake handling. These functions can be considered placeholders for now as fraud proof challenges have not been enabled.
rollbackL2Chainmethod, 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.
- Upgradable Admin: Mantle Security Msig
- Key permissions:
- Delete assertions via
- Adjust whitelists and stake handling - Proposer
- rollbackL2Chain - Proposer (potentially transferring to Mantle Security Msig in the future)
- 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
- 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.
- 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.
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.
- The L1CrossDomainMessenger component is used to send messages from L1 to L2. This is triggered through the
sendMessagemethod 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
relayMessagemethod of the L1CrossDomainMessenger and the legitimacy of the message will be verified and executed.
- The main fields of messages include:
address_targetwhich is the address of the contract to be interacted with, and
bytes memory_messagewhich includes the parameters for calling the contract. Additional L2 to L1 messages will include
If the L1CrossDomainMessenger is compromised:
- The LibAddressManager owner (Mantle Security Msig) can reset the address.
- 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 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 datato MantleDA, and after some time there will be a
confirm datawith 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.
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.
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 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.
- 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 team multisigs will maintain anonymous signers for security reasons.
- 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).
- Fraud Proof: When the
Fraud Verifiersubmits a
Fraud Proofand 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
- 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.
- The variable declaration for the BvmRollbackAddress can be found here https://github.com/mantlenetworkio/mantle/blob/0b7733c10a44e93edbf49b27e056ebe2e5279c63/l2geth/rollup/dump/constants.go#L12C7-L12C7
2\ Call Entrance Summary
- The TSS nodes ability to call
RollbackL2Chain()is controlled by a flag in the config
AllowL2AutoRollback. The current mainnet config has this configured as
False, so it currently cannot be triggered (include link to mainnet config) https://github.com/mantlenetworkio/mantle/blob/0b7733c10a44e93edbf49b27e056ebe2e5279c63/batch-submitter/drivers/proposer/driver.go#L409C16-L409C16
- The ability for Fraud Proofs to trigger
RollbackL2Chain()is controlled by a flag in the config
SccRollback. The current mainnet config has this configured as
False, so it currently cannot be triggered (include link to mainnet config) https://github.com/mantlenetworkio/mantle/blob/0b7733c10a44e93edbf49b27e056ebe2e5279c63/batch-submitter/drivers/proposer/driver.go#L430C12-L430C12
3\ Off Chain Handling
- L1 - > L2 message to the
BvmRollbackAddress(in our case
0xDeADdeaDdEaDdeADdEaDDeADDEaddEaDDEad2222) returns nil. https://github.com/mantlenetworkio/mantle/blob/0b7733c10a44e93edbf49b27e056ebe2e5279c63/l2geth/core/vm/evm.go#L219C8-L219C
- While syncing, if we encounter a rollback, it will be resimulated. However, as rollbacks are currently not enabled on mantle mainnet, this logic should never be reached at this moment in time. https://github.com/mantlenetworkio/mantle/blob/0b7733c10a44e93edbf49b27e056ebe2e5279c63/l2geth/rollup/sync_service.go#L964C17-L964C17