Skip to content
  1. Apr 25, 2024
  2. Apr 24, 2024
  3. Apr 23, 2024
  4. Apr 22, 2024
  5. Apr 20, 2024
    • thiolliere's avatar
      Fix case in type in macro generation (#4223) · f3c3ebb6
      thiolliere authored
      Generated type is not camel case this generate some warnings from IDE
      
      label should be R0
      f3c3ebb6
    • Ankan's avatar
      Allow privileged virtual bond in Staking pallet (#3889) · e504c41a
      Ankan authored
      This is the first PR in preparation for
      https://github.com/paritytech/polkadot-sdk/issues/454.
      
      ## Follow ups:
      - https://github.com/paritytech/polkadot-sdk/pull/3904.
      - https://github.com/paritytech/polkadot-sdk/pull/3905.
      
      Overall changes are documented here (lot more visual 😍):
      https://hackmd.io/@ak0n/454-np-governance
      
      [Maybe followup](https://github.com/paritytech/polkadot-sdk/issues/4217)
      with migration of storage item `VirtualStakers` as a bool or enum in
      `Ledger`.
      
      ## Context
      We want to achieve a way for a user (`Delegator`) to delegate their
      funds to another account (`Agent`). Delegate implies the funds are
      locked in delegator account itself. Agent can act on behalf of delegator
      to stake directly on Staking pallet.
      
      The delegation feature is added to Staking via another pallet
      `delegated-staking` worked on
      [here](https://github.com/paritytech/polkadot-sdk/pull/3904).
      
      ## Introduces:
      ### StakingUnchecked Trait
      As the name implies, this trait allows unchecked (non-locked) mutation
      of staking ledger. These apis are only meant to be used by other pallets
      in the runtime and should not be exposed directly to user code path.
      Also related: https://github.com/paritytech/polkadot-sdk/issues/3888.
      
      ### Virtual Bond
      Allows other pallets to stake via staking pallet while managing the
      locks on these accounts themselves. Introduces another storage
      `VirtualStakers` that whitelist these accounts.
      
      We also restrict virtual stakers to set reward account as themselves.
      Since the account has no locks, we cannot support compounding of
      rewards. Conservatively, we require them to set a separate account
      different from the staker. Since these are code managed, it should be
      easy for another pallet to redistribute reward and rebond them.
      
      ### Slashes
      Since there is no actual lock maintained by staking-pallet for virtual
      stakers, this pallet does not apply any slashes. It is then important
      for pallets managing virtual stakers to listen to slashing events and
      apply necessary slashes.
      e504c41a
  6. Apr 19, 2024
  7. Apr 18, 2024
  8. Apr 17, 2024
    • Muharem Ismailov's avatar
      Asset Conversion: Pool Touch Call (#3251) · 305d311d
      Muharem Ismailov authored
      Introduce `touch` call designed to address operational prerequisites
      before providing liquidity to a pool.
      
      This function ensures that essential requirements, such as the presence
      of the pool's accounts, are fulfilled. It is particularly beneficial in
      scenarios where a pool creator removes the pool's accounts without
      providing liquidity.
      
      ---------
      
      Co-authored-by: command-bot <>
      305d311d
    • PG Herveou's avatar
      Contracts: Refactor test builder (#4158) · aa78fe21
      PG Herveou authored
      - Moved `substrate/frame/contracts/src/tests/builder.rs` into a pub
      test_utils module, so we can use that in the
      `pallet-contracts-mock-network` tests
      - Refactor xcm tests to use XCM builders, and simplify the use case for
      xcm-send
      aa78fe21
    • Oliver Tale-Yazdi's avatar
      Fix nostd build of several crates (#4060) · 7a2c9d4a
      Oliver Tale-Yazdi authored
      
      
      Preparation for https://github.com/paritytech/polkadot-sdk/pull/3935
      
      Changes:
      - Add some `default-features = false` for the case that a crate and that
      dependency both support nostd builds.
      - Shuffle files around of some benchmarking-only crates. These
      conditionally disabled the `cfg_attr` for nostd and pulled in libstd.
      Example [here](https://github.com/ggwpez/zepter/pull/95). The actual
      logic is moved into a `inner.rs` to preserve nostd capability of the
      crate in case the benchmarking feature is disabled.
      - Add some `use sp_std::vec` where needed.
      - Remove some `optional = true` in cases where it was not optional.
      - Removed one superfluous `cfg_attr(not(feature = "std"), no_std..`.
      
      All in all this should be logical no-op.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      7a2c9d4a
    • Alexandru Vasile's avatar
      chainHead: Report unique hashes for pruned blocks (#3667) · bfbf7f5d
      Alexandru Vasile authored
      
      
      This PR ensures that the reported pruned blocks are unique.
      
      While at it, ensure that the best block event is properly generated when
      the last best block is a fork that will be pruned in the future.
      
      To achieve this, the chainHead keeps a LRU set of reported pruned blocks
      to ensure the following are not reported twice:
      
      ```bash
      	 finalized -> block 1 -> block 2 -> block 3
      	
      	                      -> block 2 -> block 4 -> block 5
      	
      	           -> block 1 -> block 2_f -> block 6 -> block 7 -> block 8
      ```
      
      When block 7 is finalized the branch [block 2; block 3] is reported as
      pruned.
      When block 8 is finalized the branch [block 2; block 4; block 5] should
      be reported as pruned, however block 2 was already reported as pruned at
      the previous step.
      
      This is a side-effect of the pruned blocks being reported at level N -
      1. For example, if all pruned forks would be reported with the first
      encounter (when block 6 is finalized we know that block 3 and block 5
      are stale), we would not need the LRU cache.
      
      cc @paritytech/subxt-team  
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3658
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      bfbf7f5d
    • thiolliere's avatar
      Improve doc for pallet macro and config macro (#4146) · ca7c01c8
      thiolliere authored
      Improve doc:
      
      * the pallet macro is actually referring to 2 places, for the module and
      for the struct placeholder but doesn't really clarify it (I should have
      named the latter just `pallet_struct` or something but it is a bit late)
      
      * The doc of `with_default` is a bit confusing too IMO.
      
      CC @Kianenigma
      
      
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      ca7c01c8
    • Muharem Ismailov's avatar
      Asset Conversion: Pool Account ID derivation with additional Pallet ID seed (#3250) · 4e10d3b0
      Muharem Ismailov authored
      Introduce `PalletId` as an additional seed parameter for pool's account
      id derivation.
      
      The PR also introduces the `pallet_asset_conversion_ops` pallet with a
      call to migrate a given pool to thew new account. Additionally
      `fungibles::lifetime::ResetTeam` and `fungible::lifetime::Refund`
      traits, to facilitate the migration of pools.
      
      ---------
      
      Co-authored-by: command-bot <>
      4e10d3b0
    • Sergej Sakac's avatar
      XCM coretime region transfers (#3455) · e6f3106d
      Sergej Sakac authored
      
      
      This PR introduces changes enabling the transfer of coretime regions via
      XCM.
      
      TL;DR: There are two primary issues that are resolved in this PR:
      
      1. The `mint` and `burn` functions were not implemented for coretime
      regions. These operations are essential for moving assets to and from
      the XCM holding register.
      2. The transfer of non-fungible assets through XCM was previously
      disallowed. This was due to incorrectly benchmarking non-fungible asset
      transfers via XCM, which led to assigning it a weight of `Weight::Max`,
      effectively preventing its execution.
      
      ### `mint_into` and `burn` implementation
      
      This PR addresses the issue with cross-chain transferring regions back
      to the Coretime chain. Remote reserve transfers are performed by
      withdrawing and depositing the asset to and from the holding registry.
      This requires the asset to support burning and minting functionality.
      
      This PR adds burning and minting; however, they work a bit differently
      than usual so that the associated region record is not lost when
      burning. Instead of removing all the data, burning will set the owner of
      the region to `None`, and when minting it back, it will set it to an
      actual value. So, when cross-chain transferring, withdrawing into the
      registry will remove the region from its original owner, and when
      depositing it from the registry, it will set its owner to another
      account
      
      This was originally implemented in this PR: #3455, however we decided to
      move all of it to this single PR
      (https://github.com/paritytech/polkadot-sdk/pull/3455#discussion_r1547324892)
      
      ### Fixes made in this PR
      
      - Update the `XcmReserveTransferFilter` on coretime chain since it is
      meant as a reserve chain for coretime regions.
      - Update the XCM benchmark to use `AssetTransactor` instead of assuming
      `pallet-balances` for fungible transfers.
      - Update the XCM benchmark to properly measure weight consumption for
      nonfungible reserve asset transfers. ATM reserve transfers via the
      extrinsic do not work since the weight for it is set to `Weight::max()`.
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/865
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      e6f3106d
    • Alexandru Vasile's avatar
      grandpa: Send neighbor packet to lightclients with every finalized head (#4135) · 8fd839df
      Alexandru Vasile authored
      
      
      This PR sends the GrandpaNeighbor packet to lightclients similarly to
      the full-nodes.
      
      Previously, the lightclient would receive a GrandpaNeigbor packet only
      when the note set changed.
      
      Related to: https://github.com/paritytech/polkadot-sdk/issues/4120
      
      Next steps:
      -  [ ] check with lightclient
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      8fd839df
  9. Apr 16, 2024
  10. Apr 15, 2024
    • thiolliere's avatar
      pallet assets: Fix errors (#4118) · a8f4f4f0
      thiolliere authored
      `LiveAsset` is an error to be returned when an asset is not supposed to
      be live.
      And `AssetNotLive` is an error to be returned when an asset is supposed
      to be live, I don't think frozen qualifies as live.
      a8f4f4f0
    • Dónal Murray's avatar
      [pallet-broker] add tests for renewing leases (#4099) · 0c9ad530
      Dónal Murray authored
      The first test proves that parachains who were migrated over on a legacy
      lease can renew without downtime.
      
      The exception is if their lease expires in period 0 - aka within
      `region_length` timeslices after `start_sales` is called. The second
      test is designed such that it passes if the issue exists and should be
      fixed.
      This will require an intervention on Kusama to add these renewals to
      storage as it is too tight to schedule a runtime upgrade before the
      start_sales call. All leases will still have at least two full regions
      of coretime.
      0c9ad530
    • Alexandru Vasile's avatar
      logging(fix): Use the proper log target for logging (#4124) · d1f9fe0a
      Alexandru Vasile authored
      This PR ensures the proper logging target (ie `libp2p_tcp` or `beefy`)
      is displayed.
      
      The issue has been introduced in:
      https://github.com/paritytech/polkadot-sdk/pull/4059, which removes the
      normalized metadata of logs.
      
      From
      [documentation](https://docs.rs/tracing-log/latest/tracing_log/trait.NormalizeEvent.html#tymethod.normalized_metadata):
      
      > In tracing-log, an Event produced by a log (through
      [AsTrace](https://docs.rs/tracing-log/latest/tracing_log/trait.AsTrace.html))
      has an hard coded “log” target
      
      >
      [normalized_metadata](https://docs.rs/tracing-log/latest/tracing_log/trait.NormalizeEvent.html#tymethod.normalized_metadata):
      If this Event comes from a log, this method provides a new normalized
      Metadata which has all available attributes from the original log,
      including file, line, module_path and target
      
      This has low implications if a version was deployed containing the
      mentioned pull request, as we'll lose the ability to distinguish between
      log targets.
      
      ### Before this PR
      
      ```
      2024-04-15 12:45:40.327  INFO main log: Parity Polkadot
      2024-04-15 12:45:40.328  INFO main log: ️  version 1.10.0-d1b0ef76
      2024-04-15 12:45:40.328  INFO main log: ️  by Parity Technologies <[email protected]>, 2017-2024
      2024-04-15 12:45:40.328  INFO main log: 📋 Chain specification: Development
      2024-04-15 12:45:40.328  INFO main log: 🏷  Node name: yellow-eyes-2963
      2024-04-15 12:45:40.328  INFO main log: 👤 Role: AUTHORITY
      2024-04-15 12:45:40.328  INFO main log: 💾 Database: RocksDb at /tmp/substrated39i9J/chains/rococo_dev/db/full
      2024-04-15 12:45:44.508  WARN main log: Took active validators from set with wrong size
      ...
      
      2024-04-15 12:45:45.805  INFO                 main log: 👶 Starting BABE Authorship worker
      2024-04-15 12:45:45.806  INFO tokio-runtime-worker log: 🥩 BEEFY gadget waiting for BEEFY pallet to become available...
      2024-04-15 12:45:45.806 DEBUG tokio-runtime-worker log: New listen address: /ip6/::1/tcp/30333
      2024-04-15 12:45:45.806 DEBUG tokio-runtime-worker log: New listen address: /ip4/127.0.0.1/tcp/30333
      ```
      
      ### After this PR
      
      ```
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: Parity Polkadot
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: ️  version 1.10.0-d1b0ef76
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: ️  by Parity Technologies <[email protected]>, 2017-2024
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: 📋 Chain specification: Development
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: 🏷  Node name: helpless-lizards-0550
      2024-04-15 12:59:45.623  INFO main sc_cli::runner: 👤
      
       Role: AUTHORITY
      ...
      2024-04-15 12:59:50.204  INFO tokio-runtime-worker beefy: 🥩 BEEFY gadget waiting for BEEFY pallet to become available...
      2024-04-15 12:59:50.204 DEBUG tokio-runtime-worker libp2p_tcp: New listen address: /ip6/::1/tcp/30333
      2024-04-15 12:59:50.204 DEBUG tokio-runtime-worker libp2p_tcp: New listen address: /ip4/127.0.0.1/tcp/30333
      ```
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      d1f9fe0a
    • Bastian Köcher's avatar
      pallet_broker: Support renewing leases expired in a previous period (#4089) · 6f73b746
      Bastian Köcher authored
      Part of: https://github.com/paritytech/polkadot-sdk/issues/4107
      6f73b746
    • Bastian Köcher's avatar
      sp-api: Use macro to detect if `frame-metadata` is enabled (#4117) · d1b0ef76
      Bastian Köcher authored
      While `sp-api-proc-macro` isn't used directly and thus, it should have
      the same features enabled as `sp-api`. However, I have seen issues
      around `frame-metadata` not being enabled for `sp-api`, but for
      `sp-api-proc-macro`. This can be prevented by using the
      `frame_metadata_enabled` macro from `sp-api` that ensures we have the
      same feature set between both crates.
      d1b0ef76
    • Alexandru Gheorghe's avatar
      Prevent accidental change of network-key for active authorities (#3852) · 2bc4ed11
      Alexandru Gheorghe authored
      
      
      As discovered during investigation of
      https://github.com/paritytech/polkadot-sdk/issues/3314 and
      https://github.com/paritytech/polkadot-sdk/issues/3673 there are active
      validators which accidentally might change their network key during
      restart, that's not a safe operation when you are in the active set
      because of distributed nature of DHT, so the old records would still
      exist in the network until they expire 36h, so unless they have a good
      reason validators should avoid changing their key when they restart
      their nodes.
      
      There is an effort in parallel to improve this situation
      https://github.com/paritytech/polkadot-sdk/pull/3786, but those changes
      are way more intrusive and will need more rigorous testing, additionally
      they will reduce the time to less than 36h, but the propagation won't be
      instant anyway, so not changing your network during restart should be
      the safest way to run your node, unless you have a really good reason to
      change it.
      
      ## Proposal
      1. Do not auto-generate the network if the network file does not exist
      in the provided path. Nodes where the key file does not exist will get
      the following error:
      ```
      Error: 
         0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot/chains/ksmcc3/network/secret_ed25519.
            
             This is not a safe operation because the old identity still lives in the dht for 36 hours.
            
             Because of it your node might suffer from not being properly connected to other nodes for validation purposes.
            
             If it is the first time running your node you could use one of the following methods.
            
             1. Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts
            
             2. Separetly generate the key with: polkadot key generate-node-key --file <YOUR_PATH_TO_NODE_KEY>
      ```
      
      2. Add an explicit parameters for nodes that do want to change their
      network despite the warnings or if they run the node for the first time.
      `--unsafe-force-node-key-generation`
      
      3. For `polkadot key generate-node-key` add two new mutually exclusive
      parameters `base_path` and `default_base_path` to help with the key
      generation in the same path the polkadot main command would expect it.
       
      4. Modify the installation scripts to auto-generate a key in default
      path if one was not present already there, this should help with making
      the executable work out of the box after an instalation.
      
      ## Notes
      
      Nodes that do not have already the key persisted will fail to start
      after this change, however I do consider that better than the current
      situation where they start but they silently hide that they might not be
      properly connected to their peers.
      
      ## TODO
      - [x] Make sure only nodes that are authorities on producation chains
      will be affected by this restrictions.
      - [x] Proper PRDOC, to make sure node operators are aware this is
      coming.
      
      ---------
      
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      2bc4ed11
  11. Apr 13, 2024
  12. Apr 12, 2024
    • Vedhavyas Singareddi's avatar
      define block hash provider and default impl using frame_system (#4080) · 5b513cc0
      Vedhavyas Singareddi authored
      This PR introduces `BlockHashProvider` into `pallet_mmr::Config`
      This type is used to get `block_hash` for a given `block_number` rather
      than directly using `frame_system::Pallet::block_hash`
      
      The `DefaultBlockHashProvider` uses `frame_system::Pallet::block_hash`
      to get the `block_hash`
      
      Closes: #4062
      5b513cc0
    • Squirrel's avatar
      Remove redundent logging code (#4059) · b28ba4ae
      Squirrel authored
      
      
      1. The `CustomFmtContext::ContextWithFormatFields` enum arm isn't
      actually used and thus we don't need the enum anymore.
      
      2. We don't do anything with most of the normalized metadata that's
      created by calling `event.normalized_metadata();` - the `target` we can
      get from `event.metadata.target()` and level we can get from
      `event.metadata.level()` - let's just call them direct to simplify
      things. (`event.metadata()` is just a field call under the hood)
      
      Changelog: No functional changes, might run a tad faster with lots of
      logging turned on.
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      b28ba4ae
    • eskimor's avatar
      Improve docs of broker pallet (#3980) · a64009ae
      eskimor authored
      
      
      Small adjustments which should make understanding what is going on much
      easier for future readers.
      
      Initialization is a bit messy, the very least we should do is adding
      documentation to make it harder to use wrongly.
      
      I was thinking about calling `request_core_count` right from
      `start_sales`, but as explained in the docs, this is not necessarily
      what you want.
      
      ---------
      
      Co-authored-by: default avatareskimor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      a64009ae
    • PG Herveou's avatar
      033484c3