Zondax HW wallet support: From zero to hero

At Zcon3, this year’s Zcash Foundation annual event, our engineers Ida Tucker and Francesco Dainese braved the main stage in Las Vegas to demonstrate Zondax’s complete Ledger support for shielded Zcash transactions in Zecwallet Lite.

We’re excited to share some technical perspectives of our significant team effort. Read on for the challenges we faced and the innovative solutions we implemented, culminating in a successful demo at Zcon3.

Developing support for z-addresses in hardware (HW) wallets like Ledger devices has been challenging. That’s because creating the Zcash Ledger app involved complex and Zcash-specific cryptography such as key derivation via ZIP32 and RedJubJub signatures.

Furthermore, the workflows included zero-knowledge proofs, a mix of C and Rust implementations, and Rust/LLVM non-constant time operations in Cortex-m0. These spiced up the challenges we experienced, complicating the identification of possible issues and the creation of a memory-optimized implementation.

What was the main issue with developing a Zcash Ledger app for shielded transactions?

Hardware wallets in general have limited memory and computational power. For instance, Ledger Nano devices were not able to decrypt on-chain messages at an acceptable rate. This limited the speed at which users could retrieve account balances and/or generate zero-knowledge proofs that were necessary to approve transfers.

Several design and engineering optimizations had to take place. In particular, the source code had to be optimized further to fit and run within less than 4kB of RAM (a limitation imposed by Ledger Nano S devices). Last but not least, it was necessary to delegate some key material to the host, so on-chain messages could be decrypted timely and account balances could be calculated. Also, by delegating proving keys, hosts were also able to compute zero-knowledge proof: A critical step in the process of signing shielded transactions.

It’s worth noting that even when hosts may have temporary access to some of these keys. They only allow decrypting or generating zero-knowledge proofs. Access to signing keys is never allowed. This means that authorizing the spenditure of funds is still and always protected by the hardware wallet

Zondax started working on the Zcash Ledger app in 2021 and completed the app itself as originally arranged that year.

Unfortunately, and probably due the complexity of our deliverable, other software wallet projects (such as ZecWallet) did not provide support to this new app within the expected timeframe. In order to submit our app for review, it was necessary for someone in the ecosystem to integrate. For this reason, we had to put the submission on hold until there was a third party integration ready.

As expected, as time passed by, Ledger continued to upgrade their firmware. Zcash also evolved their protocol over time launching Orchard v5. This situation meant that Zondax’s application source code started to lag behind.

Worried about this situation and in coordination with the Zcash Foundation, we found a path forward and we agreed to work on the integration ourselves directly. While this was not part of our original commitment, it was a missing critical step to reaching final users and a requirement to start a submission to Ledger and get some closure.

As we came back on board, we recognized that the amount of bytes occupied by the Ledger firmware on the device had increased. There was less room for our app – to the point where it was no longer compatible with the Nano S. At the same time, Ledger had deprecated Nano S devices and stopped making them available to the general public. As part of the effort, we migrated and extended our code to support the newer Nano S+ and dropped support for the discotinued Nano S.

The application was back in shape. It was time for desktop wallet integration work! This time around, the plan was simple on paper: Allow Zecwallet Lite to use our application running in a Ledger Nano S+.

In reality, we faced several challenges when integrating our work. ZecWallet was not fully designed to be modularized in the way we expected. That meant refactoring a few pieces of the application to stop it from accessing in-memory secret data on the fly, and use a more restricted approach instead.

We set some intermediate tasks for the integration work, so we could track our progress. The first step was to retrieve addresses from a Ledger device. However, the next and most challenging step was that a “LightWalletD” node wasn’t able to sync. This was due to blocks using the new transaction format released as part of Orchard - network upgrade 5 (Nu5). Adding support for Nu5 at this stage would have required a major refactoring of the app.

That being said, it was impossible to “ignore” the Nu5 upgrade, even more so because Zecwallet had also been updated in the meantime. Integrating external changes into our fork would have meant scrapping almost all the integration work done so far.

Thanks to git cherry-pick, the team was able to partially upgrade the wallet, avoiding big changes that would invalidate the on-going integration work. This partial upgrade allowed us to sync properly with the chain and inspect the balance – a major milestone! It meant the wallet and Ledger could be used to view and verify balances finally!

The next logical step was to submit a transaction. We came up against a few issues involving outdated consensus branch IDs, signature personalization, and the unexpected concatenation of the verification key to the signed data. Thanks to the knowledge and perseverance of the team, we delivered a signed transaction that worked and could get accepted!

Not only that! It was possible to send transactions with both transparent and shielded inputs and outputs. It was time for the public demo! Ida and Francesco did an excellent job in demonstrating the complete working workflow in Las Vegas and we hope they could finally enjoy a good time as part of the ZEC community.

Following that success, what’s on the horizon for Zondax and ZEC?

The live demo showed a complete Zcash Ledger app integration with unshielded and shielded addresses in Zecwallet Lite. We are looking forward to collaborating with ZecWallet to merge our changes upstream and help the Foundation to initiate a submission to Ledger. Moreover, we are discussing further collaboration areas such as maintaining this project in the long term, adding Orchard support, and strengthening daily interaction with different stakeholders in the Zcash ecosystem.

Interested in learning more about our innovative blockchain services and discussing opportunities? Let’s connect today!

At the end of our session at Zcon3, Francesco Dainese answered a handful of audience questions.

Q: Can everything be done with the Zecwallet Lite CLI?

A: Yes, because of the way Zecwallet is organized. There’s a library containing the logic, and then there’s the CLI executable, and in a separate repo, the GUI. Most of the changes are in the library, so they can be used by both the CLI and any other users of the library. We’ve also made a couple of changes in the GUI to use this new functionality and improve UX.

Q: What would you need to do to support Nano X through Bluetooth for mobile devices?

A: The way Ledger works, Bluetooth is somewhat transparent to the app logic itself, so in a way it’s already supported. The issue is that Nano X doesn’t allow app sideloading, so we can’t test it with a real device. We’d need to use the emulator, which isn’t Bluetooth, defeating the purpose of the test.

Q: Can the host be something else like ZCashD or a mobile wallet, or is there something special about Zecwallet Lite?

A: We haven’t investigated it, since our work focused on Zecwallet, but it would definitely be possible. The hardest part is gluing together the flow of the app with your desired host, which requires the right code in the right places. However, as we explained above, the transaction flow isn’t complicated when you use the app – all you need to do is follow the steps.

Q: Is there a timeline for Orchard transaction support, using the same sort of architecture and framework?

A: The short answer is not yet, but it’s something we’d like to investigate. In terms of using the same framework, it’s definitely in the realm of possibilities, given our understanding of the protocol and how the Ledger app works.