Closed EmmanuellNorbertTulbure closed 6 months ago
There are also relayer reward accounts that need to be created and funded (https://github.com/paritytech/parity-bridges-common/blob/0d2e442e6fd6e2f3bd20d061bc6f3c8adb79c12f/modules/relayers/src/lib.rs#L93). Two accounts at PBH and two at KBH.
initialize
init-bridge call as hex-encoded-data
:git clone https://github.com/paritytech/parity-bridges-common.git
git checkout -b polkadot-staging --track origin/polkadot-staging
cargo build --release -p substrate-relay
# Kusama -> Polkadot
RUST_LOG=bridge=info \
./target/release/substrate-relay init-bridge kusama-to-bridge-hub-polkadot \
--source-host kusama-rpc.polkadot.io \
--source-port 443 \
--source-secure \
--target-host polkadot-bridge-hub-rpc.polkadot.io \
--target-port 443 \
--target-secure \
--target-signer //Bob \
--dry-run
...
2022-12-02 09:08:38 +00 INFO bridge Initialize bridge call encoded as hex string: "TODO: data"
encoded call data:
TODO: generate actual encoded data
Check hex-encoded-data
here: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-bridge-hub-rpc.polkadot.io#/extrinsics/decode
Submit governance call as extrinsic with XCM::Transact
with hex-encoded-data
for para_id=1002
from Polkadot relay node
TODO: prepare command/call for opengov-cli
initialize
init-bridge call as hex-encoded-data
:git clone https://github.com/paritytech/parity-bridges-common.git
git checkout -b polkadot-staging --track origin/polkadot-staging
cargo build --release -p substrate-relay
# Polkadot -> Kusama
RUST_LOG=bridge=info \
./target/release/substrate-relay init-bridge polkadot-to-bridge-hub-kusama \
--source-host dot-rpc.stakeworld.io \
--source-port 443 \
--source-secure \
--target-host kusama-bridge-hub-rpc.polkadot.io \
--target-port 443 \
--target-secure \
--target-signer //Bob \
--dry-run
...
2022-12-02 09:08:38 +00 INFO bridge Initialize bridge call encoded as hex string: "TODO: data"
encoded call data:
TODO: generate actual encoded data
Check hex-encoded-data
here: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-bridge-hub-rpc.polkadot.io#/extrinsics/decode
Submit governance call as extrinsic with XCM::Transact
with hex-encoded-data
for para_id=1002
from Kusama relay node
TODO: prepare command/call for opengov-cli
@svyatonik just one thing came to my mind, I am not sure about, but if we submit init-bridge
calls with some data at some point T1, and when governance calls are enacted at other time T2. Do we need to make sure that our relayer is connected to some node which has old data (archive?)? I mean, if can possibly happen that RPC node (maybe not archive mode) does not have init-bridge
data, because they were pruned from its state or something like that?
@svyatonik just one thing came to my mind, I am not sure about, but if we submit
init-bridge
calls with some data at some point T1, and when governance calls are enacted at other time T2. Do we need to make sure that our relayer is connected to some node which has old data (archive?)? I mean, if can possibly happen that RPC node (maybe not archive mode) does not haveinit-bridge
data, because they were pruned from its state or something like that?
I'm not sure I understand. Why do we need data for init-bridge
at T2
? The initialize
call data is collected at T1
and we do not need an archive node for that. Then we hand it to governance and on apply, we do our usual relay-headers-and-messages
stuff. And for that we don't need an archive node too. So IIUC we won't need an archive node anywhere.
@svyatonik just one thing came to my mind, I am not sure about, but if we submit
init-bridge
calls with some data at some point T1, and when governance calls are enacted at other time T2. Do we need to make sure that our relayer is connected to some node which has old data (archive?)? I mean, if can possibly happen that RPC node (maybe not archive mode) does not haveinit-bridge
data, because they were pruned from its state or something like that?I'm not sure I understand. Why do we need data for
init-bridge
atT2
? Theinitialize
call data is collected atT1
and we do not need an archive node for that. Then we hand it to governance and on apply, we do our usualrelay-headers-and-messages
stuff. And for that we don't need an archive node too. So IIUC we won't need an archive node anywhere.
Ok, let's just ignore my comment then. It might have been a brainfart on my end. I vaguely recall encountering a situation with BridgeHubRococo where PJS couldn't display some older blocks, but I don't remember exactly what was that about (hopefully not just my imagination or dream :D), maybe it was some issue with local run or whatever :D
Yes - PJS can't access state (read runtime storage or do runtime calls) at already pruned blocks. But it can access chain data for all blocks since genesis (assuming it is fully synced if warp was used). This chain data includes: block headers, block transactions (headers + transactions = blocks) and justifications. That's what we need to be able to sync our light client (bridge GRANDPA pallet) to the latest state of bridged chain.
So at T1
we need access to the state to prepare the initialization data (IIRC we read GRANDPA authority set using some runtime calls). But once it is prepared, we won't rely on runtime state of ancient blocks (which may be pruned). Our relayer only access state of recent blocks.
So IIUC everything should be fine :)
Checked both governance calls using chopsticks and I can confirm that they produce the expected effects in the storage.
So far I couldn't check if the bridge actually works, since I couldn't find a way to start the relayer with the forked chains. More details on why that is here: https://github.com/paritytech/polkadot-sdk/issues/3522
Bridge is live, all gov calls have been successfully submitted
forceXcmVersion
governance callsforceXcmVersion
governance callshttps://github.com/polkadot-fellows/runtimes/issues/190forceDefaultXcmVersion(3)
on BridgeHubs