Skip to content
Snippets Groups Projects
Select Git revision
  • 8002
  • 7999
  • 6137
  • gh-readonly-queue/master/pr-7916-1a514f6d3753189c21a6b68d38cc6289999de047 protected
  • master default protected
  • 6412
  • 8001
  • 7948
  • 8000
  • 7567
  • 7703
  • 7997
  • 7402
  • 7896
  • 7894
  • 7994
  • 7286
  • 7995
  • 7952
  • 7983
20 results
Search by author
  • Any Author
  • Aaro Altonen Aaro Altonen altonen
  • Administrator Administrator Admin0
  • Alexander Alexander alvicsam
  • Alexander Kalankhodzhaev Alexander Kalankhodzhaev kalaninja
  • Alexander Theißen Alexander Theißen athei
  • Alexandra Alexandra a13xndra
  • Alin Dima Alin Dima alindima
  • Andrew Jones Andrew Jones ascjones
  • André Silva André Silva andresilva
  • Anthony Lazam Anthony Lazam lazam
  • Anton Anton melekes
  • Anton Vilhelm Ásgeirsson Anton Vilhelm Ásgeirsson antonva
  • Arsham Teymouri Arsham Teymouri ArshamTeymouri
  • Artyom Bakhtin Artyom Bakhtin bakhtin
  • Bernardo A. Rodrigues Bernardo A. Rodrigues bernardoaraujor
  • Bradley Olson Bradley Olson BradleyOlson64
  • Branislav Kontur Branislav Kontur bkontur
  • Bulat Saifullin Bulat Saifullin BulatSaif
  • Chevdor Chevdor chevdor
  • Chris Kerr Chris Kerr piffle-rack
20 authors
  1. Feb 15, 2025
  3. Nov 07, 2024
    • Nazar Mokrynskyi's avatar
      Syncing strategy refactoring (part 3) (#5737) · 12d90524
      Nazar Mokrynskyi authored 
      # Description

This is a continuation of
https://github.com/paritytech/polkadot-sdk/pull/5666 that finally fixes
https://github.com/paritytech/polkadot-sdk/issues/5333.

This should allow developers to create custom syncing strategies or even
the whole syncing engine if they so desire. It also moved syncing engine
creation and addition of corresponding protocol outside
`build_network_advanced` method, which is something Bastian expressed as
desired in
https://github.com/paritytech/polkadot-sdk/issues/5#issuecomment-1700816458

Here I replaced strategy-specific types and methods in `SyncingStrategy`
trait with generic ones. Specifically `SyncingAction` is now used by all
strategies instead of strategy-specific types with conversions.
`StrategyKey` was an enum with a fixed set of options and now replaced
with an opaque type that strategies create privately and send to upper
layers as an opaque type. Requests and responses are now handled in a
generic way regardless of the strategy, which reduced and simplified
strategy API.

`PolkadotSyncingStrategy` now lives in its dedicated module (had to edit
.gitignore for this) like other strategies.

`build_network_advanced` takes generic `SyncingService` as an argument
alongside with a few other low-level types (that can probably be
extracted in the future as well) without any notion of specifics of the
way syncing is actually done. All the protocol and tasks are created
outside and not a part of the network anymore. It still adds a bunch of
protocols like for light client and some others that should eventually
be restructured making `build_network_advanced` just building generic
network and not application-specific protocols handling.

## Integration

Just like https://github.com/paritytech/polkadot-sdk/pull/5666
introduced `build_polkadot_syncing_strategy`, this PR introduces
`build_default_block_downloader`, but for convenience and to avoid
typical boilerplate a simpler high-level function
`build_default_syncing_engine` is added that will take care of creating
typical block downloader, syncing strategy and syncing engine, which is
what most users will be using going forward. `build_network` towards the
end of the PR was renamed to `build_network_advanced` and
`build_network`'s API was reverted to
pre-https://github.com/paritytech/polkadot-sdk/pull/5666, so most users
will not see much of a difference during upgrade unless they opt-in to
use new API.

## Review Notes

For `StrategyKey` I was thinking about using something like private type
and then storing `TypeId` inside instead of a static string in it, let
me know if that would preferred.

The biggest change happened to requests that different strategies make
and how their responses are handled. The most annoying thing here is
that block response decoding, in contrast to all other responses, is
dependent on request. This meant request had to be sent throughout the
system. While originally `Response` was `Vec<u8>`, I didn't want to
re-encode/decode request and response just to fit into that API, so I
ended up with `Box<dyn Any + Send>`. This allows responses to be truly
generic and each strategy will know how to downcast it back to the
concrete type when handling the response.

Import queue refactoring was needed to move `SyncingEngine` construction
out of `build_network` that awkwardly implemented for `SyncingService`,
but due to `&mut self` wasn't usable on `Arc<SyncingService>` for no
good reason. `Arc<SyncingService>` itself is of course useless, but
refactoring to replace it with just `SyncingService` was unfortunately
rejected in https://github.com/paritytech/polkadot-sdk/pull/5454

As usual I recommend to review this PR as a series of commits instead of
as the final diff, it'll make more sense that way.

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [x] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
) of this project (at minimum one label for `T` required)
* External contributors: ask maintainers to put the right label on your
PR.
* [x] I have made corresponding changes to the documentation (if
applicable)
      Unverified
      12d90524
  5. Oct 23, 2024
    • Kian Paimani's avatar
      Polkadot OmniNode Docs (#6094) · fc486e55
      Kian Paimani authored 
      provides low-level documentation on how the omni-node is meant to work.
This is meant to act as reusable material for other teams (e.g.
Papermoon and W3F) to use and integrate into the high level Polkadot
documentation.

Broadly speaking, for omni-node to have great rust-docs, we need to
focus on the following crates, all of which got a bit of love in this
PR:

1. `sp-genesis-builder`
2. `polkadot-omni-node`
3. `polkadot-omni-node-lib`
4. `frame-omni-bencher`

On top of this, we have now: 

* `polkadot_sdk_docs::guides` contains two new steps demonstrating the
most basic version of composing your pallet, putting it into a runtime,
and putting that runtime into omni-node
* `polkadot_sdk_docs::reference_docs::omni_node` to explain in more
detail how omni-node differs from the old-school node.
* `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to
finally have a minimal reference about weights and benchmarking.
* It provides tests for some of the steps in
https://g...
      Unverified
      fc486e55
  7. Oct 18, 2024
  9. Aug 28, 2024
    • Maksym H's avatar
      Command bot GHA v2 - /cmd <cmd> (#5457) · 8e0cefc8
      Maksym H authored 
      Closes https://github.com/paritytech/product-engineering/issues/93

- Deprecates old command bot bash scripts. New cmd implementation is
re-written on Python
- Deprecates `sync` command, which was never used
- Benchmarks:
- Uses new
[frame-omni-bencher](https://crates.io/crates/frame-omni-bencher)
- Simplifies usage to only providing a runtime and/or pallet name (even
multiple runtimes or pallets)
- Supports sub-modules (like `/cmd bench --runtime dev --pallet
pallet_asset_conversion_ops`)
- Can regenerate all weights with one command (substrate, polkadot,
cumulus) for provided pallet(s) name
- Adds [subweight](https://crates.io/crates/subweight-core) diff as a
result of bench command
      Unverified
      8e0cefc8
  11. Jul 17, 2024
  13. Dec 05, 2023
  15. Nov 08, 2023
    • Ignacio Palacios's avatar
      [xcm-emulator] Chains generic over Network & Integration tests restructure (#2092) · ffa0e30e
      Ignacio Palacios authored 
      Closes:
- #1383 
- Declared chains can be now be imported and reused in a different
crate.
- Chain declaration are now generic over a generic type `N` (the
Network)
- #1389
- Solved #1383, chains and networks declarations can be restructure to
avoid having to compile all chains when running integrations tests where
are not needed.
- Chains are now declared on its own crate (removed from
`integration-tests-common`)
- Networks are now declared on its own crate (removed from
`integration-tests-common`)
    - Integration tests will import only the relevant Network crate
- `integration-tests-common` is renamed to
`emulated-integration-tests-common`

All this is necessary to be able to implement what is described here:
https://github.com/paritytech/roadmap/issues/56#issuecomment-1777010553

---------

Co-authored-by: command-bot <>
      Unverified
      ffa0e30e
  17. Oct 16, 2023
    • Oliver Tale-Yazdi's avatar
      [CI] Add link checker (#1875) · e0e566bc
      Oliver Tale-Yazdi authored 
      
Adding link checker to the CI (closes
https://github.com/paritytech/polkadot-sdk/issues/993). It would be nice
to have the docs people own this and extend accordingly.
Currently all known-bad links are excluded, but we should one-by-one
include those as well until all are fixed.

This check now ensures that 1) no new broken links are introduced into
`.rs` files and 2) that no old links break unnoticed.

---------

Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Unverified
      e0e566bc
  19. Sep 04, 2023
  21. Aug 29, 2023
  23. Aug 25, 2023