While we call it a blockchain, it's actually a tree of block headers. fork-observer shows the chain tips of one or multiple nodes and what other stale or invalid blocks it knows about. However, fork-observer doesn't keep any information on what a node historically considered as a valid tip and when that changed. To have data on reorgs (i.e. a node changing the branch it considers as valid) and to be able to replay them (either visually, or in a textual log), it would be useful to have a timestamped, per-node activity log of:
- when the block a node considers as tip changes
- when a node adds a header to it's chain
- when a node becomes unreachable (and reachable again)
- ... (maybe more)
A good starting point are the places where update_cache() is called:
|
// Update node tips in cache |
|
update_cache( |
|
&caches_clone, |
|
network.id, |
|
CacheUpdate::NodeTips { |
|
node_id: node.info().id, |
|
tips: tips.clone(), |
|
}, |
|
&cache_changed_tx_cloned, |
|
) |
|
.await; |
The fork-observer database is a SQLite database. An approach is to persist the activity log in one or more SQL tables. Probably, an activity_log table for a timestamp, node_id, activity_id and a table with activity specific information for each type of activity.
An implementation should come with an API that allows fetching recent activity log entries. Having a way of re-playing the activity log state changes visually (maybe on a different page) would be super nice, but might be out-of-scope for this issue and an initial implementation.
It would also be nice to be able to enable the activity log either per network (e.g. we want it on mainnet, but don't care about it on testnet4, as there's a lot of not-so-important reorg activity going on) or per node. Per node might be preferable as it's more granular.
While we call it a blockchain, it's actually a tree of block headers. fork-observer shows the chain tips of one or multiple nodes and what other stale or invalid blocks it knows about. However, fork-observer doesn't keep any information on what a node historically considered as a valid tip and when that changed. To have data on reorgs (i.e. a node changing the branch it considers as valid) and to be able to replay them (either visually, or in a textual log), it would be useful to have a timestamped, per-node activity log of:
A good starting point are the places where
update_cache()is called:fork-observer/src/main.rs
Lines 289 to 299 in a6e2956
The fork-observer database is a SQLite database. An approach is to persist the activity log in one or more SQL tables. Probably, an
activity_logtable for atimestamp,node_id,activity_idand a table with activity specific information for each type of activity.An implementation should come with an API that allows fetching recent activity log entries. Having a way of re-playing the activity log state changes visually (maybe on a different page) would be super nice, but might be out-of-scope for this issue and an initial implementation.
It would also be nice to be able to enable the activity log either per network (e.g. we want it on mainnet, but don't care about it on testnet4, as there's a lot of not-so-important reorg activity going on) or per node. Per node might be preferable as it's more granular.