From 03dac17d2a5150b3a5a890d5e5d91a1d80ec36df Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 16 Mar 2020 21:30:46 +0000 Subject: [PATCH] ZIP 221: resolve ambiguities for the first block of a network upgrade. Signed-off-by: Daira Hopwood --- zip-0221.html | 28 +++++++++++++++++++++++----- zip-0221.rst | 31 ++++++++++++++++++++++--------- 2 files changed, 45 insertions(+), 14 deletions(-) diff --git a/zip-0221.html b/zip-0221.html index 0eabad58..b44bd346 100644 --- a/zip-0221.html +++ b/zip-0221.html @@ -159,7 +159,7 @@ License: MIT in that chain, and
  • 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 +

    The protocol requires that an MMR that commits to the inclusion of all blocks since the preceding network upgrade \((B_x, \ldots, B_{n-1})\) is formed for each block \(B_n\) @@ -170,18 +170,31 @@ License: MIT .

    ( \(x\) - is the activation height of the most recent upgrade network upgrade.)

    + 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 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 11.

    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.

    Specification

    +

    For a block + \(B_n\) + at height + \(n > 0\) + in a given block chain, define the "preceding network upgrade height" + \(x\) + of + \(B_n\) + to be the last network upgrade activation height in the chain that is less than + \(n\) + . (For this definion, block height + \(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 \(B_n\) are hash commitments to the header data and metadata of each previous block \(B_x, \ldots, B_{n-1}\) , where \(x\) - 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.

    + 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.

    Tree Node specification

    Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to 'ZcashHistory' || CONSENSUS_BRANCH_ID. CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. 8 Which is to say, each node in the tree commits to the consensus branch that produced it.

    Each MMR node is defined as follows:

    @@ -193,13 +206,13 @@ License: MIT

    The consensus-defined block hash for the corresponding block.

    • 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 +
    • For clarity, in a given consensus branch, the hashSubtreeCommitment field of leaf \(n-1\) is precisely equal to the hashPrevBlock field in the header of the block at height \(x+n\) , where \(x\) - is the block height of the most recent network upgrade.
      • + is the network upgrade activation height of that consensus branch.
    Internal or root node
    @@ -504,6 +517,11 @@ License: MIT 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.

    The block header byte format and version are not altered by this ZIP.

    diff --git a/zip-0221.rst b/zip-0221.rst index 5eaeb549..eaf8f322 100644 --- a/zip-0221.rst +++ b/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.