Mantle Network is a secondary layer for Ethereum (Layer 2 or L2): a network that enables transactions to be processed and smart contracts to be executed quickly, at low cost. As several scalability for Ethereum, Mantle Network is based on rollups.
Mantle Network has the distinction of being modular the layers managing the calculations and accessibility to data are independent. Ethereum manages consensus, while data availability is ensured by an infrastructure called EigenLayer.
The L2 aim to make Ethereum scalable, easy and inexpensive to use, without sacrificing its security. Each solution is based on a compromise – the famous blockchain trilemma – between scalability, safety and decentralization. Mantle Network has a unique approach, which we present in this article.
>> Not your keys not your coins ! Choose Ledger (commercial link) as your hardware wallet of choice >> Not your keys not your coins;
Key concepts for understanding Mantle
We will first define a few important concepts for understanding Mantle Network, and more broadly the layers 2 of Ethereum. These secondary networks increase throughput by processing a large number of transactions. They unload the main chain (layer 1), as only the resulting state is finalized.
There are different types of L2. They can be based on sidechainsand Plasma chainsor rollups. Among all these techniques sidechains/Plasma chains provide data processing and calculations. This is not the case with solutions based on rollups.
Rollups on Ethereum
There are two types of rollups to create a secondary layer infrastructure for Ethereum. Visit Optimistic Rollups were initially preferred, since zkRollups were not EVM-compatible. This has recently changed, notably with the arrival of Kakarot and Scroll.
In both cases, the rollups are used to process large quantities of transactions on the L2 (batches). The remaining transactions to be processed on L1 (Ethereum) are :
- The deposits and withdrawals user funds on L2 ;
- The check of the validity of operations performed on the L2.
Everything takes place within a smart contract on L1. Visit rollups are therefore accompanied by a zero-disclosure proof of knowledge (ZKP) to validate what is happening on the L2. Herein lies the difference between optimistic and ZK rollups.
By way of example, here is a table summarizing the differences between the two types of rollups in terms of costsof locking period and complexity.
This table is given as an indication, since techniques are progressing, and scalability solutions based on Optimistic Rollups are being developed. rollups are frequently improved. To understand and learn more about zk-Rollups, please refer to the introductory article by Scroll and its zkEVM.
What is an optimistic rollup?
A Optimistic Rollup is a rollup that do not require proof of validity to be taken into account by Layer 1. In fact, transactions are validated off-chain.
On the other hand, a network of auditors generates evidence of fraud (fraud proofs) in the event of an invalid transaction. The adjective « optimistic« The reason for this is that Layer 1 assumes the validity of rollup.
Optimistic Rollups first appeared on Ethereum with Optimism. They work as follows:
- First, a module called the Sequencer collects user transactions and processes them on Layer 2 ;
- The data transactions and the state root from L2 are then sent to L1 ;
- All Layer 2 nodes run these transactions and update their chain;
- Finally, the checkers compare their own state root with that sent by the sequencer to Layer 1.
In cases where the state roots are different, the verifier nodes generate a proof of fraud. They execute transactions on the L2 but not on the L1: in this way, the resulting state root cannot be falsified.
If a Checker challenge the validity of a rollupthe transactions will be submitted to L1 to confirm their invalidity. The responsible Sequencer is then penalized part of its stake (stake) is burned (slashed). It will then have to recalculate the state roots correctly.
Data availability
The notion of data availability describes, in our case, the capacity of L2 nodes at access to the history of transaction data. This is necessary to check the validity of the state transition. There are several ways of store this history, on chain (on L1) and off chain (on the L2).
The notion of trust
Ensuring data availability in a « trustless« In other words, without having to trust a third party, is a technical challenge. On a classic blockchain, you need a complete node, which stores the entire transaction history of the network. In this way, any user can verify that a participant is following the protocol rules.
The nodes of a L2 must also access block data for check the validity of rollupsand generate possible evidence of fraud. On Mantle, the Sequencer publishes on L1 (Ethereum) the complete transaction data, accompanied by a cryptographic proof of the state transition (the root of its Merkle tree). Each can then check that said L1 state transition is correct, and challenge the sequencer otherwise.
In general, the availability of block data is essential to ensure scalability of a blockchain. In the case of an L2, it also has implications in terms of security and censorship resistance.
The central idea of Mantle Network is to use a dedicated layer to block data availability. It is called EigenLayera protocol for restaking. More on this major infrastructure below.
Visit bridges linking Mantle Network to Ethereum
The Bridges (or bridges) allow assets to be moved between Ethereum and a Layer 2. There are two categories of bridges : trusted or trustless. The trusted bridges are operated by a central entity: the user entrusts it with his assets and operates on the L2. The trustless bridges are smart contracts, so their security depends on that of L1.
In the case of Mantle Networka user with ETH on the L1 will have to use the Bridge for lock on the L2, and carry out its transactions.
How the Mantle Network works
In the case of Optimistic Rollups traditional, data availability and calculations are both managed by Ethereum. The L1 ensures data availability, serves as a settlement layerand enables L2 transactions to be verified in order to generate evidence of fraud.
Optimistic Rollups therefore benefit from the same degree of safety than Ethereum. Although they improve its scalability, they also present disadvantages. Firstly, the costs will be significant, as transaction data is sent over Ethereum. Secondly, L2 nodes are limited in terms of throughput by Ethereum’s capacities. Finally, the finalization of L1 transactions is quite long. Users have to wait a safety period before they can unlock their funds on the L2.
Modular rollups
Mantle Network is a L2 modular. Different layers of its infrastructure ensure execution transactions, consensus, settlement and data availability. Consequently, entrusting each of these tasks to a specialized module reduces overall costs rollupand improves its performance.
Separation of the layers managing the consensus and the data availability is a preferred approach to solving the famous blockchain trilemma. Indeed, this greatly improves the trade-off between decentralization, scalability and safety. This is the case, for example, of Celestia.
This principle, applied to rollupsis at the heart of Mantle Network’s architecture:
- The separation of resourcescoupled with specialization of each layer of the infrastructure, greatly improves performance network ;
- All L2 users benefit from the same degree of security. safety than the complete L1 nodes;
- Nodes performing proof computation unload other participants from the task of re-executing transactions.
On Mantle, the layer that manages data availability is based on a specific protocol.
Data availability with EigenLayer
EigenLayer is a protocol for restaking. The stakers Ethereum stakers are users who have staked ETH to help secure Ethereum. With Eigen, they can « restake » their ETH, and thus become validators for any service software built on Ethereum. This includes all the modules of the ecosystem: consensus protocols, virtual machines, oracles, secure execution environments, multisigs, and therefore… data availability (data availability or DA).
The Ethereum validators are thus able to provide data availability services, for all L2s based on rollups. Their « second stakered » ethers are then used as collateral; it is even possible to add performance conditions to reward validators. EigenLayer’s economic incentive mechanisms give them the right to interest.
EigenLayer’s data availability solution is called EigenDA. Mantle Network uses this implementation, which enables nodes to provide their services. The nodes ensuring the availability of Mantle’s data also participate in its business model, thanks to the staking from MNT token which we will present later in this article. EigenDA has three features:
- The layer separation consensus and data availability ;
- Data exchanges between network participants pass through a unicast channelgreatly improving data transmission and storage;
- With a deletion rate (erasure rate), network actors can use incomplete block data from L1 and L2 to reconstruct complete block data.
EigenDA is therefore the solution on which Mantle Network relies to provide a high-speed to its users.
Mantle Network’s decentralized sequencer
The Sequencer is the module that produces optimistic rollups. Traditional L2s use a centralized sequencer, usually maintained by the development team. This is convenient from the user’s point of view, as he or she receives an instantaneous pre-confirmation of its transaction (soft confirmation). If he trusts the sequencer, he knows that his transaction will be included in a batchthen finalized on L1.
However, the single sequencer model poses a problem of security. The sequencer has privileged write access to the L2 chain, and only it can transmit the L2 data. batches of L1 transactions. This is a single point of failureif only the core team managing the L2 can operate it.
Architecture
The Mantle Network sequencer will be decentralized. Any user can therefore become block producer for L2. Sequencer nodes will be rewarded with MNT tokens. They will also benefit from MEV rewards (maximum extractable value).
A election mechanism on the L1 determines the leader node which produces the blocks for a given period (on all sequencer nodes). In other words, it’s the leader who creates the rollup of L2 transactions, and broadcasts the new block to the sequencer network.
Several other sequencers succeed the leader (Sequencer Followers). They receive the new block from leader for the current period, and execute the transactions it contains.
There is also another role for L2 nodes: the Planner. Only one node assumes this role at any given time. It is the planner who elects a leader among all the sequencers, according to the set rules. It is also validator of the blocks produced by the sequencers, and determines their purpose. If the leader does not submit a block to the planner within the allotted time, the latter chooses a new one from among the followers.
Mantle Network Fraud Proofs
In the case of zkRollupsL2 blocks are accompanied by a proof of validitywhich ensures that the code and transactions of the rollup.
Conversely Optimistic Rollups use evidence of fraud. They can be used to signal sequences of calculations or transactions. invalid. L2 blocks are therefore considered valid by L1, until proven otherwise! In this model, the implementation of these proofs is critical.
Classic » proofs of fraud
With the basic model, the smart contract that settles disputes (On-chain Verifier) will execute all rollup to check their validity. However, this can only be done using a low-level language (MIPS or WASM). The EVM client must therefore recompile evidence of fraud in this language, so that verifier on-chain interprets them. We speak of « low-level transpilation« low-level transpilation.
This poses a problem of trust. Indeed, the verifier has no guarantee that the evidence of fraud comes from a compliant EVM client: he has to accept it « blind ».
Mantle’s enhanced proofs of fraud
The idea is to evaluate proofs of fraud directly using EVM instructions. This is the model used by Mantle Network, like Specular. The proofs are compiled and verified via instructions EVM-compliant. This confers two advantages:
- All Ethereum client software can interact without permission with a common proof system ;
- In fact, this minimizes the trust needed between verifiers, client software and compilers.
Mantle Network is thus a « trust-minimized optimistic rollup » :
The design of rollups in a « EVM-native« is superior in terms of safety and trust. Carrying out the instructions of a rollupand the resolution of disputes, take place on the same level of abstraction. The checker on-chain is agnostic in terms of Ethereum client software. This also reinforces theauditability of optimistic rollups.
The different stages of a transaction on Mantle Network
In this chapter, we will illustrate the operation of Mantle Network by detailing the life cycle of a transaction.
Initiation
Initially, a user connected to Mantle Network’s L2 via his wallet initiates a transaction (or any other task). To this end, it uses a decentralized applicationintegrated with Mantle Network (via the SDK – development kit). A request of a basic transaction will therefore contain the receiving address and the amount transferred.
Once the costs of the operation have been taken into account, the request is signed using the user’s private key. It is then sent to a Sequencer from the Mantle Network.
Management
First, the Ethereum virtual machine (EVM) deployed on these nodes verifies the validity of the request. This ensures that funds are available, charges are correct and instructions are valid. The local state of the L2 is updated to include the transaction before it is processed. So far, this process is very fast. The confirmation is therefore instantaneousin terms of user experience.
Secondly, the L2 blocks are grouped into batcheswhich are sent to Ethereum to be finalized.
Thirdly, another type of node checks that the block data is correct: the MPC nodes. MPC stands for « Multi-Party Computation » or multi-party computation. We’ll detail the role of these nodes in the chapter describing the Mantle Network architecture: they check the L2 block state roots transmitted by the Sequencer, then sign the block data.
Storage
The Sequencer then transmits the block dataonce signed, on Ethereum. On the L2the auditors will make this data available to other users and dApps. On the L1the data are registered on-chainonce approved by Ethereum’s consensus mechanism.
Nodes responsible for their availability (DA Nodes) will then synchronize them, and guarantee their accessibility at all times. In exchange, they are rewarded via token MNT.
>> Put your cryptocurrencies in the green. Choose a Ledger wallet (commercial link) >>
Mantle Network architecture
The network Mantle is composed of different modules, which are maintained by 4 actors. They each have a role precise. These nodes are economically incentivized to keep the system running smoothly and safely.
Mantle Network players
These are Sequencersand MPC nodesand Auditors rollups (Rollup Verifiers) and DA nodes (Data Availability Nodes).
Sequencers
The Sequencers receive transactions of users and record them in real time. They will also produce L2 blocks when designated leader. They aggregate transactions into a rollupwhich they accompany with his state root.
The Sequencers also receive signed blocks from the MPC nodes. They then broadcast the corresponding data through L2 and L1.
It should be noted that when Mantle Network’s Mainnet is launched, the team will be operating its own sequencer. The sequencer will be decentralized in line with the progress of the roadmap.
MPC nodes (multiparty computing)
The implementation of these nodes stems from the desire to minimize trust risks on the L2. This is because « conventional » Optimistic Rollups require a long safety period before a user can unlock his funds. MPC nodes solve this problem.
Threshold signature schemes
The multiparty calculation (Multi-Party Computation or MPC) is a branch of cryptography where calculations (and their evaluation) are fragmented between several parties, without these parties having to reveal their private data.
In the case of the Mantle Network, this makes it possible to use a distributed signature scheme to verify block data.
The diagram above shows how multiple MPC nodes verify and sign the block data from the Sequencer. The signature scheme consists of three phases:
- Private key generation Each MPC node performs the generation function. It then derives the associated public key. Of course, it must never reveal its private key.
- Signature The signature function receives the message to be signed as public input. As output, it generates a signature via the private key.
- Verification The algorithm verifies the validity of the signature using the public key.
This signature scheme is distributed among MPC nodes: we speak of threshold signature scheme (Threshold Signature Scheme or TSS). In this way, each participant can generate a valid signature, and verify the distributed signature data. However, a sufficient proportion of participants must be honest.
The big advantage of TSS is that it eliminates the single point of failure which is the private key. With TSS, each MPC node has only one private key. fragment of the key. What’s more, it’s a much more efficient process. fast to check the validity of transactions carried out on the L2.
MPC nodes must place in escrow (stake) tokens MNT to generate signatures. They are rewarded for this, but suffer from penalties if they misbehave or fail.
MPC node network architecture
The diagram above describes the three components of the MPC node network implementing TSS:
- MPC Core deploys the TSS implementation used by Mantle (https://github.com/bnb-chain/tss-lib) ;
- MPC Manager This module manages MPC nodes and assigns their tasks;
- MPC Nodes MPC Nodes: an MPC node generates its own private key, and communicates peer-to-peer with other nodes. They jointly produce a signature using the said private key.
All MPC nodes are complete and permanently connected to the Sequencer. They must therefore execute all transactions to arrive at a correct state root.
Execution result
The performance result refers to state roots from rollups signed by the MPC nodes. The status root, if valid, passes back through the MPC Manager, then through the Batch Submitter, before arriving on the L1.
The performance result is used for check all data from the MPC Manager.
MPC node selection
Visit election process consists of six phases. To become an MPC node, MNT tokens must first be placed in escrow.
- Staking of MNT tokens on the Ethereum mainnet ;
- Lock MNT on L1 – smart contract registers stake amount ;
- Election of MPC nodes through Mantle’s governance (the cluster) ;
- Generation of the private key off-line, and derivation of the public key of the cluster ;
- Diffusion of the public key on the L1 ;
- Confirmation when all MPC nodes have sent the public key to L1.
MPC node penalization (slashing)
The system detects bad behavior (malicious signature or poor connectivity/downtime). As a result, the offending MPC node is penalized, via the slashing (destruction of the stake).
The system must be protected from downtime from MPC nodes. The MPC Manager therefore records absences If repeated, any member of the cluster can ask to burn the stake of the absent MPC node. The proposal must be signed by the majority (in stake) cluster nodes to become effective.
In case of malicious signaturehonest nodes report the fraudster to the MPC Manager. The latter then issues a sanction proposal: slashing and permanent exclusion from cluster. Similarly, it must be signed by the majority of nodes in the cluster MPC.
The Auditors of rollups
The Auditors have 4 tasks to manage:
- Synchronize rollups from Sequencer ;
- Check the state roots that the Sequencer broadcasts on the L2 ;
- Forge proofs of fraud in the case of invalid state data;
- Distribute data from rollups to users.
DAs (data availability) Nodes
These are the famous data availability thanks to EigenDA. They have the complete transaction data of the Mantle Network. To guarantee their accessibility, they sign these data via the Boneh-Lynn-Shacham scheme (BLS).
At the economic incentivethey take advantage of fees collected on L2 in MNT. This is how EigenDA is structured:
Operators
These are the service providers of EigenDA. In order tooperate a DA node, place (restake) from ETH in collateral. They sign up via their digital signature, must deploy a node and store data there for a predefined period. They then distribute this data on demand; Operators are rewarded in proportion to their stake.
The Dispersers
The Dispersers are the users of the data availability service, and pay for it. They encode the data for a fixed time period and give them to EigenDA operators. The fee depends on the period of availability.
They then aggregate the operators’ signatures, and post a certificate of the availability of data on the blockchain.
Challengers
Challengers play an important role. Firstly, they keep an eye on operations not checked on L1: in the event of a failure, the problem is solved on-chainand the offender is penalized (slashing).
The Challengers follow a very interesting protocol called Proof-of-Custody. This protocol solves the « lazy validator » problem. In effect, an operator could claim that his data is available, without this being the case. This saves resources and generates more profit. The PoC technique is ingenious: it involves inserting « trapped » data from time to time. If the operator fails to meet his obligations, he will miss out on the booby-trapped data, and be heavily penalized.
EigenDA’s smart contracts
Several smart contracts are responsible for the following tasks:
- Check data availability. The protocol requires a minimum of stake and signatures for operators.
- Implement Proof-of-Custody and allow challengers to distribute data on-chain ;
- Check the validity of disputes initiated by Challengers, and penalize the offending node where appropriate.
Data storage
First of all, the pieces of data are encoded by the Dispersers. They also generate evidenceThis allows operators to check that the fragment is correct. Next, the data is scattered to operators. Finally comes the phase of verification. If the data is correct, the operators store it, then generate a certificate for the given time period. This attestation is signed and sent back to the Dispersers. When the Dispersers have enough signatures for the data, they use them to send the data back. publish the aggregate on L1.
Interactions between Mantle Network nodes
The Sequencers and the Auditors constantly interact to maintain the system. Theoretically, a single auditor from rollup which can validate the entire chain and broadcast the block data to the other participants, is sufficient to ensure the integrity of the chain. security of the network.
Auditors have a economic interest to participate: they are rewarded when they produce valid proof of fraud. What’s more, maintaining a complete Ethereum node confers many advantages.
Transaction fees
On Mantle Network, these are made up of performance fees on the L2 and Ethereum fees, known as « data fees« .
Charges on the L2 (Mantle Network)
Visit execution costs of a transaction on Mantle Network are calculated in the same way as on Ethereum. It is the amount of gas required for the transaction multiplied by the price of gas.
The quantity of gas necessary is more or less the same as on Ethereum, thanks to the EVM compatibility compatibility. On the other hand price of gas are drastically more lowwhich is what makes layer 2 so interesting.
Fees on L1 (Ethereum)
While waiting for EigenDA to be deployed, the data charges L1 data costs account for the lion’s share of total usage costs. The data required to deploy a Mantle node is stored on Ethereum. So publishing L2 transactions on Ethereum is expensive. Costs depend on both :
- the price of gas ;
- The amount of gas required to publish the transaction. It is proportional to its size.
- A surplus of gas fixed (currently 2100);
- Dynamic gas surplus (currently by a factor of 1).
Rest assured, Mantle is currently in testnetand these costs will disappear whenEigenDA will be deployed. In the meantime, it is not possible to set a limit for L1 costs. The price of gas is automatically updated, which can vary L1 fees by plus or minus 25% in the event of extreme volatility.
On the L2is the user’s client software (its wallet) which will estimate the cost of the transaction. Next, the Sequencer calculates the necessary costs based on the price of gas. These costs are deducted from the user’s account, and the Sequencer sends the transaction on L1.
Mantle does not joinEIP-1559 (Ethereum’s fee market). It is therefore not advisable to send EIP-1559 transactions via Mantle to avoid errors in estimating the gas.
The fees collected by Mantle in MNT will be burned according to the governance protocol.
Mantle Network governance
The governance of Mantle Network, through its token, the MNT, is still being structured. In particular, MNT tokenomics are under discussion.
Key points
Governance involves a number of players and processes.
The token holders MNT can determine Mantle’s strategic direction. This includes, for example:
- Launching new products;
- Modification of tokenomics from MNT ;
- Allocation of expenditure items and budget;
- Corrective actions;
- Mantle’s organizational structure;
- Committee rules ;
- Technical choices ;
- Modification of governance parameters.
The token holders have authority and can actively participate in many aspects of the project.
The DAO (decentralized autonomous organization) of Mantle is flexible. It can be modified according to the proposals and its development.
Proposals are submitted under the MIP – label. Mantle Improvement Proposal. MIPs and their approval mechanisms are formalized with the community of token holders.
A period of review and feedback is used to gauge the general feeling towards the proposal. It is then modified if necessary, and put to the vote.
If approved, the proposal is implemented in code form and deployed. off-chain or on-chain.
The MNT token
The MNT is both a governance and a token utility. It gives its holders voting rights and practical functionalities.
In the governance processor, each MNT token has the same voting right. The weight of a vote is therefore weighted by the stake in MNT of the voter.
As for its utilitarian aspect, the MNT is first and foremost required to pay expenses to use the Mantle Network. In addition, it serves as collateral for Mantle nodes. This encourages its owners to become network players, thereby improving decentralization and security.
The MNT is an ERC-20 token like its counterparts for various L2s, such as Arbitrum or Optimism.
MNT tokenomics
All DTM tokens in the Treasury are subject to Mantle governance. The processes for budgeting, raising capital and distributing MNT are strict. For the time being expenditure items are considered:
- Adoption Mantle user adoption will be encouraged by various strategies. These may include trophies, quests or other incentive programs. Target metrics are, for example, the number of daily active users or TVL (total value locked) within the network.
- Partnerships On the technology front, it’s important to encourage dApps, infrastructure providers and rollup technology developers to contribute to Mantle’s growth. The team is open to collaboration.
- Core team and consultants The core team must of course be remunerated. This budget is also voted in full transparency.
- Various opportunities Any opportunities that may arise – acquisitions, token exchange, sale of Treasury tokens, etc. – are considered on a case-by-case basis, taking into account the long-term objectives of the Mantle ecosystem. Everything is examined on a case-by-case basis, taking into account the long-term objectives of the Mantle ecosystem.
For example, a vote is underway to decide on allocations for the first year of launch.
The MNT token delegation process
In order to vote, MNT holders must delegate their tokens to a given address. This may be the address of the holder, but it is unique.
La delegation tokens does not imply any lockand can still be transferred. Tokens delegated to a compromised, stolen or incorrect address are not lost. If necessary, the token holder can delegate them to another address.
Large MNT holders are encouraged to make their profile public. Similarly, they undertake to vote in the interests of Mantle users and holders. Finally, votes must be motivated by expertise or interest, and the reasons for the vote must be published on the forum.
Mantle Network governance framework and processes
Mantle’s governance is based on several parameters:
- The ratio vote/token is for the moment simply 1 DTM for 1 vote; however, the community may well propose weighted systems in the future.
- A quorum is required to avoid spamming the proposal community.
- The funds of the Treasury are managed by an implementation of Gnosis Safe. Indeed, this multisig infrastructure is particularly robust, tested and proven.
Mantle Network is governed by off-chain. First of all, Core Team or community members submit the fruits of their labors to the discussions. The latter must be sufficiently relevant to be introduced to the community via the forum :
If the discussion generates enough interest and positive feelings, it can be formalized into a proposal (MIP). Next, it will have to pass the vote MNT holders. In the case of a approvalCore Team members will ensure that implement it.
This governance process is called off-chainbecause the result of a vote does not automatically update the code. This is not the case, for example, with the governance mechanism of a blockchain like Bitcoin.
Like many DAOs on Ethereum, Mantle’s governance is carried out via Gnosis Snapshot :
Mantle Network in practice
Mantle is currently available on the Ethereum testnet Goerli. It is necessary generate some gETH testnet, then MNT via the faucet. If you wish to deploy a node, there are 3 possibilities.
Deploy a Mantle node
First, let’s start with a node Checker (Rollup Verifier). System requirements are as follows:
- CPU – 4 cores +
- RAM – 16 GB
- Disk – 100 GB + SSD
After purchasing the latest version of Mantle (a slightly modified version of Geth), you need to deploy the node via Docker. Then, download and compile the DTL script.
The case of MPC/TSS nodes is special. It requires a stake minimum of one million MNT and be approved by the Core Team. The specifications for such nodes are basic, since they’re all about storage (500 GB space, 4 GB RAM).
As for DA nodesbandwidth is the key. Here are the requirements for storing and distributing data:
- A minimum of 10 MB/sec download
- CPU – 4 cores +
- 1Tb SSD
- 8 GB RAM
All instructions and tools relating to node deployment can be found in the Mantle documentation.
Resources and bibliography
To find out more, here are all the links and the useful resources to understand Mantle Network and Optimistic Rollups in depth.
Mantle Network
Optimistic Rollups
Need a secure wallet to explore the many applications of DeFi? The best solution is still a personal hardware wallet. At Ledgerthere’s something for every profile and every crypto. Don’t wait to secure your capital (commercial link)!