docs: fix typos and wording across SDK documentation READMEs (#25696)
Co-authored-by: Alex | Cosmos Labs <alex@cosmoslabs.io>
This commit is contained in:
Alvarez
GitHub
parent
7f6082add7
commit
d201ca9ae4
@ -301,7 +301,7 @@ app.EpochsKeeper = epochskeeper.NewKeeper(
|
||||
|
||||
Set up hooks for the epochs keeper:
|
||||
|
||||
To learn how to write hooks for the epoch keeper, see the [x/epoch README](https://github.com/cosmos/cosmos-sdk/blob/main/x/epochs/README.md)
|
||||
To learn how to write hooks for the epoch keeper, see the [x/epochs README](https://github.com/cosmos/cosmos-sdk/blob/main/x/epochs/README.md)
|
||||
|
||||
```go
|
||||
app.EpochsKeeper.SetHooks(
|
||||
|
||||
@ -48,7 +48,7 @@ It runs `pre.sh` scripts to get all the docs that are not already in the `docs/d
|
||||
It also runs `post.sh` scripts to clean up the docs and remove unnecessary files when quitting.
|
||||
|
||||
Note, the command above only builds the docs for the current versions.
|
||||
With the drawback that none of the redirections works. So, you'll need to go to /main to see the docs.
|
||||
With the drawback that none of the redirects work. So, you'll need to go to /main to see the docs.
|
||||
|
||||
To build all the docs (including versioned documentation), run:
|
||||
|
||||
@ -60,7 +60,7 @@ make build-docs
|
||||
|
||||
When a new major version of the SDK is released, the following steps should be taken:
|
||||
|
||||
* On the `release/vX.Y.Z` branch, remove the deploy action (`.github/workflows/build-docs.yml`), for avoiding deploying the docs from the release branches.
|
||||
* On the `release/vX.Y.Z` branch, remove the deploy action (`.github/workflows/build-docs.yml`) to avoid deploying the docs from the release branches.
|
||||
* On the `release/vX.Y.Z` branch, update `docusaurus.config.js` and set the `lastVersion` to `current`, remove all other versions from the config.
|
||||
* Each time a new version is released (on docusaurus), drop support from the oldest versions.
|
||||
* If the old version is still running vuepress (v0.45, v0.46), remove its line from `vuepress_versions`
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Store
|
||||
|
||||
The store package defines the interfaces, types and abstractions for Cosmos SDK
|
||||
The store package defines the interfaces, types, and abstractions for Cosmos SDK
|
||||
modules to read and write to Merkleized state within a Cosmos SDK application.
|
||||
The store package provides many primitives for developers to use in order to
|
||||
work with both state storage and state commitment. Below we describe the various
|
||||
|
||||
@ -22,6 +22,6 @@ export PRELAUNCH_GENESIS_URL=https://raw.githubusercontent.com/cosmos/mainnet/ma
|
||||
export GENTXS_DIR=~/go/src/github.com/cosmos/mainnet/$CHAIN_ID/gentxs
|
||||
```
|
||||
|
||||
Though this script is handy for verifying the gentxs locally, it is advised to use Github Action to validate gentxs.
|
||||
Though this script is handy for verifying the gentxs locally, it is advised to use GitHub Action to validate gentxs.
|
||||
An example can be found here:
|
||||
https://github.com/regen-network/mainnet/blob/0bcd387671b9574e893289e39c08a1643cac7d62/.github/workflows/validate-gentx.yml
|
||||
|
||||
@ -23,7 +23,7 @@ developers and end-users, see the
|
||||
Briefly, the Cosmos SDK takes state snapshots at regular height intervals given
|
||||
by `state-sync.snapshot-interval` and stores them as binary files in the
|
||||
filesystem under `<node_home>/data/snapshots/`, with metadata in a LevelDB database
|
||||
`<node_home>/data/snapshots/metadata.db`. The number of recent snapshots to keep are given by
|
||||
`<node_home>/data/snapshots/metadata.db`. The number of recent snapshots to keep is given by
|
||||
`state-sync.snapshot-keep-recent`.
|
||||
|
||||
Snapshots are taken asynchronously, i.e. new blocks will be applied concurrently
|
||||
|
||||
@ -4,7 +4,7 @@ This package contains an extensible plugin system for the Cosmos-SDK. The plugin
|
||||
|
||||
Although the `go-plugin` is built to work over RPC, it is currently only designed to work over a local network.
|
||||
|
||||
## Pre requisites
|
||||
## Prerequisites
|
||||
|
||||
For an overview of supported features by the `go-plugin` system, please see https://github.com/hashicorp/go-plugin. The `go-plugin` documentation is located [here](https://github.com/hashicorp/go-plugin/tree/master/docs). You can also directly visit any of the links below:
|
||||
|
||||
@ -25,6 +25,6 @@ Read the plugin documentation in the [Streaming Plugins](#streaming-plugins) sec
|
||||
|
||||
## Streaming Plugins
|
||||
|
||||
List of support streaming plugins
|
||||
List of supported streaming plugins
|
||||
|
||||
* [ABCI State Streaming Plugin](abci/README.md)
|
||||
|
||||
@ -35,7 +35,7 @@ for the documentation.
|
||||
|
||||
### gRPC Client and Server
|
||||
|
||||
Implementing the ABCIListener gRPC client and server is a simple and straight forward process.
|
||||
Implementing the ABCIListener gRPC client and server is a simple and straightforward process.
|
||||
|
||||
To create the client and server we create a `ListenerGRPCPlugin` struct that implements the
|
||||
`plugin.GRPCPlugin` interface and a `Impl` property that will contain a concrete implementation
|
||||
@ -185,7 +185,7 @@ Export a plugin from one of the Go or Python examples.
|
||||
export COSMOS_SDK_ABCI="{path to}/cosmos-sdk/store/streaming/abci/examples/file/file"
|
||||
```
|
||||
|
||||
where `{path to}` is the parent path to the `cosmos-sdk` repo on you system.
|
||||
where `{path to}` is the parent path to the `cosmos-sdk` repo on your system.
|
||||
|
||||
Test:
|
||||
|
||||
|
||||
@ -14,4 +14,4 @@ cd store
|
||||
go build -o streaming/abci/examples/file/file streaming/abci/examples/file/file.go
|
||||
```
|
||||
|
||||
* The plugin will write files to the users home directory `~/`.
|
||||
* The plugin will write files to the user's home directory `~/`.
|
||||
|
||||
@ -23,7 +23,7 @@ Server and client-side operations are executed on the host machine.
|
||||
|
||||
### Test strategy
|
||||
|
||||
System tests cover the full stack via cli and a running (multi node) network. They are more expensive (in terms of time/ cpu)
|
||||
System tests cover the full stack via CLI and a running (multi-node) network. They are more expensive (in terms of time/cpu)
|
||||
to run compared to unit or integration tests.
|
||||
Therefore, we focus on the **critical path** and do not cover every condition.
|
||||
|
||||
@ -37,7 +37,7 @@ Read the [GETTING_STARTED](../systemtests/GETTING_STARTED.md) guide to get start
|
||||
go test -tags system_test -count=1 -v . --run TestStakeUnstake -verbose
|
||||
```
|
||||
|
||||
Test cli parameters
|
||||
Test CLI parameters
|
||||
|
||||
* `-verbose` verbose output
|
||||
* `-wait-time` duration - time to wait for chain events (default 30s)
|
||||
|
||||
@ -4,7 +4,7 @@ Go black box tests that setup and interact with a local blockchain. The system t
|
||||
works with the compiled binary of the chain artifact only.
|
||||
To get up to speed, checkout the [getting started guide](../../systemtests/GETTING_STARTED.md).
|
||||
|
||||
Beside the Go tests and testdata files, this directory can contain the following directories:
|
||||
Besides the Go tests and testdata files, this directory can contain the following directories:
|
||||
|
||||
* `binaries` - cache for binary
|
||||
* `testnet` - node files
|
||||
|
||||
@ -125,7 +125,7 @@ All arguments passed to `cosmovisor run` will be passed to the application binar
|
||||
└── preupgrade.sh (optional)
|
||||
```
|
||||
|
||||
The `cosmovisor/` directory includes a subdirectory for each version of the application (i.e. `genesis` or `upgrades/<name>`). Within each subdirectory is the application binary (i.e. `bin/$DAEMON_NAME`) and any additional auxiliary files associated with each binary. `current` is a symbolic link to the currently active directory (i.e. `genesis` or `upgrades/<name>`). The `name` variable in `upgrades/<name>` is the lowercased URI-encoded name of the upgrade as specified in the upgrade module plan. Note that the upgrade name path are normalized to be lowercased: for instance, `MyUpgrade` is normalized to `myupgrade`, and its path is `upgrades/myupgrade`.
|
||||
The `cosmovisor/` directory includes a subdirectory for each version of the application (i.e. `genesis` or `upgrades/<name>`). Within each subdirectory is the application binary (i.e. `bin/$DAEMON_NAME`) and any additional auxiliary files associated with each binary. `current` is a symbolic link to the currently active directory (i.e. `genesis` or `upgrades/<name>`). The `name` variable in `upgrades/<name>` is the lowercased URI-encoded name of the upgrade as specified in the upgrade module plan. Note that upgrade name paths are normalized to lowercase: for instance, `MyUpgrade` is normalized to `myupgrade`, and its path is `upgrades/myupgrade`.
|
||||
|
||||
Please note that `$DAEMON_HOME/cosmovisor` only stores the *application binaries*. The `cosmovisor` binary itself can be stored in any typical location (e.g. `/usr/local/bin`). The application will continue to store its data in the default data directory (e.g. `$HOME/.simapp`) or the data directory specified with the `--home` flag. `$DAEMON_HOME` is dependent of the data directory and must be set to the same directory as the data directory, you will end up with a configuration like the following:
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ the core functionality of your blockchain. They can be thought of as ways to ex
|
||||
capabilities of your blockchain or further specialize it.
|
||||
|
||||
* [Authz](./authz/README.md) - Authorization for accounts to perform actions on behalf of other accounts.
|
||||
* [Epochs](./epochs/README.md) - Registration so SDK modules can have logic to be executed at the timed tickers.
|
||||
* [Epochs](./epochs/README.md) - Registration so SDK modules can have logic to be executed on timed tickers.
|
||||
* [Feegrant](./feegrant/README.md) - Grant fee allowances for executing transactions.
|
||||
* [ProtocolPool](./protocolpool/README.md) - Extended management of community pool functionality.
|
||||
|
||||
@ -60,3 +60,4 @@ The CosmWasm module enables smart contracts, learn more by going to their [docum
|
||||
## EVM
|
||||
|
||||
Read more about writing smart contracts with solidity at the official [`evm` documentation page](https://evm.cosmos.network/).
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ costs of gas in each token denomination they wish to support:
|
||||
|
||||
`simd start ... --minimum-gas-prices=0.00001stake;0.05photinos`
|
||||
|
||||
When adding transactions to mempool or gossipping transactions, validators check
|
||||
When adding transactions to mempool or gossiping transactions, validators check
|
||||
if the transaction's gas prices, which are determined by the provided fees, meet
|
||||
any of the validator's minimum gas prices. In other words, a transaction must
|
||||
provide a fee of at least one denomination that matches a validator's minimum
|
||||
|
||||
@ -94,7 +94,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/feegrant/v1be
|
||||
|
||||
* `allowance` is either `BasicAllowance` or `PeriodicAllowance`.
|
||||
|
||||
* `allowed_messages` is array of messages allowed to execute the given allowance.
|
||||
* `allowed_messages` is an array of messages allowed to execute the given allowance.
|
||||
|
||||
### FeeGranter flag
|
||||
|
||||
|
||||
@ -10,14 +10,14 @@ This paper specifies the Governance module of the Cosmos SDK, which was first
|
||||
described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in
|
||||
June 2016.
|
||||
|
||||
The module enables Cosmos SDK based blockchain to support an on-chain governance
|
||||
The module enables Cosmos SDK-based blockchains to support an on-chain governance
|
||||
system. In this system, holders of the native staking token of the chain can vote
|
||||
on proposals on a 1 token 1 vote basis. Next is a list of features the module
|
||||
currently supports:
|
||||
|
||||
* **Proposal submission:** Users can submit proposals with a deposit. Once the
|
||||
minimum deposit is reached, the proposal enters voting period. The minimum deposit can be reached by collecting deposits from different users (including proposer) within deposit period.
|
||||
* **Vote:** Participants can vote on proposals that reached MinDeposit and entered voting period.
|
||||
minimum deposit is reached, the proposal enters the voting period. The minimum deposit can be reached by collecting deposits from different users (including proposer) within the deposit period.
|
||||
* **Vote:** Participants can vote on proposals that reached MinDeposit and entered the voting period.
|
||||
* **Inheritance and penalties:** Delegators inherit their validator's vote if
|
||||
they don't vote themselves.
|
||||
* **Claiming deposit:** Users that deposited on proposals can recover their
|
||||
@ -66,12 +66,12 @@ staking token of the chain.
|
||||
|
||||
*Disclaimer: This is work in progress. Mechanisms are susceptible to change.*
|
||||
|
||||
The governance process is divided in a few steps that are outlined below:
|
||||
The governance process is divided into a few steps that are outlined below:
|
||||
|
||||
* **Proposal submission:** Proposal is submitted to the blockchain with a
|
||||
deposit.
|
||||
* **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is
|
||||
confirmed and vote opens. Bonded Atom holders can then send `TxGovVote`
|
||||
* **Vote:** Once the deposit reaches a certain value (`MinDeposit`), the proposal is
|
||||
confirmed and the vote opens. Bonded Atom holders can then send `TxGovVote`
|
||||
transactions to vote on the proposal.
|
||||
* **Execution** After a period of time, the votes are tallied and depending
|
||||
on the result, the messages in the proposal will be executed.
|
||||
@ -166,7 +166,7 @@ proposal but accept the result of the vote.
|
||||
|
||||
[ADR-037](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-037-gov-split-vote.md) introduces the weighted vote feature which allows a staker to split their votes into several voting options. For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No.
|
||||
|
||||
Often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll.
|
||||
Oftentimes the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Currently, it is not possible for them to do "passthrough voting" and give their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll.
|
||||
|
||||
To represent weighted vote on chain, we use the following Protobuf message.
|
||||
|
||||
|
||||
@ -11,13 +11,13 @@ NOTE: `x/params` is deprecated as of Cosmos SDK v0.53 and will be removed in the
|
||||
Package params provides a globally available parameter store.
|
||||
|
||||
There are two main types, Keeper and Subspace. Subspace is an isolated namespace for a
|
||||
paramstore, where keys are prefixed by preconfigured spacename. Keeper has a
|
||||
paramstore, where keys are prefixed by a preconfigured space name. Keeper has a
|
||||
permission to access all existing spaces.
|
||||
|
||||
Subspace can be used by the individual keepers, which need a private parameter store
|
||||
that the other keepers cannot modify. The params Keeper can be used to add a route to `x/gov` router in order to modify any parameter in case a proposal passes.
|
||||
|
||||
The following contents explains how to use params module for master and user modules.
|
||||
The following sections explain how to use the params module for master and user modules.
|
||||
|
||||
## Contents
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ This paper specifies the Staking module of the Cosmos SDK that was first
|
||||
described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper)
|
||||
in June 2016.
|
||||
|
||||
The module enables Cosmos SDK-based blockchain to support an advanced
|
||||
The module enables Cosmos SDK-based blockchains to support an advanced
|
||||
Proof-of-Stake (PoS) system. In this system, holders of the native staking token of
|
||||
the chain can become validators and can delegate tokens to validators,
|
||||
ultimately determining the effective validator set for the system.
|
||||
|
||||
@ -37,7 +37,7 @@ A `Plan` is created once a (frozen) release candidate along with an appropriate
|
||||
`Handler` (see below) is agreed upon, where the `Name` of a `Plan` corresponds to a
|
||||
specific `Handler`. Typically, a `Plan` is created through a governance proposal
|
||||
process, where if voted upon and passed, will be scheduled. The `Info` of a `Plan`
|
||||
may contain various metadata about the upgrade, typically application specific
|
||||
may contain various metadata about the upgrade, typically application-specific
|
||||
upgrade info to be included on-chain such as a git commit that validators could
|
||||
automatically upgrade to.
|
||||
|
||||
@ -79,7 +79,7 @@ or if the binary was upgraded too early, the node will gracefully panic and exit
|
||||
|
||||
The `x/upgrade` module also facilitates store migrations as part of the upgrade. The
|
||||
`StoreLoader` sets the migrations that need to occur before the new binary can
|
||||
successfully run the chain. This `StoreLoader` is also application specific and
|
||||
successfully run the chain. This `StoreLoader` is also application-specific and
|
||||
not defined on a per-module basis. Registering this `StoreLoader` is done via
|
||||
`app#SetStoreLoader` in the application.
|
||||
|
||||
@ -89,10 +89,10 @@ func UpgradeStoreLoader (upgradeHeight int64, storeUpgrades *store.StoreUpgrades
|
||||
|
||||
If there's a planned upgrade and the upgrade height is reached, the old binary writes `Plan` to the disk before panicking.
|
||||
|
||||
This information is critical to ensure the `StoreUpgrades` happens smoothly at correct height and
|
||||
This information is critical to ensure the `StoreUpgrades` happens smoothly at the correct height and
|
||||
expected upgrade. It eliminates the chances for the new binary to execute `StoreUpgrades` multiple
|
||||
times every time on restart. Also if there are multiple upgrades planned on same height, the `Name`
|
||||
will ensure these `StoreUpgrades` takes place only in planned upgrade handler.
|
||||
times every time on restart. Also if there are multiple upgrades planned on the same height, the `Name`
|
||||
will ensure these `StoreUpgrades` take place only in the planned upgrade handler.
|
||||
|
||||
### Proposal
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user