I absolutely agree. While this may be a competing proposal to, say PolkaVM, I think it’s more long-term solution (The fact that risc0 is not battle tested implies that we would need to wait quite some time). I would like to defer comparisons between those solutions to another thread, which preferrably has a more concrete definition of the SNARK side, not a strawman presented here! The main point of this thread is to educate developers about this tool that IMO has a lot of promise.
For contracts it would require us to store the compilation output on-chain as we can’t just require the client to have all binaries cached as we can for the runtime. For the simple reason that the relay chain does not have the source code (wasm) in state.
This caveat is also what made us ditch the caching approach and instead go for very fast compilation.
I thin it’s a bit more nuanced.
In the case of re-execution validity proofs (parachain/PVF execution), we would need to put the compilation output in the PoV. The parachain itself doesn’t have to store the compilation output in the store, since the collator can cache (offchain) or rederive it. The deal breaker may be the footprint of PoV. It might be alleviated with the relay-chain side caching of the final machine code artefacts (no wasm needed for rederivation).
In other cases (standalone L1 or rollups) you don’t care about that, since validators don’t have to re-execute it, and the protocol may be designed in a way that allows plenty of time to make sure the required artefacts are in place.