Proposal: A (parameter) versioned filecoin-ffi API

[filecoin-project]

Proposal: A (parameter) versioned filecoin-ffi API

[laser]

@dignifiedquire

sure, but I want to make it clear that I have not seen any reason so far that suggest we need more api surface and will likely not have time to think about this more for a while

and that shipping unsupported versions of the protocol is a security risk asfaiu what you suggest in the proposal above

I believe that adding API surface area - to support multiple, concurrent proof parameter versions (e.g. v25, v26) - is to allow us deploy new proofs software to the node w/out breaking the previous software. This gives nodes a smoother upgrade path than what we have today.

[anorth]

I agree with the premises. I think an appropriate API for FFI to expose is a set of functions per parameter version, as you suggest. This is necessary for any upgrade to be consumable into a running network: the whole chain history must be verifiable. For testing this, we also need to continue to be able to create proofs with older versions so we can then test they are correctly verified.

I don't quite know what "filecoin-ffi should import N versions of the filecoin-proofs crate" means. My primary recommendation would be that the underlying Rust proofs library also continues to directly support all proof versions used in a live network, probably by the same pattern of a set of functions per proof-parameters version. I think it would be super painful for integrators to have to hunt through multiple different source trees of the "same" library to trace the code they are running. Even if superceded by a new proof version, the older ones are still first-class requirements of the running network and should be treated as such by the proofs library.

[laser]

My primary recommendation would be that the underlying Rust proofs library also continues to directly support all proof versions used in a live network, probably by the same pattern of a set of functions per proof-parameters version.

What you recommend is different than what I recommend in an important way: It would require rust-fil-proofs ("the underlying Rust proofs library") to support multiple Groth parameter versions. The approach which I proposed does not have this property; the filecoin-ffi project would import various versions (Git commits) of the underlying Rust proofs library ("filecoin-ffi should import N versions of the filecoin-proofs crate") whose functions it would expose by prepending a parameter version-prefix (e.g. v27_verify_seal).

The approach which I propose will not be optimal for Rust implementations, as Rust implementations will not use filecoin-ffi. The approach which you propose is more work for the maintainers of rust-fil-proofs and less work for the maintainers of filecoin-ffi.

[vmx]

I dare to close this issue as this proposal wasn't discussed for years, and also we haven't had new parameter versions since mainnet launch.