mirror of
https://github.com/serai-dex/serai.git
synced 2024-12-23 03:59:22 +00:00
54f1929078
* Have processor report errors during the DKG to the coordinator * Add RemoveParticipant, InvalidDkgShare to coordinator * Route DKG blame around coordinator * Allow public construction of AdditionalBlameMachine Necessary for upcoming work on handling DKG blame in the processor and coordinator. Additionally fixes a publicly reachable panic when commitments parsed with one ThresholdParams are used in a machine using another set of ThresholdParams. Renames InvalidProofOfKnowledge to InvalidCommitments. * Remove unused error from dleq * Implement support for VerifyBlame in the processor * Have coordinator send the processor share message relevant to Blame * Remove desync between processors reporting InvalidShare and ones reporting GeneratedKeyPair * Route blame on sign between processor and coordinator Doesn't yet act on it in coordinator. * Move txn usage as needed for stable Rust to build * Correct InvalidDkgShare serialization
23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
Upon an issue with the DKG, the honest validators must remove the malicious
|
|
validators. Ideally, a threshold signature would be used, yet that would require
|
|
a threshold key (which would require authentication by a MuSig signature). A
|
|
MuSig signature which specifies the signing set (or rather, the excluded
|
|
signers) achieves the most efficiency.
|
|
|
|
While that resolves the on-chain behavior, the Tributary also has to perform
|
|
exclusion. This has the following forms:
|
|
|
|
1) Rejecting further transactions (required)
|
|
2) Rejecting further participation in Tendermint
|
|
|
|
With regards to rejecting further participation in Tendermint, it's *ideal* to
|
|
remove the validator from the list of validators. Each validator removed from
|
|
participation, yet not from the list of validators, increases the likelihood of
|
|
the network failing to form consensus.
|
|
|
|
With regards to the economic security, an honest 67% may remove a faulty
|
|
(explicitly or simply offline) 33%, letting 67% of the remaining 67% (4/9ths)
|
|
take control of the associated private keys. In such a case, the malicious
|
|
parties are defined as the 4/9ths of validators with access to the private key
|
|
and the 33% removed (who together form >67% of the originally intended
|
|
validator set and have presumably provided enough stake to cover losses).
|