Skip to content
  1. Apr 22, 2024
  2. Apr 18, 2024
  3. Apr 17, 2024
    • 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
  4. Apr 16, 2024
    • PG Herveou's avatar
      Contracts verify benchmark block (#4130) · e81322bc
      PG Herveou authored
      Add verify statement to ensure that benchmarks call do not revert
      
      Also updated
      [benchmarks](https://weights.tasty.limo/compare?unit=time&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=master&new=pg/verify-benchmarks&path_pattern=substrate%2Fframe%2Fcontracts%2Fsrc%2Fweights.rs)
      
      ---------
      
      Co-authored-by: command-bot <>
      e81322bc
  5. Apr 12, 2024
  6. Apr 10, 2024
    • PG Herveou's avatar
      Contracts: Remove ED from base deposit (#3536) · 643aa2be
      PG Herveou authored
      
      
      - Update internal logic so that the storage_base_deposit does not
      include ED
      - add v16 migration to update ContractInfo struct with this change
      
      Before:
      <img width="820" alt="Screenshot 2024-03-21 at 11 23 29"
      src="https://github.com/paritytech/polkadot-sdk/assets/521091/a0a8df0d-e743-42c5-9e16-cf2ec1aa949c">
      
      After:
      ![Screenshot 2024-03-21 at 11 23
      42](https://github.com/paritytech/polkadot-sdk/assets/521091/593235b0-b866-4915-b653-2071d793228b)
      
      ---------
      
      Co-authored-by: default avatarCyrill Leutwiler <[email protected]>
      Co-authored-by: command-bot <>
      643aa2be
    • PG Herveou's avatar
      Contracts: Reuse module when validating (#3789) · 1da8d12d
      PG Herveou authored
      Reuse wasmi Module when validating.
      Prepare the code for 0.32 and the addition of Module::new_unchecked
      1da8d12d
    • PG Herveou's avatar
      Contracts: Only exec parsed code in benchmarks (#3915) · 0d71753e
      PG Herveou authored
      [Weights
      compare](https://weights.tasty.limo/compare?unit=weight&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=master&new=pg%2Fbench_tweaks&path_pattern=substrate%2Fframe%2F**%2Fsrc%2Fweights.rs%2Cpolkadot%2Fruntime%2F*%2Fsrc%2Fweights%2F**%2F*.rs%2Cpolkadot%2Fbridges%2Fmodules%2F*%2Fsrc%2Fweights.rs%2Ccumulus%2F**%2Fweights%2F*.rs%2Ccumulus%2F**%2Fweights%2Fxcm%2F*.rs%2Ccumulus%2F**%2Fsrc%2Fweights.rs)
      
      Note: Raw weights change does not mean much here, as this PR reduce the
      scope of what is benchmarked, they are therefore decreased by a good
      margin. One should instead print the Schedule using
      
      cargo test --features runtime-benchmarks bench_print_schedule --
      --nocapture
      or following the instructions from the
      [README](https://github.com/paritytech/polkadot-sdk/tree/pg/bench_tweaks/substrate/frame/contracts#schedule)
      for looking at the Schedule of a specific runtime
      
      ---------
      
      Co-authored-by: command-bot <>
      0d71753e
    • PG Herveou's avatar
      Update benchmarking macros (#3934) · d38f6e67
      PG Herveou authored
      
      
      Current benchmarking macro returns a closure with the captured
      benchmarked code.
      This can cause issues when the benchmarked code has complex lifetime
      requirements.
      
      This PR updates the existing macro by injecting the recording parameter
      and invoking the start / stop method around the benchmarked block
      instead of returning a closure
      
      One other added benefit is that you can write this kind of code now as
      well:
      
      ```rust
      let v;
      #[block]
      { v = func.call(); }
      dbg!(v); // or assert something on v
      ```
      
      
      [Weights compare
      link](https://weights.tasty.limo/compare?unit=weight&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=pg/fix-weights&new=pg/bench_update&path_pattern=substrate/frame/**/src/weights.rs,polkadot/runtime/*/src/weights/**/*.rs,polkadot/bridges/modules/*/src/weights.rs,cumulus/**/weights/*.rs,cumulus/**/weights/xcm/*.rs,cumulus/**/src/weights.rs)
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@pari...>
      d38f6e67
    • PG Herveou's avatar
      Contracts: Fix legacy uapi (#3994) · 2d927b07
      PG Herveou authored
      Fix some broken legacy definitions of pallet_contracts_uapi storage host
      functions
      2d927b07
  7. Apr 09, 2024
  8. Apr 08, 2024
    • Oliver Tale-Yazdi's avatar
      [FRAME] Runtime Omni Bencher (#3512) · 9543d314
      Oliver Tale-Yazdi authored
      This MR contains two major changes and some maintenance cleanup.  
      
      ## 1. Free Standing Pallet Benchmark Runner
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3045, depends
      on your runtime exposing the `GenesisBuilderApi` (like
      https://github.com/paritytech/polkadot-sdk/pull/1492).
      
      Introduces a new binary crate: `frame-omni-bencher`.  
      It allows to directly benchmark a WASM blob - without needing a node or
      chain spec.
      
      This makes it much easier to generate pallet weights and should allow us
      to remove bloaty code from the node.
      It should work for all FRAME runtimes that dont use 3rd party host calls
      or non `BlakeTwo256` block hashing (basically all polkadot parachains
      should work).
      
      It is 100% backwards compatible with the old CLI args, when the `v1`
      compatibility command is used. This is done to allow for forwards
      compatible addition of new commands.
      
      ### Example (full example in the Rust docs)
      
      Installing the CLI:
      ```sh
      cargo install --locked --path subs...
      9543d314
  9. Apr 02, 2024
    • Serban Iorga's avatar
      Align dependencies with `parity-bridges-common` (#3937) · 8e95a3e1
      Serban Iorga authored
      Working towards migrating the `parity-bridges-common` repo inside
      `polkadot-sdk`. This PR upgrades some dependencies in order to align
      them with the versions used in `parity-bridges-common`
      
      Related to
      https://github.com/paritytech/parity-bridges-common/issues/2538
      8e95a3e1
  10. Mar 28, 2024
  11. Mar 27, 2024
  12. Mar 26, 2024
    • Dcompoze's avatar
      Fix spelling mistakes across the whole repository (#3808) · 002d9260
      Dcompoze authored
      **Update:** Pushed additional changes based on the review comments.
      
      **This pull request fixes various spelling mistakes in this
      repository.**
      
      Most of the changes are contained in the first **3** commits:
      
      - `Fix spelling mistakes in comments and docs`
      
      - `Fix spelling mistakes in test names`
      
      - `Fix spelling mistakes in error messages, panic messages, logs and
      tracing`
      
      Other source code spelling mistakes are separated into individual
      commits for easier reviewing:
      
      - `Fix the spelling of 'authority'`
      
      - `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`
      
      - `Fix the spelling of 'prev_enqueud_messages'`
      
      - `Fix the spelling of 'endpoint'`
      
      - `Fix the spelling of 'children'`
      
      - `Fix the spelling of 'PenpalSiblingSovereignAccount'`
      
      - `Fix the spelling of 'PenpalSudoAccount'`
      
      - `Fix the spelling of 'insufficient'`
      
      - `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`
      
      - `Fix the spelling of 'subtracted'`
      
      - `Fix the spelling of 'CandidatePendingAvailability'`
      
      - `Fix the spelling of 'exclusive'`
      
      - `Fix the spelling of 'until'`
      
      - `Fix the spelling of 'discriminator'`
      
      - `Fix the spelling of 'nonexistent'`
      
      - `Fix the spelling of 'subsystem'`
      
      - `Fix the spelling of 'indices'`
      
      - `Fix the spelling of 'committed'`
      
      - `Fix the spelling of 'topology'`
      
      - `Fix the spelling of 'response'`
      
      - `Fix the spelling of 'beneficiary'`
      
      - `Fix the spelling of 'formatted'`
      
      - `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'`
      
      - `Fix the spelling of 'succeeded'`
      
      - `Fix the spelling of 'reopened'`
      
      - `Fix the spelling of 'proposer'`
      
      - `Fix the spelling of 'InstantiationNonce'`
      
      - `Fix the spelling of 'depositor'`
      
      - `Fix the spelling of 'expiration'`
      
      - `Fix the spelling of 'phantom'`
      
      - `Fix the spelling of 'AggregatedKeyValue'`
      
      - `Fix the spelling of 'randomness'`
      
      - `Fix the spelling of 'defendant'`
      
      - `Fix the spelling of 'AquaticMammal'`
      
      - `Fix the spelling of 'transactions'`
      
      - `Fix the spelling of 'PassingTracingSubscriber'`
      
      - `Fix the spelling of 'TxSignaturePayload'`
      
      - `Fix the spelling of 'versioning'`
      
      - `Fix the spelling of 'descendant'`
      
      - `Fix the spelling of 'overridden'`
      
      - `Fix the spelling of 'network'`
      
      Let me know if this structure is adequate.
      
      **Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`,
      `Merkelization`, `Merkleization`, is somewhat inconsistent but I left it
      as it is.
      
      ~~**Note:** In some places the term `Receival` is used to refer to
      message reception, IMO `Reception` is the correct word here, but I left
      it as it is.~~
      
      ~~**Note:** In some places the term `Overlayed` is used instead of the
      more acceptable version `Overlaid` but I also left it as it is.~~
      
      ~~**Note:** In some places the term `Applyable` is used instead of the
      correct version `Applicable` but I also left it as it is.~~
      
      **Note:** Some usage of British vs American english e.g. `judgement` vs
      `judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc.
      are both present in different places, but I suppose that's
      understandable given the number of contributors.
      
      ~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it
      triggers errors in CI when I make changes to it, so I left it as it
      is.~~
      002d9260
  13. Mar 20, 2024
    • dependabot[bot]'s avatar
      Bump anyhow from 1.0.75 to 1.0.81 (#3752) · bb973aa0
      dependabot[bot] authored
      Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.75 to 1.0.81.
      <details>
      <summary>Release notes</summary>
      <p><em>Sourced from <a
      href="https://github.com/dtolnay/anyhow/releases">anyhow's
      releases</a>.</em></p>
      <blockquote>
      <h2>1.0.81</h2>
      <ul>
      <li>Make backtrace support available when using -Dwarnings (<a
      href="https://redirect.github.com/dtolnay/anyhow/issues/354">#354</a>)</li>
      </ul>
      <h2>1.0.80</h2>
      <ul>
      <li>Fix unused_imports warnings when compiled by rustc 1.78</li>
      </ul>
      <h2>1.0.79</h2>
      <ul>
      <li>Work around improperly cached build script result by sccache (<a
      href="https://redirect.github.com/dtolnay/anyhow/issues/340">#340</a>)</li>
      </ul>
      <h2>1.0.78</h2>
      <ul>
      <li>Reduce spurious rebuilds under RustRover IDE when using a nightly
      toolchain (<a
      href="https://redirect.github.com/dtolnay/anyhow/issues/337">#337</a>)</li>
      </ul>
      <h2>1.0.77</h2>
      <ul>
      <li>Make <code>anyhow::Error::backtrace</code> available on stable Rust
      compilers 1.65+ (<a
      href="https://redirect.github.com/dtolnay/anyhow/issues/293">#293</a>,
      thanks <a
      href="https://github.com/LukasKalbertodt"><code>@​LukasKalbertodt</code></a>)</li>
      </ul>
      <h2>1.0.76</h2>
      <ul>
      <li>Opt in to <code>unsafe_op_in_unsafe_fn</code> lint (<a
      href="https://redirect.github.com/dtolnay/anyhow/issues/329">#329</a>)</li>
      </ul>
      </blockquote>
      </details>
      <details>
      <summary>Commits</summary>
      <ul>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/4aad4edebd9f09247d6c6b6784419a74bb116829"><code>4aad4ed</code></a>
      Release 1.0.81</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/8be90917c603199c5d1fdd73984237f023768e22"><code>8be9091</code></a>
      Merge pull request <a
      href="https://redirect.github.com/dtolnay/anyhow/issues/354">#354</a>
      from dtolnay/deadcode</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/a2eb7dd5e13add83f254b6dac0f68e043effc521"><code>a2eb7dd</code></a>
      Make compatible with -Dwarnings</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/54437197ee79c20678db433d98616fab7ddff1a5"><code>5443719</code></a>
      Release 1.0.80</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/dfc7bc07d4c41b61093c3251ed82becb51810bd4"><code>dfc7bc0c
      
      </code></a>
      Work around prelude redundant import warnings</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/6e4f86b48b5182ec71dbc8e308db9dc91e2ec8a5"><code>6e4f86b</code></a>
      Import from alloc not std, where possible</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/f885a133ede579c45e90ab489455126403d05db1"><code>f885a13</code></a>
      Ignore incompatible_msrv clippy false positives in test</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/fefbcbcb0b336a2d6c2ce6f0ee6d3fd02ef2cd3b"><code>fefbcbc</code></a>
      Ignore incompatible_msrv clippy lint</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/78f2d81cc71b79050a2fda270c45ff267557d853"><code>78f2d81</code></a>
      Update ui test suite to nightly-2024-02-08</li>
      <li><a
      href="https://github.com/dtolnay/anyhow/commit/edd88d3a43f11f1931330d3dd54189353ef00203"><code>edd88d3</code></a>
      Update ui test suite to nightly-2024-01-31</li>
      <li>Additional commits viewable in <a
      href="https://github.com/dtolnay/anyhow/compare/1.0.75...1.0.81">compare
      view</a></li>
      </ul>
      </details>
      <br />
      
      
      [![Dependabot compatibility
      score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=anyhow&package-manager=cargo&previous-version=1.0.75&new-version=1.0.81)](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 this major version` will close this PR and stop
      Dependabot creating any more for this major version (unless you reopen
      the PR or upgrade to it yourself)
      - `@dependabot ignore this minor version` will close this PR and stop
      Dependabot creating any more for this minor version (unless you reopen
      the PR or upgrade to it yourself)
      - `@dependabot ignore this dependency` will close this PR and stop
      Dependabot creating any more for this dependency (unless you reopen the
      PR or upgrade to it yourself)
      
      
      </details>
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      bb973aa0
  14. Mar 19, 2024
    • PG Herveou's avatar
      Contracts: Test benchmarking v2 (#3585) · e659c4b3
      PG Herveou authored
      Co-authored-by: command-bot <>
      e659c4b3
    • Davide Galassi's avatar
      Implement crypto byte array newtypes in term of a shared type (#3684) · 1e9fd237
      Davide Galassi authored
      Introduces `CryptoBytes` type defined as:
      
      ```rust
      pub struct CryptoBytes<const N: usize, Tag = ()>(pub [u8; N], PhantomData<fn() -> Tag>);
      ```
      
      The type implements a bunch of methods and traits which are typically
      expected from a byte array newtype
      (NOTE: some of the methods and trait implementations IMO are a bit
      redundant, but I decided to maintain them all to not change too much
      stuff in this PR)
      
      It also introduces two (generic) typical consumers of `CryptoBytes`:
      `PublicBytes` and `SignatureBytes`.
      
      ```rust
      pub struct PublicTag;
      pub PublicBytes<const N: usize, CryptoTag> = CryptoBytes<N, (PublicTag, CryptoTag)>;
      
      pub struct SignatureTag;
      pub SignatureBytes<const N: usize, CryptoTag> = CryptoBytes<N, (SignatureTag, CryptoTag)>;
      ```
      
      Both of them use a tag to differentiate the two types at a higher level.
      Downstream specializations will further specialize using a dedicated
      crypto tag. For example in ECDSA:
      
      
      ```rust
      pub struct EcdsaTag;
      
      pub type Public = PublicBytes<PUBLIC_KEY_SERIALIZED_SIZE, EcdsaTag>;
      pub type Signature = PublicBytes<PUBLIC_KEY_SERIALIZED_SIZE, EcdsaTag>;
      ```
      
      Overall we have a cleaner and most importantly **consistent** code for
      all the types involved
      
      All these details are opaque to the end user which can use `Public` and
      `Signature` for the cryptos as before
      1e9fd237
    • Juan Ignacio Rios's avatar
      Add HRMP notification handlers to the xcm-executor (#3696) · 8b3bf39a
      Juan Ignacio Rios authored
      
      
      Currently the xcm-executor returns an `Unimplemented` error if it
      receives any HRMP-related instruction.
      What I propose here, which is what we are currently doing in our forked
      executor at polimec, is to introduce a trait implemented by the executor
      which will handle those instructions.
      
      This way, if parachains want to keep the default behavior, they just use
      `()` and it will return unimplemented, but they can also implement their
      own logic to establish HRMP channels with other chains in an automated
      fashion, without requiring to go through governance.
      
      Our implementation is mentioned in the [polkadot HRMP
      docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to
      submit a PR to add these changes to polkadot-sdk.
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      8b3bf39a
  15. Mar 15, 2024
  16. Mar 13, 2024
    • georgepisaltu's avatar
      Revert "FRAME: Create `TransactionExtension` as a replacement for... · bbd51ce8
      georgepisaltu authored
      
      Revert "FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280)" (#3665)
      
      This PR reverts #2280 which introduced `TransactionExtension` to replace
      `SignedExtension`.
      
      As a result of the discussion
      [here](https://github.com/paritytech/polkadot-sdk/pull/3623#issuecomment-1986789700),
      the changes will be reverted for now with plans to reintroduce the
      concept in the future.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      bbd51ce8
  17. Mar 08, 2024
  18. Mar 07, 2024
  19. Mar 06, 2024
  20. Mar 05, 2024
  21. Mar 04, 2024
    • PG Herveou's avatar
      Contracts: Fix typo (#3563) · 0708cf38
      PG Herveou authored
      0708cf38
    • Gavin Wood's avatar
      FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280) · fd5f9292
      Gavin Wood authored
      
      
      Closes #2160
      
      First part of [Extrinsic
      Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)
      
      Introduces a new trait `TransactionExtension` to replace
      `SignedExtension`. Introduce the idea of transactions which obey the
      runtime's extensions and have according Extension data (né Extra data)
      yet do not have hard-coded signatures.
      
      Deprecate the terminology of "Unsigned" when used for
      transactions/extrinsics owing to there now being "proper" unsigned
      transactions which obey the extension framework and "old-style" unsigned
      which do not. Instead we have __*General*__ for the former and
      __*Bare*__ for the latter. (Ultimately, the latter will be phased out as
      a type of transaction, and Bare will only be used for Inherents.)
      
      Types of extrinsic are now therefore:
      - Bare (no hardcoded signature, no Extra data; used to be known as
      "Unsigned")
      - Bare transactions (deprecated): Gossiped, validated with
      `ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
      `TransactionExtension` (deprecated).
        - Inherents: Not gossiped, validated with `ProvideInherent`.
      - Extended (Extra data): Gossiped, validated via `TransactionExtension`.
        - Signed transactions (with a hardcoded signature).
        - General transactions (without a hardcoded signature).
      
      `TransactionExtension` differs from `SignedExtension` because:
      - A signature on the underlying transaction may validly not be present.
      - It may alter the origin during validation.
      - `pre_dispatch` is renamed to `prepare` and need not contain the checks
      present in `validate`.
      - `validate` and `prepare` is passed an `Origin` rather than a
      `AccountId`.
      - `validate` may pass arbitrary information into `prepare` via a new
      user-specifiable type `Val`.
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`. It is encoded *for the entire transaction* and
      passed in to each extension as a new argument to `validate`. This
      facilitates the ability of extensions to acts as underlying crypto.
      
      There is a new `DispatchTransaction` trait which contains only default
      function impls and is impl'ed for any `TransactionExtension` impler. It
      provides several utility functions which reduce some of the tedium from
      using `TransactionExtension` (indeed, none of its regular functions
      should now need to be called directly).
      
      Three transaction version discriminator ("versions") are now
      permissible:
      - 0b000000100: Bare (used to be called "Unsigned"): contains Signature
      or Extra (extension data). After bare transactions are no longer
      supported, this will strictly identify an Inherents only.
      - 0b100000100: Old-school "Signed" Transaction: contains Signature and
      Extra (extension data).
      - 0b010000100: New-school "General" Transaction: contains Extra
      (extension data), but no Signature.
      
      For the New-school General Transaction, it becomes trivial for authors
      to publish extensions to the mechanism for authorizing an Origin, e.g.
      through new kinds of key-signing schemes, ZK proofs, pallet state,
      mutations over pre-authenticated origins or any combination of the
      above.
      
      ## Code Migration
      
      ### NOW: Getting it to build
      
      Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
      accompanied by renaming your aggregate type in line with the new
      terminology. E.g. Before:
      
      ```rust
      /// The SignedExtension to the basic transaction logic.
      pub type SignedExtra = (
      	/* snip */
      	MySpecialSignedExtension,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
      ```
      
      After:
      
      ```rust
      /// The extension to the basic transaction logic.
      pub type TxExtension = (
      	/* snip */
      	AsTransactionExtension<MySpecialSignedExtension>,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
      ```
      
      You'll also need to alter any transaction building logic to add a
      `.into()` to make the conversion happen. E.g. Before:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let extra: SignedExtra = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */),
      	);
      	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		extra,
      	)
      }
      ```
      
      After:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let tx_ext: TxExtension = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */).into(),
      	);
      	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		tx_ext,
      	)
      }
      ```
      
      ### SOON: Migrating to `TransactionExtension`
      
      Most `SignedExtension`s can be trivially converted to become a
      `TransactionExtension`. There are a few things to know.
      
      - Instead of a single trait like `SignedExtension`, you should now
      implement two traits individually: `TransactionExtensionBase` and
      `TransactionExtension`.
      - Weights are now a thing and must be provided via the new function `fn
      weight`.
      
      #### `TransactionExtensionBase`
      
      This trait takes care of anything which is not dependent on types
      specific to your runtime, most notably `Call`.
      
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`.
      - Weight must be returned by implementing the `weight` function. If your
      extension is associated with a pallet, you'll probably want to do this
      via the pallet's existing benchmarking infrastructure.
      
      #### `TransactionExtension`
      
      Generally:
      - `pre_dispatch` is now `prepare` and you *should not reexecute the
      `validate` functionality in there*!
      - You don't get an account ID any more; you get an origin instead. If
      you need to presume an account ID, then you can use the trait function
      `AsSystemOriginSigner::as_system_origin_signer`.
      - You get an additional ticket, similar to `Pre`, called `Val`. This
      defines data which is passed from `validate` into `prepare`. This is
      important since you should not be duplicating logic from `validate` to
      `prepare`, you need a way of passing your working from the former into
      the latter. This is it.
      - This trait takes two type parameters: `Call` and `Context`. `Call` is
      the runtime call type which used to be an associated type; you can just
      move it to become a type parameter for your trait impl. `Context` is not
      currently used and you can safely implement over it as an unbounded
      type.
      - There's no `AccountId` associated type any more. Just remove it.
      
      Regarding `validate`:
      - You get three new parameters in `validate`; all can be ignored when
      migrating from `SignedExtension`.
      - `validate` returns a tuple on success; the second item in the tuple is
      the new ticket type `Self::Val` which gets passed in to `prepare`. If
      you use any information extracted during `validate` (off-chain and
      on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
      pass it through with this. For the tuple's last item, just return the
      `origin` argument.
      
      Regarding `prepare`:
      - This is renamed from `pre_dispatch`, but there is one change:
      - FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
      `validate`!!
      - (This is different to `SignedExtension` which was required to run the
      same checks in `pre_dispatch` as in `validate`.)
      
      Regarding `post_dispatch`:
      - Since there are no unsigned transactions handled by
      `TransactionExtension`, `Pre` is always defined, so the first parameter
      is `Self::Pre` rather than `Option<Self::Pre>`.
      
      If you make use of `SignedExtension::validate_unsigned` or
      `SignedExtension::pre_dispatch_unsigned`, then:
      - Just use the regular versions of these functions instead.
      - Have your logic execute in the case that the `origin` is `None`.
      - Ensure your transaction creation logic creates a General Transaction
      rather than a Bare Transaction; this means having to include all
      `TransactionExtension`s' data.
      - `ValidateUnsigned` can still be used (for now) if you need to be able
      to construct transactions which contain none of the extension data,
      however these will be phased out in stage 2 of the Transactions Horizon,
      so you should consider moving to an extension-centric design.
      
      ## TODO
      
      - [x] Introduce `CheckSignature` impl of `TransactionExtension` to
      ensure it's possible to have crypto be done wholly in a
      `TransactionExtension`.
      - [x] Deprecate `SignedExtension` and move all uses in codebase to
      `TransactionExtension`.
        - [x] `ChargeTransactionPayment`
        - [x] `DummyExtension`
        - [x] `ChargeAssetTxPayment` (asset-tx-payment)
        - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment)
        - [x] `CheckWeight`
        - [x] `CheckTxVersion`
        - [x] `CheckSpecVersion`
        - [x] `CheckNonce`
        - [x] `CheckNonZeroSender`
        - [x] `CheckMortality`
        - [x] `CheckGenesis`
        - [x] `CheckOnlySudoAccount`
        - [x] `WatchDummy`
        - [x] `PrevalidateAttests`
        - [x] `GenericSignedExtension`
        - [x] `SignedExtension` (chain-polkadot-bulletin)
        - [x] `RefundSignedExtensionAdapter`
      - [x] Implement `fn weight` across the board.
      - [ ] Go through all pre-existing extensions which assume an account
      signer and explicitly handle the possibility of another kind of origin.
      - [x] `CheckNonce` should probably succeed in the case of a non-account
      origin.
      - [x] `CheckNonZeroSender` should succeed in the case of a non-account
      origin.
      - [x] `ChargeTransactionPayment` and family should fail in the case of a
      non-account origin.
        - [ ] 
      - [x] Fix any broken tests.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarChevdor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMaciej <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      Co-authored-by: default avatarJavier Bullrich <[email protected]>
      Co-authored-by: default avatarKoute <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: Vladimir Istyufeev's avatarVladimir Istyufeev <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarSvyatoslav Nikolsky <[email protected]>
      Co-authored-by: default avatarAndré Silva <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarAaro Altonen <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarAlexander Samusev <[email protected]>
      Co-authored-by: default avatarJulian Eager <[email protected]>
      Co-authored-by: default avatarMichal Kucharczyk <[email protected]>
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avataryjh <[email protected]>
      Co-authored-by: default avatarTom Mi <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarWill | Paradox | ParaNodes.io <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarPG Herveou <[email protected]>
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan Girini <[email protected]>
      Co-authored-by: default avatarbader y <[email protected]>
      Co-authored-by: default avatarJames Wilson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarasynchronous rob <[email protected]>
      Co-authored-by: default avatarParth <[email protected]>
      Co-authored-by: default avatarAndrew Jones <[email protected]>
      Co-authored-by: default avatarJonathan Udd <[email protected]>
      Co-authored-by: default avatarSerban Iorga <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarEvgeny Snitko <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      Co-authored-by: default avatardzmitry-lahoda <[email protected]>
      Co-authored-by: default avatarzhiqiangxu <[email protected]>
      Co-authored-by: default avatarNazar Mokrynskyi <[email protected]>
      Co-authored-by: default avatarAnwesh <[email protected]>
      Co-authored-by: default avatarcheme <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarJegor Sidorenko <[email protected]>
      Co-authored-by: default avatarMuharem <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      Co-authored-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarGabriel Facco de Arruda <[email protected]>
      Co-authored-by: default avatarSquirrel <[email protected]>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: command-bot <>
      fd5f9292
  22. Feb 29, 2024
  23. Feb 28, 2024
    • Liam Aharon's avatar
      Runtime Upgrade ref docs and Single Block Migration example pallet (#1554) · 12ce4f7d
      Liam Aharon authored
      Closes https://github.com/paritytech/polkadot-sdk-docs/issues/55
      
      - Changes 'current storage version' terminology to less ambiguous
      'in-code storage version' (suggestion by @ggwpez
      
      )
      - Adds a new example pallet `pallet-example-single-block-migrations`
      - Adds a new reference doc to replace
      https://docs.substrate.io/maintain/runtime-upgrades/ (temporarily living
      in the pallet while we wait for developer hub PR to merge)
      - Adds documentation for the `storage_alias` macro
      - Improves `trait Hooks` docs 
      - Improves `trait GetStorageVersion` docs
      - Update the suggested patterns for using `VersionedMigration`, so that
      version unchecked migrations are never exported
      - Prevents accidental usage of version unchecked migrations in runtimes
      
      https://github.com/paritytech/substrate/pull/14421#discussion_r1255467895
      - Unversioned migration code is kept inside `mod version_unchecked`,
      versioned code is kept in `pub mod versioned`
      - It is necessary to use modules to limit visibility because the inner
      migration must be `pub`. See
      https://github.com/rust-lang/rust/issues/30905 and
      
      https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504/40
      for more.
      
      ### todo
      
      - [x] move to reference docs to proper place within sdk-docs (now that
      https://github.com/paritytech/polkadot-sdk/pull/2102 is merged)
      - [x] prdoc
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatargupnik <[email protected]>
      12ce4f7d
  24. Feb 23, 2024
  25. Feb 21, 2024
    • Alexander Theißen's avatar
      contracts: Fix double charge of gas for host functions (#3361) · f3a6b6dc
      Alexander Theißen authored
      
      
      This PR is fixing a bug in the sync mechanism between wasmi and
      pallet-contracts. This bug leads to essentially double charging all the
      gas that was used during the execution of the host function. When the
      `call` host function is used for recursion this will lead to a quadratic
      amount of gas consumption with regard to the nesting depth.We also took
      the chance to refactor the code in question and improve the rust docs.
      
      The bug was caused by not updating `GasMeter::executor_consumed`
      (previously `engine_consumed`) when leaving the host function. This lead
      to the value being stale (too low) when entering another host function.
      
      ---------
      
      Co-authored-by: default avatarPG Herveou <[email protected]>
      f3a6b6dc
  26. Feb 20, 2024
    • PG Herveou's avatar
      Contracts: Stabilize APIs (#3384) · d250a6e4
      PG Herveou authored
      Remove `#[unstable]` on `call_v2`, `instantiate_v2`,
      `lock_delegate_dependency` and `unlock_delegate_dependency`.
      See ink! integrations: 
      - call_v2: https://github.com/paritytech/ink/pull/2077
      - instantiate_v2: <TODO>
      - lock/unlock dependency: https://github.com/paritytech/ink/pull/2076
      d250a6e4