1. Mar 06, 2024
  2. Feb 23, 2024
  3. Feb 19, 2024
    • PG Herveou's avatar
      Contracts: xcm host fn fixes (#3086) · ca382f32
      PG Herveou authored
      ## Xcm changes:
      - Fix `pallet_xcm::execute`, move the logic into The `ExecuteController`
      so it can be shared with anything that implement that trait.
      - Make `ExecuteController::execute` retursn `DispatchErrorWithPostInfo`
      instead of `DispatchError`, so that we don't charge the full
      `max_weight` provided if the execution is incomplete (useful for
      force_batch or contracts calls)
      - Fix docstring for `pallet_xcm::execute`, to reflect the changes from
      #2405
      - Update the signature for `ExecuteController::execute`, we don't need
      to return the `Outcome` anymore since we only care about
      `Outcome::Complete`
      
      ## Contracts changes:
      
      - Update host fn `xcm_exexute`, we don't need to write the `Outcome` to
      the sandbox memory anymore. This was also not charged as well before so
      it if fixes this too.
      - One of the issue was that the dry_run of a contract that call
      `xcm_execute` would exhaust the `gas_limit`.
      
      This is because `XcmExecuteController::execute` takes a `max_weight`
      argument, and since we don't want the user to specify it manually we
      were passing everything left by pre-charghing
      `ctx.ext.gas_meter().gas_left()`
      
      - To fix it I added a `fn influence_lowest_limit` on the `Token` trait
      and make it return false for `RuntimeCost::XcmExecute`.
      - Got rid of the `RuntimeToken` indirection, we can just use
      `RuntimeCost` directly.
      
      ---------
      
      Co-authored-by: command-bot <>
      ca382f32
  4. Feb 13, 2024
  5. Jan 31, 2024
    • Branislav Kontur's avatar
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed... · bb8ddc46
      Branislav Kontur authored
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657)
      
      I started this investigation/issue based on @liamaharon question
      [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).
      
      ## Problem
      
      The `pallet_balances` integrity test should correctly detect that the
      runtime has correct distinct `HoldReasons` variant count. I assume the
      same situation exists for RuntimeFreezeReason.
      
      It is not a critical problem, if we set `MaxHolds` with a sufficiently
      large value, everything should be ok. However, in this case, the
      integrity_test check becomes less useful.
      
      **Situation for "any" runtime:**
      - `HoldReason` enums from different pallets:
      ```rust
              /// from pallet_nis
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		NftReceipt,
      	}
      
              /// from pallet_preimage
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		Preimage,
      	}
      
              // from pallet_state-trie-migration
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		SlashForContinueMigrate,
      		SlashForMigrateCustomTop,
      		SlashForMigrateCustomChild,
      	}
      ```
      
      - generated `RuntimeHoldReason` enum looks like:
      ```rust
      pub enum RuntimeHoldReason {
      
          #[codec(index = 32u8)]
          Preimage(pallet_preimage::HoldReason),
      
          #[codec(index = 38u8)]
          Nis(pallet_nis::HoldReason),
      
          #[codec(index = 42u8)]
          StateTrieMigration(pallet_state_trie_migration::HoldReason),
      }
      ```
      
      - composite enum `RuntimeHoldReason` variant count is detected as `3`
      - we set `type MaxHolds = ConstU32<3>`
      - `pallet_balances::integrity_test` is ok with `3`(at least 3)
      
      However, the real problem can occur in a live runtime where some
      functionality might stop working. This is due to a total of 5 distinct
      hold reasons (for pallets with multi-instance support, it is even more),
      and not all of them can be used because of an incorrect `MaxHolds`,
      which is deemed acceptable according to the `integrity_test`:
        ```
        // pseudo-code - if we try to call all of these:
      
      T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
      &nft_owner, deposit)?;
      T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
      &nft_owner, deposit)?;
      
        // With `type MaxHolds = ConstU32<3>` these two will fail
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
      &nft_owner, deposit)?;
        ```  
      
      
      ## Solutions
      
      A macro `#[pallet::*]` expansion is extended of `VariantCount`
      implementation for the `#[pallet::composite_enum]` enum type. This
      expansion generates the `VariantCount` implementation for pallets'
      `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
      must be plain enum values without fields to ensure a deterministic
      count.
      
      The composite runtime enum, `RuntimeHoldReason` and
      `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
      of pallets' enum `VariantCount::VARIANT_COUNT`:
      ```rust
      #[frame_support::pallet(dev_mode)]
      mod module_single_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason {
      		ModuleSingleInstanceReason1,
      		ModuleSingleInstanceReason2,
      	}
      ...
      }
      
      #[frame_support::pallet(dev_mode)]
      mod module_multi_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason<I: 'static = ()> {
      		ModuleMultiInstanceReason1,
      		ModuleMultiInstanceReason2,
      		ModuleMultiInstanceReason3,
      	}
      ...
      }
      
      
      impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
          for RuntimeHoldReason
      {
          const VARIANT_COUNT: u32 = 0
              + module_single_instance::HoldReason::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
      }
      ```
      
      In addition, `MaxHolds` is removed (as suggested
      [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
      from `pallet_balances`, and its `Holds` are now bounded to
      `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
      the runtime specify `MaxHolds`.
      
      
      ## For reviewers
      
      Relevant changes can be found here:
      - `substrate/frame/support/procedural/src/lib.rs` 
      -  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
      -  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
      - `substrate/frame/support/src/traits/misc.rs`
      
      And the rest of the files is just about removed `MaxHolds` from
      `pallet_balances`
      
      ## Next steps
      
      Do the same for `MaxFreezes`
      https://github.com/paritytech/polkadot-sdk/issues/2997
      
      .
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      bb8ddc46
  6. Jan 26, 2024
    • Alexander Theißen's avatar
      contracts: Fix printing the `Schedule` (#3021) · 5e5341da
      Alexander Theißen authored
      Printing the `Schedule` is a useful debugging tool and general sanity
      check. It is much more easy to interpret than the raw weights.
      
      The printing relied on using `println` and hence was only available from
      the native runtime. This is no longer available. This is why in this PR
      we switch to using `log` which works from Wasm.
      
      I made sure that the `WeightDebug` is only derived when
      `runtime-benchmarks` is set so that we don't increase the size of the
      binary.
      
      Some other changes were necessary to make this actually work inside the
      runtime. For example, I needed to remove `format!` and usage of floats.
      
      Please note that this removed the decimal from the number because
      truncating the fraction without using floats would not be easy and would
      require custom code. I think the precision here is sufficient.
      
      This is how the output looks like now:
      ```
      Schedule {
          limits: Limits {
              event_topics: 4,
              globals: 256,
              locals: 1024,
              parameters: 128,
              memory_pages: 16,
              table_size: 4096,
              br_table_size: 256,
              subject_len: 32,
              payload_len: 16384,
              runtime_memory: 134217728,
          },
          instruction_weights: InstructionWeights {
              base: 2565,
              _phantom: PhantomData<kitchensink_runtime::Runtime>,
          },
          host_fn_weights: HostFnWeights {
              caller: 322 ns, 6 bytes,
              is_contract: 28 µs, 2684 bytes,
              code_hash: 29 µs, 2688 bytes,
              own_code_hash: 400 ns, 6 bytes,
              caller_is_origin: 176 ns, 3 bytes,
              caller_is_root: 158 ns, 3 bytes,
              address: 315 ns, 6 bytes,
              gas_left: 355 ns, 6 bytes,
              balance: 1 µs, 6 bytes,
              value_transferred: 314 ns, 6 bytes,
              minimum_balance: 318 ns, 6 bytes,
              block_number: 313 ns, 6 bytes,
              now: 325 ns, 6 bytes,
              weight_to_fee: 1 µs, 14 bytes,
              input: 263 ns, 6 bytes,
              input_per_byte: 989 ps, 0 bytes,
              r#return: 0 ps, 45 bytes,
              return_per_byte: 320 ps, 0 bytes,
              terminate: 1 ms, 5266 bytes,
              random: 1 µs, 10 bytes,
              deposit_event: 1 µs, 10 bytes,
              deposit_event_per_topic: 127 µs, 2508 bytes,
              deposit_event_per_byte: 501 ps, 0 bytes,
              debug_message: 226 ns, 7 bytes,
              debug_message_per_byte: 1 ns, 0 bytes,
              set_storage: 131 µs, 293 bytes,
              set_storage_per_new_byte: 576 ps, 0 bytes,
              set_storage_per_old_byte: 184 ps, 1 bytes,
              set_code_hash: 297 µs, 3090 bytes,
              clear_storage: 131 µs, 289 bytes,
              clear_storage_per_byte: 92 ps, 1 bytes,
              contains_storage: 29 µs, 289 bytes,
              contains_storage_per_byte: 213 ps, 1 bytes,
              get_storage: 29 µs, 297 bytes,
              get_storage_per_byte: 980 ps, 1 bytes,
              take_storage: 131 µs, 297 bytes,
              take_storage_per_byte: 921 ps, 1 bytes,
              transfer: 156 µs, 2520 bytes,
              call: 484 µs, 2721 bytes,
              delegate_call: 406 µs, 2637 bytes,
              call_transfer_surcharge: 607 µs, 5227 bytes,
              call_per_cloned_byte: 970 ps, 0 bytes,
              instantiate: 1 ms, 2731 bytes,
              instantiate_transfer_surcharge: 131 µs, 2549 bytes,
              instantiate_per_input_byte: 1 ns, 0 bytes,
              instantiate_per_salt_byte: 1 ns, 0 bytes,
              hash_sha2_256: 377 ns, 8 bytes,
              hash_sha2_256_per_byte: 1 ns, 0 bytes,
              hash_keccak_256: 767 ns, 8 bytes,
              hash_keccak_256_per_byte: 3 ns, 0 bytes,
              hash_blake2_256: 443 ns, 8 bytes,
              hash_blake2_256_per_byte: 1 ns, 0 bytes,
              hash_blake2_128: 440 ns, 8 bytes,
              hash_blake2_128_per_byte: 1 ns, 0 bytes,
              ecdsa_recover: 45 µs, 77 bytes,
              ecdsa_to_eth_address: 11 µs, 42 bytes,
              sr25519_verify: 41 µs, 112 bytes,
              sr25519_verify_per_byte: 5 ns, 1 bytes,
              reentrance_count: 174 ns, 3 bytes,
              account_reentrance_count: 248 ns, 40 bytes,
              instantiation_nonce: 154 ns, 3 bytes,
              add_delegate_dependency: 131 µs, 2606 bytes,
              remove_delegate_dependency: 130 µs, 2568 bytes,
          },
      }
      ###############################################
      Lazy deletion weight per key: Weight(ref_time: 126109302, proof_size: 70)
      Lazy deletion keys per block: 15859
      ```
      5e5341da
    • Liam Aharon's avatar
  7. Jan 24, 2024
  8. Jan 22, 2024
  9. Jan 18, 2024
  10. Jan 16, 2024
    • Francisco Aguirre's avatar
      XCMv4 (#1230) · 8428f678
      Francisco Aguirre authored
      
      
      # Note for reviewer
      
      Most changes are just syntax changes necessary for the new version.
      Most important files should be the ones under the `xcm` folder.
      
      # Description 
      
      Added XCMv4.
      
      ## Removed `Multi` prefix
      The following types have been renamed:
      - MultiLocation -> Location
      - MultiAsset -> Asset
      - MultiAssets -> Assets
      - InteriorMultiLocation -> InteriorLocation
      - MultiAssetFilter -> AssetFilter
      - VersionedMultiAsset -> VersionedAsset
      - WildMultiAsset -> WildAsset
      - VersionedMultiLocation -> VersionedLocation
      
      In order to fix a name conflict, the `Assets` in `xcm-executor` were
      renamed to `HoldingAssets`, as they represent assets in holding.
      
      ## Removed `Abstract` asset id
      
      It was not being used anywhere and this simplifies the code.
      
      Now assets are just constructed as follows:
      
      ```rust
      let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into();
      ```
      
      No need for specifying `Concrete` anymore.
      
      ## Outcome is now a named fields struct
      
      Instead of
      
      ```rust
      pub enum Outcome {
        Complete(Weight),
        Incomplete(Weight, Error),
        Error(Error),
      }
      ```
      
      we now have
      
      ```rust
      pub enum Outcome {
        Complete { used: Weight },
        Incomplete { used: Weight, error: Error },
        Error { error: Error },
      }
      ```
      
      ## Added Reanchorable trait
      
      Now both locations and assets implement this trait, making it easier to
      reanchor both.
      
      ## New syntax for building locations and junctions
      
      Now junctions are built using the following methods:
      
      ```rust
      let location = Location {
          parents: 1,
          interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into()
      };
      ```
      
      or
      
      ```rust
      let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]);
      ```
      
      And they are matched like so:
      
      ```rust
      match location.unpack() {
        (1, [Parachain(id)]) => ...
        (0, Here) => ...,
        (1, [_]) => ...,
      }
      ```
      
      This syntax is mandatory in v4, and has been also implemented for v2 and
      v3 for easier migration.
      
      This was needed to make all sizes smaller.
      
      # TODO
      - [x] Scaffold v4
      - [x] Port github.com/paritytech/polkadot/pull/7236
      - [x] Remove `Multi` prefix
      - [x] Remove `Abstract` asset id
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      8428f678
  11. Dec 14, 2023
    • Francisco Aguirre's avatar
      Add FungibleAdapter (#2684) · 10a91f82
      Francisco Aguirre authored
      In the move from the old `Currency` traits to the new `fungible/s`
      family of traits, we already had the `FungiblesAdapter` and
      `NonFungiblesAdapter` for multiple fungible and non fungible assets
      respectively. However, for handling only one fungible asset, we were
      missing a `FungibleAdapter`, and so used the old `CurrencyAdapter`
      instead. This PR aims to fill in that gap, and provide the new adapter
      for more updated examples.
      
      I marked the old `CurrencyAdapter` as deprecated as part of this PR, and
      I'll change it to the new `FungibleAdapter` in a following PR.
      The two stages are separated so as to not bloat this PR with some name
      fixes in tests.
      
      ---------
      
      Co-authored-by: command-bot <>
      10a91f82
  12. Dec 13, 2023
  13. Dec 01, 2023
  14. Nov 29, 2023
    • PG Herveou's avatar
      Contracts: use compiled rust tests (#2347) · 2135fa87
      PG Herveou authored
      see #2189
      
      This PR does the following:
      - Bring the user api functions into a new pallet-contracts-uapi (They
      are currently defined in ink!
      [here])(https://github.com/paritytech/ink/blob/master/crates/env/src/engine/on_chain/ext.rs
      
      )
      - Add older api versions and unstable to the user api trait.
      - Remove pallet-contracts-primitives and bring the types it defined in
      uapi / pallet-contracts
      - Add the infrastructure to build fixtures from Rust files and test it
      works by replacing `dummy.wat` and `call.wat`
      - Move all the doc from wasm/runtime.rs to pallet-contracts-uapi.
      
      This will be done in a follow up:
      - convert the rest of the test from .wat to rust
      - bring risc-v uapi up to date with wasm
      - finalize the uapi host fns, making sure everything is codegen from the
      source host fns in pallet-contracts
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      2135fa87
  15. Nov 28, 2023
  16. Nov 14, 2023