-
Notifications
You must be signed in to change notification settings - Fork 378
Add Bridges to xcm-emulator
#2812
Add Bridges to xcm-emulator
#2812
Conversation
bot fmt |
@NachoPal https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/3108369 was started for your command Comment |
@NachoPal Command |
bot fmt |
@NachoPal https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/3108705 was started for your command Comment |
@NachoPal Command |
bot fmt |
@NachoPal https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/3108859 was started for your command Comment |
@NachoPal Command |
@@ -102,6 +102,18 @@ impl TypeId for LaneId { | |||
const TYPE_ID: [u8; 4] = *b"blan"; | |||
} | |||
|
|||
impl From<LaneId> for u32 { |
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.
@NachoPal @svyatonik
I am not sure about this, can we move this out of bridges
substree?
Because then we need to backport it back to bridges repo and also in new version LaneId has a different type: https://github.com/paritytech/parity-bridges-common/pull/2221/files#diff-836b204328629e6af4b33c2a34ae41191cab06cf89c066e31bdb7085314fcda1L185-R203
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.
Agreed there's probably a better way to do 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.
The problem is implementing From
for LaneId
or the fact that LaneId
is going to change? I do not think it is harmful to implement an extra From
for a new type.
I could try to locally (as part of the BridgeHubMessageHandler
impl) wrap LaneId
in a new type and implement the From
trait for it.
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 could try to locally (as part of the BridgeHubMessageHandler impl) wrap LaneId in a new type and implement the From trait for it.
@bkontur @gilescope Check it out
Co-authored-by: Squirrel <gilescope@gmail.com>
This reverts commit 92e8f20.
bot fmt |
@NachoPal https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/3122354 was started for your command Comment |
@NachoPal Command |
bot merge |
Adding bridging capabilities to
xcm-emulator
.The
bridge
that aNetwork
is expecting is any type that implements theBridgeMessageHandler
trait. In this way we decouplexcm-emulator
from the particular Bridge implementation forBridgeHub
, avoiding also the need of importing all related packages (bp_messages
,pallet_bridge_messages
, etc). In addition, this approach would allow other teams to add their own Bridge implementations to theNetwork
.The
BridgeHub
transport layer has been mocked, abstracting out all the unnecessary complexity related to Relayers and proofs.In the PR have been added other improvements:
dmp
,ump
andhrmp
)Network
trait refactoringdecl_test_sender_receiver_accounts_parameter_types
macro