I think the answer is yes when we are referring to STARK proofs due to its large size and thus the difficulty to process in Ethereum.
As for runtime efficiency, we did’t do the benchmark really. From what we can tell regarding the canister, the verification time is in the order of 0.1 second. We can do some benchmarking later on to find out more.
The next point here is that people need to wrap proving systems so they work on ETH with Groth16, in many case. This takes a lot of work and sometimes does not work at all. Newer proving scheme might be really cool and fast, but it takes a load of effort to make them practical for ETH.
Why not just use them as-is and use tECDSA like is done here?
In the case of STARKs they either eat the gas fees or use slower provers to make smaller proofs.
ZKP on the IC makes sense all around.
Maybe Dfinity should spend some time preaching at ZK Events? ZKSummit is in Athens this year.
This is an interesting development from =nil; Foundation that they are calling zkSharding
Also, their zkLLVM compiler allows circuits to be developed straight from C++, Rust, which they used to build their Type-1 zkEVM.
This is still ultra relevant in 2025.
There have been many developments that have made ZKP faster and more portable.
Not an issue if you run locally or in a prover network and verify on the IC.
Not an issue if you run locally or in a prover network and verify on the IC.
The core remaining issue is that ZKP is still slower than native execution (some dApps would care). There would need to be formal verification of zkWasm - which would need to be continually done as ZKP tech moves so quickly.