Zecwallet Lightclient Protocol Research and Development

Community Grants Applications
21

I don’t think you are properly assessing the heavy lifting the SDKs do.

Multiplatform UI frameworks should build plugins interfacing the native SDKs. It’s the proper separation of concerns that minimizes the amount of re-work. To even use the rust crates directly, there’s a huge deal of protocol knowledge that you have to digest that would make it impossible to chew up for an outsider than only wants to integrate to a coin.

I think that Monero’s Cake Wallet has an interesting approach to a Flutter solution. Yet, there’s still a problem with having to deal with the wallet2_api.h interface that exposes a Light Wallet API from the monero codebase.

If you ask me, I’ll say that’s better to have people dedicated to what they do best. There’s room for everyone in this bus, and the only certainty we have is that there’s No Silver Bullet

1 Like
22

I don’t think you read what I wrote. I am not saying that using the rust crate directly is the ideal situation.

23

I’m pretty sure that I’m not quite following you. Sorry. I apologize. :slight_smile:

If you are currently working on the third diagram up there. I don’t know what the capabilities of the React Native FFI are. You’ll probably have to redo all the compact block processing and synchronizer logic somehow on typescript. That’s quite a lot of work, not only you will have to mimic that logic, it will probably change over time (hopefully soon, I don’t like the way iOS ended up syncing tbh) and you will have to catch up with that as well.

24

Yes, it’s tedious and I’d gladly use a package IF it was integrated with an app framework.

In my opinion, native packages that require the user to maintain two code bases have to be very special in order to justify this burden.

Otherwise, either:

  • provide an integration package that wraps the native library into an app framework, (GOOD)
  • or app developers will re-implement the logic in their client code (BAD)

React Native FFI is not very easy but Flutter FFI is better. It is roughly on the same level as JNI but also support iOS. Once you integrate it with a makefile, bindings are auto generated.

Well, that’s another reason to have it at a lower level than android/ios packages. You have different logic for ios and will end up replacing both. I think anything related to consensus should be in librustzcash. Then wrapped in various integration packages all the way to app framework - don’t stop at android/ios native.

PS: including js - no web support for lightwallet currently

25

Hi, is securing the app with PIN/biometrics on the roadmap?

1 Like
26

There are some interesting product discussions on local PINs. Which is the question of how many people will be affected by it for every person that benefitted from having a PIN. that’s the ration

people secured by pin / people locked out of their wallet by pin

also, there a very insightful request on ECC Wallet’s repository asking to remove biometrics approval to send funds

1 Like
27

I agree to an extent, but a phone is so many things these days, do you really want someone to have full access to all of your apps when you hand the phone to them? Absolutely not, Signal, Telegram, my banking app are all protected by PIN/biometrics, with good reason.

In the example given, I would like to explicitly give someone (my son in the example) permission to pay for something, I would do that by opening the wallet app and authenticating and then give the phone to him. I would see this as the equivalent of handing my physical wallet to my son, no need for further authentication after that.

But then we’re also protected not necessarily from attackers (low risk), but from prying eyes, I value my privacy, what if my friend asks to make a call on my phone, I’d rather not have him see my zec balance, or my signal messages etc.

It might also open up the possibility of having a duress PIN that unlocks a lower value wallet.

And if you get locked out of your wallet and haven’t backed up your seed phrase… tough luck, back it up next time.

28

I agree with what you are saying

Except for the ‘tough luck’ part. ^-^ It’s not a viable argument for products that are aiming to be massively adopted.

1 Like
29

Maybe that was a bit harsh, but in applications where we are trying to eliminate trusted third parties,c and saying that people can “be their own bank”, people really need to be taking more personal responsibility. I know people are too used to just contacting their service provider to ask them to reset their password, so they would be expecting similar here.

So maybe the UI emphasises (strongly) that they should back up their seed, and then enabling PIN/biometrics is an optional setting, and if they opt to turn it on there are further prominent warnings that their funds will be at risk if they forget their PIN/lose their finger/seed phrase.

I’d be interested in hearing about other solutions, maybe some sort of cloud backup option that also informs the user that they will be trading some security for convenience. There are no easy answers it seems!

30

We have reached the first checkpoint milestone for this grant.

During this initial phase, Zecwallet has mainly focused on (1) Improving infra and (2) Improving sync speed. So far, we have shipped:

  1. Fast Sync - Eliminates the startup sync for new wallets, so new users can start using wallets instantly.
  2. Price feeds into LightwalletD that fetch accurate historical prices (and accurate current prices)
  3. BlazeSync - Improves sync speed by >5x, allowing the entire blockchain to be synced in <60 seconds
  4. Infra: Unify LightwalletD, automated builds and published zcashd builds for MacOS, Linux and Windows

More details can be found in our regular updates:

In terms of progress against the specific deliverables I listed in my original post (above) that accompanied the grant application, here’s a breakdown of the progress we’ve made so far:

image
image2286×1544 407 KB

6 Likes
31

Moved Blazesync specific discussion to the existing topic: Zecwallet’s BlazeSync: Sync entire chain in < 60s!

32

Thanks Aditya, this is great!

How are you planning to apply for Milestone 3 and 4 payouts? I.e. will you have a target subset of tasks you expect to be done at each Milestone (not yet indicated in the spreadsheet), or do you plan to just work on tasks as they pop up and apply for a Milestone payout when it feels like you’ve done a % of work commensurate with the size of the Milestone payout?

3 Likes
34

I’m planning to do the later. The milestones are roughly goal based as shown in the spreadsheet (1: DevOps focused, 2: Protocol focused), and I’m planning to apply for them every ~2 months apart, which should be 25% of the work.

Also note that there are items in there that were not originally planned (BlazeSync for example, was not in the original plan, but we discovered it would be very valuable to improve sync speed) which might displace some of the items in the spreadsheet.

Note that there are a lot of internal dependencies between the tasks, so it’s not as straightforward as working through the spreadsheet items one-by-one, but my goal remains to get most of the items done by Oct 2021 as originally planned.

2 Likes
35

Alright. Cool. Thanks!

3 Likes
36

@adityapk00 when you do these updates in the future, would you mind also posting a link to the update on this thread? It helps the zomg keep track without having to scour the forum :slight_smile:

2 Likes
37

Zecwallet testing update

One of the big parts of the infra work for this grant was to build a robust testing framework to makes sure that Zecwallet continues to work without regressions as we add features and new zcash features.

Inspired by ECC’s “DarksideWalletD”, Zecwallet has built a client-side equivalent of that. It is a in-memory rust implementation of a LightwalletD server (Essentially a mock), that can serve the LightwalletD API over gRPC. It has the following features:

  • Serve real, fake or random data as the test requires
  • Consistent internal state even with fake or random data, so API calls like gettransaction or getsaplingtree return the correct values.
  • Controllable simulated latency or injectable errors
  • Fully controllable internal state, including intercepting sent transactions, mempool and blocks.

This allows all kinds of tests - unit tests, integration tests and end-to-end tests to be written against the actual Zecwallet code, that allows us to test all kinds of edge cases as well, including rollbacks & reorgs, expired transactions, mempool transactions etc…

Check out the code here. Tests that use this are here. This is a WIP, and will expand as we add more tests.

This testing will consolidate and replace items 6,7,8 and 10 in the Infra tasks list. Doing it this way is a bit more work, but will make the tests more robust and repeatable, allowing full integration and end-to-end tests for desktop and mobile wallets, including benchmarks and regression testing to be performed easily.

Writing the framework and the tests took most of the last 2 weeks. Starting this week, we’ll return to regular feature work, starting with mempool and incoming tx notifications, which should come next week.

5 Likes
38

Can it serve simulated accounts with a given profile? For example, a simulated address that has 100 received notes unspent since activation, or one that has 1000 of transactions, etc.

39

Mempool Transactions

Zecwallet Lite now supports instant notifications of incoming transactions by scanning the mempool! This is available in v1.7.2, which is downloadable from www.zecwallet.co or from the iOS App store or Play App store

Efficiently scanning the mempool

Zecwallet implements mempool scanning via a new LightwalletD API that streams transactions in the mempool to the client, where they are scanned to see if they belong to the wallet.

Up until now, fetching mempool transactions was very inefficient, especially on the battery, since it effectively required polling LightwalletD for new transactions every few seconds.

The new LightwalletD API uses a long-lived stream (which is a gRPC feature) that keeps a persistent, low-power stream open to the LightwalletD server. As soon as LightwalletD sees a new transaction in the mempool, it streams it to the client, which then scans it.

  • This is very battery efficient, allowing the Wifi/Cellular Radio to operate in low-power mode
  • It is efficient, since there is no duplication of data, no polling and no waking up the CPU/Radio every few seconds
  • It allows the transactions to be scanned as soon as they are in the mempool, updating Zecwallet near-instant.
  • A great side effect of this API is that it allows the client to monitor when new blocks are mined. This means that the wallet is always up-to-date with the zcash chain.

Next Steps

This new mempool API allows the wallet to keep up-to-date with the chain tip much more efficiently, which will allow Zecwallet to detect reorgs early. This will, in turn allow more recent funds to be spent - i.e., You won’t have to wait for confirmations to spend your funds anymore. The next version of Zecwallet will allow spending funds with just 1 confirmation.

11 Likes
40

Great work @adityapk00, I was looking forward for this feature.

Have you done any stress tests on mempool size and how it might affect the light client(mobile memory) as the mempool grows?

41

Send Funds with only 1 confirmation

With Zecwallet v1.7.3, which is now available on www.zecwallet.co and on the app stores, Zecwallet now requires just 1 confirmation to spend funds. So you can now spend funds, usually within 1 minute of receiving them.

Why we need confirmations

Up until now, Zecwallet required 5 confirmations before funds could be spent. This is a significant irritant to new users of Zcash, because it makes for an awkward ~5 minute wait before funds can be spent.

When wallets construct shielded transactions, they need to pick an “anchor block”. The problem is that if this anchor block gets re-orged, the transactions becomes invalid. So, to be on the safe side, Zecwallet used to pick an anchor block 5 blocks deep, to reduce the risk of reorgs.

Re-org risk

Light wallets can sometimes be behind the zcash blockchain tip because:

  • LightwalletD polls zcashd at 20 second intervals, so LightwalletD can be 20s behind
  • Wallets poll LightwalletD at regular intervals, so they can be further behind.
  • 1-block reorgs were not detected, neither by LightwalletD nor by the wallet, so the reorg is not detected until the next block, which can be several minutes later.

A combination of these factors can make it possible for the wallet to be several minutes behind the chain tip.

Simply decreasing the polling intervals is not a great option, because it can drain the phone’s battery, increase network usage and lightwalletD resource usage.

Solution

The recent work done on Mempool APIs on LightwalletD makes it very efficient to detect new blocks. In addition, new PRs submitted by Zecwallet to LightwalletD mempool PR and block hash detection allows wallet to now detect reorgs as soon as they happen, significantly reducing the risk that the anchor block picked by the wallet will be reorged. Especially, detecting 1-block reorgs significantly improves the reliability of the picking recent anchor blocks.

Of course, just as before, there is always a risk that the block will be reorg’d, so if you are sending / receiving large funds, please wait for a few confirmations before treating the Tx as final.

5 Likes