There are more than two components here :
- prover, verifier, and common run-time libraries,
- individual proofers and verifiers for a specific tasks ranging form individual cryptographic widgets up through full state transition functions,
- a compiler that helps produce individual proofers and verifiers from both AIRs, which sounds more general than R1CS, and other composable proofers and verifiers pairs used as “libraries”.
I’d think proovers must be open source and run by block producers, collators, or archive nodes. If not, then your chain is insecure, due either to being close source, or worse maybe outsources important functionality to some prooving company, making it not even decentralized.
We cannot make exactly this security argument about the compiler however. If the compiler is closed source then designated people can modify the chain, but the compiler’s output might be somewhat readable Rust or C ode, making security auditing possible, while not providing the full benefits of open source software.
We cannot quite build such a compiler for SNARKs and bulletproofs yet, because they require so much manual fiddling, although the ZEXE paper starts introducing a set of widgets that might eventually yield a higher level language. An enormous selling point of STARKs is promising this compiler though, so if the compiler is closed source then STARKs seem much less useful, especially from our point of view with many different parachains.