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:
There develops an attractive fraud proof market that pushes the OR narrative to a wider audience
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
DAOs that submit and resolve fraud proofs
Service providers that facilitate instant settlement to L1 for a fee (for taking on fraud risk)
Narrative that ZK proof construction requires special knowledge and/or relies on not so decentralized proof construction infrastructure
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.
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
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.
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.
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.
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).
There are schemes where the recipient does not need to transact immediately (cutting the data cost again by half).
@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.
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.
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.
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
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.
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.
@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!
