An Incomplete Guide to Ethereum Rollups
vitalik.caAs someone who's active in the Blockchain space since 2015, I found rollups to be a really cool invention. The idea of simply compressing data with a zero knowledge proof is quite simple and beautiful.
A year ago, I've worked at a company that tried making Plasma work (https://leapdao.org). We even had shipped a Plasma chain to the mainnet. As Vitalic points out correctly, a major problem (apart from not having guaranteed data availability for the Plasma's chain data) was that in order to transact "off-chain", a user had to transfer some money into a bridge. Only then, the Plasma chain credited this money to the user.
That was a major usability problem, as it took a really long time and since the user was then anyways subjected to really high transaction costs at least once. Hence, we had really low liquidity and the project never took off.
With rollups, I imagine this could become less of a burden as there's no double accounting. The single source of truth is the smart contract checking the "batches". I can imagine having a contract interface that's the equivalent of "depositing into a rollup and immediately send it to person X". I could even imagine an ERC-20 V2 standard that makes any token a rollup. Then you simply never leave L2, meaning the "on-boarding problem" would be solved.
I'm not a cryptographic expert, but to me zkp are still somewhat scary and opaque. They're really hard core concepts that still seem to be in development and have not proven themselves. As an engineer with 5 yrs of experience in the field of blockchain, I'd still be really hesitant to build something with zkps without having a sort of cryptography consultant by my side.
Optimistic rollups seem to be a better fit here. Still, I have the feeling that much of this can still be significantly simplified once a well-matching use case comes into sight. But that's just a feeling for now...
The Hermez Network (zk-rollup L2) will launch a little later this year:
How does this compare to something like arbitrum which I think is also L2 rollups but could be wrong.
Arbitrum seems to be based on optimistic rollups. See the Optimistic rollups vs ZK rollups section in Vitalik's write-up.
Will do thanks
I continue to be in awe of people like Vitalik and all of the other protocol developers who can understand all the different pieces (math, social incentives, engineering) to make blockchain technologies work. Great writeup, I really appreciated the tradeoffs tables in particular.
If you're interested in other uses of zk-SNARK, Celo (an Ethereum fork) is making it possible to run an "ultralight" node on your phone -- not mainnet yet I don't think but some details here https://docs.celo.org/celo-codebase/protocol/plumo and whitepaper here https://docs.zkproof.org/pages/standards/accepted-workshop3/...
Great write-up, concise and very clear. I just started learning dapp development and was able to easily grasp the different forms of L2-scaling.
I am especially excited about recursive ZK-Rollup smart contracts even though they are complex and computationally expensive. They seem to be more trustworthy than Optimistic Rollups and I can see them becoming the standard eventually.
It is great to follow this dapp tech at its frontier, so much potential and new breakthroughs every few months it seems!
I just read through the whole thing and have no idea what it says. It sounds smart but it’s pseudo-science to me.
You can run that pseudoscience yourself with Zokrates. They have really good documentation, which makes it a lot more concrete. I didn't get zksnarks at all but that cleared it up for me.
The basic idea is that you have functions with both public and private parameters. You can do two things:
1) Pass in all parameters, get back the output and a proof that the output is correct.
2) Pass in just the proof, the output, and the public parameters, and get verification that the function ran correctly; i.e. that the public parameters and some private parameters you don't know generated that output.
So on chain, you can skip storing all the private parameters, as long as you store the proof, and have a contract verify the proof before storing the public data.
Not sure about pseudo-science, but I have found blockchain writings to be on the abstract side. Try this interpretation:
The Ethereum blockchain hosts serious money. However it has poor cost and performance characteristics for many potential use cases. One approach to work around those is to move money temporarily from Ethereum to another blockchain (let's call that the secondary chain) that's cheaper/faster; shuffle it around there as much as you want; cash in the money back on Ethereum when you're done shuffling it. "Rollups" are a way to pull off that trick (there are other ways). Rollup means (to me at least) that you arrange to publish a kind of checkpoint of the secondary chain state at some point in time, to Ethereum. This checkpoint operation is relatively cheap to do because it's just a "put" of some small number of bytes. Where this comes in handy is when someone asks to withdraw their money from the secondary chain to Ethereum. If they were able to just say "give me my money", there would be the potential to steal funds. There has to be a way to know that a) they owned that money on the secondary chain and b) they didn't spend it already. This is achieved by making the withdrawal request of the form "give me my money because ... this rollup says I legit have that money". Absent the rollup, or some equivalent scheme the Ethereum contract deciding whether or not to give them their money would need to look at the entire history of the relevant transactions from the secondary chain. That's hard-to-impossible. Then, having invented the rollup concept there are two subspecies of ways to tell if the withdrawal request is valid or fake : 1) by holding off on giving the money for a while during which anyone who is interested can call foul on the validity (and get a reward for doing so) or 2) by means of ZK-proofs, which are a real thing but may be impractical to use for various reasons so it's always a good idea to ask for running code whenever anyone invokes them.
This paper has some useful background for the problem space: https://arxiv.org/pdf/1904.06441.pdf
One difference between rollups and sidechains is that with rollups the essential data is stored on the main chain, in compressed form.
Fwiw I disagree that the "data availability" concern is real. My take is that anyone with an interest in having some data will go ahead and store that data. If data integrity needs to be preserved under consensus then publish a hash to a blockchain. Possibly we're actually agreeing on this in your use of "essential"?
By "essential" I mean all the data required to recover complete state.
Holding the data you need yourself might work ok for your own personal ETH balance, assuming you have some way to prove the absence of any outgoing transfers. In fact, that's how one variant of Plasma works.
But with smart contracts, it gets a lot more complicated. It's way simpler if you can just know that any data you need will be on the network.
> it’s pseudo-science to me
Maybe do some background reading?
For example: https://arxiv.org/abs/1906.07221
Thanks for dropping that link. The info is very accessible.
Why not use a sidechain instead? They can compress transactions at least as effective, and have more simple security properties.
The main drawback with sidechains are that they are hard to run decentralized in any credible sense. Basically just as hard as the blockchain in the first layer sense. They seem to be identical in this regard.
Sidechains have different security properties. You probably know xdai (https://www.xdaichain.com/), where you can transact tokens that "wrap" dais from Ethereum mainnet. The sidechain is secured by a proof of authority consensus, where you require a fraction of validators to behave honestly. If a certain number of validators collude, they can do nasty things, such as censoring transactions from a certain address, or keeping the chain from making progress. This is not possible in a rollup, either optimistic or zk, because any single user can always commit a batch or report fraud on L1, so you just need a single honest actor for things to work.
As HN user timdaub stated earlier in the thread,
> in order to transact "off-chain", a user had to transfer some money into a bridge
I believe that this is the main problem with side chains.
To me this is a side chain approach, but it depends on your definition of side chain.
That is my understanding as well. At least the "optimistic" version as described seems like a standard sidechain.
The important part, who gets to publish this chain and if and how that can operate in a trustless manner, is not described here. That makes the ZK proof seem misplaced. If it is operated by a trusted third party, why bother?
Fruit Rollups?
Not as delicious, but sure to be just as sticky