Closed josepot closed 1 year ago
bestBlockHash
is guaranteed to be equal either to the current finalized block hash, or to a block reported in an earlier newBlock event.
Actually, never mind: the case in which I considered it to be unknown is in fact when the best-block points to the currently finalized block. So, this is clearly intentional. I guess that it makes sense.
I was under the impression that the best-block was supposed to always point to a block which is not yet finalized, which is the one that's the most likely to become the next finalized block. However, I supposed that it makes sense for the best-block to point to the current finalized one while it can't be known which one it is the block that's most likely to become the next finalized block? 🤔
It is intended, and happens actually commonly whenever a parachain stalls.
I am currently enhancing the
@polkadot-api/client
by integrating support for the "best block". This feature's implementation was deferred due to its complexity, particularly because the best block operations differ significantly in their trade-offs and guarantees for users. These operations are primarily suited for optimistic-updates, with the understanding that any ongoing operations on a best block that fails to achieve finalized status will result in a known, documented error, followed by the immediate unpinning of the block.However, while implementing the best block API, I've encountered a potential ambiguity in the current specification: the best block can occasionally be unknown. This raises a question: Is this a deliberate aspect of the design, or an oversight in the specification?
If it's an oversight: A possible solution could be to introduce a new field in the
finalized
event to indicate the subsequent best block. This addition would ensure continuity in the best-block stream of data.If it's intentional: Understanding this as a design choice could simplify my implementation approach. In this case, I would consider to temporarily exclude notifying users about best-blocks which introduce new runtimes, until they become finalized (if they do).
Your insights on whether this is an intentional aspect of the design or an oversight would greatly aid in steering the implementation in the right direction.
cc: @tomaka