From 133e7051d8be2bd8c867b2c347425bfafa2d551b Mon Sep 17 00:00:00 2001 From: mpoke Date: Fri, 19 Jul 2024 12:29:05 +0200 Subject: [PATCH] remove changes from ADRs --- docs/docs/adrs/adr-001-key-assignment.md | 6 +++--- docs/docs/adrs/adr-015-partial-set-security.md | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/docs/adrs/adr-001-key-assignment.md b/docs/docs/adrs/adr-001-key-assignment.md index 6d6b92a63b..36dbdfdb09 100644 --- a/docs/docs/adrs/adr-001-key-assignment.md +++ b/docs/docs/adrs/adr-001-key-assignment.md @@ -25,15 +25,15 @@ It is possible to change the keys at any time by submitting a transaction (i.e., - `ValidatorConsumerPubKey` - Stores the validator assigned keys for every consumer chain. ```golang -0x16 | len(chainID) | chainID | providerConsAddress -> consumerKey +ConsumerValidatorsBytePrefix | len(chainID) | chainID | providerConsAddress -> consumerKey ``` - `ValidatorByConsumerAddr` - Stores the mapping from validator addresses on consumer chains to validator addresses on the provider chain. Needed for the consumer initiated slashing sub-protocol. ```golang -0x17 | len(chainID) | chainID | consumerConsAddress -> providerConsAddress +ValidatorsByConsumerAddrBytePrefix | len(chainID) | chainID | consumerConsAddress -> providerConsAddress ``` - `ConsumerAddrsToPrune` - Stores the mapping from VSC ids to consumer validators addresses. Needed for pruning `ValidatorByConsumerAddr`. ```golang -0x19 | len(chainID) | chainID | vscID -> []consumerConsAddresses +ConsumerAddrsToPruneBytePrefix | len(chainID) | chainID | vscID -> []consumerConsAddresses ``` ### Protocol overview diff --git a/docs/docs/adrs/adr-015-partial-set-security.md b/docs/docs/adrs/adr-015-partial-set-security.md index c9874dced8..0c3a331dfb 100644 --- a/docs/docs/adrs/adr-015-partial-set-security.md +++ b/docs/docs/adrs/adr-015-partial-set-security.md @@ -66,7 +66,7 @@ In a future version of PSS, we intend to introduce a `ConsumerModificationPropos We augment the provider module’s state to keep track of the `top_N` value for each consumer chain. The key to store this information would be: ``` -0x21 | len(chainID) | chainID +topNBytePrefix | len(chainID) | chainID ``` To create the above key, we can use [`ChainIdWithLenKey`](https://github.com/cosmos/interchain-security/blob/v4.0.0/x/ccv/provider/types/keys.go#L418). @@ -116,10 +116,10 @@ Naturally, a validator can always change the consumer key on a consumer chain by For each validator, we store a pair `(blockHeight, isOptedIn)` that contains the block height the validator opted in and whether the validator is currently opted in or not, under the key: ``` -0x20 | len(chainID) | chainID | addr +optedInBytePrefix | len(chainID) | chainID | addr ``` -By using a prefix iterator on `0x20 | len(chainID) | chainID` we retrieve all the opted in validators. +By using a prefix iterator on `optedInBytePrefix | len(chainID) | chainID` we retrieve all the opted in validators. We introduce the following `Keeper` methods. @@ -173,7 +173,7 @@ Additionally, a validator that belongs to the top `N%` validators cannot opt out We also update the state of the opted-in validators when a validator has opted out by removing the opted-out validator. Note that only opted-in validators can be punished for downtime on a consumer chain. -For this, we use historical info of all the validators that have opted in; We can examine the `blockHeight` stored under the key `0x20 | len(chainID) | chainID | addr` to see if a validator was opted in. +For this, we use historical info of all the validators that have opted in; We can examine the `blockHeight` stored under the key `optedInBytePrefix | len(chainID) | chainID | addr` to see if a validator was opted in. This way we can jail validators for downtime knowing that indeed the validators have opted in at some point in the past. Otherwise, we can think of a scenario where a validator `V` is down for a period of time, but before `V` gets punished for downtime, validator `V` opts out, and then we do not know whether `V` should be punished or not.