Change posterity notation #20
Conversation
|
While on the subject of revising this file I wanna point out another minor issue: Regarding proof of publication, it currently says "Merkle proof that txn is in C's ATMR". The ATMR does not actually contain the transactions of the corresponding block, rather only the accepted txs of its mergeset. These makes for a subtler concept where it is proven that a tx was accepted according to some block at some point, but maybe not according to the selected chain. Also, in the code I currently use the terms post_posterity and pre_posterity rather than prev and next. Not crucial but its nice if there is consistency between code and kip. I prefer mine because I always find the word next a tad ambiguous. |
freshair18
left a comment
freshair18
left a comment
There was a problem hiding this comment.
Change fixes important ambiguities which made the kip harder to comprehend.
I believe next and prev are still a bit ambiguous - I'd recommend pre and post instead.
| # Size of PoChM | ||
|
|
||
| Computing the actual size of a PoChM is a bit tricky, as it depends on the number of *chain* blocks between ``C`` and ``next_posterity(C)`` for several blocks ``C``. Buy staring at the KGI for sufficiently long, one can get convinced that the selected chain grows by about one block every two seconds (that is, in 1BPS we see that about half of the blocks are chain blocks). To provide a reliable upper bound, I will assume that the selected chain grows at a rate of about 1 block per second. Note that the growth of the selected chain is not governed by block rates, but by network conditions. Hence, I assume this holds with overwhelming probability for any block rate. This might not hold if network conditions improve greatly. However, we'll soon see that the growth asymptotics (as a function of the number of chain blocks between two consecutive posterity blocks) are a very mild log*loglog, whereby this is hardly a concern. I will demonstrate this with concrete numbers after we obtain an expression for the size of a PoChM. | ||
| Computing the actual size of a PoChM is a bit tricky, as it depends on the number of *chain* blocks between ``C`` and ``prev_posterity(C)`` for several blocks ``C``. Buy staring at the KGI for sufficiently long, one can get convinced that the selected chain grows by about one block every two seconds (that is, in 1BPS we see that about half of the blocks are chain blocks). To provide a reliable upper bound, I will assume that the selected chain grows at a rate of about 1 block per second. Note that the growth of the selected chain is not governed by block rates, but by network conditions. Hence, I assume this holds with overwhelming probability for any block rate. This might not hold if network conditions improve greatly. However, we'll soon see that the growth asymptotics (as a function of the number of chain blocks between two consecutive posterity blocks) are a very mild log*loglog, whereby this is hardly a concern. I will demonstrate this with concrete numbers after we obtain an expression for the size of a PoChM. |
There was a problem hiding this comment.
I think in this particular instance it should have stayed next_posterity
| * Each block ``B`` contains a pointer to ``prev_posterity(prev_posterity(prev_posterity(B)))``. Hence, the chain of posterity headers is verifiable all the way down to genesis. In particular, obtaining and verifying the posterity chain is part of the process of syncing a new node. | ||
|
|
||
| The reason that ``B`` points to ``posterity(posterity(posterity(B)))`` and not is ``posterity(B)`` that the original motivation for storing these blocks comes from the pruning mechanism, where these depth-3 pointers are required (for reasons outside the scope of the current discussion). | ||
| The reason that ``B`` points to ``prev_posterity(prev_posterity(prev_posterity(B)))`` and not is ``next_posterity(B)`` that the original motivation for storing these blocks comes from the pruning mechanism, where these depth-3 pointers are required (for reasons outside the scope of the current discussion). |
There was a problem hiding this comment.
I think this sentence as a whole should be rewritten or removed.
| * They are determined in consensus. That is, all nodes store the same posterity headers. | ||
| * They are headers of blocks in the *selected chain*. | ||
| * Each block ``B`` contains a pointer to ``posterity(posterity(posterity(B)))``. Hence, the chain of posterity headers is verifiable all the way down to genesis. In particular, obtaining and verifying the posterity chain is part of the process of syncing a new node. | ||
| * Each block ``B`` contains a pointer to ``prev_posterity(prev_posterity(prev_posterity(B)))``. Hence, the chain of posterity headers is verifiable all the way down to genesis. In particular, obtaining and verifying the posterity chain is part of the process of syncing a new node. |
| Given a block ``B`` let ``next_posterity(B)`` be the *earliest* posterity header such that ``B ∈ Past(next_posterity(B))``, or ``null`` if such a stored header does not exist yet. Let ``posterity_depth(B)`` output the integer ``n`` satisfying ``B=parent(next_posterity(B),n)``. | ||
|
|
||
| For any block ``B`` let ``next_posterity(B)`` be the block header with the following property: if ``B`` is a posterity header, then ``next_posterity(B)`` is the next posterity header. Note that this is well-defined even if ``B`` is not a posterity header. | ||
| For any block ``B`` let ``prev_posterity(B)`` be the block header with the following property: if ``B`` is a posterity header, then ``prev_posterity(B)`` is the next posterity header. Note that this is well-defined even if ``B`` is not a posterity header. |
There was a problem hiding this comment.
still ambiguous, should possibly be the " the latest posterity header in B's past".
The note makes no sense to me. this should be defined in a way that disregards whether B was posterity or not
| However, this introduces additional costs. Currently, posterity headers double as pruning headers. Decoupling them from each other means that an additional ``posterity header`` would have to be added, increasing the header size to 312 bytes. In addition, this decoupling is tricky engineering-wise and is probably more complicated to implement than the entire rest of the KIP. | ||
|
|
||
| I recommend first implementing the current KIP using the current posterity/pruning header, and deciding on separating posterity headers with increased density later, based on demand and necessity. It might also be the case that the additional pointer might be removed (i.e. the pruning mechanism will somehow piggyback on the posterity blocks in a way that doesn't have computational costs). This should be subject of an independent discussion, to be concluded in a follow-up KIP. | ||
|
|
There was a problem hiding this comment.
Line 139: the ATMR does not actually contain the transactions of the corresponding block, rather only the accepted txs of its mergeset. These makes for a subtler concept where it is proven that a tx was accepted according to some block at some point, but maybe not according to the selected chain.
Maybe this concept has merits of itself but I don't see them as of now and surely the intention was not for it - so it should be changed to "merkle proof that txn is in C's block transactions" or something of this line, and the section on atmr should also change accordingly.
2 participants
No description provided.