[V2 Bridges] Dynamic way of adding permissionless lanes (bridges between parachains)

[svyatonik]

related to https://github.com/paritytech/srlabs_findings/issues/142

Our design is to have a dedicated lane for two bridged chains (see https://github.com/paritytech/parity-bridges-common/blob/master/docs/polkadot-kusama-bridge-overview.md#connecting-parachains). E.g. Polkadot' Statemint and Kusama' Statemine will use the lane [0, 0, 0, 0].

Later we want to be able to connect other parachains. While we may do that by doing runtime upgrades and manually coding that, we may also have some calls for that, so that lanes may be opened without waiting for runtime upgrades.

Apart from that, we shall think of some deposit that must be paid for opening a lane. The amount of deposit may affect (or take into account) the maximal number of outbound messages for that lane. That's because parachains may just queue messages and don't run any relayer => bridge hub runtime storage will grow and storage proofs size will grow too. We may start to take some fee from deposit if messages are queued for too long and finally close the lane if deposit is depleted.

Hints:

• SignedExtension like RefundBridgedParachainMessages uses LaneId cfg
• ...
• search in Cumulus for /// TODO: rework once dynamic lanes are supported (https://github.com/paritytech/parity-bridges-common/issues/2451)

TODO

• migrate origin/bridges-v2 Split and migrate origin/bridges-v2 branch #2976
• merge pallet changes: [bridges-v2] Permissionless lanes  polkadot-sdk#4949
• adapt relayer Adapt relayer to work with dynamic lanes #2407
• prepare documentation for end users/parachains how to open and use it
  • deposit enough funds for BridgeReserve
  • open bridge
    • can/should we do it in one call?

[bkontur]

well, this kind of on-chain configuration, I mentioned here #2452
could be really used here, and governance can manage deposit amount or what ever

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/bridge-hub-questions/2693/2

[bkontur]

• maybe it looks like if we use xcm channel: u32 and convert it to the LaneId in HaulBlob impl here we dont need hard-coded LaneId, trait XcmBlobHauler could have cfg for default (hard-coded - can be used for rialto/millau) and some logic which will choose xcm:channel: u32 or default
• plus ActiveOutboundLanes can be probably set as pub storage ActiveOutboundLanes so it can be managed by governance to add new once
• the last thing could be to fix RefundBridgedParachainMessages support dynamic lanes

[svyatonik]

The #2213 adds initial support for dynamic lanes at bridge hub. It assumes that there's also some code at the bridge origin (currently sibling/child parachain and parent relay chain is supported). I've started prototyping this code (pallet) in #2233 - the pallet from this PR will be deployed at this bridge origin and will "talk" to the pallet-xcm-bridge-hub to read bridge state and implement dynamic fee system.

Apart from future developments, there's also unimplemented stuff in the #2213, which I'd like to tackle in a separate PRs:

• everything related to weights (benchmarks, refunds, storage map limits);
• more misbehavior types;
• start closing lane at this side if the same lane is in closing state at the bridged side;
• support dynamic lanes in signed extensions. Not sure that we need it if we plan to deliver dynamic lanes and fees at the same time with the [V2 Bridges] Coordinated relayers protocol for cheaper relaying #2486. If it'll be the same time - then we'll just drop signed extensions

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-kusama-bridge/2971/26

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-kusama-bridge/2971/35