search

paritytech / json-rpc-interface-spec

29 stars 3 forks source link

Are the finalized blocks not actually a subset of the best blocks reported prior? #103

Closed jsdw closed 1 year ago

jsdw commented 1 year ago

The spec says:

The current best block, in other words the last block reported through a bestBlockChanged event, is guaranteed to either be the last item in finalizedBlockHashes, or to not be present in either finalizedBlockHashes or prunedBlockHashes.

Two questions here:

  1. How can any block hash that is announced not be present in either finalizedBlockHashes or prunedBlockHashes? I thought from https://github.com/paritytech/json-rpc-interface-spec/issues/97 that when a finalized event comes in, all block hashes reported since the last finalized event will be either in the finalized or pruned list?
  2. Naively, I assumed that every block which is reported in finalizedBlockHashes would have also, at some point prior to that finalized event, have been repoted in the bestBlockChanged event. Is this not correct? Based on a test I ran against Substrate, this isn't true in practise (which may be the current implementation at fault, but the above question makes me thingk I am just misunderstanding how this is expected to work.
tomaka commented 1 year ago

I don't really understand your questions and I think that you're misinterpreting the sentence.

Naively, I assumed that every block which is reported in finalizedBlockHashes would have also, at some point prior to that finalized event, have been repoted in the bestBlockChanged event. Is this not correct?

Every block that is reported in finalizedBlockHashes is guaranteed to be in the "best chain", in other words is guaranteed to be an ancestor of the latest block that has been reported through bestBlockChanged.

The best block, however, can jump multiple blocks at the same time. The best block can for example be block 100 and then jump to block 102. Block 101 never gets reported as being the best block, but it's still in the best chain. Later, block 101 will be included in finalizedBlockHashes.

tomaka commented 1 year ago

How can any block hash that is announced not be present in either finalizedBlockHashes or prunedBlockHashes? I thought from https://github.com/paritytech/json-rpc-interface-spec/issues/97 that when a finalized event comes in, all block hashes reported since the last finalized event will be either in the finalized or pruned list?

What the sentence says is that when for example block 102 gets finalized, the current best block must be either that block 102 (i.e. equal to the last item of the finalized block hashes) or must be block 103, 104, 105 (i.e. not in either list). If the best block is 105, then it's not in the list of finalized and pruned blocks, since this list stops at block 102. But it might be in the future in a later finalized event.

jsdw commented 1 year ago

What the sentence says is that when for example block 102 gets finalized, the current best block must be either that block 102 (i.e. equal to the last item of the finalized block hashes) or must be block 103, 104, 105 (i.e. not in either list).

Ah yup, I was muddling things up in my head and that makes perfect sense, thank you!

The best block can for example be block 100 and then jump to block 102. Block 101 never gets reported as being the best block, but it's still in the best chain. Later, block 101 will be included in finalizedBlockHashes.

Aah got it; I was thinking that block 101 would have been reported as a best block at some point as well in this case, but it makes sense to me that some blocks can be part of the best chain but never themselves have been reported as best block now!

@tomaka thanks for clearing up my confusion :)