docs: proposal for HFC simplification #1299
Conversation
nfrisby
requested review from
jasagredo,
amesgen,
fraser-iohk and
dnadales
as code owners
|
|
||
| - In particular, CP ensures that the k+1st youngest block on the selection of any of those nodes is also already on the selection of all the other nodes and will remain there forever. | ||
| The block might not yet be the k+1st youngest on the other nodes' selections. | ||
| But none of these nodes will never need to switch away from its k+1st youngest block. |
There was a problem hiding this comment.
| But none of these nodes will never need to switch away from its k+1st youngest block. | |
| But none of these nodes will ever need to switch away from its k+1st youngest block. |
| - Assume the ledger rules prevent any block from altering the leader schedule before a delay of one CG stability window and that, accordingly, ChainSync validates upstream peers' headers by forecasting the leadership schedule from the intersection of the peer's chain and the node's selection. | ||
|
|
||
| - In particular, this implies that the Ledger's governance for transitioning to the next era can also be forecasted by at least a stability window, since era transitions may affect the leader schedule. | ||
|
|
||
| - According to CG, this ensures the nodes will be able to validate at least k+1 blocks of an honest upstream peer's chain, which would suffice to incur the deepest intersection possibly allowed by CP. | ||
| Even so, the above rule is a reasonable behavior when the peer's chain violates CG: the number of validatable headers after the intersection is proportional to the severity of the CG violation. |
There was a problem hiding this comment.
There might be an additional requirement that the era transition is known even more than a stability window ahead of the epoch boundary: #385 (comment)
The Slack thread mention there has no reply so far.
| In less extreme cases, the documentation could say "you might see non-monotonic answers if using an acquired ledger state that does not have more than k blocks past the voting deadline". | ||
| A middle ground might be annotating the answer with the corresponding probability from IOG's latest official publication of the table of settlement times. | ||
|
|
||
| - In the Praos and Genesis nodes, there is no use of wall clock times beyond the header future check, slot leadership check, and queries discussed above. |
There was a problem hiding this comment.
There actually is one in the (legacy) logic for determining which mode BlockFetch shall use:
This sounds very minor; we can either remove it completely (and just rely on the GSM instead), or replace the current ad-hoc slot different with an ad-hoc wallclock time difference.
| - The ChainSync client should annotate the validated header with the wall clock translation (eg UTC time) of the header's slot's onset (translated accorded to its own chain). | ||
| This information can be used by performance monitors, etc. | ||
|
|
||
| - Node initialization from the on-disk block database is the only other means by which blocks arrive at the node, so the re-application/re-validation logic used there should also yield wall clock annotations on the node's selected header chain. |
There was a problem hiding this comment.
FYI @dnadales as we recently talked about this. In particular, attaching slot times to the selected chain would supersede your work in having different header types in BlockFetchConsensusInterface as discussed.
| 3b) add HLQ mitigations | ||
| 3c) more exotic/subtle: change block counting to be a disjunct instead of a conjunct prevents Just -> Nothing (since that only arises when switching to a denser chain) | ||
|
|
||
| 4) remove block counting, remove double stability, and add HLQ mitigations |
There was a problem hiding this comment.
What about adding a few examples for illustration, ie what would be the result of doing time translations/forecasts in different areas of an epoch when there is (no) era transition.
A proposal for simplifying the HFC logic. Related to #389.