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.
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.
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:
- ZIP 32 : Shielded Hierarchical Deterministic Wallets (updated)
- ZIP 203: Transaction Expiry (updated)
- ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances (updated)
- ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext (updated)
- ZIP 213: Shielded Coinbase (updated)
- ZIP 216: Require Canonical Jubjub Point Encodings
- ZIP 221: FlyClient – Consensus-Layer Changes (updated)
- ZIP 224: Orchard Shielded Protocol
- ZIP 225: Version 5 Transaction Format
- ZIP 239: Relay of Version 5 Transactions
- ZIP 244: Transaction Identifier Non-Malleability
- ZIP 252: Deployment of the NU5 Network Upgrade
- ZIP 316: Unified Addresses and Unified Viewing Keys
- ZIP 401: Addressing Mempool Denial-of-Service (clarified)
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.
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:
z_sendmanyis deprecated. When disabled, the default behavior of
z_sendmanywill conform to the
FullPrivacydirective (introduced in 4.7.0) in all cases instead of just for transactions involving unified addresses.
getnewaddress– controls availability of the
getrawchangeaddress– controls availability of the
z_getbalance– controls availability of the
z_gettotalbalance– controls availability of the
z_getnewaddress– controls availability of the
z_listaddresses– controls availability of the
addrtype– controls availability of the deprecated
typeattribute 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
zcrawreceiveRPC method is disabled. It may be reenabled with
zcrawjoinsplitRPC method is disabled. It may be reenabled with
zcrawkeygenRPC method is disabled. It may be reenabled with
-reindex-chainstateoptions now imply -rescan (provided that the wallet is enabled and pruning is disabled, and unless
-rescan=0is specified explicitly).
- A new
-anchorconfirmationsargument 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
-orchardactionlimitoption 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.
- The default
z_sendmanyis now 10 confirmations instead
of 1. If
minconfspecifies 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
minconfvalues less than 3 is not recommended, as it allows the transaction to be distinguished from transactions using the default for
- The deprecated
zcrawjoinsplitRPC methods are now disabled by default. Use
-allowdeprecated=<feature>to select individual features if you wish to continue using these APIs.
zcutil/build.shnow automatically runs
zcutil/clean.shto remove files created by previous builds. We previously recommended to do this manually.
native_b2dependencies have been updated to version 1.79.0.
- The environment variable that allows users of the rpc (Python) tests to override the default path to the
zcashdexecutable has been changed from
The Zcash Schedule page has been updated to reflect the 5.0.0 release, as well as mainnet activation timing.