@koute Almost!
Actually, the compiler blob is not needed, only the hash. A receipt you get from risc0 is self-sufficient to be verified and it contains, roughly speaking, the input/output data[1], the ELF image ID of the program proved and the cryptographic seal. You only need the verifier program that verifies the receipt. The verification process will verify that the seal corresponds to the claimed input/output data (which is in our case is the untrusted program, and perhaps the cycle count).
But proofing that the compiled code is “secure” (in the sense of as secure as you’d properly sandbox it), might be hard to impossible.
this is not quite true. Let me explain.
There is process of re-hydration, i.e. getting the serialized artefact Engine::precompile_module and then re-hydrating it via Module::deserialize. This process should be safe as long as Configs (or as I refer to them as compilation flags in OP) used to create the Engine are the same. It better be safe, because we are relying on it in the parachain validation functions.
Assuming the same version of wasmtime/cranelift, assuming the same flags and assuming the process is deterministic (although not necessary), then there is no difference whether you called precompile_module on your machine or got the result with the SNARK proof[2].
IOW, If you trust that the re-hydration then with the proposed solution it should stay secure.
It doesn’t matter, because you can transform the statement
f(X) == Ytof(X) - Y == 0. ↩︎Well, kind of, because you take on additional assumption of the soundness of the proving system. Modulo bugs, there are certain additional assumptions, that should hold true. But that’s the whole value proposition of the SNARK that they are convincing arguments. This is in the same way as you trust your hash function is collision resistant. ↩︎