Files
pezkuwi-subxt/substrate/client/db
Michal Kucharczyk 548955a73f BlockId removal: refactor: HeaderBackend::header (#12874)
* BlockId removal: refactor: HeaderBackend::header

It changes the arguments of:
- `HeaderBackend::header`,
- `Client::header`,
- `PeersClient::header`
- `ChainApi::block_header`

methods from: `BlockId<Block>` to: `Block::Hash`

This PR is part of BlockId::Number refactoring analysis (paritytech/substrate#11292)

* non-trivial usages of haeder(block_id) refactored

This may required introduction of dedicated function:
header_for_block_num

* fmt

* fix

* doc fixed

* ".git/.scripts/fmt.sh"

* BlockId removal: refactor: HeaderBackend::expect_header

It changes the arguments of `HeaderBackend::expect_header` method from: `BlockId<Block>` to: `Block::Hash`

* ".git/.scripts/fmt.sh"

* readme updated

* ".git/.scripts/fmt.sh"

* fix

Co-authored-by: parity-processbot <>
2022-12-20 09:43:31 +00:00
..
2022-12-19 07:38:51 +01: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