I have opened this issue for this purpose (Enumerate the set of indices required by "full node" wallets and block explorers. · Issue #72 · zingolabs/zaino · GitHub). And will be reaching out to exchanges and other users of zcashd’s cli’wallet in the near future.
Hey folks! This is thrilling news. Look forward to hearing about our progress in 30 days!
To me the issue is not whether zcashd deprecation will be complete within 5 months (although I hope it will be); it’s whether we will need the indexer piece before 5 months. I think that other parts will get to the point that they are blocked on having the indexer, long before that.
NU6 will activate on time at the halving. zcashd 6.0.0 will be released this week (6.0.0-rc1 is already out; there’s just Make DEFAULT_BLOCK_UNPAID_ACTION_LIMIT zero by daira · Pull Request #6900 · zcash/zcash · GitHub and the final changes for activation which will go in the release PR).
Is there any way to see the history of changes? (I strongly suggested moving the grants to GitHub; I gather that hasn’t been done yet.) I don’t see significant changes since the last time I reviewed, but it’s hard to tell if I have to just rely on memory.
ZF Engineering team confirms that we are good with the grant in its current shape and we have 2 pieces of additional feedback:
- We would request that all work be open source and licensed with an appropriate open source license. We notice the Zaino repo does not have a license yet.
- It would be good to have a bit more detail within the grant itself on what each of the deliverables entails although we do see that the issues in the github repo provide more information.
I am in favor of using git to manage grants. I don’t know if/how to access edits in submittable, but I can look into it, if necessary.
I believe that the MIT license is acceptable to everyone?
We can add that to the repo, if there’s agreement.
We’re happy to copy details into the submittable grant form if that’s required.
Would 2 to 5 bullet points in a list be an acceptable format in the grant?
If that’s the ask then we can make a 1:1 map from tracking issue task to submitted-deliverable bullet point.
Good luck to you and your team
I am good with the current grant with the software deliverables being under the MIT license.
Great and important news. We are one step closer to reaching new objectives, strengthening the network and leaving behind the obsolete.
We’re well under way on Zaino, but due to the initial payout occurring two weeks later than anticipated we’re expecting each milestone to come in two weeks late.
Hey folks, we’re in the process of final review of our MileStone 1 code.
The upshot is that we’re going to be testing a full set of Rust-implemented lightwalletd RPCs this week.
We’ll offer more specific details as we wrap up final review.
Hello folks we have finished review and are releasing zaino 0.1.1.
This release completes our Mile Stone 1 goals. It supports the full set of lightwalletd RPCs, and is suitable for alpha testing.
Hi,
ZingoLabs are pleased to have now released Zaino (pre-release) v0.1.1 and announce completion of Milestone 1 for the Zaino dev grant.
Zaino now supports the full set of Lightwallet RPC services. Zaino is also now ready for direct integration with Zebra’s ReadStateService
, having removed or replaced all conflicting dependencies.
We have also started developing a new test framework, zcash-local-net.
This repo has been developed to compare functionality between various validators (Zcashd, Zebrad) and indexers (Lightwalletd, Zaino) to ease migration throughout the Zcashd deprecation process.
Along with the functionality to launch, cache and load Zcash chain data (mainnet, testnet and regtest) for the full set of validator and indexer options, zcash-zocal-net
also holds a set of tests to compare functionality between Lightwalletd and Zaino for the full set of Lightwallet RPC services. These tests can be run directly from Zaino (see docs/testing.md]) and are used to test the Lightwallet RPC services held in Zaino.
Our next steps will now be implementing direct chain access using Zebra’s ReadStateService
and implementing Mempool
and CompactTx
parsing optimisations necessary for serving a large number of clients concurrently.
A full list of PRs completed for this work can be seen here (Zaino - Milestone 1 · GitHub).
Z^3 Zingo-Cli – Zaino – Zebrad
I love it!
Hey folks. I have been remiss on updating this thread.
@pacu has been publishing weekly report that cover Zaino progress, in more than monthly detail.
Instead of having multiple sources of truth for those details please read his excellent updates on our progress.
For a higher level overview, we have missed some deadlines due to my overly optimistic estimates of new-developer onboarding. This has left zaino under-resourced and forced @idky137 to work long days and weekends which they have done heroically.
The good news is that 0 ZEC will be disbursed before we hit our targets, and we’re still well ahead of schedule for supporting ZcashD deprecation.
Our new contributors are now fully onboarded, and will be getting Zaino completed by mid-to-late-May.
When you build something new you inevitably encounter unpredictable environments.
In the course of building zaino
we encountered behavior in zebrad
that no-one could have predicted because of the size, age, and diverse contributor set of the codebase.
In the current environment where that aspect of zebrad
(“regtest-mode”) is being rapidly upgraded, we have been able to contribute by detecting issues, and communicating efficiently and clearly with the zebrad
team. Indeed this process has both demonstrated and refined our cross-community collaboration patterns.
In the meantime our Zaino Milestones have been delayed in part because we needed to focus developer-time on this zebrad
behavior, and in part because upgrading zebrad
is required for parts of zaino
to be completed.
This is not to say that this behavior accounts for all of the delay in zaino
. As mentioned elsewhere, and reported in @pacu 's weekly update, I miscalculated how fast developers could switch foci, and that left zaino
with fewer resources than anticipated.
This post is to request that the @ZCG provide us with a retroactive payout worth $4000.00 to cover the developer effort that was necessary to formally isolate the behavior in systems beyond our direct control. This payout would serve to cushion our treasury against the delay of MileStone 2, that’s a consequence of this environment.
Thanks for your thoughtful attention!
Hi folks, we’re thrilled to announce that we’ve completed the work for Zaino MS2.
We’re now tracking the details of our progress using github projects, so you can easily peruse the work completed for this milestone here!