A good deal of functionality beyond the initial grant is already in place. We have key derivation, a few BIPs and ZIPs implemented, and .NET APIs that expose some of the functionality required for .NET to act as a lightwallet client.
In the next month, I hope to implement and stabilize most functionality except for transaction download and creation – the functionality that actually requires interacting with the blockchain. I have prototypes of a very limited set of lightwallet sync functionality, but there’s lots more work to do. I’m consuming ZingoLib (from the Zingo team, also funded by a Community Grant) for some of this functionality, and that team is working through some bugs and features that will be important for this project to consume, so scheduling this work for more than a month out should help our requirements and their features align.
In the next month, as expected I’ll be working on sync functionality (download and sending transactions) and balances. I hope to provide APIs by which a wallet app can convey very user-friendly concept balances (i.e. not the same ones I tend to see in wallets today). Here’s an example:
True auto-shielding functionality is also on the backlog, and I hope to get it done in the next 30 days as part of the sync work.
Finally, and this is something of a stretch goal, I hope to include shielded pool balancing functionality so that the wallet app (or user) can decide what proportion of their funds to keep in sapling vs. orchard. When each shielded pool carries a balance, payments are less likely to have to cross the turnstile, revealing the amount (or at least a clue about the amount) in a transaction.
Downloading and sending transactions is better now, but bugs in zingolib cause importing of older accounts to present bad balances, show bizarre amounts on the transactions, etc. Debugging their code to help author fixes is a bit overwhelming (for me) since I’m still ramping up.
As a possible alternative I’ve been looking at consuming the zcash_client_backend and zcash_client_sqlite crates instead. There is a lot of work involved in this switch, and I’m not sure whether it will be successful. So far though, I have re-implemented account sync, and it implements a faster sync algorithm so I think it’ll be a good long-term move. It does mean re-implementing some of the functionality that I already had through zingolib, so feature progress will appear to stall for a time (not sure how long yet).
Getting familiar with these lower-level crates also opens up possibilities for more use cases, which for a .NET library I think will be very interesting. I hope to allow for directly importing of various key types (so, not only just 1 seed phrase) for example).
Before this rust dependency reset, in the last 30 days some good stuff got done:
I have a branch where Nerdbank.Zcash is backed directly by the lower-level crates zcash_client_backend and zcash_client_sqlite. This version scans blocks much more quickly than the zingolib branch, and there is room to about double that speed as well. But these crates do not (yet) fully support orchard, which zingolib already supports. Zingolib does not yet have the sync bugs worked out, and the lower-level crates don’t support transparent pool transactions very well either.
So I’m in something of a holding pattern now, waiting for the dependencies in either branch to mature to the point where they are both full featured and can be reliably used. In the meantime, I’m studying the lower-level crates more and authoring a few small PRs to them. My hope is to help move the work along wherever I can.
I also made a few small improvements on the .NET side, namely:
I also completed my migration from ZingoLib to the librustzcash crates. We lost mempool transactions and orchard support in the transition, but picked up ZIP-317 fee support. librustzcash is expected to deliver orchard support very soon, and I’ll pick that up right away when it’s available. Mempool transactions shouldn’t be hard to add support for as well.
Following are noteworthy changes made since my last post:
I copied the grant proposal deliverables into a GitHub issue to track remaining work: Funded Zcash proposal: Complete full lightwallet functionality for .NET · Issue #229 · nerdcash/Nerdbank.Cryptocurrencies (github.com)
As you can see from that list, the work is virtually complete.
Mempool support was specifically mentioned in the grant proposal under the assumption that the rust crate the .NET library depends on would support it. Since the librustzcash crates don’t yet support it, I’m proposing we drop it from the spec of the .NET library, under the expectation that it will be filled in when the rust crate offers it (which I might contribute myself).
Watch the demo, which walks you through creating a cross-platform C# application that functions as a Zcash wallet in under 8 minutes: Zcash .NET library demo video
Fantastic work, really liked your video! Will you post this demo and code into places like The Code Project? I want to see if I can get this working in Linux as well.
It already works on linux, because Avalonia is a cross-platform GUI framework. This is running the build I produced with Visual Studio on Windows, running under WSL:
