From 4e6c61b435addb92532b4a840522e8a74c92b370 Mon Sep 17 00:00:00 2001 From: Jehan Date: Mon, 1 May 2023 09:10:29 -0700 Subject: [PATCH] Create adr-005-cryptographic-equivocation-verification.md --- ...cryptographic-equivocation-verification.md | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md new file mode 100644 index 0000000000..2f10da79e1 --- /dev/null +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 4 +title: Cryptographic verification of equivocation evidence +--- +# ADR 005: Cryptographic verification of equivocation evidence + +## Changelog +* 5/1/2023: First draft + +## Status + +Proposed + +## Context + +Currently, we use a governance proposal to slash validators for equivocation (double signing and light client attacks). This has the downside that it takes 2 weeks for the proposal to be approved, effectively reducing the unbonding period in some respects. This does not lead to any pressing real-world security concerns, but since it involves the basis of proof of stake, it would be good to get consumer chain slashing back to parity as soon as possible. + +This ADR proposes a system to slash validators automatically for equivocation, immediately upon the provider chain's receipt of the evidence. Another thing to note is that we intend to introduce this system in stages, since even the partial ability to slash and/or tombstone is a strict improvement in security. + +## Decision + +For the first stage of this work, we will only handle light client attacks, since there is already code available in the IBC libraries to handle them. We will introduce a new endpoint- `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. This endpoint takes evidence of a light client attack of the type used by IBC. It then uses various methods from IBC to cryptographically verify the evidence. It then tombstones validators based on this evidence. + +Current limitations: + +- This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. +- Since a special endpoint must be used to submit the evidence, the evidence is not automatically submitted by Hermes. In the future, we may make Hermes submit the evidence, or use a hook provided by IBC to run the code automatically when evidence is submitted to the IBC client. In the current state, someone will need to submit the evidence manually in the 3 weeks after a light client attack has occured. +- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. + +## Consequences + +After this ADR is applied, it will be possible for the provider chain to tombstone validators who committed a light client attack. + +## References + +* [{reference link}](https://github.com/cosmos/interchain-security/pull/826/files)