Owners: @Thomas Lavaur @Mehmet
Research for a Circle STARK wrapper in general (with a first attemp on Stwo).
It’s possible to generate proofs using the Poseidon2 hash function with their repo but only over the stark field, a prime field with $p := 2^{251} + 17 * 2^{192} + 1$. We would like to produce proofs based on the finite field that is the scalar field of BLS12-381 or BN256.
Regarding the Circle STARK verification algorithm defined in the Stwo prover, many optimizations are made to reduce the size of the proof in exchange for increased computation on the verifier’s side. For instance, during the verification of Merkle proofs, if multiple leaves are being verified in the same tree, complementary hashes that appear more than once or can be recalculated by the verifier are not included in the proof. As a result, the verification must account for this by deducing the missing nodes and retrieving them from the proof. However, this is not ideal for a simple verification algorithm. In our case, it is preferable to have a longer input proof, but one where the verification of Merkle trees is simpler. This means additional work is needed rewriting the prover to ensure it is more compatible with the wrapper.
Moreover, many calculations necessary for verifying the steps around FRI (such as DEEP) are performed in the M31 field, which will then need to be emulated in the BLS scalar field. This could significantly affect performance, and it's challenging to predict the exact impact.
Finally, to make it fully usable, further work is required. To consistently verify the same proof with the wrapper, we need to define a proof using Circle STARKs to verify an arbitrary proof. This ensures that the input proof for the wrapper and its verification algorithm remain the same.
For all these reasons, in addition to the time required for implementation, parameter identification, and dealing with the nuances of Circle STARK verification, we have concluded that the time needed to complete the wrapper is much greater than initially expected.
The anticipated benefits of this work—such as increased flexibility in choosing the zkVM supported for native zone applications—do not seem to justify the effort. Furthermore, our analysis of various zkVMs has led us to favor the use of RISC0 for now, which already has a wrapper available. We believe it is better to postpone this research phase and focus on more impactful areas of the project.