1. Nov 30, 2023
  2. Nov 29, 2023
    • Will | Paradox | ParaNodes.io's avatar
      Adding LuckyFriday's Bootnodes per IBP Application (#2538) · 2858cbc2
      Will | Paradox | ParaNodes.io authored
      Good day,
      
      This PR requests the inclusion of two bootnode entries for Polkadot,
      Kusama and Westend as part of LuckyFriday's IBP application. The nodes
      are hosted on self-owned hardware in a co-located facility. We've
      undertaken connectivity tests ourselves and also from members of the
      IBP.
      
      The test commands used are as follows:
      
      ```
      polkadot --chain westend --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-westend.luckyfriday.io/tcp/30334/wss/p2p/12D3KooWDg1YEytdwFFNWroFj6gio4YFsMB3miSbHKgdpJteUMB9" --no-hardware-benchmarks
      
      polkadot --chain westend --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-westend.luckyfriday.io/tcp/30333/p2p/12D3KooWDg1YEytdwFFNWroFj6gio4YFsMB3miSbHKgdpJteUMB9" --no-hardware-benchmarks
      
      polkadot --chain kusama --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-kusama.luckyfriday.io/tcp/30334/wss/p2p/12D3KooW9vu1GWHBuxyhm7rZgD3fhGZpNajPXFexadvhujWMgwfT" --no-hardware-benchmarks
      
      polkadot --chain kusama --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-kusama.luckyfriday.io/tcp/30333/p2p/12D3KooW9vu1GWHBuxyhm7rZgD3fhGZpNajPXFexadvhujWMgwfT" --no-hardware-benchmarks
      
      polkadot --chain polkadot --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-polkadot.luckyfriday.io/tcp/30334/wss/p2p/12D3KooWEjk6QXrZJ26fLpaajisJGHiz6WiQsR8k7mkM9GmWKnRZ" --no-hardware-benchmarks
      
      polkadot --chain polkadot --base-path /tmp/node --name "Boot" --reserved-only --reserved-nodes "/dns/ibp-boot-polkadot.luckyfriday.io/tcp/30333/p2p/12D3KooWEjk6QXrZJ26fLpaajisJGHiz6WiQsR8k7mkM9GmWKnRZ" --no-hardware-benchmarks
      ```
      
      All tests yielded syncing with 1 peer, a positive result. We have also
      backed up our node-key in the event that restoration is required.
      
      I hope that the aforementioned meets the requirement for inclusion and
      look forward to a speedy turnaround.
      
      Kind Regards,
      Will | Paradox
      2858cbc2
    • Bastian Köcher's avatar
      ParachainHost: No need to be generic over the block or hash type (#2537) · d3d301fa
      Bastian Köcher authored
      The `BlockNumber` and `Hash` are fixed types any way.
      d3d301fa
  3. Nov 28, 2023
    • Aaro Altonen's avatar
      Rework the event system of `sc-network` (#1370) · e71c484d
      Aaro Altonen authored
      This commit introduces a new concept called `NotificationService` which
      allows Polkadot protocols to communicate with the underlying
      notification protocol implementation directly, without routing events
      through `NetworkWorker`. This implies that each protocol has its own
      service which it uses to communicate with remote peers and that each
      `NotificationService` is unique with respect to the underlying
      notification protocol, meaning `NotificationService` for the transaction
      protocol can only be used to send and receive transaction-related
      notifications.
      
      The `NotificationService` concept introduces two additional benefits:
        * allow protocols to start using custom handshakes
        * allow protocols to accept/reject inbound peers
      
      Previously the validation of inbound connections was solely the
      responsibility of `ProtocolController`. This caused issues with light
      peers and `SyncingEngine` as `ProtocolController` would accept more
      peers than `SyncingEngine` could accept which caused peers to have
      differing views of their own states. `SyncingEngine` would reject excess
      peers but these rejections were not properly communicated to those peers
      causing them to assume that they were accepted.
      
      With `NotificationService`, the local handshake is not sent to remote
      peer if peer is rejected which allows it to detect that it was rejected.
      
      This commit also deprecates the use of `NetworkEventStream` for all
      notification-related events and going forward only DHT events are
      provided through `NetworkEventStream`. If protocols wish to follow each
      other's events, they must introduce additional abtractions, as is done
      for GRANDPA and transactions protocols by following the syncing protocol
      through `SyncEventStream`.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/512
      Fixes https://github.com/paritytech/polkadot-sdk/issues/514
      Fixes https://github.com/paritytech/polkadot-sdk/issues/515
      Fixes https://github.com/paritytech/polkadot-sdk/issues/554
      Fixes https://github.com/paritytech/polkadot-sdk/issues/556
      
      ---
      These changes are transferred from
      https://github.com/paritytech/substrate/pull/14197
      
       but there are no
      functional changes compared to that PR
      
      ---------
      
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      e71c484d
    • André Silva's avatar
      polkadot: remove grandpa pause support (#2511) · b0b4451f
      André Silva authored
      This was never used and we probably don't need it anyway.
      b0b4451f
    • s0me0ne-unkn0wn's avatar
    • Marcin S.'s avatar
      PVF: Add test instructions (#2058) · dbd8d20b
      Marcin S. authored
      dbd8d20b
    • gupnik's avatar
      Moves all test runtimes to use `derive_impl` (#2409) · cd8741c8
      gupnik authored
      Step in https://github.com/paritytech/polkadot-sdk/issues/171
      
      
      
      This PR adds `derive_impl` on all `frame_system` config impls for mock
      runtimes. The overridden configs are maintained as of now to ensure
      minimal changes.
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      cd8741c8
    • André Silva's avatar
      polkadot: disable block authoring backoff on production networks (#2510) · 58a1f9c5
      André Silva authored
      Currently the polkadot node will backoff from block authoring if
      finality starts lagging. This PR disables this mechanism on production
      networks (polkadot and kusama) and adds a flags to optionally force
      enabling it.
      58a1f9c5
    • Svyatoslav Nikolsky's avatar
      Added NetworkId::PolkadotBulletin variant (#2517) · 0f7ffc66
      Svyatoslav Nikolsky authored
      We're going to bridge Polkadot Bridge Hub with [Polkadot Bulletin
      chain](https://github.com/zdave-parity/polkadot-bulletin-chain) soon
      (and Rococo Bridge Hub with 1:1 copy of Polkadot Bulletin chain even
      sooner), so we need a variant for that chain in `NetworkId`. As
      suggested, I'm adding a new variant for it to the `NetworkId` (we may
      have used `ByGenesis(_)`, but decision was made to have a dedicated
      variant for that).
      0f7ffc66
    • Ross Bulat's avatar
      Pools: Add ability to configure commission claiming permissions (#2474) · 75062717
      Ross Bulat authored
      Addresses #409.
      
      This request has been raised by multiple community members - the ability
      for the nomination pool root role to configure permissionless commission
      claiming:
      
      > Would it be possible to have a claim_commission_other extrinsic for
      claiming commission of nomination pools permissionless?
      
      This PR does not quite introduce this additional call, but amends
      `do_claim_commission` to check a new `claim_permission` field in the
      `Commission` struct, configured by an enum:
      
      ```
      enum CommissionClaimPermission {
         Permissionless,
         Account(AccountId),
      }
      ```
      This can be optionally set in a bonded pool's
      `commission.claim_permission` field:
      
      ```
      struct BondedPool {
         commission: {
            <snip>
            claim_permission: Option<CommissionClaimPermission<T::AccountId>>,
         },
         <snip>
      }
      ```
      
      This is a new field and requires a migration to add it to existing
      pools. This will be `None` on pool creation, falling back to the `root`
      role having sole access to claim commission if it is not set; this is
      the behaviour as it is today. Once set, the field _can_ be set to `None`
      again.
      
      #### Changes
      - [x] Add `commision.claim_permission` field.
      - [x] Add `can_claim_commission` and amend `do_claim_commission`.
      - [x] Add `set_commission_claim_permission` call.
      - [x] Test to cover new configs and call.
      - [x] Add and amend benchmarks.
      - [x] Generate new weights + slot into call
      `set_commission_claim_permission`.
      - [x] Add migration to introduce `commission.claim_permission`, bump
      storage version.
      - [x] Update Westend weights.
      - [x] Migration working.
      
      ---------
      
      Co-authored-by: command-bot <>
      75062717
  4. Nov 27, 2023
    • Koute's avatar
      Build the standard library crates when building the runtimes (#2217) · 2610450a
      Koute authored
      Our executor currently only supports the WASM MVP feature set, however
      nowadays when compiling WASM the Rust compiler has more features enabled
      by default.
      
      We do set the `-C target-cpu=mvp` flag to make sure that *our* code gets
      compiled in a way that is compatible with our executor, however this
      doesn't affect Rust's standard library crates (`std`, `core` and
      `alloc`) which are by default precompiled and still can make use of
      these extra features.
      
      So in this PR we force the compiler to also compile the standard library
      crates for us to make sure that they also only use the MVP features.
      
      I've added the `WASM_BUILD_STD` environment variable which can be used
      to disable this behavior if set to `0`.
      
      Unfortunately this *will* slow down the compile times when building
      runtimes, but there isn't much that we can do about that.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1755
      
      
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      2610450a
    • Maciej's avatar
      Zombienet tests - disputes on finalized blocks (#2184) · dc69dbba
      Maciej authored
      
      
      **Overview:**
      Adding an extra malus variant focusing on disputing finalized blocks. It
      will:
      - wrap around approval-voting
      - listen to `OverseerSignal::BlockFinalized` and when encountered start
      a dispute for the `dispute_offset`th ancestor
      - simply pass through all other messages and signals
      
      Add zombienet tests testing various edgecases:
      - disputing freshly finalized blocks
      - disputing stale finalized blocks
      - disputing eagerly pruned finalized blocks (might be separate PR)
      
      **TODO:**
      - [x] Register new malus variant
      - [x] Simple pass through wrapper (approval-voting)
      - [x] Simple network definition
      - [x] Listen to block finalizations
      - [x] Fetch ancestor hash
      - [x] Fetch session index
      - [x] Fetch candidate
      - [x] Construct and send dispute message
      - [x] zndsl test 1 checking that disputes on fresh finalizations resolve
      valid Closes #1365
      - [x] zndsl test 2 checking that disputes for too old finalized blocks
      are not possible Closes #1364
      - [ ] zndsl test 3 checking that disputes for candidates with eagerly
      pruned relay parent state are handled correctly #1359 (deferred to a
      separate PR)
      - [x] Unit tests for new malus variant (testing cli etc)
      - [x] Clean/streamline error handling
      - [ ] ~~Ensure it tests properly on session boundaries~~
      
      ---------
      
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      dc69dbba
    • Chevdor's avatar
      New runtime `spec_version` format + backport of the bump to 1.4.0 (#2468) · 4f8048b9
      Chevdor authored
      ## Overview
      
      This PR aligns the `spec_version` formatting to the [recent
      changes](https://github.com/polkadot-fellows/runtimes/pull/26/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R142
      
      )
      made for the Polkadot/Kusama runtimes.
      
      It also backports the latest version `v1.4.0` bumps as `1_004_000`.
      
      ## Details
      
      During the switch from `v0.9` to `v1.x`, the format of the
      `spec_version` was modified from: `(M)m_ppp` for a runtime considered on
      version `M.m.pp`. For instance `0.9.42` had a `spec_version` of `9420`.
      
      With the transition to `v1.x`, the format was changed to a bigger number
      (still `u32`) formatted as `MM_mm_ppp` where `1.2.3` would be stored as
      `01_02_003`.
      
      This PR aligns the format with that has been introduced in the
      fellowship repo: `MMM_mmm_ppp`.
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      4f8048b9
  5. Nov 25, 2023
  6. Nov 24, 2023
  7. Nov 23, 2023
  8. Nov 22, 2023
  9. Nov 21, 2023
  10. Nov 20, 2023
  11. Nov 19, 2023
  12. Nov 17, 2023
  13. Nov 16, 2023
  14. Nov 15, 2023
    • Adrian Catangiu's avatar
      xcm: SovereignPaidRemoteExporter: remove unused RefundSurplus instruction (#2312) · 824b7823
      Adrian Catangiu authored
      Refunding surplus happens anyway on xcm_executor::post_process(),
      automatically refunding surplus to original_origin at the end of
      execution. Since SovereignPaidRemoteExporter doesn't ClearOrigin, it can
      simply rely on the automatic mechanism.
      
      Furthermore, RefundSurplus instruction refunds _surplus_. Surplus exists
      only as a result of Transact, SetErrorHandler or SetAppendix
      instructions, none of which being part of the
      SovereignPaidRemoteExporter XCM program. So surplus is always zero here
      anyway.
      824b7823
    • joe petrowski's avatar
      Identity Deposits Relay to Parachain Migration (#1814) · c79b234b
      joe petrowski authored
      The goal of this PR is to migrate Identity deposits from the Relay Chain
      to a system parachain.
      
      The problem I want to solve is that `IdentityOf` and `SubsOf` both store
      an amount that's held in reserve as a storage deposit. When migrating to
      a parachain, we can take a snapshot of the actual `IdentityInfo` and
      sub-account mappings, but should migrate (off chain) the `deposit`s to
      zero, since the chain (and by extension, accounts) won't have any funds
      at genesis.
      
      The good news is that we expect parachain deposits to be significantly
      lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
      the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
      migrate the deposits in the following way:
      
      1. Introduces a new pallet with two extrinsics: 
      - `reap_identity`: Has a configurable `ReapOrigin`, which would be set
      to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
      `EnsureRoot` on the parachain (we don't want identities reaped from
      there).
      - `poke_deposit`: Checks what deposit the pallet holds (at genesis,
      zero) and attempts to update the amount based on the calculated deposit
      for storage data.
      2. `reap_identity` clears all storage data for a `target` account and
      unreserves their deposit.
      3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
      and calls `poke_deposit`. Since the parachain deposit is much lower, and
      was just unreserved, we know we have enough.
      
      One awkwardness I ran into was that the XCMv3 instruction set does not
      provide a way for the system to teleport assets without a fee being
      deducted on reception. Users shouldn't have to pay a fee for the system
      to migrate their info to a more efficient location. So I wrote my own
      program and did the `InitiateTeleport` accounting on my own to send a
      program with `UnpaidExecution`. Have discussed an
      `InitiateUnpaidTeleport` instruction with @franciscoaguirre . Obviously
      any chain executing this would have to pass a `Barrier` for free
      execution.
      
      TODO:
      
      - [x] Confirm People Chain ParaId
      - [x] Confirm People Chain deposit rates (determined in
      https://github.com/paritytech/polkadot-sdk/pull/2281
      
      )
      - [x] Add pallet to Westend
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      c79b234b
    • Adrian Catangiu's avatar
      pallet-xcm: use XcmTeleportFilter for teleported fees in reserve transfers (#2322) · f5360436
      Adrian Catangiu authored
      Disallow reserve transfers that use teleportable fees if `(origin,
      fees)` matches `XcmTeleportFilter`.
      
      Add regression tests for filtering based on `XcmTeleportFilter` for both
      `(limited_)reserve_transfer_assets()` and `(limited_)teleport_assets`
      extrinsics.
      f5360436
  15. Nov 14, 2023