Block import and verification refactoring #4844
Conversation
…block_metered` such that they can be used independently
…fication-refactoring # Conflicts: # cumulus/client/consensus/aura/Cargo.toml
|
@nazar-pc I think you need to include more crates into the PRDoc to make the CI semver check pass. Can you see the semver job output? |
|
Hm... I think For others I agree that it needs to change after reading docs, but not sure if major or minor. I'm leaning towards major, any objections? |
Yes, breaking for sure, we should make the decision, CI is just a suggestion. You can put |
0ed3f04
|
Appreciate quick review, folks 👍 |
A few refactorings to block import and block verification that should not be controversial. Block verification before block import is stateless by design as described in https://substrate.stackexchange.com/a/1322/25 and the fact that it wasn't yet I consider to be a bug. Some code that requires it had to use `Mutex`, but I do not expect it to have a measurable performance impact. Similarly with block import checking whether block preconditions should not be an exclusive operation, there is nothing fundamentally wrong with checking a few competing blocks whose parent blocks exist at the same time (and even import them concurrently later, though IIRC this is not yet implemented either). They were originally a part of paritytech#4842 and upstreaming will help us to reduce the size of the patch we need to apply on top of upstream code at Subspace every time we upgrade. There are no new features introduced here, just refactoring to get rid of unnecessary requirements.
Trivial leftover from #4844 Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
…block()` (paritytech#5339) There was no need for it to be `&mut self` since block import can happen concurrently for different blocks and in many cases it was `&mut Arc<dyn BlockImport>` anyway 🤷♂️ Similar in nature to paritytech#4844
A few refactorings to block import and block verification that should not be controversial.
Block verification before block import is stateless by design as described in https://substrate.stackexchange.com/a/1322/25 and the fact that it wasn't yet I consider to be a bug. Some code that requires it had to use
Mutex, but I do not expect it to have a measurable performance impact.Similarly with block import checking whether block preconditions should not be an exclusive operation, there is nothing fundamentally wrong with checking a few competing blocks whose parent blocks exist at the same time (and even import them concurrently later, though IIRC this is not yet implemented either).
They were originally a part of #4842 and upstreaming will help us to reduce the size of the patch we need to apply on top of upstream code at Subspace every time we upgrade. There are no new features introduced here, just refactoring to get rid of unnecessary requirements.