fix: spelling/grammar across docs and tooling (#25677)
Co-authored-by: Alex | Cosmos Labs <alex@cosmoslabs.io>
This commit is contained in:
viktorking7
GitHub
parent
8fb7b4b324
commit
46a7f918d6
@ -28,7 +28,7 @@ The Cosmos SDK is a modular, open-source blockchain SDK for building secure, hig
|
||||
|
||||
The Cosmos SDK is tailored for building secure, sovereign application-specific blockchains. Developers building with the Cosmos SDK can use predefined modules that cover standard blockchain functionality or create custom modules for their specific use case. This composable architecture enables robust customization. The SDK provides abstractions for permissioning, governance, state management, account abstraction, tokenization processes, application logic, and more.
|
||||
|
||||
Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). Ibc-go is implemented as a Go module in the Cosmos SDK.
|
||||
Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). ibc-go is implemented as a Go module in the Cosmos SDK.
|
||||
|
||||
While the Cosmos SDK is plug-and-play with any consensus engine, we recommend using [CometBFT](https://github.com/cometbft/cometbft) for a fast, battle-tested, high-throughput, configurable BFT state machine. CometBFT is developed as part of the Cosmos Stack and its releases are updated alongside the SDK.
|
||||
|
||||
|
||||
@ -104,7 +104,7 @@ func PubkeyCmd() *cobra.Command {
|
||||
return &cobra.Command{
|
||||
Use: "pubkey [pubkey]",
|
||||
Short: "Decode a pubkey from proto JSON",
|
||||
Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display it's address.
|
||||
Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display its address.
|
||||
|
||||
Example:
|
||||
$ %s debug pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AurroA7jvfPd1AadmmOvWM2rJSwipXfRf8yD6pLbA2DJ"}'
|
||||
|
||||
@ -122,7 +122,7 @@ var (
|
||||
|
||||
#### Rules
|
||||
|
||||
``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8`for disk space efficiency.
|
||||
``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8` for disk space efficiency.
|
||||
|
||||
A collection **MUST NOT** share the same prefix as another collection in the same module, and a collection prefix **MUST NEVER** start with the same prefix as another, examples:
|
||||
|
||||
@ -397,7 +397,7 @@ func (k Keeper) RemoveValidator(ctx sdk.Context, validator sdk.ValAddress) error
|
||||
}
|
||||
```
|
||||
|
||||
The first difference we notice is that `KeySet` needs use to specify only one type parameter: the key (`sdk.ValAddress` in this case).
|
||||
The first difference we notice is that `KeySet` needs us to specify only one type parameter: the key (`sdk.ValAddress` in this case).
|
||||
The second difference we notice is that `KeySet` in its `NewKeySet` function does not require
|
||||
us to specify a `ValueCodec` but only a `KeyCodec`. This is because a `KeySet` only saves keys and not values.
|
||||
|
||||
@ -605,7 +605,7 @@ we specified in the range.
|
||||
Then we use again the `Values` method of the `Iterator` to collect all the results.
|
||||
|
||||
`collections.Range` also offers a `Prefix` API which is not applicable to all keys types,
|
||||
for example uint64 cannot be prefix because it is of constant size, but a `string` key
|
||||
for example uint64 cannot be prefixed because it is of constant size, but a `string` key
|
||||
can be prefixed.
|
||||
|
||||
#### IterateAccounts
|
||||
@ -648,7 +648,7 @@ Let's see now how we can work with composite keys using collections.
|
||||
|
||||
### Example
|
||||
|
||||
In our example we will show-case how we can use collections when we are dealing with balances, similar to bank,
|
||||
In our example we will showcase how we can use collections when we are dealing with balances, similar to bank,
|
||||
a balance is a mapping between `(address, denom) => math.Int` the composite key in our case is `(address, denom)`.
|
||||
|
||||
## Instantiation of a composite key collection
|
||||
|
||||
@ -24,7 +24,7 @@ A table can be built given a `codec.ProtoMarshaler` model type, a prefix to acce
|
||||
https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/table.go#L30-L36
|
||||
```
|
||||
|
||||
In the prefix store, entities should be stored by an unique identifier called `RowID` which can be based either on an `uint64` auto-increment counter, string or dynamic size bytes.
|
||||
In the prefix store, entities should be stored by a unique identifier called `RowID` which can be based either on a `uint64` auto-increment counter, string or dynamic size bytes.
|
||||
Regular CRUD operations can be performed on a table, these methods take a `sdk.KVStore` as parameter to get the table prefix store.
|
||||
|
||||
The `table` struct does not:
|
||||
|
||||
@ -21,7 +21,7 @@ var (
|
||||
)
|
||||
|
||||
// table is the high level object to storage mapper functionality. Persistent
|
||||
// entities are stored by an unique identifier called `RowID`. The table struct
|
||||
// entities are stored by a unique identifier called `RowID`. The table struct
|
||||
// does not:
|
||||
// - enforce uniqueness of the `RowID`
|
||||
// - enforce prefix uniqueness of keys, i.e. not allowing one key to be a prefix
|
||||
|
||||
@ -192,7 +192,7 @@ The presented workaround can be used until the IBC module is fully upgraded to s
|
||||
|
||||
We consider a compression of prefix keys by creating a mapping from module key to an integer, and serializing the integer using varint coding. Varint coding assures that different values don't have common byte prefix. For Merkle Proofs we can't use prefix compression - so it should only apply for the `SS` keys. Moreover, the prefix compression should be only applied for the module namespace. More precisely:
|
||||
|
||||
* each module has it's own namespace;
|
||||
* each module has its own namespace;
|
||||
* when accessing a module namespace we create a KVStore with embedded prefix;
|
||||
* that prefix will be compressed only when accessing and managing `SS`.
|
||||
|
||||
@ -279,7 +279,7 @@ We were discussing use case where modules can use a support database, which is n
|
||||
## References
|
||||
|
||||
* [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
|
||||
* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
|
||||
* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15
|
||||
* [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
|
||||
* [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
|
||||
* Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)
|
||||
|
||||
@ -14,7 +14,7 @@ This ADR describes a flexible mechanism to maintain a consensus level gas prices
|
||||
|
||||
## Context
|
||||
|
||||
Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level.
|
||||
Currently, each validator configures its own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from DoS attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level.
|
||||
|
||||
Since tendermint 0.34.20 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system.
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@ type ExtensionPayloadReader = func() ([]byte, error)
|
||||
type ExtensionPayloadWriter = func([]byte) error
|
||||
|
||||
// ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream.
|
||||
// ExtensionSnapshotter has an unique name and manages it's own internal formats.
|
||||
// ExtensionSnapshotter has a unique name and manages its own internal formats.
|
||||
type ExtensionSnapshotter interface {
|
||||
// SnapshotName returns the name of snapshotter, it should be unique in the manager.
|
||||
SnapshotName() string
|
||||
|
||||
@ -137,7 +137,7 @@ transactions entirely with other transactions.
|
||||
|
||||
When evaluating transactions from `RequestPrepareProposal`, the application will
|
||||
ignore *ALL* transactions sent to it in the request and instead reap up to
|
||||
`RequestPrepareProposal.max_tx_bytes` from it's own mempool.
|
||||
`RequestPrepareProposal.max_tx_bytes` from its own mempool.
|
||||
|
||||
Since an application can technically insert or inject transactions on `Insert`
|
||||
during `CheckTx` execution, it is recommended that applications ensure transaction
|
||||
|
||||
@ -286,7 +286,7 @@ decision based on the vote extensions.
|
||||
> nor the vote extension verification mechanism described above is required for
|
||||
> applications to implement. In other words, a proposer is not required to verify
|
||||
> and propagate vote extensions along with their signatures nor are proposers
|
||||
> required to verify those signatures. An application can implement it's own
|
||||
> required to verify those signatures. An application can implement its own
|
||||
> PKI mechanism and use that to sign and verify vote extensions.
|
||||
|
||||
#### Vote Extension Persistence
|
||||
|
||||
@ -40,10 +40,10 @@ Now when logging into the server, the non `root` user can be used.
|
||||
|
||||
### Go
|
||||
|
||||
1. Install the [Go](https://go.dev/doc/install) version preconized by the application.
|
||||
1. Install the [Go](https://go.dev/doc/install) version recommended by the application.
|
||||
|
||||
:::warning
|
||||
In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is preconized by the application.
|
||||
In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is recommended by the application.
|
||||
:::
|
||||
|
||||
### Firewall
|
||||
|
||||
@ -22,4 +22,4 @@ We can and will still support the `ValidateBasic` function for users and provide
|
||||
|
||||
### Consequences
|
||||
|
||||
The consequence of updating the transaction flow is that transaction that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged.
|
||||
The consequence of updating the transaction flow is that transactions that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged.
|
||||
|
||||
@ -152,7 +152,7 @@ more complex structures, apart from just string messages, and still be able to
|
||||
know exactly what they are signing (opposed to signing a bunch of arbitrary bytes).
|
||||
|
||||
Thus, in the future, the Cosmos signing message specification will be expected
|
||||
to expand upon it's canonical JSON structure to include such functionality.
|
||||
to expand upon its canonical JSON structure to include such functionality.
|
||||
|
||||
## API
|
||||
|
||||
|
||||
@ -29,9 +29,9 @@ with, which also provides the basis of most state storage and commitment operati
|
||||
is the `KVStore`. The `KVStore` interface provides basic CRUD abilities and
|
||||
prefix-based iteration, including reverse iteration.
|
||||
|
||||
Typically, each module has it's own dedicated `KVStore` instance, which it can
|
||||
Typically, each module has its own dedicated `KVStore` instance, which it can
|
||||
get access to via the `sdk.Context` and the use of a pointer-based named key --
|
||||
`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How a exactly a `KVStoreKey`
|
||||
`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How exactly a `KVStoreKey`
|
||||
maps to a `KVStore` will be illustrated below through the `CommitMultiStore`.
|
||||
|
||||
Note, a `KVStore` cannot directly commit state. Instead, a `KVStore` can be wrapped
|
||||
@ -194,7 +194,7 @@ a `BaseApp` instance which internally has a reference to a `CommitMultiStore`
|
||||
that is implemented by a `rootmulti.Store`. The application then registers one or
|
||||
more `KVStoreKey` that pertain to a unique module and thus a `KVStore`. Through
|
||||
the use of an `sdk.Context` and a `KVStoreKey`, each module can get direct access
|
||||
to it's respective `KVStore` instance.
|
||||
to its respective `KVStore` instance.
|
||||
|
||||
Example:
|
||||
|
||||
@ -227,7 +227,7 @@ func NewApp(...) Application {
|
||||
The `rootmulti.Store` itself can be cache-wrapped which returns an instance of a
|
||||
`cachemulti.Store`. For each block, `BaseApp` ensures that the proper abstractions
|
||||
are created on the `CommitMultiStore`, i.e. ensuring that the `rootmulti.Store`
|
||||
is cached-wrapped and uses the resulting `cachemulti.Store` to be set on the
|
||||
is cache-wrapped and uses the resulting `cachemulti.Store` to be set on the
|
||||
`sdk.Context` which is then used for block and transaction execution. As a result,
|
||||
all state mutations due to block and transaction execution are actually held
|
||||
ephemerally until `Commit()` is called by the ABCI client. This concept is further
|
||||
|
||||
@ -102,7 +102,7 @@ func (m *Manager) RegisterExtensions(extensions ...types.ExtensionSnapshotter) e
|
||||
return fmt.Errorf("duplicated snapshotter name: %s", name)
|
||||
}
|
||||
if !IsFormatSupported(extension, extension.SnapshotFormat()) {
|
||||
return fmt.Errorf("snapshotter don't support it's own snapshot format: %s %d", name, extension.SnapshotFormat())
|
||||
return fmt.Errorf("snapshotter doesn't support its own snapshot format: %s %d", name, extension.SnapshotFormat())
|
||||
}
|
||||
m.extensions[name] = extension
|
||||
}
|
||||
|
||||
@ -40,7 +40,7 @@ type ExtensionPayloadReader = func() ([]byte, error)
|
||||
type ExtensionPayloadWriter = func([]byte) error
|
||||
|
||||
// ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream.
|
||||
// ExtensionSnapshotter has an unique name and manages its own internal formats.
|
||||
// ExtensionSnapshotter has a unique name and manages its own internal formats.
|
||||
type ExtensionSnapshotter interface {
|
||||
// SnapshotName returns the name of snapshotter, it should be unique in the manager.
|
||||
SnapshotName() string
|
||||
|
||||
@ -79,7 +79,7 @@ For a full list of configurable options see: https://github.com/open-telemetry/o
|
||||
The node's `init` command will generate an empty otel file in the `~/.<node_home>/config` directory. Place your otel configuration
|
||||
here.
|
||||
|
||||
When the node's `start` command is ran, the OpenTelemetry SDK will be initialized using this file.
|
||||
When the node's `start` command is run, the OpenTelemetry SDK will be initialized using this file.
|
||||
If left empty, all meters and tracers will be noop.
|
||||
|
||||
## OpenTelemetry Initialization
|
||||
@ -107,4 +107,3 @@ NOTE: it is important to thread context.Context properly for spans and metrics t
|
||||
correlated correctly.
|
||||
When using the SDK's context type, spans must be started with Context.StartSpan to
|
||||
get an SDK context which has the span set correctly.
|
||||
|
||||
|
||||
@ -249,7 +249,7 @@ simd query auth --help
|
||||
|
||||
#### account
|
||||
|
||||
The `account` command allow users to query for an account by it's address.
|
||||
The `account` command allows users to query for an account by its address.
|
||||
|
||||
```bash
|
||||
simd query auth account [address] [flags]
|
||||
@ -504,7 +504,7 @@ A user can query the `auth` module using gRPC endpoints.
|
||||
|
||||
#### Account
|
||||
|
||||
The `account` endpoint allow users to query for an account by it's address.
|
||||
The `account` endpoint allows users to query for an account by its address.
|
||||
|
||||
```bash
|
||||
cosmos.auth.v1beta1.Query/Account
|
||||
@ -687,7 +687,7 @@ A user can query the `auth` module using REST endpoints.
|
||||
|
||||
#### Account
|
||||
|
||||
The `account` endpoint allow users to query for an account by it's address.
|
||||
The `account` endpoint allows users to query for an account by its address.
|
||||
|
||||
```bash
|
||||
/cosmos/auth/v1beta1/account?address={address}
|
||||
@ -695,7 +695,7 @@ The `account` endpoint allow users to query for an account by it's address.
|
||||
|
||||
#### Accounts
|
||||
|
||||
The `accounts` endpoint allow users to query all the available accounts.
|
||||
The `accounts` endpoint allows users to query all the available accounts.
|
||||
|
||||
```bash
|
||||
/cosmos/auth/v1beta1/accounts
|
||||
@ -703,7 +703,7 @@ The `accounts` endpoint allow users to query all the available accounts.
|
||||
|
||||
#### Params
|
||||
|
||||
The `params` endpoint allow users to query the current auth parameters.
|
||||
The `params` endpoint allows users to query the current auth parameters.
|
||||
|
||||
```bash
|
||||
/cosmos/auth/v1beta1/params
|
||||
|
||||
@ -125,7 +125,7 @@ aforementioned state:
|
||||
|
||||
## Params
|
||||
|
||||
The bank module stores it's params in state with the prefix of `0x05`,
|
||||
The bank module stores its params in state with the prefix of `0x05`,
|
||||
it can be updated with governance or the address with authority.
|
||||
|
||||
* Params: `0x05 | ProtocolBuffer(Params)`
|
||||
|
||||
@ -198,7 +198,7 @@ type ValidatorDistInfo struct {
|
||||
### Delegation Distribution
|
||||
|
||||
Each delegation distribution only needs to record the height at which it last
|
||||
withdrew fees. Because a delegation must withdraw fees each time it's
|
||||
withdrew fees. Because a delegation must withdraw fees each time its
|
||||
properties change (aka bonded tokens etc.) its properties will remain constant
|
||||
and the delegator's _accumulation_ factor can be calculated passively knowing
|
||||
only the height of the last withdrawal and its current properties.
|
||||
@ -213,7 +213,7 @@ type DelegationDistInfo struct {
|
||||
|
||||
### Params
|
||||
|
||||
The distribution module stores it's params in state with the prefix of `0x09`,
|
||||
The distribution module stores its params in state with the prefix of `0x09`,
|
||||
it can be updated with governance or the address with authority.
|
||||
|
||||
* Params: `0x09 | ProtocolBuffer(Params)`
|
||||
|
||||
@ -148,7 +148,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/slashing/v1be
|
||||
|
||||
### Params
|
||||
|
||||
The slashing module stores it's params in state with the prefix of `0x00`,
|
||||
The slashing module stores its params in state with the prefix of `0x00`,
|
||||
it can be updated with governance or the address with authority.
|
||||
|
||||
* Params: `0x00 | ProtocolBuffer(Params)`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user