-
Notifications
You must be signed in to change notification settings - Fork 100
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
Tracking: Update lightwalletd
RPCs for "spend before sync" algorithm
#6642
Comments
Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn |
@mpguerra I can't estimate this ticket until the |
lightwalletd
RPCs for faster sync algorithmlightwalletd
RPCs for "fast spend ability" algorithm
lightwalletd
RPCs for "fast spend ability" algorithmlightwalletd
RPCs for "fast spendability" algorithm
The current draft of the JSON-RPC changes is here (last few commits, the PR is currently based on another one and will be rebased as the backend changes are landed): zcash/zcash#6677. |
I've added a draft list of RPC changes to the ticket, just trying to work out how to calculate subtree roots: |
Note from the engineering sync: This seems risky to do between the last release candidate and the first stable release. There is no specific deadline for this change. |
@mpguerra I'd like to talk through the design for this change with the engineers who will be working on it. We need to work out the tree API changes, and the database format changes. Did you want to have a large group meeting? Or we could do it in two smaller groups: tree APIs and database format. |
Also I just split this task into tickets, can we schedule them in this sprint or next sprint? |
lightwalletd
RPCs for "fast spendability" algorithmlightwalletd
RPCs for "fast spendability" algorithm
Unscheduling as this will be the overall "tracking" issue and we'll schedule individual issues in sprints instead |
I think it's probably best to have smaller group meetings and involve only the people that will need to be involved |
lightwalletd
RPCs for "fast spendability" algorithmlightwalletd
RPCs for "spend before sync" algorithm
We are done here for now 🎉 |
Motivation
The
zcashd
andlightwalletd
teams have been working on a "spend before sync" algorithm, targeted forzcashd
5.6.0 in June 2023.As part of that change, the JSON-RPC interface used by
lightwalletd
will need extra methods or fields.Preparation:
completed preparation
Make the first stable release forward-compatible with planned state changes #6746
Create an empty database format update task and format update tests #6955
Tracking: Upgrade shared ECC dependencies and zcash_script for zcashd 5.6.0 #6859 (Update
incrementalmerkletree
crate to 0.4.0)Upgrade lightwalletd used by Zebra #7292
Zebra will need to implement some of those changes to remain compatible with the latest
lightwalletd
versions:getblock
RPC #6952z_getsubtreesbyindex
RPC #6954z_getsubtreesbyindex
RPC #7449zcashd
#7446z_getsubtreesbyindex
usingzcash-rpc-diff
#7450z_getsubtreesbyindex
using alightwalletd
gRPC request #7451z_getsubtreesbyindex
RPC #7513Extra Dependencies & Tests:
completed
deny.toml
onceed25519-zebra
andzcashd
are released #6638Lower Priority
Minor bug or test fixes:
zcash-rpc-diff
#7351completed performance & documentation
To get reasonable lookup performance:
Documentation:
Optional Cleanups & Fixes:
these tickets are optional, ask Pili before starting them
Bug fixes:
Height
s #7263Technical debt:
NoteCommitmentTree
s using supported serialization format instead ofbincode
#7383Diagnostics:
Needs decision/triage:
Timing
zcashd
aims to finalize the RPC design by the end of May, and then release it in the first two weeks of June.lightwalletd
will start calling the new RPCs around the same time, but they aim to be compatible with old RPC versions using an off-by-default flag.Implementation Notes
Zebra already stores the data we need for these lookups. We might need extra indexes for good performance, but that's not a breaking state change. (So we don't need to upgrade the state version, we can just automatically add/update a new column family with the new index at startup.)
We will need to implement #4784 to have acceptable note commitment tree scanning performance.
The text was updated successfully, but these errors were encountered: