Skip to content
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 cleanups #4842

Merged
merged 4 commits into from
Jun 23, 2024
Merged

Conversation

nazar-pc
Copy link
Contributor

@nazar-pc nazar-pc commented Jun 20, 2024

I carried these things in a fork for a long time, I think wouldn't hurt to have it upstream.

Originally submitted as part of #1598 that went nowhere.

@bkchr bkchr added the R0-silent Changes should not be mentioned in any release notes label Jun 23, 2024
@bkchr bkchr requested a review from a team June 23, 2024 11:09
@bkchr bkchr enabled auto-merge June 23, 2024 11:09
@bkchr bkchr added this pull request to the merge queue Jun 23, 2024
Merged via the queue into paritytech:master with commit 686aa23 Jun 23, 2024
155 of 158 checks passed
@nazar-pc nazar-pc deleted the block-import-cleanups branch June 23, 2024 12:19
github-merge-queue bot pushed a commit that referenced this pull request Jun 26, 2024
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.
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
I carried these things in a fork for a long time, I think wouldn't hurt
to have it upstream.

Originally submitted as part of
paritytech#1598 that went nowhere.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants