Spec for ordering block parent CIDs by ticket #289
Conversation
validation.md
Outdated
| A syntactically valid block: | ||
|
|
||
| - must include a well-formed miner address | ||
| - must include at least one well-formed ticket |
There was a problem hiding this comment.
the chain of tickets should be checkable at this point.
|
Hold off on landing this for me: see discussion in #285 |
expected-consensus.md
Outdated
| @@ -321,6 +321,8 @@ All valid blocks generated in a round form a `TipSet` that participants will att | |||
|
|
|||
| The first condition implies that all blocks in a TipSet were mined at the same height (remember that height refers to block height as opposed to ticket round). This rule is key to helping ensure that EC converges over time. While multiple new blocks can be mined in a round, subsequent blocks all mine off of a TipSet bringing these blocks together. The second rule means blocks in a TipSet are mined in a same round. | |||
|
|
|||
| The blocks in a tipset are canonically ordered by ticket. | |||
There was a problem hiding this comment.
I had thought we settled on making the order not matter at all?
There was a problem hiding this comment.
This line refers to the logical ordering, the order of processing in consensus state transitions, rather than the "syntactic" requirement (or not) for ordering in the block header. Can I clarify that in the text more?
For the block header, I was waiting for your call in #285 whether to order by CID or not at all.
There was a problem hiding this comment.
Ah, okay. I think that what we want to say is that there is no ordering enforced for tipsets, but during state computation, we apply the transitions of blocks in a tipset ordered by their tickets.
anorth
force-pushed
the
anorth/tipset
branch
2 times, most recently
from
7f3b72e to
ce8dabb
Compare
|
@whyrusleeping ready to land |
| @@ -303,6 +301,9 @@ To create a block, the eligible miner must compute a few fields: | |||
| - `ReceiptsRoot` - To compute this: | |||
| - Apply the set of messages selected above to the parent state, collecting invocation receipts as this happens. | |||
| - Insert them into a Merkle Tree and take its root. | |||
| - `Timestamp` - A Unix Timestamp generated at block creation. We use an unsigned integer to represent a UTC timestamp (in seconds). The Timestamp in the newly created block must satisfy the following conditions: | |||
There was a problem hiding this comment.
curious why the timestamp was moved. It's not a big deal, but it feels a little odd now being between the message stuff, and the signature aggregation (Which is kinda part of the messages flow). So this now reads "apply all the messages, collect their receipts, GO SET A TIMESTAMP, then take all the signatures from those messages and aggregate them together"
There was a problem hiding this comment.
I moved it to align with the field order in the block header. I agree its a bit awkward but was aiming for consistency. I'm happy to undo this here, but opine that it should be re-ordered in the block header to come earlier.
|
(P.S. I'm not authorized to merge, so do land it for me if ok, or push over it) |
…ticket order when processed.
|
Please merge me @whyrusleeping |
|
Sorry for the delay, was a busy week last week |
As discussed in slack. If this validation proves onerous in implementation we may elect to declare the ordering irrelevant to tipset equivalence, and order lexicographically in the block header instead (at the cost of having two distinct concepts of parent set).
Closes #285
CC @gnunicorn.