-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block import and verification refactoring #4844
Block import and verification refactoring #4844
Conversation
…block_metered` such that they can be used independently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall the changes look good!
…fication-refactoring # Conflicts: # cumulus/client/consensus/aura/Cargo.toml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied review suggestions and added prdoc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks a lot!
@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 <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
…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.