First two screenshots are clearly taken at different times, but beyond that there is indeed a possibility for different farmers to have different finalized block.
First of all, finalized block makes no sense for Subspace protocol. The protocol has probabilistic finality like Bitcoin, so in principle there can’t be any finalized block. In practice however reference implementation refuses to reorg to blocks below archiving depth (100 blocks), so anything at the depth of 100 blocks is effectively final even though technically it is not.
With this context you might be wondering why isn’t finalized block always -100 from the best block?
The short answer is this is a Substratism that we will be fixing (see Make node use bounded amount of space on disk · Issue #2114 · autonomys/subspace · GitHub and issues linked from there).
The longer answer is that to solve farmer’s dilemma, we need to make sure nodes are using bounded amount of disk space. This implies that as blockchain is growing we’ll need to prune old blocks and corresponding state. The historical data can still be retrieved later due to Subspace consensus being built on Proof-of-Archival-Storage, meaning farmers are storing the history of the blockchain itself. However, durability of the history is not the same for deep history and more recent history, so we configure node to store a few segments worth of data to improve redundancy and to allow nodes that were only able to download second last segment during sync to download the rest of the blocks from nodes directly.
There is a problem though, Substrate doesn’t have an API for this. Today Substrate only allows to specify an offset from the finalized block, but doesn’t allow us to provide a custom logic that decides what blocks to prune. This means we have to artificially delay this “finalization” just to keep blocks in node’s database for a little longer. This is why you see finalized block being fixed and then jump ahead every time new segment is archived.
But wait, there is more! Specifically, there is Snap sync. During Snap sync node only downloads only pieces from the last archived segment of the history and since those blocks were archived they are by definition final, which is why you will temporarily see much higher “finalized” block for nodes that just synced with Snap sync. Over time they will fall back to the same block number as everyone else.
Once we add corresponding APIs to Substrate itself, we’ll make blocks “finalized” at 100 blocks depth, but until then above is the answer to this seemingly simple, but actually a bit complicated question.
3 Likes