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