Claim Layer3 rewards
Much of the gas cost incurred on an optimistic layer 2 network is to offset the cost to rollup the transaction to Ethereum L1. Ethereum mainnet is expensive. For example,
https://etherscan.io/tx/0x801b65cfd1f0de5a184f42bab7d74e41234d2f8837fc5efae9506dadbd78ba15
The above transaction rolled up 107 transactions. At the time of writing this post, the cost of that transaction is $100 dollars. If we factor in the transaction cost for submitting the state batch, the cost of each transaction is already above a dollar. And this is when the gas price is ONLY at 75 GWEI. Ethereum mainnet when busy can have gas price up to 200 GWEI (or more when large airdrops are happening) The roll-up cost of each transaction can easily surpass 3 dollars, making layer 2 transactions cost still a bit steep for many users.
At this point, someone may ask: so if the majority of the cost comes from the transaction rollup, why do we rollup that expensive blob of data?
The answer is network security. Transaction data is crucial to ensure the data integrity of an optimistic layer 2 network. When Metis produces a block, there is no block production consensus. The block is made by the current block producer on duty. Metis’s security is ensured by a delayed validation consensus, i.e. validators constantly checking that the block producer and the sequencer both are honest and challenging when fraudulent behavior is observed.
Metis’s validation consensus is accomplished by two separate mechanisms. The first mechanism ensures the block production correctness in near real-time. Basically, when a block is produced by the current block producer on duty, the peer network will immediately validate the block. If the block producer on duty is dishonest, the peers will catch it immediately on the first block and halt the network. The election of a new block producer will follow with a rollback of one block. The peer network holds the block producer accountable and minimizes the rollback required. However, this mechanism does not prevent sequencers to submit incorrect state roots, which may result in fraudulent withdrawals from layer 2.
The second mechanism is the core of any optimistic rollups: Fraud proofing. Fraud proofing is a signature mechanism which allows the network to be secured as long as there is at least one honest player. However, fraud proofing requires two types of inputs to be on-chain in order to work, the state roots and the transaction information. The core of the fraud proofing, which Metis is currently implementing, is to be able to deterministically compute the result state given a starting state and the transaction data. The transaction data needs to contain all required information to support such computation on chain in the smart contract. The information requirement to support such computation is not trivial. For example, Metis’s working-in-progress fraud proofing requires compressed state transition opcodes, which can easily cost more than a dollar when rolled up to L1. Fraud proofing ensures that the peer network is always honest and also protects users from fraudulent withdrawals.
So we absolutely need the data to ensure security, there is no hope, right?
There are some details we purposely omitted in the previous section. The most important bit is that we don’t need the transaction data all the time.
First, the network itself does not depend on the submitted transaction data. The block is produced by following the normal EVM execution, the state root is computed accordingly and submitted to L1. Transaction relayers will be able to relay the transactions to L1 if there are any cross domain messages included in the state root batches. The transaction data is only required when on-chain fraud proofing is required. I.e. when a validator challenges the state submission by the sequencer. If the sequencer is honest, the transaction data submitted is mostly wasted other than serving as a chain replica to restore the chain from L1 when the entire L2 network data is lost. With Metis’s vast peer network, the likelihood of requiring a network restore is negligible. Thus. to Metis, the transaction data is only required to be on chain when a challenge is initiated.
Second, for the purpose of fraud proofing, the transaction data is only required to be on chain for the duration of the challenge window. Metis currently has a 7 day window for validators to challenge the submissions. Therefore, the transaction data is only needed for 7 days.
Obviously, we say to ourselves, what a waste it is to spend all the computation power to reach a consensus for those blobs of data that have no practical use most of the time. All those energies and CO2 footprint are there to cover a rare scenario. There must be a better way, right? There must be. We just need to reduce the data size we need to submit to the Ethereum mainnet.
Before I go on talking about how Metis reduces the data size, I would like to discuss some alternatives first. While I was writing this paper, I noticed another interesting development, which forks the Ethereum mainnet to support temporary blob data.(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md) The work actually is based on a similar idea as Metis’s solution. However, the caveat is that it requires changes in the protocol. We don’t know how long it will take and how much saving it will be able to achieve, because the gas price for the blob data is still undetermined. We, at Metis, would like to accelerate the Layer2 adoption as soon as possible. Thus we are not going to depend on this fork to reduce the transaction cost. However, Metis will continue following this development. It is fairly easy to switch to this solution if it makes sense in the future. And when the EIP is implemented, our solution will also benefit a lot from it due to reduced storage cost for transaction data.
The key idea to our approach is to submit what is needed only when it is needed. The state roots submission is untouched because we can already roll up thousands of transactions in one state batch submission. The cost per transaction is very low already. What we will focus on is the transaction data submissions. This is how it works.
First, the sequencer will grab the latest batches of transactions on the chain and compile the required transaction data to support the fraud proofing. Then, the sequencer will compute a merkle tree root of compiled transaction data. Next, the sequencer will compute an identifier based on the merkle tree root, which then is used to submit the data to our decentralized storage partner Memolabs. Memolabs was chosen as the storage partner because of their state-of-art technology and friendly incentive mechanism, which supports both high data availability and data security. Once the data is available in the decentralized storage, the merkle tree node is then submitted to the Ethereum mainnet as part of the rollup. Thus, the transaction data rollup for the batch is done.
When verifiers see the submission, based on the submitted hash, the verifiers will be able to locate and download the transaction data from the decentralized storage so that they can compute the state roots and compare them with the submitted state roots. If verifiers are happy about the submission, nothing else is required,
However, when a challenge is initiated, the verifier can either pay the sequencer to write the selected actual transaction data back to Ethereum or submit the transaction data to Ethereum itself. When writing the transaction data, the smart contract ensures that the data is included in the merkle tree root when the roll-up was done. Once the transaction data is on chain, the fraud proofing can then be carried out by the validator to potentially slash the sequencer.
With the above mechanism in place, we can avoid submitting most of the transaction data to the Ethereum mainnet, while still supporting fraud proofing to secure the network. Because the cost of rollup becomes negligible, Metis will no longer charge for rollup costs in the future, which effectively brings the cost of transactions in the range of cents.
Some security-minded audiences may already start wondering whether the system is attackable. The answer is yes, it is attackable. Thus, I will enumerate the possible scenarios and introduce some additional mechanics.
It is actually possible for a dishonest sequencer to purposely submit an invalid hash to Ethereum. The sequencer can do so because the fraud proofing only works when the full transaction data is on chain. But the transaction data can only be written to the chain when the hash matches with the submitted hash. When a sequencer submits an invalid hash for the transaction data, the sequencer effectively evades the fraud proofing challenge. This attack will render the whole mechanism useless. Thus we have added an interesting mechanism to address it. Here is how it works. A white-listed validator can deposit some ETH to request the sequencer to write the transaction data to the Ethereum mainnet. If the sequencer fails to fulfill the request, the same validator can then write the transaction data in without need of matching the hash. The transaction data then will be used for fraud proofing afterwards.
In this way, if a sequencer tries to evade the fraud proof by submitting invalid hash, the sequencer will not be able to submit the transaction data itself, which will eventually be slashed by the validator once the validator writes the correct transaction data in.
One may ask what if the white-listed validator submits invalid transaction data. The validator will not be able to successfully complete an interactive fraud proofing process in this case. Thus there is no incentive for the validator to do so.
It is also possible for a profit-minded sequencer to keep a copy of the correct transaction data but submit the invalid transaction data to the decentralized storage. When the white-listed validator requests the transaction data, the sequencer will always be able to write the correct data in because the sequencer has a copy. There are two details to cover to address this scenario.
First, the payment the validator makes needs to be high enough to deter the unnecessary requests but low enough so that the sequencer does not profit from such transactions. The smart contractor will rely on gas price oracles to calculate the appropriate amount.
Second, the transaction data is readily available on the metis network. Anyone can compile and compute the correct transaction data to submit to Ethereum for fraud proofing. So even if the copy in the decentralized storage is invalid from the start, validators can still validate the state roots and start a challenge.
When the sequencer is a trusted entity, the above scenario is unlikely to happen. But when Metis fully decentralizes the sequencers and block producers, there is no guarantee that there won’t be malicious users trying to hurt the ecosystem even if it means that they will lose a lot of money in the process. Metis has a governance smart contract in place that manages the whitelist of validators and sequencers. The community can vote malicious users out of the whitelist if required as the last line of defense to ensure the stability of the ecosystem. Note that, the validator needs to be whitelisted only to request the sequencer to write the transaction data. Fraud proofing can be initiated by anyone.
The idea of lazy loading the transaction data has been discussed internally for a long time. I’m thrilled that it has become a reality. I hope this article gives everyone a good idea of our thought process when trying to promote layer 2 adoptions by further lowering the transaction costs. The system isn’t perfect. But we believe it strikes a perfect balance to lower the transaction cost with adequate security. The beauty of this approach is that we do not need to fork the chain and are still backed by the security of Ethereum through fraud proofing. Now, let’s all enjoy Metis Layer 2 to its full potential until the next article for our journey of decentralization.
