docs: Small tweaks to PSS adr for clarity #1619
Conversation
…ion when talking about attacks
github-actions
bot
added
C:Docs
|
|
||
| ### Negative | ||
| - A consumer chain does not receive the same economic security as with Replicated Security (assuming a value of `SoftOptOutThreshold` is `5%`), unless it is a Top N chain with `N >= 95%`. | ||
|
|
||
| * A consumer chain does not receive the same economic security as with Replicated Security (assuming a value of `SoftOptOutThreshold` is `5%`), unless it is a Top N chain with `N >= 95%`. |
There was a problem hiding this comment.
| * A consumer chain does not receive the same economic security as with Replicated Security (assuming a value of `SoftOptOutThreshold` is `5%`), unless it is a Top N chain with `N >= 95%`. | |
| * A consumer chain does not receive the same economic security as with Replicated Security (assuming the value of `SoftOptOutThreshold` is `5%`), unless it is a Top N chain with `N >= 95%`. |
Co-authored-by: Philip Offtermatt <[email protected]>
| Additionally, by having `N >= 50%` (and hence `N > (VetoThreshold = 33.4%)`) we enable the top N validators to `Veto` any `ConsumerAdditionProposal` for consumer chains they do not want to validate. | ||
|
|
||
| If a proposal has the `top_N` argument wrongly set, it should get rejected in [ValidateBasic](https://github.com/cosmos/interchain-security/blob/v4.0.0/x/ccv/provider/types/proposal.go#L86). | ||
| If a proposal has the `top_N` argument wrongly set, it should get rejected in [ValidateBasic] (<https://github.com/cosmos/interchain-security/blob/v4.0.0/x/ccv/provider/types/proposal.go#L86>). |
There was a problem hiding this comment.
Do the < and > break the link? See diff below:
There was a problem hiding this comment.
hmm maybe something weird in my editor's formatting
| @@ -42,25 +51,28 @@ For example, `53` corresponds to a Top 53% chain, meaning that the top `53%` pro | |||
| `top_N` can be `0` or include any value in `[50, 100]`. A chain can join with `top_N == 0` as an Opt In, or with `top_N ∈ [50, 100]` as a Top N chain. | |||
|
|
|||
| In case of a Top N chain, we restrict the possible values of `top_N` from `(0, 100]` to `[50, 100]`. | |||
| By having `top_N >= 50` we can guarantee that we cannot have a successful invalid-execution attack, assuming that at most `1/3` of provider validators can be malicious. | |||
| This is because, a Top N chain with `N >= 50%` would have at least `1/3` honest validators, which is sufficient to stop invalid-execution attacks. | |||
| By having `top_N >= 50` we can guarantee that we cannot have a successful attack, assuming that at most `1/3` of provider validators can be malicious. | |||
There was a problem hiding this comment.
I think the >= 50 is rather specific to invalid-execution attacks. For instance, we do not ask for >= 50 to avoid equivocation attacks. So removing "invalid-execution" might be too general.
There was a problem hiding this comment.
I agree. Obviously it's true that we care about other attacks, too, but the exact choice of N>=50 rather than N>=66 or whatever is because of what Karolos argued here afaict
There was a problem hiding this comment.
Maybe a way to resolve this is to leave the original, but then go on to say:
"Choosing N>=50 also prevents other attacks, like chaindeath/liveness attacks." to make clear we also consider other attacks
|
|
||
| In an Opt In chain, a set of validators might attempt to perform an attack. To deter such potential attacks, PSS allows for the use of fraud votes. |
There was a problem hiding this comment.
Similarly to my previous comment, fraud votes deter a specific type of attack, so might be too vague if we remove the "invalid-execution" part.
p-offtermatt
changed the title
|
markdown link failure is not related to this pr, so can merge despite it |
change emphasis on top-n and opt-in, generalize beyond invalid execution when talking about attacks, whitespace formatting
Please go to the
Previewtab and select the appropriate sub-template:fix,feat, andrefactor.