Mantle DA

Why Mantle DA

When opting for Mantle DA, it's essential to consider the ongoing development of the EIP-4844 proposal. As this proposal is under development, we currently do not support EIP-4844 until its deployment on the Ethereum mainnet.

Moreover, due to the specified block size limit in EIP-4844, there might be performance constraints for layer 2 (L2) solutions with high TPS.

However, once EIP-4844 is officially implemented, Mantle can swiftly adapt with minimal modifications. This means that we can harness the full potential of EIP-4844, ensuring Mantle's sustained superior performance in the L2 space, adapting to the continuous evolution of the Ethereum ecosystem, and providing users with more efficient services and exceptional experiences.

Architecture

Components

Mantle DA, supported by EigenDA technology, consists of four main components with a set of supported interactions:

Operator Nodes / DA Nodes:

Operators, as service providers in the DA network, confirm their commitment through digital signatures that stake assets as guarantees for their participation. Operators will run nodes in the network that store data chunks for a predefined period, and make these data chunks available on request.

Dispersers

They are the roles of the Mantle DA service and pay for financial assurance of their data availability. This role can be played by rollup sequencers. Dispersers perform the following tasks:

• Encoding data into blocks, providing funds to make the data available for a fixed period, and distributing the coded blocks to Mantle DA operators
• Aggregate operators' signatures and publish proofs to the blockchain, confirming the availability of the data of interest for a specified period

Retrievers

They are stakeholders who play an important role in the Proof of Custody protocol. Retrievers perform the following tasks:

• Monitor certain verifiable operations of the protocol (will not be verified or resolved on-chain in optimistic scenarios)
• Permissionless enforces toxic operations to be resolved up on-chain, slashing operators' stake

MantleLayer and Mantle DA Smart Contracts:

The collection of DA-related smart contracts running on Ethereum is responsible for the following:

• Responsible for ensuring data acceptance only when a group of operators with sufficient stake collectively signs.
• Implements the proof-of-custody protocol, providing on-chain data disclosure mechanisms for Retrievers.
• Verifies the validity of data submitted by Retrievers based on signed commitments and enforces slash according to the proof-of-custody protocol.

Workflow

1. Encoding: Dispersers encode data chunks (stored by Graph-node in L1 contract data) and generate KZG multi-reveal proofs for operators to verify chunk correctness.
2. Dispersal: Dispersers send data chunks to respective DA Operators.
3. Attestation: Operators verify their chunks based on global commitments. Upon successful verification, Operators will continue to store their data chunks for the time specified by Disperser and send back proofs.
4. Aggregation: If enough signatures are received, Dispersers aggregate them and publish them to L1 Ethereum.
5. Retrieve: Retrievers fetch valid data chunks from Operators and transfer data to the L2 application layer in frames.

Mantle DA With BedRock Upgrade:

In Mantle v1, the DA-DTL component (DA internal data component) was responsible for fetching data from Mantle DA and storing it in a local database for use by internal DA components and browsers. However, in Mantle v2 Tectonic, we have significantly optimized the da-retriever component, which significantly reduces the computer configuration requirements. This means that we no longer need DA-DTL as a data relay service. In Mantle v2 Tectonic, the op-batcher and op-node need to go through several optimizations for the Bedrock upgrade to integrate smoothly with Mantle DA. In addition to supporting sending data frames directly to an EOA (Externally Owned Account) in L1 in Mantle v2 Tectonic, we also need to implement the ability to send data frames to Mantle DA. These improvements will allow us to better adapt to the evolving needs of data interaction and provide users with more flexible options.

Appendix

L1 < -- > L2 Data Flow

For a robust L2, stable data flow includes batch submission from L2 to L1 and derivation from L1 to L2. Mantle v2 Tectonic ensures compatibility with Bedrock upgrades, enabling native data flow and interaction with Mantle DA.

Batch

Batch is a process of sending data frames from the L2 to the DA layer. The data frames are stored in the form of a channel and sent to the destination (DA Layer), where the the verifier can validate the availability of the data.

• Batch Submit To L1 / Ethereum EOA op-batcher obtains the latest block ranges to be packed from the sequencer, encodes and compresses the latest block data, and generates frames. op-batcher creates a channel to store the frames, and then builds the EOA transaction to complete the batch submission.
• Batch Submit To Mantle DA op-batcher obtains the latest block ranges to be packed from the sequencer, encodes and compresses the latest block data, and generates frames. op-batcher will create a channel to store the frames, and once the channel is full, it will send all the frames in it to them and once the rollup is successful, the frames involved will undergo a state transition and be deleted from the cache.

Derivation

Derivation is the process of obtaining data from the DA Layer and deriving it in L2 to ensure that the state of all L2 nodes remains consistent. the L2 op-node completes the state reconstruction of L2 by obtaining data frames from different DA Layers.

• Derived from L1 / Ethereum EOA If we need to derive L2 data from the EOA address of L1, we can do it by syncing to the L1 block, then read the data batched to the EOA address from it, decode it to get the corresponding frame, and finally store it into a channel for processing. For more information, please check here.
• Derived from Mantle DA If we need to do L2 data derivation from Mantle DA, we first need to get the confirmed block from L1, and then parse out the dataStoreId, which is a field about the data in the block, and use the dataStoreId to get the corresponding frame from Graph-Node and da-retriever. This completes the Mantle DA-based data derivation.