Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

authority-discovery: Support multiple authority ids per peer id #10259

Merged
merged 13 commits into from
Nov 17, 2021

Conversation

bkchr
Copy link
Member

@bkchr bkchr commented Nov 13, 2021

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

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.
@bkchr bkchr added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit labels Nov 13, 2021
@ordian
Copy link
Member

ordian commented Nov 13, 2021

Needs a polkadot companion

Copy link
Member

@ordian ordian left a 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);
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

@ordian ordian Nov 15, 2021

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 Multiaddrs corresponding to one peer. Otherwise, a warning might be warranted -- this is either an equivocation symptom or misbehavior.

Copy link
Contributor

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?

Copy link
Member

@ordian ordian Nov 15, 2021

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.

Copy link
Contributor

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?

Copy link
Member Author

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

bkchr and others added 2 commits November 14, 2021 14:31
Copy link
Contributor

@wigy-opensource-developer wigy-opensource-developer left a 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.

client/authority-discovery/src/worker/addr_cache.rs Outdated Show resolved Hide resolved
bkchr and others added 2 commits November 15, 2021 12:54
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
bkchr added a commit to paritytech/polkadot that referenced this pull request Nov 15, 2021
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
Copy link
Member

@ordian ordian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last thing...

client/authority-discovery/src/lib.rs Outdated Show resolved Hide resolved
client/authority-discovery/src/service.rs Outdated Show resolved Hide resolved
client/authority-discovery/src/worker/addr_cache.rs Outdated Show resolved Hide resolved
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>>>),
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

@ordian
Copy link
Member

ordian commented Nov 16, 2021

companion needs fixing and we're good to go

@bkchr
Copy link
Member Author

bkchr commented Nov 17, 2021

bot merge force

@paritytech-processbot
Copy link

Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#4295

@bkchr
Copy link
Member Author

bkchr commented Nov 17, 2021

bot merge force

@paritytech-processbot
Copy link

Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#4295

@bkchr bkchr merged commit 0baa586 into master Nov 17, 2021
@bkchr bkchr deleted the bkchr-authority-discovery-multiple-peer-ids branch November 17, 2021 09:53
@ordian
Copy link
Member

ordian commented Nov 17, 2021

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

bkchr added a commit to paritytech/polkadot that referenced this pull request Nov 17, 2021
* 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
@bkchr bkchr modified the milestone: Polkadot v0.9.13 Nov 25, 2021
bkchr added a commit to paritytech/polkadot that referenced this pull request Nov 30, 2021
* 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
grishasobol pushed a commit to gear-tech/substrate that referenced this pull request Mar 28, 2022
…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>
ark0f pushed a commit to gear-tech/substrate that referenced this pull request Feb 27, 2023
…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>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

client/authority-discovery: Allow two AuthorityIds to share one PeerId
5 participants