On June 17, 6pm UTC, shielded transactions submitted to the Zcash network increased dramatically. As a result, third party wallets have experienced lower performance. The network remained, and still remains, stable and operational, and transactions are being processed normally.
The ECC core team worked over the Fourth of July holiday to implement a new batch validation algorithm to further reduce verification time by another 80%. Their efforts saw release zcashd
5.1.0 go live.
Summary
This release is primarily targeted at improving the validation performance of Sapling and Orchard transactions as well as an incremental improvement to the scan performance of post-NU5 blocks. The release also made improvements to getblocktemplate
performance and added Orchard information to getrawtransaction
and decoderawtransaction
. We will continue to address remaining scan performance issues in subsequent releases.
Notable changes
Faster block validation for Sapling and Orchard transactions
Block validation in zcashd
is a mostly single-threaded process, due to how the chain update logic inherited from Bitcoin Core is written. However, certain more computationally intensive checks are performed more efficiently than checking everything individually:
- ECDSA signatures on transparent inputs are checked via multithreading.
- RedPallas signatures on Orchard actions are checked via batch validation.
As of this release, zcashd
applies these techniques to more Sapling and Orchard components:
- RedJubjub signatures on Sapling Spends are checked via batch validation.
- Groth16 proofs for Sapling Spends and Outputs are checked via batch validation and multithreading.
- Halo 2 proofs for Orchard Actions are checked via batch validation and multithreading.
This reduces worst-case block validation times for observed historic blocks by around 80% on a Ryzen 9 5950X CPU.
The number of threads used for checking Groth16 and Halo 2 proofs (as well as for creating them when spending funds) can be set via the RAYON_NUM_THREADS
environment variable.
Option handling
- A new
-preferredtxversion
argument allows the node to preferentially create transactions of a specified version, if a transaction does not contain components that necessitate creation with a specific version. For example, setting-preferredtxversion=4
will cause the node to create V4 transactions whenever the transaction does not contain Orchard components. This can be helpful if recipients of transactions are likely to be using legacy wallets that have not yet been upgraded to support parsing V5 transactions.
RPC interface
- The
getblocktemplate
RPC method now skips proof and signature checks on templates it creates, as these templates only include transactions that have previously been checked when being added to the mempool. - The
getrawtransaction
anddecoderawtransaction
RPC methods now include details about Orchard actions within transactions.
Wallet
- Rescan performance of post-NU5 blocks has been slightly improved (overall rescan time for a single-account wallet decreases by around 6% on a Ryzen 9 5950X). Further improvements will be implemented in future releases to help mitigate the effect of blocks full of shielded outputs.
- The
CWallet::UpdatedTransaction
signal is no longer called while holding thecs_main
lock. This fixes an issue where RPCs could block for long periods of time onzcashd
nodes with large wallets. Downstream code forks that have reconnected theNotifyTransactionChanged
wallet signal should take note of this change, and not rely there on access to globals protected bycs_main
. - Some
zcashd 5.0.0
nodes would shut down some time after start with the errorThreadNotifyWallets: Failed to read block X while notifying wallets of block disconnects. zcashd
now attempts to rectify the situation, and otherwise will inform the user before shutting down that a reindex is required.
Deprecated
As of this release, the following previously deprecated features are disabled by default, but may be reenabled using -allowdeprecated=<feature>
.
- The
dumpwallet
RPC method is disabled. It may be reenabled withallowdeprecated=dumpwallet. dumpwallet
should not be used; it is unsafe for backup purposes as it does not return any key information for keys used to derive shielded addresses. Usez_exportwallet
instead.
As of this release, the following features are deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none
. After at least 3 minor-version releases, these features will be disabled by default and the following flags to -allowdeprecated
will be required to permit their continued use:
wallettxvjoinsplit
– controls availability of the deprecatedvjoinsplit
attribute returned by thegettransaction
RPC method.
The Zcash Schedule page has been updated to reflect the 5.1.0 release.