All ECC teams focused on wallet performance

Sounds great! I’m not a very technical person when it comes to this stuff, but how does the syncing algo ECC is working on compare to warp sync that is used by Ywallet?

And a follow up, would the warp sync integration proposed by @hanh in his recent Ywallet grant proposal (forgive me I don’t have the link here) aid ECC’s efforts at faster syncing?

Thanks I’m advance!

3 Likes

Why not hire more people?

2 Likes

We recognized SDK sync time was subpar even prior to the increased load which is why we had an improved sync in the roadmap. (as mentioned above we moved it up in priority)

You’re correct, there will be three different implementations of improved sync algorithms which is fine IMO. I’m not a first-hand user of Ywallet or ZecWallet Lite beyond limited testing but it is my understanding that each performs well in different circumstances depending on the shape of a given transaction load.

3 Likes

We looked at warp sync in details when we began working on an improved sync in earnest which was shortly after we packaged zcashd 5.2.0 for release. We determined then that the shortest path to an improved sync would be our own phased implementation to improve both the SDKs and the underlying librustzcash layer.

3 Likes

Thanks Steven, good luck!

1 Like

I’m definetly no expert but I think ECCs version is called DAGSync? Benchmarking is yet to be done for DAGSync AFAIK.

My understanding is at a high level DAGSync prioritises using your previously known spendable funds (i.e. notes) and trying to invalidate them (i.e. nullifiers). If no nullifier is found for a given note a few extra steps happen and those portion of funds are spendable.

Imagine that I’m in line at a coffee shop, I see they accept ZEC, and I pull out my wallet that I haven’t used in a month. I don’t actually care about being able to spend my entire balance. What matters to me, in that moment, is that I can spend enough funds to pay for a coffee.

WarpSync’s goal is to make all your funds (i.e. notes) spendable ASAP.

A typical mobile wallet user might benefit from DAGSync while an exchange or service or store might benefit more from WarpSync.

1 Like

We definitively need to do some profiling when DAGsync is ready. I think Warpsync will perform well in this scenario too.

Emphasis mine

1 Like

From the previous benchmarks you’ve provided it’s hard to disagree. I suspect both methods would be fast in the given example. We will soon find out I guess :slightly_smiling_face:.

Not solely that; what it does is find the shortest path from “current wallet state” to “spendable wallet state”. That may be by finding existing notes that are spent, and jumping ahead through the DAG, before updating any witnesses; or it may be by updating the witnesses for those existing notes, and then speculatively attempting to spend them (which could result in a double-spend). Both steps need to happen to establish for certain that a note is spendable, but they can happen independently, and give potentially tunable UX trade-offs and benefits.

Yeah, in the steady state mode (syncing a wallet that was last up-to-date in the last few days or weeks) I don’t think there will be too much difference (DAGSync includes improvements to the way witnesses are managed and updated that may be faster than what Warpsync currently does, but those can be pretty easily adapted). The biggest benefit that DAGSync provides (due to its fundamentally different design) is in recovery from backup, and the design should also help improve performance in the scenario where you have the same mnemonic phrase imported into two different wallets (so notes in a wallet can be spent while the wallet is offline).

3 Likes

Do you mean the case where you recover from backup seed and want your wallet to look for a recent note that you can spend right away?

1 Like

I had a question about how Warp Sync approaches the “make your notes spendable right away” issue. In order to spend a shielded note, you have to choose an anchor in the note commitment tree, and preferably your choice of anchor should be recent enough (say within the last 10 blocks) to reveal no information about the age of the note you’re spending.

The intention that I have is that, in conjunction with the DAG Sync changes, that the lightwalletd protocol will be modified to provide a cache of high-level nodes in the note commitment tree that can be used to produce current anchors for old notes, such that only ~2^16 notes in the vicinity of the note that you want to spend (along with the most recent 2^16 notes) will need to be added to subtrees of the note commitment tree in order to make it possible to spend your note. How does Warp Sync approach this today?

1 Like

Hi Chris, Ywallet current approach to “make your notes spendable right away” is to skip trial decryption for transactions that would have cost too much to spend under a progressive fee structure.
The idea is that I know people who send me zec would not pay more than X in fees.
I suggested pushing a fee filter to lightwalletd so that the wallet would not have to download epk & ciphertext but at the moment, the filter is only client-side.

Lightwallets must balance 3 resources: CPU, Memory, and Network bandwidth.
Of all three, IMO, Network is the biggest issue currently. In the last 2 months alone, the blockchain grew from ~1GB to ~5GB and 4GB is too expensive on most mobile phone data plans.
Next comes memory. Many phones have <3 GB of RAM. Therefore, caching is limited for them. Since I think redownloading and caching aren’t practical for many users, I chose to make WarpSync strictly streaming.

Finally, it’s CPU. Besides trial decryption, which we can skip for 99% of the notes, the heaviest calculation is witness maintenance. For this, roughly speaking, WarpSync combines all the note commitment updates in a pass. So that whether you have 100 notes or 0, the CPU cost is about the same (= the cost to update the tree_state). Because all the hashes needed for the updated witnesses were calculated at one point during the tree update. We just need to pick them up.

9 Likes

Hi everyone,

As mentioned previously, fixing performance issues is ECC’s number 1 priority at the moment, and we have a cross-departmental team — including engineering, partner engagement and support, product marketing, and comms — focused on it. Here’s an update.

  • 5.1.0 and 5.2.0 have largely addressed performance issues for full nodes
  • End user wallet sync remains an issue
  • Priority remains faster sync for mobile SDKs
  • Team is also researching possible fee change mechanisms
  • Team is also evaluating longer-term scalability options consistent with our scalability road map

As mentioned before, feel free to DM me, or comment below, with any questions.

Ian

7 Likes

Are you in communications with @hanh he has demonstrated himself as a solutions person.

YWallet has been a life-vest for hundreds of Zcash wallet end-users with sync trapped ZEC funds

2 Likes

Yes, we’ve both spoken with Hanh (async) and reviewed the faster sync algorithm he uses in Ywallet.

3 Likes

Hi @steven-ecc , you may have been talking with someone who impersonated me because the only communication I remember is in this thread.

2 Likes

I believe I was remembering the conversation in this thread but I thought there were others as well but may have been mistaken.

My point to the prior question was that we looked at your fast sync algorithm as well as the one in ZecWallet and elected to implement our own as I’ve mentioned elsewhere.

2 Likes

Hi everyone,

Here’s an ongoing update on the work ECC is doing around wallet performance and SDKs. As mentioned previously, people’s experience with ZEC has been suboptimal, and ECC has a cross-functional team focused on improving ZEC UX.

  • Our priority remains mitigating the impact of the increased shielded transaction load across zcashd and the mobile SDKs
    • A number of team members are working directly on an improved mobile sync experience which we hope to rollout the initial phase this sprint
  • We have made performance improvements to transaction verification times, block propagation times, and zcashd full node wallet scan performance
  • We’re surveying the ecosystem to understand the effects of 5.1.0 and 5.2.0 and identify any remaining performance-related issues
    • Due to increased memory usage during sync, some users have experienced OOM conditions which we are investigating and have identified one potential solution
  • We are also evaluating the ZIP 317 fee change proposal, analyzing historical transaction profiles, and modeling potential fee changes to assess impact

At a high level, this means that the team is seeing progress and we should be releasing improvements to our mobile wallet SDKs in the next couple of weeks which will positively impact end-users’ experience. Overall performance improvements are something that will be ongoing, but mobile wallet users can expect better syncing performance after the next versions of the mobile SDKs are released.

Also, we’d like to thank Hanh and his work with Ywallet, which has provided many Zcash users with a consistent user experience during this time. We were pleased to see his recent grant funded by ZCG, and look forward to Ywallet’s future progress and contributions to Zcash.

As mentioned before, feel free to DM me, or comment below, with any questions.

Ian

17 Likes

Hi everyone,

Firstly, I want to thank everyone for their patience during this time. The team is working through the issues to get mobile wallets working to the standard users expect. These issues are complex, but our team is confident in the improvements that have been made and those that are in progress both for the wallet SDKs and the zcashd node.

Here are updates from our engineering teams:

  • Continued the back-end work required to support the next release of the IOS and Android SDKs which will include the first phase of an improved sync capability

  • Fixed a number of intermittent out-of-memory issues that were introduced by the batch scanning optimizations which will be included in zcashd release 5.3.0.

  • Built a number of dashboards analyzing historical transaction data which we are using in our analysis of the proposed fee change mechanism in ZIP 317.

@Daira also provided an update in another thread: Zcash's current performance issues are frustrating - #60 by daira

Thank you all for your patience during this time. Please reach out with any questions.

Ian

12 Likes

Just compiled latest zcashd master, Huge improvement. Excited :zebra:

6 Likes