From 0d67dcf681e4f0bde76c24650cea9d00f17dd519 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Tue, 30 Mar 2021 09:54:04 -0400 Subject: [PATCH] Update zip-0221.rst Co-authored-by: Deidre Connolly Signed-off-by: Daira Hopwood --- zip-0221.html | 2 +- zip-0221.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0221.html b/zip-0221.html index fba7a6bb..fe6aba25 100644 --- a/zip-0221.html +++ b/zip-0221.html @@ -571,7 +571,7 @@ License: MIT

Tree nodes

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.

-

Open issue: currently Orchard fields are placed last; should they be placed between the existing fields? See zcash/zips#476.

+

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

diff --git a/zip-0221.rst b/zip-0221.rst index 18bf7965..852a3e80 100644 --- a/zip-0221.rst +++ b/zip-0221.rst @@ -605,8 +605,8 @@ were placed last, so that most metadata in a node could be directly indexed. We 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. -Open issue: currently Orchard fields are placed last; should they be placed between the -existing fields? See `zcash/zips#476 `_. +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.