first draft

docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md

@@ -6,8 +6,8 @@ title: Cryptographic verification of equivocation evidence
 
 ## Changelog
 * 5/1/2023: First draft
-* 7/23/23: Add light client attacks handling
-* 6/9/23: Add double signing attacks handling
+* 7/23/2023: Add light client attacks handling
+* 6/9/2023: Add double signing attacks handling
 
 ## Status
 
@@ -20,7 +20,7 @@ Every proposal needs to go through a (two weeks) voting period before it can be
 Given a three-week unbonding period, this means that an equivocation proposal needs to be submitted within one week since the infraction occurred.
 
 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.
-Additionally, this feature will be implemented in two iterations: first we will start by handling light client attacks and secondly the double signing attack handling we be added.
+Additionally, this feature will be implemented in two iterations: first, we will start by handling light client attacks, and secondly, we will add the double signing attack handling.
 
 
 ### Light Client Attack
@@ -78,17 +78,17 @@ After having successfully verified a misbehaviour, the endpoint will execute the
 
 ### Double Signing
 
-A double signing attack, also known as an equivocation, happens when a validator sends two different votes for a block in the same round of a consensus instance.
-The Tendermint consensus operates for each block height, with multiple rounds of voting per height, and voting twice in the same round is strictly prohibited.
+A double signing attack, also known as an equivocation,
+ occurs when a validator sends two different votes for a block in the same round of a consensus instance.
+ The Tendermint consensus operates with multiple rounds of voting at each block height
+ to determine the next block, and voting twice in the same round is strictly prohibited.
 
 When a node detects two votes from the same peer, it will use these two votes to create
-a `DuplicateVoteEvidence` evidence and gossip it to the other nodes in the network, see [Tendermint equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L25). 
-Each node will then verify the evidence according to the Tendermint rules defining a valid equivocation, and decide on adding the evidence to a block, see [Tendermint equivocation verification] (https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95).
+a [`DuplicateVoteEvidence`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/types/evidence.go#L35) evidence and gossip it to the other nodes in the network, see [Tendermint equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L25). 
+Each node will then verify the evidence according to the Tendermint rules that define a valid equivocation, and based on this verification, they will decide whether to add the evidence to a block.
+ Note that validators sign their votes. This means that the votes in an evidence must be correctly signed. In addition, the ChainID of the chain where the infraction occurred is also used in the signature, see [Tendermint equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95).
 
-Note that validators sign their votes. It entails the the votes in a evidence must be correctly signed. In addition, the `ChainID` of the chain where the infraction occurred
-also used in the signature.
-
-Once an evidence is committed to a block, the consensus layer will report the equivocation to the evidence module of the Cosmos SDK application layer. The application will in its turn punish the malicious validator using jailing, tombstoning and slashing, see [handleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/19389505643500b25a5efeb02715c3deef9b6ede/x/evidence/keeper/infraction.go#L27C17-L27C43).
+Once a double signing evidence is committed to a block, the consensus layer will report the equivocation to the evidence module of the Cosmos SDK application layer. The application will, in turn, punish the malicious validator through jailing, tombstoning and slashing, see [handleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/19389505643500b25a5efeb02715c3deef9b6ede/x/evidence/keeper/infraction.go#L27C17-L27C43).
 
 ## Decision
 
@@ -98,67 +98,37 @@ In the second iteration of this feature, we will introduce a new endpoint `Handl
 	chainID string,
 	pubkey cryptotypes.PubKey)`. 
 
-  Simply put, the handling logic will verify a double signing evidence against a given
-  public key and chain Id and, if successful, execute the jailing of the malicious validator, which double voted.
+  Simply put, the handling logic will verify a double signing evidence against a provided
+  public key and chain ID and, if successful, execute the jailing of the malicious validator who double voted.
 
-  We will define a new `SubmitConsumerDoubleVoting` message to report double voting evidences observed on a consumer chain to the endpoint on the provider. This message will contain two fields: the double signing evidence `duplicate_vote_evidence` and the light client header for the infraction block height of the infraction `infraction_block_header`. The second field will provide the malicious validator public key and the chain Id required to verify the signature of the votes contained in the evidence.
+  We will define a new `MsgSubmitConsumerDoubleVoting` message to report double voting evidences observed on a consumer chain to the endpoint on the provider chain. This message will contain two fields: the double signing evidence [`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) and the light client header for the infraction block height, referred to as [`infraction_block_header`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L77). The latter will provide the malicious validator's public key and the chain ID required to verify the signature of the votes contained in the evidence.
 
-  Note equivocations will be verified using same rules than in Tendermint with the exception that
-  the ages of the evidence won't be checked. This is mainly due to the fact the feature will only jail validators for double signing. Since the jail time isn't doesn't depend on the evidence age, in opposite 
-  of slashing, the evidence can't be ignored. Additional details of this decision a provided in the [Current limitations](#current-limitations)section below.
+  Note that equivocations will be verified by using the same conditions than in the Tendermint [`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) method, with the exception that
+  the ages of the evidence won't be checked. This is primarily because for the first stage of this feature, the goal is to jail validators for double signing only. Since the jail time doesn't depend on the evidence's age, it can be ignored. More technical details can be found in the [Current limitations](#current-limitations) section below.
 
 
-  Upon a successful equivocation verification, the misbehaving validator will be jailed for the maximum time, see [DoubleSignJailEndTime](https://github.com/cosmos/cosmos-sdk/blob/cd272d525ae2cf244c53433b6eb1e835783d7531/x/evidence/types/params.go) the SDK evidence module.
-
-
-
-- The logic in brief
-  - verify equivocation 
-  - jail validators
-
-  - signature verification 
-    - chain Id is signed
-    - pubkey is used to verify signature
-
-
-- Details:
-  - how we verify the signature from consumer 
-
-
- - The message contain a DuplicateVoteEvidence with the votes and their signatures
-
- - The light client header at the infraction height infraction_block_header 
-
- - Verification is done as for tendermint using the validator pubkey and the chain ID received in the message
-
- - Note that since for this first iteration we will only slash validators so no voting power and infraction height timestamp / evidence age must is checked
-   since the time when the jailing is executed don't change anything jail forever - don't speak about slashing since we're doing it yet
-
-- Note that we change remove the tombstoning since it'd would prevent to get slash using governance proposal 
-
-
-
+  Upon a successful equivocation verification, the misbehaving validator will be jailed for the maximum time, see [DoubleSignJailEndTime](https://github.com/cosmos/cosmos-sdk/blob/cd272d525ae2cf244c53433b6eb1e835783d7531/x/evidence/types/params.go) in the SDK evidence module.
 
 
 ### Current limitations:
 
-- This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing.
-
-- We cannot derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them.
+- We cannot derive an infraction height from the evidence, so it is only possible to jail validators, not actually slash them.
 To explain the technical reasons behind this limitation, let's recap the initial consumer initiated slashing logic.
 In a nutshell, consumer heights are mapped to provider heights through VSCPackets, namely through the so called vscIDs.
 When an infraction occurs on the consumer, a SlashPacket containing the vscID obtained from mapping the consumer infraction height
 is sent to the provider. Upon receiving the packet, the provider maps the consumer infraction height to a local infraction height,
 which is used to slash the misbehaving validator. In the context of untrusted consumer chains, all their states, including vscIDs,
 could be corrupted and therefore cannot be used for slashing purposes.
 
-- Currently, the endpoint can only handle "equivocation" light client attacks. This is because the "lunatic" attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to define the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)).
+- For the same reasons mentioned above: a double singing evidence age can't be checked using either its infraction height or
+its unsigned timestamp.
 
+- In the first stage of this feature, validators are jailed indefinitely without being tombstoned.
+The underlying reason is that a malicious validator could take advantage of getting tombstoned 
+to avoid being slashed on the provider, ([see comment](https://github.com/cosmos/interchain-security/pull/1232#issuecomment-1693127641)). 
 
-- Since the validators are currently, only jail for the first iteration
-  of this work the evidence age is obsolete i.e.
+- Currently, the endpoint can only handle "equivocation" light client attacks. This is because the "lunatic" attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to define the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)).
 
-  The reason is two folded: first we can't derived the infraction height( see limitations below), secondly the evidence timestamp isn't signed so can be trusted.
 
 ## Consequences
 
@@ -174,4 +144,5 @@ could be corrupted and therefore cannot be used for slashing purposes.
 ## References
 
 * [ICS misbehaviour handling PR](https://github.com/cosmos/interchain-security/pull/826)
+* [Consumer double voting handler PR](https://github.com/cosmos/interchain-security/pull/1232)
 * [Architectural diagrams](https://docs.google.com/document/d/1fe1uSJl1ZIYWXoME3Yf4Aodvz7V597Ric875JH-rigM/edit#heading=h.rv4t8i6d6jfn)