diff --git a/zip-0221.html b/zip-0221.html index cfbfca18..fe6aba25 100644 --- a/zip-0221.html +++ b/zip-0221.html @@ -171,7 +171,7 @@ License: MIT

( \(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 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.

+

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

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

@@ -323,17 +323,60 @@ License: MIT
  • nSaplingTxCount
    Leaf node
    -
    The number of transactions in the leaf block where either of vShieldedSpend or vShieldedOutput is non-empty.
    +
    The number of transactions in the leaf block where either of vSpendsSapling or vOutputsSapling is non-empty.
    Internal or root node
    The sum of the nSaplingTxCount field of both children.

    Serialized as CompactSize uint.

    • +
  • [NU5 onward] hashEarliestOrchardRoot
    • -

    Each node, when serialized, is between 147 and 171 bytes long. The canonical serialized representation of a node is used whenever creating child commitments for future nodes. Other than the metadata commitments, the MMR tree's construction is standard.

    +
    +
    +
    Leaf node
    +
    Calculated as the note commitment root of the final Orchard treestate (similar to hashEarliestSaplingRoot in Sapling).
    +
    Internal or root node
    +
    Inherited from the left child.
    +
    +

    Serialized as char[32].

    +
    +
      +
    1. [NU5 onward] hashLatestOrchardRoot
      2. +
    +
    +

    System Message: INFO/1 (zip-0221.rst line 169)

    +

    Enumerated list start value not ordinal-1: "13" (ordinal 13)

    +
    +
    +
    +
    Leaf node
    +
    Calculated as the note commitment root of the final Orchard treestate (similar to hashLatestSaplingRoot in Sapling).
    +
    Internal or root node
    +
    Inherited from the right child.
    +
    +

    Serialized as char[32].

    +
    +
      +
    1. [NU5 onward] nOrchardTxCount +
      +
      Leaf node
      +
      The number of transactions in the leaf block where vActionsOrchard is non-empty.
      +
      Internal or root node
      +
      The sum of the nOrchardTxCount field of both children.
      +
      +

      Serialized as CompactSize uint.

      +
      2. +
    +
    +

    System Message: INFO/1 (zip-0221.rst line 169)

    +

    Enumerated list start value not ordinal-1: "14" (ordinal 14)

    +
    +

    The fields marked "[NU5 onward]" are omitted before NU5 activation 11.

    +

    Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes after NU5 activation). The canonical serialized representation of a node is used whenever creating child commitments for future nodes. Other than the metadata commitments, the MMR tree's construction is standard.

    Once the MMR has been generated, we produce hashChainHistoryRoot, which we define as the BLAKE2b-256 digest of the serialization of the root node.

    Tree nodes and hashing (pseudocode)

    +

    Note that this pseudocode reflects the specification prior to NU5 activation.

    def H(msg: bytes, consensusBranchId: bytes) -> bytes:
     return blake2b256(msg, personalization=b'ZcashHistory' + consensusBranchId)
 
@@ -421,7 +464,7 @@ License: MIT
    \(B_n\) , we append a new MMR leaf node corresponding to block \(B_{n-1}\) - . The append operation is detailed below in pseudocode (adapted from 2):

    + . The append operation is detailed below in pseudocode (adapted from 2):

    def get_peaks(node: ZcashMMRNode) -> List[ZcashMMRNode]:
     peaks: List[ZcashMMRNode] = []
 
@@ -509,8 +552,9 @@ License: MIT
    return new_root

    Block header semantics and consensus rules

    +

    The following specification is accurate before NU5 activation. See 9 for header field changes in NU5.

    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 network upgrade that deploys this ZIP, 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] hashLightClientRoot MUST be \(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\) @@ -525,8 +569,9 @@ License: MIT

    Rationale

    Tree nodes

    -

    Nodes in the commitment tree are canonical and immutable. They are cheap to generate, as (with the exception of nSaplingTxCount) all metadata is already generated during block construction and/or checked during block validation. Nodes are relatively compact in memory. Approximately 140,000 blocks have elapsed since Sapling activation. Assuming a 164 byte commitment to each of these, we would have generated approximately 24 MB of additional storage cost for the set of leaf nodes (and an additional ~24 MB for storage of intermediate nodes).

    -

    hashSubtreeCommitment forms the strucuture of the commitment tree. Other metadata commitments were chosen to serve specific purposes. Variable-length commitments are placed last, so that most metadata in a node can be directly indexed. We considered using fixed-length commitments here, but opted for variable-length, in order to marginally reduce the memory requirements for managing and updating the commitment trees.

    +

    Nodes in the commitment tree are canonical and immutable. They are cheap to generate, as (with the exception of nSaplingTxCount and nOrchardTxCount) all metadata is already generated during block construction and/or checked during block validation. Nodes are relatively compact in memory. As of the original publication of this ZIP, approximately 140,000 blocks had elapsed since Sapling activation. Assuming a 164-byte commitment to each of these, we would have generated approximately 24 MB of additional storage cost for the set of leaf nodes (and an additional ~24 MB for storage of intermediate nodes).

    +

    hashSubtreeCommitment forms the strucuture of the commitment tree. Other metadata commitments were chosen to serve specific purposes. Originally variable-length commitments were placed last, so that most metadata in a node could be directly indexed. We considered using fixed-length commitments here, but opted for variable-length, in order to marginally reduce the memory requirements for managing and updating the commitment trees.

    +

    Orchard fields are placed last, in order to avoid complicating existing uses of the other fields.

    In leaf nodes, some information is repeated. We chose to do this so that leaf nodes could be treated identically to internal and root nodes for all algorithms and (de)serializers. Leaf nodes are easily identifiable, as they will show proof of work in the hashSubtreeCommitment field (which commits to the block hash for leaf nodes), and their block range (calculated as nLatestHeight - (nEarliestHeight - 1)) will be precisely 1.

    Personalized BLAKE2b-256 was selected to match existing Zcash conventions. Adding the consensus branch ID to the hash personalization string ensures that valid nodes from one consensus branch cannot be used to make false statements about parallel consensus branches.

    FlyClient Requirements and Recommendations

    @@ -569,12 +614,17 @@ License: MIT
  • If a future network upgrade introduced a new shielded pool, a new commitment to that pool's transactions would be added, to similarly enable future light clients that do not support Sapling addresses.
    • +
  • hashEarliestOrchardRoot, hashLatestOrchardRoot, and nOrchardTxCount +
      +
    • These are included with the same rationale as for Sapling.
      • +
    +

    • Header Format Change

    The primary goal of the original authors was to minimize header changes; in particular, they preferred not to introduce changes that could affect mining hardware or embedded software. Altering the block header format would require changes throughout the ecosystem, so we decided against adding hashChainHistoryRoot to the header as a new field.

    -

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

    +

    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." 12 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 @@ -590,10 +640,11 @@ License: MIT

    Generally, header commitments have no impact on privacy. However, FlyClient has additional security and privacy implications. Because FlyClient is a motivating factor for this ZIP, it seems prudent to include a brief overview. A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash.

    FlyClient, like all light clients, requires a connection to a light client server. That server may collect information about client requests, and may use that information to attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and publicly verifiable, they could be shared among many light clients after the initial server interaction.

    FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.

    -

    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.

    +

    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.

    Deployment

    -

    On the Zcash Mainnet and Testnet, 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. 10

    +

    Additional fields are added on activation of the NU5 network upgrade 11, to support the new Orchard shielded protocol.

    Additional Reading

    diff --git a/zip-0252.rst b/zip-0252.rst index 3f303a55..ea450d17 100644 --- a/zip-0252.rst +++ b/zip-0252.rst @@ -41,11 +41,13 @@ The primary sources of information about NU5 consensus protocol changes are: - The Zcash Protocol Specification [#protocol]_ - ZIP 200: Network Upgrade Mechanism [#zip-0200]_ -- ZIP 216: Require Canonical Point Encodings [#zip-0216]_ *proposed* -- ZIP 224: Orchard Shielded Protocol [#zip-0224]_ *proposed* -- ZIP 225: Version 5 Transaction Format [#zip-0225]_ *proposed* -- ZIP 244: Transaction Identifier Non-Malleability [#zip-0244]_ *proposed* +- ZIP 216: Require Canonical Point Encodings [#zip-0216]_ +- ZIP 221: FlyClient - Consensus-Layer Changes [#zip-0221]_ (amended) +- ZIP 224: Orchard Shielded Protocol [#zip-0224]_ +- ZIP 225: Version 5 Transaction Format [#zip-0225]_ +- ZIP 244: Transaction Identifier Non-Malleability [#zip-0244]_ - The Orchard Book [#orchard-book]_ +- The halo2 Book [#halo2-book]_ The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_ also apply to this upgrade. @@ -181,7 +183,9 @@ References .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0216] `ZIP 216: Require Canonical Point Encodings `_ +.. [#zip-0221] `ZIP 221: FlyClient - Consensus-Layer Changes `_ .. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_ .. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#orchard-book] `The Orchard Book `_ +.. [#halo2-book] `The halo2 Book `_