Mantle is a layer-2 network built on Ethereum with a modular architecture, which provides high performance, low fees, and high security. Developers can utilize Mantle’s unique design to build decentralized applications (dApps) that offer an exceptional user experience, while relying on Ethereum’s unparalleled security.
Mantle achieves its high performance through a combination of roll-up technology and a decentralized data availability layer that provides faster finality and low fees. The Ethereum ecosystem encourages independent verification of information through the maxim “don’t trust, verify.” The data availability problem arises when nodes need to confirm the validity of transaction data that is being added to the blockchain without requiring all nodes to download all data.
Data Availability
Data availability refers to the confidence users have that the data required to verify a block is available to all network participants. Full nodes on Ethereum layer 1 achieve this relatively easily by downloading a copy of all the data in each block. However, modular blockchains, layer 2 rollups, and light clients require more sophisticated verification procedures.
The data availability problem is a significant barrier to scaling solutions for Ethereum. Light nodes and layer 2 rollups need strong data availability assurances, but cannot download and process transaction data for themselves. Future “stateless” Ethereum clients also require data availability assurances.
There are two solutions to the data availability problem. Data Availability Sampling (DAS) is a way to check data availability without putting too much strain on any individual node. Each node downloads a small, randomly selected subset of the total data, relying upon data erasure coding to expand the dataset with redundant information. Data Availability Committees (DACs) are trusted parties that provide or attest to data availability. They can be used instead of, or in combination with DAS. Ethereum uses randomly sampled subsets of validators to attest to data availability for light nodes.
DACs are also used by some validiums to store copies of data offline and provide on-chain attestations. Some validiums replace DACs with a proof-of-stake (PoS) validator system. In this system, anyone can become a validator and store data off-chain, but they must provide a “bond” deposited in a smart contract. Proof-of-stake data availability committees incentivize honest behavior and are more secure than regular DACs.
Hyperscale Performance
Mantle is a layer-2 (L2) blockchain that aims to provide hyperscale to Ethereum by using a modular chain approach. It achieves this by leveraging a separate decentralized data availability layer and combining it with Ethereum roll-ups. This approach offers higher security than existing scaling solutions (L2s, sidechains, etc.) while allowing for broader adoption in emerging markets where gas fees have priced many people out of the ecosystem. The Mantle network is the first Ethereum layer-2 chain initiated by a DAO, BitDAO, which is also the native gas token of Mantle.
Mantle’s approach is different from existing L2s, which rely on a monolithic architecture combining settlement, execution, and data availability. This architecture makes it challenging to achieve hyperscale and has resulted in gas savings that are not enough to support broader adoption. Mantle’s approach combines roll-ups with data availability, building robust decentralized data layers with high security using re-staking mechanisms. This approach opens up many new use cases, including social graph protocols, advanced DeFi protocols, and game ecosystems, without compromising on security.
Mantle is also on the bleeding edge of network design, adopting innovations early to greatly improve the user experience of the web3 ecosystem. For example, Mantle aims to be the first network to adopt EIP-3074, which extends contract functionality and meta-transactions to externally-owned accounts. With meta-transactions, a user can enjoy gasless transactions, paid for by a dApp developer, a friend, or even a wallet developer, reducing the barrier to entry for onboarding the next generation of web3 users.
Being EVM-compatible, Mantle allows all the contracts and tools that work on Ethereum to work with Mantle with minimal modifications, providing an efficient, low-fee environment for developers to deploy smart contracts. The Mantle network is committed to building the most innovative and forward-thinking L2 network designs to solve mass adoption of web3 technology.
How to Use Mantle Testnet
Are you interested in exploring Mantle, a recently announced modular layer 2 built on Ethereum? Mantle is a decentralized platform that enables users to interact with Ethereum-based applications more efficiently and cheaply. In this guide, we will walk you through the process of onboarding to Mantle’s testnet, so you can start using it today!
Before we begin, you will need a web3 wallet. This tutorial will use the MetaMask browser wallet, but Mantle is also compatible with WalletConnect and Coinbase Wallet. If you don’t have a web3 wallet yet, we recommend downloading MetaMask from here.
Once you have a web3 wallet, you can start onboarding to Mantle’s testnet by following these steps:
Step 1: Add Mantle Testnet to Metamask
Mantle uses $BIT as its native token, so before bridging to Mantle, we need to tell MetaMask to recognize both the Mantle blockchain and the $BIT testnet token. You have two options to add Mantle to MetaMask:
Option 1: The easiest option is to go to ChainList.org, check the box that says “Include Testnets,” and search for “Mantle.” When you see “Mantle Testnet,” press “Connect Wallet” (or “Add to MetaMask” if connected), and a prompt will appear to add a network to MetaMask. Press “Approve,” and then confirm your switch to Mantle Testnet.
Option 2: Open MetaMask and click where it says “Mantle Testnet” (or any other chain you are connected to) and switch to the Goerli Test Network. Under the “Assets” heading, look to the very bottom and press “Import Tokens.” Paste the following address into the Token contract address field: 0x5a94dc6cc85fda49d8e9a8b85dde8629025c42be, and you should see MetaMask autofill the following information. Approve the next two prompts (Add Custom Token, Import Token), and you’re one step closer!
Step 2: Acquiring Test $BIT
The Mantle Testnet Faucet helps users receive testnet $BIT to explore the network and experiment with dApps. Using the faucet will require a small amount of Goerli ETH ($gETH) to cover the gas fee for minting $BIT. If you need Goerli ETH, you can use either the Paradigm or Alchemy faucets.
Visit https://faucet.testnet.mantle.xyz/, verify your humanity, and enter your Ethereum address. You can mint up to 1000 $BIT. You should see the $BIT in your wallet shortly!
Step 3: Bridging to Mantle
You are now ready to bridge your funds over to Mantle. Your wallet addresses are 1:1 across both Mantle and Ethereum, so the address you’ve used so far will be waiting for you on Mantle.
Visit https://bridge.testnet.mantle.xyz/ to use the Mantle Bridge. Confirm once more that you are connected to Goerli (it will show in the top right of the Bridge interface). Decide whether you will be bridging $BIT or $ETH, input the transfer amount, and press “Deposit.”
Mantle will ask to approve the transaction in-browser, followed by another confirmation in MetaMask. Congratulations, your tokens are on their way to Mantle Testnet! You can view the transaction status using the Etherscan link provided by the UI.
Step 4: See Your Tokens on Mantle
Now all that’s left to do is see that your tokens have arrived safely in your Mantle address. Open MetaMask and switch
Data Availability and Light Nodes
In this blog post, we will discuss data availability and light nodes in the context of Ethereum. Light nodes are unable to independently verify block headers by re-executing transactions locally in the same way that full nodes can. To get around this, Ethereum light nodes trust random sets of 512 validators assigned to a sync committee that signal to light clients that the data in the header is correct using a cryptographic signature. However, there is still a chance that an attacker could pass a malicious block header to light clients and convince them that it was signed off by an honest sync-committee. To prevent this, light clients could use fraud proofs. A full node could generate a small piece of data demonstrating that a proposed state transition could not possibly arise from a given set of transactions and broadcast that data to peers. Light nodes could pick up those fraud-proofs and use them to discard bad block headers, ensuring they stay on the same honest chain as the full nodes.
In the context of layer 2 scaling solutions, such as rollups, data availability becomes an even bigger issue. Rollups process transactions off-chain and then post compressed transaction data to Ethereum in batches. To trust the summary transactions posted to Ethereum, the state change proposed must be independently verified and confirmed to be the result of applying all the individual off-chain transactions. If rollup operators do not make the transaction data available for this verification, then they could send incorrect data to Ethereum. Optimistic rollups wait for a certain amount of time to allow independent verifiers to check the data, but after that, data availability is only guaranteed for a short fixed window. ZK-rollups don’t need to post transaction data since zero-knowledge validity proofs guarantee the correctness of state transitions. However, data availability is still an issue because we can’t guarantee the functionality of the ZK-rollup without access to its state data.
It’s important to note that data availability is different from data retrievability. Data availability is the assurance that full nodes have been able to access and verify the full set of transactions associated with a specific block. Data retrievability, on the other hand, is the ability of nodes to retrieve historical information from the blockchain. This historical data is not needed for verifying new blocks, it is only required for syncing full nodes from the genesis block or serving other purposes.
