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: ADR for Customizable Slashing and Jailing #2146

Merged
merged 24 commits into from
Oct 18, 2024
Merged

Conversation

mpoke
Copy link
Contributor

@mpoke mpoke commented Aug 14, 2024

Description

Closes: #XXXX


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct docs: prefix in the PR title
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • Confirmed the correct docs: prefix in the PR title
  • Confirmed all author checklist items have been addressed
  • Confirmed that this PR only changes documentation
  • Reviewed content for consistency
  • Reviewed content for spelling and grammar
  • Tested instructions (if applicable)
  • Checked that the documentation website can be built and deployed successfully (run make build-docs)

Summary by CodeRabbit

  • New Features

    • Introduced a new document outlining "Proof of Reputation Consumer Chains" to enhance blockchain security and reduce operational costs.
    • Proposed a shift from traditional slashing penalties to a reputational system for validators, promoting safer redelegation for delegators.
    • Added a document on "Customizable Slashing and Jailing," enabling consumer chains to tailor slashing and jailing conditions based on validator infractions.
  • Documentation

    • Provided detailed implementation steps and operational cost management strategies for validators under the new frameworks.

@mpoke mpoke requested a review from a team as a code owner August 14, 2024 15:25
Copy link
Contributor

coderabbitai bot commented Aug 14, 2024

📝 Walkthrough
📝 Walkthrough

Walkthrough

The proposed changes introduce a "Proof of Reputation Consumer Chains" model and a "Customizable Slashing and Jailing" framework to enhance Interchain Security (ICS) within the Cosmos ecosystem. These models aim to reduce operational costs for validators and delegators by modifying the consequences of validator misbehavior and allowing consumer chains to tailor slashing rules. The changes include adjustments to specific proposals to facilitate these updates, promoting broader validator participation in consumer chains.

Changes

Files Change Summary
docs/docs/adrs/adr-020-proof-of-reputation.md Introduced the concept of Proof of Reputation (PoR) for consumer chains, detailing changes to the ConsumerAdditionProposal to support PoR launches.
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md Established customizable slashing and jailing parameters for validator infractions, introducing new InfractionParameters and SlashJailParameters declarations.

Possibly related PRs

Suggested labels

C:x/provider, C:x/consumer


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added C:Docs Assigned automatically by the PR labeler C:ADR Assigned automatically by the PR labeler labels Aug 14, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (5)
docs/docs/adrs/adr-020-proof-of-reputation.md (5)

14-38: Context: Remove trailing spaces.

The context is well-explained. Consider removing trailing spaces for cleaner formatting.

- 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. 
+ 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.
Tools
Markdownlint

16-16: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


18-18: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


24-24: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


25-25: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


26-26: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


28-28: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


29-29: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


33-33: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


36-36: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


38-38: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


52-63: Security Model: Fix unordered list style.

The security model is well-structured. Consider using asterisks for unordered lists to adhere to markdown standards.

- - 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.
Tools
Markdownlint

56-56: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


57-57: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


58-58: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


59-59: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


61-61: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


62-62: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


74-81: Implementation: Simplify language and fix unordered list style.

The implementation steps are clear. Consider simplifying language and using asterisks for unordered lists.

- - 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.    
+ * Add a field to `ConsumerAdditionProposal` to enable consumer chains to launch as PoR chains.
+ * Disable opt-in to PoR consumer chains for validators outside 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 the unbonding period to allow for validators to opt-out.
Tools
LanguageTool

[style] ~79-~79: This phrase is redundant. Consider using “outside”.
Context: ...n to PoR consumer chains for validators outside of the provider's active set. - Cryptograp...

(OUTSIDE_OF)

Markdownlint

78-78: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


79-79: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


80-80: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


81-81: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


81-81: Expected: 0 or 2; Actual: 4
Trailing spaces

(MD009, no-trailing-spaces)


83-95: Consequences: Fix unordered list style.

The consequences are clearly categorized. Consider using asterisks for unordered lists.

- - Reduce the cost of ICS be removing the risk of slashing delegators.
- - Reduce the economical security provided to PoR consumer chains. 
- - [Inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt in on PoR consumer chains
+ * Reduce the cost of ICS by removing the risk of slashing delegators.
+ * Reduce the economical security provided to PoR consumer chains.
+ * [Inactive validators](./adr-017-allowing-inactive-validators.md) are ineligible to opt-in on PoR consumer chains.
Tools
Markdownlint

87-87: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


91-91: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


95-95: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


91-91: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


97-99: References: Consider adding content or removing the section.

The references section is empty. Consider adding relevant references or removing the section if not needed.

Tools
Markdownlint

99-99: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)

@jtremback
Copy link
Contributor

jtremback commented Aug 15, 2024

I'll just comment on the most important part here:

### 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.  

I think that too much theory is being bundled into this proposal and this implementation plan reflects that. Let's just add few new settings that consumer chain owners can set and modify as they wish.

slash_for_equivocation: bool
tombstone_for_equivocation: bool
slash_for_downtime: bool
jail_for_downtime: bool
allow_inactive_validators: bool

Now if they want something that matches your PoR concept, they can just set these flags in the right way.

I think the inactive validators ADR probably already has something like allow_inactive_validators.

- (Optional) PoR consumer chains can switch to PoS chains, but the transition takes at least unbonding period to allow for validators to opt out.

This is a good one. @sainoe is working on a mechanism like this for fault resolutions. We should get on a call to discuss whether it should be applied more broadly to other consumer chain settings.

@mpoke
Copy link
Contributor Author

mpoke commented Aug 16, 2024

slash_for_equivocation: bool
tombstone_for_equivocation: bool
slash_for_downtime: bool
jail_for_downtime: bool
allow_inactive_validators: bool

@jtremback allow_inactive_validators is indeed part of the power shaping config as a result of the inactive validators feature

I agree that we could do as you suggest for the rest to allow for more general configurations. I would then make the slashing ones to be slashing ratios instead of bools. For example, a consumer can have slash_for_equivocation set to 1%. For starters, we can bound these values to the slashing ratios on the Hub (i.e., slash_for_equivocation for any consumer cannot be larger than 5%).

To improve UX, we can set some defaults in Forge:

  • PoS consumer chain
slash_for_equivocation: 5%
tombstone_for_equivocation: true
slash_for_downtime: 0%
jail_for_downtime: true
  • PoR consumer chain
slash_for_equivocation: 0%
tombstone_for_equivocation: true
slash_for_downtime: 0%
jail_for_downtime: true
  • testnet chains
slash_for_equivocation: 0%
tombstone_for_equivocation: false
slash_for_downtime: 0%
jail_for_downtime: false

@mpoke mpoke changed the title docs: ADR for Proof of Reputation Consumer Chains docs: ADR for Customizable Slashing and Jailing Aug 23, 2024
@mpoke
Copy link
Contributor Author

mpoke commented Aug 23, 2024

@jtremback I updated the ADR to allow consumer chain owners to set their own slashing and jailing params.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

Outside diff range, codebase verification and nitpick comments (1)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (1)

177-179: Consider adding references or removing the section.

The references section is empty. Add relevant references or remove the section if not needed.

Tools
Markdownlint

179-179: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (4)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (4)

17-48: Consider improving conciseness and remove trailing spaces.

The context is informative but could be more concise in some parts. Additionally, there are trailing spaces that should be removed.

Apply this diff to address the issues:

 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.
+The voting power of validators on consumer chains is a function of their stake on 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.
+ICS differentiates 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.

-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.
+One cost of validating on 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 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.
+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.
 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.
+  As validators don't need their own stake, delegators might take all the risk of misbehavior.
 * 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.
+  This applies to their delegators as well.
   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.

-Misbehaviors don't need to be malicious, e.g., most cases of double signing infractions are due to misconfiguration.
+Misbehaviors aren't always malicious; most double signing infractions result from 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.

 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.
Tools
LanguageTool

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)

Markdownlint

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


54-58: Decision is clear, but remove trailing spaces.

The decision section is well-articulated, but trailing spaces should be removed for consistency.

Apply this diff to remove trailing spaces:

 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.
+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.
Tools
Markdownlint

56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


136-144: Improve list formatting and remove trailing spaces.

The implementation section is detailed, but list formatting can be improved, and trailing spaces should be removed.

Apply this diff to address the issues:

 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.
Tools
Markdownlint

144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)


146-181: Enhance conciseness and remove trailing spaces.

The consequences section is informative but could be more concise in some areas. Trailing spaces should also be removed.

Apply this diff to address the issues:

 ### Positive

-* Reduce the cost of ICS by removing the risk of slashing delegators.
+* Reduce the cost of ICS by eliminating the risk of slashing delegators.

 ### Negative

-* Reduce the economical security of consumer chains with weaker slashing conditions.
+* Decrease the economic 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;
+* Validators are not anonymous, meaning they could be legally liable if 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);
+* Most validators have their stake primarily 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 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.
+* Permanent removal from the provider validator set is a strong deterrent to misbehavior on consumer chains.

 The additional economical security a consumer gets from slashing is limited:
-Since most of the stake is delegated, slashing punishes delegators more than validators.
+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 acquire `$15,000,000` worth of ATOM, granting them around `1%` voting power on the Cosmos Hub (at the time of 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.
 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).

 ### Neutral

-NA
+N/A
Tools
LanguageTool

[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

Markdownlint

169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)

* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about inactive validators?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could disable this for inactive validators. Or even better, users should choose their configuration.


For every consumer chain, we introduce the following slashing and jailing parameters:
```proto
message InfractionParameters {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we also want to parameterize (i.e., enable/disable) fault resolutions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fault resolutions are not implemented yet.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range and nitpick comments (1)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (1)

183-185: Consider adding references if applicable.

The "References" section is currently empty. If there are any relevant external references that were used in the creation of this ADR or that could provide additional context or support for the proposed changes, consider adding them to this section.

Tools
Markdownlint

185-185: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 58d87fa and 090415e.

Files selected for processing (1)
  • docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (1 hunks)
Additional context used
LanguageTool
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)


[uncategorized] ~116-~116: The preposition “in” seems more likely in this position than the preposition “on”.
Context: ...ave on PoR consumer chains, their stake on the provider is not being slashed, inst...

(AI_EN_LECTOR_REPLACEMENT_PREPOSITION_ON_IN)


[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

Markdownlint
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


50-50: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


51-51: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


77-77: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


85-85: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


86-86: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


88-88: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


96-96: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


98-98: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


107-107: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


116-116: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


118-118: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


119-119: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


129-129: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


130-130: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


132-132: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


134-134: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)


169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


185-185: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)


7-7: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


5-5: null
Multiple top-level headings in the same document

(MD025, single-title, single-h1)


60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


80-80: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


85-85: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


90-90: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


8-8: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)

Additional comments not posted (5)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (5)

15-49: The "Context" section provides a clear and concise background.

The section effectively highlights the current state of ICS and the challenges associated with the high cost of validating on consumer chains. It explains the risks incurred by validators and their delegators, and how this leads to the need for compensation, making the current design of ICS expensive.

Tools
LanguageTool

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)

Markdownlint

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


54-135: The "Decision" section provides a well-structured proposal.

The section clearly outlines the proposed changes to allow consumer chains to customize slashing and jailing parameters. The introduction of the InfractionParameters and SlashJailParameters message structures, along with the default values and recommended settings for different types of consumer chains, demonstrates a thoughtful approach to reducing the cost of ICS while maintaining flexibility for consumer chains.

Tools
LanguageTool

[uncategorized] ~116-~116: The preposition “in” seems more likely in this position than the preposition “on”.
Context: ...ave on PoR consumer chains, their stake on the provider is not being slashed, inst...

(AI_EN_LECTOR_REPLACEMENT_PREPOSITION_ON_IN)

Markdownlint

56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


77-77: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


85-85: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


86-86: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


88-88: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


96-96: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


98-98: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


107-107: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


116-116: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


118-118: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


119-119: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


129-129: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


130-130: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


132-132: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


134-134: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


80-80: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


85-85: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


90-90: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


136-145: The "Implementation" section provides clear steps.

The implementation steps outlined in this section are clear and concise. The changes to MsgCreateConsumer and MsgUpdateConsumer, along with the use of the consumer chain's slash_fraction and jail_duration, ensure that the customized parameters are applied correctly. The special handling of cryptographic equivocation evidence for PoR chains aligns with the goal of reducing the risk for validators.

Tools
Markdownlint

144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)


146-182: The "Consequences" section provides a balanced analysis.

The section presents a balanced view of the proposed changes by discussing both the positive and negative consequences. The reduction of the cost of ICS is a significant benefit for validators and their delegators, while the potential reduction of the economical security of consumer chains with weaker slashing conditions is a valid concern. The economic security model without slashing, which relies on the properties of the Cosmos ecosystem, provides a reasonable justification for the proposed changes.

Tools
LanguageTool

[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

Markdownlint

169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


60-76: The message structures are well-defined.

The InfractionParameters and SlashJailParameters message structures are well-defined and clearly represent the infraction parameters. The use of SlashJailParameters for both double sign and downtime infractions allows for customization of each type of infraction. The slash_fraction field uses appropriate custom scalar types and annotations for compatibility with the Cosmos SDK, and the jail_duration field uses the standard google.protobuf.Duration type for representing time durations.

Tools
Markdownlint

60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (4)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (4)

15-50: Consider minor stylistic improvements for clarity.

The Context section provides a comprehensive background on ICS and its associated costs. However, consider the following improvements:

  1. Line 39: Rephrase for conciseness. Suggestion: "As validators may not have their own stake, delegators could bear the full risk of validator misbehavior."
  2. Line 41: Move "also" before "applies" for better flow.
  3. Line 48: Consider breaking this long sentence into two for better readability.

These changes will enhance the overall clarity and flow of the section.

🧰 Tools
🪛 LanguageTool

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)

🪛 Markdownlint

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


50-50: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


146-177: Enhance clarity of the economic security model explanation.

The Consequences section provides a good overview of the positive and negative impacts. To improve the explanation of the economic security model without slashing:

  1. Consider using bullet points or a numbered list to clearly outline the steps in the potential attack scenario.
  2. Elaborate on how power shaping and token toxicity mitigate the risks of attacks, providing more concrete examples if possible.

These changes will help readers better understand the security implications of the proposed changes.

🧰 Tools
🪛 LanguageTool

[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

🪛 Markdownlint

169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


183-185: Consider adding relevant references.

The References section is currently empty. Consider adding links to relevant resources, such as:

  1. Cosmos Interchain Security documentation
  2. Papers or articles discussing slashing and jailing mechanisms in PoS systems
  3. Any external discussions or proposals that influenced this ADR

These references would provide valuable context and further reading for those interested in the topic.

🧰 Tools
🪛 Markdownlint

185-185: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)


1-185: Fix minor formatting issues throughout the document.

Please address the following formatting issues:

  1. Remove trailing spaces at the end of lines throughout the document.
  2. Ensure consistent use of asterisks (*) for unordered lists instead of dashes (-).
  3. Remove extra blank lines at the end of the document, leaving only one.
  4. Add blank lines before and after code blocks for better readability.

These changes will improve the overall formatting and consistency of the document.

🧰 Tools
🪛 LanguageTool

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)


[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

🪛 Markdownlint

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


50-50: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


51-51: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


77-77: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


85-85: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


86-86: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


88-88: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


96-96: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


98-98: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


107-107: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


116-116: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


118-118: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


119-119: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


129-129: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


130-130: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


132-132: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


134-134: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)


169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


185-185: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)


7-7: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


5-5: null
Multiple top-level headings in the same document

(MD025, single-title, single-h1)


60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


80-80: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


85-85: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


90-90: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


8-8: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 090415e and 5cb269a.

📒 Files selected for processing (1)
  • docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md

[style] ~39-~39: For conciseness, try rephrasing this sentence.
Context: ...ors don't need to have their own stake, it is possible that delegators take all the risk of validators misbehaving....

(MAY_MIGHT_BE)


[style] ~172-~172: Consider a shorter alternative to avoid wordiness.
Context: ...buying a large amount of staking tokens in order to attack a consumer chain. For example, ...

(IN_ORDER_TO_PREMIUM)

🪛 Markdownlint
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md

17-17: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


19-19: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


20-20: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


22-22: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


30-30: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


31-31: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


34-34: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


35-35: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


40-40: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


41-41: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


44-44: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


46-46: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


48-48: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


50-50: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


51-51: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


77-77: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


85-85: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


86-86: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


88-88: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


96-96: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


98-98: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


107-107: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


116-116: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


118-118: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


119-119: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


129-129: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


130-130: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


132-132: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


134-134: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)


169-169: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


172-172: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


175-175: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


176-176: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


185-185: Expected: 1; Actual: 2
Multiple consecutive blank lines

(MD012, no-multiple-blanks)


7-7: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


5-5: null
Multiple top-level headings in the same document

(MD025, single-title, single-h1)


60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


80-80: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


85-85: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


90-90: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


8-8: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)

🔇 Additional comments (3)
docs/docs/adrs/adr-020-cutomizable_slashing_and_jailing.md (3)

1-14: LGTM: Document header and changelog are well-structured.

The frontmatter, title, and changelog are properly formatted. The status is correctly set to "Proposed" for this new ADR.

🧰 Tools
🪛 Markdownlint

7-7: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


5-5: null
Multiple top-level headings in the same document

(MD025, single-title, single-h1)


8-8: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)


54-135: LGTM: Well-structured decision with clear guidelines.

The Decision section effectively outlines the customizable slashing and jailing parameters, providing clear definitions, default values, and update mechanisms. The recommendations for different types of consumer chains are particularly helpful.

🧰 Tools
🪛 Markdownlint

56-56: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


77-77: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


85-85: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


86-86: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


88-88: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


96-96: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


98-98: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


107-107: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


116-116: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


118-118: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


119-119: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


129-129: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


130-130: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


132-132: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


134-134: Expected: 0 or 2; Actual: 1
Trailing spaces

(MD009, no-trailing-spaces)


60-60: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


76-76: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


80-80: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


85-85: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


90-90: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


163-163: Clarify handling of inactive validators.

The document mentions the difficulty of entering the active validator set and climbing the voting power ladder. However, it doesn't address how inactive validators are handled in this customizable slashing and jailing framework. Could you please clarify if there are any specific considerations or parameters for inactive validators?

Comment on lines +136 to +144
### Implementation

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Consider including fault resolutions in the implementation plan.

The implementation steps are well-defined. However, consider adding a step to parameterize (enable/disable) fault resolutions, as mentioned in a previous comment. This would provide a more comprehensive implementation plan and align with the overall goal of customizable security measures.

🧰 Tools
🪛 Markdownlint

144-144: Expected: 0 or 2; Actual: 3
Trailing spaces

(MD009, no-trailing-spaces)

@mpoke mpoke merged commit da02ef3 into main Oct 18, 2024
13 checks passed
@mpoke mpoke deleted the marius/por_consumers_adr branch October 18, 2024 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:ADR Assigned automatically by the PR labeler C:Docs Assigned automatically by the PR labeler
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants