The problem
Zero-Knowledge rollups (ZKR) are finding great success in the greater blockchain ecosystem. In fact, even within the IC ecosystem, ZK-proofs have been used successfully in SpinnerCash to allow for more private BTC transactions. ZKR leverages another aspect of SNARK proofs: their succinctness. Mathematically, it is much easier to verify a computation than to redo it. This allows us to ‘outsource’ computation off-chain and only submit batch transactions to the ‘target’ chain.
ZKR allows for increased throughput on blockchains where finalization takes a significant amount of time. Currently on the IC, tECDSA can be used for signing transactions on other blockchain, but there is a limit of 1 txn/second per subnet. This greatly limits the use cases for cross-chain DeFi, NFT, and other inter-chain operations, which may require hundreds of transactions per second.
In the literature, various methods have been proposed to increase ETH’s throughput using transaction batching with ZKR. Many of the popular L2s use variations of these methods. Technical readers may want to review the basic mechanics, methods, challenges, and successes of L2s.
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
ETH, BTC, More
DeFi on the IC could look to exchange tokens from ETH to ICP and back via signing messages with tECDSA. These messages could be assumed to contain TO, FROM, and AMOUNT, signed with the user’s signature. In general, batch transactions containing many of these messages could be aggregated and signed at once by a canister smart contract.
Additionally, due to our unique ability to interact with BTC without a bridge, we could leverage ICP’s programmability with BTC’s liquidity by submitting SNARK-based transactions for BTC, which ensure the successful computation of ‘chains of logic’.
How it could work
A subnet or canister could submit batches of transactions to the target chain, which would include:
- A summary of the changes, representing all transactions in the batch.
- A proof of the validity of the changes in the batch.
On ETH, the rollup’s main contract will hold the state. A secondary contract can be used to verify that transactions were computed correctly off-chain (off-chain in this case refers to the IC). Proofs can be generated within users’ browsers (like SpinnerCash, with Circom, etc.), or they can be generated on-chain in canisters via a purpose-made API (3).
For BTC, component #1 and #2 can be held on the IC as canisters, submitting transactions for finality onto BTC asynchronously. The key benefit here is that transactions that require synchronous logic can be ensured to be computed correctly before finalization on BTC (e.g. DeFi, atomic transactions, or aggregating multiple actions before submission). This use case is particularly relevant for DeFi, as large batches of user data may be processed daily. Even the smallest mistake could be catastrophic for such a system.
- A purpose made API could be created at a subnet level, which creates a SNARK proof for all computations within a canister for a specific function.This proof would be used in #2 above. It would need to be made tamperproof by node providers so that one could not fake a computation without it actually occurring. This could be limited to IC level functions such as ledger interaction and token transfers where efficient and predictable circuits could be made. Also this might be possible with ZK-VM (Risc0)
Data availability and privacy
Some use-case of blockchain requires that all of the transactions are verifiable by re-creating the blockchain state when needed. With rollups this is generally possible as we submit state changes in (1) to the target chain. This increases usability and cross-chain friendliness for things like NFT. CAP is one such IC specific solution for this. The benefits of a cross-chain solution come with increased liquidity and audience for app developers
If we use the Zero-Knowledge portion of ZK-Proof we can ensure that IC users are not DOXXED by their interactions via apps on third party chains. If transactions are single signed, not batched, and do not contain mathematical ZK properties, it is very real possibility that transactions can be tracked back to IC users.
Conclusion
In summary, the use of Zero-Knowledge rollups (ZKR) can greatly increase throughput and improve the efficiency of various blockchain-based operations. By leveraging the succinctness of SNARK proofs and allowing for the ‘outsourcing’ of computation, ZKR can enable the submission of batch transactions to target chains, including ETH and BTC. These batches could consist of a summary of changes and a proof of their validity, and could be verified by a secondary contract on ETH or held as canisters on the IC for BTC. Additionally, a purpose-made API at the subnet level could be used to generate SNARK proofs for specific functions within a canister. Ensuring data availability is also an important consideration, and a data availability layer may be used for this purpose.
Discussion
How this would ‘plug-into’ the current thought about method for ETH-integration?
Other methods not mentioned.
Other benefits not mentioned.
Feasibility.
Public good or app specific?
Grant target or foundation? (If grant we will take it at ICME) (A standardize way to do #1 and #2 without #3)