As part of the Network Upgrade Pipeline, Electric Coin Co. (ECC) is publishing our Zcash Improvement Proposals (ZIPs) for Network Upgrade 5 (NU5), projected to activate on Mainnet in October* 2021. Our proposals for inclusion of the ZIPs outlined here are subject to community approval and the outcome of security audits, the results of which will be published as soon as they’ve been completed and reviewed.
About the proposed features
The primary impetus for this proposed feature set is to bring the first application of the Halo 2 proving system to Zcash and enable the building blocks for cross-chain integrations and layer 2 applications.
The Halo 2 zero-knowledge proving system eliminates trusted setup for users of a new “Orchard” shielded pool, makes a big step toward reducing the attack surface of the Zcash protocol, and aims to improve assurances about ZEC supply integrity. This first deployment also enables circuit upgrades without the need for setup ceremonies, making the Zcash shielded protocol more agile for future improvements, such as supporting additional assets. The longer-term aim is to leverage this proving system to support scalability, and perhaps programmability, using recursive proofs.
Separately, these proposed features introduce a new algorithm for transaction identifier computation. At present, the fact that transaction identifiers remain “malleable” until a transaction is mined inhibits them from being used in protocols that do not immediately submit signed transactions to the blockchain, but which need a stable identifier. The zkChannels protocol (formerly known as BOLT) is an example of such a protocol.
ZIP 216: Require Canonical Jubjub Point Encodings
The Sapling specification was written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types. The intention of the Jubjub implementation (both in the jubjub crate and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an edge case to slip through. This proposal fixes that oversight in the implementation of the Sapling consensus rules, by rejecting all non-canonical representations of Jubjub points.
ZIP 224: Orchard Shielded Protocol
Orchard is a new shielded-transaction protocol and would be the first phase of Halo 2 deployment in Zcash. This introduces the first shielded-transfer capability that does not rely on a trusted setup. The functionality offered will be very similar to that available from the Sapling protocol, however, the proving system will leverage the Halo 2 stack. This includes a new cycle of elliptic curves, Pallas and Vesta, together referred to as the Pasta curves. The Pasta curves, a new cryptographic construct, are a result of ECC’s continued effort to ensure that Zcash benefits as much as possible from groundbreaking cryptographic innovations. This proposal also introduces a new shielded-address format, using the Pasta curves, and a new shielded pool. Its protocol design characteristics and privacy properties are intentionally almost identical to Sapling, in order to limit technical risk and simplify the user experience and adoption.
ZIP 225: Version 5 Transaction Format
The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extensions in a systematic fashion, where elements required for support for a given pool are kept separate.
ZIP 244: Transaction Identifier Non-Malleability
This proposal defines a new transaction identifier digest for the Zcash blockchain. Instead of using a hash of the flat serialized form of a transaction, the new digest algorithm specifies a tree of hashes that commits to exactly the parts of the transaction which are “effecting” data, and excludes proofs and signatures. As an added benefit, the tree structure of these hashes opens up possibilities for light clients to use Merkle paths for verifying the integrity of specific granular parts of a transaction without needing to download all transaction data, and it also opens up possibilities for pruning of witness data from blockchain history in a fashion similar to Bitcoin’s SegWit.
ZIP 252: Deployment of the NU5 Network Upgrade
This proposal defines the deployment of the NU5 network upgrade. The network handshake and peer-management mechanisms defined in ZIP 201 also apply to this upgrade.
Halo on Zcash creates fertile ground for new Zcash-inclusive solutions, with the potential to surpass the importance of our previous work with zero-knowledge proofs. It’s an evolution in cryptography and creates a new baseline for interoperability, additional assets, scale, and adoption. ECC is excited to see this new era beginning in Zcash, and we look forward to working with the community on the successful activation of NU5!
* Updated from August timeline
