mirror of https://github.com/zcash/zips.git
ZIP 221: resolve ambiguities for the first block of a network upgrade.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
62e4a4228d
commit
03dac17d2a
|
|
@ -159,7 +159,7 @@ License: MIT</pre>
|
|||
in that chain, and</li>
|
||||
<li>certain metadata of any block or range of blocks in that chain.</li>
|
||||
</ul>
|
||||
<p>The protocol requires that an MMR that commits to the inclusion of all blocks since the most recent network upgrade
|
||||
<p>The protocol requires that an MMR that commits to the inclusion of all blocks since the preceding network upgrade
|
||||
<span class="math">\((B_x, \ldots, B_{n-1})\)</span>
|
||||
is formed for each block
|
||||
<span class="math">\(B_n\)</span>
|
||||
|
|
@ -170,18 +170,31 @@ License: MIT</pre>
|
|||
.</p>
|
||||
<p>(
|
||||
<span class="math">\(x\)</span>
|
||||
is the activation height of the most recent upgrade network upgrade.)</p>
|
||||
is the activation height of the preceding network upgrade.)</p>
|
||||
<p>FlyClient reduces the number of block headers needed for light client verification of a valid chain, from linear (as in the current reference protocol) to logarithmic in block chain length. This verification is correct with high probability. It also allows creation of subtree proofs, so light clients need only check blocks later than the most recently verified block index. Following that, verification of a transaction inclusion within that block follows the usual reference protocol <a id="id6" class="footnote_reference" href="#zip-0307">11</a>.</p>
|
||||
<p>A smaller proof size could enable the verification of Zcash SPV Proofs in block-chain protocols such as Ethereum, enabling efficient cross-chain communication and pegs. It also reduces bandwidth and storage requirements for resource-limited clients like mobile or IoT devices.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>For a block
|
||||
<span class="math">\(B_n\)</span>
|
||||
at height
|
||||
<span class="math">\(n > 0\)</span>
|
||||
in a given block chain, define the "preceding network upgrade height"
|
||||
<span class="math">\(x\)</span>
|
||||
of
|
||||
<span class="math">\(B_n\)</span>
|
||||
to be the last network upgrade activation height in the chain that is less than
|
||||
<span class="math">\(n\)</span>
|
||||
. (For this definion, block height
|
||||
<span class="math">\(0\)</span>
|
||||
is considered to be the height of a network upgrade activation. The preceding network upgrade height of the genesis block is undefined.)</p>
|
||||
<p>The leaves of the MMR at block
|
||||
<span class="math">\(B_n\)</span>
|
||||
are hash commitments to the header data and metadata of each previous block
|
||||
<span class="math">\(B_x, \ldots, B_{n-1}\)</span>
|
||||
, where
|
||||
<span class="math">\(x\)</span>
|
||||
is the block height of the most recent network upgrade. We extend the standard MMR to allow metadata to propagate upwards through the tree by either summing the metadata of both children, or inheriting the metadata of a specific child as necessary. This allows us to create efficient proofs of selected properties of a range of blocks without transmitting the entire range of blocks or headers.</p>
|
||||
is defined as above. We extend the standard MMR to allow metadata to propagate upwards through the tree by either summing the metadata of both children, or inheriting the metadata of a specific child as necessary. This allows us to create efficient proofs of selected properties of a range of blocks without transmitting the entire range of blocks or headers.</p>
|
||||
<section id="tree-node-specification"><h3><span class="section-heading">Tree Node specification</span><span class="section-anchor"> <a href="#tree-node-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to <code>'ZcashHistory' || CONSENSUS_BRANCH_ID</code>. <code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. <a id="id7" class="footnote_reference" href="#zip-0200">8</a> Which is to say, each node in the tree commits to the consensus branch that produced it.</p>
|
||||
<p>Each MMR node is defined as follows:</p>
|
||||
|
|
@ -193,13 +206,13 @@ License: MIT</pre>
|
|||
<p>The consensus-defined block hash for the corresponding block.</p>
|
||||
<ul>
|
||||
<li>This hash is encoded in internal byte order, and does NOT use the BLAKE2b-256 personalization string described above.</li>
|
||||
<li>For clarity, the <code>hashSubtreeCommitment</code> field of leaf
|
||||
<li>For clarity, in a given consensus branch, the <code>hashSubtreeCommitment</code> field of leaf
|
||||
<span class="math">\(n-1\)</span>
|
||||
is <em>precisely equal</em> to the <code>hashPrevBlock</code> field in the header of the block at height
|
||||
<span class="math">\(x+n\)</span>
|
||||
, where
|
||||
<span class="math">\(x\)</span>
|
||||
is the block height of the most recent network upgrade.</li>
|
||||
is the network upgrade activation height of that consensus branch.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
<dt>Internal or root node</dt>
|
||||
|
|
@ -504,6 +517,11 @@ License: MIT</pre>
|
|||
is the root of the Sapling note commitment tree for the final Sapling tree state of this block.</p>
|
||||
</blockquote>
|
||||
<p>Once the Heartwood network upgrade activates, <code>hashLightClientRoot</code> MUST be set to the value of <code>hashChainHistoryRoot</code> as specified above.</p>
|
||||
<p>The above specification is not well-defined for the genesis block, since then
|
||||
<span class="math">\(n = 0\)</span>
|
||||
and there is no block
|
||||
<span class="math">\(B_{n-1}\)</span>
|
||||
. 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 <code>hashLightClientRoot</code> field of the genesis block for that chain MUST be set to all zero bytes.</p>
|
||||
<p>The block header byte format and version are not altered by this ZIP.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
31
zip-0221.rst
31
zip-0221.rst
|
|
@ -147,10 +147,10 @@ needed for light clients to verify:
|
|||
- certain metadata of any block or range of blocks in that chain.
|
||||
|
||||
The protocol requires that an MMR that commits to the inclusion of all blocks since the
|
||||
most recent network upgrade :math:`(B_x, \ldots, B_{n-1})` is formed for each block :math:`B_n`.
|
||||
preceding network upgrade :math:`(B_x, \ldots, B_{n-1})` is formed for each block :math:`B_n`.
|
||||
The root :math:`M_n` of the MMR MUST be included in the header of :math:`B_n`.
|
||||
|
||||
(:math:`x` is the activation height of the most recent upgrade network upgrade.)
|
||||
(:math:`x` is the activation height of the preceding network upgrade.)
|
||||
|
||||
FlyClient reduces the number of block headers needed for light client verification of a
|
||||
valid chain, from linear (as in the current reference protocol) to logarithmic in
|
||||
|
|
@ -168,9 +168,15 @@ devices.
|
|||
Specification
|
||||
=============
|
||||
|
||||
The leaves of the MMR at block :math:`B_n` are hash commitments to the header data and
|
||||
metadata of each previous block :math:`B_x, \ldots, B_{n-1}`, where :math:`x` is the block height of
|
||||
the most recent network upgrade. We extend the standard MMR to allow metadata to propagate
|
||||
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,
|
||||
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.)
|
||||
|
||||
The leaves of the MMR at block :math:`B_n` are hash commitments to the header data
|
||||
and metadata of each previous block :math:`B_x, \ldots, B_{n-1}`, where :math:`x`
|
||||
is defined as above. We extend the standard MMR to allow metadata to propagate
|
||||
upwards through the tree by either summing the metadata of both children, or inheriting
|
||||
the metadata of a specific child as necessary. This allows us to create efficient proofs
|
||||
of selected properties of a range of blocks without transmitting the entire range of
|
||||
|
|
@ -194,10 +200,10 @@ Each MMR node is defined as follows:
|
|||
|
||||
* This hash is encoded in internal byte order, and does NOT use the BLAKE2b-256
|
||||
personalization string described above.
|
||||
* For clarity, the ``hashSubtreeCommitment`` field of leaf :math:`n-1` is *precisely
|
||||
equal* to the ``hashPrevBlock`` field in the header of the block at height
|
||||
:math:`x+n`, where :math:`x` is the block height of the most recent network
|
||||
upgrade.
|
||||
* For clarity, in a given consensus branch, the ``hashSubtreeCommitment`` field
|
||||
of leaf :math:`n-1` is *precisely equal* to the ``hashPrevBlock`` field in the
|
||||
header of the block at height :math:`x+n`, where :math:`x` is the network
|
||||
upgrade activation height of that consensus branch.
|
||||
|
||||
Internal or root node
|
||||
* Both child nodes are serialized.
|
||||
|
|
@ -529,6 +535,13 @@ block headers (adjusted for the renamed field) is enforced: [#block-header]_
|
|||
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 :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.
|
||||
|
||||
The block header byte format and version are not altered by this ZIP.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue