We had a sync-up on the 1.0.12 release at the beginning of the week to check on the status and requirements for the coming weeks. While we anticipate the RC date (upcoming Monday) could slip by a day, we still plan to stay on track for an official 1.0.12 release on Sept. 25.
The extended release cycle seems to be a positive and stabilizing decision and our focus on performance and user support related issues this time around will let us focus on feature improvement in the upcoming releases (which we certainly are anticipating and excited for).
The auto-senescence feature introduced in 1.0.9 will kick in soon (as a rule, after 18 weeks for each release thereafter). This means at block 193076 all 1.0.9 nodes which do not have the -disabledeprecation=1.0.9 flag set to disable this feature will automatically shut down. At this point, any 1.0.9 nodes should be receiving a related message about the upcoming version deprecation. Note that the deprecation and new release will fall at about the same time since we extended our release cycle to 6 weeks. If you’re still running 1.0.9, you probably don’t care to be on top of the most recent version anyways so upgrading to 1.0.11 right before we release 1.0.12 is probably not a big deal to you. But if you’d like to change your ways, we suggest upgrading to 1.0.11 now (or at least before block 193076) then again to 1.0.12 to be on the bleeding edge of Zcash.
We finally announced the performance improvements our expert cryptographers have devised for the Sapling protocol upgrade (ETA 2018). Woo hoo! Onto building and prototyping.
UX & Website migration
As part of our ongoing studies of UX in the Zcash ecosystem, we’re excited to be taking a peek at a really cool piece of software just released in beta (major hint ) and how the process feels for someone spending ZEC.
We’re also diving into migrating our website, blog and the whole translation process to a more scalable solution. With 8 supported languages, a lot of the translation management has become burdensome using our current website framework. We’re excited to expand to more languages but want to make this transition first so further expansion can be easier to manage overall.
I wonder why we’re using the modifier “finally”? It conveys a sense of frustration, and a notion that someone’s schedule is not being met. These things are likely known to insiders, to outside observers it gives an appearance of dysfunction.
We had been holding onto the faster SNARKs news for a few weeks while we finalized some benchmarks. And I had alluded to an announcement in previous dev updates. So no dysfunction, just excited to finally get the great news out to the community!
I am very interested to see how fast the Sapling circuit ends up being for an actual shielded send, because right now it usually takes 2-3 minutes. THAT is the benchmark I’m interested in
(yes i realize that sapling isn’t 100% designed yet, too)
The zk-SNARK protocols we’re using (both PHGR13 and Groth16) perform optimally when the number of constraints is just under a power of two. The number of constraints for Sprout was 221, and it’s tentatively looking like the number for Sapling will be 217. So that’s 16 times fewer –
and there are also independent improvements, about a factor of 2, in the performance of the arithmetic and proof system. This doesn’t necessarily mean that proving will be 16 times faster (which would be better than the performance estimate we posted before) --and it’s not easy to compare overall shielded transaction performance because the number of proofs can be different-- but it’s looking very promising.