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

Merge pull request #520 from nuttycom/zip244-clarify_auth_tree 

ZIP 244: Clarify contruction of `hashAuthDataRoot`
This commit is contained in:
Daira Hopwood 2021-06-16 04:03:59 +01:00 committed by GitHub
parent 814ad87b40 604c40a5c0
commit 4fbf8e5da2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 31 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
zip-0244.html
View File

@ -3,6 +3,7 @@
<head>
<title>ZIP 244: Transaction Identifier Non-Malleability</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
@ -307,12 +308,13 @@ S.2d.iv: nSequence (4-byte unsigned little-endian)</pre>
</section>
</section>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new transaction digest algorithm is defined that constructs a digest which commits to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes. The overall structure of the hash is as follows:</p>
<p>A new transaction digest algorithm is defined that constructs a digest which commits to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes. For v5 transactions, the overall structure of the hash is as follows:</p>
<pre>auth_digest
├── transparent_scripts_digest
├── sapling_auth_digest
└── orchard_auth_digest</pre>
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of authorizing data of the transaction.</p>
<p>For transaction versions before v5, a placeholder value consisting of 32 bytes of <code>0xFF</code> is used in place of the authorizing data commitment. This is only used in the tree committed to by <code>hashAuthDataRoot</code>, as defined in <a href="#block-header-changes">Block Header Changes</a>.</p>
<p>The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.</p>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
@ -355,8 +357,14 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
</section>
<section id="block-header-changes"><h3><span class="section-heading">Block Header Changes</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-changes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The nonmalleable transaction identifier specified by this ZIP will be used in the place of the current malleable transaction identifier within the Merkle tree committed to by the <code>hashMerkleRoot</code> value. However, this change now means that <code>hashMerkleRoot</code> is not sufficient to fully commit to the transaction data, including witnesses, that appear within the block.</p>
<p>As a consequence, we now need to add a new commitment to the block header. This commitment will be the root of a Merkle tree that has parallel structure to the tree committed to by <code>hashMerkleRoot</code> (a path through this Merkle tree to a transaction identifies the same transaction as that path reaches in the tree rooted at <code>hashMerkleRoot</code>), but where the leaves are hashes produced according to the <cite>Authorizing Data Commitment</cite> part of this specification.</p>
<p>This new commitment is named <code>hashAuthDataRoot</code> and is the root of a left-dense binary Merkle tree of transaction authorizing data commitments. Empty internal nodes and leaves in the Merkle tree (nodes without children) have the "null" hash value <code>[0u8; 32]</code>. Hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
<p>As a consequence, we now need to add a new commitment to the block header. This commitment will be the root of a Merkle tree having leaves that are transaction authorizing data commitments, produced according to the <a href="#authorizing-data-commitment">Authorizing Data Commitment</a> part of this specification. The insertion order for this Merkle tree MUST be identical to the insertion order of transaction identifiers into the Merkle tree that is used to construct <code>hashMerkleRoot</code>, such that a path through this Merkle tree to a transaction identifies the same transaction as that path reaches in the tree rooted at <code>hashMerkleRoot</code>.</p>
<p>This new commitment is named <code>hashAuthDataRoot</code> and is the root of a binary Merkle tree of transaction authorizing data commitments having height
<span class="math">\(\mathsf{ceil(log_2(tx\_count))}\)</span>
, padded with leaves having the "null" hash value <code>[0u8; 32]</code>. Note that
<span class="math">\(\mathsf{log_2(tx\_count)}\)</span>
is well-defined because
<span class="math">\(\mathsf{tx\_count} &gt; 0\)</span>
, due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id15" class="footnote_reference" href="#zip-0221">3</a>, is changed.</p>
<p><code>hashLightClientRoot</code> is renamed to <code>hashBlockCommitments</code>. The value of this hash is the BLAKE2b-256 hash personalized by the string <code>"ZcashBlockCommit"</code> of the following elements:</p>
<pre>hashLightClientRoot (as described in ZIP 221)

32
zip-0244.rst
View File

@ -590,7 +590,7 @@ Authorizing Data Commitment
A new transaction digest algorithm is defined that constructs a digest which commits
to the authorizing data of a transaction from a tree of BLAKE2b-256 hashes.
The overall structure of the hash is as follows::
For v5 transactions, the overall structure of the hash is as follows::
auth_digest
├── transparent_scripts_digest
@ -600,6 +600,10 @@ The overall structure of the hash is as follows::
Each node written as ``snake_case`` in this tree is a BLAKE2b-256 hash of authorizing
data of the transaction.
For transaction versions before v5, a placeholder value consisting of 32 bytes of
``0xFF`` is used in place of the authorizing data commitment. This is only used in
the tree committed to by ``hashAuthDataRoot``, as defined in `Block Header Changes`_.
The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the
data of a serialized transaction that may be included in a block.
@ -683,18 +687,22 @@ change now means that ``hashMerkleRoot`` is not sufficient to fully commit
to the transaction data, including witnesses, that appear within the block.
As a consequence, we now need to add a new commitment to the block header.
This commitment will be the root of a Merkle tree that has parallel structure
to the tree committed to by ``hashMerkleRoot`` (a path through this Merkle
tree to a transaction identifies the same transaction as that path reaches
in the tree rooted at ``hashMerkleRoot``), but where the leaves are hashes
produced according to the `Authorizing Data Commitment` part of this
specification.
This commitment will be the root of a Merkle tree having leaves that are
transaction authorizing data commitments, produced according to the
`Authorizing Data Commitment`_ part of this specification. The insertion
order for this Merkle tree MUST be identical to the insertion order of
transaction identifiers into the Merkle tree that is used to construct
``hashMerkleRoot``, such that a path through this Merkle tree to a
transaction identifies the same transaction as that path reaches in the tree
rooted at ``hashMerkleRoot``.
This new commitment is named ``hashAuthDataRoot`` and is the root of a left-dense
binary Merkle tree of transaction authorizing data commitments. Empty internal nodes
and leaves in the Merkle tree (nodes without children) have the "null" hash value
``[0u8; 32]``. Hashes in this tree are BLAKE2b-256 hashes personalized by the string
``"ZcashAuthDatHash"``.
This new commitment is named ``hashAuthDataRoot`` and is the root of a
binary Merkle tree of transaction authorizing data commitments having height
:math:`\mathsf{ceil(log_2(tx\_count))}`, padded with leaves having the "null"
hash value ``[0u8; 32]``. Note that :math:`\mathsf{log_2(tx\_count)}` is
well-defined because :math:`\mathsf{tx\_count} > 0`, due to the coinbase
transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256
hashes personalized by the string ``"ZcashAuthDatHash"``.
Changing the block header format to allow space for an additional
commitment is somewhat invasive. Instead, the name and meaning of the