-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Enable over-bridge-messaging in Rococo/Wococo runtime #3377
Conversation
} | ||
|
||
fn transaction_payment(transaction: MessageTransaction<Weight>) -> crate::Balance { | ||
// current fee multiplier is used here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will also likely be changed (e.g. x2-ed, not sure yet) in the P<>K deployment, because it describes future transactions, where multiplier may increase. Actually in P<>K we'll need messages parameter for that, because this value must be taken from bridged runtime storage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
impl MessageBridge for AtRococoWithWococoMessageBridge { | ||
const THIS_CHAIN_ID: ChainId = ROCOCO_CHAIN_ID; | ||
const BRIDGED_CHAIN_ID: ChainId = WOCOCO_CHAIN_ID; | ||
const RELAYER_FEE_PERCENT: u32 = 10; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in the future it would be cool to have relayers dictate this rate themselves in order to create more realistic market dynamics
// Since we deal with testnets here, in case of failure + urgency: | ||
// | ||
// 1) ping bridges team about this failure; | ||
// 2) comment/remove the test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 2) comment/remove the test. | |
// 2) comment out or ignore the test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't simply ignore failing test, if it blocks CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(unless you mean #[ignore]
, of course)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I meant #[ignore]
. Should we make that more explicit in the comment?
@@ -245,6 +248,13 @@ construct_runtime! { | |||
// Validator Manager pallet. | |||
ValidatorManager: validator_manager::{Pallet, Call, Storage, Event<T>}, | |||
|
|||
// Bridge messages support. The same story as with the bridge grandpa pallet above ^^^ - when we're | |||
// running as Rococo we only use `BridgeWococoMessages`/`BridgeWococoMessagesDispatch`, and vice versa. | |||
BridgeRococoMessages: pallet_bridge_messages::{Pallet, Call, Storage, Event<T>, Config<T>} = 43, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little unfortunate that we're being split by ValidatorManager
, do you think anything (major) would break if we moved it after the message lane pallets 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It requires a transaction spec version update. I personally don't care about this split
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would nice to have all the bridge stuff side by side, but I won't push too hard on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree Hernando here. @shawntabrizi do you mind if we change the pallet index of ValidatorManager
in the next restart/runtime upgrade of Rococo? I'd move it above the bridge stuff.
// Bridge messages support. The same story as with the bridge grandpa pallet above ^^^ - when we're | ||
// running as Rococo we only use `BridgeWococoMessages`/`BridgeWococoMessagesDispatch`, and vice versa. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Bridge messages support. The same story as with the bridge grandpa pallet above ^^^ - when we're | |
// running as Rococo we only use `BridgeWococoMessages`/`BridgeWococoMessagesDispatch`, and vice versa. | |
// Bridge messages support. | |
// The same story as with the bridge grandpa pallets: when we're | |
// running as Rococo we only use `BridgeWococoMessages`/`BridgeWococoMessagesDispatch`, and vice versa. |
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Looking forward to see that deployed 👨🚀
@@ -245,6 +248,13 @@ construct_runtime! { | |||
// Validator Manager pallet. | |||
ValidatorManager: validator_manager::{Pallet, Call, Storage, Event<T>}, | |||
|
|||
// Bridge messages support. The same story as with the bridge grandpa pallet above ^^^ - when we're | |||
// running as Rococo we only use `BridgeWococoMessages`/`BridgeWococoMessagesDispatch`, and vice versa. | |||
BridgeRococoMessages: pallet_bridge_messages::{Pallet, Call, Storage, Event<T>, Config<T>} = 43, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree Hernando here. @shawntabrizi do you mind if we change the pallet index of ValidatorManager
in the next restart/runtime upgrade of Rococo? I'd move it above the bridge stuff.
bot merge |
Trying merge. |
* master: (33 commits) Update all weights, add run_all_benches.sh script (#3400) Enable over-bridge-messaging in Rococo/Wococo runtime (#3377) paras.rs to FRAME V2 (#3403) Add XCM Tracing (#3353) Use MaxEncodedLen trait from new parity-scale-codec v2.2 (#3412) bump a bunch of deps in parity-common (#3402) Warn on low connectivity. (#3408) origin to frame v2 (#3405) Enable logging in the puppet worker (#3411) make it easier to dbg stalls (#3351) XCM `canonicalize` + `prepend_with` fix (#3269) cleanup stream polls (#3397) Staking Miner (#3141) Companion for Substrate#8953 (#3140) Bump version, specs & substrate in prep for v0.9.8 (#3387) Fix busy loops. (#3392) Minor refactor (#3386) add simnet tests (#3381) BEEFY: adjust gossip (#3372) Companion for #9193 (#3376) ...
This PR adds two pallets (every pallet is 'deployed' twice - on Rococo and on Wococo) to Rococo/Wocoo runtime. The messages pallet configuration isn't trivial, hence the separate
bridge_messages.rs
file. Normally there'll be to files like that - one that describes bridge with Chain2 and which is a part of Chain1 runtime and another one that describes bridge with Chain1 and which is a part of Chain2 runtime. Here we have a slightly different scenario when there's one runtime => the single file.Short pallets description (since it is first reference from the polkadot repo):
pallet-bridge-messages
: is the 'core' pallet of this PR. It has the only interesting (for end-user/apps) entrypoint -send_message
, which enqueues your message (encoded call of the bridged chain) in the internal queue. Eventually, your message will be picked up by the offchain (not to confuse with offchain workers) relayer, which will submit delivery transaction to the bridged chain. Once messages are delivered, relayer will submit confirmation transaction back to the original chain. The side-effect of this tx is theMessagesDelivered
event, where you could find info on whether message dispatch has succeeded or not;pallet-bridge-dispatch
: a simple pallet that will try to decode the message from the bridged chain as a call of this chain (in Rococo<>Wococo case it is the same call). If call is decoded and passes all other checks (likespec_version
check, weight check, ...), it is dispatched. In any case - for every incoming message, it'll emit event (MessageWeightMismatch
,MessageVersionSpecMismatch
,MessageDispatched
, ...).Deployment details (mostly for ones, who has some internal knowledge of pallets):
bp_rococo
/bp_wococo
) are a copy of Millau constants.