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 will also be sent to the Zcash Foundation for review and signature.
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 forz_sendmany
is deprecated. When disabled, the default behavior ofz_sendmany
will conform to theFullPrivacy
directive (introduced in 4.7.0) in all cases instead of just for transactions involving unified addresses.getnewaddress
– controls availability of thegetnewaddress
RPC method.getrawchangeaddress
– controls availability of thegetrawchangeaddress
RPC method.z_getbalance
– controls availability of thez_getbalance
RPC method.z_gettotalbalance
– controls availability of thez_gettotalbalance
RPC method.z_getnewaddress
– controls availability of thez_getnewaddress
RPC method.z_listaddresses
– controls availability of thez_listaddresses
RPC method.addrtype
– controls availability of the deprecatedtype
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 withallowdeprecated=zcrawreceive
- The
zcrawjoinsplit
RPC method is disabled. It may be reenabled withallowdeprecated=zcrawjoinsplit
- The
zcrawkeygen
RPC method is disabled. It may be reenabled withallowdeprecated=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 forz_sendmany
is now 10 confirmations instead
of 1. Ifminconf
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. Selectingminconf
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
, andzcrawjoinsplit
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 runszcutil/clean.sh
to remove files created by previous builds. We previously recommended to do this manually.
Dependencies
- The
boost
andnative_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 fromBITCOIND
toZCASHD
.
The Zcash Schedule page has been updated to reflect the 5.0.0 release, as well as mainnet activation timing.