Skip to content

Commit

Permalink
docs: update key assignment doc (#1596)
Browse files Browse the repository at this point in the history
* update key assingment doc

* improve clarity

* update broken link
  • Loading branch information
sainoe authored Feb 8, 2024
1 parent 07be033 commit 432a081
Show file tree
Hide file tree
Showing 2 changed files with 12 additions and 2 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@ either using its infraction height or its unsigned timestamp. Note that changes
The underlying reason is that a malicious validator could take advantage of getting tombstoned
to avoid being slashed on the provider ([see comment](https://github.com/cosmos/interchain-security/pull/1232#issuecomment-1693127641)).

- Currently, the endpoint can only handle _equivocation_ light client attacks. This is because the _lunatic_ attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to extract the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)). In addition, "amnesia" attacks are ignored, similar to CometBFT (see [ADR-056](https://github.com/cometbft/cometbft/blob/main/docs/architecture/tendermint-core/adr-056-light-client-amnesia-attacks.md#decision)).
- Currently, the endpoint can only handle _equivocation_ light client attacks. This is because the _lunatic_ attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to extract the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)). In addition, "amnesia" attacks are ignored, similar to CometBFT (see [ADR-056](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-047-handling-evidence-from-light-client.md#negative)).


## Consequences
Expand Down
12 changes: 11 additions & 1 deletion docs/docs/features/key-assignment.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Key assignment is handled only by the provider chain - the consumer chains are n

## Rules

- a key can be assigned before the consumer addition proposal passes on the provider
- a key can be assigned as soon as the consumer addition proposal is submitted to the provider
- validator A cannot assign consumer key K to consumer chain X if there is already a validator B (B!=A) using K on the provider
- validator A cannot assign consumer key K to consumer chain X if there is already a validator B using K on X
- a new validator on the provider cannot use a consensus key K if K is already used by any validator on any consumer chain
Expand Down Expand Up @@ -80,3 +80,13 @@ To change your key, simply repeat all of the steps listed above. Take note that
## Removing a key

To remove a key, simply switch it back to the consensus key you have assigned on the provider chain by following steps in the `Adding a key` section and using your provider consensus key.

## Querying proposed consumer chains

To query the consumer addition proposals that are in the voting period, you can use the following command on the provider:

```bash
gaiad query provider list-proposed-consumer-chains
```

This query is valuable for staying informed about when keys can be assigned to newly proposed consumer chains.

0 comments on commit 432a081

Please sign in to comment.