PLONK proofs are over 1kB compressed. But bulletproofs, STARKs, RedShift are a lot more. Thus order of hundreds.
1 Like
Halo 2 applied to multiple proofs that are made together, even without use of recursion, will have a marginal proof size on the order of 100-300 bytes (preliminary estimate): https://www.youtube.com/watch?v=pCSjN9__mtc&t=2100
2 Likes
This is really cool!
But my understanding is that verifying it in a single fraud proof is infeasible on Ethereum, even if arithmetic pre-compiles for EC cycles were available (which they aren’t). Am I wrong?
Even if we assume it would somehow magically be feasible, Halo transactions in ORs would still be at least (200*2+60)/40 ~ 10x more expensive than in ZKRs.
1 Like
If verification of a proof takes >10m gas, you can always use truebit-style multi-round techniques to verify it, I suppose. Though intuitively I dislike multi-round techniques because they mean that an attacker willing to get slashed can stall for time (during which only full nodes can ignore the attack, light nodes can’t), whereas in a single-round fraud proof system attacks can be caught and reverted immediately.
7 Likes
@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