Hi everyone, another ECC update on the work we’re doing. Tl;dr is we’ve identified and fixed the last known bugs that were blocking the first phase of SDK releases, we’re continuing to make good progress on DAGsync, and we’re prepping both zcashd and mobile wallets for ZIP 317.
Update:
Squashed the last known librustzcash bugs that were blocking wallet release and completed Android & IOS SDK integration.
Made good progress on the groundwork for DAGSync in the mobile SDKs.
Completed the implementation of zcashd optimizations expected to save memory and to reduce orphan rates for miners. We’re testing now and will included the updates in zcashd release 5.3.1.
Working on abstractions to support ZIP 317 (Proportional Transfer Fee Mechanism) in the mobile wallets.
Nearing completion on making zcashd have a single way of constructing transactions, rather than 4 different approaches. This will also support ZIP 317 changes.
Continuing to make progress on recursion for Halo 2, a fundamental building block for future scalability solutions
Thanks again for your time and patience during this time. If there are any questions, please post them below and our team will answer them. You can also reach out to me directly.
What does the ECC team think about putting a EIP-1559 style non-discretionary, algorithmic fee mechanism in place as one of the next top priorities? In my mind, there’s some big things to work on - retiring old pools, posterity fund, POS, fee mechanisms. It seems like 1559/posterity fund (or perhaps Sustainability Fund since posterity is a fancier word less people might recognize and brings up images of “old” or “aged” while sustainability brings up images of “green” or “solar punk” in my mind ) might be good to do in one fell swoop. The earlier we institute a posterity fund, the more ZEC will start accumulating in it for rainy days, and the also the sooner a future proof, non-discretionary fee mechanism is put in place, the less developers would have to later tinker with different fee mechanisms, sooner we could get an organic revenue source for posterity fund, etc.
As an aside, it would be very interesting to do a model of how much txn fees there would be under a 1559 style thing given current and past network loads - similar to how a comparison was done with current fees versus 317.
I remember @Souptacular said there was a certain economist who did some great modeling for 1559 for ETH - what was their name Hudson?
There’s a lot here (which is great!), so I’ll do inline replies.
We haven’t explicitly put this item on the roadmap, but I think it’s a prime candidate for ECC’s efforts on our Late 2023 roadmap goal. The current work on ZIP-317 which is being spearheaded by @NighthawkApps w/ some support from ECC is a step towards improving fees so that they are proportional to the costs imposed on the network. However, that ZIP just sets a hard coded “fee schedule”, which means it may be too high or too low, depending on usage and demand for transactions. Some kind of dynamically adjusting fees are necessary to maximize usage of the network, and some examples would be a Bitcoin-style fee market or an algorithmic thing similar to EIP-1559. I’m in favor of the latter for several reasons, especially because I think it’s easier for users to understand, simpler for wallet logic, and better for privacy vs a BTC-style fee market.
Yes, these are all “goals of interest” for me. However, I don’t think ECC could design and implement those all in the 2023 milestone, while I also think we can/should do some prior to others. Also, at ECC we need to anticipate the effort and coordination it might take to integrate other changes to the protocol from across different teams (for example Qedit’s ZSA work). So any discussion of “the roadmap” needs to anticipate multiple teams showing up with their preferred roadmaps and timelines.
While the features you mention are all inter-related and might make a good “package”, my opinion is it’s better to ship features as soon as feasible in smaller upgrades for multiple reasons. One is to make each upgrade (relatively) simpler than a “big bundle upgrade” for safety and engineering reasons. The other is to get features out as quickly as possible to learn from how they perform in the market. PoS is probably the biggest / thorniest one there that I doubt would be done by end of 2023. In the ECC’s recently published 30-year vision notice we are aiming for a PoS transition by 2025, should the Zcash users accept that kind of transition.
I like your suggestion of rebranding Posterity Fund! It’s a name I just picked, and I agree it sounds a bit “old fashioned”. (I personally thought old-fashioned retro was kind of cool, but I’m totally not a marketer. ) “Sustainability” sounds both more contemporary but also seems easier to understand to me.
It looks like the total fees over all time thus far is between 3500 and 4000 ZEC.
Another interesting analysis is what would fees be if the network started with an EIP-1559-like change, if you assume the exact same transaction load. I believe it may be similar or lower, since when blocks are less than half full (or some similar rule) the network fee falls. In real life, though, if fees approach 0 it might change how people would use txns, so it’s not safe to assume that the transaction load would be the same.
Finally, while all these changes seem important, at ECC we’re focused in the immediate term on getting shielded wallet performance & usability back to a better state with the current load, and then a prime candidate for the 2023 target which may be important than the stuff in this post is making shielded wallet perf & UX work much better for even higher txns loads. We’ll have to figure out how to balance that goal against some of the ideas we’re discussing here.
Hey everyone, Ian here from ECC. It’s been a few weeks since my last post, so I wanted to provide everyone an update on the work ECC is doing to mitigate performance issues related to the ECC wallet SDKs.
This remains our top priority and focus as a company. We continue to have a cross-functional team working on these issues.
ECC updates:
We’ve integrated diverging rust libraries to ensure all new performance improvements and bug fixes are deployed consistently across the iOS and Android mobile SDKs as well as zcashd. This will help ensure users, which rely on our mobile SDK or zcashd wallet, will receive upcoming performance improvements with better quality assurances, and more promptly.
We’re modifying the wallet SDK architecture to enable performance improvements to scanning and syncing moving forward. This will enable a variety of upcoming improvements to the robustness of syncing a mobile wallet, including recovering when interrupted, improving the syncing protocol to greatly reduce sync time, and lowering mobile device storage requirements while syncing.
We’ve completed the implementation of zcashd optimizations expected to save memory and to reduce orphan rates for miners. This ensures the main network nodes operate robustly under the increased load which supports all Zcash wallet users.
Working on abstractions to support ZIP 317 (Proportional Transfer Fee Mechanism) in the mobile wallets. This upcoming change to the fee system will reduce the amount of low-value transactions which make up the bulk of the current load, which will further alleviate syncing issues for shielded wallet users.
Continuing to work on recursion for Halo 2. While this does not address the current performance issues, it sets the stage for longer term consensus protocol improvements to scalability down the road.
Thank you all for your time and patience. As mentioned previously, if there are any questions, please post them below and our team will answer them. You can also reach out to me directly.
Is there a way to default to or instruct about good privacy hygiene for shielding transactions and unshielding transactions within the mobile wallets?
Shielded to Shielded is optimal for privacy, and that is what we are working toward. But in the interim transition, there will be many shielding and unshielding transactions, and we may as well help those users as best we can.
A master tab with a short policy primer about privacy hygiene, shielded transactions, shielding and unshielding transactions, and why it’s important to follow some simple rules like:
Let them know that difference between shielding transactions, unshielding transactions, and why z to z is the optimal transaction for privacy.
If they need to do an unshielding z to t because the party they are interacting with will only accept from a t address, leave a significant amount of time between shielding and unshielding transactions, and think of your shielding address like a bank account where you keep money for an amount of time that you may want to unshield later
need to make sure that you unshield to a different t address from the t address of your shielding transaction.
need to make sure that the amounts of unshielding transactions are randomly different from prior shielding transactions.
And/or can we add features to the mobile wallets like:
enabled to create new t addresses for every unshielding transaction by default.
enabled to warn a user if a prior shielding transaction is (less the shielding transaction fee) for the same or similar amount as the unshielding transaction? And give them a prompt for that unshields for them in multiple transactions to multiple t addresses over a short period of time in random amounts.
I may be way off in my specific suggestions, but my general point is how can wallet design help newbie users from making rookie mistakes as they conduct shielding transactions and unshielding transactions?
Samourai Wallet does a good job of protecting the low information user from themselves, I hope we are learning what we can from that design.
I am looking forward to the next ECC update from @januszgrze
Meanwhile, I can provide the updates shared in the @LightCli_WG meetings, the DAGSync is a series of developments in the works. The changes are expected in zcashd and lightwalletd adapter software and need subsequent testing and review on test-net. Then the librustzcash modifications to include the updated syncing mechanism to play with the lightwalletd adapter layer, and ultimately the changes in the SDK and client apps to integrate with the new workflows.
The SDK and client apps will see a series of updates to improve the overall performance of syncing, the rollout of which has already started.
Regarding DAGSync, mentioned by @aiyadt it is a series of updates to zcashd, lightwalletd and finally the mobile SDKs. The initial piece we are working on is making funds available as quickly as possible upon opening a wallet. The second piece is moving away from a linear-style sync where every block must be downloaded and processed to a selective non-linear sync (the DAG “graph” component). The combination of these approaches will result in faster sync times and faster availability of funds across any of the apps that leverage the SDK.
Thanks David! We appreciate the kind words! All the functional areas within ECC are focusing on this problem and working as hard as we can to continue to make improvements.
Hi, everyone. We’re making progress on Zcash wallet performance issues. Here’s the update.
TL;DR
ECC is still on track to deliver a set of product releases by May 31 that will resolve Zcash wallet performance issues.
Zcashd 5.5.0 will be released on or around April 17.
Code dependencies have pushed the fund availability improvement (originally slated for 5.5.0) to 5.6.0, but this does not affect the overall timeline for exiting “Emergency Mode.”
Two weeks ago, we updated the community on our progress with regard to fixing wallet syncing issues that are affecting users of third-party apps Edge, Nighthawk, and Unstoppable. We said our goal was to exit “Emergency Mode” by May 31, and — good news — we are still on track.
On or around April 17, ECC will release zcashd 5.5.0. This contains infrastructure improvements (that lay the groundwork for 5.6.0) and the completed transaction-fee-structure change (ZIP 317), which will be enabled when wallets are working normally again.
The 5.5.0 release will not have an immediate, noticeable impact on normal user experience, but it’s an important milestone and narrows ECC’s focus on the remaining pieces that will restore good user experience in the impacted apps and allow users to quickly access and spend their funds.
As mentioned in previous communications, the solution comprises changes to every component in the shielded mobile wallet stack: zcashd, lightwalletd, the ECC wallet SDKs, and the ECC prototype wallet.
Dont know about that link of yours but some mobile wallets already attempt to instruct or enforce good hygiene to some degree. When unshielding you’ll typically be notified prior to the send of the tx’s sub-optimal privacy policy
It is always important for the community to have orientations for future updates. It’s like a vacation - knowing that it’s coming gives us the joy of waiting.
Thanks for this link and for raising the good point about how the NUP resources seem to be abandoned (or at minimum, out-of-date). I’m intrigued by the bottom of the NUP 2.0 ECC page because it identifies that a Network Upgrade #6 would be coming in 2022. Can we hear an update about that projection from the ECC team? What are the NU6 target features?
Thanks for highlighting these resources and confusion about the Network Upgrade Pipeline. At ECC, because we are focused on improving shielded wallet performance as an urgent top priority, we postponed non-related protocol upgrade processes and work.
We could have communicated more clearly about this, and we intend to rectify that moving forward.
We removed the associated timeline chart from https://z.cash because it is not up-to-date and wanted to reduce misleading information. The Time.Graphics Embed Timeline link is stale and not updated. We will see if we can remove it.
Generally, however, we believe this episode shows that the NUP 2.0 is too reliant on ECC as a single point of failure. We’d like to see more collaboration and ownership of the network upgrade process across development orgs working on protocol improvements or implementations. To that end, we intend to engage multiple orgs to iterate on, improve, or replace the NUP 2.0 with a community-lead process.
We will determine what next step we can take on this effort after the release of Zcashd 5.5.0 (April 17), and we’ll keep our eyes/ears open if any other dev orgs are coordinating on network upgrade improvements.
Related, but distinct from the upgrade process, we’ll also be resuming our protocol research and posts around Proof-of-Stake and cross-chain interoperability after we’ve delivered SDK improvements to shielded wallet performance as described in the mini-roadmap above.
Does zcash 5.5.0 include the part of zip317 that brings the minimum fee from 1000 up to 10000? If so, mobile wallets sending regular single recipient transactions will be affected by that change.
) might be good to do in one fell swoop. The earlier we institute a posterity fund, the more ZEC will start accumulating in it for rainy days, and the also the sooner a future proof, non-discretionary fee mechanism is put in place, the less developers would have to later tinker with different fee mechanisms, sooner we could get an organic revenue source for posterity fund, etc.
) “Sustainability” sounds both more contemporary but also seems easier to understand to me.
