@vbuterin can you expand on the benefits of the ETH burn and next-block inclusion for rollups? Is the latter a UX-nice-to-have or is there something more there? Thanks!
1 Like
One thing I am curious about is the inevitable state growth of the L2s and its impact on users, whether dapp developers, sysadmins, auditors, and other users interested in the txn history. We often think of a user as an operator, but we need to put more focus on the “back office”.
Does anyone have any comments for this issue specifically? Perhaps it requires an entirely new thread? @tjayrush
These various kinds of L2s – ORUs, ZK Rollups, Plasmas, even state channels – can coordinate on standards for archive nodes, querying, exporting, etc. This problem domain is already very challenging for mainnet.
IMO when users can’t easily run a full archive node themselves it invites centralization and surveillance of the users of data, and even this unideal situation is stabilized by the constraints of Eth1. Imagine what happens when L2s with composability leads to 10X or 100X more data per day.
4 Likes
@timbeiko next-block inclusion is important for rollups because they rely on data being posted to the main-chain for finality and to progress the rollup side chain. Therefore it’s important that rollup aggregators can reliably post their transactions in the next block and not be stuck with a pending transaction as that would essentially delay the entire rollup chain from updating its state.
3 Likes
Maybe phase 1.5 could consider more trustless mempool service with quadratic demand modeling. This would better align the interest of client networks vs whales by orchestrating throughput less influenced by MEV, now more desireable for L1.
Miner fee-based compensation is similar to the square area of a funding pool, and the quadratic funding mechanism might be useful to better coordinate mempool service. The first step however is challenging since the concept of “one vote”, which in this case is a request for network service, requires some attention.
To address that, the value of transaction fees can be denominated in terms of a fair average (updated periodically) to form a basis for proportional mempool service according to the square root of that value.
For example, if an average transaction fee is deemed $2 for some window of time, a $2 fee is represented with a weight of 1 ($2 divided by $2). If there is a $100 fee opportunity pending, it would scale to 50 ($100 divided by $2). Then the square root of the weights would reveal how resources can serve the pool proportionally. The square root of 50 (the $100 opportunity) is about 7 with respect to fees in the $2 range with weights and roots near 1, so proportionally seven $2 transactions would be processed for each $100 transaction.
1 Like
I have been called a rollup shiller before, but I am bearish on this roll-up-centric roadmap and in favor of keeping the original plan of general-compute shards (ETH2 Phase 2), for a couple of reasons:
(1) validity proof of general computation are already here, see Cairo, Zinc and Noir by StarkWare, Matter Labs and Azteck respectively. So, it is not inconceivable that the runtime of shards in Phase 2 are provable in zk. Yes rollbacks of ORUs are localized to the offending contracts and not the network as a whole, but ORUs are a short-term solution anyway and may not even be universally viable because of capital efficiency vs security problem. So there seems to be a pre-mature optimization here.
(2) by reducing itself to merely data-availability and proof-enforcing layer, Ethereum risks losing its hard-earned network effects. These effects “grow” out of webs of interdependencies between L1 contracts … and by removing general compute, those webs start growing as inter-L2 dependencies. But then, rollup #1 having can keep its dependency on rollup #2 without necessarily being dependent on L1 for security. It just runs a light-client for ETH2.0 and outsource its own security to some other chain. This is different from when L2 rely heavily on logic on L1 to function. We should push to thicken the amount of logic on L1, not reduce it.
(3) if Ethereum takes over the world, there are many use cases that require nation-state-grade and enterprise-grade security and availability and may not tolerate the possibility of some withdraw delay due to an uncooperative ZKRU chain or a detected fraud in an ORU. Example: end-of-day inter-bank settlement logic … these people are gonna want to do this directly on L1.
(4) Having a proof-powered state- and data-shared ETH2.0 should improve scalability massively because the beacon chain is verifying proofs of proofs (whether fraud of validity) … so I don’t see why the scalability goes down (?). Unless Im missing something here.
TLDR: Rollback risks are not existential. Validity proofs of general compute are here and prover markets and ASICs will pop-up if necessary. Ethereum network effects are at risk if shards are not general-compute.
If we can make EVM execution zk-provable, and the ethereum ecosystem ends up preferring one particular zk-provable system, I’d be totally fine with considering enshrining it as the core execution model at some point [EDIT: see caveats below]. Though I would still favor delaying any such “phase 2” until such zk-proofing is actually possible.
The good news is that the rollup-centric roadmap doesn’t remove our ability to take this path; it’s much easier to add new functionalities to the ethereum base environment in the future than to take them away.
I would argue the opposite is easier: generalize by cleanly decoupling state transition from consensus, both at the shard and beacon chain, and then swap the state transition function with a zk-provable one when ready.
So plan for generality, settle for specificity if need be.
IIUC in the rollup-centric world the beacon chain will be hardcoded to enforce proofs of a data-avaiability-purpose-built VM. While in the generalized case the state function is itself an argument to the beacon chain so it can be swapped out anytime … hence the need for the plumbing of generality to be built out from the get go.
IIUC in the rollup-centric world the beacon chain will be hardcoded to enforce proofs of a data-avaiability-purpose-built VM
How so? The beacon chain would just be exactly the same EVM as it is today. So it could execute fraud proofs (or validity proofs) of any type of rollup that can be implemented in a contract.
I have another objection to the rollup world which comes from our stateless roadmap. This is because rollups typically come without witnesses; while a rollup with witnesses is possible, it will probably not be implemented because from the point of view of the rollup and implementers, witnesses will feel like pure overhead with no benefit, so why add them?
As long as rollup sequencers and validators stay separate, that is probably fine. However, in the long run, this system will feel very inefficient: We want to use the massive capital invested in layer 1 to also secure layer 2. In fact, as I have argued before, I think pure rollups offer terrible UX, and this can only be fixed by adding stake capital to secure rollup states (insuring users against fraud proofs). If we want validators to do this, it will mean that validators will have to accept maintainting the rollup state in addition to their duties. Of course, this will be “optional” – but since it brings in additional returns, it will mean all validators not doing it will essentially be priced out (because they won’t have their costs covered from the now lower returns on “pure” staking).
TL;DR: Rollups will force stateful shards on uss through the backdoor. I think this is bad.
3 Likes
Which of the following worlds do you think is long-term best?
- Proposers select which shard they are on and specialize in that shard (in this case it’s okay if the proposers need to be stateful as long as there are zkps for the rest of the network, which it seems like we are assuming we will have)
- Proposers are forced to rotate between shards, but they get block contents from a third class of actor (relayers?) that is stateful
- Proposers are forced to rotate between shards, proposers are stateless, and it’s users who need to be stateful
I feel like a zkrollup is totally forward-compatible with any of these three strategies, no?
1 Like
A zkrollup does indeed solve my concerns. But I am far from convinced that general computation zk rollups are coming as fast as people wish.
I believe currently GP computation CIP (Computational Integrity Proofs) are about 10^9-10^12 times slower than actually doing the computation. So I believe that for the foreseeable future it will be much more efficient to send a committee of 1000 to check the correctness of a computation, vs. building a super powerful sequencer that proves correctness to everyone. This will change if that factor comes down a lot (I would doubt it will ever be less than 10^6, much less 10^3), or the cost itself being negligible (such that other costs like latency (for the user) and bandwidth dominate).
I think GP zkrollups for a realistic EVM alternative are further out than some people think.
3 Likes
How about the implication of rollup to composability? Looks like there is a few discussion, and to me, it seems that the composability between rollups is even more difficult than that between sharding.
1 Like
Gas fees can be reduced easily by January.
Change Ethash algo, take ASICs off the network and GPU miners will agree to ETH issuance reduction equal to increase in rewards after 30 days stability in hash.
1 Like
But I am far from convinced that general computation zk rollups are coming as fast as people wish.
If general-purpose ZK rollups are still far away, then that nullifies reason 1 that originally contributed to kicking off this part of the discussion:
(1) validity proof of general computation are already here, see Cairo, Zinc and Noir by StarkWare, Matter Labs and Azteck respectively. So, it is not inconceivable that the runtime of shards in Phase 2 are provable in zk.
If we can’t have ZK rollups for general computation, then that does mean that the optimistic and ZK families will both have durable value for quite some time, implying that there is not a single architecture that’s optimal for all cases, so giving users choice between the rich-but-optimistic environment and the limited-but-instantly-zk-proven environment (by having both kinds of rollups) is the best thing we can do…
1 Like
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…
What would be a fair behavior of a protocol that wins a lot of popularity on Ethereum?
2 Likes
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.
6 Likes
@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.
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 of finality 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
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!)*