Report annoying peers

[HCastano]

As a first step towards #333, I want to implement a system for reporting "annoying" peers during the DKG and Signing protocols.

An "annoying peer" is one that drops a connection during while performing protocol tasks, preventing the protocol from running to completion.

We want to report this type of behaviour on-chain. However, since we can't know if this peer dropped the connection maliciously we also don't want to punish them unecessarily.

What I suggest is that if a peer gets reported by a certain threshold of its DKG or Signing committee as being "annoying" it will end up being kicked (a.k.a chilled) from the validator set at the end of the session.

Open questions:

• Is there a way for the chain to know what the protocol comittee was for a given registration or signature request?
  • For DKG anyways, from my reading of the code, it looks like the chain does have the ability to compute this since it passes that list in to the OCW
  • However, we don't end up storing this as part of the registration process, which we would need to do in order to hold validators accountable later
• How do we prevent validators from reporting their peers every round
  • Maybe we make the transaction cost a bit?
• Should we have a way to cancel pending chills?
  • Might be good if our reporting system goes awry lol
  • May also be something that's already part of the staking tooling
• Are there any other places in the protocol where we could potentially report annoying peers?
  • Maybe somewhere here or here
  • But not sure, you got any ideas here @ameba23?

[ameba23]

Is there a way for the chain to know what the protocol committee was for a given registration or signature request?

For DKG, yes, its based on block number. For signature request its based on the message so only the other members of the committee (and the user) know it.

Are there any other places in the protocol where we could potentially report annoying peers?

@JesseAbram put some TODOs in for exactly this purpose eg:

https://github.com/entropyxyz/entropy-core/blob/49cd78e79fee6f33f0d5cf2bcde6cf427f86d84a/crates/threshold-signature-server/src/signing_client/api.rs#L158

and there might have been another one.

---

Is there any documentation around kicking / chilling besides this: https://wiki.polkadot.network/docs/maintain-guides-how-to-chill#involuntary-chills

I'm trying to work out how serious a punishment it is.

Good idea about multiple complaints being required. This is a hard problem because network problems do just happen, and because the one complaining / punishing might be the bogus / malicious one.

[HCastano]

For DKG, yes, its based on block number. For signature request its based on the message so only the other members of the committee (and the user) know it.

Hmm, okay this might cause some problems for this flow then. Need to think about this more.

Is there any documentation around kicking / chilling besides this: https://wiki.polkadot.network/docs/maintain-guides-how-to-chill#involuntary-chills

I'm trying to work out how serious a punishment it is.

Good idea about multiple complaints being required. This is a hard problem because network problems do just happen, and because the one complaining / punishing might be the bogus / malicious one.

Here's a good read on slashing in general.

So this shouldn't be a serious punishment, which is why simply kicking somebody from the validator set and allowing them to come back in a future session (once they presumably get their networking under control) seems like enough. One thing to look into here would be if we can chill people without them losing their nominators, since that would be more severe than we really need this to be.

We may also want to up the reporting threshold. E.g, you're allowed to miss X full registration/signing rounds in a session (where X is probably between <5). It is possible your network could be down for the one whole protocol round and now you're getting kicked from the set, which seems a bit harsh.