Foresight Ventures: What Kind of Ethereum Rollups Are We Looking For? (Zuzalu Hackathon)

by Maggie, Foresight Ventures

Good afternoon, everyone. Thanks for showing up. My name is Maggie; I am the Tech lead at Foresight Ventures. Today, we will spend 30 minutes to discover a fun topic “What Kind of Ethereum Rollups Are We Looking For?”.

Now I’d like to start by briefly introducing our company.

  • Foresight Ventures is a research-driven powerhouse in the field of crypto investment and incubation. Our product matrix includes several key components:
  • Foresight News — the largest multilingual web3 media platform in the Asia-Pacific region.
  • We proudly operate Foresight X, an accelerator that provides dedicated support to spin-up crypto startups, building a thriving global Web3 developer community along the way.

If you would like to learn more about us, please don’t hesitate to visit our official websites or connect with us on our social media channels.

Now let’s move on to today’s agenda. First, let’s review the recent controversies around “What is Ethereum L2” and Rollups. After that, we will discuss “what kind of Ethereum rollups we are looking for.”

1. Controversies over ‘What is ETH L2’ and Rollups.

So last month, Dankrad tweeted that “if it doesn’t use Ethereum for DA, it is not an Ethereum rollup and therefore not an Ethereum L2”. He also said that plasmas and state channels are considered L2s, but Validiums are not. After Dankrad’s posted his opinion, many builders and researchers in the Layer 2 (L2) field began to question it. Because After all, there are a lot of L2 projects that don’t use ETH as the data availability layer to save costs. If those projects aren’t included in the L2 list, it could significantly impact those scaling network projects. Furthermore, some of them argued that if Validiums are not L2s, then Plasmas shouldn’t be counted either.

So, if you digging around in Ethereum’s documentation, you might notice that they’re somewhat unclear about whether Validiums are part of L2 or not. However, they did say that Validiums are more secure than Plasmas because they use validity proofs. This seems to conflict with Dankred’s ideas, as he believes that in some perspectives, Plasmas are more secure than Validium because users can exit using the past state, while Validiums cannot.

So, there’s no certain answer to prove if Plasmas and Validiums should be included in L2 or not.

However, L2BEAT applied a ‘show rollups only’ filter on its site, which allows users to filter all projects that do not use Ethereum as the DA layer.

As we can tell here, the debate about L2 and Rollup is far more than that. We also heard a lot of opinions, like “Data availability is a confusing term, data publishing is better”, “Classic Rollups are also Sovereign Rollups”, and “Sovereign Rollup is not a Rollup at all.”

So, Instead of struggling with those definitions, let’s focus on a more meaningful topic, What kind of Ethereum L2 do we want?

2. What Kind of Ethereum Rollups Are We Looking for?

A layer 2 is a separate blockchain that extends Ethereum and inherits the security guarantees of Ethereum.

So, here are the features we want in a Layer 2 solution:

  • First of all, we want a Layer 2 that can scale up Ethereum, which means that the Layer 2 must have a validating bridge to Ethereum allowing users to move assets back and forth and get a security guarantee from Ethereum. For example, I can use my ETH on Arbitrum L2 to make some transactions at a relatively lower cost, and I can retain Ethereum’s security in the meantime.
  • Second, we expect the L2 to be super secure by inheriting security from Ethereum.
  • We first want Layer 2 to inherit safety from Ethereum. The best way to do so is to use ETH as the data availability (DA) layer and be a Rollup. Ideally, we want to make L2 nodes trustless, and only trust Ethereum to fully guarantee the safety of the Rollup.
  • Secondly, we want the rollup to inherit the liveness of Ethereum. Even when the nodes of Rollup are not working, users should be able to run the Rollup by themselves, or at least they have a way to exit L2 and get their money back to the L1, as long as Ethereum is alive.
  • And then, we want the Rollup to inherit the decentralization and censorship resistance of Ethereum as well.

2.1 Inheriting Safety from Ethereum

To better inherit the safety of Ethereum (ETH), it is important to use Ethereum not only for data availability and transaction ordering but also for settlement. The Rollup layer is responsible for executing the transactions and applying state transitions. It anchors back to Ethereum for settlement through fraud proofs or validity proofs.

As you can see on the diagram, the roles of Rollup nodes can be classified into 2–3 different types: sequencer, proposer, and ZK prover.

  • The sequencer plays an important role in the Rollup by packaging transactions and submitting them to the Ethereum network, using Ethereum for data availability and transaction ordering.
  • Meanwhile, the proposer executes those transactions and generates the latest state of the Rollup, then submits the Merkle root of the new state to Ethereum. If this is an Optimistic rollup, and no one initiates a challenge within the specified time, then this state root will be accepted, and then the transactions will be settled as well.
  • In the case of ZK Rollup, a Prover generates Zero-knowledge proofs to prove the validity of the state root. Once the ZKP is submitted and confirmed on Ethereum, the transactions will be settled as well.

So, once all these data are submitted and confirmed by Ethereum, reverting the rollup’s transactions requires reverting Ethereum, therefore inheriting Ethereum’s security guarantee. These roles are sometimes played by the same node. In some protocols, such as Optimism, the transaction batch, and Merkle state root are submitted at the same time by a sequencer.

Another safety-related issue is the rollup’s state validation, as mentioned earlier, Optimistic rollups use fraud proofs while ZK rollups use validity proofs like zero-knowledge proofs.

  • The advantage of using fraud proofs, like Optimism and Arbitrum, is that the rollup can be EVM-equivalent. But, users have to validate the chain to protect their funds, and due to its long challenge period, which is around 7 days, the transaction finality is slow
  • ZK rollup, like Starknet, zkSync, Scroll, and polygon zkEVM, provides enhanced security by using zero-knowledge proof to prove that the state is correctly computed. Once ZKPs are verified on L1, the transactions will be finalized immediately. It only takes a couple of minutes or up to a few hours, which is much faster than optimistic rollups. However, ZK rollups are usually not fully EVM equivalent.

From a security perspective, zero-knowledge proofs work better. They rely on trustless cryptographic mechanisms for state validation, not the honesty of incentivized actors as with optimistic rollups. But the transaction fees could be higher, and not fully EVM equivalent. So choosing which one to use is decided based on the network goals. In some cases, a hybrid approach may combine the features of both rollups. A new project called Morphism uses ZK validity proof to answer the challenges in the optimistic Rollup design, which can reduce the challenge window from 7 days to 1 day and reduce the DA costs. OP stack also explores methods to use ZKP to prove the Optimism fault-proof program.

However, There’s a huge security concern about Rollup’s upgradability. When an urgent bug needs to be fixed or the Rollup needs to be upgraded to support new features, sometimes we need to upgrade the Rollup smart contracts on Ethereum. So who controls those smart contracts is essential.

  • For lots of Rollups, the keys that control the upgrade are held by core team members. In theory, these members have the capability to steal users’ funds by using the upgrade mechanism. Like Vitalic said it is like a “backdoor” for developers.
  • To avoid this issue, you can disable the upgradability. For example, Fuel V1 disabled upgradability, but each update iteration requires redeploying smart contracts and users need to manually migrate their assets to the new version. This process is similar to launching a new project, resulting in fragmented liquidity and significantly reduced flexibility.
  • A better approach is to use DAO for governance upgrades and set a delay to allow users who do not agree with the upgrade to exit before it happens. This added some DAO’s security assumptions like the honest-majority assumption to the Rollup.

Overall, to inherit the safety of Ethereum, we recommend Rollup using Ethereum for data availability, transaction ordering, and settlement. For state validation, using zero-knowledge proof is more reliable. If we want to support upgradability, it would be better to use DAO to govern upgrades and give users enough time(e.g. 30 days) to exit.

2.2 Inheriting Liveness from Ethereum

Now, let’s talk about how to inherit liveness from Ethereum. We hope that even if the current sequencer and proposer fail, with the help of Ethereum mainnet, users can still recreate the L2 state, and keep the Rollup running, Or at least users have a way to trustlessly exit to L1.

  • However, we find that many of the existing rollups so far lack this kind of mechanism, like Optimism, zkSync Era, and Base. So if that happens, the Rollup just stops and everybody loses their money on L2.
  • Some of the rollups allow users to force exit and withdraw their funds on L1 by submitting a Merkle proof or ZK proof of funds on L2.
  • But some rollups won’t let you withdraw your assets other than collateral /kəˈladərəl/, which means that your L2 native assets cannot be extracted. if you trade your collateral for NFTs or LP tokens, you might not be able to get them back on Ethereum L1.
  • Rollup like dYdX, allows you to force execute to convert the L2 native assets to collateral and then withdraw them on L1.
  • Some rollups also support extracting the NFTs to the L1.
  • A better solution here is to let users jump in as sequencers and proposers to keep the rollup running. For example, Polygon zkEVM uses permissionless sequencers. Arbitrum allows users to enforce transactions to be included in the rollup by sending them to L1. (This action has a one-day delay). Additionally, anyone can become a Proposer after the current whitelisted Proposers have been inactive for over 6 days.

In fact, liveness is also related to the degree of decentralization. Better decentralization and censorship resistance of rollup nodes will result in better liveness.

So, to improve rollups’ liveness, we recommend decentralizing the nodes, allowing users to sequence, and propose by themselves when crashes.

2.3 Inheriting Decentralization and Censorship Resistance from Ethereum

The research on Rollup decentralization focuses on decentralized sequencers.

  • Nowadays, almost all rollup networks use just one centralized sequencer. The sequencer is able to deny user’s transactions and extract malicious MEV, which could be economically harmful to the users. Furthermore, using a solo sequencer lacks censorship resistance.
  • So, rollups are exploring some promising methods for decentralized sequencers. One of them is permissionless PoS decentralized sequencers. This method is used in Morphism rollup, sequencers get selected under the POS rules and perform a BFT-based consensus algorithm to reach consensus on transaction batches. Some other rollups try to use a leader election method to elect a leader sequencer working at each epoch.
  • Another method is through MEV auctions. During each epoch, participants bid based on the expected profit from transaction fees and MEV they can extract as the sequencer. The winner pays their bid amount to the rollup treasury and earns the right to sequence transactions and capture all profits during the epoch.
  • Polygon’s proof-of-efficiency is another approach where anyone can be a sequencer or an aggregator. Sequencers deposit an additional fee to prevent spam attacks when proposing transaction batches to the Ethereum L1. The aggregators validate batches posted by sequencers and the first one who submits the validity proof will receive the tokens that the sequencer deposited. However, the computing resources of those aggregators who fall behind may be wasted.
  • In the shared sequencers method, a network of nodes provides sequencing-as-a-service to multiple rollups. Rollups plug into the shared sequencers network to handle their transaction ordering and block production. And the shared sequencer pool is decentralized. (they perform consensus protocol to agree on transactions and propose transaction batches)

All these techniques for decentralized sequencers are still in their preliminary stages and still in development. Therefore, for now, we can only provide a neutral evaluation. The ZKP prover can be decentralized and permissionless like Polygon’s proof-of-efficiency, as they cannot perform MEV and are hard to act maliciously. In summary, we require decentralized sequencers and provers to enhance the decentralization and censorship resistance of Rollups.

Besides the issues of security, there are many other factors to consider as well. Here are some of the questions.

  • How to balance incentives between sequencers and ZKP provers? Sequencers can do MEV, while provers cannot. This mechanism makes people more likely to become sequencers. However, we actually need more provers than sequencers, because generating zero-knowledge proofs requires much more computational power than packing transactions. So, how can we balance the incentives between the two? I think we need to design a clever dynamic fee model and incentive model.
  • After the EIP4844 upgrade, Rollups will use blobs to store data, and blob data is only saved for 1–3 months on Ethereum, So will this affect Rollups? My answer is yes, I think there is a minor impact, (but it is easily solvable). The historical data of Rollup can be uploaded to a decentralized storage for future use. If all nodes of the Rollup go offline (especially in the current single sequencer situation) users will need to download historical data from the decentralized storage system and combine the most recent data from Ethereum L1 to rebuild the state.
  • How do we reduce transaction fees for Rollups? There are a lot of trade-offs among security, decentralization, and cost efficiency. For example, we use ZKP for state validity to get enhanced security, but it requires more computing power and also makes the transaction more expensive. It is a trade-off between security and costs. Some ZK rollups use recursive proof to aggregate multiple transaction batches’ ZKP, and then submit the aggregated proof to the L1. It can save gas costs on Ethereum and reduce the L2 transaction fee, but it also delays the final confirmation of transactions.


Finally, let’s go back to our beginning question, What kind of Ethereum Rollups are we looking for?

  • At first, We want rollups to inherit not only the safety of Ethereum but also its liveness, decentralization, and censorship resistance.
  • Actually, it’s very difficult to create an L2 Rollup without introducing additional trust assumptions, because the upgradability, decentralized sequencer, and trusted setup for zero-knowledge proofs can all involve additional trust assumptions. You can’t say that L2 Rollup inherits ETH’s security completely without trusting any node of L2 Rollups.
  • To have better safety. The upgrade of L1 Rollup smart contracts should be governed by a DAO and have a delay to allow users to have enough time to exit if they disagree with the upgrade. However, this method also introduces the DAO’s security assumption into the system.
  • Last but not least, instead of using a single sequencer, do use decentralized sequencers to achieve better liveness, decentralization, and censorship resistance.