New Release 5.0.0

Network Upgrade 5

The 5.0.0 release supports NU5 activation on mainnet, which will occur at a block height of 1687104 (May 31st), following the targeted EOS halt of our 4.6.0-2 and 4.7.0 releases on May 16th. Release binaries will be available later today and instructions on how to install can be found on our download site.

Please upgrade to this release, or any subsequent release, prior to May 16th in order to avoid service disruption and follow the NU5 network upgrade on mainnet.

Summary

NU5 represents the largest network upgrade in Zcash history, launching the Orchard shielded payment protocol and utilizing the Halo proving system to remove reliance on complex setup ceremonies. The efficiencies built into this upgrade make possible — for the first time ever — private, trustless digital cash payments on mobile phones. Halo also paves the way for increased interoperability by providing a system that could unlock private cross-chain proofs at scale.

NU5 readiness

The upgrade has undergone extensive review at both the specification and implementation levels, including external security assessments by NCC and QEDIT. ECC also engaged Mary Maller, a cryptography researcher at the Ethereum Foundation and a member of ECC’s Scientific Advisory Group, to perform a review of the Halo 2 security proof and protocol, which didn’t result in any concerns about the protocol’s security. ECC will continue to work with Mary over the coming weeks to address her feedback and suggestions. Mary’s current review can be found here. 

The Halo 2 security proof is a proof of zero-knowledge and soundness for the Halo 2 construction which, to the best of our knowledge, is the first proof of a generalized PLONK-based protocol and the first explicit proof written for the polynomial commitment scheme based on the inner product argument. Additionally, the ECC Core and Security engineering teams have completed another extensive review of the Orchard circuit, the Halo2 libraries, and the consensus logic implemented in NU5. 

BOSL licensing for Orchard and general exceptions

The Orchard payment protocol is licensed under the Bootstrap Open Source License (BOSL), an open-source software license intended to guarantee that all improvements remain open-source long-term while still allowing commercial development. ECC is in the process of adding two general exceptions to BOSL so that our partners and future friendly forks can use the Orchard technology in a manner consistent with their current licensing choice. The exception for future friendly forks are for those chains that descend from the block hash as referenced in the Trademark Agreement. The exception for partners applies to those partners that use the Orchard technology to support the Zcash network and ZEC coin. We’ll be working with our attorneys with the objective to complete that before NU5 activation.

Endorsement under the Trademark Agreement

In accordance with Section 6.2.b of the Trademark Agreement, ECC is providing notice of the pending upgrade of NU5 and has endorsed release 5.0.0 as the Reference Implementation of Zcash. The endorsement agreement has also been signed by the Zcash Foundation.


Notable changes in 5.0.0

The mainnet activation of the NU5 network upgrade is supported by the 5.0.0 release, with an activation height of 1687104, which should occur on approximately May 31, 2022. Please upgrade to this release, or any subsequent release, in order to follow the NU5 network upgrade.

The following ZIPs are being deployed, or have been updated, as part of this upgrade:

Feature deprecation and removal

zcashd now has a process for how features of the public API may be deprecated and removed. Feature deprecation follows a series of steps whereby, over a series of releases, features first remain enabled by default (but may be explicitly disabled), then switch to being disabled by default, and eventually are removed entirely. A new string-valued option, -allowdeprecated has been introduced to allow a user to explicitly manage the availability of deprecated zcashd features. This flag makes it possible for users to reenable deprecated methods and features api that are currently disabled by default, or alternately to explicitly disable all deprecated features if they so choose. Multiple instances of this argument may be provided. A user may disable deprecated features entirely by providing the string none as the argument to this parameter. In the case that none is specified, multiple invocations of -allowdeprecated are not permitted.

Deprecated

As of this release, the following features are deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none. After release 5.3.0, these features will be disabled by default and the following flags to -allowdeprecated will be required to permit their continued use:

  • legacy_privacy – the default “legacy” privacy policy for z_sendmany is deprecated. When disabled, the default behavior of z_sendmany will conform to the FullPrivacy directive (introduced in 4.7.0) in all cases instead of just for transactions involving unified addresses.
  • getnewaddress – controls availability of the getnewaddress RPC method.
  • getrawchangeaddress – controls availability of the getrawchangeaddress RPC method.
  • z_getbalance – controls availability of the z_getbalance RPC method.
  • z_gettotalbalance – controls availability of the z_gettotalbalance RPC method.
  • z_getnewaddress – controls availability of the z_getnewaddress RPC method.
  • z_listaddresses – controls availability of the z_listaddresses RPC method.
  • addrtype – controls availability of the deprecated type attribute returned by RPC methods that return address metadata.

As of this release, the following previously deprecated features are disabled by default, but may be reenabled using -allowdeprecated=<feature>.

  • The zcrawreceive RPC method is disabled. It may be reenabled with allowdeprecated=zcrawreceive
  • The zcrawjoinsplit RPC method is disabled. It may be reenabled with allowdeprecated=zcrawjoinsplit
  • The zcrawkeygen RPC method is disabled. It may be reenabled with allowdeprecated=zcrawkeygen

Option handling

  • The -reindex and -reindex-chainstate options now imply -rescan (provided that the wallet is enabled and pruning is disabled, and unless -rescan=0 is specified explicitly).
  • A new -anchorconfirmations argument has been added to allow the user to specify the number of blocks back from the chain tip that anchors will be selected from when spending notes. By default, anchors will now be selected to have 3 confirmations. Values greater than 100 are not supported.
  • A new -orchardactionlimit option has been added to allow the user to override the default maximum of 50 Orchard actions per transaction. Transactions that contain large numbers of Orchard actions can use large amounts of memory for proving, so the 50-action default limit is imposed to guard against memory exhaustion. Systems with more than 16G of memory can safely set this parameter to allow 200 actions or more.

RPC Interface

  • The default minconf value for z_sendmany is now 10 confirmations instead
    of 1. If minconf specifies a value less than that provided for -anchorconfirmations, it will also override that value as it is not possible to spend notes that are more recent than the anchor. Selecting minconf values less than 3 is not recommended, as it allows the transaction to be distinguished from transactions using the default for -anchorconfirmations.

RPC Changes

  • The deprecated zcrawkeygen, zcrawreceive, and zcrawjoinsplit RPC methods are now disabled by default. Use -allowdeprecated=<feature> to select individual features if you wish to continue using these APIs.

Build system

  • zcutil/build.sh now automatically runs zcutil/clean.sh to remove files created by previous builds. We previously recommended to do this manually.

Dependencies

  • The boost and native_b2 dependencies have been updated to version 1.79.0.

Tests

  • The environment variable that allows users of the rpc (Python) tests to override the default path to the zcashd executable has been changed from BITCOIND to ZCASHD.

The Zcash Schedule page has been updated to reflect the 5.0.0 release, as well as mainnet activation timing.

Recent blog posts: