Exploring the Potential of Zero-Knowledge Rollups (ZKR) for Improved Cross-chain Efficiency on the IC

Roadmap
1

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:

  1. A summary of the changes, representing all transactions in the batch.
  2. 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.

  1. 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 :index_pointing_at_the_viewer: :wink:

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)

13 Likes
2

Interesting idea, this sounds like it could be a lot more scalable than tECDSA subnets signing transactions one by one. For the rollups, instead of canisters, couldn’t just 1 centralized off-chain sequencer be used (like regular rollups)?

3 Likes
3

Hmm…I don’t understand how this would help to improve the throughput of tECDSA. The problem is the latency of the threshold protocol itself, which is just producing signatures. It doesn’t have anything directly to do with Ethereum, there is no communication with the Ethereum Blockchain.

tECDSA is just producing keypairs and signatures in a threshold manner. Batching wouldn’t overcome the fundamental latency required to perform the threshold operation in the first place.

That’s my take on this so far.

2 Likes
5

1 centralized off-chain sequencer

It would need to be decentralized. Also possible!

6

I am thinking about this from an application developer standpoint. I can sign messages with tECDSA which is rather slow if we just sign transactions for each… Or I can aggregate messages wth proofs validating correct execution of the aggregation like a rollup and submit them to smart contracts on the ‘target chain’. We can have users consent using IC methods like II… and let the code sign for a bundle of consents with tECDSA.

No intention of correcting tECDSA itself. I would also be interested in hearing about the theoretical possible throughput of tECDSA.

5 Likes
7

I see, that makes more sense to me now. I apologize I didn’t read the whole thing to truly understand.

3 Likes
8

Thanks, @apotheosis, for the write-up! One aspect I’d like to bring up initially is that the current restriction to ~1 sig/s stems from the fact that the current implementation of tECDSA has not been optimized for speed; some aspects are intentionally kept simple for now. As the implementation matures further, we do expect significant speed-ups. That said, the protocol is inherently complex (simply because ECDSA is weird) and the rate of signatures per subnet will always be limited.

For zkSNARKs, there are two main challenges:

  • Efficiency: Computing a zkSNARK proof is actually significantly more expensive than doing the computation (I don’t know the latest numbers, but the factor is probably in the hundreds for contemporary schemes). This is of course great in certain scenarios where one can greatly parallelize proof computation or where a proof is validated very often. But it also means that there’s still a big overhead.
  • Decentralized ZK: In order to get the ZK/confidentiality properties from the zkSNARKs, certain values in the computation need to be both random and secret. Which, when computing such a proof on the IC, means that we inherently need to do these things as threshold computations between multiple nodes, which of course again brings quite a bit of complexity.

If we only want the rollup part (and don’t care about the ZK), then this should be possible to build even within a canister and without support from the system (at least now that we have deterministic time slicing). That may even be a good POC to start with.

8 Likes
9

Thank you @bjoern completely agree! SNARK in a canister as a POC makes perfect sense.

  • I think with a POC and after creating some open-source tooling we can have a good use case for DeFi and NFT that work with IC and other chains (ETH first target).
5 Likes
10

Is the implication here that the IC can function as a L2 rollup for Ethereum? Can it feasibly outperform other zk rollups like StarkNet? What advantages would using the IC as a rollup bring over using a “traditional” zk rollup? I’m not sure I fully understand.

11

A roll up requires the user to control the private key of the address making signatures in order to inherit security from the chain of origin. Since the proposed design does not address incorporating BTC/ETH address user signatures, the purpose of the proposed design is to enable a canister running on the IC able to batch transactions on a chain integrated with the IC in order to overcome the tECDSA throughput limitations.

It is wonderful to see this novel proposal being developed by the community and I hope a grant is issued to support those researching this. I would suggest also integrating off-chain privately held signatures in order to make the ZKRU a true roll up which inherits the source chain’s security rather than solely using it for increasing tECDSA throughput. Direct Integration with Bitcoin - #677 by jglassemc2

3 Likes
12

There are various implications.

  1. Sequencers and provers can be on-chain. Most L2s use centralized sequencers and/or provers… (Cloud providers can still shut them down even if they ‘decentralize’, they still may have bad actors…)

If the code for sequencers is open sourced and the canisters blackholed - we can all trust there is no front-running, MEV work going on and those sequencers are processing exactly as the code tells them. Cloud providers cannot shut them down.

  1. Throughput for smart contract on other chains.

Defi: If the rollup’s state is also stored on ETH, and the rollup did transaction batches and made proofs on the IC — you can have full-stack DeFi running on the IC with finalization on other L1; the user can sign over using Metamask to an ETH smart contract as normal.

*For people who like ETH’s security guarantees; like @jglassemc2 mentions above.

tECDSA would be used to send proofs & summaries to be verified on ETH.

  1. Verifiable transactions.

If we have a summary of transactions and a proof (SNARK) showing accuracy of transactions, we can outsource (NFT histories) to other L1 that have public data. CAP does this on the IC, but I am not 100% sure of the setup. Does Psychedelic hold the data?

  1. Rollups are cheaper

It will be cheaper to do one summary transaction vs one for each on the L1s. Anyone interacting from the IC to another L1 would benefit from this when the state is left to the L1.

  1. Privacy

This will be picked up again later, after more discussion here, and a POC.

5 Likes
13

Implementing optimistic or zk rollups sequencers on the IC I believe is a fantastic experimental idea. If decentralization and censorship-resistance and community-ownership is important to rollup projects, then the benefits of running these sequencers on the IC should be readily apparent.

Biggest challenges I foresee would be actually getting these sequencers to run in the restrictive Wasm environment of the IC, which possibly doesn’t have the hardware access (GPUs?) some sequencers might be relying on for prover times.

5 Likes
14

Back in 2021 I believe it was, I reached out to someone from optimism to discuss the possibility of implementing an OP sequencer on the IC. At the time they were open to the idea, I think they still would be now. I also heard they have a ZK rollup in their plans, I haven’t confirmed that though.

7 Likes
15

“Optimism runs the sole sequencer on Optimism”

“The first step to decentralizing the sequencer is to still have one sequencer at a time, but rotate that sequencer with some frequency.”

I think they can do it, or help fund it after a homegrown POC. Most of the relevant work on this is already done in Rust. If a POC succeeds, I see no reason why the IC could not be used to make valid transactions to any L2 smart contract on ETH.

The prover & verifier code will help with many application types as ZKP tech has very real business and practical reasons to be hosted on blockchain.

I applied for a grant for this. Wish me luck :crossed_fingers:

=======
Community call / more discussion is always appreciated!

7 Likes
16

Dfinity should definitely be supporting something like this 100%.

4 Likes
17

Oh man I hope you get the grant!

3 Likes
18

Hey @apotheosis! Apparently, there is already a decentralized proof generation sequencers protocol called Proof Market developed by us (=nil; Foundation) in collaboration with Ethereum Foundation, Solana Foundation, Mina Foundation and StarkWare. All the proofs in there are verifiable on Ethereum, Solana, StarkNet and more verification is coming.

I’m thinking that ICP integration is something we’d be interested in if you’re about to do it.

4 Likes
19

Hello, please provide a few links or documents. It seems like this is a market of some sort where you pay for proofs? How much demand is there for this?

Are you generating Groth16 proofs with your zkLLVM that people then pay for later on ZKP related blockchains?

20

Also on your partners page, are those your investors? If so, can you do an intro so I can pitch them something :wink:

1 Like
21

Love the idea, but I have a question about the efficiency of this scheme @apotheosis :

Is a zero knowledge proof any faster to generate than a tECDSA signature on the IC? A ZK proof generated by the IC would still have to go through consensus and may be slow. In which case, what extra performance do you get over just batching transactions, and using ECDSA to sign on the batch of transactions, with some inclusion proof e.g. merkle or BLS submitted to the destination chain?

2 Likes