An Incomplete Guide to Ethereum Rollups(vitalik.ca) |
An Incomplete Guide to Ethereum Rollups(vitalik.ca) |
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...
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/...
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!
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.
> 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.
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?
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.
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
Maybe do some background reading?
For example: https://arxiv.org/abs/1906.07221
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.