From 51e2af1156c89ee750c13c36962b34c4ac861dec Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 6 Sep 2023 15:26:15 +0200 Subject: [PATCH 01/20] save draft --- ...r-005-cryptographic-equivocation-verification.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index dac41b912e..a783ad1a3a 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -7,6 +7,7 @@ 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 ## Status @@ -73,6 +74,18 @@ the light client isn’t expired. After having successfully verified a misbehaviour, the endpoint will execute the jailing and slashing of the malicious validators similarly as in the evidence module. + +### Double Signing + +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 for each block height, with multiple rounds of voting per height, and voting twice in the same round is strictly prohibited. + +Explain the votes data structure + + +## Decision + + ### Current limitations: - This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. From 01c06f68df8dd4e58de3ad8d90d2dda86887eca3 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Thu, 7 Sep 2023 14:55:59 +0200 Subject: [PATCH 02/20] draft --- ...cryptographic-equivocation-verification.md | 26 ++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index a783ad1a3a..54e3efc141 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -80,12 +80,36 @@ After having successfully verified a misbehaviour, the endpoint will execute the 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 for each block height, with multiple rounds of voting per height, and voting twice in the same round is strictly prohibited. -Explain the votes data structure +- How equivocations are detected ? +- How are they reported ? + + +- How it is verified ? + - note on data loss through ABCI + +How are the validators punished in consequence ? ## Decision + - We will introduce a new endpoint: handling a SubmitConsumerDoubleVote message + + - 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 + + + + + ### Current limitations: - This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. From 6cb68109101de7a5948711d7ec572d30c9c88093 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 11 Sep 2023 13:47:39 +0200 Subject: [PATCH 03/20] save changes --- ...cryptographic-equivocation-verification.md | 55 +++++++++++++++---- 1 file changed, 45 insertions(+), 10 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 54e3efc141..fd0d2c7080 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -7,7 +7,7 @@ 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 +* 6/9/23: Add double signing attacks handling ## Status @@ -20,7 +20,8 @@ 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. -For the first stage of this work, we will only handle light client attacks. +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. + ### Light Client Attack @@ -77,23 +78,52 @@ After having successfully verified a misbehaviour, the endpoint will execute the ### Double Signing -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. +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. -- How equivocations are detected ? +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). -- How are they reported ? +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). -- How it is verified ? - - note on data loss through ABCI +## Decision -How are the validators punished in consequence ? +In the second iteration of this feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( + ctx sdk.Context, + evidence *tmtypes.DuplicateVoteEvidence, + 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. + + 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. + + 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. + + + 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. -## Decision - - We will introduce a new endpoint: handling a SubmitConsumerDoubleVote message +- 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 @@ -125,6 +155,11 @@ 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)). +- Since the validators are currently, only jail for the first iteration + of this work the evidence age is obsolete i.e. + + 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 ### Positive From 40e9fc691194c4af62600dc9d6512550328eebe0 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 11 Sep 2023 15:35:00 +0200 Subject: [PATCH 04/20] first draft --- ...cryptographic-equivocation-verification.md | 79 ++++++------------- 1 file changed, 25 insertions(+), 54 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index fd0d2c7080..d744d16f74 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/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,53 +98,21 @@ 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 @@ -152,13 +120,15 @@ is sent to the provider. Upon receiving the packet, the provider maps the consum 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) From a0dfe54a6ce12769d9a7cd234c0c8ac0d11c1551 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 11 Sep 2023 16:43:29 +0200 Subject: [PATCH 05/20] typo --- ...cryptographic-equivocation-verification.md | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index d744d16f74..26e899d754 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -84,11 +84,17 @@ A double signing attack, also known as an equivocation, 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`](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). - -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). + 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 chain ID 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)). + +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) in the SDK evidence module). ## Decision @@ -97,17 +103,24 @@ In the second iteration of this feature, we will introduce a new endpoint `Handl evidence *tmtypes.DuplicateVoteEvidence, chainID string, pubkey cryptotypes.PubKey)`. - - 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 `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. + 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. - 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. + We will define a new [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) 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 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) in the SDK evidence module. +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: From d0dfe4490f774b68fabd3cc9980b91b01b4ca7b2 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 11 Sep 2023 18:18:41 +0200 Subject: [PATCH 06/20] typo --- ...cryptographic-equivocation-verification.md | 47 ++++++++++--------- 1 file changed, 26 insertions(+), 21 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 26e899d754..ea3a426922 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -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, we will add the double signing attack handling. +In addition, 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 @@ -83,18 +83,17 @@ A double signing attack, also known as an equivocation, 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 +When a node observes two votes from the same peer, it will use these two votes to create 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 chain ID 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)). + Each node will then verify the evidence according to the Tendermint rules that define a valid double signing infraction, and based on this verification, + Note that validators sign their votes. This implies that the vote signatures in evidence must be successfully verified using the public key of the misbehaving validators, along with the ChainID of the chain where the infraction occurre (see [Tendermint equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). 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) in the SDK evidence module). + 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) + in the SDK evidence module). ## Decision @@ -106,39 +105,45 @@ In the second iteration of this feature, we will introduce a new endpoint `Handl 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 [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) message to report double voting evidences observed +We will define a new + [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) + message to report a double voting evidence 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). + referred to as [`infraction_block_header`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/txproto#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 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, +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) in the SDK evidence module). +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: - 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. + 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. -- For the same reasons mentioned above: a double singing evidence age can't be checked using either its infraction height or -its unsigned timestamp. +- For the same reasons explained above, the age of a consumer double signing evidence can't be verified, + either using its infraction height nor 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)). +to avoid being slashed on the provider ([see comment](https://github.com/cosmos/interchain-security/pull/1232#issuecomment-1693127641)). - 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)). From be308d863dbf9eea84cf60b4e7f25e83168687f1 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Tue, 12 Sep 2023 16:29:57 +0200 Subject: [PATCH 07/20] last changes --- ...cryptographic-equivocation-verification.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index ea3a426922..753a116b99 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -20,8 +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. -In addition, 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. - +The feature will be implemented in two parts, each with its dedicated endpoint. One endpoint will handle light client attacks, while the other will handle double signing attacks. ### Light Client Attack @@ -62,7 +61,7 @@ light client, halting any further trust in or updating of its states. ## Decision -In the first iteration of the feature, we will introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. +In the first part of the feature, we will introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. The main idea is to leverage the current IBC misbehaviour handling and update it to solely jail and slash the validators that performed a light client attack. This update will be made under the assumption that the chain connected via this light client share the same validator set, as it is the case with Replicated Security. @@ -76,7 +75,7 @@ the light client isn’t expired. After having successfully verified a misbehaviour, the endpoint will execute the jailing and slashing of the malicious validators similarly as in the evidence module. -### Double Signing +### Double Signing Attack 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. @@ -87,17 +86,17 @@ When a node observes two votes from the same peer, it will use these two votes t 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 double signing infraction, and based on this verification, - Note that validators sign their votes. This implies that the vote signatures in evidence must be successfully verified using the public key of the misbehaving validators, along with the ChainID of the chain where the infraction occurre (see [Tendermint equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). + Each node will then verify the evidence according to the Tendermint rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. + During the evidence verification process, the signatures of the conflicting votes must be verified successfully. + Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [Tendermint equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). 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) - in the SDK evidence module). + (see [handleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/19389505643500b25a5efeb02715c3deef9b6ede/x/evidence/keeper/infraction.go#L27C17-L27C43)). ## Decision -In the second iteration of this feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( +In the second part of the feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( ctx sdk.Context, evidence *tmtypes.DuplicateVoteEvidence, chainID string, @@ -108,16 +107,16 @@ In the second iteration of this feature, we will introduce a new endpoint `Handl We will define a new [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) message to report a double voting evidence observed - on a consumer chain to the endpoint on the provider chain. This message will contain two fields: - the double signing evidence + on a consumer chain to the endpoint of the provider chain. This message will contain two fields: + a 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, + and a 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/txproto#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 that equivocations will be verified by using the same conditions than in the Tendermint +Note that double signing evidence 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. + method, with the exception that its age 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. @@ -139,7 +138,7 @@ To explain the technical reasons behind this limitation, let's recap the initial could be corrupted and therefore cannot be used for slashing purposes. - For the same reasons explained above, the age of a consumer double signing evidence can't be verified, - either using its infraction height nor its unsigned timestamp. + either using 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 @@ -152,7 +151,8 @@ to avoid being slashed on the provider ([see comment](https://github.com/cosmos/ ### Positive -- After this ADR is applied, it will be possible for the provider chain to tombstone validators who committed a light client attack. +- After this ADR is applied, it will be possible for the provider chain to jail validators who committed + light client or double signing attacks. ### Negative From b90477c140edda268396b3c044d0034e62990f0f Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Tue, 12 Sep 2023 16:39:07 +0200 Subject: [PATCH 08/20] change TM to Comet --- ...cryptographic-equivocation-verification.md | 83 +++++++++---------- 1 file changed, 40 insertions(+), 43 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 753a116b99..21bdfb0d3c 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -78,53 +78,50 @@ After having successfully verified a misbehaviour, the endpoint will execute the ### Double Signing Attack 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 observes two votes from the same peer, it will use these two votes to create - 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 double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. - During the evidence verification process, the signatures of the conflicting votes must be verified successfully. - Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [Tendermint equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). - -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)). +occurs when a validator sends two different votes for a block in the same round of a consensus instance. +The CometBFT 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 observes two votes from the same peer, it will use these two votes to create +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 [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L25)). +Each node will then verify the evidence according to the CometBFT rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. +During the evidence verification process, the signatures of the conflicting votes must be verified successfully. +Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). + +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 In the second part of the feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( - ctx sdk.Context, - evidence *tmtypes.DuplicateVoteEvidence, - chainID string, - pubkey cryptotypes.PubKey)`. - 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. +ctx sdk.Context, evidence *tmtypes.DuplicateVoteEvidence, chainID string, pubkey cryptotypes.PubKey)`. +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 - [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) - message to report a double voting evidence observed - on a consumer chain to the endpoint of the provider chain. This message will contain two fields: - a double signing evidence - [`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) - and a 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/txproto#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. +We will define a new +[`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) +message to report a double voting evidence observed +on a consumer chain to the endpoint of the provider chain. This message will contain two fields: +a double signing evidence +[`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) +and a 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/txproto#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 that double signing evidence 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 its age 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. +Note that double signing evidence will be verified by using the same conditions than in the CometBFT +[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) +method, with the exception that its age 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) - in the SDK evidence module). +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: @@ -137,8 +134,8 @@ To explain the technical reasons behind this limitation, let's recap the initial 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. -- For the same reasons explained above, the age of a consumer double signing evidence can't be verified, - either using its infraction height or its unsigned timestamp. +- For the same reasons explained above, the age of a consumer double signing evidence can't be verified, +either using 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 @@ -151,8 +148,8 @@ to avoid being slashed on the provider ([see comment](https://github.com/cosmos/ ### Positive -- After this ADR is applied, it will be possible for the provider chain to jail validators who committed - light client or double signing attacks. +- After this ADR is applied, it will be possible for the provider chain to jail validators who committed +light client or double signing attacks. ### Negative From 49e6e9748826a72bd9fdf56bea88a90508f82f12 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 09:59:48 +0200 Subject: [PATCH 09/20] fix date --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 21bdfb0d3c..d74cf1720a 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -7,7 +7,7 @@ title: Cryptographic verification of equivocation evidence ## Changelog * 5/1/2023: First draft * 7/23/2023: Add light client attacks handling -* 6/9/2023: Add double signing attacks handling +* 9/6/2023: Add double signing attacks handling ## Status From 75ae7d2eed7963c5a5fcaf599e63d2c1012b8d8b Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 15:19:46 +0200 Subject: [PATCH 10/20] fix links --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index d74cf1720a..bbfd774d2e 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -85,10 +85,10 @@ to determine the next block, and voting twice in the same round is strictly proh When a node observes two votes from the same peer, it will use these two votes to create 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 [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L25)). +(see [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#detection)). Each node will then verify the evidence according to the CometBFT rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. During the evidence verification process, the signatures of the conflicting votes must be verified successfully. -Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#L95)). +Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#verification)). 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 @@ -108,7 +108,7 @@ on a consumer chain to the endpoint of the provider chain. This message will con a double signing evidence [`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) and a 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/txproto#L77). +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 that double signing evidence will be verified by using the same conditions than in the CometBFT From 396b18b3e586fec27110456721f0d9938e92777d Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 15:59:59 +0200 Subject: [PATCH 11/20] address comments --- ...r-005-cryptographic-equivocation-verification.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index bbfd774d2e..900d5fb213 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -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. -The feature will be implemented in two parts, each with its dedicated endpoint. One endpoint will handle light client attacks, while the other will handle double signing attacks. +The feature is implemented in two parts, each with its dedicated endpoint. One endpoint handles light client attacks, while the other handles double signing attacks. ### Light Client Attack @@ -77,10 +77,11 @@ After having successfully verified a misbehaviour, the endpoint will execute the ### Double Signing Attack -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 CometBFT 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. +A double signing attack, also known as equivocation, +occurs when a validator votes for two different blocks in the same round of the CometBFT consensus. +This consensus mechanism operates with multiple voting rounds at each block height, +and it strictly prohibits sending two votes of the same type during a round +(see [CometBFT State Machine Overview](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/consensus.md#state-machine-overview)). When a node observes two votes from the same peer, it will use these two votes to create a [`DuplicateVoteEvidence`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/types/evidence.go#L35) @@ -88,7 +89,7 @@ evidence and gossip it to the other nodes in the network (see [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#detection)). Each node will then verify the evidence according to the CometBFT rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. During the evidence verification process, the signatures of the conflicting votes must be verified successfully. -Note that this is achieved using the public key of the misbehaving validator, along with the `ChainID` of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#verification)). +Note that this is achieved using the public key of the misbehaving validator, along with the chain ID of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#verification)). 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 From da6bda21eeefe828d0e4b4370d24a27c5aa7d28e Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 16:58:16 +0200 Subject: [PATCH 12/20] add ADR link --- .../docs/adrs/adr-005-cryptographic-equivocation-verification.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 900d5fb213..cbe3792d07 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -162,3 +162,4 @@ light client or double signing attacks. * [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) +* [ADR on equivocation slashing](https://github.com/cosmos/interchain-security/blob/main/docs/docs/adrs/adr-013-equivocation-slashing.md) From 0bed27ca5b837e4928cefd44913e3248bc8bfd90 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 17:08:54 +0200 Subject: [PATCH 13/20] change cometBFT and cosmos SDK refs to specific version --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index cbe3792d07..52cfcf920a 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -84,7 +84,7 @@ and it strictly prohibits sending two votes of the same type during a round (see [CometBFT State Machine Overview](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/consensus.md#state-machine-overview)). When a node observes two votes from the same peer, it will use these two votes to create -a [`DuplicateVoteEvidence`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/types/evidence.go#L35) +a [`DuplicateVoteEvidence`](https://github.com/cometbft/cometbft/blob/v0.34.28/types/evidence.go#L35) evidence and gossip it to the other nodes in the network (see [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#detection)). Each node will then verify the evidence according to the CometBFT rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. From 7cc61318ef4c517bd72a404e3148eeaf39c223b4 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 20 Sep 2023 17:28:58 +0200 Subject: [PATCH 14/20] fix links --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 52cfcf920a..b3f22a3174 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -93,7 +93,7 @@ Note that this is achieved using the public key of the misbehaving validator, al 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)). +(see [handleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/v0.45.16-ics-lsm/x/evidence/keeper/infraction.go#L263)). ## Decision From facd7757700ae66c41c674f3a05f8e70eb74886e Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 11:38:57 +0200 Subject: [PATCH 15/20] Update docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md Co-authored-by: Marius Poke --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index b3f22a3174..fc01a6d1de 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -115,9 +115,7 @@ The latter will provide the malicious validator's public key and the chain ID re Note that double signing evidence will be verified by using the same conditions than in the CometBFT [`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) method, with the exception that its age 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. +More 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 From 9756daa454d7dab7c883d4fa42d89fef438e888a Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 08:58:06 +0200 Subject: [PATCH 16/20] update structure --- ...cryptographic-equivocation-verification.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index fc01a6d1de..c09ba7ac77 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -58,23 +58,6 @@ a chain will first verify whether these headers would have convinced its light c the header states against the light client consensus states (see [IBC misbehaviour handler](https://github.com/cosmos/ibc-go/blob/2b7c969066fbcb18f90c7f5bd256439ca12535c7/modules/light-clients/07-tendermint/types/misbehaviour_handle.go#L101)). If the misbehaviour is successfully verified, the chain will then "freeze" the light client, halting any further trust in or updating of its states. - -## Decision - -In the first part of the feature, we will introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. -The main idea is to leverage the current IBC misbehaviour handling and update it to solely jail and slash the validators that -performed a light client attack. This update will be made under the assumption that the chain connected via this light client -share the same validator set, as it is the case with Replicated Security. - -This endpoint will reuse the IBC client libraries to verify that the misbehaviour headers would have fooled the light client. -Additionally, it’s crucial that the endpoint logic result in the slashing and jailing of validators under the same conditions -as a light client agent detector. Therefore, the endpoint will ensure that the two conditions are met: -the headers in the misbehaviour message have the same block height, and -the light client isn’t expired. - -After having successfully verified a misbehaviour, the endpoint will execute the jailing and slashing of the malicious validators similarly as in the evidence module. - - ### Double Signing Attack A double signing attack, also known as equivocation, @@ -95,8 +78,26 @@ Once a double signing evidence is committed to a block, the consensus layer will The application will, in turn, punish the malicious validator through jailing, tombstoning and slashing (see [handleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/v0.45.16-ics-lsm/x/evidence/keeper/infraction.go#L263)). + ## Decision +### Light Client Attack + +In the first part of the feature, we will introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. +The main idea is to leverage the current IBC misbehaviour handling and update it to solely jail and slash the validators that +performed a light client attack. This update will be made under the assumption that the chain connected via this light client +share the same validator set, as it is the case with Replicated Security. + +This endpoint will reuse the IBC client libraries to verify that the misbehaviour headers would have fooled the light client. +Additionally, it’s crucial that the endpoint logic result in the slashing and jailing of validators under the same conditions +as a light client agent detector. Therefore, the endpoint will ensure that the two conditions are met: +the headers in the misbehaviour message have the same block height, and +the light client isn’t expired. + +After having successfully verified a misbehaviour, the endpoint will execute the jailing and slashing of the malicious validators similarly as in the evidence module. + +### Double Signing Attack + In the second part of the feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( ctx sdk.Context, evidence *tmtypes.DuplicateVoteEvidence, chainID string, pubkey cryptotypes.PubKey)`. Simply put, the handling logic will verify a double signing evidence against a provided @@ -117,7 +118,6 @@ Note that double signing evidence will be verified by using the same conditions method, with the exception that its age won't be checked. More 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) in the SDK evidence module). From 57e353c767ed4884a587141be1f912da23eb5977 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 12:10:02 +0200 Subject: [PATCH 17/20] save changes --- ...cryptographic-equivocation-verification.md | 39 ++++++++++--------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index c09ba7ac77..7ae3d29d77 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -83,42 +83,42 @@ The application will, in turn, punish the malicious validator through jailing, t ### Light Client Attack -In the first part of the feature, we will introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. +In the first part of the feature, we introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. The main idea is to leverage the current IBC misbehaviour handling and update it to solely jail and slash the validators that -performed a light client attack. This update will be made under the assumption that the chain connected via this light client +performed a light client attack. Note that in this context, we assume that the chains connected via a light client share the same validator set, as it is the case with Replicated Security. -This endpoint will reuse the IBC client libraries to verify that the misbehaviour headers would have fooled the light client. -Additionally, it’s crucial that the endpoint logic result in the slashing and jailing of validators under the same conditions -as a light client agent detector. Therefore, the endpoint will ensure that the two conditions are met: +This endpoint reuses the IBC client libraries to verify that the misbehaviour headers would have fooled the light client. +Additionally, it’s crucial that the endpoint logic results in the slashing and jailing of validators under the same conditions +as a light client agent detector. Therefore, the endpoint ensures that the two conditions are met: the headers in the misbehaviour message have the same block height, and the light client isn’t expired. -After having successfully verified a misbehaviour, the endpoint will execute the jailing and slashing of the malicious validators similarly as in the evidence module. +After having successfully verified a misbehaviour, the endpoint executes the jailing and slashing of the malicious validators similarly as in the evidence module. ### Double Signing Attack -In the second part of the feature, we will introduce a new endpoint `HandleConsumerDoubleVoting( +In the second part of the feature, we introduce a new endpoint `HandleConsumerDoubleVoting( ctx sdk.Context, evidence *tmtypes.DuplicateVoteEvidence, chainID string, pubkey cryptotypes.PubKey)`. -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. +Simply put, the handling logic verifies a double signing evidence against a provided +public key and chain ID and, if successful, executes the jailing of the malicious validator who double voted. -We will define a new +We define a new [`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) message to report a double voting evidence observed -on a consumer chain to the endpoint of the provider chain. This message will contain two fields: +on a consumer chain to the endpoint of the provider chain. This message contains two fields: a double signing evidence [`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) and a 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. +The latter provides the malicious validator's public key and the chain ID required to verify the signature of the votes contained in the evidence. -Note that double signing evidence will be verified by using the same conditions than in the CometBFT -[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) -method, with the exception that its age won't be checked. +Note that double signing evidence is not verified using the same conditions than in the implementation CometBFT +[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) +method. Specifically, we do not check that the evidence hasn't expired. More 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 +Upon a successful equivocation verification, the misbehaving validator is 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). @@ -134,7 +134,8 @@ To explain the technical reasons behind this limitation, let's recap the initial could be corrupted and therefore cannot be used for slashing purposes. - For the same reasons explained above, the age of a consumer double signing evidence can't be verified, -either using its infraction height or its unsigned timestamp. +either using its infraction height or its unsigned timestamp. This means that the jailing behavior has changed; +a validator may be jailed due to some "old" evidence on a consumer, while it wouldn't get jailed if the consumer had been a standalone chain. - 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 @@ -147,8 +148,8 @@ to avoid being slashed on the provider ([see comment](https://github.com/cosmos/ ### Positive -- After this ADR is applied, it will be possible for the provider chain to jail validators who committed -light client or double signing attacks. +- It is now possible for the provider chain to jail validators who committed +light client or double signing attacks on a consumer chain. ### Negative From 584367a029a2b9ddd39309615ad47134bcf0e0ec Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 14:08:06 +0200 Subject: [PATCH 18/20] rework double signing limitations --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 7ae3d29d77..220ded0f2b 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -113,9 +113,8 @@ and a 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 provides the malicious validator's public key and the chain ID required to verify the signature of the votes contained in the evidence. -Note that double signing evidence is not verified using the same conditions than in the implementation CometBFT -[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) -method. Specifically, we do not check that the evidence hasn't expired. +Note that double signing evidence is not verified using the same conditions as in the implementation CometBFT (see +[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) method). Specifically, we do not check that the evidence hasn't expired. More details can be found in the ["Current limitations"](#current-limitations) section below. Upon a successful equivocation verification, the misbehaving validator is jailed for the maximum time From 2f2aaf9c964e54d592e900934c7505fb70c46377 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 14:34:34 +0200 Subject: [PATCH 19/20] fix links --- ...cryptographic-equivocation-verification.md | 25 ++++++++----------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 220ded0f2b..023ea8a224 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -64,15 +64,15 @@ A double signing attack, also known as equivocation, occurs when a validator votes for two different blocks in the same round of the CometBFT consensus. This consensus mechanism operates with multiple voting rounds at each block height, and it strictly prohibits sending two votes of the same type during a round -(see [CometBFT State Machine Overview](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/consensus.md#state-machine-overview)). +(see [CometBFT State Machine Overview](https://github.com/cometbft/cometbft/blob/v0.34.28/spec/consensus/consensus.md#state-machine-overview)). When a node observes two votes from the same peer, it will use these two votes to create a [`DuplicateVoteEvidence`](https://github.com/cometbft/cometbft/blob/v0.34.28/types/evidence.go#L35) evidence and gossip it to the other nodes in the network -(see [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#detection)). +(see [CometBFT equivocation detection](https://github.com/cometbft/cometbft/blob/v0.34.28/spec/consensus/evidence.md#detection)). Each node will then verify the evidence according to the CometBFT rules that define a valid double signing infraction, and based on this verification, they will decide whether to add the evidence to a block. During the evidence verification process, the signatures of the conflicting votes must be verified successfully. -Note that this is achieved using the public key of the misbehaving validator, along with the chain ID of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/spec/consensus/evidence.md#verification)). +Note that this is achieved using the public key of the misbehaving validator, along with the chain ID of the chain where the infraction occurred (see [CometBFT equivocation verification](https://github.com/cometbft/cometbft/blob/v0.34.28/spec/consensus/evidence.md#verification)). 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 @@ -85,8 +85,8 @@ The application will, in turn, punish the malicious validator through jailing, t In the first part of the feature, we introduce a new endpoint: `HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour ibctmtypes.Misbehaviour)`. The main idea is to leverage the current IBC misbehaviour handling and update it to solely jail and slash the validators that -performed a light client attack. Note that in this context, we assume that the chains connected via a light client -share the same validator set, as it is the case with Replicated Security. +performed a light client attack. Note that in this context, we assume that chains connected via a light client +share the same validator set, as is the case with Replicated Security. This endpoint reuses the IBC client libraries to verify that the misbehaviour headers would have fooled the light client. Additionally, it’s crucial that the endpoint logic results in the slashing and jailing of validators under the same conditions @@ -104,21 +104,19 @@ Simply put, the handling logic verifies a double signing evidence against a prov public key and chain ID and, if successful, executes the jailing of the malicious validator who double voted. We define a new -[`MsgSubmitConsumerDoubleVoting`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L69C9-L69C38) -message to report a double voting evidence observed +`MsgSubmitConsumerDoubleVoting` message to report a double voting evidence observed on a consumer chain to the endpoint of the provider chain. This message contains two fields: a double signing evidence -[`duplicate_vote_evidence`](https://github.com/cosmos/interchain-security/blob/20b0e35a6d45111bd7bfeb6845417ba752c67c60/proto/interchain_security/ccv/provider/v1/tx.proto#L75) -and a 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). +`duplicate_vote_evidence` and a light client header for the infraction block height, +referred to as `infraction_block_header`. The latter provides the malicious validator's public key and the chain ID required to verify the signature of the votes contained in the evidence. Note that double signing evidence is not verified using the same conditions as in the implementation CometBFT (see -[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/verify.go#L19) method). Specifically, we do not check that the evidence hasn't expired. +[`verify(evidence types.Evidence)`](https://github.com/cometbft/cometbft/blob/v0.34.28/evidence/verify.go#L19) method). Specifically, we do not check that the evidence hasn't expired. More details can be found in the ["Current limitations"](#current-limitations) section below. Upon a successful equivocation verification, the misbehaving validator is jailed for the maximum time -(see [DoubleSignJailEndTime](https://github.com/cosmos/cosmos-sdk/blob/cd272d525ae2cf244c53433b6eb1e835783d7531/x/evidence/types/params.go) +(see [DoubleSignJailEndTime](https://github.com/cosmos/cosmos-sdk/blob/v0.45.16-ics-lsm/x/evidence/types/params.go#L11) in the SDK evidence module). @@ -133,8 +131,7 @@ To explain the technical reasons behind this limitation, let's recap the initial could be corrupted and therefore cannot be used for slashing purposes. - For the same reasons explained above, the age of a consumer double signing evidence can't be verified, -either using its infraction height or its unsigned timestamp. This means that the jailing behavior has changed; -a validator may be jailed due to some "old" evidence on a consumer, while it wouldn't get jailed if the consumer had been a standalone chain. +either using its infraction height or its unsigned timestamp. Note that changes the jailing behaviour, potentially leading to a validator's jailing based on some "old" evidence from a consumer, which wouldn't occur if the consumer were a standalone chain. - 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 From 0b29cb2144a388f56b1da3464937627da80eeddf Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Mon, 25 Sep 2023 14:52:32 +0200 Subject: [PATCH 20/20] fix IBC links --- ...05-cryptographic-equivocation-verification.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 023ea8a224..8bd68dfcaf 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -43,19 +43,19 @@ The types of light client attacks are defined by analyzing the differences betwe There are three types of light client attacks: lunatic attack, equivocation attack, and amnesia attack. For details, see the [CometBFT specification](https://github.com/cometbft/cometbft/blob/main/spec/light-client/attacks/notes-on-evidence-handling.md#evidence-handling). -When a light client agent detects two conflicting headers, it will initially verify their traces (see [cometBFT detector](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/light/detector.go#L28)) using its primary and witness nodes. +When a light client agent detects two conflicting headers, it will initially verify their traces (see [cometBFT detector](https://github.com/cometbft/cometbft/blob/v0.34.28/light/detector.go#L28)) using its primary and witness nodes. If these headers pass successful verification, the Byzantine validators will be identified based on the header's commit signatures -and the type of light client attack. The agent will then transmit this information to its nodes using a [`LightClientAttackEvidence`](https://github.com/cometbft/cometbft/blob/feed0ddf564e113a840c4678505601256b93a8bc/docs/architecture/adr-047-handling-evidence-from-light-client.md) to be eventually voted on and added to a block. +and the type of light client attack. The agent will then transmit this information to its nodes using a [`LightClientAttackEvidence`](https://github.com/cometbft/cometbft/blob/v0.34.28/spec/consensus/evidence.md#light-client-attacks) evidence to be eventually voted on and added to a block. Note that from a light client agent perspective, it is not possible to establish whether a primary or a witness node, or both, are malicious. -Therefore, it will create and send two `LightClientAttackEvidence`: one against the primary (sent to the witness), and one against the witness (sent to the primary). -Both nodes will then verify it before broadcasting it and adding it to the [evidence pool](https://github.com/cometbft/cometbft/blob/2af25aea6cfe6ac4ddac40ceddfb8c8eee17d0e6/evidence/pool.go#L28). -If a `LightClientAttackEvidence` is finally committed to a block, the chain's evidence module will execute it, resulting in the jailing and the slashing of the validators responsible for the light client attack. +Therefore, it will create and send two evidences: one against the primary (sent to the witness), and one against the witness (sent to the primary). +Both nodes will then verify it before broadcasting it and adding it to the [evidence pool](https://github.com/cometbft/cometbft/blob/v0.34.28/evidence/pool.go#L28). +If an evidence is finally committed to a block, the chain's evidence module will execute it, resulting in the jailing and the slashing of the validators responsible for the light client attack. -Light clients are a core component of IBC. In the event of a light client attack, IBC relayers notify the affected chains by submitting an [IBC misbehavior message](https://github.com/cosmos/ibc-go/blob/2b7c969066fbcb18f90c7f5bd256439ca12535c7/proto/ibc/lightclients/tendermint/v1/tendermint.proto#L79). -A misbehavior message includes the conflicting headers that constitute a `LightClientAttackEvidence`. Upon receiving such a message, +Light clients are a core component of IBC. In the event of a light client attack, IBC relayers notify the affected chains by submitting an [IBC misbehavior message](https://github.com/cosmos/ibc-go/blob/v4.4.2/proto/ibc/lightclients/tendermint/v1/tendermint.proto#L79). +A misbehavior message includes the conflicting headers that constitute a light client attack evidence. Upon receiving such a message, a chain will first verify whether these headers would have convinced its light client. This verification is achieved by checking -the header states against the light client consensus states (see [IBC misbehaviour handler](https://github.com/cosmos/ibc-go/blob/2b7c969066fbcb18f90c7f5bd256439ca12535c7/modules/light-clients/07-tendermint/types/misbehaviour_handle.go#L101)). If the misbehaviour is successfully verified, the chain will then "freeze" the +the header states against the light client consensus states (see [IBC misbehaviour handler](https://github.com/cosmos/ibc-go/blob/v4.4.2/modules/light-clients/07-tendermint/types/misbehaviour_handle.go#L24)). If the misbehaviour is successfully verified, the chain will then "freeze" the light client, halting any further trust in or updating of its states. ### Double Signing Attack