A rollup-centric ethereum roadmap

I wonder if in the future when ZKRs support general purpose computation, ORs (although less ‘elegant’) will still be the more popular variety. For these reasons:

  1. There develops an attractive fraud proof market that pushes the OR narrative to a wider audience
  2. Trusted service providers in the vein of Infura/Metamask emerge that provide a watcher service to automatically submit fraud proofs and an automated resolution service
  3. DAOs that submit and resolve fraud proofs
  4. Service providers that facilitate instant settlement to L1 for a fee (for taking on fraud risk)
  5. Narrative that ZK proof construction requires special knowledge and/or relies on not so decentralized proof construction infrastructure
2 Likes

I guess RU centric contract design might be needed especially for minting including contract - all contracts have to have their “primary” contract in the L1 and secondary (=scalable) contract on the RU.

Eg, ERC-20 on the L1 and RU will have each own token issuance limit and those would run parallelly. How can those contract keep consistency when a mint function fired on RU?

My hottake is RU-specific ERC-20 (eg, ruDAI) tokens and enabling 1:1 conversion with general ERC-20. Anyway, some investigation of secure RU contract design would be needed.

1 Like

Once ZKRs support full migration from Solidity, it’s game over. No single advantage left to ORs:

  1. ZKRs have short finality/exit times (minutes vs. days in ORs).
  2. ZKRs are cheaper (addresses, signatures and intermediate state hashes can be omitted).
  3. ZKRs are A LOT more secure with large value locked in them.
  4. ZKRs support low-cost privacy (at least 100x more expensive in ORs).

ZKP generation can be much better decentralized due to its self-verifying nature than OR aggregation.

Fraud proof markets are a solution to the problem, they cannot drive adoption once the problem is not relevant anymore. It’s like saying that people won’t stream movies over the Internet because the video rental shops will push against it :wink:

3 Likes

I am bullish on ZKRs too but want to see if I can make a case for OR’s relevance once ZKRs for general computation is a reality

We (the Solidity team) had a discussion with the Optimisim team a few months ago, when they still had their Javascript/Typescript based transcompiler (which tried to identify functions based on the Solidity EVM output). We agreed that using Yul is a better direction, and our estimate for “feature completeness” of the Solidity to Yul step (“Yul IR”) was the end of this year. The compiler progressed pretty well and a lot of well known contracts can be compiled to Yul now (such as Uniswap, Gnosis Safe, etc.)

I did not know there was a deadline for launch though, and obviously the Yul IR work is planned to take longer.


Besides that, we were lately talking about this exact topic you raise, to consider the requirements of layer 2 systems when designing the Solidity language. We are in the process of discussing a standard library and some ideas regarding dialects, which would definitely be helpful.

When the gas prices were close to 1000 gwei and given how Eth1x/Eth2 is progressing, I was rather worried that contracts become more like “system contracts” and every “user contract” moves to layer 2 – which means a shrinking user base for Solidity if we don’t support layer 2 systems.

4 Likes

Very interesting trade-offs!

I have made a claim about this proposal on The Ether, which allows for signalling of if you are for the more roll-up centric road-map or against the more roll-up centric roadmap.

Additionally, it will allow you to see the top arguments on the for and against side.

I did my best to summarize the core points of @vbuterin and @souptacular discussion so far, but feel free to write your own arguments that are better than mine in order to flesh out the trade-offs

How could you reach 100x advantage vs optimistic rollup?

For optimistic zk rollup we need to publish 2 nullifiers and 2 new utxos per transaction and one proof (2 compressed g1 and one g2 point).

This is 20*2+20*2+4*32=208 bytes per tx, published onchain.

Also, to keep the rollup working we should publish anywhere encrypted messages from users. A simple note is (amount, owner, salt), we should publish at least one note and ephemeral public key per tx. So, it is about 100 bytes and this cost should be the same for both zk and optimistic constructions.

1 Like

I would like to throw EIP-726 in the mix of protocol changes that would really help facilitate ORUs :slight_smile:

2 Likes

You are a product of your own inability to take action against ASICs for almost 3 years now. They have increased network security costs so high that none of the GPU community was healthy enough to voluntarily take a cut in fees due to them finally getting to break even.

Very simple, remove ASICs from the network and you will have a very robust GPU mining community that has the ability to trim it’s belts in times of need to bolster the community.

Remove ASICs and bring back solid GPU mining to Ethereum and you would be suprised what we will do in return as some of the largest HODLrs.

1 Like

A zk zk rollup can go down to just publishing the nullifiers and utxos, and you can get the nullifiers down to 10 bytes as you don’t need collision resistance, so that’s 60 bytes (assuming an 80 bit security margin as you appear to be).

2 Likes

Besides:

  1. There are schemes where the recipient does not need to transact immediately (cutting the data cost again by half).
  2. @snjax, you are talking about Groth16 with an app-specific trusted setup, which is hard to consider a viable, practical and trustworthy solution in 2020. You need a universal PLONK at the very least, but eventually you want to move to fully transparent proof systems (STARKs, RedShift, Halo). In either scenario the compressed proof size is on the order of kilobytes—and must be posted on-chain by optimistic rollups.

Of course, you could aggregate the proofs for many transactions in the block without checking them on-chain, but this construction would not be an optimistic rollup—it would be a ZK rollup with optimistic verification: combining the worst of both worlds.

1 Like

You compare optimistic rollup with proving system, developed for zk rollup (in proving single transactions case) with zk zk rollups.

As you mentioned, the proof size will be some kilobytes. When for groth16 in optimistic rollup it’s 128 bytes per tx.

1 Like

Ok. Optimistic rollup is ~5x worse with Groth16, ~100x worse with anything without an app-specific trusted setup. We’ll let the reader make conclusions.

1 Like

Btw, is there any community approved methods to store off-chain data for private transactions (like encrypted utxo)? If both user and data storage forget the data, assets will be stuck. Also, if data storage forgets the data and the user could not send it directly to the receiver, assets will be stuck too.

1 Like

Wait, why 100x worse? PLONK proofs are only around 500 bytes, no?

1 Like

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

3 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.

6 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