Comments (4)
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.
from filecoin-ffi.
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.
from filecoin-ffi.
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.
from filecoin-ffi.
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.
from filecoin-ffi.
Related Issues (20)
- Rust unittests fail HOT 4
- failed to select a version for the requirement `funty = "~1.2"` HOT 6
- LotusTrace is incompatible with Lotus's FvmExecutionTrace
- Remove unused Rust dependencies HOT 2
- Is nightly Rust still needed? HOT 3
- Integration for new ec-gpu-gen available in rust-fil-proofs? HOT 4
- golang build failed HOT 2
- build failure on mac HOT 18
- Releasing MacOS prebuilts will break in June 2024 HOT 2
- CI fails on ARM due to cgocheck > 1 mode is no longer supported at runtime HOT 4
- CI failure due to ssh key issue HOT 1
- bug: lotus1.25.x lotus-worker cannot get gpu info HOT 1
- Release for FIP-0090/0092 HOT 6
- Migrate CI from CircleCI to GitHub Actions
- Align Filecoin-FFI Versioning with Builtin-Actors Versioning HOT 3
- Releases are triggered by code review HOT 2
- [DX Streamline] Do not hardcode the versions of tools in the CI HOT 1
- Final filecoin-ffi release for NV23. HOT 2
- Build flag for an SP-optimized library.
- Skeleton for nv24 to support development and testing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from filecoin-ffi.