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

docs: fix grammar and spelling errors (#25139)

Browse Source 
Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>
This commit is contained in:
heksan-ui 2025-08-11 21:26:31 +02:00 committed by GitHub
parent ed0847d374
commit 85fa0ae755
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
12 changed files with 24 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/docs/build/building-modules/05-protobuf-annotations.md vendored
View File

@ -56,7 +56,7 @@ There are a few options for what can be provided as a scalar: `cosmos.AddressStr
## Implements_Interface
Implement interface is used to provide information to client tooling like [telescope](https://github.com/cosmology-tech/telescope) on how to encode and decode protobuf messages.
`Implements_Interface` is used to provide information to client tooling like [telescope](https://github.com/cosmology-tech/telescope) on how to encode and decode protobuf messages.
```proto
option (cosmos_proto.implements_interface) = "cosmos.auth.v1beta1.AccountI";
@ -66,7 +66,7 @@ option (cosmos_proto.implements_interface) = "cosmos.auth.v1beta1.AccountI";
`method_added_in`, `field_added_in` and `message_added_in` are annotations to denote to clients that a field has been supported in a later version. This is useful when new methods or fields are added in later versions and that the client needs to be aware of what it can call.
The annotation should be worded as follow:
The annotation should be worded as follows:
```proto
option (cosmos_proto.method_added_in) = "cosmos-sdk v0.50.1";
@ -76,17 +76,15 @@ option (cosmos_proto.method_added_in) = "simapp v24.0.0";
## Amino
The amino codec was removed in `v0.50+`, this means there is not a need register `legacyAminoCodec`. To replace the amino codec, Amino protobuf annotations are used to provide information to the amino codec on how to encode and decode protobuf messages.
The amino codec was removed in `v0.50+`, this means there is no need to register `legacyAminoCodec`. To replace the amino codec, Amino protobuf annotations are used to provide information to the amino codec on how to encode and decode protobuf messages.
:::note
Amino annotations are only used for backwards compatibility with amino. New modules are not required use amino annotations.
:::
Amino annotations are only used for backwards compatibility with amino. New modules are not required to use amino annotations.
The below annotations are used to provide information to the amino codec on how to encode and decode protobuf messages in a backwards compatible manner.
### Name
Name specifies the amino name that would show up for the user in order for them see which message they are signing.
Name specifies the amino name that would show up for the user in order for them to see which message they are signing.
```proto
option (amino.name) = "cosmos-sdk/BaseAccount";
@ -98,7 +96,7 @@ https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9
### Field_Name
Field name specifies the amino name that would show up for the user in order for them see which field they are signing.
Field name specifies the amino name that would show up for the user in order for them to see which field they are signing.
```proto
uint64 height = 1 [(amino.field_name) = "public_key"];

4
docs/docs/build/building-modules/06-beginblock-endblock.md vendored
View File

@ -18,11 +18,11 @@ sidebar_position: 1
`BeginBlocker` and `EndBlocker` are a way for module developers to add automatic execution of logic to their module. This is a powerful tool that should be used carefully, as complex automatic functions can slow down or even halt the chain.
In 0.47.0, Prepare and Process Proposal were added that allow app developers to do arbitrary work at those phases, but they do not influence the work that will be done in BeginBlock. If an application required `BeginBlock` to execute prior to any sort of work is done then this is not possible today (0.50.0).
In 0.47.0, Prepare and Process Proposal were added that allow app developers to do arbitrary work at those phases, but they do not influence the work that will be done in BeginBlock. If an application requires `BeginBlock` to execute prior to any sort of work is done then this is not possible today (0.50.0).
When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](./01-module-manager.md#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`.
The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](./03-msg-services.md):
The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` is very similar to that of a [`Msg` service](./03-msg-services.md):
* They generally use the [`keeper`](./06-keeper.md) and [`ctx`](../../learn/advanced/02-context.md) to retrieve information about the latest state.
* If needed, they use the `keeper` and `ctx` to trigger state-transitions.

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

@ -16,7 +16,7 @@ sidebar_position: 1
## Motivation
The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer.
The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developers.
The Cosmos SDK adopts an [object-capabilities-based approach](../../docs/learn/advanced/10-ocap.md) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../../learn/advanced/04-store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s).

4
docs/docs/build/building-modules/08-genesis.md vendored
View File

@ -17,7 +17,7 @@ Modules generally handle a subset of the state and, as such, they need to define
## Type Definition
The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](../../learn/advanced/05-encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process.
The subset of the genesis state defined by a given module is generally defined in a `genesis.proto` file ([more info](../../learn/advanced/05-encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process.
See an example of `GenesisState` protobuf message definition from the `auth` module:
@ -29,7 +29,7 @@ Next we present the main genesis-related methods that need to be implemented by
### `DefaultGenesis`
The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module:
The `DefaultGenesis()` method is a simple function that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/module.go#L63-L67

3
docs/docs/build/building-modules/09-module-interfaces.md vendored
View File

@ -132,7 +132,8 @@ Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags requ
Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command.
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/client/flags/flags.go#L95-L106```
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/client/flags/flags.go#L95-L106
```
-->
## gRPC

2
docs/docs/build/building-modules/11-structure.md vendored
View File

@ -82,7 +82,7 @@ x/{module_name}
* `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined).
* `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
* `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`).
* `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../../spec/SPEC_MODULE.md).
* `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more about how to write module specs in the [spec guidelines](../../spec/SPEC_MODULE.md).
* The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers.
* `codec.go`: The module's registry methods for interface types.
* `errors.go`: The module's sentinel errors.

2
docs/docs/build/building-modules/14-simulator.md vendored
View File

@ -71,7 +71,7 @@ If the module does **not** have message handlers or governance proposal handlers
Registering the store decoders is required for the `AppImportExport` simulation. This allows
for the key-value pairs from the stores to be decoded to their corresponding types.
In particular, it matches the key to a concrete type and then unmarshalls the value from the `KVPair` to the type provided.
In particular, it matches the key to a concrete type and then unmarshals the value from the `KVPair` to the type provided.
Modules using [collections](https://github.com/cosmos/cosmos-sdk/blob/main/collections/README.md) can use the `NewStoreDecoderFuncFromCollectionsSchema` function that builds the decoder for you:

2
docs/docs/build/building-modules/15-depinject.md vendored
View File

@ -36,7 +36,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/group/mod
* `go_import` must point to the Go package of the custom module.
* Message fields define the module configuration.
That configuration can be set in the `app_config.go` / `app.yaml` file for a chain developer to configure the module.
Taking `group` as example, a chain developer is able to decide, thanks to `uint64 max_metadata_len`, what the maximum metadata length allowed for a group proposal is.
Taking `group` as an example, a chain developer is able to decide, thanks to `uint64 max_metadata_len`, what the maximum metadata length allowed for a group proposal is.
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/app_config.go#L228-L234

4
docs/docs/build/building-modules/16-testing.md vendored
View File

@ -7,7 +7,7 @@ sidebar_position: 1
The Cosmos SDK contains different types of [tests](https://martinfowler.com/articles/practical-test-pyramid.html).
These tests have different goals and are used at different stages of the development cycle.
We advise, as a general rule, to use tests at all stages of the development cycle.
It is advised, as a chain developer, to test your application and modules in a similar way than the SDK.
It is advised, as a chain developer, to test your application and modules in a similar way to the SDK.
The rationale behind testing can be found in [ADR-59](https://docs.cosmos.network/main/build/architecture/adr-059-test-scopes).
@ -46,7 +46,7 @@ This allows us to test the `x/gov` module without having to import other modules
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/gov/keeper/keeper_test.go#L3-L42
```
We can test then create unit tests using the newly created `Keeper` instance.
We can then create unit tests using the newly created `Keeper` instance.
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/gov/keeper/keeper_test.go#L83-L107

2
docs/docs/build/building-modules/17-preblock.md vendored
View File

@ -21,7 +21,7 @@ There are two semantics around the new lifecycle method:
* It runs before the `BeginBlocker` of all modules
* It can modify consensus parameters in storage, and signal the caller through the return value.
When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameter in the deliver context:
When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameters in the deliver context:
```
app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())

2
docs/docs/build/packages/README.md vendored
View File

@ -4,7 +4,7 @@ sidebar_position: 0
# Packages
The Cosmos SDK is a collection of Go modules. This section provides documentation on various packages that can used when developing a Cosmos SDK chain.
The Cosmos SDK is a collection of Go modules. This section provides documentation on various packages that can be used when developing a Cosmos SDK chain.
It lists all standalone Go modules that are part of the Cosmos SDK.
:::tip

8
docs/docs/build/tooling/00-protobuf.md vendored
View File

@ -22,7 +22,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/scripts/protocgen.sh
## Buf
[Buf](https://buf.build) is a protobuf tool that abstracts the needs to use the complicated `protoc` toolchain on top of various other things that ensure you are using protobuf in accordance with the majority of the ecosystem. Within the cosmos-sdk repository there are a few files that have a buf prefix. Lets start with the top level and then dive into the various directories.
[Buf](https://buf.build) is a protobuf tool that abstracts the need to use the complicated `protoc` toolchain on top of various other things that ensure you are using protobuf in accordance with the majority of the ecosystem. Within the cosmos-sdk repository there are a few files that have a buf prefix. Lets start with the top level and then dive into the various directories.
### Workspace
@ -50,7 +50,7 @@ Next is the `proto/` directory where all of our protobuf files live. In here the
└── tendermint
```
The above diagram all the files and directories within the Cosmos SDK `proto/` directory.
The above diagram shows all the files and directories within the Cosmos SDK `proto/` directory.
#### `buf.gen.gogo.yaml`
@ -78,7 +78,7 @@ Example of how to define `gen` files can be found [here](https://docs.buf.build/
#### `buf.gen.swagger.yaml`
`buf.gen.swagger.yaml` generates the swagger documentation for the query and messages of the chain. This will only define the REST API end points that were defined in the query and msg servers. You can find examples of this [here](https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/bank/v1beta1/query.proto#L19)
`buf.gen.swagger.yaml` generates the swagger documentation for the query and messages of the chain. This will only define the REST API endpoints that were defined in the query and msg servers. You can find examples of this [here](https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/bank/v1beta1/query.proto#L19)
```go reference
https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.swagger.yaml#L1-L6
@ -90,7 +90,7 @@ Example of how to define `gen` files can be found [here](https://docs.buf.build/
#### `buf.lock`
This is an autogenerated file based off the dependencies required by the `.gen` files. There is no need to copy the current one. If you depend on cosmos-sdk proto definitions a new entry for the Cosmos SDK will need to be provided. The dependency you will need to use is `buf.build/cosmos/cosmos-sdk`.
This is an autogenerated file based on the dependencies required by the `.gen` files. There is no need to copy the current one. If you depend on cosmos-sdk proto definitions a new entry for the Cosmos SDK will need to be provided. The dependency you will need to use is `buf.build/cosmos/cosmos-sdk`.
```go reference
https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.lock#L1-L16