From 897a3009a4e8de2be3d4831cc127dbb7ba65b055 Mon Sep 17 00:00:00 2001 From: MSalopek Date: Fri, 24 May 2024 23:45:40 +0200 Subject: [PATCH 01/15] turn off expensive tests --- .github/workflows/test.yml | 189 ++----------------------------------- 1 file changed, 10 insertions(+), 179 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 078ab2c0d8..ab60f22a2b 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -53,11 +53,11 @@ jobs: if: env.GIT_DIFF run: | make test-unit-cov - - uses: actions/upload-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-coverage" - path: ./profile.out + # - uses: actions/upload-artifact@v4 + # if: env.GIT_DIFF + # with: + # name: "${{ github.sha }}-coverage" + # path: ./profile.out test-integration: runs-on: ubuntu-latest @@ -84,88 +84,11 @@ jobs: if: env.GIT_DIFF run: | make test-integration-cov - - uses: actions/upload-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-integration-coverage" - path: ./integration-profile.out - - test-mbt: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - - uses: actions/setup-go@v5 - with: - go-version: "1.21" - check-latest: true - cache: true - cache-dependency-path: go.sum - - uses: actions/setup-node@v4 - with: - node-version: ">= 18" - check-latest: true - - run: npm i @informalsystems/quint -g - - uses: technote-space/get-diff-action@v6.1.2 - id: git_diff - with: - PATTERNS: | - **/*.go - go.mod - go.sum - **/go.mod - **/go.sum - **/Makefile - Makefile - - name: mbt tests - if: env.GIT_DIFF - run: | - make test-mbt-cov - - uses: actions/upload-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-mbt-coverage" - path: ./mbt-profile.out - - name: Archive MBT traces - uses: actions/upload-artifact@v4 - if: ${{ success() || failure() }} # to upload the traces only when the test failed - with: - name: mbt-traces - path: tests/mbt/driver/traces - retention-days: 6 # to not clog our cloud storage too much, we retain only for a few days - - repo-analysis: - runs-on: ubuntu-latest - needs: [tests, test-integration, test-mbt] - steps: - - uses: actions/checkout@v4 - - uses: technote-space/get-diff-action@v6.1.2 - id: git_diff - with: - PATTERNS: | - **/*.go - go.mod - go.sum - **/go.mod - **/go.sum - - uses: actions/download-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-coverage" - - uses: actions/download-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-integration-coverage" - - uses: actions/download-artifact@v4 - if: env.GIT_DIFF - with: - name: "${{ github.sha }}-mbt-coverage" - continue-on-error: true - - name: sonarcloud - if: ${{ env.GIT_DIFF && !github.event.pull_request.draft }} - uses: SonarSource/sonarcloud-github-action@master - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} + # - uses: actions/upload-artifact@v4 + # if: env.GIT_DIFF + # with: + # name: "${{ github.sha }}-integration-coverage" + # path: ./integration-profile.out test-e2e: runs-on: ubuntu-latest @@ -198,98 +121,6 @@ jobs: run: | make test-e2e-short - test-e2e-compatibility: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - lfs: true - - name: checkout LFS objects - run: git lfs checkout - - uses: actions/setup-go@v5 - with: - go-version: "1.21" - check-latest: true - cache: true - cache-dependency-path: go.sum - - uses: technote-space/get-diff-action@v6.1.2 - id: git_diff - with: - PATTERNS: | - **/*.go - go.mod - go.sum - **/go.mod - **/go.sum - **/Makefile - Makefile - Dockerfile* - - name: e2e compatibility tests - if: env.GIT_DIFF - run: | - make test-e2e-compatibility-tests-latest - - test-cometmock: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - lfs: true - - name: checkout LFS objects - run: git lfs checkout - - uses: actions/setup-go@v5 - with: - go-version: "1.21" - check-latest: true - cache: true - cache-dependency-path: go.sum - - uses: technote-space/get-diff-action@v6.1.2 - id: git_diff - with: - PATTERNS: | - **/*.go - go.mod - go.sum - **/go.mod - **/go.sum - **/Makefile - Makefile - Dockerfile* - - name: cometmock tests - if: env.GIT_DIFF - run: | - make test-e2e-short-cometmock - - test-trace: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - lfs: true - - name: checkout LFS objects - run: git lfs checkout - - uses: actions/setup-go@v5 - with: - go-version: "1.21" - check-latest: true - cache: true - cache-dependency-path: go.sum - - uses: technote-space/get-diff-action@v6.1.2 - id: git_diff - with: - PATTERNS: | - **/*.go - go.mod - go.sum - **/go.mod - **/go.sum - **/Makefile - Makefile - Dockerfile* - - name: trace-e2e tests - if: env.GIT_DIFF - run: | - make test-trace model-analysis: runs-on: ubuntu-latest steps: From 4eaf86f0bbdd845e3626a1c78af569262fb88817 Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 19 Jul 2024 16:43:22 +0200 Subject: [PATCH 02/15] Proof of Reputation Consumer Chains ADR --- docs/docs/adrs/adr-0XX-conditional-clients.md | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 docs/docs/adrs/adr-0XX-conditional-clients.md diff --git a/docs/docs/adrs/adr-0XX-conditional-clients.md b/docs/docs/adrs/adr-0XX-conditional-clients.md new file mode 100644 index 0000000000..df719132ed --- /dev/null +++ b/docs/docs/adrs/adr-0XX-conditional-clients.md @@ -0,0 +1,95 @@ +--- +sidebar_position: 2 +title: Proof of Reputation Consumer Chains +--- +# ADR 0XX: Proof of Reputation Consumer Chains + +## Changelog +* 2024-07-19: Initial draft of ADR + +## Status + +Proposed + +## Context + +Interchain Security (ICS) is a cross-chain staking protocol -- it uses the stake on the provider chain as collateral for the Proof of Stake (PoS) on the consumer chains. +This means that the voting power of validators validating (aka producing blocks) on the consumer chains is a function of their stake on the provider. +Moreover, if these validators misbehave on the consumer chains, their stake on the provider is being slashed (see [ADR 005](./adr-005-cryptographic-equivocation-verification.md)). +Thus, ICS consumer chains get their economical security from the provider. +However, this might come at a high cost. + +### The Cost of PoS + +One of the cost of validating on the consumer chains is operational -- validators need to run and monitor full nodes of every consumer chain they opt in. +Although this cost varies from validator team to validator team (depending on how efficiently they can run their infrastructure), it doesn't depend on the total stake (or voting power) of the validators, so we can think of it as constant. +The other cost of validating comes from the risk of getting slashed. + +Most chains in Cosmos (including the Cosmos Hub) use delelegated PoS -- users delegate their tokens to validators, which stake them in return for voting power. +Therefore, validators act as representatives chosen by their delegators to represent their interests. +When validators misbehave, their stake is getting slashed, including the tokes delegated by users. +As validators don't need to have their own stake, delegators take the risk of validators misbehaving and having their assets slashed. + +Misbehavior doesn't need to be malicious, e.g., most cases of double signing infractions are due to misconfiguration. +This means that, by opting in on multiple consumer chains, validators increase their chances of getting slashed and, consequently, +their delegators incur a higher risk. +As a result, delegators want to be compensated for this additional risk, which makes PoS expensive. + +This ADR addresses the high cost of ICS by proposing the deployment of consumer chains that rely only on Proof of Reputation (PoR) -- when validators misbehave on these PoR consumer chains, their stake is not slashed, but they are tombstoned (permanently removed from the provider), which means their reputation is destroyed (they loose all their delegators). + +## Decision + +To reduce the cost of ICS, consumer chains will be able to deploy as Proof of Reputation (PoR) chains. +This means that when validators that opt in misbehave on the consumer chains (e.g., they double sign), their stake on the provider is not being slashed, instead they are being tombstoned on the provider. +As a result, delegators incur no risk if their validators opt in on multiple PoR consumer chains. +This means that PoR consumer chains need only to cover the operational costs of the validators that opt in. +For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running a PoR consumer chain and have `$150` profit per validator as incentive. + +### Security Model + +The security model provided to PoR chains is based on the following properties of most Cosmos chains: + +- validators are not anonymous, which means that they could be legally liable if they are malicious; +- the delegated PoS mechanism creates a reputation-based network of validators; +- most validators have most of their stake coming from delegations (i.e., nothing at stake, besides reputation); +- it is relatively difficult to enter the active validator set and even more so to climb the voting power ladder. + +The assumption is that being permanently removed from the provider active validator set is strong enough of a deterrent to misbehaving on PoR consumer chains. +Note that this assumption holds only if [inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt in on PoR consumer chains. + +The additional economical security a consumer gets from slashing is limited. +The reason is that slashing punishes delegators as most of the stake is delegated. + +One benefit of slashing is that it acts as a deterrent for someone buying a large amount of staking tokens in order to attack a consumer chain. +For example, an attacker could get `$15.000.000` worth of ATOM, which would give them around `1%` voting power on the Cosmos Hub (at the time of this writing). +On a consumer chain, this voting power could be amplified depending on the other validators that opt in. +However, by having the right [power shaping](https://cosmos.github.io/interchain-security/features/power-shaping) settings, the voting power of validators can be capped. +This means that even if the attacker manages to double sign without getting slashed, it doesn't benefit from this attack. +Moreover, the attacker might lose due to other factors, such as [token toxicity](https://forum.cosmos.network/t/enabling-opt-in-and-mesh-security-with-fraud-votes/10901). + +### Implementation + +The implementation of this feature involves the following steps: + +- Add a field to `ConsumerAdditionProposal` to enable consumer chains to launch as PoR chains. +- Disable opt in to PoR consumer chains for validators outside of the provider's active set. +- Cryptographic equivocation evidence received for PoR chains results in the misbehaving validators only being tombstoned and not slashed. +- (Optional) PoR consumer chains can switch to PoS chains, but the transition takes at least unbonding period to allow for validators to opt out. + +## Consequences + +### Positive + +- Reduce the cost of ICS be removing the risk of slashing delegators. + +### Negative + +- Reduce the economical security provided to PoR consumer chains. + +### Neutral + +- [Inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt in on PoR consumer chains + +## References + + From fb3ee6c2abb6e453b5bc06b860224b724d3d99e1 Mon Sep 17 00:00:00 2001 From: Marius Poke Date: Mon, 22 Jul 2024 15:06:09 +0200 Subject: [PATCH 03/15] Update docs/docs/adrs/adr-0XX-conditional-clients.md Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> --- docs/docs/adrs/adr-0XX-conditional-clients.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-0XX-conditional-clients.md b/docs/docs/adrs/adr-0XX-conditional-clients.md index df719132ed..840ebd89f8 100644 --- a/docs/docs/adrs/adr-0XX-conditional-clients.md +++ b/docs/docs/adrs/adr-0XX-conditional-clients.md @@ -21,7 +21,7 @@ However, this might come at a high cost. ### The Cost of PoS -One of the cost of validating on the consumer chains is operational -- validators need to run and monitor full nodes of every consumer chain they opt in. +One of the cost of validating on the consumer chains is operational -- validators need to run and monitor full nodes of every consumer chain they opt in for. Although this cost varies from validator team to validator team (depending on how efficiently they can run their infrastructure), it doesn't depend on the total stake (or voting power) of the validators, so we can think of it as constant. The other cost of validating comes from the risk of getting slashed. From 2885f48e958b5bf62ef72ed0a2d3cb5b9441d382 Mon Sep 17 00:00:00 2001 From: Marius Poke Date: Mon, 22 Jul 2024 15:06:22 +0200 Subject: [PATCH 04/15] Update docs/docs/adrs/adr-0XX-conditional-clients.md Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> --- docs/docs/adrs/adr-0XX-conditional-clients.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-0XX-conditional-clients.md b/docs/docs/adrs/adr-0XX-conditional-clients.md index 840ebd89f8..244c1e6088 100644 --- a/docs/docs/adrs/adr-0XX-conditional-clients.md +++ b/docs/docs/adrs/adr-0XX-conditional-clients.md @@ -25,7 +25,7 @@ One of the cost of validating on the consumer chains is operational -- validator Although this cost varies from validator team to validator team (depending on how efficiently they can run their infrastructure), it doesn't depend on the total stake (or voting power) of the validators, so we can think of it as constant. The other cost of validating comes from the risk of getting slashed. -Most chains in Cosmos (including the Cosmos Hub) use delelegated PoS -- users delegate their tokens to validators, which stake them in return for voting power. +Most chains in Cosmos (including the Cosmos Hub) use delegated PoS -- users delegate their tokens to validators, which stake them in return for voting power. Therefore, validators act as representatives chosen by their delegators to represent their interests. When validators misbehave, their stake is getting slashed, including the tokes delegated by users. As validators don't need to have their own stake, delegators take the risk of validators misbehaving and having their assets slashed. From 471353e46bd338db0e640d232df00e8dd839052e Mon Sep 17 00:00:00 2001 From: mpoke Date: Mon, 22 Jul 2024 15:27:32 +0200 Subject: [PATCH 05/15] address reviewing suggestions --- docs/docs/adrs/adr-0XX-conditional-clients.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/docs/adrs/adr-0XX-conditional-clients.md b/docs/docs/adrs/adr-0XX-conditional-clients.md index 244c1e6088..ace19fb3d1 100644 --- a/docs/docs/adrs/adr-0XX-conditional-clients.md +++ b/docs/docs/adrs/adr-0XX-conditional-clients.md @@ -41,9 +41,13 @@ This ADR addresses the high cost of ICS by proposing the deployment of consumer To reduce the cost of ICS, consumer chains will be able to deploy as Proof of Reputation (PoR) chains. This means that when validators that opt in misbehave on the consumer chains (e.g., they double sign), their stake on the provider is not being slashed, instead they are being tombstoned on the provider. -As a result, delegators incur no risk if their validators opt in on multiple PoR consumer chains. +As a result, delegators incur (almost) no risk if their validators opt in on multiple PoR consumer chains. +If their validators are tombstoned, then the delegators can redelegate to other validators. +However, delegators cannot redelegate multiple times, which means that if the new validators get also tombstoned, the delegators need to wait for the unbonding period to elapse. + This means that PoR consumer chains need only to cover the operational costs of the validators that opt in. -For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running a PoR consumer chain and have `$150` profit per validator as incentive. +For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running a PoR consumer chain and have `$150` profit per validator as incentive. +In practice, this can be implemented via the per-consumer-chain commission rate that allows validators to have different commission rates on different consumer chains. ### Security Model @@ -64,7 +68,7 @@ One benefit of slashing is that it acts as a deterrent for someone buying a larg For example, an attacker could get `$15.000.000` worth of ATOM, which would give them around `1%` voting power on the Cosmos Hub (at the time of this writing). On a consumer chain, this voting power could be amplified depending on the other validators that opt in. However, by having the right [power shaping](https://cosmos.github.io/interchain-security/features/power-shaping) settings, the voting power of validators can be capped. -This means that even if the attacker manages to double sign without getting slashed, it doesn't benefit from this attack. +This means that even if the attacker manages to double sign without getting slashed, as long as they don't have 1/3+ of the voting power, they cannot benefit from the attack. Moreover, the attacker might lose due to other factors, such as [token toxicity](https://forum.cosmos.network/t/enabling-opt-in-and-mesh-security-with-fraud-votes/10901). ### Implementation From 37e41d9e36d00bf56baf4ea0c3083a3ba96ee0ef Mon Sep 17 00:00:00 2001 From: Marius Poke Date: Wed, 14 Aug 2024 15:45:50 +0200 Subject: [PATCH 06/15] Delete .github/dependabot.yml --- .github/dependabot.yml | 70 ------------------------------------------ 1 file changed, 70 deletions(-) delete mode 100644 .github/dependabot.yml diff --git a/.github/dependabot.yml b/.github/dependabot.yml deleted file mode 100644 index d2d38c4c09..0000000000 --- a/.github/dependabot.yml +++ /dev/null @@ -1,70 +0,0 @@ -version: 2 -updates: - - package-ecosystem: github-actions - directory: "/" - schedule: - interval: weekly - target-branch: "main" - open-pull-requests-limit: 10 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: weekly - target-branch: "main" - open-pull-requests-limit: 10 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: daily - target-branch: "release/v4.3.x" - # Only allow automated security-related dependency updates on release branches. - open-pull-requests-limit: 0 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: daily - target-branch: "release/v4.3.x-lsm" - # Only allow automated security-related dependency updates on release branches. - open-pull-requests-limit: 0 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: daily - target-branch: "release/v4.4.x" - # Only allow automated security-related dependency updates on release branches. - open-pull-requests-limit: 0 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: daily - target-branch: "release/v5.x" - # Only allow automated security-related dependency updates on release branches. - open-pull-requests-limit: 0 - labels: - - dependencies - - - package-ecosystem: gomod - directory: "/" - schedule: - interval: daily - target-branch: "release/v5.1.x" - # Only allow automated security-related dependency updates on release branches. - open-pull-requests-limit: 0 - labels: - - dependencies - From 7df612b0730814d8cac985c3afd2d88e4778c0e7 Mon Sep 17 00:00:00 2001 From: mpoke Date: Wed, 14 Aug 2024 16:02:44 +0200 Subject: [PATCH 07/15] change name of ADR --- ...XX-conditional-clients.md => adr-019-conditional-clients.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename docs/docs/adrs/{adr-0XX-conditional-clients.md => adr-019-conditional-clients.md} (99%) diff --git a/docs/docs/adrs/adr-0XX-conditional-clients.md b/docs/docs/adrs/adr-019-conditional-clients.md similarity index 99% rename from docs/docs/adrs/adr-0XX-conditional-clients.md rename to docs/docs/adrs/adr-019-conditional-clients.md index ace19fb3d1..646cf44c14 100644 --- a/docs/docs/adrs/adr-0XX-conditional-clients.md +++ b/docs/docs/adrs/adr-019-conditional-clients.md @@ -2,7 +2,7 @@ sidebar_position: 2 title: Proof of Reputation Consumer Chains --- -# ADR 0XX: Proof of Reputation Consumer Chains +# ADR 020: Proof of Reputation Consumer Chains ## Changelog * 2024-07-19: Initial draft of ADR From 3d2b801fa94d8b452b9755da37cf918e4a25632a Mon Sep 17 00:00:00 2001 From: mpoke Date: Wed, 14 Aug 2024 17:21:32 +0200 Subject: [PATCH 08/15] update filename --- ...19-conditional-clients.md => adr-020-proof-of-reputation.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename docs/docs/adrs/{adr-019-conditional-clients.md => adr-020-proof-of-reputation.md} (99%) diff --git a/docs/docs/adrs/adr-019-conditional-clients.md b/docs/docs/adrs/adr-020-proof-of-reputation.md similarity index 99% rename from docs/docs/adrs/adr-019-conditional-clients.md rename to docs/docs/adrs/adr-020-proof-of-reputation.md index 646cf44c14..5c8ce298a4 100644 --- a/docs/docs/adrs/adr-019-conditional-clients.md +++ b/docs/docs/adrs/adr-020-proof-of-reputation.md @@ -1,5 +1,5 @@ --- -sidebar_position: 2 +sidebar_position: 21 title: Proof of Reputation Consumer Chains --- # ADR 020: Proof of Reputation Consumer Chains From 853bd34fb94f29ea7c266219e12c529eac6c9767 Mon Sep 17 00:00:00 2001 From: mpoke Date: Wed, 14 Aug 2024 17:24:44 +0200 Subject: [PATCH 09/15] revert changes to main --- .github/dependabot.yml | 70 +++++++++++++++++++++++++++++++ .github/workflows/test.yml | 85 +++++++++++++++++++++++++++++++++----- 2 files changed, 145 insertions(+), 10 deletions(-) create mode 100644 .github/dependabot.yml diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 0000000000..d2d38c4c09 --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,70 @@ +version: 2 +updates: + - package-ecosystem: github-actions + directory: "/" + schedule: + interval: weekly + target-branch: "main" + open-pull-requests-limit: 10 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: weekly + target-branch: "main" + open-pull-requests-limit: 10 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: daily + target-branch: "release/v4.3.x" + # Only allow automated security-related dependency updates on release branches. + open-pull-requests-limit: 0 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: daily + target-branch: "release/v4.3.x-lsm" + # Only allow automated security-related dependency updates on release branches. + open-pull-requests-limit: 0 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: daily + target-branch: "release/v4.4.x" + # Only allow automated security-related dependency updates on release branches. + open-pull-requests-limit: 0 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: daily + target-branch: "release/v5.x" + # Only allow automated security-related dependency updates on release branches. + open-pull-requests-limit: 0 + labels: + - dependencies + + - package-ecosystem: gomod + directory: "/" + schedule: + interval: daily + target-branch: "release/v5.1.x" + # Only allow automated security-related dependency updates on release branches. + open-pull-requests-limit: 0 + labels: + - dependencies + diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 54d9283371..9f283ee3d3 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -53,11 +53,11 @@ jobs: if: env.GIT_DIFF run: | make test-unit-cov - # - uses: actions/upload-artifact@v4 - # if: env.GIT_DIFF - # with: - # name: "${{ github.sha }}-coverage" - # path: ./profile.out + - uses: actions/upload-artifact@v4 + if: env.GIT_DIFF + with: + name: "${{ github.sha }}-coverage" + path: ./profile.out test-integration: runs-on: Gaia-Runner-medium @@ -84,11 +84,45 @@ jobs: if: env.GIT_DIFF run: | make test-integration-cov - # - uses: actions/upload-artifact@v4 - # if: env.GIT_DIFF - # with: - # name: "${{ github.sha }}-integration-coverage" - # path: ./integration-profile.out + - uses: actions/upload-artifact@v4 + if: env.GIT_DIFF + with: + name: "${{ github.sha }}-integration-coverage" + path: ./integration-profile.out + + repo-analysis: + runs-on: ubuntu-latest + needs: [tests, test-integration] + steps: + - uses: actions/checkout@v4 + - uses: technote-space/get-diff-action@v6.1.2 + id: git_diff + with: + PATTERNS: | + **/*.go + go.mod + go.sum + **/go.mod + **/go.sum + - uses: actions/download-artifact@v4 + if: env.GIT_DIFF + with: + name: "${{ github.sha }}-coverage" + - uses: actions/download-artifact@v4 + if: env.GIT_DIFF + with: + name: "${{ github.sha }}-integration-coverage" + - uses: actions/download-artifact@v4 + if: env.GIT_DIFF + with: + name: "${{ github.sha }}-mbt-coverage" + continue-on-error: true + - name: sonarcloud + if: ${{ env.GIT_DIFF && !github.event.pull_request.draft }} + uses: SonarSource/sonarcloud-github-action@master + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} test-e2e: runs-on: Gaia-Runner-medium @@ -121,6 +155,37 @@ jobs: run: | make test-e2e-short + test-e2e-compatibility: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + lfs: true + - name: checkout LFS objects + run: git lfs checkout + - uses: actions/setup-go@v5 + with: + go-version: "1.22" + check-latest: true + cache: true + cache-dependency-path: go.sum + - uses: technote-space/get-diff-action@v6.1.2 + id: git_diff + with: + PATTERNS: | + **/*.go + go.mod + go.sum + **/go.mod + **/go.sum + **/Makefile + Makefile + Dockerfile* + - name: e2e compatibility tests + if: env.GIT_DIFF + run: | + make test-e2e-compatibility-tests-latest + model-analysis: runs-on: ubuntu-latest steps: From bdb42db454906dddabd643e919dd02883d91c9d2 Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 23 Aug 2024 10:07:42 +0200 Subject: [PATCH 10/15] update ADR -- wip --- docs/docs/adrs/adr-020-proof-of-reputation.md | 40 +++++++++++++------ 1 file changed, 28 insertions(+), 12 deletions(-) diff --git a/docs/docs/adrs/adr-020-proof-of-reputation.md b/docs/docs/adrs/adr-020-proof-of-reputation.md index 5c8ce298a4..8b7e507940 100644 --- a/docs/docs/adrs/adr-020-proof-of-reputation.md +++ b/docs/docs/adrs/adr-020-proof-of-reputation.md @@ -1,8 +1,8 @@ --- sidebar_position: 21 -title: Proof of Reputation Consumer Chains +title: Customizable Slashing and Jailing --- -# ADR 020: Proof of Reputation Consumer Chains +# ADR 020: Customizable Slashing and Jailing ## Changelog * 2024-07-19: Initial draft of ADR @@ -15,31 +15,47 @@ Proposed Interchain Security (ICS) is a cross-chain staking protocol -- it uses the stake on the provider chain as collateral for the Proof of Stake (PoS) on the consumer chains. This means that the voting power of validators validating (aka producing blocks) on the consumer chains is a function of their stake on the provider. -Moreover, if these validators misbehave on the consumer chains, their stake on the provider is being slashed (see [ADR 005](./adr-005-cryptographic-equivocation-verification.md)). -Thus, ICS consumer chains get their economical security from the provider. +Moreover, if these validators misbehave on the consumer chains, they get punished on the provider chain. +ICS is currently differentiating between two types of infractions -- equivocation and downtime. +Depending on the infraction type, the misbehaving validators might be jailed (i.e., removed from the provider validator set) and / or slashed (i.e., a portion of their stake on the provider is being burned). +For example, validators double sining on consumer chains get slashed and are permanently jailed, +while validators not validating sufficient blocks are temporarily jailed. + +This means that ICS consumer chains get their economical security from the provider. However, this might come at a high cost. ### The Cost of PoS One of the cost of validating on the consumer chains is operational -- validators need to run and monitor full nodes of every consumer chain they opt in for. Although this cost varies from validator team to validator team (depending on how efficiently they can run their infrastructure), it doesn't depend on the total stake (or voting power) of the validators, so we can think of it as constant. -The other cost of validating comes from the risk of getting slashed. +The other cost of validating comes from the risk of getting slashed or jailed. Most chains in Cosmos (including the Cosmos Hub) use delegated PoS -- users delegate their tokens to validators, which stake them in return for voting power. Therefore, validators act as representatives chosen by their delegators to represent their interests. -When validators misbehave, their stake is getting slashed, including the tokes delegated by users. -As validators don't need to have their own stake, delegators take the risk of validators misbehaving and having their assets slashed. +However, delegators share the risk of their validators getting slashed or jailed: + +- When validators get slashed, a portion of their stake is being burned, including a portion of the tokens delegated by users. + As validators don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving and having their assets slashed. +- When validators get jailed, they no longer receive block rewards (neither from the provider nor from the consumer chains). + This applies also for their delegators. + As a result, delegators might choose to restake their tokens with another validator. + The longer the validators are jailed, the more likely is that delegators will restake. + Thus, by getting jailed, validators risk damaging their reputation. Misbehavior doesn't need to be malicious, e.g., most cases of double signing infractions are due to misconfiguration. -This means that, by opting in on multiple consumer chains, validators increase their chances of getting slashed and, consequently, -their delegators incur a higher risk. -As a result, delegators want to be compensated for this additional risk, which makes PoS expensive. +This means that, by opting in on multiple consumer chains, validators and their delegators incur a higher risk. +As a result, validators and their delegators want to be compensated for this additional risk, which makes the current design of ICS expensive. -This ADR addresses the high cost of ICS by proposing the deployment of consumer chains that rely only on Proof of Reputation (PoR) -- when validators misbehave on these PoR consumer chains, their stake is not slashed, but they are tombstoned (permanently removed from the provider), which means their reputation is destroyed (they loose all their delegators). +This ADR addresses the high cost of ICS by allowing consumer chains to customize the slashing and jailing conditions. +Basically, every consumer chain can decide the punishment for every type of infraction. +This enables consumer chains to tradeoff economical security against cost. ## Decision -To reduce the cost of ICS, consumer chains will be able to deploy as Proof of Reputation (PoR) chains. +To reduce the cost of ICS, consumer chains will be able to customize the slashing and jailing for every type of infraction. + + +deploy as Proof of Reputation (PoR) chains. This means that when validators that opt in misbehave on the consumer chains (e.g., they double sign), their stake on the provider is not being slashed, instead they are being tombstoned on the provider. As a result, delegators incur (almost) no risk if their validators opt in on multiple PoR consumer chains. If their validators are tombstoned, then the delegators can redelegate to other validators. From 9509e956dfb1144ef16d7ca820ea677cc93560b3 Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 23 Aug 2024 14:22:33 +0200 Subject: [PATCH 11/15] rename file --- ...-reputation.md => adr-020-cutomizable_slashing_and_jailing.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/docs/adrs/{adr-020-proof-of-reputation.md => adr-020-cutomizable_slashing_and_jailing.md} (100%) diff --git a/docs/docs/adrs/adr-020-proof-of-reputation.md b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md similarity index 100% rename from docs/docs/adrs/adr-020-proof-of-reputation.md rename to docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md From f95df44a77bca8d0f02062976e8a2f67e1d3ac92 Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 23 Aug 2024 16:43:51 +0200 Subject: [PATCH 12/15] update ADR decision --- ...dr-020-cutomizable_slashing_and_jailing.md | 128 +++++++++++++----- 1 file changed, 96 insertions(+), 32 deletions(-) diff --git a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md index 8b7e507940..238cd62dd5 100644 --- a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md +++ b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md @@ -6,6 +6,7 @@ title: Customizable Slashing and Jailing ## Changelog * 2024-07-19: Initial draft of ADR +* 2024-08-23: Generalize ADR to make slashing and jailing customizable ## Status @@ -53,29 +54,111 @@ This enables consumer chains to tradeoff economical security against cost. ## Decision To reduce the cost of ICS, consumer chains will be able to customize the slashing and jailing for every type of infraction. +As a result, consumer chains can decide on the amount of economic security they want and validators (and their delegators) can decide on the amount of additional risk they want to incur. + +For every consumer chain, we introduce the following slashing and jailing parameters: +```proto +message InfractionParameters { + SlashJailParameters double_sign = 1; + SlashJailParameters downtime = 2; +} + +message SlashJailParameters { + bytes slash_fraction = 1 [ + (cosmos_proto.scalar) = "cosmos.Dec", + (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", + (gogoproto.nullable) = false, + (amino.dont_omitempty) = true + ]; + // use time.Unix(253402300799, 0) for permanent jailing + google.protobuf.Duration jail_duration = 2; +} +``` +Currently, we consider only two infraction types -- double signing and downtime. + +By default, every consumer chain will have the following slashing and jailing parameters: +```go +double_sign.slash_fraction: 0.05 // same as on the provider +double_sign.jail_duration: time.Unix(253402300799, 0) // permanent jailing, same as on the provider +downtime.slash_fraction: 0 // no slashing for downtime on the consumer +downtime.jail_duration: 600s // same as on the provider +``` +These parameters can be updated by the consumer chain owner at any given time (via `MsgCreateConsumer` or `MsgUpdateConsumer`). +However, the changes will come into effect after a period equal to the staking module's unbonding period elapses. +This will allow validators that don't agree with the changes to opt out and not be affected by them. +Also, to avoid malicious chains attacking the provider validator set, these params will be bounded by the values on the provider chain: +```go +double_sign.slash_fraction <= 0.05 // 5% +downtime.slash_fraction <= 0.0001 // 0.1% +downtime.jail_duration <= 600s // 10 minutes +``` + +Although consumer chains can set any values to these parameters (within the allowed bounds), we recommend the following settings, depending on the type of consumer chain. + +- **Proof-of-Stake (PoS) Consumer Chains.** These are chains that have the full economical security of the provider validators that opted in. This means that all slashing and jailing parameters are the same as on the provider. + ```go + double_sign.slash_fraction: 0.05 + double_sign.jail_duration: time.Unix(253402300799, 0) + downtime.slash_fraction: 0.0001 + downtime.jail_duration: 600s + ``` +- **Proof-of-Reputation (PoR) Consumer Chains.** + ```go + double_sign.slash_fraction: 0 // no slashing + double_sign.jail_duration: time.Unix(253402300799, 0) + downtime.slash_fraction: 0 // no slashing + downtime.jail_duration: 600s + ``` + This means that when validators that opt in misbehave on PoR consumer chains, their stake on the provider is not being slashed, instead they are just jailed on the provider. + As a result, delegators incur (almost) no risk if their validators opt in on multiple PoR consumer chains. + If their validators are jailed, then the delegators can redelegate to other validators. + Note though that delegators cannot redelegate multiple times, which means that if the new validators get also tombstoned, the delegators need to wait for the unbonding period to elapse. +- **Testnet Consumer Chains.** + ```go + double_sign.slash_fraction: 0 // no slashing + double_sign.jail_duration: 0 // no jailing + downtime.slash_fraction: 0 // no slashing + downtime.jail_duration: 0 // no jailing + ``` + This means that validators are not punished for infractions on consumer chains. + This setting is ideal for testing consumer chains before going in production as neither validators nor their delegators incur any risk from the validators opting in on this consumer chains. + +This means that both PoR and testnet consumer chains need only to cover the operational costs of the validators that opt in. +For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running such a consumer chain and have `$150` profit per validator as incentive. +In practice, this can be implemented via the per-consumer-chain commission rate that allows validators to have different commission rates on different consumer chains. +### Implementation -deploy as Proof of Reputation (PoR) chains. -This means that when validators that opt in misbehave on the consumer chains (e.g., they double sign), their stake on the provider is not being slashed, instead they are being tombstoned on the provider. -As a result, delegators incur (almost) no risk if their validators opt in on multiple PoR consumer chains. -If their validators are tombstoned, then the delegators can redelegate to other validators. -However, delegators cannot redelegate multiple times, which means that if the new validators get also tombstoned, the delegators need to wait for the unbonding period to elapse. +The implementation of this feature involves the following steps: -This means that PoR consumer chains need only to cover the operational costs of the validators that opt in. -For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running a PoR consumer chain and have `$150` profit per validator as incentive. -In practice, this can be implemented via the per-consumer-chain commission rate that allows validators to have different commission rates on different consumer chains. +- Add the `InfractionParameters` to `MsgCreateConsumer`. +- On slashing events (for either downtime or double signing infractions), use the corresponding `slash_fraction` set by the consumer chain. +- On jailing events (for either downtime or double signing infractions), use the corresponding `jail_duration` set by the consumer chain. +- Cryptographic equivocation evidence received for PoR chains results in the misbehaving validators only being tombstoned and not slashed. +- (Optional) Add the `InfractionParameters` to `MsgUpdateConsumer`, i.e., allow consumer chains to update the slashing and jailing parameters, but the changes will come into effect after a period equal to the staking module's unbonding period elapses to allow for validators to opt out. + +## Consequences -### Security Model +### Positive + +- Reduce the cost of ICS by removing the risk of slashing delegators. + +### Negative -The security model provided to PoR chains is based on the following properties of most Cosmos chains: +- Reduce the economical security of consumer chains with weaker slashing conditions. + +#### Economic Security Model without Slashing + +The economic security model of most Cosmos chains relies on the following properties: - validators are not anonymous, which means that they could be legally liable if they are malicious; - the delegated PoS mechanism creates a reputation-based network of validators; - most validators have most of their stake coming from delegations (i.e., nothing at stake, besides reputation); - it is relatively difficult to enter the active validator set and even more so to climb the voting power ladder. -The assumption is that being permanently removed from the provider active validator set is strong enough of a deterrent to misbehaving on PoR consumer chains. -Note that this assumption holds only if [inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt in on PoR consumer chains. +These properties enables us to make the following assumption: + +- Being permanently removed from the provider validator set is strong enough of a deterrent to misbehaving on consumer chains. The additional economical security a consumer gets from slashing is limited. The reason is that slashing punishes delegators as most of the stake is delegated. @@ -87,28 +170,9 @@ However, by having the right [power shaping](https://cosmos.github.io/interchain This means that even if the attacker manages to double sign without getting slashed, as long as they don't have 1/3+ of the voting power, they cannot benefit from the attack. Moreover, the attacker might lose due to other factors, such as [token toxicity](https://forum.cosmos.network/t/enabling-opt-in-and-mesh-security-with-fraud-votes/10901). -### Implementation - -The implementation of this feature involves the following steps: - -- Add a field to `ConsumerAdditionProposal` to enable consumer chains to launch as PoR chains. -- Disable opt in to PoR consumer chains for validators outside of the provider's active set. -- Cryptographic equivocation evidence received for PoR chains results in the misbehaving validators only being tombstoned and not slashed. -- (Optional) PoR consumer chains can switch to PoS chains, but the transition takes at least unbonding period to allow for validators to opt out. - -## Consequences - -### Positive - -- Reduce the cost of ICS be removing the risk of slashing delegators. - -### Negative - -- Reduce the economical security provided to PoR consumer chains. - ### Neutral -- [Inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt in on PoR consumer chains +NA ## References From 58d87fa1a0ac48c2a4c3a8c96a8f723d1e2b8050 Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 23 Aug 2024 18:29:31 +0200 Subject: [PATCH 13/15] suggestions from coderabbitai --- ...dr-020-cutomizable_slashing_and_jailing.md | 56 ++++++++++--------- 1 file changed, 31 insertions(+), 25 deletions(-) diff --git a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md index 238cd62dd5..c8570ff597 100644 --- a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md +++ b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md @@ -35,15 +35,15 @@ Most chains in Cosmos (including the Cosmos Hub) use delegated PoS -- users dele Therefore, validators act as representatives chosen by their delegators to represent their interests. However, delegators share the risk of their validators getting slashed or jailed: -- When validators get slashed, a portion of their stake is being burned, including a portion of the tokens delegated by users. - As validators don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving and having their assets slashed. -- When validators get jailed, they no longer receive block rewards (neither from the provider nor from the consumer chains). - This applies also for their delegators. +* When validators get slashed, a portion of their stake is being burned, including a portion of the tokens delegated by users. + As validators don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving. +* When validators get jailed, they no longer receive block rewards (neither from the provider nor from the consumer chains). + This also applies to their delegators. As a result, delegators might choose to restake their tokens with another validator. The longer the validators are jailed, the more likely is that delegators will restake. Thus, by getting jailed, validators risk damaging their reputation. -Misbehavior doesn't need to be malicious, e.g., most cases of double signing infractions are due to misconfiguration. +Misbehaviors don't need to be malicious, e.g., most cases of double signing infractions are due to misconfiguration. This means that, by opting in on multiple consumer chains, validators and their delegators incur a higher risk. As a result, validators and their delegators want to be compensated for this additional risk, which makes the current design of ICS expensive. @@ -95,33 +95,39 @@ downtime.jail_duration <= 600s // 10 minutes Although consumer chains can set any values to these parameters (within the allowed bounds), we recommend the following settings, depending on the type of consumer chain. -- **Proof-of-Stake (PoS) Consumer Chains.** These are chains that have the full economical security of the provider validators that opted in. This means that all slashing and jailing parameters are the same as on the provider. +* **Proof-of-Stake (PoS) Consumer Chains.** These are chains that have the full economical security of the provider validators that opted in. This means that all slashing and jailing parameters are the same as on the provider. + ```go double_sign.slash_fraction: 0.05 double_sign.jail_duration: time.Unix(253402300799, 0) downtime.slash_fraction: 0.0001 downtime.jail_duration: 600s ``` -- **Proof-of-Reputation (PoR) Consumer Chains.** + +* **Proof-of-Reputation (PoR) Consumer Chains.** + ```go double_sign.slash_fraction: 0 // no slashing double_sign.jail_duration: time.Unix(253402300799, 0) downtime.slash_fraction: 0 // no slashing downtime.jail_duration: 600s ``` + This means that when validators that opt in misbehave on PoR consumer chains, their stake on the provider is not being slashed, instead they are just jailed on the provider. As a result, delegators incur (almost) no risk if their validators opt in on multiple PoR consumer chains. If their validators are jailed, then the delegators can redelegate to other validators. - Note though that delegators cannot redelegate multiple times, which means that if the new validators get also tombstoned, the delegators need to wait for the unbonding period to elapse. -- **Testnet Consumer Chains.** + Note though that delegators cannot redelegate multiple times, which means that if the new validators also get permanently jailed, the delegators need to wait for the unbonding period to elapse. +* **Testnet Consumer Chains.** + ```go double_sign.slash_fraction: 0 // no slashing double_sign.jail_duration: 0 // no jailing downtime.slash_fraction: 0 // no slashing downtime.jail_duration: 0 // no jailing ``` + This means that validators are not punished for infractions on consumer chains. - This setting is ideal for testing consumer chains before going in production as neither validators nor their delegators incur any risk from the validators opting in on this consumer chains. + This setting is ideal for testing consumer chains before going in production, as neither validators nor their delegators incur any risk from the validators opting in on these consumer chains. This means that both PoR and testnet consumer chains need only to cover the operational costs of the validators that opt in. For example, if we take `$600` as the cost of running a validator node, a budget of `$3000` will be sufficient to cover the cost of four validators running such a consumer chain and have `$150` profit per validator as incentive. @@ -131,37 +137,37 @@ In practice, this can be implemented via the per-consumer-chain commission rate The implementation of this feature involves the following steps: -- Add the `InfractionParameters` to `MsgCreateConsumer`. -- On slashing events (for either downtime or double signing infractions), use the corresponding `slash_fraction` set by the consumer chain. -- On jailing events (for either downtime or double signing infractions), use the corresponding `jail_duration` set by the consumer chain. -- Cryptographic equivocation evidence received for PoR chains results in the misbehaving validators only being tombstoned and not slashed. -- (Optional) Add the `InfractionParameters` to `MsgUpdateConsumer`, i.e., allow consumer chains to update the slashing and jailing parameters, but the changes will come into effect after a period equal to the staking module's unbonding period elapses to allow for validators to opt out. +* Add the `InfractionParameters` to `MsgCreateConsumer`. +* On slashing events (for either downtime or double signing infractions), use the corresponding `slash_fraction` set by the consumer chain. +* On jailing events (for either downtime or double signing infractions), use the corresponding `jail_duration` set by the consumer chain. +* Cryptographic equivocation evidence received for PoR chains results in the misbehaving validators only being tombstoned and not slashed. +* (Optional) Add the `InfractionParameters` to `MsgUpdateConsumer`, i.e., allow consumer chains to update the slashing and jailing parameters, but the changes will come into effect after a period equal to the staking module's unbonding period elapses to allow for validators to opt out. ## Consequences ### Positive -- Reduce the cost of ICS by removing the risk of slashing delegators. +* Reduce the cost of ICS by removing the risk of slashing delegators. ### Negative -- Reduce the economical security of consumer chains with weaker slashing conditions. +* Reduce the economical security of consumer chains with weaker slashing conditions. #### Economic Security Model without Slashing The economic security model of most Cosmos chains relies on the following properties: -- validators are not anonymous, which means that they could be legally liable if they are malicious; -- the delegated PoS mechanism creates a reputation-based network of validators; -- most validators have most of their stake coming from delegations (i.e., nothing at stake, besides reputation); -- it is relatively difficult to enter the active validator set and even more so to climb the voting power ladder. +* validators are not anonymous, which means that they could be legally liable if they are malicious; +* the delegated PoS mechanism creates a reputation-based network of validators; +* most validators have most of their stake coming from delegations (i.e., nothing at stake, besides reputation); +* it is relatively difficult to enter the active validator set and even more so to climb the voting power ladder. -These properties enables us to make the following assumption: +These properties enable us to make the following assumption: -- Being permanently removed from the provider validator set is strong enough of a deterrent to misbehaving on consumer chains. +* Being permanently removed from the provider validator set is strong enough of a deterrent to misbehaving on consumer chains. -The additional economical security a consumer gets from slashing is limited. -The reason is that slashing punishes delegators as most of the stake is delegated. +The additional economical security a consumer gets from slashing is limited: +Since most of the stake is delegated, slashing punishes delegators more than validators. One benefit of slashing is that it acts as a deterrent for someone buying a large amount of staking tokens in order to attack a consumer chain. For example, an attacker could get `$15.000.000` worth of ATOM, which would give them around `1%` voting power on the Cosmos Hub (at the time of this writing). From 090415e2e096669888f4dd16e418efc00f9ab47e Mon Sep 17 00:00:00 2001 From: Marius Poke Date: Mon, 16 Sep 2024 17:28:40 +0200 Subject: [PATCH 14/15] Update docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md Co-authored-by: insumity --- docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md index c8570ff597..b8e910d789 100644 --- a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md +++ b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md @@ -19,7 +19,7 @@ This means that the voting power of validators validating (aka producing blocks) Moreover, if these validators misbehave on the consumer chains, they get punished on the provider chain. ICS is currently differentiating between two types of infractions -- equivocation and downtime. Depending on the infraction type, the misbehaving validators might be jailed (i.e., removed from the provider validator set) and / or slashed (i.e., a portion of their stake on the provider is being burned). -For example, validators double sining on consumer chains get slashed and are permanently jailed, +For example, validators double signing on consumer chains get slashed and are permanently jailed, while validators not validating sufficient blocks are temporarily jailed. This means that ICS consumer chains get their economical security from the provider. From 5cb269a5fd9b2f722303a91632ca8ee18a6c1dd7 Mon Sep 17 00:00:00 2001 From: Marius Poke Date: Fri, 18 Oct 2024 10:41:21 +0200 Subject: [PATCH 15/15] Update docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md Co-authored-by: insumity --- docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md index b8e910d789..e83119eabf 100644 --- a/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md +++ b/docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md @@ -170,7 +170,7 @@ The additional economical security a consumer gets from slashing is limited: Since most of the stake is delegated, slashing punishes delegators more than validators. One benefit of slashing is that it acts as a deterrent for someone buying a large amount of staking tokens in order to attack a consumer chain. -For example, an attacker could get `$15.000.000` worth of ATOM, which would give them around `1%` voting power on the Cosmos Hub (at the time of this writing). +For example, an attacker could get `$15,000,000` worth of ATOM, which would give them around `1%` voting power on the Cosmos Hub (at the time of this writing). On a consumer chain, this voting power could be amplified depending on the other validators that opt in. However, by having the right [power shaping](https://cosmos.github.io/interchain-security/features/power-shaping) settings, the voting power of validators can be capped. This means that even if the attacker manages to double sign without getting slashed, as long as they don't have 1/3+ of the voting power, they cannot benefit from the attack.