-
Notifications
You must be signed in to change notification settings - Fork 2.6k
authority-discovery: Support multiple authority ids per peer id #10259
Conversation
An peer id can be mapped to multiple authority ids, because an authority id is a session key that could be changed every session. Before this pr the internal authority discovery cache assumed that each authority id can only be mapped to one peer id. However, this isn't true since we changed the default implementation of the authority discovery to combine the current and next session authorities.
…covery-multiple-peer-ids
Needs a polkadot companion |
…covery-multiple-peer-ids
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 better now :)
}; | ||
pub fn insert(&mut self, authority_id: AuthorityId, addresses: Vec<Multiaddr>) { | ||
let addresses = addresses.into_iter().collect::<HashSet<_>>(); | ||
let peer_ids = addresses_to_peer_ids(&addresses); |
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.
maybe we should ensure the len is 1 here? See the comment above
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.
Done
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 actually meant exactly one
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.
Hmm, I mean you could change your peerid and then for some time you would occur with multiple peer ids in the dht?
Even if someone runs two nodes, we can not know this for sure.
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.
But if you're putting a new record, won't it override the old one? They are keyed by AuthorityId
(s).
Even if someone runs two nodes, we can not know this for sure.
yeah, I wrote this in the comment above:
Technically, one could copy an AuthorityId to a validator with different PeerId and change other session keys. But that's a really contrived scenario.
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.
Even if there are two records (old and new) floating around, we'll never see a mix of a few records in one call. We either see one or another (or one after another). And each record should contain Multiaddr
s corresponding to one peer. Otherwise, a warning might be warranted -- this is either an equivocation symptom or misbehavior.
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.
Even if the current implementation does not end up with multiple PeerId-s, does it really affect security if the same AuthorityId is used on multiple peers? That would need copying the ephemeral private key of the session from one peer to another, right?
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.
An authority that has put multiple PeerIds into its own record can do harm to noone but itself, by not properly connecting to everyone an missing on approval voting rewards (and if there are many such authorities, it may slightly delay finality). But I think we should detect and report this and not silently ignore.
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.
So are you okay if finding multiple PeerId-s for an AuthorityId is detected and logged, but not forbidden?
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.
But I think we should detect and report this and not silently ignore.
Done
Co-authored-by: Andronik Ordian <write@reusable.software>
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 is nice to see how separated these mappings in AddrCache
were from all other code. Hopefully other pieces of code that had an assumption about the multiplicity of this relation would be compile-time broken by these changes.
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
Authority discovery before had a fixed mapping from `PeerId` to `AuthorityId`. This wasn't correct, as a `PeerId` can actually map to multiple `AuthorityId`s. The linked Substrate pr fixes this. paritytech/substrate#10259
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.
One last thing...
Co-authored-by: Andronik Ordian <write@reusable.software>
…com:paritytech/substrate into bkchr-authority-discovery-multiple-peer-ids
/// See [`Service::get_authority_id_by_peer_id`]. | ||
GetAuthorityIdByPeerId(PeerId, oneshot::Sender<Option<AuthorityId>>), | ||
GetAuthorityIdByPeerId(PeerId, oneshot::Sender<Option<HashSet<AuthorityId>>>), |
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.
Isn't the Option
redundant 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.
Depends on how you see it. None
tells you that the peer id is unknown.
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.
We would also know that, if the set is empty - no? Like if there is an entry for the PeerId
the set should not be empty, otherwise, why would we keep the entry?
companion needs fixing and we're good to go |
bot merge force |
Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#4295 |
bot merge force |
Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#4295 |
The error message is wrong, it expects 2 approvals on companion |
* Substrate companion: Authority discovery multiple peer ids Authority discovery before had a fixed mapping from `PeerId` to `AuthorityId`. This wasn't correct, as a `PeerId` can actually map to multiple `AuthorityId`s. The linked Substrate pr fixes this. paritytech/substrate#10259 * Update node/network/availability-distribution/src/requester/mod.rs * Update node/network/collator-protocol/src/validator_side/mod.rs * Update node/network/statement-distribution/src/tests.rs * Update guide * Adapt to Substrate pr * Update Substrate
* Substrate companion: Authority discovery multiple peer ids Authority discovery before had a fixed mapping from `PeerId` to `AuthorityId`. This wasn't correct, as a `PeerId` can actually map to multiple `AuthorityId`s. The linked Substrate pr fixes this. paritytech/substrate#10259 * Update node/network/availability-distribution/src/requester/mod.rs * Update node/network/collator-protocol/src/validator_side/mod.rs * Update node/network/statement-distribution/src/tests.rs * Update guide * Adapt to Substrate pr * Update Substrate
…tytech#10259) * authority-discovery: Support multiple authority ids per peer id An peer id can be mapped to multiple authority ids, because an authority id is a session key that could be changed every session. Before this pr the internal authority discovery cache assumed that each authority id can only be mapped to one peer id. However, this isn't true since we changed the default implementation of the authority discovery to combine the current and next session authorities. * Review feedback * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Early return on no peer ids * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> * Update types in comment * FMT * Add warning * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Feedback Co-authored-by: Andronik Ordian <write@reusable.software> Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
…tytech#10259) * authority-discovery: Support multiple authority ids per peer id An peer id can be mapped to multiple authority ids, because an authority id is a session key that could be changed every session. Before this pr the internal authority discovery cache assumed that each authority id can only be mapped to one peer id. However, this isn't true since we changed the default implementation of the authority discovery to combine the current and next session authorities. * Review feedback * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Early return on no peer ids * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> * Update types in comment * FMT * Add warning * Update client/authority-discovery/src/worker/addr_cache.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Feedback Co-authored-by: Andronik Ordian <write@reusable.software> Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
An peer id can be mapped to multiple authority ids, because an authority id is a session key that
could be changed every session. Before this pr the internal authority discovery cache assumed that
each authority id can only be mapped to one peer id. However, this isn't true since we changed the
default implementation of the authority discovery to combine the current and next session authorities.
Closes: #7461
polkadot companion: paritytech/polkadot#4295
skip check-dependent-cumulus