Skip to content
  1. Nov 27, 2023
  3. Nov 25, 2023
  5. Nov 24, 2023
  7. Nov 23, 2023
  9. Nov 22, 2023
    • James Wilson's avatar
      Make TypeInfo for SkipCheckIfFeeless transparent, too (#2449) · 0d6dcb3f
      James Wilson authored 
      

The `SkipCheckifFeeless::IDENTIFIER` became transparent (ie was whatever
the inner signed ext was). This PR just makes the `TypeInfo` transparent
too, so that libraries that use said info to decode the data (ie subxt)
can behave identically whether or not the `SkipCheckifFeeless` wrapper
is used or not.

---------

Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      0d6dcb3f
    • gupnik's avatar
      Fixes import path in benchmark macro (#2437) · 98f9e2ea
      gupnik authored 
      Fully-qualified path was not being used in benchmark macro for one of
the cases. This PR fixes this and removes the unnecessary import in a
couple of files, which I believe was done to fix this issue.
      98f9e2ea
    • Ross Bulat's avatar
      Deprecate `RewardDestination::Controller` (#2380) · 7a32f4be
      Ross Bulat authored 
      

Deprecates `RewardDestination::Controller` variant.

- [x] `RewardDestination::Controller` annotated with `#[deprecated]`.
- [x] `Controller` variant is now handled the same way as `Stash` in
`payout_stakers`.
- [x] `set_payee` errors if `RewardDestination::Controller` is provided.
- [x] Added `update_payee` call to lazily migrate
`RewardDestination::Controller` `Payee` storage entries to
`RewardDestination::Account(controller)` .
- [x] `payout_stakers_dead_controller` has been removed from benches &
weights - was not used.
- [x] Tests no longer use `RewardDestination::Controller`.

---------

Co-authored-by: command-bot <>
Co-authored-by: default avatarGonçalo Pestana <[email protected]>
Co-authored-by: default avatargeorgepisaltu <[email protected]>
      7a32f4be
  11. Nov 21, 2023
  13. Nov 20, 2023
  15. Nov 17, 2023
  17. Nov 15, 2023
    • Bastian Köcher's avatar
      frame-system: Add `last_runtime_upgrade_spec_version` (#2351) · ea4085ab
      Bastian Köcher authored 
      

Adds a function for querying the last runtime upgrade spec version. This
can be useful for when writing runtime level migrations to ensure that
they are not executed multiple times. An example would be a session key
migration.

---------

Co-authored-by: default avatarLiam Aharon <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      ea4085ab
    • joe petrowski's avatar
      Identity Deposits Relay to Parachain Migration (#1814) · c79b234b
      joe petrowski authored 
      The goal of this PR is to migrate Identity deposits from the Relay Chain
to a system parachain.

The problem I want to solve is that `IdentityOf` and `SubsOf` both store
an amount that's held in reserve as a storage deposit. When migrating to
a parachain, we can take a snapshot of the actual `IdentityInfo` and
sub-account mappings, but should migrate (off chain) the `deposit`s to
zero, since the chain (and by extension, accounts) won't have any funds
at genesis.

The good news is that we expect parachain deposits to be significantly
lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
migrate the deposits in the following way:

1. Introduces a new pallet with two extrinsics: 
- `reap_identity`: Has a configurable `ReapOrigin`, which would be set
to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
`EnsureRoot` on the parachain (we don't want identities reaped from
there).
- `poke_deposit`: Checks what deposit the pallet holds (at genesis,
zero) and attempts to update the amount based on the calculated deposit
for storage data.
2. `reap_identity` clears all storage data for a `target` account and
unreserves their deposit.
3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
and calls `poke_deposit`. Since the parachain deposit is much lower, and
was just unreserved, we know we have enough.

One awkwardness I ran into was that the XCMv3 instruction set does not
provide a way for the system to teleport assets without a fee being
deducted on reception. Users shouldn't have to pay a fee for the system
to migrate their info to a more efficient location. So I wrote my own
program and did the `InitiateTeleport` accounting on my own to send a
program with `UnpaidExecution`. Have discussed an
`InitiateUnpaidTeleport` instruction with @franciscoaguirre . Obviously
any chain executing this would have to pass a `Barrier` for free
execution.

TODO:

- [x] Confirm People Chain ParaId
- [x] Confirm People Chain deposit rates (determined in
https://github.com/paritytech/polkadot-sdk/pull/2281

)
- [x] Add pallet to Westend

---------

Co-authored-by: default avatarBastian Köcher <[email protected]>
      c79b234b
  19. Nov 14, 2023
  21. Nov 13, 2023
    • gupnik's avatar
      Adds syntax for marking calls feeless (#1926) · 60c77a2e
      gupnik authored 
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1725



This PR adds the following changes:
1. An attribute `pallet::feeless_if` that can be optionally attached to
a call like so:
```rust
#[pallet::feeless_if(|_origin: &OriginFor<T>, something: &u32| -> bool {
	*something == 0
})]
pub fn do_something(origin: OriginFor<T>, something: u32) -> DispatchResult {
     ....
}
```
The closure passed accepts references to arguments as specified in the
call fn. It returns a boolean that denotes the conditions required for
this call to be "feeless".

2. A signed extension `SkipCheckIfFeeless<T: SignedExtension>` that
wraps a transaction payment processor such as
`pallet_transaction_payment::ChargeTransactionPayment`. It checks for
all calls annotated with `pallet::feeless_if` to see if the conditions
are met. If so, the wrapped signed extension is not called, essentially
making the call feeless.

In order to use this, you can simply replace your existing signed
extension that manages transaction payment like so:
```diff
- pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
+ pallet_skip_feeless_payment::SkipCheckIfFeeless<
+	Runtime,
+	pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
+ >,
```

### Todo
- [x] Tests
- [x] Docs
- [x] Prdoc

---------

Co-authored-by: Nikhil Gupta <>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
Co-authored-by: default avatarLiam Aharon <[email protected]>
      60c77a2e
    • Bastian Köcher's avatar
      pallet-grandpa: Remove `GRANDPA_AUTHORITIES_KEY` (#2181) · ebcf0a0f
      Bastian Köcher authored 
      

Remove the `GRANDPA_AUTHORITIES_KEY` key and its usage. Apparently this
was used in the early days to communicate the grandpa authorities to the
node. However, we have now a runtime api that does this for us. So, this
pull request is moving from the custom managed storage item to a FRAME
managed storage item.

This pr also includes a migration for doing the switch on a running
chain.

---------

Co-authored-by: default avatarDavide Galassi <[email protected]>
      ebcf0a0f
  23. Nov 10, 2023
  25. Nov 09, 2023
  27. Nov 08, 2023
  29. Nov 07, 2023
    • Bill Laboon's avatar
      Fix "slashaed" typo (#2205) · 44c7a5eb
      Bill Laboon authored 
      # Description

This merely fixes a typo in the documentation, replacing the typo
"slashaed" with "slashed". Since external entities use the comments for
explanations of events, this will then be shown externally. I noticed
this when reviewing [this
event](https://polkadot.subscan.io/extrinsic/0xb6bc1e3abde0c2ed9c500c74cfc64cdb8179e5d9af97f4bf53242ce4cdd15a1d?event=18064194-6)
on Subscan.

This is not related to any other issues or PRs.
      44c7a5eb
    • vuittont60's avatar
      docs: fix typos (#2193) · 4caa3d8d
      vuittont60 authored
      4caa3d8d
    • Liam Aharon's avatar
      Initialise on-chain `StorageVersion` for pallets added after genesis (#1297) · c4211b65
      Liam Aharon authored 
      Original PR https://github.com/paritytech/substrate/pull/14641

---

Closes https://github.com/paritytech/polkadot-sdk/issues/109



### Problem
Quoting from the above issue:

> When adding a pallet to chain after genesis we currently don't set the
StorageVersion. So, when calling on_chain_storage_version it returns 0
while the pallet is maybe already at storage version 9 when it was added
to the chain. This could lead to issues when running migrations.

### Solution

- Create a new trait `BeforeAllRuntimeMigrations` with a single method
`fn before_all_runtime_migrations() -> Weight` trait with a noop default
implementation
- Modify `Executive` to call
`BeforeAllRuntimeMigrations::before_all_runtime_migrations` for all
pallets before running any other hooks
- Implement `BeforeAllRuntimeMigrations` in the pallet proc macro to
initialize the on-chain version to the current pallet version if the
pallet has no storage set (indicating it has been recently added to the
runtime and needs to have its version initialised).

### Other changes in this PR

- Abstracted repeated boilerplate to access the `pallet_name` in the
pallet expand proc macro.

### FAQ

#### Why create a new hook instead of adding this logic to the pallet
`pre_upgrade`?

`Executive` currently runs `COnRuntimeUpgrade` (custom migrations)
before `AllPalletsWithSystem` migrations. We need versions to be
initialized before the `COnRuntimeUpgrade` migrations are run, because
`COnRuntimeUpgrade` migrations may use the on-chain version for critical
logic. e.g. `VersionedRuntimeUpgrade` uses it to decide whether or not
to execute.

We cannot reorder `COnRuntimeUpgrade` and `AllPalletsWithSystem` so
`AllPalletsWithSystem` runs first, because `AllPalletsWithSystem` have
some logic in their `post_upgrade` hooks to verify that the on-chain
version and current pallet version match. A common use case of
`COnRuntimeUpgrade` migrations is to perform a migration which will
result in the versions matching, so if they were reordered these
`post_upgrade` checks would fail.

#### Why init the on-chain version for pallets without a current storage
version?

We must init the on-chain version for pallets even if they don't have a
defined storage version so if there is a future version bump, the
on-chain version is not automatically set to that new version without a
proper migration.

e.g. bad scenario:

1. A pallet with no 'current version' is added to the runtime
2. Later, the pallet is upgraded with the 'current version' getting set
to 1 and a migration is added to Executive Migrations to migrate the
storage from 0 to 1
    a. Runtime upgrade occurs
    b. `before_all` hook initializes the on-chain version to 1
c. `on_runtime_upgrade` of the migration executes, and sees the on-chain
version is already 1 therefore think storage is already migrated and
does not execute the storage migration
Now, on-chain version is 1 but storage is still at version 0.

By always initializing the on-chain version when the pallet is added to
the runtime we avoid that scenario.

---------

Co-authored-by: default avatarKian Paimani <[email protected]>
Co-authored-by: default avatarBastian Köcher <[email protected]>
      c4211b65
  31. Nov 06, 2023
  33. Nov 05, 2023
  35. Nov 04, 2023
  37. Nov 03, 2023
    • georgepisaltu's avatar
      Identity pallet improvements (#2048) · 21fbc00d
      georgepisaltu authored 
      This PR is a follow up to #1661 

- [x] rename the `simple` module to `legacy`
- [x] fix benchmarks to disregard the number of additional fields
- [x] change the storage deposits to charge per encoded byte of the
identity information instance, removing the need for `fn
additional(&self) -> usize` in `IdentityInformationProvider`
- [x] ~add an extrinsic to rejig deposits to account for the change
above~
- [ ] ~ensure through proper configuration that the new byte-based
deposit is always lower than whatever is reserved now~
- [x] remove `IdentityFields` from the `set_fields` extrinsic signature,
as per [this
discussion](https://github.com/paritytech/polkadot-sdk/pull/1661#discussion_r1371703403)

> ensure through proper configuration that the new byte-based deposit is
always lower than whatever is reserved now

Not sure this is needed anymore. If the new deposits are higher than
what is currently on chain and users don't have enough funds to reserve
what is needed, the extrinisc fails and they're basically grandfathered
and frozen until they add more funds and/or make a change to their
identity. This behavior seems fine to me. Original idea
[here](https://github.com/paritytech/polkadot-sdk/pull/1661#issuecomment-1779606319).

> add an extrinsic to rejig deposits to account for the change above

This was initially implemented but now removed from this PR in favor of
the implementation detailed
[here](https://github.com/paritytech/polkadot-sdk/pull/2088

).

---------

Signed-off-by: default avatargeorgepisaltu <[email protected]>
Co-authored-by: default avatarjoepetrowski <[email protected]>
      21fbc00d
  39. Nov 02, 2023