Dora currently provides a fork overview that fully backed by the heads of the connected clients.
This is useful to debug persistent forks that specific client types follow.
However, it is not very helpful to see actual chain splits that might have happened in past and is no longer followed by any client.
Background:
The new indexer introduced by #83 tracks chain forks internally (as it is needed for the canonical chain selection) and even persists a history of forks in DB.
A fork as tracked by the explorer consists of an increasing fork id, the base block slot/root, the leaf slot/root and the parent fork id.
Each chain split in the unfinalized slot range are tracked by 2 forks, so in a simple fork situation like this:
B C
| /
A
there are 2 fork entries created:
the first consists of parent A slot/root, leaf B slot/root & the forkId of A as parent forkId
the second consists of parent A slot/root, leaf C slot/root & the forkId of A as parent forkId
Fork relationships can be resolved via the parent fork id of each entry.
Finalized blocks are assigned to forkId 0 and fork entries with finalized leaf roots are removed.
Feature Request:
This information should be made accessible on the UI via a separate chain forks page.
The page should be capable of:
Show the most recent forks up to the finalization checkpoint
Visualize nested forks (maybe reuse the graph / list approach from the slots page)
Show the amount of blocks in each fork
Show fork participation for forks in unfinalized epochs (information not available after finalization)
Dora currently provides a fork overview that fully backed by the heads of the connected clients. This is useful to debug persistent forks that specific client types follow. However, it is not very helpful to see actual chain splits that might have happened in past and is no longer followed by any client.
Background: The new indexer introduced by #83 tracks chain forks internally (as it is needed for the canonical chain selection) and even persists a history of forks in DB. A fork as tracked by the explorer consists of an increasing fork id, the base block slot/root, the leaf slot/root and the parent fork id. Each chain split in the unfinalized slot range are tracked by 2 forks, so in a simple fork situation like this:
there are 2 fork entries created:
Fork relationships can be resolved via the parent fork id of each entry. Finalized blocks are assigned to forkId
0and fork entries with finalized leaf roots are removed.Feature Request: This information should be made accessible on the UI via a separate chain forks page. The page should be capable of: