Zcash Remote Nodes for Mobile Wallets


#1

Unlike Monero, Zcash does not currently allow for a separation of the wallet and the node. If you’re not familiar with how this “remote node” concept works in Monero, there are many guides that explain the concept and provide instruction for running your own publicly available node or for connecting to an existing remote node. Here’s one such guide: https://coinguides.org/remote-nodes-monero-wallet-gui-cli/

This is a very convenient feature that is used all the time, and even beginners can easily operate a remote node.

Why is this split architecture useful? Because you are separating the wallet (monero-cli), which has minimal storage and compute requirements, from the node (monerod), which has very serious compute and storage requirements. You are not escaping any bandwidth requirements, so this arrangement will not work well (or at all) for users in any region which does not have excellent network infrastructure. But you are creating possibilities for access that weren’t there before, and you’re especially making it possible to build a proper mobile wallet. This is because you can ensure:

  1. The user’s keys are generated on the user’s hardware, and never have to leave that hardware

And importantly:
2. The user does not necessarily have to operate their own node. The requirement to run your own node is a serious roadblock to adoption. A third party or company can operate a “default” remote node, with minimal capability to observe the user’s transactions. As users become more sophisticated, they will learn to operate their own node. In fact, it’s not always sophistication, it’s a need- in the world of Monero users who need to recover their mobile wallet (when they use a proper wallet) often must restore their balance with a full node, then send their funds back to their mobile wallet, rather than restore directly on the mobile wallet.

Before Sapling, it was not even possible to consider creating a Zcash mobile wallet, as the compute resources required to sign transactions far exceeded even what was available in top-end flagship smartphones. Now it’s possible, but because of the “monolithic” architecture inherited from Bitcoin, mobile wallet development is moving about as fast as molasses in wintertime.

Does anyone know if there is any progress being made towards a split-architecture ala monero, or some other initiative which would allow developers to achieve the same ends?


#2

https://github.com/gtank/zips/blob/light_payment_detection/zip-XXX-light-payment-detection.rstttps://github.com/str4d/librustzcash/tree/note-detection


From

And

From
https://lists.zfnd.org/pipermail/general/attachments/20190119/01f78b0d/attachment-0001.html
Hope this helps ’ )


#3

I’m aware of these projects, as well as https://github.com/str4d/librustzcash/tree/note-detection. What is the difference between these?

These also seem very early stage. I would expect something like a maintained/documented library (including a README.md); something which provides a JSON-RPC or exposes an API.

Is there anything which is currently available or will be available soon?


#4

Most of what is linked above is components being generated by the reference wallet project. zqwandroid is a separate project which I believe is just an Android front-end for the zec-qt-wallet desktop wallet.

Yep, the reference wallet libraries are still in-progress, but the end goal is to have a documented library that provides APIs for use in light clients and wallets. The in-progress code is accessible, but the client-side library in particular should not be relied on for production code before it is merged into https://github.com/zcash/librustzcash

There are no currently-available production libraries for shielded mobile wallets. The blocker has been the need to write almost the entire necessary codebase from scratch (which is what I and several others have spent a chunk of the last six months working on, in parallel with the development of Sapling itself). Hopefully the various components will be in a more usable state in the next few months.


#5

Ok that makes sense, that’s a heavy task. Will these libraries be receiving the “official” blessing and be knighted alongside the official Debian binary? I assume they will be synchronized with all future releases in order to ensure address type compatibility etc.


#6

There was a project called Pyzcto by Miguel Marco that allows you to run a full Node, run Pyzcto on your desktop to issue commands to the Node, and connect via Tor to the Pyzcto app via an Android app called Pannel.

He was working on it but stopped awhile back due to a lack of time/help from the community.


#7

I have heard someone is working on a similar project. The problem with this approach is you assume the user is running their own full node. This is a sort of “remote control” to your full node, which might be interesting for a small group of experienced existing users.

Most users are not sophisticated or motivated enough to do this; they expect to download a mobile app from the app store and then withdraw their funds from the exchange (not your keys, not your coins rings true for not technical people too) to their smartphone, where it’s easier to manage small amounts.


#8

Agreed. Lite clients are a tough nut to crack, hopefully the upcoming reference wallet will help push wallet developers in the right direction.