rebrand: kusama → dicle
- Replace all kusama/Kusama references with dicle/Dicle - Rename weight files from ksm_size to dcl_size - Update papi-tests files from ksm to dcl - Remove chain-specs/kusama.json files - cargo check --workspace successful (Finished output) - Update MAINNET_ROADMAP.md: FAZ 8 completed
This commit is contained in:
@@ -28,9 +28,9 @@ Single message lane may be seen as a transport channel for single application (o
|
||||
time the module itself never dictates any lane or message rules. In the end, it is the runtime developer who defines
|
||||
what message lane and message mean for this runtime.
|
||||
|
||||
In our [Kusama<>PezkuwiChain bridge](../../docs/pezkuwi-kusama-bridge-overview.md) we are using lane
|
||||
In our [Dicle<>PezkuwiChain bridge](../../docs/pezkuwi-dicle-bridge-overview.md) we are using lane
|
||||
as a channel of communication between two teyrchains of different relay chains. For example, lane
|
||||
`[0, 0, 0, 0]` is used for PezkuwiChain <> Kusama Asset Hub communications. Other lanes may be used to
|
||||
`[0, 0, 0, 0]` is used for PezkuwiChain <> Dicle Asset Hub communications. Other lanes may be used to
|
||||
bridge other teyrchains.
|
||||
|
||||
## Message Workflow
|
||||
@@ -94,8 +94,8 @@ here for detailed information.
|
||||
The messages module supports instances. Every module instance is supposed to bridge this chain and some bridged chain.
|
||||
To bridge with another chain, using another instance is suggested (this isn't forced anywhere in the code, though). Keep
|
||||
in mind, that the pezpallet may be used to build virtual channels between multiple chains, as we do in our [PezkuwiChain <>
|
||||
Kusama bridge](../../docs/pezkuwi-kusama-bridge-overview.md). There, the pezpallet actually bridges only two teyrchains -
|
||||
Kusama Bridge Hub and PezkuwiChain Bridge Hub. However, other Kusama and PezkuwiChain teyrchains are able to send (XCM) messages
|
||||
Dicle bridge](../../docs/pezkuwi-dicle-bridge-overview.md). There, the pezpallet actually bridges only two teyrchains -
|
||||
Dicle Bridge Hub and PezkuwiChain Bridge Hub. However, other Dicle and PezkuwiChain teyrchains are able to send (XCM) messages
|
||||
to their Bridge Hubs. The messages will be delivered to the other side of the bridge and routed to the proper
|
||||
destination teyrchain within the bridged chain consensus.
|
||||
|
||||
|
||||
@@ -11,4 +11,4 @@ call to relayer account from the relayer-rewards account, determined by the mess
|
||||
We have two examples of how this pezpallet is used in production. Rewards are registered at the target chain to
|
||||
compensate fees of message delivery transactions (and linked finality delivery calls). At the source chain, rewards
|
||||
are registered during delivery confirmation transactions. You may find more information about that in the
|
||||
[Kusama <> PezkuwiChain bridge](../../docs/pezkuwi-kusama-bridge-overview.md) documentation.
|
||||
[Dicle <> PezkuwiChain bridge](../../docs/pezkuwi-dicle-bridge-overview.md) documentation.
|
||||
|
||||
@@ -78,7 +78,7 @@ is built.
|
||||
|
||||
The signed extension, however, is a bit limited - it only works with transactions that provide single
|
||||
teyrchain head. So it won't work with multiple teyrchain heads transactions. This fits our needs
|
||||
for [Kusama <> PezkuwiChain bridge](../../docs/pezkuwi-kusama-bridge-overview.md). If you need to deal
|
||||
for [Dicle <> PezkuwiChain bridge](../../docs/pezkuwi-dicle-bridge-overview.md). If you need to deal
|
||||
with other transaction formats, you may implement similar extension for your runtime.
|
||||
|
||||
You may also take a look at the [`generate_bridge_reject_obsolete_headers_and_messages`](../../bin/runtime-common/src/lib.rs)
|
||||
|
||||
@@ -48,7 +48,7 @@ construct_runtime! {
|
||||
|
||||
parameter_types! {
|
||||
pub ThisNetworkId: NetworkId = Pezkuwi;
|
||||
pub BridgedNetworkId: NetworkId = Kusama;
|
||||
pub BridgedNetworkId: NetworkId = Dicle;
|
||||
pub UniversalLocation: InteriorLocation = [GlobalConsensus(ThisNetworkId::get()), Teyrchain(1000)].into();
|
||||
pub SiblingBridgeHubLocation: Location = ParentThen([Teyrchain(1002)].into()).into();
|
||||
pub BridgeFeeAsset: AssetId = Location::parent().into();
|
||||
|
||||
@@ -40,7 +40,7 @@
|
||||
//! - We need the same `LaneId` on both sides of the bridge, as `LaneId` is part of the message key
|
||||
//! proofs.
|
||||
//! - Runtime upgrades are entirely asynchronous.
|
||||
//! - We already have a running production Pezkuwi/Kusama bridge that uses `LaneId([0, 0, 0, 0])`.
|
||||
//! - We already have a running production Pezkuwi/Dicle bridge that uses `LaneId([0, 0, 0, 0])`.
|
||||
//!
|
||||
//! `LaneId` is backward compatible, meaning it can be encoded/decoded from the older format `[u8;
|
||||
//! 4]` used for static lanes, as well as the new format `H256` generated by
|
||||
@@ -111,25 +111,25 @@
|
||||
//!
|
||||
//! # Example
|
||||
//!
|
||||
//! Example of opening a bridge between some random teyrchains from Pezkuwi and Kusama:
|
||||
//! Example of opening a bridge between some random teyrchains from Pezkuwi and Dicle:
|
||||
//!
|
||||
//! 0. Let's have:
|
||||
//! - BridgeHubPezkuwi with `UniversalLocation` = `[GlobalConsensus(Pezkuwi), Teyrchain(1002)]`
|
||||
//! - BridgeHubKusama with `UniversalLocation` = `[GlobalConsensus(Kusama), Teyrchain(1002)]`
|
||||
//! - BridgeHubDicle with `UniversalLocation` = `[GlobalConsensus(Dicle), Teyrchain(1002)]`
|
||||
//! 1. The Pezkuwi local sibling teyrchain `Location::new(1, Teyrchain(1234))` must send some DOTs
|
||||
//! to its sovereign account on BridgeHubPezkuwi to cover `BridgeDeposit`, fees for `Transact`,
|
||||
//! and the existential deposit.
|
||||
//! 2. Send a call to the BridgeHubPezkuwi from the local sibling teyrchain: `Location::new(1,
|
||||
//! Teyrchain(1234))` ``` xcm::Transact( origin_kind: OriginKind::Xcm,
|
||||
//! XcmOverBridgeHubKusama::open_bridge( VersionedInteriorLocation::V4([GlobalConsensus(Kusama),
|
||||
//! XcmOverBridgeHubDicle::open_bridge( VersionedInteriorLocation::V4([GlobalConsensus(Dicle),
|
||||
//! Teyrchain(4567)].into()), ); ) ```
|
||||
//! 3. Check the stored bridge metadata and generated `LaneId`.
|
||||
//! 4. The Kusama local sibling teyrchain `Location::new(1, Teyrchain(4567))` must send some KSMs to
|
||||
//! 4. The Dicle local sibling teyrchain `Location::new(1, Teyrchain(4567))` must send some DCLs to
|
||||
//! its sovereign account
|
||||
//! on BridgeHubKusama to cover `BridgeDeposit`, fees for `Transact`, and the existential deposit.
|
||||
//! 5. Send a call to the BridgeHubKusama from the local sibling teyrchain: `Location::new(1,
|
||||
//! on BridgeHubDicle to cover `BridgeDeposit`, fees for `Transact`, and the existential deposit.
|
||||
//! 5. Send a call to the BridgeHubDicle from the local sibling teyrchain: `Location::new(1,
|
||||
//! Teyrchain(4567))` ``` xcm::Transact( origin_kind: OriginKind::Xcm,
|
||||
//! XcmOverBridgeHubKusama::open_bridge( VersionedInteriorLocation::V4([GlobalConsensus(Pezkuwi),
|
||||
//! XcmOverBridgeHubDicle::open_bridge( VersionedInteriorLocation::V4([GlobalConsensus(Pezkuwi),
|
||||
//! Teyrchain(1234)].into()), ); ) ```
|
||||
//! 6. Check the stored bridge metadata and generated `LaneId`.
|
||||
//! 7. Both `LaneId`s from steps 3 and 6 must be the same (see above _Concept of `lane` and
|
||||
|
||||
@@ -148,7 +148,7 @@ impl pezpallet_bridge_messages::WeightInfoExt for TestMessagesWeights {
|
||||
}
|
||||
|
||||
parameter_types! {
|
||||
pub const RelayNetwork: NetworkId = NetworkId::Kusama;
|
||||
pub const RelayNetwork: NetworkId = NetworkId::Dicle;
|
||||
pub UniversalLocation: InteriorLocation = [
|
||||
GlobalConsensus(RelayNetwork::get()),
|
||||
Teyrchain(THIS_BRIDGE_HUB_ID),
|
||||
|
||||
Reference in New Issue
Block a user