Limited Kusama <> Polkadot bridge#5174
Conversation
| } | ||
|
|
||
| /// Initialize with-Polkadot bridge. | ||
| pub struct InitializePolkadotBridge; |
There was a problem hiding this comment.
I'm unsure about this upgrade. We'll need to initialize the "pallet owner" field of both bridge pallets (that's the account that may issue some special "requests" - e.g. halt bridge during temporarily to handle runtime upgrade , update messages pallet parameters like conversion rate, ...). Don't know if doing this during runtime upgrade or using some governance mechanisms after runtime upgrade is better here.
| crate::OriginCaller::system(frame_system::RawOrigin::Signed(ref submitter)) => | ||
| Some(submitter.clone()), | ||
|
|
||
| OriginCaller::Council(_) => AllowedMessageSender::get(), |
There was a problem hiding this comment.
That's another questionable part, which I've mentioned in description. It means that we'll only accept messages with OriginCaller::Council origin
|
/benchmark runtime polkadot pallet_bridge_grandpa |
|
Benchmark Runtime Polkadot Pallet for branch "sv-bridges-finally" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=pallet_bridge_grandpa --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/ Toolchain: stable-x86_64-unknown-linux-gnu (default) ResultsERROR: Unable to push ./runtime/polkadot/src/weights/ |
|
/benchmark runtime polkadot pallet_bridge_messages |
|
Benchmark Runtime Polkadot Pallet for branch "sv-bridges-finally" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=pallet_bridge_messages --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/ Toolchain: stable-x86_64-unknown-linux-gnu (default) Results |
…-- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=pallet_bridge_messages --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/
|
/benchmark runtime polkadot pallet_bridge_grandpa |
|
Benchmark Runtime Polkadot Pallet for branch "sv-bridges-finally" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=pallet_bridge_grandpa --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/ Toolchain: stable-x86_64-unknown-linux-gnu (default) Results |
…-- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=pallet_bridge_grandpa --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/
|
/benchmark runtime kusama pallet_bridge_grandpa |
|
Benchmark Runtime Kusama Pallet for branch "sv-bridges-finally" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=pallet_bridge_grandpa --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/ Toolchain: stable-x86_64-unknown-linux-gnu (default) Results |
…-- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=pallet_bridge_grandpa --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/
|
/benchmark runtime kusama pallet_bridge_messages |
|
Benchmark Runtime Kusama Pallet for branch "sv-bridges-finally" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=pallet_bridge_messages --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/ Toolchain: stable-x86_64-unknown-linux-gnu (default) Results |
…-- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=pallet_bridge_messages --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/
|
So this isn’t quite about allowing the Kusama Council to spend Kusama’s DOT. And it’s certainly not about allowing any individual council member to spend the DOT. Rather it’s about allowing the Kusama treasury to own DOT. In the light of Gov2, which will be rolled out imminently this distinction is especially important since there will not be a council if/when it gets deployed. |
Ok, I may be wrong here as I've already lost origins of this requirement. But it is what we/I've been working here so far. Possibly, it was just one possible implementations:
The original idea was to have some kind of wrapped DOTs on Kusama (iirc some pallet that implements
Yes - that's what I'm unsure about. The options are to change it to majority or complete council. But it depends on whether all this schema works (where council directly controls DOTs over the bridge) for you.
If there won't be a council or any other group (read: dispatch origin) that we may grant control over bridged DOTs, then we'll need to be able to process spend-treasury-DOTs referenda somehow, right? If we'll keep this control-DOTs-over-bridge concept, then there's a problem even at first glance. Right now we're storing In any case, the future of this PR isn't clear to me. Shall we introduce some minor fixes and make it work with majority/complete council approval (mean: governance v1)? Shall we postpone bridge and start adapting it for governance v2? Do we need to change the way how Kusama council/members can control DOTs - i.e. wDOTs instead of control-DOTs-over-bridge? |
|
the decision is to deploy XCM bridge (either relay or para) instead. closing |
Even though there are some TODOs here, the PR is reviewable already (the only planned code changes are weight-related). Main TODOs in this PR:
Short bridge FAQ
This bridge adds Polkadot GRANDPA light client (
pallet-bridge-gandpa) to the Kusama runtime and vice versa. This light client may be used to verify proofs (e.g. storage proofs) from the bridged chain. In our implementation, we'll be accepting messages (usingpallet-bridge-messages) at the source chain and submit storage proofs of these messages to the target chain. Both chains may serve as the source and target chains. The message in our implementation means encoded call (that's the main part of the regular transaction) that will be accepted at the source chain and then dispatched (usingpallet-bridge-dispatch) at the target chain.Apart from the on-chain pallets, there's also offchain entity - relay/relayer, which is submitting message delivery transactions to both chains.
More details can be found in the
parity-bridges-commonrepository.Bridge limitations
While the bridge we develop is a general-usage bridge, it'll have serious restrictions in initial deployment.
balances::transfercalls may be sent over the bridgeWhy is it so restricted? The main reason is that the bridge is going to change in the future (detailed plan is still WiP) and if we'll allow everyone to use it now, it'll be hard, if not impossible, to perform migrations.
Bridge use-case
@gavofyork - This is the most questionable part here, where I'd like to get your approval.
How it is designed:
KusamaCouncilAccount;AllowedMessageSenderparameter from thepolkadot_messages.rsfile);KusamaCouncilAccount. Let it be theKusamaCouncilAccountAtPolkadot;KusamaCouncilAccountAtPolkadotat the Polkadot.Technically it means, that we'll only accept messages that are being sent using origin
pallet_collective::RawOrigin::<CouncilCollective>::Members(_, _)orpallet_collective::RawOrigin::<CouncilCollective>::Member(). So even one member can send messages (aka spend DOTs)!Please check if I'm wrong here - I guess we may need some corrections here.
Local Demo
Everyone may test it with local Kusama/Polkadot chains, using this guide. This guide needs some updates - in particular, how to fill all send-message transaction parameters, but overall it is usable.
There's also kusama-polkadot.test repository, which may be used for spinning up local Kusama and Polkadot nodes + running the bridge. But it is a bit outdated and maintenance is not guaranteed.
P.S.: I'm pinging @andresilva as well, as suggested by @stefan-sopic, since you're somewhat related to bridges :) Feel free to ignore if you feel its outside of your interests/expertise.