July 7, 2017 - Dev update

Sapling planning
This week started off with another meeting to discuss the Sapling protocol upgrade. While last time we focused on a lot of UI considerations that the upgrade would provide, this meeting was focused more on the crypto and proving system.

One of our engineers and a few of the scientists have been studying a new elliptic curve called BLS12-381 which was introduced in our blog a little while ago. This curve offers improved efficiency while also increasing the security margins. We’ve decided to go ahead and give the green light on using this new curve.

We also discussed the Groth16 proving system which would increase proving speed by requiring less components in the construction and resulting in a smaller proof size overall. We’re a little more hesitant to give this a green light and want to take the time first for writing a proof showing it can’t be broken. That said, we’re enthusiastic about the enhancements it allows such as cheap and indistinguishable pay-to-verification-key payments (#2425). This proving system would also enable a simpler and safer multi-party computation ceremony process (#2247).

Next steps are benchmarking for time and memory consumption.

The agenda and notes from this meeting are in the Zcash github wiki. We encourage anyone interested in Sapling upgrade to join us in our upcoming meetings by reaching out to us for an invite!

Release prep
Time this week was also spent on preparing for the upcoming 1.0.11 CI deployment and release milestones which are being organized in the 1.0.11 release project on Github. You can see which issues were nominated to include in the upcoming milestones and out of those, which ones were marked as accepted, nice-to-have and rejected. Next week will see the 1.0.11 CI milestone in preparation for the subsequent week’s 1.0.11 release milestone.

XCAT, Beswick, Documentation
Progress was made on various other projects including work on an XCAT proof of concept for Ethereum. Also, further design and improvement discussions for Beswick and work on more user friendly documentation via Readthedocs progressed.

Next week’s update
Heads up: I’ll be traveling late next weekend to the other side of the world so might end up having to postpone the dev update again or make it shorter than normal.


I am so looking forward to speed improvements in Sapling!
My only big news this last week is that I finally got around to updating my Windows port to track 1.0.10-1, and released a new version at https://zcash4win.com incorporating it


For the simplest, one-input-one-output type of protected transaction, how many bytes are needed for these new Groth16 proofs?

1 Like

The proof size isn’t dependent on the circuit for either our current proving system, or Groth16. Assuming a small tweak to reduce overhead, the proof sizes are:

  • 288 bytes for BCTV14 with BN-254 (our current proving system and curve; this excludes 8 bytes of encoding overhead);
  • 432 bytes for BCTV14 with BLS12-381;
  • 128 bytes for Groth16 with BN-254;
  • 192 bytes for Groth16 with BLS12-381 (the most likely choice for Sapling).

Note that the majority of the size of a JoinSplit description is taken up by fields other than the proof.


See Decide whether to use Groth16 or PHGR13/BCTV14 for Sapling · Issue #2465 · zcash/zcash · GitHub for more detail; that’s the ticket we’ll be updating with performance information for Groth16.