diff --git a/zip-0221.html b/zip-0221.html
index 2526221e..8cb4ac34 100644
--- a/zip-0221.html
+++ b/zip-0221.html
@@ -18,7 +18,7 @@ Category: Consensus
Created: 2019-03-30
License: MIT
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. 8Terminology
-
The leaves of the MMR at block
@@ -510,7 +510,7 @@ License: MIT
The 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] Once the Heartwood network upgrade activates, 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 In the block that activates this ZIP, In subsequent blocks, 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. 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 We also considered putting The calculation of 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. 9Block header semantics and consensus rules
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.
- hashLightClientRoot
MUST 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.hashLightClientRoot
MUST be set to the value of hashChainHistoryRoot
as specified above.hashLightClientRoot
field of the genesis block for that chain MUST be set to all zero bytes.hashLightClientRoot
MUST be set to all zero bytes. This MUST NOT be interpreted as a root hash.hashLightClientRoot
MUST be set to the value of hashChainHistoryRoot
as specified above.Non-FlyClient Commitments
hashEarliestSaplingRoot
@@ -581,6 +577,11 @@ License: MIT
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.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.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.Security and Privacy Considerations
@@ -592,7 +593,7 @@ License: MIT
Deployment
- Additional Reading
diff --git a/zip-0221.rst b/zip-0221.rst
index 4a488856..770d318f 100644
--- a/zip-0221.rst
+++ b/zip-0221.rst
@@ -14,8 +14,8 @@
Terminology
===========
-The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described
-in RFC 2119. [#RFC2119]_
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted
+as described in RFC 2119. [#RFC2119]_
The terms "consensus branch", "epoch", and "network upgrade" in this document are to be
interpreted as described in ZIP 200. [#zip-0200]_
@@ -170,7 +170,7 @@ Specification
For a block :math:`B_n` at height :math:`n > 0` in a given block chain, define the
"preceding network upgrade height" :math:`x` of :math:`B_n` to be the last network
-upgrade activation height in the chain that is less than :math:`n`. (For this definion,
+upgrade activation height in the chain that is less than :math:`n`. (For this definition,
block height :math:`0` is considered to be the height of a network upgrade activation.
The preceding network upgrade height of the genesis block is undefined.)
@@ -527,22 +527,18 @@ The ``hashFinalSaplingRoot`` block header field (which was named ``hashReserved`
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: [#block-header]_
+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: [#block-header]_
[Sapling onward] ``hashLightClientRoot`` MUST be :math:`\mathsf{LEBS2OSP}_{256}(\mathsf{rt})`
where :math:`\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.
+In the block that activates this ZIP, ``hashLightClientRoot`` MUST be set to all zero bytes.
+This MUST NOT be interpreted as a root hash.
-The above specification is not well-defined for the genesis block, since then :math:`n = 0`
-and there is no block :math:`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 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.
@@ -602,7 +598,8 @@ 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.
+the proper serialization and commitment format for the nullifier vector, for possible
+inclusion in a future upgrade.
- ``hashEarliestSaplingRoot``
@@ -680,6 +677,16 @@ chain history. If a chain were to be designed from scratch there may be some eff
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 :math:`n = 0` and there is no block :math:`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.
+
Security and Privacy Considerations
===================================
@@ -730,7 +737,8 @@ deficiencies.
Deployment
==========
-This proposal will be deployed with the Heartwood network upgrade. [#zip-0250]_
+On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood
+network upgrade. [#zip-0250]_
Additional Reading