- Mar 14, 2025
-
-
Matteo Muraca authored
-
- Mar 13, 2025
-
-
Matteo Muraca authored
-
Matteo Muraca authored
-
Matteo Muraca authored
-
Javier Viola authored
Set timeout to 60mins. Prevent failures like this one https://github.com/paritytech/polkadot-sdk/actions/runs/13651327605/job/38160444244?pr=7790 Thanks! --------- Co-authored-by:
Bastian Köcher <git@kchr.de>
-
Iulian Barbu authored
# Description It is difficult to spot changes to umbrella features when reviewing, when defined on a long line, so made sure tomls formatting will be applied to long array lines by splitting them on multiple lines. This will be applied to any tomls in the monorepo that is not excluded from taplo. ## Integration N/A ## Review Notes Set global taplo config `array_auto_expand` to true. --------- Signed-off-by:
Iulian Barbu <iulian.barbu@parity.io>
-
PG Herveou authored
Update pallet-revive-fixtures so that it can build without looking up dependencies from the workspace --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Alexandru Vasile authored
This PR punishes behaviors that deviate from the notification spec. When a peer misbehaves by writing data on an unidirectional read stream, the peer is banned and disconnected immediately. In this PR: - The `NotificationOutError` is enriched with termination reason and made publically available for higher levels - The protocol misbehavior is propagated through the `CloseDesired` events - The network behavior of the protocol is responsible for banning the peer. - The peer is banned immediately and, as a result, the reputation system disconnects the malicious / misbehaving peer - Logs are enriched with protocol names Closes: https://github.com/paritytech/polkadot-sdk/issues/7722 cc @paritytech/networking --------- Signed-off-by:
Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by:
Bastian Köcher <git@kchr.de>
-
Egor_P authored
-
Matteo Muraca authored
# Description Part of #3326 As per title, the `pallet:getter` usage has been removed from: - `pallet-bridge-beefy` - `pallet-bridge-grandpa` - `pallet-bridge-messages` - `pallet-bridge-relayers` - `pallet-xcm-bridge-hub-router` polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp --------- Co-authored-by:
Branislav Kontur <bkontur@gmail.com> Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
PG Herveou authored
Support "latest" blocktag in ethGetLogs from_block and to_block parameters This is not in specs (https://github.com/ethereum/execution-apis/blob/main/src/schemas/filter.yaml#L17) but defined and used by 3rd parties and in some other reference docs See https://docs.metamask.io/services/reference/ethereum/json-rpc-methods/eth_getlogs/ --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
thiolliere authored
giving the wrong origin in `extrinsic_call` would result in: ``` | 43 | #[benchmarks] | ^^^^^^^^^^^^^ | | | expected associated type, found `Result<RawOrigin<...>, ...>` | arguments to this function are incorrect | = note: expected associated type `<T as frame_system::Config>::RuntimeOrigin` found enum `Result<RawOrigin<<T as frame_system::Config>::AccountId>, <T as frame_system::Config>::RuntimeOrigin>` note: method defined here --> $WORKSPACE/substrate/frame/support/src/traits/dispatch.rs | | fn dispatch_bypass_filter(self, origin: Self::RuntimeOrigin) -> DispatchResultWithPostInfo; | ^^^^^^^^^^^^^^^^^^^^^^ = note: this error originates in the attribute macro `benchmarks` (in Nightly builds, run with -Z macro-backtrace for more info) ``` Now it results in an error message with good span. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
ordian authored
This PR adds a convenience extrinsic `manual_slash` for the governance to slash a validator manually. ## Changes * The `on_offence` implementation for the Staking pallet accepts a slice of `OffenceDetails` including the full validator exposure, however, it simply [ignores](https://github.com/paritytech/polkadot-sdk/blob/c8d33396 /substrate/frame/staking/src/pallet/impls.rs#L1864) that part. I've extracted the functionality into an inherent `on_offence` method that takes `OffenceDetails` without the full exposure and this is called directly in `manual_slash` * `manual_slash` creates an offence for a validator with a given slash percentange ## Questions - [x] should `manual_slash` accept session instead of an era when the validator was in the active set? staking thinks in terms of eras and we can check out of bounds this way, which is why it was chosen for this implementation, but if there are arguments against, happy to change to session index - [X] should the accepted origin be something more than just root? Changed to `T::AdminOrigin` to align with `cancel_deferred_slash` - [X] should I adapt this PR also against https://github.com/paritytech/polkadot-sdk/pull/6996? looking at the changes, it should apply mostly without conflicts --------- Co-authored-by:
Tsvetomir Dimitrov <tsvetomir@parity.io> Co-authored-by:
Ankan <10196091+Ank4n@users.noreply.github.com>
-
- Mar 12, 2025
-
-
Francisco Aguirre authored
The xcm-executor will not support `ExecuteWithOrigin` from the start. It might be implemented again in the future when more time can be spent on it. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Ankan authored
## Summary The existing fungible migration code has an issue when handling partially unbonding accounts, leaving them in an inconsistent state. These changes fix it by properly withdrawing overstake from unlock chunks. This PR also removes the `withdraw_overstake` extrinsic from pallet-staking, as this scenario could only occur before the fungible migration. With fungibles, over-staking is no longer possible. ## TODO - [ ] Backport to stable2503. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Kian Paimani authored
Co-authored-by:
Ankan <ankan.anurag@gmail.com>
-
- Mar 11, 2025
-
-
Alexandru Vasile authored
This PR makes the litep2p backend the default network backend in Kusama. We performed a gradual rollout in Kusama by asking validators to manually switch to litep2p. The rollout went smoothly, with 250 validators running litep2p without issues. This PR represents the next step in testing the backend at scale. Thanks to everyone who contributed to making this happen! A special shoutout to the validators for their prompt support and cooperation
While at it, the litep2p release is bumped to the latest 0.9.2, which downgrades a spamming log to debug. ### CLI Testing Done ``` ### Kusama without network backend specified RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output 2025-03-10 14:24:18.503 INFO main sub-libp2p: Running litep2p network backend ### Kusama with libp2p RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output --network-backend libp2p INFO main sub-libp2p: Running libp2p network backend ### Kusama with litep2p RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output --network-backend litep2p INFO main sub-libp2p: Running litep2p network backend ### Polkadot without network backend specified RUST_LOG=info ./target/release/polkadot --chain polkadot --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output 2025-03-10 14:27:03.762 INFO main sub-libp2p: Running libp2p network backend ``` cc @paritytech/networking --------- Signed-off-by:Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by:
Bastian Köcher <git@kchr.de>
-
Egor_P authored
This PR contains few fixes for the Promote RC to final flow: - Now the `polkadot-preapre-worker` and `polkadot-execute-worker` artefacts will be uploaded alongside with the `polakdot` artefact (it was missing before) - Added missing upload of the deb package - Few typos fixed Closes: https://github.com/paritytech/release-engineering/issues/241
-
Egor_P authored
-
PG Herveou authored
[pallet-revive] Add support for eip1898 block notation https://eips.ethereum.org/EIPS/eip-1898 --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Serban Iorga authored
This PR includes: - deduplicating some XCM decoding logic - making use of `decode_with_depth_limit` consistently for `VersionedXcm` - some cleanup
-
Sebastian Kunert authored
**Summary:** This PR enables authoring of multiple blocks in one AURA slot in the slot-based collator and stabilizes the slot-based collator. ## CLI Changes The flag `--experimental-use-slot-based` is now marked as deprecated. I opted to introduce `--authoring slot-based` instead of just removing the `experimental` prefix. By introducing the `authoring` variant, we get some future-proofing in case we want to introduce further options. ## Change Description With elastic-scaling, we are able to author multiple blocks with a single relay-chain parent. In the initial iteration, the interval between two blocks was determined by the `slot_duration` of the parachain. This PR introduces a more flexible model, where we try to author multiple blocks in a single slot if the runtime allows it. The block authoring loop is largely the same. The [`SlotTimer`](https://github.com/paritytech/polkadot-sdk/blob/f1935bd9/cumulus/client/consensus/aura/src/collators/slot_based/slot_timer.rs#L48-L48) now lives in a separate module and is updated with the last seen [core count](https://github.com/paritytech/polkadot-sdk/blob/f1935bd9 /cumulus/client/consensus/aura/src/collators/slot_based/block_builder_task.rs#L231-L231). It will then trigger rounds in the block-building loop based on the core count. This allows some flexibility where elastic-scaling chains can run on a single core in quiet times. Previously, running on 1 core with a 3-core elastic-scaling chain would result in authors getting skipped because the `slot_duration` was too low. ## Parameter Considerations The core logic does not change, so there are a few things to consider: - The `ConsensusHook` implementation still determines how many blocks are allowed per relay-chain block. So if you add arbitrary cores to an async-backing, 6-second parachain, `can_build_upon` in the runtime will deny block-building of additional blocks. - The `MINIMUM_PERIOD` in the runtime needs to be configured to allow enough blocks in the slot. A "classic" configuration of `SLOT_DURATION/2` will lead to slot mismatches when running with 3 cores. - We fetch available cores at least once every relay chain block. So if a parachain runs with a 12-second slot duration and 1 fixed core, we would still author 2 blocks if the parachain runtime allows it. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by:
Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by:
Javier Viola <javier@parity.io> Co-authored-by:
Bastian Köcher <git@kchr.de>
-
- Mar 10, 2025
-
-
Sebastian Kunert authored
Follow up of : #7217, #7529 When the zombienet tests were integrated into github, it seems like the gitlab ones remained active. But they look a lot more unstable. This causes confusion when the same tests fail and pass at the same time (aside from extra costs). This PR attempts to get rid of the gitlab ones.
-
Bastian Köcher authored
As proposed by Gui :)
-
jpserrat authored
Closes #6851 This PR adds an `EventEmitter` trait to the XCM Executor configuration, enabling event emission for XCM handling. The implementation introduces three dedicated functions to emit relevant events: - `emit_sent_event`: Emits a `Sent` event when an XCM is successfully sent. - `emit_send_failure_event`: Emits a `SendFailed` event when an XCM fails to send. - `emit_process_failure_event`: Emits a `ProcessXcmError` event when an XCM fails during processing. Kusama address: FkB6QEo8VnV3oifugNj5NeVG3Mvq1zFbrUu4P5YwRoe5mQN --------- Co-authored-by:
Raymond Cheung <178801527+raymondkfcheung@users.noreply.github.com> Co-authored-by:
Adrian Catangiu <adrian@parity.io> Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Bastian Köcher authored
Close: https://github.com/paritytech/polkadot-sdk/issues/7816 --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
clangenb authored
Closes #7845 --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by:
Guillaume Thiolliere <guillaume.thiolliere@parity.io>
-
- Mar 07, 2025
-
-
girazoki authored
# Description Chains like moonbeam work with an ED deposit of 0 (insecure-ed-0) which is unsable with the current pallet-transaction-payment benchmark. This PR adds an if-else case in case the existential deposit found is 0.
-
Alexandru Gheorghe authored
Bumping trie-db to latest version to pick up https://github.com/paritytech/trie/pull/216 Signed-off-by:
Alexandru Gheorghe <alexandru.gheorghe@parity.io>
-
PG Herveou authored
Allow using the legacy data field for GenericTransaction
-
Michal Kucharczyk authored
#### PR Description This pull request introduces measures to handle finality stalls by : - notifying outdated transactions with a [`FinalityTimeout`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/api/src/lib.rs#L145-L147) event. - removing outdated views from the `view_store` An item is considered _outdated_ when the difference between its associated block and the current block exceeds a pre-defined threshold. #### Note for Reviewers The core logic is provided in the following small commits: - `ViewStore`: new method [`finality_stall_view_cleanup`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/src/fork_aware_txpool/view_store.rs#L869-L903) for removing stale views was added: 64267000 - `ForkAwareTransactionPool`: core logic for tracking finality stalls added here: 7b37ea6f. Entry point in [`finality_stall_cleanup`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L1096-L1136) - Some related renaming was made to better reflect purpose/shorten the names: 1a3a1284, a511601f. Also new method [`transactions_finality_timeout`](https://github.com/paritytech/polkadot-sdk/blob/a511601f/substrate/client/transaction-pool/src/fork_aware_txpool/multi_view_listener.rs#L771-L790) for triggering external events was added for `MultiViewListener`. - `included_transactions` which basically is mapping `block hash -> included transactions hashes`, is also used to find to included transactions. I also sneaked in some minor improvements: - fixed per-transaction logging: 1572f721 - `handle_pre_finalized` method was removed, it was some old leftover which is no longer needed: a6f84ad0 , closes: #5482 --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by:
Sebastian Kunert <skunert49@gmail.com> Co-authored-by:
Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>
-
Iulian Barbu authored
# Description Builds up towards addressing #5497 by creating some zombienet-sdk code infra that can be used to spin regular networks, as described in the fork aware transaction pool testing setup added here #7100. It will be used for developing tests against such networks, and to also spawn them on demand locally through tooling that will be developed in follow ups. ## Integration Node/runtime developers can run tests based on the zombienet-sdk infra that spins frequently used networks which can be used for analyzing behavior of various node related components, like fork aware transaction pool. ## Review Notes - Uses ttxt API implemented here: https://github.com/michalkucharczyk/tx-test-tool/pull/22/files - currently, only two test scenarios are considered: 10k future & 10k ready txs are sent to two separate networks - one parachain and one relaychain, asserting at the end on the finalization of all 20k txs on both networks. --------- Signed-off-by:
Iulian Barbu <iulian.barbu@parity.io> Co-authored-by:
Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by:
Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
-
Bastian Köcher authored
This pr ensures that we remove the `authorization` for a runtime upgrade if the version check failed. If that check is failing, it means that the runtime upgrade is invalid and the check will never succeed. Besides that the pr is doing some clean ups. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
- Mar 06, 2025
-
-
thiolliere authored
If the inner transaction extension used inside `SkipCheckIfFeeless` are multiples then the metadata is not correct, it is now fixed. E.g. if the transaction extension is `SkipCheckIfFeeless::<Runtime, (Payment1, Payment2)>` then the metadata was wrong. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by:
Bastian Köcher <git@kchr.de>
-
Utkarsh Bhardwaj authored
# Description * This PR adds a new extrinsic `poke_deposit` to `pallet-proxy`. This extrinsic will be used to re-adjust the deposits made in the pallet to create a proxy or to create an announcement. * Part of #5591 ## Review Notes * Added a new extrinsic `poke_deposit` in `pallet-proxy`. * This extrinsic checks and adjusts the deposits made for either creating a proxy or creating an announcement or both. * Added a new event `DepositPoked` to be emitted upon a successful call of the extrinsic. * Although the immediate use of the extrinsic will be to give back some of the deposit after the AH-migration, the extrinsic is written such that it can work if the deposit decreases or increases (both). * The call to the extrinsic would be `free` if an actual adjustment is made to the deposit for creating a proxy or to the deposit for creating an announcement or both and `paid` otherwise (when no deposit is changed). * Added a new enum `DepositKind` to differentiate between proxy deposit adjusted and announcement deposit adjusted when emitting events. * Added tests to test all scenarios. ## TO-DOs * [ ] Run CI cmd bot to benchmark --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Alexander Samusev authored
More details [here](https://github.com/paritytech/security/issues/103#issuecomment-2682362253) cc https://github.com/paritytech/security/issues/103
-
seemantaggarwal authored
Follow up from #7619 Adding a more verbose rustdoc for guidance and difference between chain-spec-builder and build-spec commands under polkadot-omni-node --------- Co-authored-by:
Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com> Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-
Andrii authored
[XCM] Add generic location to account converter that also works with external ecosystems for bridge hubs (#7809) That's the continuation of [PR#7313](https://github.com/paritytech/polkadot-sdk/pull/7313)
-
clangenb authored
I discovered in https://github.com/paritytech/polkadot-sdk/pull/7459, that the overhead benchmark is not working for glutton-westend, as the client can't send `system.remark` extrinsics. This was due to 2 issues: 1. Alice was not set as sudo. Hence, the `CheckOnlySudoAccount` deemed the extrinsic as invalid. 2. The `CheckNonce` TxExtension also marked the extrinsic as invalid, as the account doesn't exist (because glutton has no balances pallet). This PR fixes the 1.) for now. I wanted to simply remove the `CheckNonce` in the TxExtension to fix 2., but it turns out that this is not possible, as the tx-pool needs the nonce tag to identify the transaction. https://github.com/paritytech/polkadot-sdk/pull/6884 will fix sending extrinsics on glutton. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by:
Bastian Köcher <git@kchr.de> Co-authored-by:
s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
-
Dónal Murray authored
Asset Hub Next has been deployed on Westend as parachain 1100, but it's not yet a trusted teleporter. This minimal PR adds it in stable2412 so that it can be deployed right away without waiting for the rest of the release to be finalised and deployed. --------- Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
-