[SPEC] Slashing conditions in multi-party-ecdsa

[drewstone]

Overview

In order to report a misbehaviour we need to obtain and utilise proofs of this misbehaviour from underlying multi-party-ecdsa library (further MPE).

Research:

• Mapping between MPE parties and node authority ids.
  • Parties in MPE are identified by numbers from 1 to N inclusive. This identifiers are assigned at the start of Keygen process.
  • For party id we use authority index in authorities set.
    • [ ] Need to make sure the set has consistent order
• Proof that party i has violated the protocol
  • The MPE seems to only return a set of violating party ids, so we need to construct a proof that certain party indeed has violated the protocol.
  • One possible way to do so is by voting, similar to what we have in proposals right now. For this solution to work, the MPE’s state machine misbehaviour report must be consistent across all the nodes.
    • [ ] Check if MPE broadcasts misbehaviour with proofs to other parties, so that eventually every good party will have the same information about malicious parties.
    • [ ] Check if there is a possibility for malicious parties to manipulate others so good parties never agree reach voting threshold for slashing. E.g. malicious party sends corrupted messages to only a subset of parties while sending correct messages to others

[drewstone]

@temld4 there's a few things we'll need to do nonetheless if we want to catch and handle slashing conditions. I'd be curious to hear your thoughts on them and where you think we may fit it into the current workflow (if it's not there already).

We should be signing messages over the gossip network.

For starters, we need to validate that the only messages we process are sent by valid parties. I think we have this implemented by would be worth double-checking. Next, we need a way of indexing signed messages received from other parties efficiently. If we reach a blame stage at any phase of the protocol, it will require tracing back the misbehaving message to its signature.

We must somehow have a mapping from the signing key either (ECDSA or SR25519 key) to their staking records on-chain.

Once we identify misbehavior and the misbehaving message and signature pair, we will submit this on-chain. There we will compute a slashing amount and slash that validator's staked / nominating balances. This will require having a 1:1 mapping between the signing key for gossip messages and the staking keys on-chain for the authorities.

Misbehaviors

Offline

Likely to catch offline nodes we may only be able to rely on an honest-majority reporting assumption.

Malicious participation

Most parts of the protocol that deal with misbehavior that are not due to offline time are due to broadcasting invalid zero-knowledge proofs. Peers in the protocol broadcast zero-knowledge proofs of the data they're sharing with other participants in the DKG. Each peer verifies these proofs locally.

Keygen (Page 16 of GG20)

Signing (Page 17 of GG20)

[1xstj]

Same as #33