Transaction Lifecycle
L2 -> L1 Workflow
1. The Initiation
Wallet users, dApps, or some scripts may wish to utilize a blockchain-based system to transfer funds or execute tasks.
- For users, they have connected to Mantle network by adding the sequencer node's RPC endpoint to their wallet.
- On the other hand, dApps have integrated the Mantle SDK and instantiated it to communicate with Mantle network. They are ready to send requests containing the recipient's address and the amount they want to transfer.
As with any other service, this operation requires payment. It is not just for the transfer itself, but also for maintaining a permanent, immutable public record that anyone can verify. Their wallet or dApp must ensure there is a sufficient balance to execute this operation.
- For wallets, things are simpler; as it is easier to calculate the required fee.
- dApps need to do more detailed calculations; for more information, please refer to this section.
They use the tools at hand to compose a request, sign it using their private keys, and send it to Mantle Network where a sequencer is ready to process it. This is where the transaction first enters Mantle. More details here.
2. The Handling
The transaction triggers the standard state verification process, executed by the Ethereum Virtual Machine (EVM) software (op-geth) running on these nodes. This is to ensure that the transaction is fundamentally valid, the necessary fees have been paid, and nothing exceptional has occurred. After completing the state transition, the op-proposer proposes a new state's Merkle root and submits it to the corresponding L1 contract.
It's important to note that state submission doesn't need to be executed after every transaction, but can be chosen to be submitted after a tx-batch.
The transaction updates the local state (ledger) and waits for further processing as part of a pending block. So far, this process is particularly fast. Many such pending blocks are combined to form batches, which are encoded and compressed by op-batcher and sent to Ethereum for final settlement. L2 achieves low transaction fees by spreading fixed costs across multiple transactions in a batch.
For details on the encoding and compression process of op-batcher, please refer to this spec.
3. The Storage
Unlike typical Rollups, Mantle Network aims for more efficient and cost-effective Data Availability (DA) guarantees. Therefore, it opts for Mantle DA, developed based on a third-party DA component. op-batcher needs to submit all transaction data (not raw transactions) to Mantle DA to ensure the integrity and effectiveness of the L2 network. DA nodes synchronize block data and ensure access to it at any given time in exchange for $MNT rewards for providing this service. For more detailed information, please see this section.
Mantle DA supports data storage and reverse derivation, ensuring data availability. In addition to data storage, state storage is also crucial.
On Ethereum, there is a complete trust network ready to verify the updated state root stored in the contract. Once a block passes Ethereum's consensus mechanism, it is recorded on the secure chain. The state transition is considered valid once the uploaded state root passes the challenge period (typically 7 days).
Transaction Pool in Mantle
In Mantle v2 Tectonic, a transaction pool structure similar to Ethereum's mempool is introduced for the temporary storage of transactions until they are included in a block. The introduction of the transaction pool in L2 is aimed at improving transaction packing. With Mantle v2 Tectonic's support for EIP-1559 transaction types, users can control the transaction packing speed by manipulating the priority fee in transactions. The transaction pool is used to temporarily store those unpacked transactions.
However, the introduction of the transaction pool also brings certain challenges, such as the impact of Miner Extractable Value (MEV). Therefore, in Mantle v2 Tectonic, the tx pool is designed to be private. If you want to submit a transaction, you need to configure op-geth to send the transaction to the sequencer. The sequencer will then process transactions in the transaction pool in the order of their base fee and priority fee.