consensus: update sketch implementation plan for Ouroboros Genesis #3063
Conversation
nfrisby
added
consensus
|
That discussion didn't reach any conclusions, so we'll be having more. This PR just writes-up what came up during that first meeting. |
nfrisby
force-pushed
the
nfrisby/update-genesis-plan
branch
from
b4b331b to
a4ae12f
Compare
nfrisby
force-pushed
the
nfrisby/update-genesis-plan
branch
from
a4ae12f to
d37ce79
Compare
|
I've added a draft commit with another overall sketch -- this one reflects much additional thought about what exactly BlockFetch can and can't do, when we should respect the peers' claimed tips, and related timeouts. |
nfrisby
force-pushed
the
nfrisby/update-genesis-plan
branch
from
d37ce79 to
ec33107
Compare
| true). | ||
|
|
||
| - TODO Do we actually need that exception? Under what circumstances | ||
| would it be relevant, during Syncing? |
There was a problem hiding this comment.
If their latest header is beyond our forecast range that means it is more than 3k/f slots ahead of the intersection from our chain. Can't we in that case already decide which one is denser as it is also the length of the genesis window?
| block (which the honest nodes would always do, up to their immutable | ||
| tip), then they're allowed to be somewhat slower, since we'll | ||
| disconnect from them if either they don't deliver that block or if | ||
| the eventual densest chain does not include that block. |
There was a problem hiding this comment.
I assume this is the case but I want to confirm it. We are going to disconnect from adversarial peers and then wait until we reconnect to enough peers to continue?
| disconnect from them if either they don't deliver that block or if | ||
| the eventual densest chain does not include that block. | ||
|
|
||
| - A possible refinment: each peer can offer _jump points_ that are |
There was a problem hiding this comment.
This will happen in ChainSync, right?
| hold back at least one of the other conjuncts. On the other hand, it | ||
| seems fine if we do need this, because of the timeout discussed | ||
| above. | ||
|
|
There was a problem hiding this comment.
Wouldn't we also consider the case when the wallclock is closer than a genesis window length from the first intersection with out chain? In that case every chain tip is necessarily inside the genesis window, and we judge based on length. Or maybe this case is redundant with cases above.
There was a problem hiding this comment.
This probably would also imply the opposite situation, when the wallclock is further than a genesis window length from the [last?] intersection with our chain it means that if block production is not halted, all the forks will fill the genesis window and then we can decide on the only chain that is the honest one.
| interaction. | ||
|
|
||
| - TODO Sketch: we transition as soon N (?) of our peers' tips have a | ||
| time point that is more than LIM (?) behind our wallclock. |
There was a problem hiding this comment.
As mentioned above, not sure if this would have to be something like "the intersection is a genesis window length behind our wallclock"
|
Closing; migrated to IntersectMBO/ouroboros-consensus#487 |
Update the sketched plan after our discussion on 2021 April 13 and again on 2021 August 9 and 2021 August 12.