We at Edge have full intent to support the updated SDKs that improve performance and stability. As maintainers of the react-native-zcash repo/library with RN bindings, we will keep the repo updated for Edge and other react native focused projects incorporating Zcash. We look forward to the updates bringing zcash usability to the masses.
To follow up Nick’s post from yesterday, ECC’s restructuring operations created a small impact on the overall delivery schedule for the remaining “Emergency Mode” functionality. The release timeline below includes those updates.
In addition to what is listed, we also completed a quiet SDK update release, which included block download and scanning parallelization features. This is part of our continuing Emergency Mode efforts to address functionality and feature challenges within the software. The end result of releasing this functionality is a much improved linear scan capability ahead of the zcashd 5.6.0 release, which will enable the DAGSync algorithm and fund availability.
We are also actively engaged with our third-party wallet development partners as we reach critical milestones. This ensures a two-way communication channel while minimizing the wait for end users to see new features realized in their favorite wallet product.
With the updated timeline below, we are expecting a release candidate for zcashd 5.6.0 in the week of June 5, with the stable release a week later. The updated lightwalletd and SDK versions will follow the same timeframe, coming during the week of June 12.
The release candidate for zcashd 5.6.0 was cut yesterday and final QA is underway, with the intent to deliver the updated version next week. Full node operators can access the code for testing at Release v5.6.0-rc1 · zcash/zcash · GitHub.
As outlined in a recent blog post, ECC is in the process of transitioning to a narrowed focus on proof-of-stake ZEC, a mobile SDK and accompanying wallet, and US-based policy work.
ECC released zcashd 5.6.0 today, a key piece to solving wallet performance issues and one of the last remaining hurdles to exiting emergency mode. Because of some necessary changes to back-end structures, we’ve included a migration tool, which makes things much simpler for node operators performing the upgrade.
The SDK and lightwalletd will be released next week.
Thanks for the consistent updates on this @adjychris. The whole community appreciates it.
Hi, everyone. Lightwalletd 0.4.14* was released July 4, which means the mobile wallet SDK is the only outstanding piece in ECC’s plan to resolve wallet performance issues and exit Emergency Mode. Please see table of releases below.
The lightwalletd update introduces additional gRPC methods in support of fast fund spendability and the DAGSync algorithm implementation provided with zcashd 5.6.0. This version also includes bug fixes and a change to the compact block serialization format.
All lightwalletd operators should upgrade to this latest version ahead of the mobile wallet SDK release. While the new SDK will provide backwards compatibility to non-upgraded lightwalletd environments, the new speed and performance functionality will not work unless the wallet connects to an upgraded lightwalletd server.
NOTE: This release requires a rebuild of the compact block disk cache. The process can take a few hours, depending on hardware and network speed. Please plan appropriately prior to beginning the upgrade.
Full details of the included features along with directions for upgrading a node are available at Release v0.4.14 · zcash/lightwalletd · GitHub.
- In previous comms, we referred to this as the upcoming lightwalletd version 0.5.
To anyone running
lightwalletd: please ensure your backing
zcashd has the
-lightwalletd flag enabled. The new
GetSubtreeRoots gRPC method uses the
zcashd RPC method
z_getsubtreesbyindex, which is enabled by that flag.
Any update on the NU5 retrospective or the discussions on the network upgrade process? I seem to recall the NU5 retrospective being planned for June. Was it delayed?
any update on mobile SDK v2? is it out?
No, it didn’t come out, but I’m watching the repository and I see that work is being done daily. However, many people would like to know what is going on there.
The bill literally went on for weeks, but at some point we stopped receiving any information updates. I see confusion in Russian-language chats. Many people assumed that updates should be expected for the conference as important community news, but this did not happen. The lack of information always causes concern, although of course this is science and we cannot be accurate in forecasting, but due to the lack of at least some news, people assume that the whole idea of accelerated synchronization has failed.
@artkor and @zerodartz, thanks for your patience, and apologies for the long stretch here without much news. Ultimately, that’s on me. The ECC team is working hard to finish up the SDK for release, and I will provide a full update on progress and remaining work before the end of this week.
Wasn’t the v2 SDK release supposed to be mid July?
It’s already mid-August now. Is work today happening for v3?
If the dates in the product tables are never delivered to, why even name dates at all? Just remove that column and forget about it
That was the original plan. This last piece of functionality to enable Spend before Sync is a complicated piece of functionality. Having watched the process unfold over the recent weeks, we have taken great pains to test and retest as much as possible to ensure a stable and robust experience. You will see comms coming shortly around the release, which should provide the much needed relief that many in the community have been asking for.
ECC is pleased to announce the pre-release availability of the Spend before Sync (SbS) capability in our mobile SDKs. Available in both iOS and Android versions, this new capability builds upon previous sync parallelization and optimization work to provide a much improved user experience. In addition to the traditional linear sync, Spend Before Sync introduces a non-linear sync, allowing the ability to spend funds as they were discovered without requiring the wallet to fully sync the entire blockchain.
This new feature provides a faster and more robust user experience when accessing Zcash via a light client wallet. Our wallet partners Nighthawk, Edge, and Unstoppable, have already started work to integrate the new SDK features into their products. The ECC team has thoroughly tested the updated SDKs, and we will await feedback from these wallets before tagging version 2.0.
In addition to this release, the ECC team has opened a closed beta program for our own commercial wallet, Zashi. Testers, more than two dozen of them, have provided great feedback so far, and we are excited to give you news on this soon.
After much anticipation, the release of this SDK is a significant milestone that we’ve eagerly awaited. It’s been a journey of dedication for ECC engineers and core devs, and I take immense pride in my @NighthawkApps team’s proactive involvement – from testing and offering valuable feedback to promptly flagging bugs during the year-long development phase.
A special round of applause goes to Carter and @pacu, the chief architects behind this native mobile SDK. Their dedication has played a pivotal role in shaping this release. Although they have moved on from their official roles in maintaining the SDKs, Pacu now serves as the community wallet developer. We’re excited about this transition and eagerly anticipate the integration, testing, and delivery of the Spend before Sync Innovation – a groundbreaking advancement that promises to revolutionize Zcash’s peer-to-peer usage for payments and shielded app interactions.
Would you be able to describe the circumstances under which this system might exhibit different behavior compared to Zingo or YWallet? These wallets also permit the utilization of a note immediately upon its discovery.
As far as I’m aware both of those wallets do a linear sync whereas SbS adds a non linear backwards style sync so recently received notes are spendable without requiring a 100% synced wallet.
I’d like to try it.
I don’t know the specifics of the Send Before Sync but YWallet does not require a 100 % synced wallet before spending. It’s been like that for as long as I can remember.
Edit: I see you mentioned “recently received”. That is indeed different.
This is great news! I’ve been silently following the changes on the SDKs these last two months. I’m eager to test this out!