Skip to content
Snippets Groups Projects
  1. Oct 07, 2024
  2. Oct 06, 2024
  3. Oct 05, 2024
    • Javier Viola's avatar
    • Maksym H's avatar
      update runners for cmd and docs (#5938) · cb8f4665
      Maksym H authored
      Updated runners for CMD and Docs
    • Cyrill Leutwiler's avatar
      [pallet-revive] immutable data storage (#5861) · a8ebe9af
      Cyrill Leutwiler authored
      
      This PR introduces the concept of immutable storage data, used for
      [Solidity immutable
      variables](https://docs.soliditylang.org/en/latest/contracts.html#immutable).
      
      This is a minimal implementation. Immutable data is attached to a
      contract; to keep `ContractInfo` fixed in size, we only store the length
      there, and store the immutable data in a dedicated storage map instead.
      Which comes at the cost of requiring an additional storage read (costly)
      for contracts using this feature.
      
      We discussed more optimal solutions not requiring any additional storage
      accesses internally, but they turned out to be non-trivial to implement.
      Another optimization benefiting multiple calls to the same contract in a
      single call stack would be to cache the immutable data in `Stack`.
      However, this potential creates a DOS vulnerability (the attack vector
      is to call into as many contracts in a single stack as possible, where
      they all have maximum immutable data to fill the cache as efficiently as
      possible). So this either has to be guaranteed to be a non-issue by
      limits, or, more likely, to have some logic to bound the cache.
      Eventually, we should think about introducing the concept of warm and
      cold storage reads (akin to EVM). Since immutable variables are commonly
      used in contracts, this change is blocking our initial launch and we
      should only optimize it properly in follow-ups.
      
      This PR also disables the `set_code_hash` API (which isn't usable for
      Solidity contracts without pre-compiles anyways). With immutable storage
      attached to contracts, we now want to run the constructor of the new
      code hash to collect the immutable data during `set_code_hash`. This
      will be implemented in a follow up PR.
      
      ---------
      
      Signed-off-by: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
      Signed-off-by: default avatarxermicus <cyrill@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
    • Branislav Kontur's avatar
      Bridge relayer backwards compatibility for reading storage InboundLaneData/OutboundLaneData (#5921) · 73bf37ab
      Branislav Kontur authored
      For permissionless lanes, we add `lane_state` to the `InboundLaneData`
      and `OutboundLaneData` structs. However, for a period of time (until
      both BHK and BHP are upgraded to the same version), we need the relayer
      to function with runtimes where one has been migrated with `lane_state`
      and the other has not. This PR addresses the incompatibility by
      introducing wrapper structs for decoding without `lane_state`.
    • Adrian Catangiu's avatar
      XCM paid execution barrier supports more origin altering instructions (#5917) · d968c941
      Adrian Catangiu authored
      The AllowTopLevelPaidExecutionFrom allows ClearOrigin instructions
      before the expected BuyExecution instruction, it also allows messages
      without any origin altering instructions.
      
      This commit enhances the barrier to also support messages that use
      AliasOrigin, or DescendOrigin. This is sometimes desired in asset
      transfer XCM programs that need to run the inbound assets instructions
      using the origin chain root origin, but then want to drop privileges for
      the rest of the program. Currently these programs drop privileges by
      clearing the origin completely, but that also unnecessarily limits the
      range of actions available to the rest of the program. Using
      DescendOrigin or AliasOrigin allows the sending chain to instruct the
      receiving chain what the deprivileged real origin is.
      
      See https://github.com/polkadot-fellows/RFCs/pull/109 and
      https://github.com/polkadot-fellows/RFCs/pull/122
      
       for more details on
      how DescendOrigin and AliasOrigin could be used instead of ClearOrigin.
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <adrian@parity.io>
    • Iulian Barbu's avatar
      templates: add genesis config presets for minimal/solochain (#5868) · f8807d1e
      Iulian Barbu authored
      # Description
      
      Closes [#5790](https://github.com/paritytech/polkadot-sdk/issues/5790).
      Useful for starting nodes based on minimal/solochain when doing
      development or for testing omni node with less happy code paths. It is
      reusing the presets defined for the nodes chain specs.
      
      ## Integration
      
      Specifically useful for development/testing if generating chain-specs
      for `minimal` or `solochain` runtimes from `templates` directories.
      
      ## Review Notes
      
      Added `genesis_config_presets` modules for both minimal/solochain. I
      reused the presets defined in each node `chain_spec` module
      correspondingly.
      
      ### PRDOC
      
      Not sure who uses templates, maybe node devs and runtime devs at start
      of their learning journey, but happy to get some guidance on how to
      write the prdoc if needed.
      
      ### Thinking out loud
      
      I saw concerns around sharing functionality for such genesis config
      presets between the template chains. I think there might be a case for
      doing that, on the lines of this comment:
      https://github.com/paritytech/polkadot-sdk/pull/4739#issuecomment-2157341035.
      I would add that `parachains-common::genesis_config_heleper` contains a
      few methods from those mentioned, but I am unsure if using it as a
      dependency for templates is correct. Feels like the comment suggests
      there should be a `commons` crate concerning just `templates`, which I
      agree with to some degree, if we assume `cumulus` needs might be driven
      in certain directions that are not relevant to `templates` and vice
      versa. However I am not so certain about this, so would welcome some
      thoughts, since I am seeing `parachains-common` being used already in a
      few runtime implementations:
      https://crates.io/crates/parachains-common/reverse_dependencies?page=3
      
      ,
      so might be a good candidate already for the `common` logic.
      
      ---------
      
      Signed-off-by: default avatarIulian Barbu <iulian.barbu@parity.io>
  4. Oct 04, 2024
  5. Oct 03, 2024
    • Branislav Kontur's avatar
      Simplify bridges relayer cli configuration (#5912) · a995caf7
      Branislav Kontur authored
      This PR removes the requirement to set the `LaneId` in the relayer CLI
      configuration where it was not really necessary.
      
      ---------
      
      Co-authored-by: command-bot <>
    • Maksym H's avatar
      Re-establish pallet_revive weights baseline (#5845) · 72309bd8
      Maksym H authored
      - update baseline for pallet_revive
      - update cmd pipeline name
      - Fix compilation after renaming some of benchmarks in pallet_revive.
      [Runtime Dev]. Changed the "instr" benchmark so that it should no longer
      return to little weight. It is still bogus but at least benchmarking
      should not work. (by @athei
      
       )
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
      Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      Co-authored-by: default avatarAlexander Samusev <41779041+alvicsam@users.noreply.github.com>
      Co-authored-by: command-bot <>
    • Niklas Adolfsson's avatar
      rpc v2: backpressure chainHead_v1_storage (#5741) · 33131634
      Niklas Adolfsson authored
      
      Close https://github.com/paritytech/polkadot-sdk/issues/5589
      
      This PR makes it possible for `rpc_v2::Storage::query_iter_paginated` to
      be "backpressured" which is achieved by having a channel where the
      result is sent back and when this channel is "full" we pause the
      iteration.
      
      The chainHead_follow has an internal channel which doesn't represent the
      actual connection and that is set to a very small number (16). Recall
      that the JSON-RPC server has a dedicate buffer for each connection by
      default of 64.
      
      #### Notes
      
      - Because `archive_storage` also depends on
      `rpc_v2::Storage::query_iter_paginated` I had to tweak the method to
      support limits as well. The reason is that archive_storage won't get
      backpressured properly because it's not an subscription. (it would much
      easier if it would be a subscription in rpc v2 spec because nothing
      against querying huge amount storage keys)
      - `query_iter_paginated` doesn't necessarily return the storage "in
      order" such as
      - `query_iter_paginated(vec![("key1", hash), ("key2", value)], ...)`
      could return them in arbitrary order because it's wrapped in
      FuturesUnordered but I could change that if we want to process it
      inorder (it's slower)
      - there is technically no limit on the number of storage queries in each
      `chainHead_v1_storage call` rather than the rpc max message limit which
      10MB and only allowed to max 16 calls `chainHead_v1_x` concurrently
      (this should be fine)
      
      #### Benchmarks using subxt on localhost
      
      - Iterate over 10 accounts on westend-dev -> ~2-3x faster 
      - Fetch 1024 storage values (i.e, not descedant values) -> ~50x faster
      - Fetch 1024 descendant values -> ~500x faster
      
      The reason for this is because as Josep explained in the issue is that
      one is only allowed query five storage items per call and clients has
      make lots of calls to drive it forward..
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarJames Wilson <james@jsdw.me>
    • Javier Viola's avatar
      bump zombienet version `v1.3.112` (#5916) · 00f7104c
      Javier Viola authored
      Bump `zombienet` version, including fixes (`ci`) and the latest version
      of `pjs` embedded.
      Thx!
  6. Oct 02, 2024
  7. Oct 01, 2024
    • Serban Iorga's avatar
      Beefy equivocation: check all the MMR roots (#5857) · 3de2a925
      Serban Iorga authored
      
      Normally, the BEEFY protocol only accepts a single MMR Root entry in a
      commitment's payload. But to be extra careful, when validating
      equivocation reports, let's check all the MMR roots, if there are more.
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
    • Andrei Eres's avatar
      Remove ValidateFromChainState (#5707) · 1617852a
      Andrei Eres authored
      # Description
      
      This PR removes the
      `CandidateValidationMessage::ValidateFromChainState`, which was
      previously used by backing, but is no longer relevant since initial
      async backing implementation
      https://github.com/paritytech/polkadot/pull/5557.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/5643
      
      ## Integration
      
      This change should not affect downstream projects since
      `ValidateFromChainState` was already unused.
      
      ## Review Notes
      
      - Removed all occurrences of `ValidateFromChainState`.
      - Moved utility functions, previously used in candidate validation tests
      and malus, exclusively to candidate validation tests as they are no
      longer used in malus.
      - Deleted the
      `polkadot_parachain_candidate_validation_validate_from_chain_state`
      metric from Prometheus.
      - Removed `Spawner` from `ReplaceValidationResult` in malus’
      interceptors.
      - `fake_validation_error` was only used for `ValidateFromChainState`
      handling, while other cases directly used
      `InvalidCandidate::InvalidOutputs`. It has been replaced with
      `fake_validation_error`, with a fallback to
      `InvalidCandidate::InvalidOutputs`.
      - Updated overseer’s minimal example to replace `ValidateFromChainState`
      with `ValidateFromExhaustive`.
  8. Sep 30, 2024
    • dependabot[bot]'s avatar
      Bump syn from 2.0.77 to 2.0.79 in the known_good_semver group (#5864) · 8279d104
      dependabot[bot] authored
      
      Bumps the known_good_semver group with 1 update:
      [syn](https://github.com/dtolnay/syn).
      
      Updates `syn` from 2.0.77 to 2.0.79
      <details>
      <summary>Release notes</summary>
      <p><em>Sourced from <a
      href="https://github.com/dtolnay/syn/releases">syn's
      releases</a>.</em></p>
      <blockquote>
      <h2>2.0.79</h2>
      <ul>
      <li>Fix infinite loop on parsing chained ranges (<a
      href="https://redirect.github.com/dtolnay/syn/issues/1741">#1741</a>)</li>
      <li>Fix panic in parsing <code>use</code> items containing absolute
      paths (<a
      href="https://redirect.github.com/dtolnay/syn/issues/1742">#1742</a>)</li>
      </ul>
      <h2>2.0.78</h2>
      <ul>
      <li>Fix infinite loop on chained comparison (<a
      href="https://redirect.github.com/dtolnay/syn/issues/1739">#1739</a>)</li>
      </ul>
      </blockquote>
      </details>
      <details>
      <summary>Commits</summary>
      <ul>
      <li><a
      href="https://github.com/dtolnay/syn/commit/732e6e39406538aebe34ed5f5803113a48c28602"><code>732e6e3</code></a>
      Release 2.0.79</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/af63396422250a1c7c80e6f12da08ce31ea435af"><code>af63396</code></a>
      Merge pull request <a
      href="https://redirect.github.com/dtolnay/syn/issues/1742">#1742</a>
      from dtolnay/usecrateroot</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/31e863233872eb3f4239a25f42030c369c22d72b"><code>31e8632</code></a>
      Fix construction of UseGroup containing crate roots</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/037861ac3ca6f91aec7f7c20811535488dafaec4"><code>037861a</code></a>
      Merge pull request <a
      href="https://redirect.github.com/dtolnay/syn/issues/1741">#1741</a>
      from dtolnay/binoploop</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/8df4dd0fa4c353a2979bd56c34955e9335bb701d"><code>8df4dd0</code></a>
      Force cursor to advance in parse_expr calls</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/09d020f5a10b3d3e4d54ec03290f773be91b9cac"><code>09d020f</code></a>
      Release 2.0.78</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/7eaebfbb470fd056ee95ec892fc012ce292e7209"><code>7eaebfb</code></a>
      Merge pull request <a
      href="https://redirect.github.com/dtolnay/syn/issues/1739">#1739</a>
      from dtolnay/chainedcomparison</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/b3d2886fc9bbff5eb45995c72beec0463a8cec2a"><code>b3d2886</code></a>
      Fix infinite loop on chained comparison</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/3f3d0c57ac66b4fa42a3f10209dd1fde29c5ce57"><code>3f3d0c5</code></a>
      Add regression test for issue 1738</li>
      <li><a
      href="https://github.com/dtolnay/syn/commit/346efaec55d7a3865a42fcd1007f45a8a7549052"><code>346efae</code></a>
      Touch up PR 1737</li>
      <li>Additional commits viewable in <a
      href="https://github.com/dtolnay/syn/compare/2.0.77...2.0.79">compare
      view</a></li>
      </ul>
      </details>
      <br />
      
      
      [![Dependabot compatibility
      score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=syn&package-manager=cargo&previous-version=2.0.77&new-version=2.0.79)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
      
      Dependabot will resolve any conflicts with this PR as long as you don't
      alter it yourself. You can also trigger a rebase manually by commenting
      `@dependabot rebase`.
      
      [//]: # (dependabot-automerge-start)
      [//]: # (dependabot-automerge-end)
      
      ---
      
      <details>
      <summary>Dependabot commands and options</summary>
      <br />
      
      You can trigger Dependabot actions by commenting on this PR:
      - `@dependabot rebase` will rebase this PR
      - `@dependabot recreate` will recreate this PR, overwriting any edits
      that have been made to it
      - `@dependabot merge` will merge this PR after your CI passes on it
      - `@dependabot squash and merge` will squash and merge this PR after
      your CI passes on it
      - `@dependabot cancel merge` will cancel a previously requested merge
      and block automerging
      - `@dependabot reopen` will reopen this PR if it is closed
      - `@dependabot close` will close this PR and stop Dependabot recreating
      it. You can achieve the same result by closing it manually
      - `@dependabot show <dependency name> ignore conditions` will show all
      of the ignore conditions of the specified dependency
      - `@dependabot ignore <dependency name> major version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's major version (unless you unignore this specific
      dependency's major version or upgrade to it yourself)
      - `@dependabot ignore <dependency name> minor version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's minor version (unless you unignore this specific
      dependency's minor version or upgrade to it yourself)
      - `@dependabot ignore <dependency name>` will close this group update PR
      and stop Dependabot creating any more for the specific dependency
      (unless you unignore this specific dependency or upgrade to it yourself)
      - `@dependabot unignore <dependency name>` will remove all of the ignore
      conditions of the specified dependency
      - `@dependabot unignore <dependency name> <ignore condition>` will
      remove the ignore condition of the specified dependency and ignore
      conditions
      
      
      </details>
      
      Signed-off-by: default avatardependabot[bot] <support@github.com>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
    • Joseph Zhao's avatar
      Replace lazy_static with LazyLock (#5716) · a8d8596f
      Joseph Zhao authored
      
      # Description
      
      close #5641
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
    • Egor_P's avatar
      [Backport] Version bumps and prdocs reordering from stable2409 (#5849) · 9283dc1d
      Egor_P authored
      
      This PR backports regular version bumps and prdocs reordering from the
      `stable2409` release branch to `master`
      
      ---------
      
      Co-authored-by: default avatarMorgan Adamiec <morgan@parity.io>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarNazar Mokrynskyi <nazar@mokrynskyi.com>
    • Alexander Samusev's avatar
Loading