Architecture and Roadmap
Components and modules part of Mantle Network
Mantle v2 Tectonic has been released, please move to the new documentation!
Network Architecture
This diagram illustrates how different network modules and components interact with each other going through transaction execution and eventually published updated state data to Ethereum L1, and storing the rollup data on the Mantle Data Availability (DA) powered by EigenDA technology. Let's go over the process of transaction handling to better understand how each module works.
Users send signed transactions via an available RPC node.
The Sequencer receives transactions and pack them into blocks. The DTL (Data Transport Layer) service syncs this block data. Verifiers sync the L2 block data from the DTL.
The batch submitter fetches updated state roots and sends them to the Threshold Signature Scheme (TSS) module to be verified and signed. Verifiers can also fetch the state root data and confirm their validity.
Once TSS nodes establish the validity of the updated state roots and sign off on the rollup batches, the batch submitter publishes the state root data to the State Commitment Chain (SCC) contract on L1 Ethereum.
The rollup transaction data is stored on Mantle DA. Verifiers can fetch this data at any point and verify its validity. This action is performed when issuing fraud proof challenges.
Mantle DA nodes also post the validity certificates to L1 guaranteeing liveness and availability with each new batch.
In case the state root validity is challenged with a fraud proof, L2 data is posted to the contract on L1 to perform the execution and check state transition validity.
For more details on the role played by each network component, check out the Network Roles page.
Roadmap
The following table tentatively summarizes our current approach to different network components and actions on L2 and L1 for our initial mainnet version, and other potential implementations that we're considering for future mainnet upgrades.
Failure Handling
L2 Sequencer Failure
In the event of L2 Sequencing issues, common industry approaches to remain "secured by Ethereum" are:
Enqueue via L1**: Users can submit transactions to an L1 queue, but can't force them. The sequencer can selectively skip transactions, but cannot stop processing the queue entirely. In other words, if the sequencer censors or is down, it affects everyone.
Force via L1: Users can force sequencer to include a trade or a withdrawal transaction by submitting a request through L1. If the sequencer censors or is down for X period, users can use the exit hatch to withdraw their funds.
Self Sequence: In the event of sequencer failure, users can force transactions to be included on L2 by sending them to L1.
** denotes approach of the initial Mantle Network Mainnet version
L2 Batch Submitter / Proposer Failure
The Batch Submitter, or Proposer, is responsible for submitting the L2 state and necessary transaction data to L1. In the event it is offline, common industry approaches to remain "secured by Ethereum" are:
Propose blocks: Anyone can become a Proposer after X period of inactivity from currently whitelisted Proposers.
Escape hatch: Users have the ability to withdraw their funds on L1 by submitting a Merkle proof or ZK proof of funds.
No automated mechanism**: If whitelisted Proposers are offline, withdrawals cannot be processed. In such cases, a new Proposer has to be whitelisted by the L2 core contributor team, potentially involving a DAO governance process. The transition is controlled by the DevOps team with measures in place to minimize downtime.
** denotes approach of the initial Mantle Network Mainnet version
Last updated
