Skip to content
  1. May 28, 2024
  2. May 27, 2024
  3. May 24, 2024
    • Branislav Kontur's avatar
    • Andrei Sandu's avatar
      availability-recovery: bump chunk fetch threshold to 1MB for Polkadot and 4MB... · f469fbfb
      Andrei Sandu authored
      availability-recovery: bump chunk fetch threshold to 1MB for Polkadot and 4MB for Kusama + testnets (#4399)
      
      Doing this change ensures that we minimize the CPU usage we spend in
      reed-solomon by only doing the re-encoding into chunks if PoV size is
      less than 4MB (which means all PoVs right now)
       
      Based on susbystem benchmark results we concluded that it is safe to
      bump this number higher. At worst case scenario the network pressure for
      a backing group of 5 is around 25% of the network bandwidth in hw specs.
      
      Assuming 6s block times (max_candidate_depth 3) and needed_approvals 30
      the amount of bandwidth usage of a backing group used would hover above
      `30 * 4 * 3 = 360MB` per relay chain block. Given a backing group of 5
      that gives 72MB per block per validator -> 12 MB/s.
      
      <details>
      <summary>Reality check on Kusama PoV sizes (click for chart)</summary>
      <br>
      <img width="697" alt="Screenshot 2024-05-07 at 14 30 38"
      src="https://github.com/paritytech/polkadot-sdk/assets/54316454/bfed32d4-8623-48b0-9ec0-8b95dd2a9d8c
      
      ">
      </details>
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      f469fbfb
    • Oliver Tale-Yazdi's avatar
      Polkadot-SDK Umbrella Crate (#3935) · 1c7a1a58
      Oliver Tale-Yazdi authored
      
      
      # Umbrella Crate
      
      The Polkadot-SDK "umbrella" is a crate that re-exports all other
      published crates. This makes it
      possible to have a very small `Cargo.toml` file that only has one
      dependency, the umbrella
      crate. This helps with selecting the right combination of crate
      versions, since otherwise 3rd
      party tools are needed to select a compatible set of versions.
      
      ## Features
      
      The umbrella crate supports no-std builds and can therefore be used in
      the runtime and node.
      There are two main features: `runtime` and `node`. The `runtime` feature
      enables all `no-std`
      crates, while the `node` feature enables all `std` crates. It should be
      used like any other
      crate in the repo, with `default-features = false`.
      
      For more fine-grained control, additionally, each crate can be enabled
      selectively. The umbrella
      exposes one feature per dependency. For example, if you only want to use
      the `frame-support`
      crate, you can enable the `frame-support` feature.
      
      The umbrella exposes a few more general features:
      - `tuples-96`: Needs to be enabled for runtimes that have more than 64
      pallets.
      - `serde`: Specifically enable `serde` en/decoding support.
      - `experimental`: Experimental enable experimental features - should not
      yet used in production.
      - `with-tracing`: Enable tracing support.
      - `try-runtime`, `runtime-benchmarks` and `std`: These follow the
      standard conventions.
      - `runtime`: As described above, enable all `no-std` crates.
      - `node`: As described above, enable all `std` crates.
      - There does *not* exist a dedicated docs feature. To generate docs,
      enable the `runtime` and
      `node` feature. For docs.rs the manifest contains specific configuration
      to make it show up
        all re-exports.
      
      There is a specific `zepter` check in place to ensure that the features
      of the umbrella are
      correctly configured. This check is run in CI and locally when running
      `zepter`.
      
      ## Generation
      
      The umbrella crate needs to be updated every time when a new crate is
      added or removed from the
      workspace. It is checked in CI by calling its generation script. The
      generation script is
      located in `./scripts/generate-umbrella.py` and needs dependency
      `cargo_workspace`.
      
      Example: `python3 scripts/generate-umbrella.py --sdk . --version 1.9.0`
      
      ## Usage
      
      > Note: You can see a live example in the `staging-node-cli` and
      `kitchensink-runtime` crates.
      
      The umbrella crate can be added to your runtime crate like this:
      
      `polkadot-sdk = { path = "../../../../umbrella", features = ["runtime"],
      default-features =
      false}`
      
      or for a node:
      
      `polkadot-sdk = { path = "../../../../umbrella", features = ["node"],
      default-features = false
      }`
      
      In the code, it is then possible to bring all dependencies into scope
      via:
      
      `use polkadot_sdk::*;`
      
      ### Known Issues
      
      The only known issue so far is the fact that the `use` statement brings
      the dependencies only
      into the outer module scope - not the global crate scope. For example,
      the following code would
      need to be adjusted:
      
      ```rust
      use polkadot_sdk::*;
      
      mod foo {
         // This does sadly not compile:
         frame_support::parameter_types! { }
      
         // Instead, we need to do this (or add an equivalent `use` statement):
         polkadot_sdk::frame_support::parameter_types! { }
      }
      ```
      
      Apart from this, no issues are known. There could be some bugs with how
      macros locate their own
      re-exports. Please compile issues that arise from using this crate.
      
      ## Dependencies
      
      The umbrella crate re-exports all published crates, with a few
      exceptions:
      - Runtime crates like `rococo-runtime` etc are not exported. This
      otherwise leads to very weird
        compile errors and should not be needed anyway.
      - Example and fuzzing crates are not exported. This is currently
      detected by checking the name
      of the crate for these magic words. In the future, it will utilize
      custom metadata, as it is
        done in the `rococo-runtime` crate.
      - The umbrella crate itself. Should be obvious :)
      
      ## Follow Ups
      - [ ] Re-writing the generator in Rust - the python script is at its
      limit.
      - [ ] Using custom metadata to exclude some crates instead of filtering
      by names.
      - [ ] Finding a way to setting the version properly. Currently its
      locked in the CI script.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      1c7a1a58
    • Oliver Tale-Yazdi's avatar
      Remove litep2p git dependency (#4560) · 49bd6a6e
      Oliver Tale-Yazdi authored
      @serban300
      
       could you please do the same for the MMR crate? Am not sure
      what commit was released since there are no release tags in the repo.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      49bd6a6e
    • Branislav Kontur's avatar
      Attempt to avoid specifying `BlockHashCount` for different... · ef144b1a
      Branislav Kontur authored
      Attempt to avoid specifying `BlockHashCount` for different `mocking::{MockBlock, MockBlockU32, MockBlockU128}` (#4543)
      
      While doing some migration/rebase I came in to the situation, where I
      needed to change `mocking::MockBlock` to `mocking::MockBlockU32`:
      ```
      #[derive_impl(frame_system::config_preludes::TestDefaultConfig)]
      impl frame_system::Config for TestRuntime {
      	type Block = frame_system::mocking::MockBlockU32<TestRuntime>;
      	type AccountData = pallet_balances::AccountData<ThisChainBalance>;
      }
      ```
      But actual `TestDefaultConfig` for `frame_system` is using `ConstU64`
      for `type BlockHashCount = frame_support::traits::ConstU64<10>;`
      [here](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L303).
      Because of this, it force me to specify and add override for `type
      BlockHashCount = ConstU32<10>`.
      
      This PR tries to fix this with `TestBlockHashCount` implementation for
      `TestDefaultConfig` which supports `u32`, `u64` and `u128` as a
      `BlockNumber`.
      
      ### How to simulate error
      Just by removing `type BlockHashCount = ConstU32<250>;`
      [here](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/multisig/src/tests.rs#L44)
      ```
      :~/parity/olkadot-sdk$ cargo test -p pallet-multisig
         Compiling pallet-multisig v28.0.0 (/home/bparity/parity/aaa/polkadot-sdk/substrate/frame/multisig)
      error[E0277]: the trait bound `ConstU64<10>: frame_support::traits::Get<u32>` is not satisfied
         --> substrate/frame/multisig/src/tests.rs:41:1
          |
      41  | #[derive_impl(frame_system::config_preludes::TestDefaultConfig)]
          | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `frame_support::traits::Get<u32>` is not implemented for `ConstU64<10>`
          |
          = help: the following other types implement trait `frame_support::traits::Get<T>`:
                    <ConstU64<T> as frame_support::traits::Get<u64>>
                    <ConstU64<T> as frame_support::traits::Get<std::option::Option<u64>>>
      note: required by a bound in `frame_system::Config::BlockHashCount`
         --> /home/bparity/parity/aaa/polkadot-sdk/substrate/frame/system/src/lib.rs:535:24
          |
      535 |         type BlockHashCount: Get<BlockNumberFor<Self>>;
          |                              ^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `Config::BlockHashCount`
          = note: this error originates in the attribute macro `derive_impl` which comes from the expansion of the macro `frame_support::macro_magic::forward_tokens_verbatim` (in Nightly builds, run with -Z macro-backtrace for more info)
      
      For more information about this error, try `rustc --explain E0277`.
      error: could not compile `pallet-multisig` (lib test) due to 1 previous error 
      ```
      
      
      
      
      ## For reviewers:
      
      (If there is a better solution, please let me know!)
      
      The first commit contains actual attempt to fix the problem:
      https://github.com/paritytech/polkadot-sdk/commit/3c5499e539f2218503fbd6ce9be085b03c31ee13.
      The second commit is just removal of `BlockHashCount` from all other
      places where not needed by default.
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/1657
      
      
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      ef144b1a
    • Serban Iorga's avatar
      Use polkadot-ckb-merkle-mountain-range dependency (#4562) · 700d5910
      Serban Iorga authored
      We need to use the `polkadot-ckb-merkle-mountain-range` dependency
      published on `crates.io` in order to unblock the release of the
      `sp-mmr-primitives` crate
      700d5910
  4. May 23, 2024
  5. May 22, 2024