From a64ebec493ef2bd08e0c05ca02f2151edf742619 Mon Sep 17 00:00:00 2001 From: maradini77 <140460067+maradini77@users.noreply.github.com> Date: Thu, 11 Dec 2025 16:58:50 +0100 Subject: [PATCH] docs: fix typos and wording in learn and README docs (#25668) --- blockstm/README.md | 2 +- blockstm/utils.go | 2 +- client/v2/autocli/query_test.go | 2 +- docs/README.md | 12 ++++++------ docs/docs/learn/advanced/00-baseapp.md | 4 ++-- docs/docs/learn/advanced/01-transactions.md | 4 ++-- docs/docs/learn/beginner/00-app-anatomy.md | 4 ++-- docs/docs/learn/beginner/01-tx-lifecycle.md | 2 +- docs/docs/learn/beginner/02-query-lifecycle.md | 6 +++--- docs/docs/learn/beginner/03-accounts.md | 6 +++--- docs/docs/learn/beginner/04-gas-fees.md | 6 +++--- docs/docs/learn/intro/00-overview.md | 4 ++-- docs/docs/learn/intro/01-why-app-specific.md | 2 +- store/types/store.go | 2 +- x/auth/migrations/v2/store_test.go | 2 +- x/bank/keeper/virtual.go | 2 +- 16 files changed, 31 insertions(+), 31 deletions(-) diff --git a/blockstm/README.md b/blockstm/README.md index eaedabf6df..5e92cd44a9 100644 --- a/blockstm/README.md +++ b/blockstm/README.md @@ -38,4 +38,4 @@ The internal data structures are also adapted with multiple stores in mind. ### Attribution -This package was originally authored in [go-block-stm](https://github.com/crypto-org-chain/go-block-stm). We have brought the full source tree into the SDK so that we can natively incorporate the library and required changes into the SDK. Over time we expect to incoporate optimizations and deviations from the upstream implementation. +This package was originally authored in [go-block-stm](https://github.com/crypto-org-chain/go-block-stm). We have brought the full source tree into the SDK so that we can natively incorporate the library and required changes into the SDK. Over time we expect to incorporate optimizations and deviations from the upstream implementation. diff --git a/blockstm/utils.go b/blockstm/utils.go index 4909d8f699..f15912a3c3 100644 --- a/blockstm/utils.go +++ b/blockstm/utils.go @@ -37,7 +37,7 @@ func IncrAtomic(a *atomic.Uint64) { a.Add(1) } -// FetchIncr increaes the atomic value by 1 and returns the old value +// FetchIncr increases the atomic value by 1 and returns the old value func FetchIncr(a *atomic.Uint64) uint64 { return a.Add(1) - 1 } diff --git a/client/v2/autocli/query_test.go b/client/v2/autocli/query_test.go index 4983c9e53b..10a9b1f6ea 100644 --- a/client/v2/autocli/query_test.go +++ b/client/v2/autocli/query_test.go @@ -339,7 +339,7 @@ func TestMap(t *testing.T) { assert.ErrorContains(t, err, "invalid argument \"bar=123.9\" for \"--map-string-uint32\" flag: strconv.ParseUint: parsing \"123.9\": invalid syntax") } -// TestEveything tests all the different types of flags are correctly read and as well as correctly returned +// TestEverything tests all the different types of flags are correctly read and as well as correctly returned // This tests the flag binding and the message building func TestEverything(t *testing.T) { fixture := initFixture(t) diff --git a/docs/README.md b/docs/README.md index ce05077da2..346dc7e536 100644 --- a/docs/README.md +++ b/docs/README.md @@ -6,7 +6,7 @@ The documentation for Cosmos SDK is hosted at https://docs.cosmos.network and bu It is built using the following stack: * [Docusaurus 2](https://docusaurus.io) -* Vuepress (pre v0.47) +* VuePress (pre v0.47) * [Algolia DocSearch](https://docsearch.algolia.com/) ```js @@ -23,11 +23,11 @@ It is built using the following stack: ## Docs Build Workflow The docs are built and deployed automatically on GitHub Pages by a [GitHub Action workflow](../.github/workflows/build-docs.yml). -The workflow is triggered on every push to the `main` and `release/v**` branches, every time documentations or specs are modified. +The workflow is triggered on every push to the `main` and `release/v**` branches, every time documentation or specs are modified. ### How It Works -There is a GitHub Action listening for changes in the `/docs` directory for the `main` branch and each supported version branch (e.g. `release/v0.46.x`). Any updates to files in the `/docs` directory will automatically trigger a website deployment. Under the hood, the private website repository has a `make build-docs` target consumed by a Github Action within that repository. +There is a GitHub Action listening for changes in the `/docs` directory for the `main` branch and each supported version branch (e.g. `release/v0.46.x`). Any updates to files in the `/docs` directory will automatically trigger a website deployment. Under the hood, the private website repository has a `make build-docs` target consumed by a GitHub Action within that repository. ## How to Build the Docs Locally @@ -47,7 +47,7 @@ npm start It runs `pre.sh` scripts to get all the docs that are not already in the `docs/docs` folder. It also runs `post.sh` scripts to clean up the docs and remove unnecessary files when quitting. -Note, the command above only build the docs for the current versions. +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. To build all the docs (including versioned documentation), run: @@ -56,7 +56,7 @@ To build all the docs (including versioned documentation), run: make build-docs ``` -## What to for new major SDK versions +## What to do for new major SDK versions When a new major version of the SDK is released, the following steps should be taken: @@ -75,6 +75,6 @@ When a new major version of the SDK is released, the following steps should be t * Add the new version sidebar to the list of versioned sidebar and add the version to `versions.json`. * Update the latest version (`presets[1].docs.lastVersion`) in `docusaurus.config.js`. -* Add the new version with in `presets[1].docs.versions` in `docusaurus.config.js`. +* Add the new version within `presets[1].docs.versions` in `docusaurus.config.js`. Learn more about [versioning](https://docusaurus.io/docs/versioning) in Docusaurus. diff --git a/docs/docs/learn/advanced/00-baseapp.md b/docs/docs/learn/advanced/00-baseapp.md index 8a3d3a7cf0..cc9b899938 100644 --- a/docs/docs/learn/advanced/00-baseapp.md +++ b/docs/docs/learn/advanced/00-baseapp.md @@ -234,10 +234,10 @@ The [Application-Blockchain Interface](https://github.com/cometbft/cometbft/blob The consensus engine handles two main tasks: -* The networking logic, which mainly consists in gossiping block parts, transactions and consensus votes. +* The networking logic, which mainly consists of gossiping block parts, transactions and consensus votes. * The consensus logic, which results in the deterministic ordering of transactions in the form of blocks. -It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. +It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At key moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: diff --git a/docs/docs/learn/advanced/01-transactions.md b/docs/docs/learn/advanced/01-transactions.md index 965e8e8b6c..d48a45582e 100644 --- a/docs/docs/learn/advanced/01-transactions.md +++ b/docs/docs/learn/advanced/01-transactions.md @@ -83,7 +83,7 @@ need to sign over the fees: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.proto#L68-L93 ``` -The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and +The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need for an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and create the final transaction by appending a fee. Note that the fee payer of the transaction (in our case Charlie) must sign over the fees, so must use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. @@ -128,7 +128,7 @@ While messages contain the information for state transition logic, a transaction ### Transaction Generation -The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can set to generate the desired transaction: +The `TxBuilder` interface contains data closely related to the generation of transactions, which an end-user can set to generate the desired transaction: ```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/client/tx_config.go#L39-L57 diff --git a/docs/docs/learn/beginner/00-app-anatomy.md b/docs/docs/learn/beginner/00-app-anatomy.md index 988c7242a9..1957666c56 100644 --- a/docs/docs/learn/beginner/00-app-anatomy.md +++ b/docs/docs/learn/beginner/00-app-anatomy.md @@ -147,7 +147,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/params/encoding.go#L9-L Here are descriptions of what each of the four fields means: -* `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations. +* `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought of as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations. * You can read more about `Any` in [ADR-019](../../build/architecture/adr-019-protobuf-state-encoding.md). * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](../../build/architecture/adr-019-protobuf-state-encoding.md). * `Codec`: The default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` used to output data to the users (for example, in the [CLI](#cli)). By default, the SDK uses Protobuf as `Codec`. @@ -255,7 +255,7 @@ The Cosmos SDK also provides a development endpoint to generate [Swagger](https: The main interface is the [Command-Line Interface](../advanced/07-cli.md). The CLI of a Cosmos SDK application is built by aggregating [CLI commands](#cli) defined in each of the modules used by the application. The CLI of an application is the same as the daemon (e.g. `appd`), and is defined in a file called `appd/main.go`. The file contains the following: * **A `main()` function**, which is executed to build the `appd` interface client. This function prepares each command and adds them to the `rootCmd` before building them. At the root of `appd`, the function adds generic commands like `status`, `keys`, and `config`, query commands, tx commands, and `rest-server`. -* **Query commands**, which are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query command are called by using the command `appd query [query]` of the CLI. +* **Query commands**, which are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query commands are called by using the command `appd query [query]` of the CLI. * **Transaction commands**, which are added by calling the `txCmd` function. Similar to `queryCmd`, the function returns a Cobra command that contains the tx commands defined in each of the application's modules, as well as lower level tx commands like transaction signing or broadcasting. Tx commands are called by using the command `appd tx [tx]` of the CLI. See an example of an application's main command-line file from the [Cosmos Hub](https://github.com/cosmos/gaia). diff --git a/docs/docs/learn/beginner/01-tx-lifecycle.md b/docs/docs/learn/beginner/01-tx-lifecycle.md index b2e821e9f8..62f4850555 100644 --- a/docs/docs/learn/beginner/01-tx-lifecycle.md +++ b/docs/docs/learn/beginner/01-tx-lifecycle.md @@ -98,7 +98,7 @@ through several steps, beginning with decoding `Tx`. ### Decoding -When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT ), it is still in its [encoded](../advanced/05-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../advanced/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes. +When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT), it is still in its [encoded](../advanced/05-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../advanced/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes. ### ValidateBasic (deprecated) diff --git a/docs/docs/learn/beginner/02-query-lifecycle.md b/docs/docs/learn/beginner/02-query-lifecycle.md index c3d7eb1ccc..a5093d3ad8 100644 --- a/docs/docs/learn/beginner/02-query-lifecycle.md +++ b/docs/docs/learn/beginner/02-query-lifecycle.md @@ -47,7 +47,7 @@ One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC ```bash grpcurl \ - -plaintext # We want results in plain test + -plaintext # We want results in plain text -import-path ./proto \ # Import these .proto files -proto ./proto/cosmos/staking/v1beta1/query.proto \ # Look into this .proto file for the Query protobuf service -d '{"address":"$MY_DELEGATOR"}' \ # Query arguments @@ -76,7 +76,7 @@ The first thing that is created in the execution of a CLI command is a `client.C * **Codec**: The [encoder/decoder](../advanced/05-encoding.md) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. * **Account Decoder**: The account decoder from the [`auth`](../../build/modules/auth/README.md) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. -* **Keyring**: A [Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. +* **Keyring**: A [Key Manager](../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. * **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query, and `--indent`, which indicates to add an indent to the JSON response. @@ -134,7 +134,7 @@ Once a result is received from the querier, `baseapp` begins the process of retu ## Response -Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.cometbft.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response and. +Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.cometbft.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response. ### CLI Response diff --git a/docs/docs/learn/beginner/03-accounts.md b/docs/docs/learn/beginner/03-accounts.md index 150436b9d3..87148ca384 100644 --- a/docs/docs/learn/beginner/03-accounts.md +++ b/docs/docs/learn/beginner/03-accounts.md @@ -75,7 +75,7 @@ The Cosmos SDK supports the following digital key schemes for creating digital s * `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keys/secp256r1/pubkey.go). * `tm-ed25519`, as implemented in the [Cosmos SDK `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation. -| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (cometbft) | +| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (CometBFT) | | :----------: | :---------------------: | :------------------------: | :---------------------------------: | :-----------------------------: | | `secp256k1` | 20 | 33 | yes | no | | `secp256r1` | 32 | 33 | yes | no | @@ -167,7 +167,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.pro ### Create New Key Type -To create a new key type for using in keyring, `keyring.SignatureAlgo` interface must be fulfilled. +To create a new key type for use in the keyring, the `keyring.SignatureAlgo` interface must be fulfilled. ```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keyring/signing_algorithms.go#L11-L16 @@ -194,7 +194,7 @@ First a new function to create a private key from a secret number is needed in t ```go // cosmos-sdk/crypto/keys/secp256r1/privkey.go -// NewPrivKeyFromSecret creates a private key derived for the secret number +// NewPrivKeyFromSecret creates a private key derived from the secret number // represented in big-endian. The `secret` must be a valid ECDSA field element. func NewPrivKeyFromSecret(secret []byte) (*PrivKey, error) { var d = new(big.Int).SetBytes(secret) diff --git a/docs/docs/learn/beginner/04-gas-fees.md b/docs/docs/learn/beginner/04-gas-fees.md index 5aea1238be..e0bfbd57cb 100644 --- a/docs/docs/learn/beginner/04-gas-fees.md +++ b/docs/docs/learn/beginner/04-gas-fees.md @@ -16,10 +16,10 @@ This document describes the default strategies to handle gas and fees within a C ## Introduction to `Gas` and `Fees` -In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: +In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever reads and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: * Make sure blocks are not consuming too many resources and are finalized. This is implemented by default in the Cosmos SDK via the [block gas meter](#block-gas-meter). -* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](../../build/building-modules/02-messages-and-queries.md#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). +* Prevent spam and abuse by end-users. To this end, `gas` consumed during [`message`](../../build/building-modules/02-messages-and-queries.md#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). ## Gas Meter @@ -98,4 +98,4 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/proto/cosmos/tx/v1beta1/t * Verify that the sender of the transaction has enough funds to cover for the `fees`. When the end-user generates a transaction, they must indicate 2 of the 3 following parameters (the third one being implicit): `fees`, `gas` and `gas-prices`. This signals how much they are willing to pay for nodes to execute their transaction. The provided `gas` value is stored in a parameter called `GasWanted` for later use. * Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each transaction (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time a transaction executes). -As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`FinalizeBlock`](../advanced/00-baseapp.md#finalizeblock) returns. +As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed <= GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`FinalizeBlock`](../advanced/00-baseapp.md#finalizeblock) returns. diff --git a/docs/docs/learn/intro/00-overview.md b/docs/docs/learn/intro/00-overview.md index f1e896f396..62a7332dac 100644 --- a/docs/docs/learn/intro/00-overview.md +++ b/docs/docs/learn/intro/00-overview.md @@ -7,13 +7,13 @@ sidebar_position: 1 The [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) is an open-source toolkit for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub, as well as permissioned Proof-of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. -We further this modular approach by allowing developers to plug and play with different consensus engines this can range from the [CometBFT](https://github.com/cometbft/cometbft) or [Rollkit](https://rollkit.dev/). +We further this modular approach by allowing developers to plug and play with different consensus engines. This can range from the [CometBFT](https://github.com/cometbft/cometbft) or [Rollkit](https://rollkit.dev/). SDK-based blockchains have the choice to use the predefined modules or to build their own modules. What this means is that developers can build a blockchain that is tailored to their specific use case, without having to worry about the low-level details of building a blockchain from scratch. Predefined modules include staking, governance, and token issuance, among others. What's more, the Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](../advanced/10-ocap.md). -How you can look at this is if we imagine that the SDK is like a lego kit. You can choose to build the basic house from the instructions or you can choose to modify your house and add more floors, more doors, more windows. The choice is yours. +How you can look at this is if we imagine that the SDK is like a LEGO kit. You can choose to build the basic house from the instructions or you can choose to modify your house and add more floors, more doors, more windows. The choice is yours. ## What are Application-Specific Blockchains diff --git a/docs/docs/learn/intro/01-why-app-specific.md b/docs/docs/learn/intro/01-why-app-specific.md index df16c19af0..bee2ae37ea 100644 --- a/docs/docs/learn/intro/01-why-app-specific.md +++ b/docs/docs/learn/intro/01-why-app-specific.md @@ -32,7 +32,7 @@ Blockchain node | | Consensus | | Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralized applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize. -Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralized platforms. Here is why: +Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret Turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralized platforms. Here is why: * Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails. * Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can severely restrain **performance**. And even if the state-machine were to be split in multiple subsets (e.g. via sharding), Smart Contracts would still need to be interpreted by a virtual machine, which would limit performance compared to a native application implemented at state-machine level (our benchmarks show an improvement on the order of 10x in performance when the virtual-machine is removed). diff --git a/store/types/store.go b/store/types/store.go index 2c9f6c4c7f..154adcef87 100644 --- a/store/types/store.go +++ b/store/types/store.go @@ -289,7 +289,7 @@ type GIterator[V any] interface { // Error returns the last error encountered by the iterator, if any. Error() error - // Close closes the iterator, relasing any allocated resources. + // Close closes the iterator, releasing any allocated resources. Close() error } diff --git a/x/auth/migrations/v2/store_test.go b/x/auth/migrations/v2/store_test.go index e1b3ae8b39..551070255f 100644 --- a/x/auth/migrations/v2/store_test.go +++ b/x/auth/migrations/v2/store_test.go @@ -85,7 +85,7 @@ func TestMigrateVestingAccounts(t *testing.T) { testCases := []struct { name string prepareFunc func(ctx sdk.Context, validator stakingtypes.Validator, delegatorAddr sdk.AccAddress) - garbageFunc func(ctx sdk.Context, vesting exported.VestingAccount, accounKeeper keeper.AccountKeeper) error + garbageFunc func(ctx sdk.Context, vesting exported.VestingAccount, accountKeeper keeper.AccountKeeper) error tokenAmount int64 expVested int64 expFree int64 diff --git a/x/bank/keeper/virtual.go b/x/bank/keeper/virtual.go index d56ce71ea6..0fe6a51e3b 100644 --- a/x/bank/keeper/virtual.go +++ b/x/bank/keeper/virtual.go @@ -43,7 +43,7 @@ func (k BaseSendKeeper) SendCoinsFromModuleToAccountVirtual( // SendCoinsToVirtual accumulate the recipient's coins in a per-transaction transient state, // which are sumed up and added to the real account at the end of block. -// Events are emiited the same as normal send. +// Events are emitted the same as normal send. func (k BaseSendKeeper) SendCoinsToVirtual(ctx context.Context, fromAddr, toAddr sdk.AccAddress, amt sdk.Coins) error { var err error err = k.subUnlockedCoins(ctx, fromAddr, amt)