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

docs: add ADR for Partial Set Security #1584

Merged
merged 26 commits into from
Jan 31, 2024
Merged
Changes from 1 commit
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
3c90fc8
added Partial Set Security ADR
insumity Jan 22, 2024
a86272d
fix indentation
insumity Jan 22, 2024
4a418c8
add on AllocateTokens
insumity Jan 22, 2024
3bdb04b
fixed MsgOptOut to not have a delay and added different way to opt in
insumity Jan 23, 2024
bedb15a
added some clarifications
insumity Jan 23, 2024
0a354ae
added note on downtime
insumity Jan 23, 2024
f3f6d01
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 25, 2024
66122ad
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 25, 2024
84e2a8f
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 26, 2024
9989e54
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
99182df
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
fcf8f6b
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
53113c1
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
3bdfa2c
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
0f9bd8b
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 29, 2024
a6c705b
updated based on comments
insumity Jan 29, 2024
9ffa1e2
remove fraud votes
insumity Jan 29, 2024
45c796d
smaller updates
insumity Jan 29, 2024
0b56b0f
add consumer key in the opt in message
insumity Jan 29, 2024
4ccb925
remove partial set computation and reward pseudocode
insumity Jan 30, 2024
5ac5b12
changed top_N_fraction to int
insumity Jan 30, 2024
537da61
nit changes
insumity Jan 30, 2024
01a7097
remove fraction
insumity Jan 30, 2024
3dea3ff
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 31, 2024
c1bd9b8
Update docs/docs/adrs/adr-015-partial-set-security.md
insumity Jan 31, 2024
2e5dd4c
applied some changes based on comments
insumity Jan 31, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
remove fraud votes
insumity committed Jan 29, 2024

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
commit 9ffa1e2cf3f777e61559ad21336cd9836b16e748
26 changes: 3 additions & 23 deletions docs/docs/adrs/adr-015-partial-set-security.md
Original file line number Diff line number Diff line change
@@ -268,30 +268,10 @@ Note that we would only distribute rewards to validators that are opted in but a
### Misbehaviour

#### Fraud votes
For fraud votes, we add a new type `FraudVoteProposal` similar to [EquivocationProposal](https://github.com/cosmos/interchain-security/pull/703). The time to detect incorrect execution evidence is 7 days (the same time as that of detecting a light client attack on a client with a `trustingPeriod` of 14 days); We have 7 days to detect an incorrect execution and then 14 days for the proposal to be accepted.
In an Opt In chain, a set of validators might attempt to perform an invalid-execution attack. To deter such potential attacks, PSS allows for the use of fraud votes.
A _fraud vote_ is a governance proposal that enables the slashing of validators that performed an invalid-execution attack.
Due to their inherent complexity, we intend to introduce fraud votes in a different ADR and at a future iteration of PSS.

##### When are fraud votes eligible?
Because fraud votes allow the slashing of a validator through a governance proposal, we are cautious on when a fraud vote is eligible and try to restrict their eligibility as much as possible to avoid an adversary proposing a bogus fraud vote.
As described earlier, because in Top N chains we consider that `N > 50%` we only consider validators that have opted in an Opt In chain. Fraud votes are also **only** intended to be used for **malicious** behaviour, for example, in a scenario similar to what [happened to Neutron](https://blog.neutron.org/neutron-halt-post-mortem-927dbe4540c8), validators should vote against slashing those validators.

#### Message
```protobuf
message FraudVoteProposal {
string title = 1;
string description = 2;

// validator that performed incorrect execution (consensus address on consumer chain)
Validator validator = 3;

// validator's vote contains BlockId on what was signed
Vote vote = 4;

// header for which the hash led to the blockId in the vote
Header header = 5;
}
```

The message includes the `vote` that was signed by the validator. Validators that vote on a fraud vote can look at the `BlockID` contained in a `vote` and the `appHash`, `lastResultHash`, etc. in the `header` (that led to this `BlockID`) to conclude whether the to-be-voted validator has performed incorrect execution or not.

#### Double signing
We do not change the way slashing for double signing and light client attacks functions. If a validator misbehaves on a consumer, then we slash that validator on the provider.