A rollup-centric ethereum roadmap

,
41

You mentioned in the ETH Online talk that such enshrining would only be necessary if the winning rollup abuses its position and behaves in unfair way towards the community. I totally understand this motivation (and agree with it), but it’s very important to draw the red line very clearly when such things are mentioned. Because, obviously, a “nationalization” like this would be quite a harsh move. Alone a threat of it could undermine the idea that Ethereum is a nation where property rights are respected. Imagine, for example, that Uniswap decides to introduces fees, and since it’s a protocol with “systemic importance”, community deems UNI as “too extractive” and nationalizes it…

Agree there’s a lot of things to be careful about here, and thank you for bringing this up explicitly. It’s better to discuss such things earlier rather than later, when tens of millions of dollars will have been invested.

I’ll walk back on being “totally fine with enshrining it”; I was too quick to make that statement without thinking through the whole picture and not just the narrow technical considerations.

First of all, to be super clear I would definitely oppose “state-intervention forks” (ie. DAO-style forks) that just grab the state root of a rollup and import it into another system, stripping the token out in the process. A state-intervention fork is the only way to truly cleanly move everyone over from an L2 to an L1 “by default”, so it seems to be off the table by existing norms.

That said, there are other things that in theory could be done. One possibility is the ethereum protocol forking existing code to create a native execution capability, and inviting users to voluntarily move into that system. This would not be a violation of immutability or property rights, but it would be a gross violation of open-source politeness norms. And if the ethereum community commits not to do such a direct fork except in case of some kind of malicious exploitation of monopoly power, that could significantly boost L2 projects’ confidence in building on the ecosystem. I am inclined to also support such a commitment.

The truly tough thing though is dealing with all of the less clear possibilities. At the very least, if ethereum makes a native sharded execution capability, that would compete with all the L2s that have been made until that point, and it would have an unfair advantage. And the concept of doing that versus forking an existing protocol is not a binary, it is a spectrum. For example, if ethereum makes a native L2 execution capability using SNARKs or STARKs, that will doubtlessly use at least some open-source research and software packages that were originally built at least in part with L2s in mind.

There’s a limit to how strong a commitment we can make, because there’s also the possibility that we learn something new in 2-4 years that makes an ethereum-native sharded execution layer a really good idea and crucial to the ongoing success of the project. If we extend from 1 execution shard to 8 execution shards, where the new three execution shards have some different non-EVM language that’s designed to be ZK-provable, but where the goal is not to compete with ZK rollups, is that a problem? I think the best we can promise is to be fair to existing L2 projects and not do things that intuitively feel like pulling the rug out from under them.

A final possibility is some kind of “coin merger” with L2 projects (with their teams and token holders’ consent), but this risks being too controversial because it interferes with the goal of ETH monetary neutrality.

5 Likes
42

@vbuterin could you elaborate further why there is this reduction in TPS?


I think there is broad consensus on this. What is being questioned is why having 64 shards is better or worse long-term. What I argue is that rollups committing to 64 shards >= rollups committing to 1-4 data-availability-first shards for reasons mentioned above. I use “>=” to signify that in the worst case where general-compute shards were built but not used, the goals of the rollup-centric path are still fully realized, while the inverse is not true … if it turned out that we need build general-compute shards (say, centralization concerns or rogue rollups), then the costs will be much higher. We see this with technical debt in Eth1.x.

43

Once phase 1 comes along and rollups move to eth2 sharded chains for their data storage, we go up to a theoretical max of ~100000 TPS.

Is there any detailed document on how to use Phase 1 for Rollup? Since Eth2 Phase 1 does not have “transactions” as in Eth2, I’m assuming that:

  • a Rollup operator must run Eth2 validator(s), and
  • either one of the Rollup operator’s validators must be elected as a shard block proposer and create a shard block by themselves to put the Rollup transactions on Eth2 shards.

I have some questions about this.

First, the Rollup operator needs to run many validators (i.e., stake a lot) to reduce the latency offinality in the Rollup? In the worst case, if the Rollup operator runs only one validator, and the shard committee size is 2048 (maximum in the spec), the operator has an opportunity to commit Rollup transactions once in 2048 slots (~ 6.8 hours) in expectation.

Second, if most of the Eth2 validators are not Rollup operators, we cannot make full use of the data capacity of Eth2? Since running Eth2 validator and Rollup operator are different things in terms of responsibilities and economics, I assume most of (or at least some portion of) Eth2 validators are not interested in Rollups.

Or, is there any plan to introduce (in-protocol or off-chain) “transactions” for users other than validators to put data on Eth2 shards?

1 Like
44

Or, is there any plan to introduce (in-protocol or off-chain) “transactions” for users other than validators to put data on Eth2 shards?

There is a plan to support the fee market for users to request Eth2 validators to put their data in Phase 1. Therefore, the above concern might not be a problem. (Thanks @djrtwo!)*

45

@vbuterin could you elaborate further why there is this reduction in TPS?

A shard as defined today needs to have its TPS capped at ~10-50 just to ensure that state sizes remain reasonable, a node can verify incoming blocks and maintain an up-to-date state, etc.

If we have a ZK-proven VM at the base layer, then potentially we could have much higher TPS.

1 Like
46

@vbuterin is there any effort to ensure the integration of L2 in a form of rollups requires minimum changes in client applications that are currently only using ETH JSON RPC standard to send transactions or read blockchain state and web3 to generate signatures?

That can be a huge problem to tell every client that they would need to adapt a new data format when they read from L2.

1 Like
47

This is very important. Most ppl are used to having a bank to guide them and take responsibility for security issues, including social engineering ones. And, when they are scammed, banks go and revert the transaction or at least refund them.

It’s very hard for many ppl to be responsible for everything they do. They have trouble to understand in example the difference of a simple transfer to a token swap.

Many wallets and online reports are hard to view tokens balances. Ppl mix up the wallet not discovering a token and just not showing its balance with actual 0 balance.

I can imagine how hard it will be to figure the difference between the balance on L1 and on each L2 instance.

But my biggest concern with L2 is if we’re able to choose to make a tx on L1 or L2 or if we’re forced to use L2. If we need to pay fee to deposit and then another to withdraw, L2 is a no-go for long term investors who just wanna buy/deposit/loan a token and hold it for some years.

To do that on L1, it’s required only 1 tx. If L2 requires 2 L1 tx (deposit then withdraw), then we’re paying double gas.

1 Like
48

Hey all,

We are going to host Ethereum L2 Future virtual event sessions starting tomorrow Friday 13th at 3pm UTC :sparkles:

RSVP to the first one starting tomorrow.

More info regarding the event sessions: L2 Future Session 1: "Starting with L2s" - Intro, review of solutions, mapping out needs

49

I think this will be a little bit hard in an async network.

50

I actually have some concerns.

Data across rollups are somehow isolated and won’t be accessible on chain until users exit (and users exits are intuitively infrequent). This usually won’t be a big issue in terms of normal transfers or smart contracts making use of L2 (for example, https://zksync.curve.fi/).

However, this may lead to

  1. inconvenience to make use of prtocols compositability and build DeFi lego.
  2. less instant verifiability of oracles if some data source from rollups.
  3. semi-centralized rollup-based DEXs – liquidity tends to gather together.
53

hey Vbuterin this post and the whole other section is a gold mine, event though im a beginner…
I can sense the wisdom in those words… Thank You … I’ll come back later after i’ve upgraded my knowledge on Ethereum Blockchain.

3 Likes
55

Please offer feedback!!

56

How would the implication of roll up to composability, between roll up sharding would be a difficult

57

Are “L1 rollups” possible without L2s by sort of virtually doing TXs on L1, and proving them with ZKR on L1, and storing all that on L1 shards, or something to reduce gas on L1?

There are benefits to staying in L1 by increasing TPS & reducing L1 fees like

  1. TVL all in 1 place, less spread out.

The spread out problem is perhaps mitigated by seamless direct cross L2 as OP mentions for future

  1. Get funds out of complex, very-high-gas contracts ($1000+ gas)

If such “L1 rollups” were possible, would they compete with L2’s for shard capacity? L1 would seem to win

What TPS can L1 have before a phase 2, with its up to 64, but likely closer to 8, execution shards?

With phase 2, will the TPS be multiplied by the number of execution shards? Or how does it reach 1-5k?

Thanks! Great post!

2 Likes
58

Reading this ins 2022 on the following days of Matterlabs announcing the zkEVM testnet is ready. Looking forward to building and living in this rollup-centric world.

59

Yes :raised_hands: is coming up to you guys at work tomorrow

1 Like
60

What’s HLL exactly?

61

High Level Language, e.g. Solidity, Vyper :smile:

1 Like