From 432a08166d767750d74b477432ba6c35a31ff5e3 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Thu, 8 Feb 2024 16:08:36 +0100 Subject: [PATCH] docs: update key assignment doc (#1596) * update key assingment doc * improve clarity * update broken link --- ...dr-005-cryptographic-equivocation-verification.md | 2 +- docs/docs/features/key-assignment.md | 12 +++++++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index d4f9bd2bf8..4438b83239 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -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 diff --git a/docs/docs/features/key-assignment.md b/docs/docs/features/key-assignment.md index 7ac7d02f48..1906eb8b78 100644 --- a/docs/docs/features/key-assignment.md +++ b/docs/docs/features/key-assignment.md @@ -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 @@ -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.