This week concludes a 2-week engineering sprint. You can check out last week’s update for recent updates on community and communications.
Consensus Protocol Team
The focus of the team over the next couple months will be protocol code cleanup/refactoring and research to study potential improvements in the next network upgrades. Follow along in the #zcash-refactor channel in the community chat.
This team has been working on documenting the Sapling design explanation and jubjub cleanup/refactoring.
We worked on getting more of our infrastructure into Gitlab and got the initial Zcashd Windows CI component implemented. Next sprint we’ll work on a binary running full test suite on native Windows and updating new Sapling benchmarks.
For the time being this team handles business development in the phases after initial contact by providing technical insight and support.
The Ecosystem team continued to do outreach and education directed to commercial products such as wallets and exchanges about the Sapling upgrade. We’ve got a growing list of Sapling-ready services on the countdown page .
We added documentation to the Debian binary setup page to help users deal with a recent expiration of the dev signing key. We also have been continuing to update Sapling related changes to the RPC and general user experience post-activation.
These pages include:
The dev-infrastructure team moved the documentation repository to a new (official) repository in Gitlab now that the process has been running smoothly for several months now.
Finally, as stated last update, we’re working on smoothing out the process of engineering teams taking responsibility for their own documentation related tasks.
Reference Wallet Team
This teams current charter is to build a Zcash reference wallet. Deliverables will be a series of MVPs where Android is the first target platform.
We’re continuing to work on the reference wallet, which is concrete and functioning code proving that a shielded transactions can work on mobile devices.
Given the technical challenges associated with implementing shielded addresses today, the most obvious way for a wallet to obtain transaction information is to give the server its viewing key, so that the server can see which transactions belong to it and just pass those along. However, we at Zcash don’t find this to be a satisfying solution because it does not meet our privacy goals:
- The server should not learn which transactions are belong to a given wallet.
- The server should not learn which transactions are being spent by a given wallet.
Instead, we are working on an alternative solution that satisfies these two goals. This week, we spent time specing out this work, implementing payment detection in a privacy-preserving way, and setting up the android application to integrate with dependencies.
We’re hiring an IT Operations Engineer!
We have a new blog out on Sapling shielded HD wallets: Sapling in HD.
That’s all for this week!