-
Notifications
You must be signed in to change notification settings - Fork 137
SNO-425: For parachain -> eth messages, sync by parachain id instead of account id #806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This should be fixed in latest master. |
| fn into(self) -> Token { | ||
| Token::Tuple(vec![ | ||
| Token::Bytes(self.parachain_id.encode()), | ||
| Token::Uint(u32::from(self.origin).into()), |
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.
Had to add an explicit conversion here because Uint has a From<u32> but no From<polkadot_parachain::primitives::Id>
SCALE uses Little Endian.
Creating a non-nil slice will make `slice != nil` checks return true when there's nothing in the slice anyway. Also nil slices are preferred: https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices
23b26ce to
ff458c2
Compare
yrong
left a comment
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.
LGTM!
This is now done in the loop.
The inbound channel contract uses OpenZeppelin's single MerkleProof, which sorts hashes before concatenation instead of including the order in the proof.
| Contracts SourceContractsConfig `mapstructure:"contracts"` | ||
| // Block number when Beefy was activated | ||
| BeefyActivationBlock uint64 `mapstructure:"beefy-activation-block"` | ||
| LaneID uint32 `mapstructure:"lane-id"` |
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.
A LaneId is a ParaId. I am not sure if we should use different terms for the same thing. In the outbound queue, we use ParaId and make no mention of Lanes. In the Rococo-Wococo bridge, they use a concept of a lane as well and it seems to be an arbitrary id that routes to but is not a ParaId.
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.
Right, that could be confusing. This was based on the execution relayer config, so I'd rather do it in a follow-up PR so we don't change the execution relayer here. LaneIDs only exist in our relayers, in the queues & messages we call it origin but paraID sounds fine for the relayers.
@vgeddes Are you happy with ParaID in the relayers?
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.
Semi-related: I noticed a bunch of sourceID references and changed them to laneID for consistency.
This also makes the parachain relayer sync messages for a single configured parachain id instead of multiple.
Issue
Companion PR in Cumulus fork (will bump the submodule here once the companion's merged)