The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8
The hashFinalSaplingRoot block header field (which was named hashReserved prior to the Sapling network upgrade) is renamed to hashLightClientRoot, to reflect its usage by light clients.
Prior to activation of the Heartwood network upgrade, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: 4
+Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: 4
-[Sapling onward]
hashLightClientRootMUST be \(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\) @@ -518,12 +518,8 @@ License: MIT \(\mathsf{rt}\) is the root of the Sapling note commitment tree for the final Sapling tree state of this block.
Once the Heartwood network upgrade activates, hashLightClientRoot MUST be set to the value of hashChainHistoryRoot as specified above.
The above specification is not well-defined for the genesis block, since then
- \(n = 0\)
- and there is no block
- \(B_{n-1}\)
- . For the Zcash Mainnet and Testnet chains, this is not an issue because the Heartwood network upgrade is not active at genesis. In the case of this specification being adopted for a chain that starts with Heartwood active at genesis, the hashLightClientRoot field of the genesis block for that chain MUST be set to all zero bytes.
In the block that activates this ZIP, hashLightClientRoot MUST be set to all zero bytes. This MUST NOT be interpreted as a root hash.
In subsequent blocks, hashLightClientRoot MUST be set to the value of hashChainHistoryRoot as specified above.
The block header byte format and version are not altered by this ZIP.
Additional metadata commitments were chosen primarily to improve light client security guarantees. We specified commitments where we could see an obvious security benefit, but there may be other useful metadata that we missed. We're interested in feedback and suggestions from the implementers of the current light client.
-We considered adding a commitment to the nullifier vector at each block. We would appreciate comments from light client teams on the utility of this commitment, as well as the proper serialization and commitment format for the nullifier vector.
+We considered adding a commitment to the nullifier vector at each block. We would appreciate comments from light client teams on the utility of this commitment, as well as the proper serialization and commitment format for the nullifier vector, for possible inclusion in a future upgrade.
hashEarliestSaplingRoot
ZIP 301 states that "[Miner client software] SHOULD alert the user upon receiving jobs containing block header versions they do not know about or support, and MUST ignore such jobs." 10 As the only formally defined block header version is 4, any header version change requires changes to miner client software in order for miners to handle new jobs from mining pools. We therefore do not alter the block version for this semantic change. This does not make block headers ambiguous to interpret, because blocks commit to their block height inside their coinbase transaction, 7 and they are never handled in a standalone context (unlike transactions, which exist in the mempool outside of blocks).
Replacing hashFinalSaplingRoot with hashChainHistoryRoot does introduce the theoretical possibility of an attack where a miner constructs a Sapling commitment tree update that results in the same 32-byte value as the MMR root. We don't consider this a realistic attack, both because the adversary would need to find a preimage over 32 layers of Pedersen hash, and because light clients already need to update their code to include the consensus branch ID for the Heartwood network upgrade, and can simultaneously make changes to not rely on the value of this header field being the Sapling tree root.
We also considered putting hashChainHistoryRoot in the hashPrevBlock field as it commits to the entire chain history, but quickly realized it would require massive refactoring of the existing code base and would negatively impact performance. Reorgs in particular are fragile, performance-critical, and rely on backwards iteration over the chain history. If a chain were to be designed from scratch there may be some efficient implementation that would join these commitments, but it is clearly not appropriate for Zcash as it exists.
The calculation of hashChainHistoryRoot is not well-defined for the genesis block, since then
+ \(n = 0\)
+ and there is no block
+ \(B_{n-1}\)
+ . Also, in the case of chains that activate this ZIP after genesis (including Zcash Mainnet and Testnet), the hashChainHistoryRoot of the activation block would commit to the whole previous epoch if a special case were not made. It would be impractical to calculate this commitment all at once, and so we specify that hashLightClientRoot is set to all zero bytes for that block instead. The hash of the final Sapling note commitment tree root for the activation block will not be encoded in that block, but will be committed to one block later in the hashLatestSaplingRoot field of the MMR root commitment.
In addition, 2 only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. That paper leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case. However, as mentioned in FlyClient Requirements and Recommendations, additional commitments allowing light clients to reason about application of the difficulty adjustment algorithm were added in discussion with an author of the FlyClient paper. The use of these fields has not been analysed in the academic security literature. It would be possible to update them in a future network upgrade if further security analysis were to find any deficiencies.
This proposal will be deployed with the Heartwood network upgrade. 9
+On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. 9