Skip to content
  1. May 07, 2024
    • jimdssd's avatar
      chore: fix typos (#4395) · 29c8130b
      jimdssd authored
      29c8130b
    • Branislav Kontur's avatar
      Add support for versioned notification for HRMP pallet (#4281) · b709dccd
      Branislav Kontur authored
      Closes: https://github.com/paritytech/polkadot-sdk/issues/4003 (please
      see for the problem description)
      
      ## TODO
      - [x] add more tests covering `WrapVersion` corner cases (e.g. para has
      lower version, ...)
      - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo
      is here: https://github.com/paritytech/polkadot-sdk/pull/4332)
      
      ## Questions / possible improvements
      - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version
      discovery with
      [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25
      
      ),
      there is possibility to avoid this overhead in this HRMP case to create
      new `WrapVersion` adapter for `pallet_xcm` which would not use
      `note_unknown_version`. Is it worth to do it or not?
      - [ ] There's a possibility to decouple XCM functionality from the HRMP
      pallet, allowing any relay chain to generate its own notifications. This
      approach wouldn't restrict notifications solely to the XCM. However,
      it's uncertain whether it's worthwhile or desirable to do so? It means
      making HRMP pallet more generic. E.g. hiding HRMP notifications behind
      some trait:
      	```
      	trait HrmpNotifications {
      
      		fn on_channel_open_request(
      			sender: ParaId,
      			proposed_max_capacity: u32,
      			proposed_max_message_size: u32) -> primitives::DownwardMessage;
      
      fn on_channel_accepted(recipient: ParaId) ->
      primitives::DownwardMessage;
      
      fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient:
      ParaId) -> primitives::DownwardMessage;
      	}
      	```
      and then we could have whatever adapter, `impl HrmpNotifications for
      VersionedXcmHrmpNotifications {...}`,
      	```
      	impl parachains_hrmp::Config for Runtime {
      	..
      		type HrmpNotifications = VersionedXcmHrmpNotifications;
      	..
      	}
      	```
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      b709dccd
  2. May 06, 2024
    • Egor_P's avatar
      Improve Create release draft workflow + templates for the free notes and... · e434176e
      Egor_P authored
      Improve Create release draft workflow + templates for the free notes and docker images sections in the notes (#4371)
      
      This PR has the following changes:
      
      - New templates for the free notes and docker images sections in the
      release notes. There is going to be a section for the manual additions
      to the release notes + a section with the links to the docker images for
      `polkadot` and `polkadot-parachain` binaries at the end of the release
      draft.
      - Fix for matrix section in the Create release draft flow (adds the
      release environment variable)
      - Reduction of the message which is posted to the announcement chats, as
      the current one with the full release notes text is too big.
      e434176e
    • Jun Jiang's avatar
      Upgrade a few deps (#4381) · 6e3059a8
      Jun Jiang authored
      Split from #4374
      
      This PR helps to reduce dependencies and align versions, which would
      help to move them to workspace dep
      6e3059a8
    • gupnik's avatar
      Introduces `TypeWithDefault<T, D: Get<T>>` (#4034) · 73c89d30
      gupnik authored
      Needed for: https://github.com/polkadot-fellows/runtimes/issues/248
      
      
      
      This PR introduces a new type `TypeWithDefault<T, D: Get<T>>` to be able
      to provide a custom default for any type. This can, then, be used to
      provide the nonce type that returns the current block number as the
      default, to avoid replay of immortal transactions.
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      73c89d30
  3. May 04, 2024
  4. May 03, 2024
  5. May 02, 2024
  6. May 01, 2024
    • Branislav Kontur's avatar
      HRMP - set `DefaultChannelSizeAndCapacityWithSystem` with dynamic values... · e5a93fbc
      Branislav Kontur authored
      HRMP - set `DefaultChannelSizeAndCapacityWithSystem` with dynamic values according to the `ActiveConfig` (#4332)
      
      ## Summary
      This PR enhances the capability to set
      `DefaultChannelSizeAndCapacityWithSystem` for HRMP. Currently, all
      testnets (Rococo, Westend) have a hard-coded value set as 'half of the
      maximum' determined by the live `ActiveConfig`. While this approach
      appears satisfactory, potential issues could arise if the live
      `ActiveConfig` are adjusted below these hard-coded values, necessitating
      a new runtime release with updated values. Additionally, hard-coded
      values have consequences, such as Rococo's benchmarks not functioning:
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6082656.
      
      ## Solution
      The proposed solution here is to utilize
      `ActiveConfigHrmpChannelSizeAndCapacityRatio`, which reads the current
      `ActiveConfig` and calculates `DefaultChannelSizeAndCapacityWithSystem`,
      for example, "half of the maximum" based on live data. This way,
      whenever `ActiveConfig` is modified,
      `ActiveConfigHrmpChannelSizeAndCapacityRatio` automatically returns
      adjusted values with the appropriate ratio. Thus, manual adjustments and
      new runtime releases become unnecessary.
      
      
      Relates to a comment/discussion:
      https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1541001420
      Relates to a comment/discussion:
      https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1549291588
      
      ---------
      
      Co-authored-by: command-bot <>
      e5a93fbc
    • Maciej's avatar
      Statement Distribution Per Peer Rate Limit (#3444) · 6d392c7e
      Maciej authored
      - [x] Drop requests from a PeerID that is already being served by us.
      - [x] Don't sent requests to a PeerID if we already are requesting
      something from them at that moment (prioritise other requests or wait).
      - [x] Tests
      - [ ] ~~Add a small rep update for unsolicited requests (same peer
      request)~~ not included in original PR due to potential issues with
      nodes slowly updating
      - [x] Add a metric to track the amount of dropped requests due to peer
      rate limiting
      - [x] Add a metric to track how many time a node reaches the max
      parallel requests limit in v2+
      
      Helps with but does not close yet:
      https://github.com/paritytech-secops/srlabs_findings/issues/303
      6d392c7e
  7. Apr 30, 2024
  8. Apr 29, 2024
    • Shawn Tabrizi's avatar
      Refactor XCM Simulator Example (#4220) · 4875ea11
      Shawn Tabrizi authored
      
      
      This PR does a "developer experience" refactor of the XCM Simulator
      Example.
      
      I was looking for existing code / documentation where developers could
      better learn about working with and configuring XCM.
      
      The XCM Simulator was a natural starting point due to the fact that it
      can emulate end to end XCM scenarios, without needing to spawn multiple
      real chains.
      
      However, the XCM Simulator Example was just 3 giant files with a ton of
      configurations, runtime, pallets, and tests mashed together.
      
      This PR breaks down the XCM Simulator Example in a way that I believe is
      more approachable by a new developer who is looking to navigate the
      various components of the end to end example, and modify it themselves.
      
      The basic structure is:
      
      - xcm simulator example
          - lib (tries to only use the xcm simulator macros)
          - tests
          - relay-chain
              - mod (basic runtime that developers should be familiar with)
              - xcm-config
                  - mod (contains the `XcmConfig` type
                  - various files for each custom configuration  
          - parachain
              - mock_msg_queue (custom pallet for simulator example)
              - mod (basic runtime that developers should be familiar with)
              - xcm-config
                  - mod (contains the `XcmConfig` type
                  - various files for each custom configuration
      
      I would like to add more documentation to this too, but I think this is
      a first step to be accepted which will affect how documentation is added
      to the example
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      4875ea11
    • Ankan's avatar
      [Staking] Not allow reap stash for virtual stakers (#4311) · 0031d49d
      Ankan authored
      Related to https://github.com/paritytech/polkadot-sdk/pull/3905.
      
      Since virtual stakers does not have a real balance, they should not be
      allowed to be reaped.
      
      The proper reaping for agents slashed will be done in a separate PR.
      0031d49d
    • Tin Chung's avatar
      Remove hard-coded indices from pallet-xcm tests (#4248) · f34d8e3c
      Tin Chung authored
      # ISSUE
      - Link to issue: https://github.com/paritytech/polkadot-sdk/issues/4237
      
      
      
      # DESCRIPTION
      Remove all ModuleError with hard-coded indices to pallet Error. For
      example:
      ```rs
      Err(DispatchError::Module(ModuleError {
      	index: 4,
      	error: [2, 0, 0, 0],
      	message: Some("Filtered")
      }))
      ```
      To 
      ```rs
      let expected_result = Err(crate::Error::<Test>::Filtered.into());
      assert_eq!(result, expected_result);
      ```
      # TEST OUTCOME
      ```
      test result: ok. 74 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s
      ```
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      f34d8e3c
  9. Apr 28, 2024
  10. Apr 26, 2024