Files
pezkuwi-subxt/substrate/client/db
Bastian Köcher cc4b5c4818 Finality notification: Optimize calculation of stale heads (#11200)
* Finality notification: Optimize calculation of stale heads

While looking into some problem on Versi where a collator seemed to be stuck. I found out that it
was not stuck but there was a huge gap between last finalized and best block. This lead to a lot
leaves and it was basically trapped inside some loop of reading block headers from the db to find
the stale heads. While looking into this I found out that `leaves` already supports the feature to
give us the stale heads relative easily. However, the semantics change a little bit. Instead of
returning all stale heads of blocks that are not reachable anymore after finalizing a block, we
currently only return heads with a number lower than the finalized block. This should be no problem,
because these other leaves that are stale will be returned later when a block gets finalized which
number is bigger than the block number of these leaves.

While doing that, I also changed `tree_route` of the `FinalityNotification` to include the
`old_finalized`. Based on the comment I assumed that this was already part of it. However, if
wanted, I can revert this change.

* FMT

* Update client/service/src/client/client.rs

Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>

* Do not include the last finalized block

* Rename function

* FMT

* Fix tests

* Update figure

Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
2022-04-12 13:12:53 +02:00
..
2020-08-20 17:04:42 +02:00

Client backend that is backed by a database.

Canonicality vs. Finality

Finality indicates that a block will not be reverted, according to the consensus algorithm, while canonicality indicates that the block may be reverted, but we will be unable to do so, having discarded heavy state that will allow a chain reorganization.

Finality implies canonicality but not vice-versa.

License: GPL-3.0-or-later WITH Classpath-exception-2.0