From a2d13693c93e56d7f8eaf61fd203e3385e3d4f70 Mon Sep 17 00:00:00 2001 From: kogisin Date: Fri, 7 Apr 2023 13:53:11 +0900 Subject: [PATCH] fix: fix typos and fix to use correct links --- docs/docs/consumer-development/app-integration.md | 2 +- docs/docs/consumer-development/onboarding.md | 2 +- docs/docs/features/proposals.md | 6 +++--- docs/docs/features/reward-distribution.md | 2 +- docs/docs/features/slashing.md | 4 ++-- docs/docs/frequently-asked-questions.md | 12 ++++++------ docs/docs/validators/joining-testnet.md | 2 +- docs/docs/validators/overview.md | 4 ++-- 8 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/docs/consumer-development/app-integration.md b/docs/docs/consumer-development/app-integration.md index 6fd939d8b3..81d9141242 100644 --- a/docs/docs/consumer-development/app-integration.md +++ b/docs/docs/consumer-development/app-integration.md @@ -4,7 +4,7 @@ sidebar_position: 1 # Developing an ICS consumer chain When developing an ICS consumer chain, besides just focusing on your chain's logic you should aim to allocate time to ensure that your chain is compatible with the ICS protocol. -To help you on your journey, the ICS team has provied multiple examples of a minumum viable consumer chain applications. +To help you on your journey, the ICS team has provided multiple examples of a minimum viable consumer chain applications. ## Basic consumer chain diff --git a/docs/docs/consumer-development/onboarding.md b/docs/docs/consumer-development/onboarding.md index 4b4327e4b5..37c2718e8c 100644 --- a/docs/docs/consumer-development/onboarding.md +++ b/docs/docs/consumer-development/onboarding.md @@ -18,7 +18,7 @@ Additionally, you can check the [testnet repo](https://github.com/cosmos/testnet To help validators and other node runners onboard onto your chain, please prepare a repository with information on how to run your chain. -This should include (at minumum): +This should include (at minimum): - [ ] genesis.json witout CCV data (before the propsal passes) - [ ] genesis.json with CCV data (after spawn time passes) diff --git a/docs/docs/features/proposals.md b/docs/docs/features/proposals.md index 8b5a4cfa83..3ba208b342 100644 --- a/docs/docs/features/proposals.md +++ b/docs/docs/features/proposals.md @@ -54,7 +54,7 @@ When proposals of this type are passed, the consumer chain in question will be g After the consumer chain removal, the chain in question will no longer be secured by the provider's validator set. :::info -The chain in question my continue to produce blocks, but the validator set can no longer be slashed for any infractions commited on that chain. +The chain in question my continue to produce blocks, but the validator set can no longer be slashed for any infractions committed on that chain. Additional steps are required to completely offboard a consumer chain, such as re-introducing the staking module and removing the provider's validators from the active set. More information will be made available in the [Consumer Offboarding Checklist](../consumer-development/offboarding.md). ::: @@ -74,7 +74,7 @@ Minimal example: ## `EquivocationProposal` :::tip `EquivocationProposal` will only be accepted on the provider chain if at least one of the consumer chains submits equivocation evidence to the provider. -Sending equivocation evidece to the provider is handled automatically by the interchain security protocol when an equivocation infraction is detected on the consumer chain. +Sending equivocation evidence to the provider is handled automatically by the interchain security protocol when an equivocation infraction is detected on the consumer chain. ::: Proposal type used to suggest slashing a validator for double signing on consumer chain. @@ -82,7 +82,7 @@ When proposals of this type are passed, the validator in question will be slashe :::warning Take note that an equivocation slash causes a validator to be tombstoned (can never re-enter the active set). -Tomstoning a validator on the provider chain will remove the validator from the validator set of all consumer chains. +Tombstoning a validator on the provider chain will remove the validator from the validator set of all consumer chains. ::: Minimal example: diff --git a/docs/docs/features/reward-distribution.md b/docs/docs/features/reward-distribution.md index 7f09d36c29..e762a9fe7f 100644 --- a/docs/docs/features/reward-distribution.md +++ b/docs/docs/features/reward-distribution.md @@ -16,7 +16,7 @@ Sending and distributing rewards from consumer chains to provider chain is handl :::tip The following chain parameters dictate consumer chain distribution amount and frequency. They are set at consumer genesis and `blocks_per_distribution_transmission`, `consumer_redistribution_fraction` -`transfer_timeout_period` must be provided in every `ConsumerChainAddition` propsal. +`transfer_timeout_period` must be provided in every `ConsumerChainAddition` proposal. ::: diff --git a/docs/docs/features/slashing.md b/docs/docs/features/slashing.md index 5427747a1e..65d14c0b41 100644 --- a/docs/docs/features/slashing.md +++ b/docs/docs/features/slashing.md @@ -6,8 +6,8 @@ sidebar_position: 4 A consumer chain is essentially a regular Cosmos-SDK based chain that uses the interchain security module to achieve economic security by stake deposited on the provider chain, instead of it's own chain. In essence, provider chain and consumer chains are different networks (different infrastructures) that are bound together by the provider's validator set. By being bound to the provider's validator set, a consumer chain inherits the economic security guarantees of the provider chain (in terms of total stake). -To maintain the proof of stake model, the consumer chain is able to send evidece of infractions (double signing and downtime) to the provider chain so the offending validators can be penalized. -Any infraction commited on any of the consumer chains is reflected on the provider and all other consumer chains. +To maintain the proof of stake model, the consumer chain is able to send evidence of infractions (double signing and downtime) to the provider chain so the offending validators can be penalized. +Any infraction committed on any of the consumer chains is reflected on the provider and all other consumer chains. In the current implementation there are 2 important changes brought by the interchain security module: diff --git a/docs/docs/frequently-asked-questions.md b/docs/docs/frequently-asked-questions.md index e073f56769..6e2f4957b5 100644 --- a/docs/docs/frequently-asked-questions.md +++ b/docs/docs/frequently-asked-questions.md @@ -9,9 +9,9 @@ VSR simply means that the same validator set is used to secure both the provider ## What even is a consumer chain? -Consumer chain is blockchain operated by the same the same validator operators as the provider chain. The ICS protocol ensures the validator set replication properties (informs consumer chain about the current state of the validator set on the provider) +Consumer chain is blockchain operated by the same validator operators as the provider chain. The ICS protocol ensures the validator set replication properties (informs consumer chain about the current state of the validator set on the provider) -Consumer chains are run on infrastructure (virtual or phyisical machines) distinct from the provider, have their own configurations and operating requirements. +Consumer chains are run on infrastructure (virtual or physical machines) distinct from the provider, have their own configurations and operating requirements. ## What happens to consumer if provider is down? In case the provider chain halts or experiences difficulties the consumer chain will keep operating - the provider chain and consumer chains represent different networks, which only share the validator set. @@ -67,7 +67,7 @@ There are multiple opt-out mechanisms under active research. ## How does Equivocation Governance Slashing work? To avoid potential attacks directed at provider chain validators, a new mechanism was introduced: -When a validator double-signs on the provider chain a special type of slash packet is relayed to the provider chain. The provider will store information about the double signing validator and allow a governance proposal to be submitted. +When a validator double-signs on the consumer chain, a special type of slash packet is relayed to the provider chain. The provider will store information about the double signing validator and allow a governance proposal to be submitted. If the double-signing proposal passes, the offending validator will be slashed on the provider chain and tombstoned. Tombstoning will permanently exclude the validator from the active set of the provider. :::caution @@ -80,14 +80,14 @@ Consumer chains are standalone chains, in the sense that they can run arbitrary Consumer chain upgrades are unlikely to impact the provider chain, as long as there are no changes to the ICS module. ## How can I connect to the testnets? -Check out the [Joining Replicated Security testnet](../validators/joining-testnet.md) section. +Check out the [Joining Replicated Security testnet](./validators/joining-testnet.md) section. ## How do I start using ICS? -To become a consumer chain use this [checklist](../consumer-development/onboarding.md) and check the [App integration section](../consumer-development/app-integration.md) +To become a consumer chain use this [checklist](./consumer-development/onboarding.md) and check the [App integration section](./consumer-development/app-integration.md) ## Which relayers are supported? Currently supported versions: - Hermes 1.3 ## How does key delegation work in ICS? -You can check the [Key Assignment Guide](../features/key-assignment.md) for specific instructions. +You can check the [Key Assignment Guide](./features/key-assignment.md) for specific instructions. diff --git a/docs/docs/validators/joining-testnet.md b/docs/docs/validators/joining-testnet.md index 8fcdef07fb..b9d9f8f9da 100644 --- a/docs/docs/validators/joining-testnet.md +++ b/docs/docs/validators/joining-testnet.md @@ -89,7 +89,7 @@ $: touch statesync.sh $ chmod 700 statesync.sh # make executable ``` -Paste the following intructions into the `statesync.sh`: +Paste the following instructions into the `statesync.sh`: ```bash #!/bin/bash diff --git a/docs/docs/validators/overview.md b/docs/docs/validators/overview.md index bc628a8eaa..2f5cdc4369 100644 --- a/docs/docs/validators/overview.md +++ b/docs/docs/validators/overview.md @@ -37,7 +37,7 @@ Consumer chain team initializes the chain genesis.json and prepares binaries whi Consumer chain team (or their advocates) submits a `ConsumerAdditionProposal`. The most important parameters for validators are: - `spawn_time` - the time after which the consumer chain must be started -- `genesis_hash` - hash of the pre-ccv genesis.json; the file does not contain any validator info -> the infomation is available only after the proposal is passed and `spawn_time` is reached +- `genesis_hash` - hash of the pre-ccv genesis.json; the file does not contain any validator info -> the information is available only after the proposal is passed and `spawn_time` is reached - `binary_hash` - hash of the consumer chain binary used to validate the software builds ### 4. CCV Genesis state generation @@ -80,7 +80,7 @@ hermes start ``` ## Downtime Infractions -At present, the consumer chain can report evidence about downtime infracations to the provider chain. The `min_signed_per_window` and `signed_blocks_window` can be different on each consumer chain and are subject to changes via consumer chain governance. +At present, the consumer chain can report evidence about downtime infractions to the provider chain. The `min_signed_per_window` and `signed_blocks_window` can be different on each consumer chain and are subject to changes via consumer chain governance. :::info Causing a downtime infraction on any consumer chain will not incur a slash penalty. Instead, the offending validator will be jailed on the provider chain and consequently on all consumer chains.