Skip to content

Commit

Permalink
Incorporate comments
Browse files Browse the repository at this point in the history
  • Loading branch information
p-offtermatt committed May 15, 2024
1 parent e39785a commit 2ac71cb
Show file tree
Hide file tree
Showing 3 changed files with 14 additions and 12 deletions.
2 changes: 1 addition & 1 deletion docs/docs/features/partial-set-security.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,5 +24,5 @@ Both Opt In and Top N chains currently require a governance proposal to be added

For Top N chains, this is also the long term vision for how they are launched.

For Opt In chains, this is a temporary measure to prevent issues around chain ID squatting. Eventually, the plan is to allow launching Opt In chains permissionlessly without going through governance, with quality control being handled by the market of validators deciding which chains they would like to validate on.
For Opt In chains, this is a temporary measure to prevent issues around chain ID squatting, i.e. someone could spuriously register many desirable chain IDs of upcoming consumer chain and simply deny legitimate consumer chains from using them. Eventually, the plan is to allow launching Opt In chains permissionlessly without going through governance, with quality control being handled by the market of validators deciding which chains they would like to validate on.
:::
14 changes: 11 additions & 3 deletions docs/docs/features/power-shaping.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,21 @@ These are:
1) **Capping the size of the validator set**: The consumer chain can specify a maximum number of validators it
wants to have in its validator set. This can be used to limit the number of validators in the set, which can
be useful for chains that want to have a smaller validator set for faster blocks or lower overhead.
*Note*: This is only applicable to Opt In chains (chains with Top N = 0).
:::info
This is only applicable to Opt In chains (chains with Top N = 0).
:::
1) **Capping the fraction of power any single validator can have**: The consumer chain can specify a maximum fraction
of the total voting power that any single validator in its validator set should have.
This is a security measure with the intention of making it harder for a single large validator to take over a consumer chain. This mitigates the risk of an Opt In chain with only a few validators being dominated by a validator with a large amount of voting power opting in.
This is a security measure with the intention of making it harder for a single large validator to take over a consumer chain. This mitigates the risk of an Opt In chain with only a few validators being dominated by a validator with a large amount of stake opting in.
For example, setting this fraction to e.g. 33% would mean that no single validator can have more than 33% of the total voting power,
and thus there is no single validator who would stop the chain by going offline.
Note that this is a soft cap, and the actual power of a validator can exceed this fraction if the validator set is small (e.g. there are only 3 validators and the cap is 20%).
:::info
This is a soft cap, and the actual power of a validator can exceed this fraction if the validator set is small (e.g. there are only 3 validators and the cap is 20%).
:::
:::info
Rewards are distributed proportionally to validators with respect to their capped voting power on the consumer,
not their total voting power on the provider.
:::
1) **Allowlist and denylist**: The consumer chain can specify a list of validators that are allowed or disallowed from participating in the validator set. If an allowlist is set, all validators not on the allowlist cannot validate the consumer chain. If a validator is on both lists, the denylist takes precedence, that is, they cannot validate the consumer chain. If neither list is set, all validators are able to validate the consumer chain.

:::warning
Expand Down
10 changes: 2 additions & 8 deletions docs/docs/frequently-asked-questions.md
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ To become a consumer chain use this [checklist](./consumer-development/onboardin

Currently supported versions:

- Hermes 1.4.1
- Hermes 1.8.0

## How does key delegation work in ICS?

Expand All @@ -117,7 +117,7 @@ Yes, see the [Key Assignment Guide](./features/key-assignment.md) for more infor
## Can validators assign a consensus key during the voting period for a consumer-addition proposal if they are not in the top N?
Yes.

## Can validators opt in to an Opt-in chain after its consumer-addition proposal voting period is over but before the spawn time?
## Can validators opt in to an Opt-in or Top N chain after its consumer-addition proposal voting period is over but before the spawn time?
Yes.

## Can validators opt in to an Opt-in chain after the spawn time if nobody else opted in?
Expand All @@ -129,9 +129,3 @@ Yes, the consumer chain will halt with an ERR CONSENSUS FAILURE error after the
## Can validators set a commission rate for chains they have not opted in to?
Yes, and this is useful for validators that are not in the top N% of the provider chain, but might move into the top N% in the future.
By setting the commission rate ahead of time, they can make sure that they immediately have a commission rate of their choosing as soon as they are in the top N%.

## On how many consumer chains can a validator opt-in at the same time?

There is no limit to the number of consumer chains a validator can opt in to.
However, some consumer chains may restrict the validators actually getting to validate there, for example consumer chains can set up denylists to stop certain validators from validating there.
See the [Power Shaping](./features/power-shaping.md) section for more information.

0 comments on commit 2ac71cb

Please sign in to comment.