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.