LaconicNetwork/cosmos-sdk
9
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: fix spelling errors (#22802)

Browse Source 
Co-authored-by: github-merge-queue <118344674+github-merge-queue@users.noreply.github.com>
Co-authored-by: Julien Robert <julien@rbrt.fr>
This commit is contained in:
github-actions[bot] 2024-12-09 12:26:05 +00:00 committed by GitHub
parent f995d0a219
commit 13e3e211a6
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
13 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.github/.codespellignore vendored
View File

@ -5,4 +5,5 @@ pastTime
hasTables
Nam
EyT
upTo
upTo
pullRequests

2
CHANGELOG.md
View File

@ -142,7 +142,7 @@ Every module contains its own CHANGELOG.md. Please refer to the module you are i
* (genutil) [#21701](https://github.com/cosmos/cosmos-sdk/pull/21701) Improved error messages for genesis validation.
* (runtime) [#21704](https://github.com/cosmos/cosmos-sdk/pull/21704) Move `upgradetypes.StoreLoader` to runtime and alias it in upgrade for backward compatibility.
* (sims)[#21613](https://github.com/cosmos/cosmos-sdk/pull/21613) Add sims2 framework and factory methods for simpler message factories in modules
* (modules) [#21963](https://github.com/cosmos/cosmos-sdk/pull/21963) Duplicatable metrics are no more collected in modules. They were unecessary overhead.
* (modules) [#21963](https://github.com/cosmos/cosmos-sdk/pull/21963) Duplicatable metrics are no more collected in modules. They were unnecessary overhead.
* (crypto/ledger) [#22116](https://github.com/cosmos/cosmos-sdk/pull/22116) Improve error message when deriving paths using index >100
### Bug Fixes

8
docs/architecture/adr-75-v2.md
View File

@ -56,7 +56,7 @@ The alternative to doing a rewrite is to spend more time cleaning up baseapp. Th
## Decision
The Descision is to rewrite the core componenets (baseapp, server, store) of the SDK into smaller modules.
The Decision is to rewrite the core components (baseapp, server, store) of the SDK into smaller modules.
These components will be broken into separate go.mods. The modules consist of the following:
@ -135,7 +135,7 @@ The state transition function interface is simple and meant to be as light weigh
```mermaid
graph TD
subgraph STF[State Transition Funciton]
subgraph STF[State Transition Function]
BR --> DB
subgraph DB[DeliverBlock]
PB[PreBlock]
@ -205,9 +205,9 @@ The design of the node comes with a number of tradeoffs.
### Backwards Compatibility
The state machine was made to not affect modules that are not using the state transition function. If a user would like to migrate to v2 they will need to migrate to `appmodule.Environment` from `sdk.Context`. `sdk.Context` is a struct which is a global in the state machine, this desing limits the concurrency.
The state machine was made to not affect modules that are not using the state transition function. If a user would like to migrate to v2 they will need to migrate to `appmodule.Environment` from `sdk.Context`. `sdk.Context` is a struct which is a global in the state machine, this design limits the concurrency.
V2 will have a breaking changes in regards to how CometBFT handles certain fields in ABCI. Previously, the Cosmos SDK paniced and recovered in the case of out of gas, providing an error to CometBFT which we do not return in the new design.
V2 will have a breaking changes in regards to how CometBFT handles certain fields in ABCI. Previously, the Cosmos SDK panicked and recovered in the case of out of gas, providing an error to CometBFT which we do not return in the new design.
V2 only works with `Store/v2`, `IAVL V1` can be used with `Store/v2`. This allows chains to continue with existing databases. There will be a migration happening to convert the database to the separation of Storage and Commitment. Once the migration is completed the state machine will query information from the rawDB unless otherwise specified.

2
docs/build/building-modules/01-module-manager.md vendored
View File

@ -44,7 +44,7 @@ The `AppModule` interface exists to define inter-dependent module methods. Many
The usage of extension interfaces allows modules to define only the functionalities they need. For example, a module that does not need an `EndBlock` does not need to define the `HasEndBlocker` interface and thus the `EndBlock` method. `AppModule` and `AppModuleGenesis` are voluntarily small interfaces, that can take advantage of the `Module` patterns without having to define many placeholder functions.
:::note legacy
Prior to the introduction of the `cosmossdk.io/core` package the interfaces were defined in the `types/module` package of the Cosmos SDK. Not all interfaces have been migrated to core. Those legacy interfaces are still supported for backward compatability, but aren't described in this document and should not be used in new modules.
Prior to the introduction of the `cosmossdk.io/core` package the interfaces were defined in the `types/module` package of the Cosmos SDK. Not all interfaces have been migrated to core. Those legacy interfaces are still supported for backward compatibility, but aren't described in this document and should not be used in new modules.
:::

2
docs/build/building-modules/06-keeper.md vendored
View File

@ -82,4 +82,4 @@ State management is recommended to be done via [Collections](../packages/collect
In the Cosmos SDK, it is crucial to be methodical and selective when managing state within a module, as improper state management can lead to inefficiency, security risks, and scalability issues. Not all data belongs in the on-chain state; it's important to store only essential blockchain data that needs to be verified by consensus. Storing unnecessary information, especially client-side data, can bloat the state and slow down performance. Instead, developers should focus on using an off-chain database to handle supplementary data, extending the API as needed. This approach minimizes on-chain complexity, optimizes resource usage, and keeps the blockchain state lean and efficient, ensuring scalability and smooth operations.
The Cosmos SDK leverages Protocol Buffers (protobuf) for efficient state management, providing a well-structured, binary encoding format that ensures compatibility and performance across different modules. The SDK’s recommended approach for managing state is through the [collections package](../pacakges/02-collections.md), which simplifies state handling by offering predefined data structures like maps and indexed sets, reducing the complexity of managing raw state data. While users can opt for custom encoding schemes if they need more flexibility or have specialized requirements, they should be aware that such custom implementations may not integrate seamlessly with indexers that decode state data on the fly. This could lead to challenges in data retrieval, querying, and interoperability, making protobuf a safer and more future-proof choice for most use cases.
The Cosmos SDK leverages Protocol Buffers (protobuf) for efficient state management, providing a well-structured, binary encoding format that ensures compatibility and performance across different modules. The SDK’s recommended approach for managing state is through the [collections package](../packages/02-collections.md), which simplifies state handling by offering predefined data structures like maps and indexed sets, reducing the complexity of managing raw state data. While users can opt for custom encoding schemes if they need more flexibility or have specialized requirements, they should be aware that such custom implementations may not integrate seamlessly with indexers that decode state data on the fly. This could lead to challenges in data retrieval, querying, and interoperability, making protobuf a safer and more future-proof choice for most use cases.

2
docs/user/run-node/00-keyring.md
View File

@ -8,7 +8,7 @@ sidebar_position: 1
This document describes how to configure and use the keyring and its various backends for an [**application**](../../learn/beginner/00-app-anatomy.md).
:::
The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage.
The keyring holds the private/public key pairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage.
## Available backends for the keyring

2
docs/user/run-node/03-txs.md
View File

@ -269,7 +269,7 @@ func sendTx() error {
### Broadcasting a Transaction
The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](../../learn/advanced/06-grpc_rest.md). For this tutorial, we will only describe the gRPC method.
The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also possible. An overview of the differences between these methods is exposed [here](../../learn/advanced/06-grpc_rest.md). For this tutorial, we will only describe the gRPC method.
```go
import (

4
docs/user/run-node/04-rosetta.md
View File

@ -54,7 +54,7 @@ An implementation example can be found in `simapp` package.
To run Rosetta in your application CLI, use the following command:
> **Note:** if using the native approach, add your node name before any rosetta comand.
> **Note:** if using the native approach, add your node name before any rosetta command.
```shell
rosetta --help
@ -74,7 +74,7 @@ rosetta
## Plugins - Multi chain connections
Rosetta will try to reflect the node types trough reflection over the node gRPC endpoints, there may be cases were this approach is not enough. It is possible to extend or implement the required types easily trough plugins.
Rosetta will try to reflect the node types through reflection over the node gRPC endpoints, there may be cases were this approach is not enough. It is possible to extend or implement the required types easily through plugins.
To use Rosetta over any chain, it is required to set up prefixes and registering zone specific interfaces through plugins.

2
docs/user/run-node/05-run-testnet.md
View File

@ -34,7 +34,7 @@ The default output directory is a relative `.testnets` directory. Let's take a l
### gentxs
The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initilization process.
The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initialization process.
### nodes

2
docs/user/run-node/06-run-production.md
View File

@ -196,7 +196,7 @@ tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/t
At this point, it is necessary to delete the `priv_validator_key.json` from the validator node and the tmkms node. Since the key has been imported into tmkms (above) it is no longer necessary on the nodes. The key can be safely stored offline.
4. Modifiy the `tmkms.toml`.
4. Modify the `tmkms.toml`.
```bash
vim $HOME/tmkms/config/tmkms.toml

6
x/accounts/defaults/lockup/TUTORIAL.md
View File

@ -29,7 +29,7 @@ simd keys add owner
Normally the creator must have enough token to grant to the lockup account during the lockup account init process. The owner wallet should be associated with the individual that the creator want to grant the fund to.
Now, the creator can craft the lockup account init messages. This message depend on what type of lockup account the creator want to create.
For continous, delayed, permanent locking account:
For continuous, delayed, permanent locking account:
```json
{
@ -40,7 +40,7 @@ For continous, delayed, permanent locking account:
```
:::info
`start_time` is only needed for continous locking account init process. For the other two, you dont have to set it in. Error will returned if `start_time` is not provided when creating continous locking account*
`start_time` is only needed for continuous locking account init process. For the other two, you dont have to set it in. Error will returned if `start_time` is not provided when creating continuous locking account*
:::
For periodic locking account:
@ -215,7 +215,7 @@ simd tx accounts query <account_address> <query-request-type-url> $querycontents
The query request type url for this query is `cosmos.accounts.defaults.lockup.QueryLockupAccountInfoRequest`. And query json file can be an empty object since `QueryLockupAccountInfoRequest` does not required an input.
Account informations including:
Account information including:
* original locked amount

2
x/auth/CHANGELOG.md
View File

@ -60,7 +60,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
* [#18817](https://github.com/cosmos/cosmos-sdk/pull/18817) SigVerification, GasConsumption, IncreaseSequence ante decorators have all been joined into one SigVerification decorator. Gas consumption during TX validation flow has reduced.
* [#19093](https://github.com/cosmos/cosmos-sdk/pull/19093) SetPubKeyDecorator was merged into SigVerification, gas consumption is almost halved for a simple tx.
* [#19535](https://github.com/cosmos/cosmos-sdk/pull/19535) Remove vesting account creation when the chain is running. The accounts module is required for creating [#vesting accounts](../accounts/defaults/lockup/README.md) on a running chain.
* [#21688](https://github.com/cosmos/cosmos-sdk/pull/21688) Allow x/accounts to be queriable from the `AccountInfo` and `Account` gRPC endpoints
* [#21688](https://github.com/cosmos/cosmos-sdk/pull/21688) Allow x/accounts to be queryable from the `AccountInfo` and `Account` gRPC endpoints
* [#21820](https://github.com/cosmos/cosmos-sdk/pull/21820) Allow x/auth `BaseAccount` to migrate to a `x/accounts` via the new `MsgMigrateAccount`.
### Bug Fixes

2
x/bank/README.md
View File

@ -589,7 +589,7 @@ The bank module contains the following parameters
### SendEnabled
SendEnabled is depreacted and only kept for backward compatibility. For genesis, use the newly added send_enabled field in the genesis object. Storage, lookup, and manipulation of this information is now in the keeper.
SendEnabled is deprecated and only kept for backward compatibility. For genesis, use the newly added send_enabled field in the genesis object. Storage, lookup, and manipulation of this information is now in the keeper.
### DefaultSendEnabled