Contracts: migrate to fungible traits

[juangirini]

Fix #13643

Cumulus companion: paritytech/cumulus#2841

The Currency (and ReservableCurrency) traits are deprecated after this PR in favour of the fungible traits.

A few things have changed:

• ReservableCurrency::reserve becomes fungible::hold::Mutate::hold; and ReservableCurrency::unreserve becomes fungible::hold::Mutate::release

Holds are roughly analagous to reserves, but are now explicitly designed to be infallibly slashed. They do not contribute to the ED but do require a provider reference, removing any possibility of account reference counting from being problematic for a slash. They are also always named, ensuring different holds do not accidentally slash each other's balances.

Also they require an identifier which is configurable and is expected to be an enum aggregated across all pallet instances of the runtime.

In the Pallet Contracts context we only have one identifier only HoldReason::CodeUploadDepositReserve

/// A reason for the pallet contracts placing a hold on funds.
#[pallet::composite_enum]
pub enum HoldReason {
    /// The Pallet has reserved it for storage deposit.
    CodeUploadDepositReserve,
}

• Due to the changes from reserve/unreserve to hold/release some events have been changed:

  • pallet_balances::Event::Reserved is not fired anymore in the context of Contracts, instead pallet_contracts::Event::CodeStored contains a deposit_held field.
  • analogously pallet_balances::Event::Unreserved is not fired anymore in the context of Contracts, instead pallet_contracts::Event::CodeRemoved contains a deposit_held field.
    Please note that these events belong to pallet_contracts as the fungible traits don't emit any events on hold and release.

• The ExistenceRequirement enum is not used anymore, it is replaced by Preservation. They don't map exactly therefore a few adaptations have been made.

/// Simple boolean for whether an account needs to be kept in existence.
#[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
pub enum ExistenceRequirement {
    /// Operation must not result in the account going out of existence.
    ///
    /// Note this implies that if the account never existed in the first place, then the operation
    /// may legitimately leave the account unchanged and still non-existent.
    KeepAlive,
    /// Operation may result in account going out of existence.
    AllowDeath,
}

/// The mode by which we describe whether an operation should keep an account alive.
#[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
pub enum Preservation {
    /// We don't care if the account gets killed by this operation.
    Expendable,
    /// The account may not be killed, but we don't care if the balance gets dusted.
    Protect,
    /// The account may not be killed and our provider reference must remain (in the context of
    /// tokens, this means that the account may not be dusted).
    Preserve,
}

• Currency::transfer() does not perform the sanity it used to anymore, so those are now addressed before calling Currency::transfer()

if !value.is_zero() && from != to {
    T::Currency::transfer(from, to, value, preservation)
        .map_err(|_| Error::<T>::TransferFailed)?;
}

Upgrade notes

The pallet_contracts::Config trait now requires new type RuntimeHoldReason:

impl pallet_contracts::Config for Runtime {
	...
	type RuntimeHoldReason = RuntimeHoldReason;
	...
}

Also, construct_runtime needs pallet_contracts::HoldReason:

construct_runtime!(
	pub enum Runtime where
		...
	{
		...
		// Smart Contracts.
		Contracts: pallet_contracts::{Pallet, Call, Storage, Event<T>, HoldReason} = ...,
		...
	}
)

Migrations generic OldCurrency

Some migrations require a generic OldCurrency that implements the traits that the previous T::Currency implemented. Most commonly we could just use pallet_balances::Pallet<T>.

---

Deposit account

After this PR we should no longer need the deposit accounts, as the new "held" balance does not contribute to the ED.

This PR does not alters the deposit accounts and its functionality. There is this other PR #14589 that takes care of that.

[athei]

Needs a migration. So we wait with merging until #14045 is merged so we can include the migration in this PR.

[pgherveou]

wouldn't comparing the total held vs reserved amount be enough here ?

[juangirini]

Unfortunately not, as there could be several reasons the code owner could have balance reserved, not just for uploaded code deposit. Therefore the "old" reserved balance should be >= than the "new" held balance under the HoldReason::CodeUploadDepositReserve, and that's a loose comparison to make.

[pgherveou]

do we need this test at all as slashing can not kill account by design now that we moved to fungible?

[juangirini]

In general I would agree, but the fact that this extra test is there does not hurt, and it adds an extra shield that can potentially prevent a situation in which we are not thinking of at the moment. (It might sound stupid, but maybe a situation where the Currency type used in the test does not honour the actual definition of the trait implementation)

[juangirini]

bot merge

[juangirini]

bot merge