mirror of https://github.com/zcash/zips.git
Fix typographical errors
This commit is contained in:
parent
f569d2863d
commit
5aa4db445c
12
zip-0221.rst
12
zip-0221.rst
|
@ -32,7 +32,7 @@ described in ZIP 200. [#zip-0200]_
|
||||||
where λ is the security parameter.
|
where λ is the security parameter.
|
||||||
|
|
||||||
*Merkle mountain range (MMR)*
|
*Merkle mountain range (MMR)*
|
||||||
A Merkle mountain range (MMR) is binary hash tree that allows for efficient appends of
|
A Merkle mountain range (MMR) is a binary hash tree that allows for efficient appends of
|
||||||
new leaves without changing the value of existing nodes.
|
new leaves without changing the value of existing nodes.
|
||||||
|
|
||||||
|
|
||||||
|
@ -128,7 +128,7 @@ algorithm:
|
||||||
/ \ / \ / \ / \ / \ \
|
/ \ / \ / \ / \ / \ \
|
||||||
0 0 1 3 4 7 8 10 11 15 16 18
|
0 0 1 3 4 7 8 10 11 15 16 18
|
||||||
|
|
||||||
The MMR tree allow for efficient incremental set update operations (push, pop, prune). In
|
MMR trees allow for efficient incremental set update operations (push, pop, prune). In
|
||||||
addition, MMR update operations and Merkle proofs for recent additions to the leaf set are
|
addition, MMR update operations and Merkle proofs for recent additions to the leaf set are
|
||||||
more efficient than other incremental Merkle tree implementations (e.g. Bitcoin's padded
|
more efficient than other incremental Merkle tree implementations (e.g. Bitcoin's padded
|
||||||
leafset, sparse Merkle trees, and Zcash's incremental note commitment trees).
|
leafset, sparse Merkle trees, and Zcash's incremental note commitment trees).
|
||||||
|
@ -264,6 +264,7 @@ Each MMR node is defined as follows:
|
||||||
* ``nLatestTimestamp`` is the header's timestamp
|
* ``nLatestTimestamp`` is the header's timestamp
|
||||||
|
|
||||||
- If the node is an internal or root node
|
- If the node is an internal or root node
|
||||||
|
|
||||||
* ``nLatestTimestamp`` is inherited from the right child
|
* ``nLatestTimestamp`` is inherited from the right child
|
||||||
|
|
||||||
- Note that due to timestamp consensus rules, ``nLatestTimestamp`` may be smaller than
|
- Note that due to timestamp consensus rules, ``nLatestTimestamp`` may be smaller than
|
||||||
|
@ -278,6 +279,7 @@ Each MMR node is defined as follows:
|
||||||
* ``nEarliestTarget`` is the header's ``nBits`` field
|
* ``nEarliestTarget`` is the header's ``nBits`` field
|
||||||
|
|
||||||
- If the node is an internal or root node
|
- If the node is an internal or root node
|
||||||
|
|
||||||
* ``nEarliestTarget`` is inherited from the left child
|
* ``nEarliestTarget`` is inherited from the left child
|
||||||
|
|
||||||
- serialized as ``nBits`` (``uint32``)
|
- serialized as ``nBits`` (``uint32``)
|
||||||
|
@ -289,6 +291,7 @@ Each MMR node is defined as follows:
|
||||||
* ``nLatestTarget`` is the header's ``nBits`` field
|
* ``nLatestTarget`` is the header's ``nBits`` field
|
||||||
|
|
||||||
- If the node is an internal or root node
|
- If the node is an internal or root node
|
||||||
|
|
||||||
* ``nLatestTarget`` is inherited from the right child
|
* ``nLatestTarget`` is inherited from the right child
|
||||||
|
|
||||||
- serialized as ``nBits`` (uint32)
|
- serialized as ``nBits`` (uint32)
|
||||||
|
@ -339,6 +342,7 @@ Each MMR node is defined as follows:
|
||||||
* ``nEarliestHeight`` is the header's height
|
* ``nEarliestHeight`` is the header's height
|
||||||
|
|
||||||
- If the node is an internal or root node
|
- If the node is an internal or root node
|
||||||
|
|
||||||
* ``nEarliestHeight`` is inherited from the left child
|
* ``nEarliestHeight`` is inherited from the left child
|
||||||
|
|
||||||
- serialized as ``CompactSize uint``
|
- serialized as ``CompactSize uint``
|
||||||
|
@ -564,7 +568,7 @@ This ZIP introduces a new header version. It is identical to the current v4 head
|
||||||
[#zcashBlock]_, except for the following changes:
|
[#zcashBlock]_, except for the following changes:
|
||||||
|
|
||||||
1. The version number is changed to `5`.
|
1. The version number is changed to `5`.
|
||||||
2. ``hashSaplingFinalRoot`` is replaced by ``hashChainHistoryRoot``, as described above.
|
2. ``hashFinalSaplingRoot`` is replaced by ``hashChainHistoryRoot``, as described above.
|
||||||
|
|
||||||
The new block header format is:
|
The new block header format is:
|
||||||
|
|
||||||
|
@ -657,7 +661,7 @@ the proper serialization and commitment format for the nullifier vector.
|
||||||
* This commitment serves the same purpose as ``hashFinalSaplingRoot`` in current Sapling
|
* This commitment serves the same purpose as ``hashFinalSaplingRoot`` in current Sapling
|
||||||
semantics.
|
semantics.
|
||||||
* However, because the MMR tree commits to blocks ``B_x ... B_(n-1)``, the latest
|
* However, because the MMR tree commits to blocks ``B_x ... B_(n-1)``, the latest
|
||||||
commitment will descrie the final treestate of the previous block, rather than the
|
commitment will describe the final treestate of the previous block, rather than the
|
||||||
current block.
|
current block.
|
||||||
* Concretely: block 500 currently commits to the final treestate of block 500 in its
|
* Concretely: block 500 currently commits to the final treestate of block 500 in its
|
||||||
header. With this ZIP, block 500 will commit to all roots up to block 499, but not the
|
header. With this ZIP, block 500 will commit to all roots up to block 499, but not the
|
||||||
|
|
Loading…
Reference in New Issue