- Apr 04, 2024
-
-
Michal Kucharczyk authoredThe 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/3b41d66b/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/3b41d66b/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/3b41d66b/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/3b41d66b/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/2caffaae /polkadot/node/service/src/chain_spec.rs#L404). Implementation of #1984. fixes: #150 part of: #25 --------- Co-authored-by:Sebastian Kunert <[email protected]> Co-authored-by:
Kian Paimani <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]>
-
Shawn Tabrizi authoredThis function is currently only exposed to runtime-benchmarks, where it should be available in all tests. Also made it available in `std` because this is how `set_block_number` works in FRAME System, however, not sure if it is needed in the latest std/no_std paradigm. --------- Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
-
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:Dónal Murray <[email protected]>
-
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
-
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:Adrian Catangiu <[email protected]>
-
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:
Liam Aharon <[email protected]>
-
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:
-
Lulu authored
CI will be enforcing this with next parity-publish release
-
Vladimir Istyufeev authored
Use of `- >` instead of `- |` workarounds GitLab quirk when it crops collapsed multiline `script:` section commands in its CI job logs. This PR also fixes `- |` based `script:` steps to behave properly after `- >` conversion. Resolves https://github.com/paritytech/ci_cd/issues/972.
-
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:
-
- Apr 03, 2024
-
-
Andrei Sandu authored
Remove `fetch_next_scheduled_on_core` in favor of new wrapper and methods for accessing it. --------- Signed-off-by:Andrei Sandu <[email protected]>
-
Sebastian Kunert authored
Enables pov-reclaim on the rococo/westend parachains, part of https://github.com/paritytech/polkadot-sdk/issues/3622
-
Alexandru Vasile authored
This PR ensure that the distance between any leaf and the finalized block is within a reasonable distance. For a new subscription, the chainHead has to provide all blocks between the leaves of the chain and the finalized block. When the distance between a leaf and the finalized block is large: - The tree route is costly to compute - We could deliver an unbounded number of blocks (potentially millions) (For more details see https://github.com/paritytech/polkadot-sdk/pull/3445#discussion_r1507210283) The configuration of the ChainHead is extended with: - suspend on lagging distance: When the distance between any leaf and the finalized block is greater than this number, the subscriptions are suspended for a given duration. - All active subscriptions are terminated with the `Stop` event, all blocks are unpinned and data discarded. - For incoming subscriptions, until the suspended period expires the subscriptions will immediately receive the `Stop` event. - Defaults to 128 blocks - suspended duration: The amount of time for which subscriptions are suspended - Defaults to 30 seconds cc @paritytech/subxt-team --------- Signed-off-by:Alexandru Vasile <[email protected]> Co-authored-by:
-
Branislav Kontur authored
Added tests for XCM barriers: `AllowSubscriptions`, `WithUniqueTopic` and `TrailingSetTopicAsId` (#3955) Closes: https://github.com/paritytech/polkadot-sdk/issues/1756
-
Bastian Köcher authored
Closes: https://github.com/paritytech/polkadot-sdk/issues/3909
-
Andrei Sandu authored
fixes https://github.com/paritytech/polkadot-sdk/issues/3775 Additionally moves the claim queue fetch utilities into `subsystem-util`. TODO: - [x] fix tests - [x] add elastic scaling tests --------- Signed-off-by:
-
- Apr 02, 2024
-
-
Andrei Eres authored
Fixes https://github.com/paritytech/polkadot-sdk/issues/3884#issuecomment-2026058687 After moving regression tests to benchmarks (https://github.com/paritytech/polkadot-sdk/pull/3741) we don't need to filter tests anymore. --------- Signed-off-by:
Andrei Sandu <[email protected]> Co-authored-by:
Alin Dima <[email protected]> Co-authored-by:
Javier Viola <[email protected]> Co-authored-by:
Serban Iorga <[email protected]> Co-authored-by:
Alexandru Vasile <[email protected]> Co-authored-by:
Niklas Adolfsson <[email protected]> Co-authored-by:
Dastan <[email protected]> Co-authored-by:
Clara van Staden <[email protected]> Co-authored-by:
Ron <[email protected]> Co-authored-by:
Vincent Geddes <[email protected]> Co-authored-by:
Svyatoslav Nikolsky <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]>
-
Dino Pačandi authored
Adds implementation for `SortedMembers::add` for _pallet-membership_ benchmarks. --------- Co-authored-by: -
Michal Kucharczyk authored
Added `TryFrom<&'a RuntimeString> for &'a str`
-
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: -
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:
-
Serban Iorga authored
Working towards migrating the `parity-bridges-common` repo inside `polkadot-sdk`. This PR upgrades some dependencies in order to align them with the versions used in `parity-bridges-common` Related to https://github.com/paritytech/parity-bridges-common/issues/2538
-
Alexandru Vasile authored
chainHead: Allow methods to be called from within a single connection context and limit connections (#3481) This PR ensures that the chainHead RPC class can be called only from within the same connection context. The chainHead methods are now registered as raw methods. - https://github.com/paritytech/jsonrpsee/pull/1297 The concept of raw methods is introduced in jsonrpsee, which is an async method that exposes the connection ID: The raw method doesn't have the concept of a blocking method. Previously blocking methods are now spawning a blocking task to handle their blocking (ie DB) access. We spawn the same number of tasks as before, however we do that explicitly. Another approach would be implementing a RPC middleware that captures and decodes the method parameters: - https://github.com/paritytech/polkadot-sdk/pull/3343 However, that approach is prone to errors since the methods are hardcoded by name. Performace is affected by the double deserialization that needs to happen to extract the subscription ID we'd like to limit. Once from the middleware, and once from the methods itself. This PR paves the way to implement the chainHead connection limiter: - https://github.com/paritytech/polkadot-sdk/issues/1505 Registering tokens (subscription ID / operation ID) on the `RpcConnections` could be extended to return an error when the maximum number of operations is reached. While at it, have added an integration-test to ensure that chainHead methods can be called from within the same connection context. Before this is merged, a new JsonRPC release should be made to expose the `raw-methods`: - [x] Use jsonrpsee from crates io (blocked by: https://github.com/paritytech/jsonrpsee/pull/1297) Closes: https://github.com/paritytech/polkadot-sdk/issues/3207 cc @paritytech/subxt-team --------- Signed-off-by:
-
Adrian Catangiu authored
This outputs: ``` 2024-04-02 14:36:02.135 ERROR tokio-runtime-worker beefy: 🥩 for session starting at block 21990151 no BEEFY authority key found in store, you must generate valid session keys (https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#generating-the-session-keys) ``` error log entry, once every session, for nodes running with `Role::Authority` that have no public BEEFY key in their keystore --------- Co-authored-by: -
Serban Iorga authored
Pulling the latest changes from `parity-bridges-common`
-
Javier Viola authored
This version includes: - Internal metrics of zombienet (used to benchmark with v2).
-
Bastian Köcher authored
When using `schedule_code_upgrade` to change the code of a parachain in the relay chain runtime, we had already fixed to not set the `GoAhead` signal. This was done to not brick any parachain after the upgrade, because they were seeing the signal without having any upgrade prepared. The remaining problem is that the parachain code is only upgraded after a parachain header was enacted, aka the parachain made some progress. However, this is quite complicated if the parachain is bricked (which is the most common scenario why to manually schedule a code upgrade). Thus, this pull request replaces `SetGoAhead` with `UpgradeStrategy` to signal to the logic kind of strategy want to use. The strategies are either `SetGoAheadSignal` or `ApplyAtExpectedBlock`. `SetGoAheadSignal` sets the go ahead signal as before and awaits a parachain block. `ApplyAtExpectedBlock` schedules the upgrade and applies it directly at the `expected_block` without waiting for the parachain to make any kind of progress.
-
Adrian Catangiu authored
Fix "double-weights" for extrinsics, use only the ones benchmarked in the runtime. Deprecate extrinsics that don't specify WeightLimit, remove their usage across the repo. --------- Signed-off-by: -
Sam Johnson authored
derive-syn-parse v0.2.0 came out recently which (finally) adds support for syn 2x. Upgrading to this will remove many of the places where syn 1x was still compiling alongside syn 2x in the polkadot-sdk workspace. This also upgrades `docify` to 0.2.8 which is the version that upgrades derive-syn-pasre to 0.2.0. Additionally, this consolidates the `docify` versions in the repo to all use the latest, and in one case upgrades to the 0.2x syntax where 0.1.x was still being used. --------- Co-authored-by:
-
- Apr 01, 2024
-
-
s0me0ne-unkn0wn authored
Rejoice! Rejoice! The story is nearly over. This PR removes stale migrations, auxiliary structures, and package dependencies, thus making Rococo and Westend totally free from any `im-online`-related stuff. `im-online` still stays a part of the Substrate node and its runtime: https://github.com/paritytech/polkadot-sdk/blob/0d932484/substrate/bin/node/runtime/src/lib.rs#L2276-L2277 I'm not sure if it makes sense to remove it from there considering that we're not removing `im-online` from FRAME. Please share your opinion.
-
Andrei Sandu authored
fix https://github.com/paritytech/polkadot-sdk/issues/3921 --------- Signed-off-by: -
Serban Iorga authored
Fix links Related CI failure: https://github.com/paritytech/polkadot-sdk/actions/runs/8455425042/job/23162858534?pr=3859
-
Alexandru Gheorghe authored
Runtime release 1.2 includes bumping of the ParachainHost APIs up to v10, so let's move all the released APIs out of vstaging folder, this PR does not include any logic changes only renaming of the modules and some moving around. Signed-off-by:Alexandru Gheorghe <[email protected]>
-
Alexandru Gheorghe authored
Test started failing after https://github.com/paritytech/polkadot-sdk/commit/66051adb which enabled approval coalescing, that was expected to happen because the test required an polkadot_parachain_approval_checking_finality_lag of 0, which can't happen with max_approval_coalesce_count greater than 1 because we always delay the approval for no_show_duration_ticks/2 in case we can coalesce it with other approvals. So relax a bit the restrictions, since we don't actually care that the lags are 0, but the fact the finalities are progressing and are not stuck. Signed-off-by:
-
Ross Bulat authored
Related Issue https://github.com/paritytech/polkadot-sdk/issues/3398 This PR makes permissionless withdrawing the default option, giving any network participant access to claim pool rewards on member's behalf. Of course, members can still opt out of this by setting a `Permissioned` claim permission. Permissionless claiming has been a part of the nomination pool pallet for around 9 months now, with very limited uptake (~4% of total pool members). 1.6% of pool members are using `PermissionlessAll`, strongly suggesting it is not wanted - it is too ambiguous and doesn't provide guidance to claimers. Stakers expect rewards to be claimed on their behalf by default - I have expanded upon this in detail within the [accompanying issue's discussion](https://github.com/paritytech/polkadot-sdk/issues/3398). Other protocols have this behaviour, whereby staking rewards are received without the staker having to take any action. From this perspective, permissionless claiming is not intuitive for pool members. As evidence of this, over 150,000 DOT is currently unclaimed on Polkadot, and is growing at a non-linear rate.
-
Andrei Sandu authored
fixes https://github.com/paritytech/polkadot-sdk/issues/3886 --------- Signed-off-by: -
Alessandro Siniscalchi authored
This PR introduces a refactor of the parachain runtime configuration by consolidating all pallet configurations into a new module named `configs`. This change aims to improve the readability and maintainability of the runtime configuration by centralizing all configuration parameters. ## Changes - **Creation of `configs.rs`**: A new file `configs.rs` has been added under `templates/parachain/runtime/src/`, containing all the runtime configurations previously scattered across `lib.rs`. - **Refactoring of `lib.rs`**: The `lib.rs` file has been significantly slimmed down by removing the inline pallet configurations and importing them from `configs.rs` instead. - **Optimization of Import Statements**: Reorganized import statements to clarify the runtime's dependency structure. ### Benefits - **Improved Readability**: With configurations being centralized, developers can now easily locate and review runtime parameters without navigating through the `lib.rs` file. This refactor does not introduce any changes to the runtime logic but improves the project structure for better development experience. --------- Co-authored-by: -
Alexandru Gheorghe authored
The metric records the current protocol_version of the validator that just connected with the peer_map.len(), which contains all peers that connected, that has the effect the metric will be wrong since it won't tell us how many peers we have connected per version because it will always record the total number of peers Fix this by counting by version inside peer_map, additionally because that might be a bit heavier than len(), publish it only on-active leaves. --------- Signed-off-by: -
Matteo Muraca authored
Part of #3326 cc @Kianenigma @ggwpez @liamaharon polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp --------- Signed-off-by:
Matteo Muraca <[email protected]> Co-authored-by:
-
- Mar 31, 2024
-
-
gemini132 authored
Co-authored-by:
-
