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

docs: fix typos in documentation files (#25064)

Browse Source 
Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>
This commit is contained in:
Tomass 2025-07-31 19:51:50 +03:00 committed by GitHub
parent bf17b0636f
commit 591305c75c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
11 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/architecture/adr-033-protobuf-inter-module-comm.md
View File

@ -94,7 +94,7 @@ evolution.
the two which checks if one module is authorized to send the specified `Msg` to the other module providing a proper
object capability system (see below).
3. The router for inter-module communication gives us a convenient place to handle rollback of transactions,
enabling atomicy of operations ([currently a problem](https://github.com/cosmos/cosmos-sdk/issues/8030)). Any failure within a module-to-module call would result in a failure of the entire
enabling atomicity of operations ([currently a problem](https://github.com/cosmos/cosmos-sdk/issues/8030)). Any failure within a module-to-module call would result in a failure of the entire
transaction
This mechanism has the added benefits of:

4
docs/architecture/adr-049-state-sync-hooks.md
View File

@ -144,9 +144,9 @@ As a result of this implementation, we are able to create snapshots of binary ch
### Backwards Compatibility
This ADR introduces new proto message types, add an `extensions` field in snapshot `Manager`, and add new `ExtensionSnapshotter` interface, so this is not backwards compatible if we have extensions.
This ADR introduces new proto message types, adds an `extensions` field in snapshot `Manager`, and add new `ExtensionSnapshotter` interface, so this is not backwards compatible if we have extensions.
But for applications that does not have the state data outside of the IAVL tree for any module, the snapshot stream is backwards-compatible.
But for applications that do not have the state data outside of the IAVL tree for any module, the snapshot stream is backwards-compatible.
### Positive

2
docs/architecture/adr-061-liquid-staking.md
View File

@ -1,4 +1,4 @@
# ADR ADR-061: Liquid Staking
# ADR-061: Liquid Staking
## Changelog

2
docs/architecture/adr-064-abci-2.0.md
View File

@ -120,7 +120,7 @@ Recall, an implementation of `ExtendVoteHandler` does NOT need to be determinist
however, given a set of vote extensions, `VerifyVoteExtensionHandler` must be
deterministic, otherwise the chain may suffer from liveness faults. In addition,
recall CometBFT proceeds in rounds for each height, so if a decision cannot be
made about about a block proposal at a given height, CometBFT will proceed to the
made about a block proposal at a given height, CometBFT will proceed to the
next round and thus will execute `ExtendVote` and `VerifyVoteExtension` again for
the new round for each validator until 2/3 valid pre-commits can be obtained.

2
docs/architecture/adr-076-tx-malleability.md
View File

@ -72,7 +72,7 @@ In addition to being aware of the general non-determinism of protobuf binary, de
In addition to the non-determinism present in protobuf binary itself, some protobuf field data is encoded using a micro-format which itself may not be deterministic. Consider for instance integer or decimal encoding. Some decoders may allow for the presence of leading or trailing zeros without changing the logical meaning, ex. `00100` vs `100` or `100.00` vs `100`. So if a sign mode encodes numbers deterministically, but decoders accept multiple representations,
a user may sign over the value `100` while `0100` gets encoded. This would be possible with Amino JSON to the extent that the integer decoder accepts leading zeros. I believe the current `Int` implementation will reject this, however, it is
probably possible to encode a octal or hexadecimal representation in the transaction whereas the user signs over a decimal integer.
probably possible to encode an octal or hexadecimal representation in the transaction whereas the user signs over a decimal integer.
#### Signature Encoding

2
docs/docs/build/building-apps/03-app-upgrade.md vendored
View File

@ -25,7 +25,7 @@ How would this look in practice? First, we want to finalize the v0.40.0 release
and then install a specially named upgrade handler (eg. "testnet-v2" or even "v0.40.0"). An upgrade
handler should be defined in a new version of the software to define what migrations
to run to migrate from the older version of the software. Naturally, this is app-specific rather
than module specific, and must be defined in `app.go`, even if it imports logic from various
than module specific, and must be defined in `app.go`, even if it imports logic from various
modules to perform the actions. You can register them with `upgradeKeeper.SetUpgradeHandler`
during the app initialization (before starting the abci server), and they serve not only to
perform a migration, but also to identify if this is the old or new version (eg. presence of

2
docs/docs/build/building-modules/03-msg-services.md vendored
View File

@ -56,7 +56,7 @@ ValidateMsgA(msg MsgA, now Time, gm GasMeter) error {
return sdkerrrors.ErrInvalidRequest.Wrap("msg expired")
}
gm.ConsumeGas(1000, "signature verification")
return signatureVerificaton(msg.Prover, msg.Data)
return signatureVerification(msg.Prover, msg.Data)
}
```

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

@ -5,7 +5,7 @@ sidebar_position: 1
# PreBlocker
:::note Synopsis
`PreBlocker` is optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](../../learn/advanced/00-baseapp.md#beginblock).
`PreBlocker` is an optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](../../learn/advanced/00-baseapp.md#beginblock).
:::
:::note Pre-requisite Readings

2
docs/docs/learn/advanced/04-store.md
View File

@ -220,7 +220,7 @@ This is the type used whenever an IAVL Store needs to be branched to create an i
#### `Iterator`
`Store.Iterator()` have to traverse on both cached items and the original items. In `Store.iterator()`, two iterators are generated for each of them, and merged. `memIterator` is essentially a slice of the `KVPairs`, used for cached items. `mergeIterator` is a combination of two iterators, where traverse happens ordered on both iterators.
`Store.Iterator()` has to traverse on both cached items and the original items. In `Store.iterator()`, two iterators are generated for each of them, and merged. `memIterator` is essentially a slice of the `KVPairs`, used for cached items. `mergeIterator` is a combination of two iterators, where traverse happens ordered on both iterators.
### `GasKv` Store

2
docs/docs/learn/advanced/07-cli.md
View File

@ -153,7 +153,7 @@ Flags are added to commands directly (generally in the [module's CLI file](../..
## Environment variables
Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--node` for application with basename `GAIA` is bound to `GAIA_NODE`. It allows reducing the amount of flags typed for routine operations. For example instead of:
Each flag is bound to its respective named environment variable. The name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--node` for application with basename `GAIA` is bound to `GAIA_NODE`. It allows reducing the amount of flags typed for routine operations. For example instead of:
```shell
gaia --home=./ --node=<node address> --chain-id="testchain-1" --keyring-backend=test tx ... --from=<key name>

2
docs/docs/learn/advanced/09-telemetry.md
View File

@ -91,7 +91,7 @@ The following examples expose too much cardinality and may not even prove to be
| `tx_msg_withdraw_commission` | The total amount of tokens withdrawn in a `MsgWithdrawValidatorCommission` (per denom) | token | gauge |
| `tx_msg_delegate` | The total amount of tokens delegated in a `MsgDelegate` | token | gauge |
| `tx_msg_begin_unbonding` | The total amount of tokens undelegated in a `MsgUndelegate` | token | gauge |
| `tx_msg_begin_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge |
| `tx_msg_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge |
| `tx_msg_ibc_transfer` | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain) | token | gauge |
| `ibc_transfer_packet_receive` | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token | gauge |
| `new_account` | Total number of new accounts created | account | counter |