diff --git a/docs/architecture/adr-004-split-denomination-keys.md b/docs/architecture/adr-004-split-denomination-keys.md index 8abf25fdaf..53c7b0977d 100644 --- a/docs/architecture/adr-004-split-denomination-keys.md +++ b/docs/architecture/adr-004-split-denomination-keys.md @@ -74,7 +74,7 @@ This will result in the balances being indexed by the byte representation of `DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual account balance by denomination found in the (un)delegation amount. As a result, -any mutations to the account balance by will made by denomination. +any mutations to the account balance will be made by denomination. `SubtractCoins()` and `AddCoins()` will be altered to read & write the balances directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). diff --git a/docs/architecture/adr-008-dCERT-group.md b/docs/architecture/adr-008-dCERT-group.md index 2b2d2b8260..5ee5670bd0 100644 --- a/docs/architecture/adr-008-dCERT-group.md +++ b/docs/architecture/adr-008-dCERT-group.md @@ -151,7 +151,7 @@ they should all be severely slashed. ## Status -> Proposed +Proposed ## Consequences diff --git a/docs/architecture/adr-012-state-accessors.md b/docs/architecture/adr-012-state-accessors.md index e2b580cc3a..009e349272 100644 --- a/docs/architecture/adr-012-state-accessors.md +++ b/docs/architecture/adr-012-state-accessors.md @@ -92,7 +92,7 @@ func (Mapping) Set(ctx Context, key []byte, o interface{}) {} // Check if a raw value exists func (Mapping) Has(ctx Context, key []byte) bool {} -// Delete a raw value value +// Delete a raw value func (Mapping) Delete(ctx Context, key []byte) {} ``` diff --git a/docs/architecture/adr-019-protobuf-state-encoding.md b/docs/architecture/adr-019-protobuf-state-encoding.md index 5ad1b953e7..fa8bbe94b2 100644 --- a/docs/architecture/adr-019-protobuf-state-encoding.md +++ b/docs/architecture/adr-019-protobuf-state-encoding.md @@ -136,7 +136,7 @@ to be reimplemented for each chain The main counter-argument to using `Any` centers around its additional space and possibly performance overhead. The space overhead could be dealt with using compression at the persistence layer in the future and the performance impact -is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization, +is likely to be small. Thus, not using `Any` is seen as a pre-mature optimization, with user experience as the higher order concern. Note, that given the Cosmos SDK's decision to adopt the `Codec` interfaces described diff --git a/docs/architecture/adr-023-protobuf-naming.md b/docs/architecture/adr-023-protobuf-naming.md index ab8b84e825..2f32c71702 100644 --- a/docs/architecture/adr-023-protobuf-naming.md +++ b/docs/architecture/adr-023-protobuf-naming.md @@ -117,7 +117,7 @@ Instead of breaking things, we should make every effort to evolve schemas rather to prevent such breakage. With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered -different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating +different packages and this should be a last resort approach for upgrading protobuf schemas. Scenarios where creating a `v2` may make sense are: * we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural @@ -200,7 +200,7 @@ go package names, i.e. the `cosmos.bank` protobuf package will still live in ### Message Naming -Message type names should be as concise possible without losing clarity. `sdk.Msg` +Message type names should be as as concise possible without losing clarity. `sdk.Msg` types which are used in transactions will retain the `Msg` prefix as that provides helpful context. diff --git a/docs/architecture/adr-028-public-key-addresses.md b/docs/architecture/adr-028-public-key-addresses.md index 84cadf1d76..85f7a766fd 100644 --- a/docs/architecture/adr-028-public-key-addresses.md +++ b/docs/architecture/adr-028-public-key-addresses.md @@ -207,7 +207,7 @@ For backward compatibility with the existing `authtypes.NewModuleAddress`, we ad ```go func Module(moduleName string, derivationKeys ...[]byte) []byte{ if len(derivationKeys) == 0 { - return authtypes.NewModuleAddress(modulenName) // legacy case + return authtypes.NewModuleAddress(moduleName) // legacy case } submoduleAddress := Hash("module", []byte(moduleName) + 0 + key) return fold((a, k) => Derive(a, k), subsubKeys, submoduleAddress) diff --git a/docs/architecture/adr-030-authz-module.md b/docs/architecture/adr-030-authz-module.md index 5aab72c5c6..e8b64f1840 100644 --- a/docs/architecture/adr-030-authz-module.md +++ b/docs/architecture/adr-030-authz-module.md @@ -165,7 +165,7 @@ message MsgExecResponse { message MsgExec { string grantee = 1; // Authorization Msg requests to execute. Each msg must implement Authorization interface - repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "cosmos.base.v1beta1.Msg"];; + repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "cosmos.base.v1beta1.Msg"]; } ``` diff --git a/docs/architecture/adr-032-typed-events.md b/docs/architecture/adr-032-typed-events.md index 037781917b..36a242357a 100644 --- a/docs/architecture/adr-032-typed-events.md +++ b/docs/architecture/adr-032-typed-events.md @@ -294,7 +294,7 @@ func PublishChainTxEvents(ctx context.Context, client cmtclient.EventsClient, bu for _, abciEv := range events { typedEvent, err := sdk.ParseTypedEvent(abciEv) if err != nil { - return er + return err } if err := bus.Publish(typedEvent); err != nil { bus.Close() diff --git a/docs/architecture/adr-034-account-rekeying.md b/docs/architecture/adr-034-account-rekeying.md index 58ec078c38..ef67460c29 100644 --- a/docs/architecture/adr-034-account-rekeying.md +++ b/docs/architecture/adr-034-account-rekeying.md @@ -68,7 +68,7 @@ Breaks the current assumed relationship between address and pubkeys as H(pubkey) ### Neutral -* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accounts with Vesting tokens to use this feature. +* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accounts with Vesting tokens to use this feature. * Will require that PubKeys for an account are included in the genesis exports. ## References diff --git a/docs/architecture/adr-036-arbitrary-signature.md b/docs/architecture/adr-036-arbitrary-signature.md index 50bd40dd7e..4750308641 100644 --- a/docs/architecture/adr-036-arbitrary-signature.md +++ b/docs/architecture/adr-036-arbitrary-signature.md @@ -121,7 +121,7 @@ Backwards compatibility is maintained as this is a new message spec definition. ## Further discussion -* Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed. +* Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content lying in `Data` non-replayable when, and if, needed. * the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general. ## References diff --git a/docs/architecture/adr-039-epoched-staking.md b/docs/architecture/adr-039-epoched-staking.md index 9a2fd900f5..b563987129 100644 --- a/docs/architecture/adr-039-epoched-staking.md +++ b/docs/architecture/adr-039-epoched-staking.md @@ -41,7 +41,7 @@ Furthermore, it has become clearer over time that immediate execution of staking There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occurred. -Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned usecases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows: +Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned use cases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows: * For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that. * For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala https://github.com/tendermint/spec/issues/199).