Files
pezkuwi-subxt/cumulus/parachains/runtimes/bridge-hubs
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
..

Bridge-hub Parachains

BridgeHub(s) are system parachains that will house trustless bridges from the local ecosystem to others. The current trustless bridges planned for the BridgeHub(s) are:

  • BridgeHubPolkadot system parachain:
    1. Polkadot <-> Kusama bridge
    2. Polkadot <-> Ethereum bridge (Snowbridge)
  • BridgeHubKusama system parachain:
    1. Kusama <-> Polkadot bridge
    2. Kusama <-> Ethereum bridge The high-level responsibilities of each bridge living on BridgeHub:
  • sync finality proofs between relay chains (or equivalent)
  • sync finality proofs between BridgeHub parachains
  • pass (XCM) messages between different BridgeHub parachains

Requirements for local run/testing

# Prepare empty directory for testing
mkdir -p ~/local_bridge_testing/bin
mkdir -p ~/local_bridge_testing/logs

---
# 1. Install zombienet
Go to: https://github.com/paritytech/zombienet/releases
Copy the apropriate binary (zombienet-linux) from the latest release to ~/local_bridge_testing/bin


---
# 2. Build polkadot binary

We need polkadot binary with "fast-runtime" feature:

cd <polkadot-sdk-git-repo-dir>
cargo build --release --features fast-runtime --bin polkadot
cp target/release/polkadot ~/local_bridge_testing/bin/polkadot

cargo build --release --features fast-runtime --bin polkadot-prepare-worker
cp target/release/polkadot-prepare-worker ~/local_bridge_testing/bin/polkadot-prepare-worker

cargo build --release --features fast-runtime --bin polkadot-execute-worker
cp target/release/polkadot-execute-worker ~/local_bridge_testing/bin/polkadot-execute-worker


---
# 3. Build substrate-relay binary
git clone https://github.com/paritytech/parity-bridges-common.git
cd parity-bridges-common

# checkout desired branch or use master:
# git checkout -b master --track origin/master
# `polkadot-staging` (recommended) is stabilized and compatible for Cumulus releases
# `master` is latest development
git checkout -b polkadot-staging --track origin/polkadot-staging

cargo build --release -p substrate-relay
cp target/release/substrate-relay ~/local_bridge_testing/bin/substrate-relay


---
# 4. Build cumulus polkadot-parachain binary
cd <polkadot-sdk-git-repo-dir>

cargo build --release -p polkadot-parachain-bin
cp target/release/polkadot-parachain ~/local_bridge_testing/bin/polkadot-parachain
cp target/release/polkadot-parachain ~/local_bridge_testing/bin/polkadot-parachain-asset-hub

How to test local Rococo <-> Westend bridge

Run Rococo/Westend chains with zombienet

cd <polkadot-sdk-git-repo-dir>

# Rococo + BridgeHubRococo + AssetHub for Rococo (mirroring Kusama)
POLKADOT_BINARY_PATH=~/local_bridge_testing/bin/polkadot \
POLKADOT_PARACHAIN_BINARY_PATH=~/local_bridge_testing/bin/polkadot-parachain \
POLKADOT_PARACHAIN_BINARY_PATH_FOR_ASSET_HUB_ROCOCO=~/local_bridge_testing/bin/polkadot-parachain-asset-hub \
	~/local_bridge_testing/bin/zombienet-linux --provider native spawn ./cumulus/zombienet/bridge-hubs/bridge_hub_rococo_local_network.toml
cd <polkadot-sdk-git-repo-dir>

# Westend + BridgeHubWestend + AssetHub for Westend (mirroring Polkadot)
POLKADOT_BINARY_PATH=~/local_bridge_testing/bin/polkadot \
POLKADOT_PARACHAIN_BINARY_PATH=~/local_bridge_testing/bin/polkadot-parachain \
POLKADOT_PARACHAIN_BINARY_PATH_FOR_ASSET_HUB_WESTEND=~/local_bridge_testing/bin/polkadot-parachain-asset-hub \
	~/local_bridge_testing/bin/zombienet-linux --provider native spawn ./cumulus/zombienet/bridge-hubs/bridge_hub_westend_local_network.toml

Init bridge and run relayer between BridgeHubRococo and BridgeHubWestend

Accounts of BridgeHub parachains:

  • Bob is pallet owner of all bridge pallets

Run with script

cd <polkadot-sdk-git-repo-dir>

./cumulus/scripts/bridges_rococo_westend.sh run-relay

Check relay-chain headers relaying:

Check parachain headers relaying:

Initialize configuration for transfer asset over bridge (ROCs/WNDs)

This initialization does several things:

  • creates ForeignAssets for wrappedROCs/wrappedWNDs
  • drips SA for AssetHubRococo on AssetHubWestend (and vice versa) which holds reserved assets on source chains
cd <polkadot-sdk-git-repo-dir>

./cumulus/scripts/bridges_rococo_westend.sh init-asset-hub-rococo-local
./cumulus/scripts/bridges_rococo_westend.sh init-bridge-hub-rococo-local
./cumulus/scripts/bridges_rococo_westend.sh init-asset-hub-westend-local
./cumulus/scripts/bridges_rococo_westend.sh init-bridge-hub-westend-local

Send messages - transfer asset over bridge (ROCs/WNDs)

Do reserve-backed transfers:

cd <polkadot-sdk-git-repo-dir>

# ROCs from Rococo's Asset Hub to Westend's.
./cumulus/scripts/bridges_rococo_westend.sh reserve-transfer-assets-from-asset-hub-rococo-local
cd <polkadot-sdk-git-repo-dir>

# WNDs from Westend's Asset Hub to Rococo's.
./cumulus/scripts/bridges_rococo_westend.sh reserve-transfer-assets-from-asset-hub-westend-local

Do reserve withdraw transfers: (when previous is finished)

cd <polkadot-sdk-git-repo-dir>

# wrappedWNDs from Rococo's Asset Hub to Westend's.
./cumulus/scripts/bridges_rococo_westend.sh withdraw-reserve-assets-from-asset-hub-rococo-local
cd <polkadot-sdk-git-repo-dir>

# wrappedROCs from Westend's Asset Hub to Rococo's.
./cumulus/scripts/bridges_rococo_westend.sh withdraw-reserve-assets-from-asset-hub-westend-local

Claim relayer's rewards on BridgeHubRococo and BridgeHubWestend

Accounts of BridgeHub parachains:

  • //Charlie is relayer account on BridgeHubRococo
  • //Charlie is relayer account on BridgeHubWestend
cd <polkadot-sdk-git-repo-dir>

# Claim rewards on BridgeHubWestend:
./cumulus/scripts/bridges_rococo_westend.sh claim-rewards-bridge-hub-rococo-local

# Claim rewards on BridgeHubWestend:
./cumulus/scripts/bridges_rococo_westend.sh claim-rewards-bridge-hub-westend-local

How to test local BridgeHubKusama/BridgeHubPolkadot

TODO: see # !!! READ HERE above