zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update zip-0221.rst 

Co-authored-by: Deidre Connolly <deirde@zfnd.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Deirdre Connolly 2021-03-30 09:54:04 -04:00 committed by Daira Hopwood
parent 5c6ab07f15
commit 0d67dcf681
2 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
zip-0221.html
View File

@ -571,7 +571,7 @@ License: MIT</pre>
<section id="tree-nodes"><h3><span class="section-heading">Tree nodes</span><span class="section-anchor"> <a rel="bookmark" href="#tree-nodes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Nodes in the commitment tree are canonical and immutable. They are cheap to generate, as (with the exception of <code>nSaplingTxCount</code> and <code>nOrchardTxCount</code>) 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).</p>
<p><code>hashSubtreeCommitment</code> 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.</p>
<p>Open issue: currently Orchard fields are placed last; should they be placed between the existing fields? See <a href="https://github.com/zcash/zips/issues/476">zcash/zips#476</a>.</p>
<p>Orchard fields are placed last, in order to avoid complicating existing uses of the other fields.</p>
<p>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 <code>hashSubtreeCommitment</code> field (which commits to the block hash for leaf nodes), and their block range (calculated as <code>nLatestHeight</code> - (<code>nEarliestHeight</code> - 1)) will be precisely 1.</p>
<p>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.</p>
<section id="flyclient-requirements-and-recommendations"><h4><span class="section-heading">FlyClient Requirements and Recommendations</span><span class="section-anchor"> <a rel="bookmark" href="#flyclient-requirements-and-recommendations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>

4
zip-0221.rst
View File

@ -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 <https://github.com/zcash/zips/issues/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.