Support feature flags for side-loaded keys

[mitschabaude]

in o1js side-loaded keys, feature flags get hard-coded to None: https://github.com/o1-labs/o1js-bindings/blob/10e33c03648fa6d2201d2665cd2fde7064525ac8/ocaml/lib/pickles_bindings.ml#L763 which means they can't use optional custom gates!

the transaction snark, which verifies zkapp proofs which might use these gates as well, instead hard-codes all feature flags to be "Maybe": https://github.com/MinaProtocol/mina/blob/8d45fa970786e58fc6778ec3bdbe5fec1b361b27/src/lib/transaction_snark/transaction_snark.ml#L610-L627

as a quick fix we could do the same in o1js. However, Matthew says that "maybe" incurs a lot of overhead and we should expose customizing that.

note how o1js computes the feature flags itself when compiling circuits. we would just have to save them and (optionally) provide them alongside the side-loaded key https://github.com/o1-labs/o1js/blob/2b187fbe9c8d727b71e987b0477e98a2082fa54f/src/lib/proof-system/zkprogram.ts#L1040

[Trivo25]

I need to confirm my assumption but I think we have to provide the developer with these configuration options:

• all maybe - can verify any proof, no matter what custom gates it uses
• user defined compile constants - let the developer decide the shape of custom proofs their wrap circuit should be able to define

This is because we cannot provide feature flags dynamically to Pickles (at runtime), as doing so results in a change to the verification key of the wrap circuit. Instead of providing the feature flags as meta data alongside the verification key or proof, the developer would have to define this as part of the circuit configuration at compile time.

[Trivo25]

We could also require these constants as part of either the custom proof class, or additional meta data of the verification - but for side loading I believe it feels more natural to define these constants as part of the zkProgram, rather than "pseudo" dynamically in the verification key or proof

edit: I did some thinking, providing these constants as part of the custom proof class probably does feel better, since this way the developer describes the shape of the proof (or circuit) that their programs can side load - this is also quicker to implement. I dont think we can provide them alongside the verification key, as the feature flags need to be define on the branch/proof level

[mitschabaude]

I did some thinking, providing these constants as part of the custom proof class probably does feel better, since this way the developer describes the shape of the proof (or circuit) that their programs can side load - this is also quicker to implement. I dont think we can provide them alongside the verification key, as the feature flags need to be define on the branch/proof level

this sounds like the right approach to me!

we could also expose 3 ways to easily create the feature flags that the user puts on the dynamic proof class:

• all maybe
• all none
• compute from a given ZkProgram