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: update docs to capture Permissionless ICS #2289

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

insumity
Copy link
Contributor

@insumity insumity commented Sep 19, 2024

Description

This is a first attempt at updating the docs to capture the latest Permissionless ICS changes.
This PR does not yet change the docs under:

  • docs/docs/validators/changeover-procedure.md
  • docs/docs/validators/joining-neutron.md
  • docs/docs/validators/joining-stride.md

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)

@github-actions github-actions bot added C:Docs Assigned automatically by the PR labeler C:ADR Assigned automatically by the PR labeler labels Sep 19, 2024
@@ -171,7 +171,7 @@ message MsgCreateConsumer {
}
```

Note that `metadata` is a required field, while the `initialization_parameterrs` and `power_shaping_parameters` are optional and can later be set using `MsgUpdateConsumer`.
Note that `metadata` is a required field, while the `initialization_parameters` and `power_shaping_parameters` are optional and can later be set using `MsgUpdateConsumer`.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Took into account older comments that were added after the PR got merged.

@@ -28,9 +29,10 @@ A major feature of Interchain Security (also referred to as "Interchain Security
This subset can be determined by the top N% validators by voting power, or by validators opting in to validate the consumer chain.
PSS allows for more flexible security tradeoffs than Replicated Security.

## Mesh Security
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 do not talk about Mesh security anywhere else so I think we can remove.

This is a security measure that makes it harder for a single large validator to take over a consumer chain:
It mitigates the risk of an Opt In chain with only a few validators being dominated by a validator with a large amount of stake.
For example, setting this fraction to 33% would mean that no single validator can have more than 33% of the total voting power on the consumer, and thus no single validator would be able to stop the consumer by going offline.
The consumer chain can specify a _power cap_ which corresponds to the maximum power (percentage-wise) a validator can have on the consumer chain.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

People seemed to have difficulty understanding the validators power cap, so adding more examples here to make it more accessible. (cc @ve6a)

To avoid spam, the provider must whitelist denoms before accepting them as ICS rewards.

## Reward distribution with power capping

If a consumer chain has set a [validators-power cap](./power-shaping#capping-the-validator-powers), then the total received
Copy link
Contributor Author

@insumity insumity Sep 19, 2024

Choose a reason for hiding this comment

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

@ve6a, I'm adding more information here on the reward distribution to hopefully make it more understandable to users. Let me know if there are any concerns.

To avoid spam, the provider must whitelist denoms before accepting them as ICS rewards.

## Reward distribution with power capping
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @ve6a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:backport/v6.1.x 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.

2 participants