pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-30 19:51:02 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
eefd5fe4499515da66d088505093f75b5aa22550
pezkuwi-subxt/cumulus/parachains/runtimes/bridge-hubs
T
History
Oliver Tale-Yazdi eefd5fe449 Multi-Block-Migrations, poll hook and new System callbacks (#1781) 
This MR is the merge of
https://github.com/paritytech/substrate/pull/14414 and
https://github.com/paritytech/substrate/pull/14275. It implements
[RFC#13](https://github.com/polkadot-fellows/RFCs/pull/13), closes
https://github.com/paritytech/polkadot-sdk/issues/198.

----- 

This Merge request introduces three major topicals:

1. Multi-Block-Migrations
1. New pallet `poll` hook for periodic service work
1. Replacement hooks for `on_initialize` and `on_finalize` in cases
where `poll` cannot be used

and some more general changes to FRAME.  
The changes for each topical span over multiple crates. They are listed
in topical order below.

# 1.) Multi-Block-Migrations

Multi-Block-Migrations are facilitated by creating `pallet_migrations`
and configuring `System::Config::MultiBlockMigrator` to point to it.
Executive picks this up and triggers one step of the migrations pallet
per block.
The chain is in lockdown mode for as long as an MBM is ongoing.
Executive does this by polling `MultiBlockMigrator::ongoing` and not
allowing any transaction in a block, if true.

A MBM is defined through trait `SteppedMigration`. A condensed version
looks like this:
```rust
/// A migration that can proceed in multiple steps.
pub trait SteppedMigration {
	type Cursor: FullCodec + MaxEncodedLen;
	type Identifier: FullCodec + MaxEncodedLen;

	fn id() -> Self::Identifier;

	fn max_steps() -> Option<u32>;

	fn step(
		cursor: Option<Self::Cursor>,
		meter: &mut WeightMeter,
	) -> Result<Option<Self::Cursor>, SteppedMigrationError>;
}
```

`pallet_migrations` can be configured with an aggregated tuple of these
migrations. It then starts to migrate them one-by-one on the next
runtime upgrade.
Two things are important here:
- 1. Doing another runtime upgrade while MBMs are ongoing is not a good
idea and can lead to messed up state.
- 2. **Pallet Migrations MUST BE CONFIGURED IN `System::Config`,
otherwise it is not used.**

The pallet supports an `UpgradeStatusHandler` that can be used to notify
external logic of upgrade start/finish (for example to pause XCM
dispatch).

Error recovery is very limited in the case that a migration errors or
times out (exceeds its `max_steps`). Currently the runtime dev can
decide in `FailedMigrationHandler::failed` how to handle this. One
follow-up would be to pair this with the `SafeMode` pallet and enact
safe mode when an upgrade fails, to allow governance to rescue the
chain. This is currently not possible, since governance is not
`Mandatory`.

## Runtime API

- `Core`: `initialize_block` now returns `ExtrinsicInclusionMode` to
inform the Block Author whether they can push transactions.

### Integration

Add it to your runtime implementation of `Core` and `BlockBuilder`:
```patch
diff --git a/runtime/src/lib.rs b/runtime/src/lib.rs
@@ impl_runtime_apis! {
	impl sp_block_builder::Core<Block> for Runtime {
-		fn initialize_block(header: &<Block as BlockT>::Header) {
+		fn initialize_block(header: &<Block as BlockT>::Header) -> RuntimeExecutiveMode {
			Executive::initialize_block(header)
		}

		...
	}
```

# 2.) `poll` hook

A new pallet hook is introduced: `poll`. `Poll` is intended to replace
mostly all usage of `on_initialize`.
The reason for this is that any code that can be called from
`on_initialize` cannot be migrated through an MBM. Currently there is no
way to statically check this; the implication is to use `on_initialize`
as rarely as possible.
Failing to do so can result in broken storage invariants.

The implementation of the poll hook depends on the `Runtime API` changes
that are explained above.

# 3.) Hard-Deadline callbacks

Three new callbacks are introduced and configured on `System::Config`:
`PreInherents`, `PostInherents` and `PostTransactions`.
These hooks are meant as replacement for `on_initialize` and
`on_finalize` in cases where the code that runs cannot be moved to
`poll`.
The reason for this is to make the usage of HD-code (hard deadline) more
explicit - again to prevent broken invariants by MBMs.

# 4.) FRAME (general changes)

## `frame_system` pallet

A new memorize storage item `InherentsApplied` is added. It is used by
executive to track whether inherents have already been applied.
Executive and can then execute the MBMs directly between inherents and
transactions.

The `Config` gets five new items:
- `SingleBlockMigrations` this is the new way of configuring migrations
that run in a single block. Previously they were defined as last generic
argument of `Executive`. This shift is brings all central configuration
about migrations closer into view of the developer (migrations that are
configured in `Executive` will still work for now but is deprecated).
- `MultiBlockMigrator` this can be configured to an engine that drives
MBMs. One example would be the `pallet_migrations`. Note that this is
only the engine; the exact MBMs are injected into the engine.
- `PreInherents` a callback that executes after `on_initialize` but
before inherents.
- `PostInherents` a callback that executes after all inherents ran
(including MBMs and `poll`).
- `PostTransactions` in symmetry to `PreInherents`, this one is called
before `on_finalize` but after all transactions.

A sane default is to set all of these to `()`. Example diff suitable for
any chain:
```patch
@@ impl frame_system::Config for Test {
 	type MaxConsumers = ConstU32<16>;
+	type SingleBlockMigrations = ();
+	type MultiBlockMigrator = ();
+	type PreInherents = ();
+	type PostInherents = ();
+	type PostTransactions = ();
 }
```

An overview of how the block execution now looks like is here. The same
graph is also in the rust doc.

<details><summary>Block Execution Flow</summary>
<p>

![Screenshot 2023-12-04 at 19 11
29](https://github.com/paritytech/polkadot-sdk/assets/10380170/e88a80c4-ef11-4faa-8df5-8b33a724c054)

</p>
</details> 

## Inherent Order

Moved to https://github.com/paritytech/polkadot-sdk/pull/2154

---------------


## TODO

- [ ] Check that `try-runtime` still works
- [ ] Ensure backwards compatibility with old Runtime APIs
- [x] Consume weight correctly
- [x] Cleanup

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Juan Girini <juangirini@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Gavin Wood <gavin@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>
2024-02-28 19:49:00 +00:00
..
bridge-hub-rococo
Multi-Block-Migrations, poll hook and new System callbacks (#1781)
2024-02-28 19:49:00 +00:00
bridge-hub-westend
Multi-Block-Migrations, poll hook and new System callbacks (#1781)
2024-02-28 19:49:00 +00:00
common
Removes Snowbridge parachain directory (#3186)
2024-02-02 17:08:36 +00:00
docs
BridgeHubKusama - initial setup - (chain_spec + basic runtime without any bridging pallets) (#1764)
2022-12-02 14:06:39 +01:00
test-utils
Snowbridge - Test pallet order (#3381)
2024-02-21 14:48:40 +00:00
README.md
Bridge zombienet tests - move all test scripts to the same folder (#3333)
2024-02-15 12:56:58 +00:00

README.md

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=~/local_bridge_testing/bin/polkadot \
POLKADOT_PARACHAIN_BINARY=~/local_bridge_testing/bin/polkadot-parachain \
	~/local_bridge_testing/bin/zombienet-linux --provider native spawn ./bridges/testing/environments/rococo-westend/bridge_hub_rococo_local_network.toml

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

# Westend + BridgeHubWestend + AssetHub for Westend (mirroring Polkadot)
POLKADOT_BINARY=~/local_bridge_testing/bin/polkadot \
POLKADOT_PARACHAIN_BINARY=~/local_bridge_testing/bin/polkadot-parachain \
	~/local_bridge_testing/bin/zombienet-linux --provider native spawn ./bridges/testing/environments/rococo-westend/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>

./bridges/testing/environments/rococo-westend/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>

./bridges/testing/environments/rococo-westend/bridges_rococo_westend.sh init-asset-hub-rococo-local
./bridges/testing/environments/rococo-westend/bridges_rococo_westend.sh init-bridge-hub-rococo-local
./bridges/testing/environments/rococo-westend/bridges_rococo_westend.sh init-asset-hub-westend-local
./bridges/testing/environments/rococo-westend/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.
./bridges/testing/environments/rococo-westend/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.
./bridges/testing/environments/rococo-westend/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.
./bridges/testing/environments/rococo-westend/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.
./bridges/testing/environments/rococo-westend/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:
./bridges/testing/environments/rococo-westend/bridges_rococo_westend.sh claim-rewards-bridge-hub-rococo-local

# Claim rewards on BridgeHubWestend:
./bridges/testing/environments/rococo-westend/bridges_rococo_westend.sh claim-rewards-bridge-hub-westend-local

How to test local BridgeHubKusama/BridgeHubPolkadot

TODO: see # !!! READ HERE above

Reference in New Issue View Git Blame Copy Permalink