Files
pezkuwi-subxt/substrate/frame/bounties
Branislav Kontur bb8ddc46c1 [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: Bastian Köcher <git@kchr.de>
Co-authored-by: Dónal Murray <donal.murray@parity.io>
Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com>
2024-01-31 06:19:16 +00:00
..
2022-04-16 09:55:37 +00:00

Bounties Module ( pallet-bounties )

Bounty

NOTE: This pallet is tightly coupled with pallet-treasury.

A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined Treasury amount to be paid out. A curator is assigned after the bounty is approved and funded by Council, to be delegated with the responsibility of assigning a payout address once the specified set of objectives is completed.

After the Council has activated a bounty, it delegates the work that requires expertise to a curator in exchange of a deposit. Once the curator accepts the bounty, they get to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address, the curator fee and the return of the curator deposit. The delay allows for intervention through regular democracy. The Council gets to unassign the curator, resulting in a new curator election. The Council also gets to cancel the bounty if deemed necessary before assigning a curator or once the bounty is active or payout is pending, resulting in the slash of the curator's deposit.

This pallet may opt into using a [ChildBountyManager] that enables bounties to be split into sub-bounties, as children of anh established bounty (called the parent in the context of it's children).

NOTE: The parent bounty cannot be closed if it has a non-zero number of it has active child bounties associated with it.

Terminology

Bounty:

  • Bounty spending proposal: A proposal to reward a predefined body of work upon completion by the Treasury.
  • Proposer: An account proposing a bounty spending.
  • Curator: An account managing the bounty and assigning a payout address receiving the reward for the completion of work.
  • Deposit: The amount held on deposit for placing a bounty proposal plus the amount held on deposit per byte within the bounty description.
  • Curator deposit: The payment from a candidate willing to curate an approved bounty. The deposit is returned when/if the bounty is completed.
  • Bounty value: The total amount that should be paid to the Payout Address if the bounty is rewarded.
  • Payout address: The account to which the total or part of the bounty is assigned to.
  • Payout Delay: The delay period for which a bounty beneficiary needs to wait before claiming.
  • Curator fee: The reserved upfront payment for a curator for work related to the bounty.

Interface

Dispatchable Functions

Bounty protocol:

  • propose_bounty - Propose a specific treasury amount to be earmarked for a predefined set of tasks and stake the required deposit.
  • approve_bounty - Accept a specific treasury amount to be earmarked for a predefined body of work.
  • propose_curator - Assign an account to a bounty as candidate curator.
  • accept_curator - Accept a bounty assignment from the Council, setting a curator deposit.
  • extend_bounty_expiry - Extend the expiry block number of the bounty and stay active.
  • award_bounty - Close and pay out the specified amount for the completed work.
  • claim_bounty - Claim a specific bounty amount from the Payout Address.
  • unassign_curator - Unassign an accepted curator from a specific earmark.
  • close_bounty - Cancel the earmark for a specific treasury amount and close the bounty.