1. Controversy over “What is Ethereum L2”

Last month, Dankrad tweeted: "If it doesn't use Ethereum as a data availability layer (DA), then it's not Ethereum's Rollup, and therefore not Ethereum's L2." He also said that Plasma and state channels are considered L2, but Validium is not. After Dankrad expressed his views, many builders and researchers in the L2 field began to question this. There are many L2 projects that do not use Ethereum as a data availability layer to save costs. If these projects are not included in the L2 list, it will have a significant impact on these expansion network projects. In addition, some people believe that if Validium is not counted as L2, then Plasma should not be counted either.

So, if you dig deep in Ethereum’s documentation, you might notice that they don’t say anything definitive about whether Validium is an L2 platform or not. But they do mention that Validium is more secure than Plasma because they use proofs of validity. This seems to contradict Dankred’s point that Plasma is more secure than Validium from some perspectives because users can exit using past states, which Validium cannot support. So, there is no definitive answer as to whether Plasmas and Validiums should be included in L2 or not.

However, L2BEAT applies a "Show only Rollup" filter on its website, allowing users to filter out all projects that do not use Ethereum as the DA layer. The debate about L2 and Rollup goes far beyond this. We have also heard many different opinions, such as "Data availability is a confusing term, Data publishing is better", "Classic Rollup is also sovereign Rollup", "Sovereign Rollup is not Rollup at all", etc.

So, instead of getting hung up on those definitions, let’s focus on a more meaningful topic: what kind of Ethereum L2 do we want?

2. What kind of Ethereum Rollup do we want?

By definition, Layer 2 is an independent blockchain that extends Ethereum and inherits Ethereum’s security guarantees.

The security issues of Ethereum Rollup are underestimated. We hope that Rollup will improve security and that there will be more modular blockchains customized for applications.

Here are the features we would like to have in a Layer 2 solution:

  • First, we want L2 to be able to scale Ethereum, which means L2 must have a verified bridge with Ethereum, enabling users to transfer assets between L2 and Ethereum and get the security of Ethereum. For example, I can use my ETH on Arbitrum L2 to make certain transactions at a relatively low cost while retaining the security of Ethereum.

  • Secondly, we hope that L2 can achieve ultra-high security by inheriting the security of Ethereum.

  • First, we want L2 to inherit the security of Ethereum. The best way to achieve this is to use Ethereum as a data availability (DA) layer as a Rollup of Ethereum. Ideally, we want to make L2 nodes trustless nodes, and only need to trust Ethereum to fully guarantee the security of Rollup.

  • Second, we want Rollup to inherit Ethereum’s liveness. Even if the Rollup node is not working, users should be able to run Rollup themselves, or at least have a way to exit L2 and withdraw funds back to L1.

  • In addition, we also hope that Rollup can inherit the decentralization and censorship resistance of Ethereum.

2.1 Inheriting Ethereum Security

In order to better inherit the security of Ethereum (ETH), Ethereum should be used not only for data availability and transaction ordering, but also for settlement. The Rollup layer is responsible for executing transactions and performing state transitions. Settlements are made with Ethereum through fraud proofs or validity proofs.

As you can see in the figure, the roles of Rollup nodes can be divided into 2-3 different types: Sequencer, Proposer, and ZK prover.

  • Sequencer plays an important role in Rollup. It packages transactions and submits them to the Ethereum network, using Ethereum to ensure data availability and transaction order.

  • At the same time, Proposer executes these transactions and generates the latest state of Rollup, and then submits the Merkle root of the new state to Ethereum. If this is an optimistic Rollup and no one challenges it within the specified time, then this state root will be accepted and the transaction will be confirmed.

  • In the case of ZK Rollup, the prover generates a zero-knowledge proof that proves the validity of the state root. Once the ZKP is submitted and confirmed on Ethereum, the transaction will also be confirmed.

Therefore, once all of this data is committed and confirmed on Ethereum, rolling back the Rollup transaction requires rolling back Ethereum, thus inheriting Ethereum's security guarantees. In addition, these three roles are sometimes played by the same node. In some protocols, such as Optimism, the Sequencer submits both the transaction batch and the Merkle state root.

Another security-related issue is Rollup state verification. As mentioned earlier, Optimistic Rollup uses fraud proofs, while ZK Rollup uses validity proofs, such as zero-knowledge proofs.

  • The advantage of using fraud proofs (such as Optimism and Arbitrum) is that Rollup can be equivalent to the Ethereum Virtual Machine (EVM). However, users must verify the chain to protect their funds, and due to its long challenge period of about 7 days, the final confirmation of transactions is slow.

  • ZK Rollup, such as Starknet, zkSync, Scroll, and Polygon zkEVM, provides stronger security by using zero-knowledge proofs to prove that the state was calculated correctly. Once the ZKP is verified on L1, the transaction will be completed immediately. This only takes a few minutes or at most a few hours, which is much faster than optimistic Rollup. However, ZK Rollup is generally not completely equivalent to EVM.

From a security perspective, zero-knowledge proofs work better. They rely on trustless cryptography for state verification, rather than relying on the honesty of incentivized participants like optimistic rollups do. But transaction fees can be higher, and they are not completely equivalent to the EVM. So the choice of which to use depends on the goals of the network.

In some cases, hybrid approaches can combine features of both Rollups. A new project called Morphism uses ZK validity proofs to respond to challenges in optimistic Rollup design, which can reduce the challenge window from 7 days to 1 day and reduce DA costs. OP stack has also explored ways to use ZKP to prove Optimism fault programs.

However, there are huge security concerns about the upgradeability of Rollup. When Rollup needs to fix bugs urgently or needs to be upgraded to support new features, sometimes it is necessary to upgrade the Rollup smart contracts on Ethereum. Therefore, who controls these smart contracts is crucial.

  • For many Rollups, the keys that control upgrades are held by core team members. In theory, these members have the ability to steal users' funds by using the upgrade mechanism. As Vitalic said, this is like a "backdoor" for developers.

  • To avoid this problem, upgradeability can be disabled. For example, Fuel V1 disabled upgradability, but each update iteration required smart contracts to be redeployed, and users needed to manually migrate their assets to the new version. This process is similar to starting a new project, resulting in fragmented liquidity and significantly reduced flexibility.

  • A better approach is to use a DAO for governance upgrades and set a delay to allow users who disagree with the upgrade to exit before the upgrade occurs. This adds some DAO security assumptions to Rollup, such as the honest majority assumption.

In general, in order to inherit the security of Ethereum, we recommend that Rollup use Ethereum in terms of data availability, transaction ordering, and settlement. For state verification, it is more reliable to use zero-knowledge proof. If we want to support upgradeability, it is best to use DAO to manage upgrades and give users enough time (for example, 30 days) to exit.

2.2 Inheriting Ethereum Survivability

Now, let’s talk about how to inherit liveness from Ethereum.

We hope that even if the current serializer and proposer go down, with the help of the Ethereum mainnet, users can still recreate the L2 state and keep the Rollup running, or at least users have a way to exit to L1 without trust.

  • However, we found that many existing Rollups lack this mechanism so far, such as Optimism, zkSync Era, and Base. Therefore, if this happens, the Rollup will stop running and everyone will lose their funds on L2.

  • Some Rollups allow users to force an exit and withdraw their funds on L1 by submitting a Merkle proof or ZK proof of the funds on L2.

  • But some Rollups do not allow you to withdraw assets other than collateral, which means your L2 native assets cannot be withdrawn. If you trade your collateral for NFTs or LP tokens, you may not be able to get them back on Ethereum L1.

  • Rollups like dYdX allow you to enforce the conversion of L2 native assets into collateral and then withdraw them on L1.

  • Some Rollups also support extracting NFTs to L1.

  • A better solution would be to allow users to also become Sequencers and Proposers to keep the Rollup running. For example, Polygon zkEVM uses a permissionless Sequencer. Arbitrum allows users to force a transaction to be included in the Rollup by sending it to L1 (this action has a one-day delay). In addition, anyone can become a proposer after the current whitelisted Proposer has been inactive for 6 consecutive days.

In fact, activity is also related to the degree of decentralization. If the Rollup nodes are more decentralized and censorship-resistant, the Rollup will have better activity.

Therefore, to improve the survivability of Rollup, we propose decentralized nodes that allow users to sort and propose transactions themselves in the event of failures.

2.3 Inheriting Ethereum’s decentralization and censorship resistance

Research on Rollup decentralization mainly focuses on decentralized sequencers.

  • Today, almost all Rollup networks use only one centralized sequencer. The sequencer has the ability to reject user transactions and maliciously withdraw MEV, which will cause economic harm to users. In addition, using a single sequencer lacks censorship resistance.

  • Therefore, one of the promising methods that Rollup is exploring to achieve decentralized sequencers is the permissionless PoS decentralized sequencer. This method is used in Morphism Rollup, where the sequencer is selected according to the POS rule and a BFT-based consensus algorithm is executed to reach consensus on transaction batches. Some other Rollups are trying to use the leader election method to elect a leader sequencer in each epoch.

  • Another way is through MEV auctions. In each era, participants bid according to the profit they expect from transaction fees and the MEV they can extract as a sequencer. The winner pays their bid amount to the Rollup Treasury and gains the right to sequence transactions and capture all profits within that era.

  • Polygon's Proof-of-Efficiency is another approach where anyone can become a sequencer or aggregator. Sequencers pay an additional fee to prevent spam attacks when proposing transaction batches to Ethereum L1. Aggregators verify batches of transactions posted by sequencers, and the first aggregator to submit a proof of validity will receive the tokens deposited by the sequencer. However, the computing resources of lagging aggregators may be wasted.

  • In the shared sequencer approach, a group of nodes provides ordering services to multiple Rollups. Rollups connect to the shared sequencer network to handle their transaction ordering and block generation. The shared sequencer pool is decentralized (they execute the consensus protocol to agree on transactions and submit batches of transactions)

All of these technologies regarding decentralized sequencers are still in their infancy and are still evolving. Therefore, at this time we can only provide a neutral assessment.

ZKP provers can be as decentralized and permissionless as Polygon’s Proof-of-Efficiency, as they cannot enforce MEV and are difficult to act maliciously.

In summary, we need decentralized serializers and provers to enhance the decentralization and censorship resistance of Rollup.

In addition to security issues, there are many other factors to consider. Here are some relevant questions:

  • How to balance the incentives of sequencer and ZKP prover? Sequencer can execute MEV, while prover cannot. This mechanism makes people more willing to become serializers. However, in reality we need more provers than sequencers, because generating zero-knowledge proofs requires more computing power than packaging transactions. So, how to balance the incentives between the two? I think we need to design a clever dynamic fee model and incentive model.

  • After the EIP4844 upgrade, Rollup will use blobs to store data, and blob data is only saved on Ethereum for 1-3 months, so will this affect Rollup? My answer is yes, I think there will be some small impacts, but they are easy to solve. Rollup's historical data can be uploaded to decentralized storage for archiving. If all Rollup nodes go offline (especially in the current single serializer case), users will need to download historical data from the decentralized storage system and combine it with the blob data from Ethereum L1 to rebuild the state.

  • How to reduce Rollup transaction fees? There are many trade-offs between security, decentralization, and cost-effectiveness when designing Rollup. For example, we use ZKP to verify the state for enhanced security, but this requires more computing power and also makes transactions more expensive. This is a trade-off between security and cost. Some ZK Rollups use recursive proofs to aggregate ZKPs across multiple transaction batches, and then submit the aggregated proofs to L1. This can save Gas costs on Ethereum and reduce L2 transaction fees, but it will also lengthen the time for final confirmation of transactions.

Summarize

To sum up, let’s go back to our original question: what kind of Ethereum Rollup do we want?

  • First of all, we hope that Rollup will inherit not only the security of Ethereum, but also its survivability, decentralization, and censorship resistance.

  • In fact, it is very difficult to create an L2 Rollup that does not introduce additional trust assumptions, because upgradeability, decentralized serializers, and trusted settings for zero-knowledge proofs may all involve additional trust assumptions. It cannot be said that L2 Rollup fully inherits the security of ETH without trusting any L2 Rollup nodes.

  • For better security. The upgrade of L1 Rollup smart contract should be governed by DAO and set a delay to allow users enough time to exit if they disagree with the upgrade. However, this approach also introduces the security assumption of DAO into the system.

  • Last but not least, instead of using a single serializer, use a decentralized serializer for better survivability, decentralization, and censorship resistance.

Before I wrap up my presentation, I want to emphasize that if anyone here has great ideas and needs the resources to realize them, please don’t hesitate to contact us at Foresight Ventures.

In addition, we invite you to join our Foresight X incubation program. We are here to support and nurture your entrepreneurial journey. With our deep industry knowledge and rich resources, we will ensure your project thrives.

Additionally, if you work in academia or research, Foresight X offers competitive grants to support your research path.

Also, we have a QR code here that has all the links you might be interested in, including research reports. Feel free to take a picture or scan that code for more information, and you can find me on Twitter if you have any questions after the session.

Thanks again for your time; I hope you all had fun and have a great day.

For the PPT content, please click here: https://img.foresightnews.pro/file/L2(0920).pdf