mirror of https://github.com/zcash/zips.git
Merge pull request #520 from nuttycom/zip244-clarify_auth_tree
ZIP 244: Clarify contruction of `hashAuthDataRoot`
This commit is contained in:
commit
4fbf8e5da2
|
@ -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} > 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
32
zip-0244.rst
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue