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.

Sign up for GitHub

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

Jump to bottom

chore: fix typos #2389

Merged
merged 2 commits into from
Nov 11, 2024
Merged

chore: fix typos #2389

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
445b3be
fix typos
omahs Nov 8, 2024
05a3e42
fix typos
omahs Nov 8, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 22 additions & 22 deletions docs/docs/build/modules/02-provider.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ toc_max_heading_level: 5

The ICS provider module enables a proof-of-stake chain (known as the provider chain)
to share (parts of) its security with other chains (known as consumer chains).
This basically mean that consumer chains can run as proof-of-stake chains using
This basically means that consumer chains can run as proof-of-stake chains using
(parts of) the stake locked on the provider as collateral.

The provider module has the following functionalities:
Expand All @@ -19,11 +19,11 @@ The provider module has the following functionalities:
- The customization of the consumer chains validator sets.
- The option for validators to opt in to validate the consumer chains they want.
- The distribution of rewards from consumer chains to the opted in validators.
- The slashing and jailing of validators commiting infractions on consumer chains based on cryptographic evidence.
- The slashing and jailing of validators committing infractions on consumer chains based on cryptographic evidence.

## State

For clarity, the description of the the provider module state is split into features.
For clarity, the description of the provider module state is split into features.
For a more accurate description, check out the `x/ccv/provider/types/keys.go` file, which contains the definitions of all the keys.

### Consumer Lifecycle
Expand Down Expand Up @@ -144,7 +144,7 @@ Format: `byte(53) | len(clientId) | []byte(clientId) -> string`
Format: `byte(14) | []byte(consumerId) -> ConsumerGenesisState`


### Key Assingment
### Key Assignment

#### ConsumerValidators

Expand All @@ -162,7 +162,7 @@ Format: `byte(23) | len(consumerId) | []byte(consumerId) | addr -> sdk.ConsAddre

#### ConsumerAddrsToPruneV2

`ConsumerAddrsToPruneV2` stores the list of consumer consensus addresses that can be prunned at a timestamp `ts` as they are no longer needed.
`ConsumerAddrsToPruneV2` stores the list of consumer consensus addresses that can be pruned at a timestamp `ts` as they are no longer needed.

Format: `byte(40) | len(consumerId) | []byte(consumerId) | ts -> AddressList`, where `AddressList` is defined as

Expand Down Expand Up @@ -215,7 +215,7 @@ Format: `byte(36) | len(consumerId) | []byte(consumerId) | addr -> []byte{}`, wi
#### Denylist

`Denylist` is the list of provider validators that are not eligible to validate a given consumer chain.
Note that validator can opt in regardless of whether they are eligible or not.
Note that validators can opt in regardless of whether they are eligible or not.

Format: `byte(37) | len(consumerId) | []byte(consumerId) | addr -> []byte{}`, with `addr` the validator's consensus address on the provider chain.

Expand Down Expand Up @@ -277,7 +277,7 @@ message ConsensusValidator {
#### ConsumerRewardDenoms

`ConsumerRewardDenoms` is storing the list of whitelisted denoms that are accepted as ICS rewards.
Note that denoms that are not whitelisted can still be transfer to the `consumer_rewards_pool` account on the provider module, but they will not be distributed to validators and their delegators.
Note that denoms that are not whitelisted can still be transferred to the `consumer_rewards_pool` account on the provider module, but they will not be distributed to validators and their delegators.

Format: `byte(27) | []byte(denom) -> []byte{}`

Expand Down Expand Up @@ -375,7 +375,7 @@ The consumer module is an IBC application that implements the [IBC module callba

`OnChanOpenTry` validates the parameters of the _CCV channel_ -- an ordered IBC channel connected on the `provider` port
and with the counterparty port set to `consumer` -- and asserts that the counterparty version matches the expected version
(only verions `1` is supported).
(only version `1` is supported).

If the validation passes, the provider module verifies that the underlying client is the expected client of the consumer chain
(i.e., the client created during the consumer chain launch) and that no other CCV channel exists for this consumer chain.
Expand Down Expand Up @@ -489,11 +489,11 @@ The owner of the created consumer chain is the submitter of the message.
This message cannot be submitted as part of a governance proposal, i.e., the submitter cannot be the gov module account address.
As a result, if the `power_shaping_parameters` are provided, then `power_shaping_parameters.top_N` must be set to zero (i.e., opt-in consumer chain).

To create a top-n consumer chain, the following steps are require:
To create a top-n consumer chain, the following steps are required:

- Create a opt-in consumer chain (via `MsgCreateConsumer`).
- Change the ownership of the consuemr chain to the gov module account address (via `MsgUpdateConsumer`).
- Change `power_shaping_parameters.top_N` to a value in `[50, 100]` trough a governance proposal with a `MsgUpdateConsumer` message.
- Create an opt-in consumer chain (via `MsgCreateConsumer`).
- Change the ownership of the consumer chain to the gov module account address (via `MsgUpdateConsumer`).
- Change `power_shaping_parameters.top_N` to a value in `[50, 100]` through a governance proposal with a `MsgUpdateConsumer` message.

If the `initialization_parameters` field is set and `initialization_parameters.spawn_time > 0`, then the consumer chain will be scheduled to launch at `spawn_time`.

Expand Down Expand Up @@ -524,7 +524,7 @@ message MsgCreateConsumer {
`MsgUpdateConsumer` enables the owner of a consumer chain to update its parameters (e.g., set a new owner).

Note that only the `owner` (i.e., signer) and `consumer_id` fields are mandatory.
The others field are optional. Not providing one of them will leave the existing values unchanged.
The others fields are optional. Not providing one of them will leave the existing values unchanged.
Providing one of `metadata`, `initialization_parameters`, `power_shaping_parameters`, or `allowlisted_reward_denoms`
will update all the containing fields.
If one of the containing fields is missing, it will be set to its zero value.
Expand Down Expand Up @@ -606,7 +606,7 @@ You can use the `list-consumer-chains` query to get the list of all consumer cha

The `consumer_key` field is optional.
It enables the validator to set the consensus public key to use on the consumer chain.
The validator can assing (or re-assing) this key also later via [MsgAssignConsumerKey](#msgassignconsumerkey).
The validator can assign (or re-assign) this key also later via [MsgAssignConsumerKey](#msgassignconsumerkey).

:::warning
Validators are strongly recommended to assign a separate key for each consumer chain
Expand Down Expand Up @@ -758,7 +758,7 @@ message MsgSetConsumerCommissionRate {

### MsgSubmitConsumerMisbehaviour

`MsgSubmitConsumerMisbehaviour` enables users to submit to the provider evidence of a light client attack that occured on a consumer chain.
`MsgSubmitConsumerMisbehaviour` enables users to submit to the provider evidence of a light client attack that occurred on a consumer chain.
This message can be submitted directly by users, e.g., via the CLI command `tx provider submit-consumer-misbehaviour`,
or by a relayer that can be set to automatically detect consumer chain misbehaviors, e.g., [Hermes](https://github.com/informalsystems/hermes).

Expand All @@ -768,7 +768,7 @@ the `chain_id` field is deprecated.
Users should use `consumer_id` instead.
You can use the `list-consumer-chains` query to get the list of all consumer chains and their consumer IDs.

For more details on reporting light client attacks that occured on consumer chains, check out the [guide on equivocation infractions](../../features/slashing.md#equivocation-infractions).
For more details on reporting light client attacks that occurred on consumer chains, check out the [guide on equivocation infractions](../../features/slashing.md#equivocation-infractions).

```proto
message MsgSubmitConsumerMisbehaviour {
Expand All @@ -787,7 +787,7 @@ message MsgSubmitConsumerMisbehaviour {

### MsgSubmitConsumerDoubleVoting

`MsgSubmitConsumerDoubleVoting` enables users to submit to the provider evidence of a double signing infraction that occured on a consumer chain.
`MsgSubmitConsumerDoubleVoting` enables users to submit to the provider evidence of a double signing infraction that occurred on a consumer chain.
This message can be submitted directly by users, e.g., via the CLI command `tx provider submit-consumer-double-voting`,
or by a relayer that can be set to automatically detect consumer chain misbehaviors, e.g., [Hermes](https://github.com/informalsystems/hermes).

Expand All @@ -797,7 +797,7 @@ the `chain_id` field is deprecated.
Users should use `consumer_id` instead.
You can use the `list-consumer-chains` query to get the list of all consumer chains and their consumer IDs.

For more details on reporting double signing infractions that occured on consumer chains, check out the [guide on equivocation infractions](../../features/slashing.md#equivocation-infractions).
For more details on reporting double signing infractions that occurred on consumer chains, check out the [guide on equivocation infractions](../../features/slashing.md#equivocation-infractions).

```proto
message MsgSubmitConsumerDoubleVoting {
Expand Down Expand Up @@ -841,7 +841,7 @@ In the `EndBlock` of the provider module the following actions are performed:
- Prune the no-longer needed public keys assigned by validators to use when validating on consumer chains.
- Send validator updates to the consensus engine.
The maximum number of validators is set through the [MaxProviderConsensusValidators](#maxproviderconsensusvalidators) param.
- At the begining of every epoch,
- At the beginning of every epoch,
- for every launched consumer chain, compute the next consumer validator set and send it to the consumer chain via an IBC packet;
- increment the VSC id.

Expand Down Expand Up @@ -872,7 +872,7 @@ The provider module contains the following parameters.

`TrustingPeriodFraction` is used to used to compute the trusting period of IBC clients
(for both provider and consumer chains) as `UnbondingPeriod / TrustingPeriodFraction`.
Note that a light clients must be updated within the trusting period in order to avoid being frozen.
Note that a light client must be updated within the trusting period in order to avoid being frozen.

The param is set as a string, and converted to a `sdk.Dec` when used.

Expand Down Expand Up @@ -938,7 +938,7 @@ which might impact the security of the consumer chains.
| int64 | 24 |

`NumberOfEpochsToStartReceivingRewards` is the number of ICS epochs that a validator
needs to wait after opting in on a consumer chain before being eligible to ICS reawards
needs to wait after opting in on a consumer chain before being eligible to ICS rewards
from that consumer.

### MaxProviderConsensusValidators
Expand All @@ -948,7 +948,7 @@ from that consumer.
| int64 | 180 |

`MaxProviderConsensusValidators` is the maximum number of validators sent to
the provider consensus enginer.
the provider consensus engine.
This was introduced with the [Inactive Provider Validators feature](https://cosmos.github.io/interchain-security/adrs/adr-017-allowing-inactive-validators)
and it replaces the `MaxValidators` staking module parameter.
As a result, the provider chain can differentiate between
Expand Down
20 changes: 10 additions & 10 deletions docs/docs/build/modules/03-consumer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ The ICS consumer module enables consumer chains to use stake locked on a provide
as collateral for their own proof-of-stake based block production.

The consumer module established a IBC ordered channel to the provider chain.
This channel is used by the provider chain to regularly sent validator updates the the consumer chain.
This channel is used by the provider chain to regularly send validator updates to the consumer chain.
The consumer sends these updates to its own consensus engine.
This means that the consumer module acts as a staking module of the consumer chain.

Expand All @@ -25,7 +25,7 @@ As a result, the misbehaving validator is punished on the provider chain.

## State

For clarity, the description of the the consumer module state is split into features.
For clarity, the description of the consumer module state is split into features.
For a more accurate description, check out the `x/ccv/consumer/types/keys.go` file, which contains the definitions of all the keys.

### Provider Connection
Expand Down Expand Up @@ -119,7 +119,7 @@ message CrossChainValidator {
`HistoricalInfo` is the header and validator information for a given block.
For more details, see the [Cosmos SDK docs](https://docs.cosmos.network/v0.50/build/modules/staking#historicalinfo).

Format: `byte(11) | height -> HistoricalInfo`, where `HistoricalInfo` is define in the staking module as
Format: `byte(11) | height -> HistoricalInfo`, where `HistoricalInfo` is defined in the staking module as

```proto
message HistoricalInfo {
Expand Down Expand Up @@ -213,7 +213,7 @@ The consumer module is an IBC application that implements the [IBC module callba
`OnChanOpenInit` first verifies that the CCV channel was not already created.
Then, it validates the channel parameters -- an ordered IBC channel connected on the `consumer` port
and with the counterparty port set to `provider` -- and asserts that the version matches the expected version
(only verions `1` is supported).
(only version `1` is supported).

Finally, it verifies that the underlying client is the expected client of the provider chain
(i.e., provided in the consumer module genesis state).
Expand All @@ -226,12 +226,12 @@ Finally, it verifies that the underlying client is the expected client of the pr

`OnChanOpenAck` first verifies that the CCV channel was not already created.
Then it verifies that the counterparty version matches the expected version
(only verions `1` is supported).
(only version `1` is supported).

If the verification passes, it stores the [ProviderFeePoolAddr](#providerfeepooladdrstr) in the state.

Finally, if the [DistributionTransmissionChannel](#distributiontransmissionchannel) parameter is not set,
it initiate the opening handshake for a token transfer channel over the same connection as the CCV channel
it initiates the opening handshake for a token transfer channel over the same connection as the CCV channel
by calling the `ChannelOpenInit` method of the IBC module.

### OnChanOpenConfirm
Expand All @@ -240,7 +240,7 @@ by calling the `ChannelOpenInit` method of the IBC module.

### OnChanCloseInit

`OnChanCloseInit` allow relayers to close duplicate OPEN channels, if the channel handshake is completed.
`OnChanCloseInit` allows relayers to close duplicate OPEN channels, if the channel handshake is completed.

### OnChanCloseConfirm

Expand Down Expand Up @@ -303,7 +303,7 @@ message MsgUpdateParams {
In the `BeginBlock` of the consumer module the following actions are performed:

- Store in state the block height to VSC id mapping needed for sending to the provider the height of infractions committed on the consumer chain.
- Track historical entries. This is the same lofic as in the `x/staking` module.
- Track historical entries. This is the same logic as in the `x/staking` module.

## EndBlock

Expand All @@ -313,7 +313,7 @@ In the `EndBlock` of the consumer module the following actions are performed:
that was just upgraded to include the consumer module, then execute the [changeover logic](../../consumer-development/changeover-procedure.md).
- Otherwise, distribute block rewards internally and once every [BlocksPerDistributionTransmission](#blocksperdistributiontransmission) send
ICS rewards to the provider chain.
- Send slash packets to the provider chain reporting infractions validators commited on the consumer chain.
- Send slash packets to the provider chain reporting infractions validators committed on the consumer chain.
- Send to the consensus engine validator updates reveived from the provider chain.

## Hooks
Expand All @@ -328,7 +328,7 @@ In the `EndBlock` of the consumer module the following actions are performed:

:::warning
The consumer module parameters are set by the provider when creating the consumer genesis (i.e., when launching the consumer chain).
As a result, changes of these parameters might results in incompatibilities between different versions of consumers and providers.
As a result, changes of these parameters might result in incompatibilities between different versions of consumers and providers.
:::

The consumer module contains the following parameters.
Expand Down
Loading