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

Move syncing code from sc-network-common to sc-network-sync #1912

Merged
merged 13 commits into from
Nov 1, 2023

Conversation

dmitry-markin
Copy link
Contributor

@dmitry-markin dmitry-markin commented Oct 17, 2023

This PR moves syncing-related code from sc-network-common to sc-network-sync.

Unfortunately, some parts are tightly integrated with networking, so they were left in sc-network-common for now:

  1. SyncMode in common/src/sync.rs (used in NetworkConfiguration).
  2. BlockAnnouncesHandshake, BlockRequest, BlockResponse, etc. in common/src/sync/message.rs (used in src/protocol.rs and src/protocol/message.rs).

More substantial refactoring is needed to decouple syncing and networking completely, including getting rid of the hardcoded sync protocol.

Release notes

Move syncing-related code from sc-network-common to sc-network-sync. Delete ChainSync trait as it's never used (the only implementation is accessed directly from SyncingEngine and exposes a lot of public methods that are not part of the trait). Some new trait(s) for syncing will likely be introduced as part of Sync 2.0 refactoring to represent syncing strategies.

Builds upon #1736.

@dmitry-markin dmitry-markin added R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”. labels Oct 17, 2023
@dmitry-markin dmitry-markin changed the title [draft] Move syncing code from sc-network-common to sc-network-sync Move syncing code from sc-network-common to sc-network-sync Oct 18, 2023
@dmitry-markin dmitry-markin marked this pull request as ready for review October 18, 2023 14:26
Copy link
Contributor

@altonen altonen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be silent. There are at least two external teams that are working on their own syncing implementations so this will likely affect them. At least the removal of ChainSync is something that should be mentioned, with a note that there will be some kind of new ChainSync trait in the near future.

@dmitry-markin dmitry-markin removed the R0-silent Changes should not be mentioned in any release notes label Oct 20, 2023
Copy link
Member

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. Just a little bit confused why some types are being made public?

@@ -206,24 +206,65 @@ struct GapSync<B: BlockT> {

/// Action that [`engine::SyncingEngine`] should perform after reporting imported blocks with
/// [`ChainSync::on_blocks_processed`].
enum BlockRequestAction<B: BlockT> {
pub enum BlockRequestAction<B: BlockT> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to make this public?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's consumed by SyncingEngine, that owns ChainSync.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But isn't this in the same crate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically, SyncingEngine is in the same root module as ChainSync, because ChainSync is defined in lib.rs. So pub is not needed at all (even as pub(crate)). Semantically, these types are public for SyncingEngine, so I feel inclined to highlight this with either pub or pub(crate).

pub(crate) is probably a better option, but may be it's also worth moving ChainSync to a separate chain_sync.rs file.

@bkchr would it be better to move ChainSync and its types to a separate file and use pub(crate) for types consumed by SyncingEngine?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bkchr would it be better to move ChainSync and its types to a separate file and use pub(crate) for types consumed by SyncingEngine?

Done. PR looks scary now due to moved code, but overall situation with ChainSync should have improved.

Copy link
Contributor Author

@dmitry-markin dmitry-markin Oct 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bkchr @altonen Could you have a look if moving ChainSync to a separate file worth it: 2511cfc?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pub(crate) is probably a better option, but may be it's also worth moving ChainSync to a separate chain_sync.rs file.

Yeah sorry for these dumb questions :P I should have realized that the module is private to the crate. Pub is fine by me here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking this reordering could've been done in another PR but whatever. SyncingEngine should be moved to sync/src/lib.rs but that can be done in another PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why SyncingEngine should be moved to the root module and not kept in it's own module, may be reexporting it in the root module?

@bkchr
Copy link
Member

bkchr commented Oct 29, 2023

with a note that there will be some kind of new ChainSync trait in the near future.

What is the status of completely getting rid off sync in the networking crate? Because ideally there should not exist a chain sync trait at all.

@dmitry-markin
Copy link
Contributor Author

with a note that there will be some kind of new ChainSync trait in the near future.

What is the status of completely getting rid off sync in the networking crate? Because ideally there should not exist a chain sync trait at all.

There won't be ChainSync trait in networking for sure. There may be some new traits for syncing in sc-network-sync though.

@bkchr
Copy link
Member

bkchr commented Oct 30, 2023

There may be some new traits for syncing in sc-network-sync though.

Do we really need to make sync itself generic? I don't think so? As this is some self contained implementation.

@altonen
Copy link
Contributor

altonen commented Oct 30, 2023

There may be some new traits for syncing in sc-network-sync though.

Do we really need to make sync itself generic? I don't think so? As this is some self contained implementation.

That is not the current plan at least. We are most likely going to introduce some traits for the strategies that we discussed earlier, simply to make the code easier to maintain and plug additional syncing implementations without major headache.

@bkchr
Copy link
Member

bkchr commented Oct 30, 2023

Okay :)

Copy link
Member

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving to its own file sounds reasonable!

}

#[cfg(test)]
mod test {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are at it, why not also move them into their own file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@dmitry-markin dmitry-markin merged commit 1cd6acd into master Nov 1, 2023
110 of 111 checks passed
@dmitry-markin dmitry-markin deleted the dm-get-rid-common-sync branch November 1, 2023 13:10
HCastano added a commit to entropyxyz/entropy-core that referenced this pull request Jan 20, 2024
HCastano added a commit to entropyxyz/entropy-core that referenced this pull request Jan 23, 2024
* Get `entropy-shared` compiling with updated deps

* Fix `entropy-shared` build for `wasm-no-std`

* Make `pallet-staking-extension` compile

Starts introducing some of the changes brought in by
paritytech/polkadot-sdk#1484.

* Introduce staking changes from paritytech/substrate#12970

* Add RuntimeFreezeReason from paritytech/polkadot-sdk#1900

* Re-map errors in staking extension pallet

* Bump `pallet-programs`

* Missed a crate dep for staking extension

* Remove commented out code

* Get `pallet-relayer` compiling

* Fix relayer test compilation

* Fix `pallet-free-tx`'s tests

* Reorder config types

* Bump `pallet-propagation` dependencies

* Bump `pallet-slashing` dependencies

* Bump `pallet-transaction-pause`

This includes the deprecation of `Balances::transfer` from
paritytech/polkadot-sdk#1226.

* TaploFmt

* Use `StakingAccount` instead of `.into()`

* Import `vec` macro in `pallet-slashing`

* Import `vec` in other pallets

* Bump TOML dependencies for runtime

Haven't fixed the Rust code yet though

* Self define types instead of using `node-primitives`

* Update staking related configs

Values were mostly taken from the Polkadot runtime config

* Update `pallet-preimage` config

Changes introduced in paritytech/polkadot-sdk#1363

* Add `MaxNominators` to `pallet_babe`

Introduced in paritytech/substrate#14471

* Add `MaxNominators` to `pallet_grandpa`

Also introduced in paritytech/substrate#14471

* Add `RuntimeFreezeReason` to `pallet_nomination_pools`

* Add `MaxTipAmount` to `pallet_tips`

Introduced in paritytech/polkadot-sdk#1709

* Add `IdentityInformation` to `pallet_identity`

Introduced in paritytech/polkadot-sdk#1661

* finish runtime

* Use `crates.io` packages in `entropy` TOML

This doesn't compile yet

* Remove reference to `node_primitives`

* Move imports under correct dependency section

These shouldn't be built-deps, my bad

* Change `WarpSyncParams` import to come from `sc_network_sync`

Change introduced here: paritytech/polkadot-sdk#1912

* Add missing `sc-consensus-babe` package

* Remove second generic from `DefaultImportQueue`

This was removed in paritytech/substrate#14612

* Add temporary cursed RPC bounds

* Switch `sp-consensus-grandpa` to be from Crates

* Add Grandpa justification period to service

* Rename `justification_period to` `justification_generation_period`

* Add missing `block_relay` param

Introduced in paritytech/polkadot-sdk#1524

* Try to clean up runtime types

* Add `opaque` types to runtime

These match what was in `node-primitives`. In particular we're interested in the `Block` type which
we were using in a lot of places, and I incorrectly changed to be `Unchechecked` instead of
`Opaque`.

* Use opaque block type in service

* Add full session key impls

* Remove cursed trait bounds for RPC

* Convert some tabs to spaces

Sorry, I had to

* Import `Vec` from `sp_std` in benchmarks

Turns out the issue responsible for this change is this:
paritytech/polkadot-sdk#172

* Pull `TrackedStorageKey` from `sp_storage`

From here: paritytech/substrate#14787

* Add `BenchmarkHelper` to treasury pallet

* TaploFmt

* change max freezes

* Sort TOML imports in runtime manifest

* Move `version` field to be first in runtime manifest

* Organize imports in pallet manifests

* Sort and organize imports for client

* Address TODOs in `entropy-shared`

* Remove TODOs related to `node-primitives`

* Pull `substrate-wasm-builder` from crates.io

* TaploFmt

* Fix benchmarking import post-merge

* Fix another program import port-merge

* Import `Vec` to programs benches

* Wrong vec import 🙃

* Poke CI

* Bump node metadata

---------

Co-authored-by: Jesse Abramowitz <[email protected]>
bgallois pushed a commit to duniter/duniter-polkadot-sdk that referenced this pull request Mar 25, 2024
…tytech#1912)

This PR moves syncing-related code from `sc-network-common` to
`sc-network-sync`.

Unfortunately, some parts are tightly integrated with networking, so
they were left in `sc-network-common` for now:

1. `SyncMode` in `common/src/sync.rs` (used in `NetworkConfiguration`).
2. `BlockAnnouncesHandshake`, `BlockRequest`, `BlockResponse`, etc. in
`common/src/sync/message.rs` (used in `src/protocol.rs` and
`src/protocol/message.rs`).

More substantial refactoring is needed to decouple syncing and
networking completely, including getting rid of the hardcoded sync
protocol.

## Release notes

Move syncing-related code from `sc-network-common` to `sc-network-sync`.
Delete `ChainSync` trait as it's never used (the only implementation is
accessed directly from `SyncingEngine` and exposes a lot of public
methods that are not part of the trait). Some new trait(s) for syncing
will likely be introduced as part of Sync 2.0 refactoring to represent
syncing strategies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T0-node This PR/Issue is related to the topic “node”.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants