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.
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.
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).
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.
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
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.
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.
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?
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.
Privacy
This will be picked up again later, after more discussion here, and a POC.
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.
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.
“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
=======
Community call / more discussion is always appreciated!
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.
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?
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?
ZKP are used because they are succinct. They are also commonly used because they demonstrate a summary record was created following the ‘correct’ method.
We would be batching calls into a summary and a ZKP which would be submitted to an L1 (ETH) using tECDSA. 1000 transactions being signed separately would be less efficient than batching them into one (plus cheaper because 1000 different instances of gas fees)
Moreover, a ZKR would be generally useful for many apps types as anyone could join the batch.
Plus we could have a two-way gate into and out of the ZKR.
Sure, but you don’t necessarily need a ZK proof to do this, you could just use tECDSA to sign a single hash commit that summarises the 1000 updates, which has the same effect as a ZK proof when read by a solidity smart contract. But I’m all for all types of code being implemented, the tECDSA would probably be easier to implement for a first attempt and probably cheaper to verify on Ethereum main-net.
