Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update ADR-005 with consumer double voting #1283

Merged
merged 20 commits into from
Oct 9, 2023
Prev Previous commit
Next Next commit
address comments
sainoe committed Sep 20, 2023
commit 396b18b3e586fec27110456721f0d9938e92777d
sainoe marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -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,18 +77,19 @@ 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)).
sainoe marked this conversation as resolved.
Show resolved Hide resolved

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)
sainoe marked this conversation as resolved.
Show resolved Hide resolved
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)).
sainoe marked this conversation as resolved.
Show resolved Hide resolved
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)).
sainoe marked this conversation as resolved.
Show resolved Hide resolved

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