From 010588e95af15da885712bbe8b57b8f579ee798c Mon Sep 17 00:00:00 2001 From: kaichao Date: Tue, 22 Jun 2021 15:20:00 +0800 Subject: [PATCH] Allow Root to assume SourceAccount. (#1011) * Allow Root to assume SourceAccount. * fmt code --- bridges/modules/dispatch/src/lib.rs | 9 +++------ bridges/modules/messages/README.md | 4 ++-- bridges/primitives/message-dispatch/src/lib.rs | 2 +- bridges/relays/client-substrate/src/lib.rs | 2 +- 4 files changed, 7 insertions(+), 10 deletions(-) diff --git a/bridges/modules/dispatch/src/lib.rs b/bridges/modules/dispatch/src/lib.rs index 4f61a3b935..fcf8c73c29 100644 --- a/bridges/modules/dispatch/src/lib.rs +++ b/bridges/modules/dispatch/src/lib.rs @@ -355,7 +355,7 @@ where } CallOrigin::SourceAccount(ref source_account_id) => { ensure!( - sender_origin == &RawOrigin::Signed(source_account_id.clone()), + sender_origin == &RawOrigin::Signed(source_account_id.clone()) || sender_origin == &RawOrigin::Root, BadOrigin ); Ok(Some(source_account_id.clone())) @@ -964,10 +964,7 @@ mod tests { Err(BadOrigin) )); - // If we try and send the message from Root, it is also rejected - assert!(matches!( - verify_message_origin(&RawOrigin::Root, &message), - Err(BadOrigin) - )); + // The Root account is allowed to assume any expected origin account + assert!(matches!(verify_message_origin(&RawOrigin::Root, &message), Ok(Some(1)))); } } diff --git a/bridges/modules/messages/README.md b/bridges/modules/messages/README.md index 973e251083..be25b3c37f 100644 --- a/bridges/modules/messages/README.md +++ b/bridges/modules/messages/README.md @@ -159,7 +159,7 @@ all required traits and will simply reject all transactions, related to outbound The `pallet_bridge_messages::Config` trait has 2 main associated types that are used to work with inbound messages. The `pallet_bridge_messages::Config::SourceHeaderChain` defines how we see the -bridged chain as the source or our inbound messages. When relayer sends us a delivery transaction, +bridged chain as the source or our inbound messages. When relayer sends us a delivery transaction, this implementation must be able to parse and verify the proof of messages wrapped in this transaction. Normally, you would reuse the same (configurable) type on all chains that are sending messages to the same bridged chain. @@ -201,7 +201,7 @@ message needs to be read. So there's another When choosing values for these parameters, you must also keep in mind that if proof in your scheme is based on finality of headers (and it is the most obvious option for Substrate-based chains with finality notion), then choosing too small values for these parameters may cause significant delays -in message delivery. That's because there too many actors involved in this scheme: 1) authorities +in message delivery. That's because there are too many actors involved in this scheme: 1) authorities that are finalizing headers of the target chain need to finalize header with non-empty map; 2) the headers relayer then needs to submit this header and its finality proof to the source chain; 3) the messages relayer must then send confirmation transaction (storage proof of this map) to the source diff --git a/bridges/primitives/message-dispatch/src/lib.rs b/bridges/primitives/message-dispatch/src/lib.rs index dcbc9ae085..859dc5e469 100644 --- a/bridges/primitives/message-dispatch/src/lib.rs +++ b/bridges/primitives/message-dispatch/src/lib.rs @@ -102,7 +102,7 @@ pub enum CallOrigin. -//! Tools to interact with (Open) Ethereum node using RPC methods. +//! Tools to interact with Substrate node using RPC methods. #![warn(missing_docs)]