ZK-Rollups on Bitcoin
Way More Scalable than on Ethereum
ZK-Rollup is considered as the holy grail of Ethereum Layer 2 scaling solution.
In general, my own view is that in the short term, optimistic rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves. — Vitalik
We have implemented the first ever ZK-Rollup (ZKR) directly on Bitcoin. Furthermore, we show why ZKR works better on Bitcoin than on Ethereum.
How ZKR Works in Ethereum
At its core, ZKR leverages the succintness of of a ZK-SNARK proof: it is much more efficient to verify some computation is done correctly than re-executing it. Instead of processing every transaction on chain, multiple transactions of a contract are sent to a coordinator (aka, sequencer/relayer) first, instead of miners. The coordinator “rolls”/bundles them up into a single transaction. The transaction contains a succinct proof that all these batched transaction are processed faithfully, changing the contract from state1 to state2, and is sent to the miners.
Since all the heavy lifting of transaction processing is outsourced off chain, the blockchain can process more transactions in a given interval and thus scale. The zkSNARK proof ensures the correctness of the off-chain state transition, making it impossible for the coordinators to commit an invalid state transition. This makes ZKR an appealing L2 scalability solution, since it allows scaling without sacrificing the security of L1, unlike many other L2 solutions such as Plasma and Optimistic Rollup.
We use tokens as an example to demonstrate how to use ZKR.
There is a Rollup contract on the main chain, keeping track of a state root. The “state root” is root of a Merkle tree. Each leaf of the tree is an account consisting of its owner’s public key or address and its properties, such as balance.
In the following example, two deposits are batched into a single transaction.
ZKR on Bitcoin
We have implemented the rollup contract on Bitcoin. It ensures that the current state root is updated to a correct new root after the batch of transactions are processed.
The only state it tracks is the root of the account tree in Line 8. Validity proof is verified at Line 14, using our previous zk-SNARK library. Root is updated at Line 17. The verifying key at Line 5 comes from setup phase of zk-SNARK.
Generate ZKR Proofs
We need to encode our transaction processing logic in a zk-SNARK friendly way. One popular language is Circom. Due to space limitation, we do not cover Circom syntax here and instead refer readers to the official circom site to learn more about it.
Processing a single transaction involves:
- Check the sender account is in the tree by merkle proof
- Verify sender’s signature
- Update the balance of the sender and verify the intermediate merkle root
- Update the balance of the receiver
- Update the merkle root
We can reuse existing rollup Circom code such as this.
Here is a detailed explanation of the above code.
The benefit of rollup only shows up when multiple transactions are batch processed together. We can simply add a loop on top of the code above. The generated proof is only valid if all transactions in the batch are valid.
ZKR stores transaction data on chain at Layer 1 (L1) for data availability. The underlying L1’s storage cost places a ceiling on ZKR’s scalability gain. Consequently, ZKR works much better on Bitcoin than on Ethereum, since the cost of storage of former is orders of magnitude cheaper than that of the latter.
In addition, since zk-SNARK is universal, once the rollup smart contract is deployed on Bitcoin, many existing ZKR toolings designed on other blockchains (such as Circom and ZoKrates) can be reused directly in Bitcoin. That means ZKR can be used to scale applications on Bitcoin today.