Zecwallet Lite is a set of desktop and mobile apps that implement the Zcash Lightclient protocol. They are light wallets that allow users to easily send and receive shielded transactions without needing to download the entire blockchain. Zecwallet Lite was originally released in early 2020, and is widely used in the Zcash ecosystem.
Zecwallet Lite uses the Zecwallet Lightclient SDK, an independent implementation of the Zecwallet Lightclient protocol that is used by the desktop and mobile Zecwallet Lite apps.
Motivation and overview
When Zecwallet launched, the Light client protocol was very new, and some features weren’t implemented yet, so Zecwallet had to fork a couple of projects to add support for the full feature set. Since then, Zecwallet has upstreamed several changes, but we need to catchup and pay down some of the technical and security debt we have accumulated over the last year. This proposal outlines the 3 biggest shortcomings and proposes to address them over the next 7 weeks.
A big reason for doing this now is to prepare for the upcoming Pollard/Halo upgrade. Removing un-needed dependencies and relying on common implementations will make sure that future Pollard work will be doable without complicated customization, which might introduce further risks.
This project proposes doing 3 major tasks:
1. Depend directly on ECC’s librustzcash
When Zecwallet Lite originally launched last year, we decided to support t address transactions as well in the lite client. This didn’t have support in
librustzcash, so Zecwallet forked ECC’s
librustzcash repository to add t-address support. Since then, we’ve been working to upstream the changes, and we’ve already submitted several PRs. Additionally, ECC has also added t-address support into
librustzcash. This task is to finish the final set of changes (which are largely on the Zecwallet SDK side) to completely remove the dependency on the Zecwallet’s librustzcash fork, and depend directly on ECC’s
2. LightwalletD compatibility
When Zecwallet originally launched, it forked the stock LightwalletD and implemented two sets of changes in the fork:
- Add t-address support
- Cache the entire Compact blockchain in memory, trading off higher resources for faster sync speed. Combined with multi-threaded syncing support on the client side, this significantly improved sync speed, which was the biggest complaint lite wallet users had.
Since then, ECC’s LightwalletD has progressed considerably, and now also has support for t-addresses. Unfortunately, this is not API-compatible with Zecwallet’s LightwalletD, and this task is to fix this by switching to the stock LightwalletD’s API.
- Add support for stock LightwalletD’s t-address API and implementation.
- Fix Zecwallet Lightclient SDK to use the new t-address API.
Once this is done, we’ll have two way compatibility. i.e.,
- Zecwallet Lite apps will be able to use stock LightwalletD to sync
- Other wallets implementing ECC’s light client SDK will be able to sync against Zecwallet’s LightwalletD
This should go a long way in reducing the dependency on Zecwallet’s LightwalletD server, and allow users to easily use any of the community-run LightwalletD servers.
3. Security Review of the Zecwallet Lite SDK
One of the major outstanding items from last year is to complete a full security audit of the Zecwallet Lite SDK. As a reminder, Zecwallet Lite SDK is an independent implementation of the Lightclient Protocol, which is used in Zecwallet Lite apps and a few other community projects. It uses
librustzcash to access Zcash’s cryptographic natives. While
librustzcash is maintained by the ECC and has regular security review, Zecwallet’s Lightclient SDK has never been security audited.
Zecwallet solicited 3 proposals from external companies, and the most competitive proposal is from Least Authority. You can read the detailed proposal here
Security audit Zecwallet Light client SDK.
Zecwallet will also set aside three weeks of Developer time to address any issues that are uncovered by the Security Review.
librustzcashchange, there aren’t many unknowns, since Zecwallet has kept up with the upstream changes. The vast majority of changes are on the Zecwallet Lite SDK side, to use the APIs and ZIP implementations of the upstream
For the LightwalletD compatibility, there aren’t many unknowns, since the fork already implements the t-address support. Once major risk area is performance - Zecwallet will need to maintain the faster performance even for the new API implementation, using the in-memory cache for Compact blocks.
The Security Review has many unknowns. Least Authority has done many reviews, and they have a lot of expertise on both the Rust side and on the Zcash side. There is some uncertainty around timing and availability of engineers if we are delayed beyond end-Jan.
The risks are mainly on the Zecwallet side. If there are major issues uncovered, we’ll need to move fast and implement them. For other fixes, the 3 weeks of allocated developer time to fix issues might not be sufficient.
There are no major downsides to this project, but some things to keep in mind:
- The security review might uncover major issues, which might need major architecture/infra changes
- Even after the LightwalletD API compatibility fixes, the implementations of LightwalletD will continue to be different, which might cause unexpected future issues.
This project will be a success, if:
- Zecwallet and LightwalletD are two-way compatible, and users can switch between many lightwallet servers
- The dependency on the Zecwallet fork of
librustzcashis completely eliminated
- Zecwallet addresses and fixes major items from the security review.
Tasks and schedule
Rough schedule, tasks and timelines:
- 80 hrs (2 weeks) of work
- Publish new releases of the Lite apps that don’t have this dependency
- Expected 31 Jan 2021
LightwalletD API compatibility
- 80 hrs (2 weeks of work)
- Implement stock LightwalletD API
- Update Zecwallet apps to use new API and publish releases
- Expected 15 Feb 2021
- Will be done in parallel by Least Authority
- 120 hrs (3 weeks) of developer time to fix any issues uncovered
- Security Review: Last week of Jan, 2 weeks
- Fixes: Expected 6 Mar 2021
Budget and justification
Total: USD 112,500
- 7 weeks total (@ USD 187.5/hr)
- USD 52,500
- USD 60,000 approx