Skip to content
  1. Apr 12, 2024
    • Adrian Catangiu's avatar
      pallet-xcm: add new extrinsic for asset transfers using explicit XCM transfer types (#3695) · 1e971b8d
      Adrian Catangiu authored
      
      
      # Description
      
      Add `transfer_assets_using()` for transferring assets from local chain
      to destination chain using explicit XCM transfer types such as:
      - `TransferType::LocalReserve`: transfer assets to sovereign account of
      destination chain and forward a notification XCM to `dest` to mint and
      deposit reserve-based assets to `beneficiary`.
      - `TransferType::DestinationReserve`: burn local assets and forward a
      notification to `dest` chain to withdraw the reserve assets from this
      chain's sovereign account and deposit them to `beneficiary`.
      - `TransferType::RemoteReserve(reserve)`: burn local assets, forward XCM
      to `reserve` chain to move reserves from this chain's SA to `dest`
      chain's SA, and forward another XCM to `dest` to mint and deposit
      reserve-based assets to `beneficiary`. Typically the remote `reserve` is
      Asset Hub.
      - `TransferType::Teleport`: burn local assets and forward XCM to `dest`
      chain to mint/teleport assets and deposit them to `beneficiary`.
      
      By default, an asset's reserve is its origin chain. But sometimes we may
      want to explicitly use another chain as reserve (as long as allowed by
      runtime `IsReserve` filter).
      
      This is very helpful for transferring assets with multiple configured
      reserves (such as Asset Hub ForeignAssets), when the transfer strictly
      depends on the used reserve.
      
      E.g. For transferring Foreign Assets over a bridge, Asset Hub must be
      used as the reserve location.
      
      # Example usage scenarios
      
      ## Transfer bridged ethereum ERC20-tokenX between ecosystem parachains.
      
      ERC20-tokenX is registered on AssetHub as a ForeignAsset by the
      Polkadot<>Ethereum bridge (Snowbridge). Its asset_id is something like
      `(parents:2, (GlobalConsensus(Ethereum), Address(tokenX_contract)))`.
      Its _original_ reserve is Ethereum (only we can't use Ethereum as a
      reserve in local transfers); but, since tokenX is also registered on
      AssetHub as a ForeignAsset, we can use AssetHub as a reserve.
      
      With this PR we can transfer tokenX from ParaA to ParaB while using
      AssetHub as a reserve.
      
      ## Transfer AssetHub ForeignAssets between parachains
      
      AssetA created on ParaA but also registered as foreign asset on Asset
      Hub. Can use AssetHub as a reserve.
      
      And all of the above can be done while still controlling transfer type
      for `fees` so mixing assets in same transfer is supported.
      
      # Tests
      
      Added integration tests for showcasing:
      - transferring local (not bridged) assets from parachain over bridge
      using local Asset Hub reserve,
      - transferring foreign assets from parachain to Asset Hub,
      - transferring foreign assets from Asset Hub to parachain,
      - transferring foreign assets from parachain to parachain using local
      Asset Hub reserve.
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      1e971b8d
    • Andrei Sandu's avatar
      Runtime API: introduce `candidates_pending_availability` (#4027) · 2dfe5f74
      Andrei Sandu authored
      Fixes https://github.com/paritytech/polkadot-sdk/issues/3576
      
      
      
      Required by elastic scaling collators.
      Deprecates old API: `candidate_pending_availability`.
      
      TODO:
      - [x] PRDoc
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      2dfe5f74
    • Xiliang Chen's avatar
      establish_channel_with_system (#3721) · b1db5f3a
      Xiliang Chen authored
      Implements https://github.com/polkadot-fellows/RFCs/issues/82
      
      
      Allow any parachain to have bidirectional channel with any system
      parachains
      
      Looking for initial feedbacks before continue finish it
      
      TODOs:
      - [x] docs
      - [x] benchmarks
      - [x] tests
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      b1db5f3a
  2. Apr 11, 2024
  3. Apr 10, 2024
  4. Apr 09, 2024
  5. Apr 08, 2024
    • Léa Narzis's avatar
    • Aaro Altonen's avatar
      Integrate litep2p into Polkadot SDK (#2944) · 80616f6d
      Aaro Altonen authored
      [litep2p](https://github.com/altonen/litep2p) is a libp2p-compatible P2P
      networking library. It supports all of the features of `rust-libp2p`
      that are currently being utilized by Polkadot SDK.
      
      Compared to `rust-libp2p`, `litep2p` has a quite different architecture
      which is why the new `litep2p` network backend is only able to use a
      little of the existing code in `sc-network`. The design has been mainly
      influenced by how we'd wish to structure our networking-related code in
      Polkadot SDK: independent higher-levels protocols directly communicating
      with the network over links that support bidirectional backpressure. A
      good example would be `NotificationHandle`/`RequestResponseHandle`
      abstractions which allow, e.g., `SyncingEngine` to directly communicate
      with peers to announce/request blocks.
      
      I've tried running `polkadot --network-backend litep2p` with a few
      different peer configurations and there is a noticeable reduction in
      networking CPU usage. For high load (`--out-peers 200`), networking CPU
      usage goes down from ~110% to ~30% (80 pp) and for normal load
      (`--out-peers 40`), the usage goes down from ~55% to ~18% (37 pp).
      
      These should not be taken as final numbers because:
      
      a) there are still some low-hanging optimization fruits, such as
      enabling [receive window
      auto-tuning](https://github.com/libp2p/rust-yamux/pull/176
      
      ), integrating
      `Peerset` more closely with `litep2p` or improving memory usage of the
      WebSocket transport
      b) fixing bugs/instabilities that incorrectly cause `litep2p` to do less
      work will increase the networking CPU usage
      c) verification in a more diverse set of tests/conditions is needed
      
      Nevertheless, these numbers should give an early estimate for CPU usage
      of the new networking backend.
      
      This PR consists of three separate changes:
      * introduce a generic `PeerId` (wrapper around `Multihash`) so that we
      don't have use `NetworkService::PeerId` in every part of the code that
      uses a `PeerId`
      * introduce `NetworkBackend` trait, implement it for the libp2p network
      stack and make Polkadot SDK generic over `NetworkBackend`
        * implement `NetworkBackend` for litep2p
      
      The new library should be considered experimental which is why
      `rust-libp2p` will remain as the default option for the time being. This
      PR currently depends on the master branch of `litep2p` but I'll cut a
      new release for the library once all review comments have been
      addresses.
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      80616f6d
    • Oliver Tale-Yazdi's avatar
      [FRAME] Runtime Omni Bencher (#3512) · 9543d314
      Oliver Tale-Yazdi authored
      This MR contains two major changes and some maintenance cleanup.  
      
      ## 1. Free Standing Pallet Benchmark Runner
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3045, depends
      on your runtime exposing the `GenesisBuilderApi` (like
      https://github.com/paritytech/polkadot-sdk/pull/1492).
      
      Introduces a new binary crate: `frame-omni-bencher`.  
      It allows to directly benchmark a WASM blob - without needing a node or
      chain spec.
      
      This makes it much easier to generate pallet weights and should allow us
      to remove bloaty code from the node.
      It should work for all FRAME runtimes that dont use 3rd party host calls
      or non `BlakeTwo256` block hashing (basically all polkadot parachains
      should work).
      
      It is 100% backwards compatible with the old CLI args, when the `v1`
      compatibility command is used. This is done to allow for forwards
      compatible addition of new commands.
      
      ### Example (full example in the Rust docs)
      
      Installing the CLI:
      ```sh
      cargo install --locked --path substrate/utils/frame/omni-bencher
      frame-omni-bencher --help
      ```
      
      Building the Westend runtime:
      ```sh
      cargo build -p westend-runtime --release --features runtime-benchmarks
      ```
      
      Benchmarking the runtime:
      ```sh
      frame-omni-bencher v1 benchmark pallet --runtime target/release/wbuild/westend-runtime/westend_runtime.compact.compressed.wasm --all
      ```
      
      ## 2. Building the Benchmark Genesis State in the Runtime
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/2664
      
      This adds `--runtime` and `--genesis-builder=none|runtime|spec`
      arguments to the `benchmark pallet` command to make it possible to
      generate the genesis storage by the runtime. This can be used with both
      the node and the freestanding benchmark runners. It utilizes the new
      `GenesisBuilder` RA and depends on having
      https://github.com/paritytech/polkadot-sdk/pull/3412
      
       deployed.
      
      ## 3. Simpler args for `PalletCmd::run`
      
      You can do three things here to integrate the changes into your node:
      - nothing: old code keeps working as before but emits a deprecated
      warning
      - delete: remove the pallet benchmarking code from your node and use the
      omni-bencher instead
      - patch: apply the patch below and keep using as currently. This emits a
      deprecated warning at runtime, since it uses the old way to generate a
      genesis state, but is the smallest change.
      
      ```patch
      runner.sync_run(|config| cmd
      -    .run::<HashingFor<Block>, ReclaimHostFunctions>(config)
      +    .run_with_spec::<HashingFor<Block>, ReclaimHostFunctions>(Some(config.chain_spec))
      )
      ```
      
      ## 4. Maintenance Change
      - `pallet-nis` get a `BenchmarkSetup` config item to prepare its
      counterparty asset.
      - Add percent progress print when running benchmarks.
      - Dont immediately exit on benchmark error but try to run as many as
      possible and print errors last.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      9543d314
    • Egor_P's avatar
      Github workflow to automate release draft creation (#3978) · 216509db
      Egor_P authored
      
      
      This PR introduces the github flow which will create a release draft
      automatically when the rc tag is pushed. The flow contains the following
      steps:
      
      - Gets the info about rust version used to build the node
      - Builds the runtimes using `srtool`
      - Extracts the info about each runtime 
      - Aggregates the changelog from the prdocs
      - Creates the release draft containing all the info related to the
      release (changelog, runtimes, rust versions)
      - Attaches the runtimes to the draft
      - Posts the message to the RelEng internal channel to inform that the
      build is done.
      
      Related to the #3295
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      216509db
    • Sebastian Kunert's avatar
      Add best block indicator to informant message + print parent block on import message (#4021) · fdb1dba2
      Sebastian Kunert authored
      Sometimes you need to debug some issues just by the logs and reconstruct
      what happened.
      In these scenarios it would be nice to know if a block was imported as
      best block, and what it parent was.
      So here I propose to change the output of the informant to this:
      
      ```
      2024-04-05 20:38:22.004  INFO ⋮substrate: [Parachain]  Imported #18 (0xe7b3…4555 -> 0xbd6f…ced7)    
      2024-04-05 20:38:24.005  INFO ⋮substrate: [Parachain]  Imported #19 (0xbd6f…ced7 -> 0x4dd0…d81f)    
      2024-04-05 20:38:24.011  INFO ⋮substrate: [jobless-children-5352] 🌟 Imported #42 (0xed2e…27fc -> 0x718f…f30e)    
      2024-04-05 20:38:26.005  INFO ⋮substrate: [Parachain]  Imported #20 (0x4dd0…d81f -> 0x6e85…e2b8)    
      2024-04-05 20:38:28.004  INFO ⋮substrate: [Parachain] 🌟 Imported #21 (0x6e85…e2b8 -> 0xad53…2a97)    
      2024-04-05 20:38:30.004  INFO ⋮substrate: [Parachain] 🌟
      
       Imported #22 (0xad53…2a97 -> 0xa874…890f)    
      ```
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      fdb1dba2
    • Bastian Köcher's avatar
      sc-beefy-consensus: Remove unneeded stream. (#4015) · c1063a53
      Bastian Köcher authored
      The stream was just used to communicate from the validator the peer
      reports back to the gossip engine. Internally the gossip engine just
      forwards these reports to the networking engine. So, we can just do this
      directly.
      
      The reporting stream was also pumped [in the worker behind the
      engine](https://github.com/paritytech/polkadot-sdk/blob/9d6261892814fa27c97881c0321c008d7340b54b/substrate/client/consensus/beefy/src/worker.rs#L939).
      This means if there was a lot of data incoming over the engine, the
      reporting stream was almost never processed and thus, it could have
      started to grow and we have seen issues around this.
      
      Partly Closes: https://github.com/paritytech/polkadot-sdk/issues/3945
      c1063a53
    • Tsvetomir Dimitrov's avatar
      Deprecate `para_id()` from `CoreState` in polkadot primitives (#3979) · 59f868d1
      Tsvetomir Dimitrov authored
      With Coretime enabled we can no longer assume there is a static 1:1
      mapping between core index and para id. This mapping should be obtained
      from the scheduler/claimqueue on block by block basis.
      
      This PR modifies `para_id()` (from `CoreState`) to return the scheduled
      `ParaId` for occupied cores and removes its usages in the code.
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3948
      
      
      
      ---------
      
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      59f868d1
  6. Apr 06, 2024
  7. Apr 05, 2024
  8. Apr 04, 2024
    • Ermal Kaleci's avatar
      Update pr_3844.prdoc (#3988) · 5fb43978
      Ermal Kaleci authored
      5fb43978
    • Michal Kucharczyk's avatar
      `GenesisConfig` presets for runtime (#2714) · f910a15c
      Michal Kucharczyk authored
      The runtime now can provide a number of predefined presets of
      `RuntimeGenesisConfig` struct. This presets are intended to be used in
      different deployments, e.g.: `local`, `staging`, etc, and should be
      included into the corresponding chain-specs.
      
      Having `GenesisConfig` presets in runtime allows to fully decouple node
      from runtime types (the problem is described in #1984).
      
      **Summary of changes:**
      - The `GenesisBuilder` API was adjusted to enable this functionality
      (and provide better naming - #150):
         ```rust
          fn preset_names() -> Vec<PresetId>;
      fn get_preset(id: Option<PresetId>) -> Option<serde_json::Value>;
      //`None` means default
          fn build_state(value: serde_json::Value);
          pub struct PresetId(Vec<u8>);
         ```
      
      - **Breaking change**: Old `create_default_config` method was removed,
      `build_config` was renamed to `build_state`. As a consequence a node
      won't be able to interact with genesis config for older runtimes. The
      cleanup was made for sake of API simplicity. Also IMO maintaining
      compatibility with old API is not so crucial.
      - Reference implementation was provided for `substrate-test-runtime` and
      `rococo` runtimes. For rococo new
      [`genesis_configs_presets`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/genesis_config_presets.rs#L530)
      module was added and is used in `GenesisBuilder`
      [_presets-related_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/lib.rs#L2462-L2485)
      methods.
      
      - The `chain-spec-builder` util was also improved and allows to
      ([_doc_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/bin/utils/chain-spec-builder/src/lib.rs#L19)):
         - list presets provided by given runtime (`list-presets`),
      - display preset or default config provided by the runtime
      (`display-preset`),
         - build chain-spec using named preset (`create ... named-preset`),
      
      
      - The `ChainSpecBuilder` is extended with
      [`with_genesis_config_preset_name`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/client/chain-spec/src/chain_spec.rs#L447)
      method which allows to build chain-spec using named preset provided by
      the runtime. Sample usage on the node side
      [here](https://github.com/paritytech/polkadot-sdk/blob/2caffaae803e08a3d5b46c860e8016da023ff4ce/polkadot/node/service/src/chain_spec.rs#L404
      
      ).
      
      Implementation of #1984.
      fixes: #150
      part of: #25
      
      ---------
      
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      f910a15c
    • Branislav Kontur's avatar
      Added support for coretime-kusama/polkadot and people-kusama/polkadot (#3961) · 68cdb126
      Branislav Kontur authored
      ## Running  `./polkadot-parachain --chain coretime-kusama` works now:
      
      **Parachain genesis state and header** match expected ones from
      https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5009857#gistcomment-5009857
      ```
      2024-04-03 12:03:58 [Parachain] 🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) 
      ...
      2024-04-03 12:04:04 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050)
      ```
      
      **Relaychain genesis state and header** match expected ones:
      https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0
      
      ```
      2024-04-03 12:03:59 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe)    
      ```
      
      
      
      
      
      **Full logs:**
      ```
      bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/polkadot-sdk$ ./target/debug/polkadot-parachain --chain coretime-kusama
      2024-04-03 12:03:52 Polkadot parachain    
      2024-04-03 12:03:52 ️  version 4.0.0-665e3654    
      2024-04-03 12:03:52 ️  by Parity Technologies <[email protected]>, 2017-2024    
      2024-04-03 12:03:52 📋 Chain specification: Kusama Coretime    
      2024-04-03 12:03:52 🏷  Node name: subsequent-quicksand-2382    
      2024-04-03 12:03:52 👤 Role: FULL    
      2024-04-03 12:03:52 💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/coretime-kusama/db/full    
      2024-04-03 12:03:54 Parachain id: Id(1005)    
      2024-04-03 12:03:54 Parachain Account: 5Ec4AhPakEiNWFbAd26nRrREnaGQZo3uukPDC5xLr6314Dwg    
      2024-04-03 12:03:54 Is collating: no    
      2024-04-03 12:03:58 [Parachain] 🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050)    
      2024-04-03 12:03:59 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe)    
      2024-04-03 12:03:59 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
      2024-04-03 12:03:59 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup.    
      2024-04-03 12:03:59 [Relaychain] 🏷  Local node identity is: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd    
      2024-04-03 12:03:59 [Relaychain] 💻 Operating system: linux    
      2024-04-03 12:03:59 [Relaychain] 💻 CPU architecture: x86_64    
      2024-04-03 12:03:59 [Relaychain] 💻 Target environment: gnu    
      2024-04-03 12:03:59 [Relaychain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz    
      2024-04-03 12:03:59 [Relaychain] 💻 CPU cores: 4    
      2024-04-03 12:03:59 [Relaychain] 💻 Memory: 31797MB    
      2024-04-03 12:03:59 [Relaychain] 💻 Kernel: 5.15.0-101-generic    
      2024-04-03 12:03:59 [Relaychain] 💻 Linux distribution: Ubuntu 20.04.6 LTS    
      2024-04-03 12:03:59 [Relaychain] 💻 Virtual machine: no    
      2024-04-03 12:03:59 [Relaychain] 📦 Highest known block at #0    
      2024-04-03 12:03:59 [Relaychain] ️ Prometheus exporter started at 127.0.0.1:9616    
      2024-04-03 12:03:59 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]    
      2024-04-03 12:03:59 [Relaychain] 🏁 CPU score: 1.40 GiBs    
      2024-04-03 12:03:59 [Relaychain] 🏁 Memory score: 15.42 GiBs    
      2024-04-03 12:03:59 [Relaychain] 🏁 Disk score (seq. writes): 1.39 GiBs    
      2024-04-03 12:03:59 [Relaychain] 🏁 Disk score (rand. writes): 690.56 MiBs    
      2024-04-03 12:03:59 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs    
      2024-04-03 12:03:59 [Parachain] 🏷  Local node identity is: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW    
      2024-04-03 12:03:59 [Parachain] 💻 Operating system: linux    
      2024-04-03 12:03:59 [Parachain] 💻 CPU architecture: x86_64    
      2024-04-03 12:03:59 [Parachain] 💻 Target environment: gnu    
      2024-04-03 12:03:59 [Parachain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz    
      2024-04-03 12:03:59 [Parachain] 💻 CPU cores: 4    
      2024-04-03 12:03:59 [Parachain] 💻 Memory: 31797MB    
      2024-04-03 12:03:59 [Parachain] 💻 Kernel: 5.15.0-101-generic    
      2024-04-03 12:03:59 [Parachain] 💻 Linux distribution: Ubuntu 20.04.6 LTS    
      2024-04-03 12:03:59 [Parachain] 💻 Virtual machine: no    
      2024-04-03 12:03:59 [Parachain] 📦 Highest known block at #0    
      2024-04-03 12:03:59 [Parachain] ️ Prometheus exporter started at 127.0.0.1:9615    
      2024-04-03 12:03:59 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]    
      2024-04-03 12:03:59 [Parachain] 🏁 CPU score: 1.40 GiBs    
      2024-04-03 12:03:59 [Parachain] 🏁 Memory score: 15.42 GiBs    
      2024-04-03 12:03:59 [Parachain] 🏁 Disk score (seq. writes): 1.39 GiBs    
      2024-04-03 12:03:59 [Parachain] 🏁 Disk score (rand. writes): 690.56 MiBs    
      2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/192.168.1.100/tcp/30334/ws    
      2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/192.168.1.100/tcp/30333/ws    
      2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.18.0.1/tcp/30333/ws    
      2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.17.0.1/tcp/30334/ws    
      2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.17.0.1/tcp/30333/ws    
      2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.18.0.1/tcp/30334/ws    
      2024-04-03 12:04:00 [Relaychain] 🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd    
      2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate    
      2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate    
      2024-04-03 12:04:04 [Relaychain] ️  Syncing, target=#22575321 (7 peers), best: #738 (0x1803…bbef), finalized #512 (0xb9b6…7014),  328.5kiB/s  102.9kiB/s    
      2024-04-03 12:04:04 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),  0  0    
      2024-04-03 12:04:09 [Relaychain] ️  Syncing 169.5 bps, target=#22575322 (8 peers), best: #1586 (0x405b…a8aa), finalized #1536 (0x55d1…fb04),  232.3kiB/s  55.9kiB/s    
      2024-04-03 12:04:09 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),  0  0    
      2024-04-03 12:04:14 [Relaychain] ️  Syncing 168.0 bps, target=#22575323 (8 peers), best: #2426 (0x155f…d083), finalized #2048 (0xede6…f879),  235.8kiB/s  67.2kiB/s    
      2024-04-03 12:04:14 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),  0  0    
      2024-04-03 12:04:19 [Relaychain] ️  Syncing 170.0 bps, target=#22575324 (8 peers), best: #3276 (0x94d8…097e), finalized #3072 (0x0e4c…f587),  129.0kiB/s  34.0kiB/s
      ...
      ```
      
      ## Running  `./polkadot-parachain --chain people-kusama` works now:
      
      **Parachain genesis state and header** match expected ones from
      https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5011798#gistcomment-5011798
      ```
      2024-04-04 10:26:24 [Parachain] 🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645)    
      ...
      2024-04-04 10:26:30 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),  0  0    
      ```
      
      **Relaychain genesis state and header** match expected ones:
      https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0
      
      ```
      2024-04-04 10:26:25 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe)  
      ```
      
      
      
      
      
      **Full logs:**
      ```
      bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/aaa/polkadot-sdk$ ./target/debug/polkadot-parachain --chain people-kusama
      2024-04-04 10:26:18 Polkadot parachain    
      2024-04-04 10:26:18 ️  version 4.0.0-39274bb7    
      2024-04-04 10:26:18 ️  by Parity Technologies <[email protected]>, 2017-2024    
      2024-04-04 10:26:18 📋 Chain specification: Kusama People    
      2024-04-04 10:26:18 🏷  Node name: knotty-flight-5398    
      2024-04-04 10:26:18 👤 Role: FULL    
      2024-04-04 10:26:18 💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/people-kusama/db/full    
      2024-04-04 10:26:21 Parachain id: Id(1004)    
      2024-04-04 10:26:21 Parachain Account: 5Ec4AhPaYcfBz8fMoPd4EfnAgwbzRS7np3APZUnnFo12qEYk    
      2024-04-04 10:26:21 Is collating: no    
      2024-04-04 10:26:24 [Parachain] 🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645)    
      2024-04-04 10:26:25 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe)    
      2024-04-04 10:26:25 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
      2024-04-04 10:26:25 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup.    
      2024-04-04 10:26:25 [Relaychain] 🏷  Local node identity is: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB    
      2024-04-04 10:26:25 [Relaychain] 💻 Operating system: linux    
      2024-04-04 10:26:25 [Relaychain] 💻 CPU architecture: x86_64    
      2024-04-04 10:26:25 [Relaychain] 💻 Target environment: gnu    
      2024-04-04 10:26:25 [Relaychain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz    
      2024-04-04 10:26:25 [Relaychain] 💻 CPU cores: 4    
      2024-04-04 10:26:25 [Relaychain] 💻 Memory: 31797MB    
      2024-04-04 10:26:25 [Relaychain] 💻 Kernel: 5.15.0-101-generic    
      2024-04-04 10:26:25 [Relaychain] 💻 Linux distribution: Ubuntu 20.04.6 LTS    
      2024-04-04 10:26:25 [Relaychain] 💻 Virtual machine: no    
      2024-04-04 10:26:25 [Relaychain] 📦 Highest known block at #0    
      2024-04-04 10:26:25 [Relaychain] ️ Prometheus exporter started at 127.0.0.1:9616    
      2024-04-04 10:26:25 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]    
      2024-04-04 10:26:25 [Relaychain] 🏁 CPU score: 1.18 GiBs    
      2024-04-04 10:26:25 [Relaychain] 🏁 Memory score: 15.61 GiBs    
      2024-04-04 10:26:25 [Relaychain] 🏁 Disk score (seq. writes): 1.49 GiBs    
      2024-04-04 10:26:25 [Relaychain] 🏁 Disk score (rand. writes): 650.01 MiBs    
      2024-04-04 10:26:25 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs    
      2024-04-04 10:26:25 [Parachain] 🏷  Local node identity is: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj    
      2024-04-04 10:26:25 [Parachain] 💻 Operating system: linux    
      2024-04-04 10:26:25 [Parachain] 💻 CPU architecture: x86_64    
      2024-04-04 10:26:25 [Parachain] 💻 Target environment: gnu    
      2024-04-04 10:26:25 [Parachain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz    
      2024-04-04 10:26:25 [Parachain] 💻 CPU cores: 4    
      2024-04-04 10:26:25 [Parachain] 💻 Memory: 31797MB    
      2024-04-04 10:26:25 [Parachain] 💻 Kernel: 5.15.0-101-generic    
      2024-04-04 10:26:25 [Parachain] 💻 Linux distribution: Ubuntu 20.04.6 LTS    
      2024-04-04 10:26:25 [Parachain] 💻 Virtual machine: no    
      2024-04-04 10:26:25 [Parachain] 📦 Highest known block at #0    
      2024-04-04 10:26:25 [Parachain] ️ Prometheus exporter started at 127.0.0.1:9615    
      2024-04-04 10:26:25 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]    
      2024-04-04 10:26:25 [Parachain] 🏁 CPU score: 1.18 GiBs    
      2024-04-04 10:26:25 [Parachain] 🏁 Memory score: 15.61 GiBs    
      2024-04-04 10:26:25 [Parachain] 🏁 Disk score (seq. writes): 1.49 GiBs    
      2024-04-04 10:26:25 [Parachain] 🏁 Disk score (rand. writes): 650.01 MiBs    
      2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.17.0.1/tcp/30334/ws    
      2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.18.0.1/tcp/30333/ws    
      2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/192.168.1.100/tcp/30333/ws    
      2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.18.0.1/tcp/30334/ws    
      2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.17.0.1/tcp/30333/ws    
      2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/192.168.1.100/tcp/30334/ws    
      2024-04-04 10:26:26 [Relaychain] 🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB    
      2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate    
      2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate    
      2024-04-04 10:26:30 [Relaychain] ️  Syncing, target=#22588722 (8 peers), best: #638 (0xa9cd…7c30), finalized #512 (0xb9b6…7014),  345.6kiB/s  108.7kiB/s    
      2024-04-04 10:26:30 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),  0  0    
      2024-04-04 10:26:35 [Relaychain] ️  Syncing 174.4 bps, target=#22588722 (9 peers), best: #1510 (0xec0b…72f0), finalized #1024 (0x3f17…fd7f),  203.1kiB/s  45.0kiB/s    
      2024-04-04 10:26:35 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),  0  0    
      2024-04-04 10:26:40 [Relaychain] ️  Syncing 168.9 bps, target=#22588723 (9 peers), best: #2355 (0xa68b…3a64), finalized #2048 (0xede6…f879),  201.6kiB/s  47.4kiB/s    
      2024-04-04 10:26:40 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),  0  0    
      
      ```
      
      ## TODO
      - [x] double check
      `cumulus/polkadot-parachain/chain-specs/coretime-kusama.json`
      (safeXcmVersion=3) see
      [comment](https://github.com/paritytech/polkadot-sdk/pull/3961#discussion_r1549473587
      
      )
      - [x] check if ~~`start_generic_aura_node`~~ or
      `start_generic_aura_lookahead_node`
      - [x] generate chain-spec for `people-kusama`
      
      ---------
      
      Co-authored-by: default avatarDónal Murray <[email protected]>
      68cdb126
    • Liam Aharon's avatar
      Migrate fee payment from `Currency` to `fungible` (#2292) · bda4e75a
      Liam Aharon authored
      Part of https://github.com/paritytech/polkadot-sdk/issues/226 
      Related https://github.com/paritytech/polkadot-sdk/issues/1833
      
      - Deprecate `CurrencyAdapter` and introduce `FungibleAdapter`
      - Deprecate `ToStakingPot` and replace usage with `ResolveTo`
      - Required creating a new `StakingPotAccountId` struct that implements
      `TypedGet` for the staking pot account ID
      - Update parachain common utils `DealWithFees`, `ToAuthor` and
      `AssetsToBlockAuthor` implementations to use `fungible`
      - Update runtime XCM Weight Traders to use `ResolveTo` instead of
      `ToStakingPot`
      - Update runtime Transaction Payment pallets to use `FungibleAdapter`
      instead of `CurrencyAdapter`
      - [x] Blocked by https://github.com/paritytech/polkadot-sdk/pull/1296,
      needs the `Unbalanced::decrease_balance` fix
      bda4e75a
    • Francisco Aguirre's avatar
      XCM builder pattern improvement - Accept `impl Into<T>` instead of just `T` (#3708) · c130ea99
      Francisco Aguirre authored
      
      
      The XCM builder pattern lets you build xcms like so:
      
      ```rust
      let xcm = Xcm::builder()
          .withdraw_asset((Parent, 100u128).into())
          .buy_execution((Parent, 1u128).into())
          .deposit_asset(All.into(), AccountId32 { id: [0u8; 32], network: None }.into())
          .build();
      ```
      
      All the `.into()` become quite annoying to have to write.
      I accepted `impl Into<T>` instead of `T` in the generated methods from
      the macro.
      Now the previous example can be simplified as follows:
      
      ```rust
      let xcm = Xcm::builder()
          .withdraw_asset((Parent, 100u128))
          .buy_execution((Parent, 1u128))
          .deposit_asset(All, [0u8; 32])
          .build();
      ```
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      c130ea99
    • juangirini's avatar
      [doc] Example MBM pallet (#2119) · bcb4d137
      juangirini authored
      ## Basic example showcasing a migration using the MBM framework
      
      This PR has been built on top of
      https://github.com/paritytech/polkadot-sdk/pull/1781
      
       and adds two new
      example crates to the `examples` pallet
      
      ### Changes Made:
      
      Added the `pallet-example-mbm` crate: This crate provides a minimal
      example of a pallet that uses MBM. It showcases a storage migration
      where values are migrated from a `u32` to a `u64`.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      bcb4d137
    • Liam Aharon's avatar
      Fix Mermaid diagram rendering (#3875) · 0ef37c75
      Liam Aharon authored
      Closes https://github.com/paritytech/polkadot-sdk/issues/2977
      
      The issue appears to stem from the `aquamarine` crate failing to render
      diagrams in re-exported crates.
      
      e.g. as raised
      [here](https://github.com/paritytech/polkadot-sdk/issues/2977), diagrams
      would render at `frame_support::traits::Hooks` but not the re-exported
      doc `frame::traits::Hooks`, even if I added `aquamarine` as a `frame`
      crate dependency.
      
      To resolve this, I followed advice in
      https://github.com/mersinvald/aquamarine/issues/20
      
       to instead render
      mermaid diagrams directly using JS by adding an `after-content.js`.
      
      ---
      
      Also fixes compile warnings, enables `--all-features` and disallows
      future warnings in CI.
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      0ef37c75
    • gupnik's avatar
      Renames `frame` crate to `polkadot-sdk-frame` (#3813) · 38363769
      gupnik authored
      Step in https://github.com/paritytech/polkadot-sdk/issues/3155
      
      Needed for https://github.com/paritytech/eng-automation/issues/6
      
      
      
      This PR renames `frame` crate to `polkadot-sdk-frame` as `frame` is not
      available on crates.io
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      38363769
  9. Apr 03, 2024
  10. Apr 02, 2024
    • Clara van Staden's avatar
      Snowbridge: Synchronize from Snowfork repository (#3761) · 5d9826c2
      Clara van Staden authored
      This PR includes the following 2 improvements:
      
      ## Ethereum Client
      
      Author: @yrong 
      ### Original Upstream PRs
      - https://github.com/Snowfork/polkadot-sdk/pull/123
      - https://github.com/Snowfork/polkadot-sdk/pull/125
      
      ### Description
      The Ethereum client syncs beacon headers as they are finalized, and
      imports every execution header. When a message is received, it is
      verified against the import execution header. This is unnecessary, since
      the execution header can be sent with the message as proof. The recent
      Deneb Ethereum upgrade made it easier to locate the relevant beacon
      header from an execution header, and so this improvement was made
      possible. This resolves a concern @svyatonik had in our initial Rococo
      PR:
      https://github.com/paritytech/polkadot-sdk/pull/2522#discussion_r1431270691
      
      ## Inbound Queue
      
      Author: @yrong 
      ### Original Upstream PR
      - https://github.com/Snowfork/polkadot-sdk/pull/118
      
      ### Description
      When the AH sovereign account (who pays relayer rewards) is depleted,
      the inbound message will not fail. The relayer just will not receive
      rewards.
      
      Both these changes were done by @yrong, many thanks. 
      
      ️
      
      ---------
      
      Co-authored-by: claravanstaden <Cats 4 life!>
      Co-authored-by: default avatarRon <[email protected]>
      Co-authored-by: default avatarVincent Geddes <[email protected]>
      Co-authored-by: default avatarSvyatoslav Nikolsky <[email protected]>
      5d9826c2
    • Dastan's avatar
      migrations: prevent accidentally using unversioned migrations instead of... · e5427969
      Dastan authored
      migrations: prevent accidentally using unversioned migrations instead of `VersionedMigration` (#3835)
      
      closes #1324 
      
      #### Problem
      Currently, it is possible to accidentally use inner unversioned
      migration instead of `VersionedMigration` since both implement
      `OnRuntimeUpgrade`.
      
      #### Solution
      
      With this change, we make it clear that value of `Inner` is not intended
      to be used directly. It is achieved by bounding `Inner` to new trait
      `UncheckedOnRuntimeUpgrade`, which has the same interface (except
      `unchecked_` prefix) as `OnRuntimeUpgrade`.
      
      #### `try-runtime` functions
      
      Since developers can implement `try-runtime` for `Inner` value in
      `VersionedMigration` and have custom logic for it, I added the same
      `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a
      ways to not duplicate functions, but couldn't find anything that doesn't
      significantly change the codebase. So I would appreciate If you have any
      suggestions to improve this
      
      cc @liamaharon
      
       @xlc 
      
      polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      e5427969