Vitalik: With different types of L2s emerging, how should applications and users choose?
TechFlow Selected TechFlow Selected
Vitalik: With different types of L2s emerging, how should applications and users choose?
For a given application, which of these complex trade-offs among Rollup, Validium, and other systems makes the most sense?
Navigating Web3 tides with focused insightsAuthor: Vitalik
Translation: TechFlow
The Ethereum Layer 2 ecosystem has rapidly expanded over the past year. The ZK-EVM Rollup ecosystem—traditionally featuring StarkNet, Arbitrum, Optimism, and Scroll—has advanced quickly, making significant progress in improving security; L2beat offers a good summary of each project's current status. Additionally, we have seen teams building sidechains begin to develop Rollups (Polygon), first-layer projects seeking to move toward Validium (Celo), and entirely new initiatives (Linea, Zeth, ...).
One inevitable consequence of this development is an increasing diversification among Layer 2 projects. I expect this trend to continue for several key reasons:
-
Some currently independent Layer-1 projects are seeking closer integration with the Ethereum ecosystem and may transition into becoming Layer 2s. These projects may prefer a gradual transition. An immediate full migration would reduce usability because the technology is not yet ready to support everything on Rollups. However, delaying the transition too long risks losing momentum and becoming irrelevant.
-
Some centralized projects aiming to provide greater security guarantees for their users are exploring blockchain-based approaches. In many cases, these projects might previously have considered “permissioned consortium chains.” Realistically, they may only require a degree of "semi-centralization." Moreover, they often have very high throughput, making them unsuitable—at least in the short term—for Rollups.
-
Non-financial applications such as games or social media want to decentralize but require only moderate levels of security. In the case of social media, this actually involves treating different parts of the application differently: rare, high-value activities like username registration and account recovery should occur on a Rollup, while frequent, low-value activities like posting and voting can tolerate lower security. If your posts disappear due to chain failure, that may be an acceptable cost. But if you lose your account due to chain failure, that would be a much more serious issue.
An important theme is that although users of existing Ethereum Layer 1 applications are willing in the short term to pay small yet noticeable Rollup fees, users from outside the blockchain world will not: paying $0.10 after previously paying $1.00 is easier to accept than starting to pay when previously there was no cost at all. This applies not only to today’s centralized applications but also to smaller Layer 1 blockchains, which typically maintain very low fees as long as their user base remains small.
A natural question arises: for a given application, which of these complex trade-offs between Rollups, Validium, and other systems makes the most sense?
Rollup vs Validium vs Disconnected Systems
The first dimension of the scalability-security trade-off we will explore can be described as follows: If you hold an asset issued on L1, deposit it into an L2, and then transfer it to you, what level of assurance do you have that you can withdraw that asset back to L1?
There is a similar question: What technological choices determine this level of assurance, and what are the trade-offs involved in those choices?
We can simply illustrate this using a chart:
It's worth noting that this is a simplified model, and many intermediate options exist. For example:
-
Between Rollup and Validium: A Validium could allow anyone to make on-chain payments to cover transaction fees, forcing operators to publish some data on-chain or else forfeit their deposit.
-
Between Plasma and Validium: A Plasma system provides Rollup-like security guarantees with off-chain data availability but supports only a limited number of applications. A system could offer full EVM compatibility and give users who don’t use more complex applications Plasma-level guarantees, while offering Validium-level guarantees to those who do.
These intermediate options can be viewed as sitting between Rollup and Validium. But what drives an application to choose a specific point on either end rather than somewhere further left or right? Two main factors influence this decision:
-
The cost of native data availability on Ethereum, which is gradually decreasing as technology improves. Ethereum's upcoming hard fork, Dencun, introduces EIP-4844 (also known as "proto-danksharding"), providing about 32 kB per second of on-chain data availability. Over the next few years, this is expected to scale up in phases, ultimately reaching around 1.3 MB per second with full danksharding. Meanwhile, improvements in data compression will enable us to do more with the same amount of data.
-
Application-specific needs: Will users suffer more from high fees, or from application failures? Financial applications stand to lose more from application failures; games and social media involve large volumes of relatively low-value user activity, so different security trade-offs make sense for them.
Roughly speaking, this trade-off looks like this:
Another type of partial guarantee worth mentioning is pre-confirmations. Pre-confirmations are messages signed by participants in a Rollup or Validium stating, “We confirm these transactions are included in this order and the resulting state root is this value.” These participants could sign a pre-confirmation inconsistent with reality, but doing so would result in their deposit being burned. This is very useful for low-value applications like consumer payments, whereas high-value operations like multi-million dollar financial transfers might wait for a “regular” confirmation backed by the system’s full security.
Pre-confirmations can be seen as another example of a hybrid system, similar to the earlier mentioned “Plasma/Validium hybrid,” but this time blending between a Rollup (or Validium) with full security but higher latency, and a system with lower security but lower latency. Applications needing lower latency get reduced security, yet can coexist in the same ecosystem as those willing to accept higher latency for maximum security.
Trustlessly Reading Ethereum
Another connection form, less discussed but still highly important, relates to a system’s ability to read the Ethereum blockchain. Specifically, this includes the capability to roll back when Ethereum rolls back. To understand why this is valuable, consider the following scenario:
Suppose, as shown, the Ethereum chain undergoes a rollback. This could be a temporary reorganization within an epoch before finality, or a prolonged reversion during a stalled period where too many validators are offline.
The worst-case outcome could be the following: Suppose data from the leftmost block of Ethereum is read into the top chain’s first block. For example, someone deposits 100 ETH from Ethereum to the top chain. Then, Ethereum rolls back. However, the top chain does not roll back. As a result, future blocks on the top chain correctly follow new blocks on the corrected Ethereum chain, but the consequences of the incorrect old link (the 100 ETH deposit) remain embedded in the top chain. This vulnerability could allow counterfeiting, turning bridged ETH on the top chain into a partially backed reserve.
There are two ways to solve this problem:
-
The top chain reads only finalized Ethereum blocks, so it never needs to roll back.
-
If Ethereum rolls back, the top chain should also roll back. Both methods prevent this issue. The former is easier to implement but could lead to extended downtime if Ethereum enters a stalled state. The latter is harder to implement but ensures optimal functionality at all times.
Note that method (1) has one special case: If a 51% attack on Ethereum creates two incompatible new blocks both appearing finalized, the top chain may lock onto the wrong block (i.e., the one not supported by Ethereum’s social consensus) and must roll back to switch to the correct one. One could argue that there’s no need to write code for this situation in advance—it could be handled via a hard fork of the top chain.
The ability of a chain to trustlessly read Ethereum matters for two reasons:
-
It reduces security issues involved in bridging tokens issued on Ethereum (or other L2s).
-
It enables account-abstraction wallets using shared key repositories to securely hold assets on that chain.
Both aspects are important, though it could be argued that this need is already widely recognized. The second aspect is particularly significant because it means you can have a wallet that allows easy key rotation and holding assets across many different chains.
Does Having a Bridge Make You a Validium?
Suppose the top chain starts as an independent chain, and someone deploys a bridge contract on Ethereum. The bridge contract simply accepts block headers from the top chain, verifies whether any submitted header comes with a valid certificate showing it has been accepted by the top chain’s consensus, and adds the header to a list. Applications can build on this to enable depositing and withdrawing tokens. Once such a bridge exists, does it provide any of the asset safety guarantees mentioned earlier?
So far, no—and for two reasons:
-
We verify that blocks are signed, but not that state transitions are correct. Therefore, if you deposit an asset issued on Ethereum into the top chain, and the top chain’s validators turn malicious, they could sign an invalid state transition that steals those assets.
-
The top chain still cannot read Ethereum. Thus, it’s impossible to deposit native Ethereum assets directly into the top chain without relying on some other (potentially insecure) third-party bridge.
Now, suppose we upgrade the bridge contract into a verifying bridge: it checks not just consensus, but also performs ZK-SNARK verification to ensure that the state of any new block is correctly computed.
Once this is done, the top chain’s validators cannot steal your funds. They could publish a block with unavailable data, preventing withdrawals, but they cannot steal (unless attempting to extort ransom from users by offering withdrawal-enabling data). This matches the security model of a Validium.
However, the second issue remains unresolved: the top chain still cannot read Ethereum.
To fix this, we need to do one of the following:
-
Place a bridge contract inside the top chain that verifies finalized Ethereum blocks.
-
Include the hash of recent Ethereum blocks in every top chain block and establish a fork choice rule to enforce this linkage. That is, a top chain block linked to a non-canonical Ethereum block is itself non-canonical, and if a top chain block was initially linked to a canonical Ethereum block that later becomes non-canonical, the top chain block must also become non-canonical.
Is this sufficient? It turns out, still not quite—due to some edge cases:
-
What happens if Ethereum suffers a 51% attack?
-
How to handle hard fork upgrades on Ethereum?
-
How to handle hard fork upgrades on your own chain?
A 51% attack on Ethereum would produce consequences similar to—but opposite of—a 51% attack on the top chain. An Ethereum hard fork might render the Ethereum bridge inside the top chain invalid. The clearest way to address this is to establish a social commitment: if Ethereum reorganizes a finalized block or undergoes a hard fork, the top chain will roll back. This commitment likely would never need to be executed in practice: if governance gadgets on the top chain detect signs of an attack or hard fork, they could activate, resorting to a hard fork only if governance fails.
For question (3), the only viable answer, unfortunately, is having a form of governance gadget on Ethereum that allows the bridge contract to recognize hard fork upgrades of the top chain.
Summary: A bidirectional verified bridge is almost sufficient to make a chain a Validium. The main remaining element is a social commitment that if exceptional events occur on Ethereum rendering the bridge invalid, the other chain will respond with a hard fork.
Conclusion
“Connection to Ethereum” has two key dimensions:
-
Security of withdrawals to Ethereum;
-
Security of reading Ethereum.
Both are important and involve different considerations:
Note that each of these two dimensions has two distinct measurement aspects (so effectively four dimensions): Withdrawal security can be measured by (i) the security level and (ii) how many users or use cases benefit from the highest security level. Reading security can be assessed by (i) how quickly the chain can read Ethereum blocks—especially finalized versus any block—and (ii) the strength of the chain’s social commitment in handling edge cases like 51% attacks and hard forks.
Many regions in this design space host valuable projects. For certain applications, high security and tight coupling are crucial. For others, more flexible solutions may be acceptable to achieve greater scalability. In many cases, starting today with a more flexible solution and transitioning over the next decade toward tighter coupling as technology improves is likely the best path forward.
Recommended reading: ETH HK Live Notes: What Did Vitalik Say About Ethereum’s Challenges and Future? - TechFlow
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
