From 63cb501cf943574fda41f666c3002610f216fcf6 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Tue, 16 Jul 2024 10:49:17 +0200 Subject: [PATCH] save last version --- docs/docs/adrs/adr-018-fault-resolutions.md | 75 +++++++++++++++------ 1 file changed, 55 insertions(+), 20 deletions(-) diff --git a/docs/docs/adrs/adr-018-fault-resolutions.md b/docs/docs/adrs/adr-018-fault-resolutions.md index 6aa5c050b7..643ec9c2c5 100644 --- a/docs/docs/adrs/adr-018-fault-resolutions.md +++ b/docs/docs/adrs/adr-018-fault-resolutions.md @@ -2,54 +2,89 @@ sidebar_position: 2 title: ADR Template --- -# ADR [018]: [Fault Resolutions (fraud votes)] +# ADR [018]: [Fault Resolutions] ## Changelog -* [date]: [changelog] +* 2024-07-06: Initial draft ## Status - Proposed ## Context -Currently, in _PSS_, consumer chains can be secured by a only subset of the provider validator set. - That makes them vulnerable to incorrect execution attacks. - These kind misbehaviour of that cannot be handled by the protocol and hence requires a way to submit evidence of such misbehaviour - to the Hub. - - The ADR proposes a fault resolutions solution that gives the ability to the victims of these attack to prove and slash - validators through a governance. +Partial Set Security ([PSS](./adr-015-partial-set-security.md)) allows a subset of a provider chain's validator set to secure a consumer chain. While this shared security scheme has many advantages, it comes with a pitfall known as the [subset problem](https://informal.systems/blog/replicated-vs-mesh-security#risks-of-opt-in-security-also-known-as-ics-v-2). This problem arises when a malicious majority of validators from the provider chain collude and misbehave on a consumer chain. This threat is particularly relevant for Opt-in chains since they might be secured by a relatively small subset of the provider's validator set. + +In cases of collusion, various types of misbehaviour can be performed by the validators, such as: + +-Incorrect executions to break the rules of the protocol and steal funds. +-Liveness attacks to halt the chain or censor transactions. +-Oracle attacks to falsify information used by the chain logic. +Currently, these type of attack aren't handled by the protocol, leaving the malicious validators unpunished. - from incorrect executions. Partial Set Security gives the option to consumer chains to be secured by only a subset of the provider validator set. +A potential solution is to use fraud proofs. This technology allows proving incorrect state transitions of a chain without a full node. However, this is a complex technology, and there is no framework that works for Cosmos chains to this day. +To address this risk in PSS, a governance-gated slashing solution can be used until fraud proof technology matures. -> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. +This ADR proposes a fault resolution mechanism, which is a type of governance proposal that victims of faults can use to vote on the slashing of validators that misbehave on Opt-in consumer chains. + +In what follows, we describe the implementation of a fault resolution mechanism that handles incorrect executions on consumer chains, as a first iteration. + ## Decision -> This section explains all of the details of the proposed solution, including implementation details. -It should also describe affects / corollary items that may need to be changed as a part of this. -If the proposed change will be large, please also indicate a way to do the change to maximize ease of review. -(e.g. the optimal split of things to do between separate PR's) +The proposed solution introduces a new `consumer-fault-resolution` governance proposal type to the `provider` module, which allows validators to be penalised for committing faults on an Opt-in consumer chain. -## Consequences +If such a proposal passes, the proposal handler tombstones all the validators listed in the proposal and slashes them by a predefined amount or the default value used for double-sign infractions. + +The proposal has the following fields: + +-**Description**: This field should be filled with a fault definition describing the type of misbehavior that the validators executed on a Opt-in consumer chain. A fault definition should precisely describe how an attack was performed and why it is eligible as a slashable fault. +-**Consumer Chain**: The chain that the fault was related to. +-**Validators**: The list of all the validators to be slashed. + +In addition, in order to prevent spamming, users are required to pay a fee of `250ATOM` to submit a fault resolution to the provider. + +### validations + +The submission of a fault resolution fails if any of the following conditions are not met: + +-the consumer chain is an Opt-in chain +-all listed validators were opted-in to the consumer chain in the past unbonding-period +-the minimum fee is provided -> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. +### additional considerations + +Fault resolution proposals should be `expedited` to minimize the time given to the listed validators to +to unbond in order to not be punished. + + +## Consequences ### Positive +-Provide the ability to slash and tombstone validators for committing incorrect executions on Opt-in consumer chains. + ### Negative +-Assuming that malicious validators unbond immediately after misbehaving, a fault resolution has to be submitted within a maximum of two weeks in order to slash the validators. + ### Neutral +-Fault definitions need to have a clear framework in order to avoid debates about whether or not an attack has actually take place. + ## References -> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! + + +* [Enabling Opt-in and Mesh Security with Fraud Votes](https://forum.cosmos.network/t/enabling-opt-in-and-mesh-security-with-fraud-votes/10901) + +* [CHIPs discussion phase: Partial Set Security](https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security-updated/11775) + + + -* [references]