-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Milestone: zerokit release v0.1 #31
Comments
This release was supposed to be out 2-3 weeks ago and it has become big in scope. Last portfolio update it was reported to be "100% complete" which is clearly not the case. A lot of code hasn't been merged, no release notes or anything. I know there's a "blocker" but the goal was to take what exists and make that into a release. We want to cut scope and fix time, not expand scope and increase time. |
This is marked as done but issue is still open. |
It was marked in red with comments, which meant that required attention/discussion. From commit history, the implementation was complete (modulo cherry-picking commits in sub PRs) the 2nd of September with respect to scope set in #31 (reduce library size was added later in light of #37 to track experiments done in #37 (comment)). Note that blockers (most of which were later solved internally) would have prevented drafting a reasonable release note and/or merge scoped small sub-PRs, since such blockers would have affected directly features' usage and availability. |
See #35 (comment) |
Problem
UPDATE: This is becoming a waterfall release which keeps getting delayed, which was never the intention. We want to take existing code and cut it into an initial 0.1 release.
We want to publish a release v0.1 for Zerokit with a first
matureversion of the RLN module.Before that, it is desirable to clean-up the RLN module library code and implement different optimizations which are already standard in other libraries.
These allow to: make the RLN module more efficient and easily integrable in projects employing the RLN primitive; bring a cleaner code and optimized cross-module primitives (e.g., Merkle trees) to new zerokit modules.
Scope
Release zerokit v0.1 with a RLN module that can replace and improve Kilic's RLN module currently employed by
nwaku
.Must have:
-- Err on side of not accepting more scope
Initial list of issues, many nice to haves that can be dealt with separately:
new_with_params
#36)Acceptance criteria
Issues defined in scope addressed.
Risks and uncertainty
Removing some dependencies (e.g. semaphore-rs) might result not trivial, since there might some implementation used across the code base that should be ported to the replacing dependencies.
Out of scope
This milestone's scope requires a RLN module which can replace (in terms of APIs and efficiency) Kilic's RLN module. However, integration of zerokit v0.1 in nwaku is out-of-scope and is tracked in waku-org/nwaku#1061.
Notes and links
This first issue partially overlaps with vacp2p/research#127, where a thorough performance analysis of employing Incremental Merkle trees is performed. This milestone will clearly benefit from completion of vacp2p/research#127, and new items will be added to the above issues list to implement any eventual optimization found.
The text was updated successfully, but these errors were encountered: