Conversation
|
I believe Teku will just report the finalized slot as the common ancestor if the fork is longer than I'm not against allowing |
Oh yeah, this is a good idea. It's important to report the finalized slot of the old head, since (in LH at least) it's possible for a new head to have an arbitrarily higher finalized slot. We had considered just returning a distance of the entire chain, which is a similar approach (e.g., overkill but safe). I'll go back to the drawing board and potentially open a new PR that makes it explicit that it's a maximum re-org distance. |
2 participants
We've been having a conversation about the reorg event
depthin sigp/lighthouse#2090.The problem is that computing the re-org distance involves finding the highest common ancestor of two blocks. This is a notoriously difficult problem in blockchains which is resistant to optimization and typically involves an
O(n)walk back through the chain.In Eth2, computing that re-org distance is quite easy if the re-org is not deeper than
SLOTS_PER_HISTORICAL_ROOT(8,192) blocks, since clients probably have all those block roots sitting in memory (they're in theBeaconState). However, once we go past 8,192 we're entering the territory of readingBeaconStates from the database or doing block-by-block reads from the DB.My concern is that if the chain is very unhealthy and the head is bouncing around then the BN is committed to constantly computing the correct re-org depth for consumers of the event stream. In this PR I've explicitly added the ability for nodes to return
nulland save themselves from entering thisO(n)search.