Skip to content
  1. Feb 03, 2024
  3. Jan 31, 2024
    • Pablo Andrés Dorado Suárez's avatar
      [Documentation] Add description for VoteTally's methods (#3140) · 8a8f6f98
      Pablo Andrés Dorado Suárez authored 
      # Description

While methods' names on [`VoteTally`][1] trait might be self-explanatory
at first sight, the distinction between `support` and `approval` can be
a bit ambiguous for some readers. This PR aims to clarify the
distinction and inform about the expected values for every not yet
documented method on this trait.

# Checklist

- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
- [x] I have made corresponding changes to the documentation (if
applicable)
- [x] I have added tests that prove my fix is effective or that my
feature works (if applicable)

[1]:
https://docs.rs/frame-support/latest/frame_support/traits/trait.VoteTally.html



---------

Co-authored-by: default avatarBastian Köcher <[email protected]>
      8a8f6f98
    • Oliver Tale-Yazdi's avatar
      [FRAME] Make `core-fellowship` ans `salary` work for swapped members (#3156) · 07e55006
      Oliver Tale-Yazdi authored 
      Fixup for https://github.com/paritytech/polkadot-sdk/pull/2587 to make
the `core-fellowship` crate work with swapped members.

Adds a `MemberSwappedHandler` to the `ranked-collective` pallet that are
implemented by `core-fellowship+salary`.
There is are exhaustive tests
[here](https://github.com/paritytech/polkadot-sdk/blob/72aa7ac17a0e5b16faab5d2992aa2db2e01b05d0/substrate/frame/core-fellowship/src/tests/integration.rs#L338)
and
[here](https://github.com/paritytech/polkadot-sdk/blob/ab3cdb05a5ebc1ff841f8dda67edef0ea40bbba5/substrate/frame/salary/src/tests/integration.rs#L224

)
to check that adding member `1` is equivalent to adding member `0` and
then swapping.

---------

Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      07e55006
    • Branislav Kontur's avatar
      Addressing Liam's comments from https://github.com/paritytech/polkadot-sdk/pull/2657 (#3150) · a03ef279
      Branislav Kontur authored
      a03ef279
    • 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
  5. Jan 30, 2024
  7. Jan 29, 2024
  9. Jan 28, 2024
  11. Jan 27, 2024
  13. 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
      Sync Cargo.toml and crates.io versions (#3034) · 3717ec38
      Liam Aharon authored 
      Related https://github.com/paritytech/polkadot-sdk/issues/3032

---

Using https://github.com/liamaharon/cargo-workspace-version-tools/

 

`cargo run -- sync --path ../polkadot-sdk`

---------

Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      3717ec38
    • Oliver Tale-Yazdi's avatar
      Fix Pools 6->7 migration (#2942) · dd45c949
      Oliver Tale-Yazdi authored 
      

Fix the Pools `v7` migration.

---------

Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarBranislav Kontur <[email protected]>
      dd45c949
  15. Jan 24, 2024
  17. Jan 23, 2024
    • Niklas Adolfsson's avatar
      rpc: backpressured RPC server (bump jsonrpsee 0.20) (#1313) · e16ef086
      Niklas Adolfsson authored 
      This is a rather big change in jsonrpsee, the major things in this bump
are:
- Server backpressure (the subscription impls are modified to deal with
that)
- Allow custom error types / return types (remove jsonrpsee::core::Error
and jsonrpee::core::CallError)
- Bug fixes (graceful shutdown in particular not used by substrate
anyway)
   - Less dependencies for the clients in particular
   - Return type requires Clone in method call responses
   - Moved to tokio channels
   - Async subscription API (not used in this PR)

Major changes in this PR:
- The subscriptions are now bounded and if subscription can't keep up
with the server it is dropped
- CLI: add parameter to configure the jsonrpc server bounded message
buffer (default is 64)
- Add our own subscription helper to deal with the unbounded streams in
substrate

The most important things in this PR to review is the added helpers
functions in `substrate/client/rpc/src/utils.rs` and the rest is pretty
much chore.

Regarding the "bounded buffer limit" it may cause the server to handle
the JSON-RPC calls
slower than before.

The message size limit is bounded by "--rpc-response-size" thus "by
default 10MB * 64 = 640MB"
but the subscription message size is not covered by this limit and could
be capped as well.

Hopefully the last release prior to 1.0, sorry in advance for a big PR

Previous attempt: https://github.com/paritytech/substrate/pull/13992

Resolves https://github.com/paritytech/polkadot-sdk/issues/748, resolves
https://github.com/paritytech/polkadot-sdk/issues/627
      e16ef086
  19. Jan 22, 2024
  21. Jan 20, 2024
  23. Jan 19, 2024
  25. Jan 18, 2024
  27. Jan 17, 2024
  29. 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
    • Xavier Lau's avatar
      CI check features (#1708) · 05cfb02b
      Xavier Lau authored 
      To resolve issue #1136.

This is a cross verification against zepter.

- [cargo-featalign](https://github.com/hack-ink/cargo-featalign):
Verifies the proper propagation of all features.
- [zepter](https://github.com/ggwpez/zepter): Checks for accidentally
enabled features.

cc @ggwpez

 

---
Switch to a new branch. Original PR #1537.

---------

Signed-off-by: default avatarXavier Lau <[email protected]>
Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarChevdor <[email protected]>
      05cfb02b