docs: lint (#24854)
This commit is contained in:
Alex | Interchain Labs
GitHub
parent
1b72b047e2
commit
78bb60a377
17
CHANGELOG.md
17
CHANGELOG.md
@ -41,7 +41,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
### Breaking Changes
|
||||
|
||||
* [#24837](https://github.com/cosmos/cosmos-sdk/pull/24837) Update to using CometBFT v2.
|
||||
* This update changes the import paths from `cometbft/cometbft` to `cometbft/cometbft/v2`. Users can use the migration tool to automatically update their nodes.
|
||||
* This update changes the import paths from `cometbft/cometbft` to `cometbft/cometbft/v2`. Users can use the migration tool to automatically update their nodes.
|
||||
|
||||
### Features
|
||||
|
||||
@ -81,7 +81,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
* (crypto/keyring) [#24040](https://github.com/cosmos/cosmos-sdk/pull/24040) Expose the db keyring used in the keystore.
|
||||
* (types) [#23919](https://github.com/cosmos/cosmos-sdk/pull/23919) Add MustValAddressFromBech32 function.
|
||||
* (all) [#23708](https://github.com/cosmos/cosmos-sdk/pull/23708) Add unordered transaction support.
|
||||
* Adds a `--timeout-timestamp` flag that allows users to specify a block time at which the unordered transactions should expire from the mempool.
|
||||
* Adds a `--timeout-timestamp` flag that allows users to specify a block time at which the unordered transactions should expire from the mempool.
|
||||
* (x/epochs) [#23815](https://github.com/cosmos/cosmos-sdk/pull/23815) Upstream `x/epochs` from Osmosis
|
||||
* (client) [#23811](https://github.com/cosmos/cosmos-sdk/pull/23811) Add auto cli for node service.
|
||||
* (genutil) [#24018](https://github.com/cosmos/cosmos-sdk/pull/24018) Allow manually setting the consensus key type in genesis
|
||||
@ -89,11 +89,11 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
* (x/auth) [#24030](https://github.com/cosmos/cosmos-sdk/pull/24030) Allow usage of ed25519 keys for transaction signing.
|
||||
* (baseapp) [#24163](https://github.com/cosmos/cosmos-sdk/pull/24163) Add `StreamingManager` to baseapp to extend the abci listeners.
|
||||
* (x/protocolpool) [#23933](https://github.com/cosmos/cosmos-sdk/pull/23933) Add x/protocolpool module.
|
||||
* x/distribution can now utilize an externally managed community pool. NOTE: this will make the message handlers for FundCommunityPool and CommunityPoolSpend error, as well as the query handler for CommunityPool.
|
||||
* x/distribution can now utilize an externally managed community pool. NOTE: this will make the message handlers for FundCommunityPool and CommunityPoolSpend error, as well as the query handler for CommunityPool.
|
||||
* (client) [#18101](https://github.com/cosmos/cosmos-sdk/pull/18101) Add a `keyring-default-keyname` in `client.toml` for specifying a default key name, and skip the need to use the `--from` flag when signing transactions.
|
||||
* (x/gov) [#24355](https://github.com/cosmos/cosmos-sdk/pull/24355) Allow users to set a custom CalculateVoteResultsAndVotingPower function to be used in govkeeper.Tally.
|
||||
* (x/mint) [#24436](https://github.com/cosmos/cosmos-sdk/pull/24436) Allow users to set a custom minting function used in the `x/mint` begin blocker.
|
||||
* The `InflationCalculationFn` argument to `mint.NewAppModule()` is now ignored and must be nil. To set a custom `InflationCalculationFn` on the default minter, use `mintkeeper.WithMintFn(mintkeeper.DefaultMintFn(customInflationFn))`.
|
||||
* The `InflationCalculationFn` argument to `mint.NewAppModule()` is now ignored and must be nil. To set a custom `InflationCalculationFn` on the default minter, use `mintkeeper.WithMintFn(mintkeeper.DefaultMintFn(customInflationFn))`.
|
||||
* (api) [#24428](https://github.com/cosmos/cosmos-sdk/pull/24428) Add block height to response headers
|
||||
|
||||
### Improvements
|
||||
@ -103,7 +103,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
* (telemetry) [#24541](https://github.com/cosmos/cosmos-sdk/pull/24541) Telemetry now includes a pre_blocker metric key. x/upgrade should migrate to this key in v0.54.0.
|
||||
* (x/auth) [#24541](https://github.com/cosmos/cosmos-sdk/pull/24541) x/auth's PreBlocker now emits telemetry under the pre_blocker metric key.
|
||||
* (x/bank) [#24431](https://github.com/cosmos/cosmos-sdk/pull/24431) Reduce the number of `ValidateDenom` calls in `bank.SendCoins` and `Coin`.
|
||||
* The `AmountOf()` method on`sdk.Coins` no longer will `panic` if given an invalid denom and will instead return a zero value.
|
||||
* The `AmountOf()` method on`sdk.Coins` no longer will `panic` if given an invalid denom and will instead return a zero value.
|
||||
* (x/staking) [#24391](https://github.com/cosmos/cosmos-sdk/pull/24391) Replace panics with error results; more verbose error messages
|
||||
* (x/staking) [#24354](https://github.com/cosmos/cosmos-sdk/pull/24354) Optimize validator endblock by reducing bech32 conversions, resulting in significant performance improvement
|
||||
* (client/keys) [#18950](https://github.com/cosmos/cosmos-sdk/pull/18950) Improve `<appd> keys add`, `<appd> keys import` and `<appd> keys rename` by checking name validation.
|
||||
@ -224,11 +224,6 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
* [#20631](https://github.com/cosmos/cosmos-sdk/pull/20631) Fix json parsing in the wait-tx command.
|
||||
* (x/auth) [#20438](https://github.com/cosmos/cosmos-sdk/pull/20438) Add `--skip-signature-verification` flag to multisign command to allow nested multisigs.
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
* (simulation) [#17911](https://github.com/cosmos/cosmos-sdk/pull/17911) Fix all problems with executing command `make test-sim-custom-genesis-fast` for simulation test.
|
||||
* (simulation) [#18196](https://github.com/cosmos/cosmos-sdk/pull/18196) Fix the problem of `validator set is empty after InitGenesis` in simulation test.
|
||||
|
||||
## [v0.50.7](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.7) - 2024-06-04
|
||||
|
||||
### Improvements
|
||||
@ -240,6 +235,8 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* (simulation) [#17911](https://github.com/cosmos/cosmos-sdk/pull/17911) Fix all problems with executing command `make test-sim-custom-genesis-fast` for simulation test.
|
||||
* (simulation) [#18196](https://github.com/cosmos/cosmos-sdk/pull/18196) Fix the problem of `validator set is empty after InitGenesis` in simulation test.
|
||||
* (baseapp) [#20346](https://github.com/cosmos/cosmos-sdk/pull/20346) Correctly assign `execModeSimulate` to context for `simulateTx`.
|
||||
* (baseapp) [#20144](https://github.com/cosmos/cosmos-sdk/pull/20144) Remove txs from mempool when AnteHandler fails in recheck.
|
||||
* (baseapp) [#20107](https://github.com/cosmos/cosmos-sdk/pull/20107) Avoid header height overwrite block height.
|
||||
|
||||
@ -6,21 +6,21 @@ This guide includes one **required** change and three **optional** features.
|
||||
|
||||
After completing this guide, applications will have:
|
||||
|
||||
- The `x/protocolpool` module
|
||||
- The `x/epochs` module
|
||||
- Unordered Transaction support
|
||||
* The `x/protocolpool` module
|
||||
* The `x/epochs` module
|
||||
* Unordered Transaction support
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [App Wiring Changes (REQUIRED)](#app-wiring-changes-required)
|
||||
- [Adding ProtocolPool Module (OPTIONAL)](#adding-protocolpool-module-optional)
|
||||
- [ProtocolPool Manual Wiring](#protocolpool-manual-wiring)
|
||||
- [ProtocolPool DI Wiring](#protocolpool-di-wiring)
|
||||
- [Adding Epochs Module (OPTIONAL)](#adding-epochs-module-optional)
|
||||
- [Epochs Manual Wiring](#epochs-manual-wiring)
|
||||
- [Epochs DI Wiring](#epochs-di-wiring)
|
||||
- [Enable Unordered Transactions (OPTIONAL)](#enable-unordered-transactions-optional)
|
||||
- [Upgrade Handler](#upgrade-handler)
|
||||
* [App Wiring Changes (REQUIRED)](#app-wiring-changes-required)
|
||||
* [Adding ProtocolPool Module (OPTIONAL)](#adding-protocolpool-module-optional)
|
||||
* [ProtocolPool Manual Wiring](#protocolpool-manual-wiring)
|
||||
* [ProtocolPool DI Wiring](#protocolpool-di-wiring)
|
||||
* [Adding Epochs Module (OPTIONAL)](#adding-epochs-module-optional)
|
||||
* [Epochs Manual Wiring](#epochs-manual-wiring)
|
||||
* [Epochs DI Wiring](#epochs-di-wiring)
|
||||
* [Enable Unordered Transactions (OPTIONAL)](#enable-unordered-transactions-optional)
|
||||
* [Upgrade Handler](#upgrade-handler)
|
||||
|
||||
## App Wiring Changes **REQUIRED**
|
||||
|
||||
@ -41,12 +41,12 @@ Using an external community pool such as `x/protocolpool` will cause the followi
|
||||
|
||||
**QueryService**
|
||||
|
||||
- `CommunityPool`
|
||||
* `CommunityPool`
|
||||
|
||||
**MsgService**
|
||||
|
||||
- `CommunityPoolSpend`
|
||||
- `FundCommunityPool`
|
||||
* `CommunityPoolSpend`
|
||||
* `FundCommunityPool`
|
||||
|
||||
If your services depend on this functionality from `x/distribution`, please update them to use either `x/protocolpool` or your custom external community pool alternatives.
|
||||
|
||||
@ -500,4 +500,4 @@ func (app SimApp) RegisterUpgradeHandlers() {
|
||||
app.SetStoreLoader(upgradetypes.UpgradeStoreLoader(upgradeInfo.Height, &storeUpgrades))
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
@ -6,7 +6,7 @@ Note, always read the **App Wiring Changes** section for more information on app
|
||||
|
||||
🚨Upgrading to v0.54.x will require a **coordinated** chain upgrade.🚨
|
||||
|
||||
### TLDR;
|
||||
### TLDR
|
||||
|
||||
**The only major feature in Cosmos SDK v0.54.x is the upgrade from CometBFT v0.x.x to CometBFT v2.**
|
||||
|
||||
@ -23,4 +23,4 @@ is still used if `NextBlockDelay` is 0 (its default value). This means that whe
|
||||
the existing `timout_commit` values that validators have been using will be maintained and have the same behavior.
|
||||
|
||||
For setting the field in your application, there is a new `baseapp` option, `SetNextBlockDelay` which can be passed to your application upon
|
||||
initialization in `app.go`. Setting this value to any non-zero value will override anything that is set in validators' `config.toml`.
|
||||
initialization in `app.go`. Setting this value to any non-zero value will override anything that is set in validators' `config.toml`.
|
||||
|
||||
@ -34,6 +34,8 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
|
||||
# Changelog
|
||||
|
||||
## UNRELEASED
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* [#24722](https://github.com/cosmos/cosmos-sdk/pull/24722) Fix msg parsing in when no pulsar file is present.
|
||||
@ -111,7 +113,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
* [#20083](https://github.com/cosmos/cosmos-sdk/pull/20083) Integrate latest version of cosmos-proto and improve version filtering.
|
||||
* [#19618](https://github.com/cosmos/cosmos-sdk/pull/19618) Marshal enum as string in queries.
|
||||
* [#19060](https://github.com/cosmos/cosmos-sdk/pull/19060) Use client context from root (or enhanced) command in autocli commands.
|
||||
* Note, the given command must have a `client.Context` in its context.
|
||||
* Note, the given command must have a `client.Context` in its context.
|
||||
* [#19216](https://github.com/cosmos/cosmos-sdk/pull/19216) Do not overwrite TxConfig, use directly the one provided in context. TxConfig should always be set in the `client.Context` in `root.go` of an app.
|
||||
* [#20266](https://github.com/cosmos/cosmos-sdk/pull/20266) Add ability to override the short description in AutoCLI-generated top-level commands.
|
||||
|
||||
|
||||
@ -423,7 +423,7 @@ The third type of collection is the `collections.Item`.
|
||||
It stores only one single item, it's useful for example for parameters, there's only one instance
|
||||
of parameters in state always.
|
||||
|
||||
#### implementation curiosity
|
||||
### implementation curiosity
|
||||
|
||||
A `collections.Item` is just a `collections.Map` with no key but just a value.
|
||||
The key is the prefix of the collection!
|
||||
@ -683,7 +683,7 @@ func NewKeeper(storeKey *storetypes.KVStoreKey) Keeper {
|
||||
}
|
||||
```
|
||||
|
||||
#### The Map Key definition
|
||||
### The Map Key definition
|
||||
|
||||
First of all we can see that in order to define a composite key of two elements we use the `collections.Pair` type:
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ We propose middleware-solution, which could help developers implement the follow
|
||||
* call panic for specific error cases;
|
||||
|
||||
It will also make `OutOfGas` case and `default` case one of the middlewares.
|
||||
`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#Recovery-middleware)).
|
||||
`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#recovery-middleware)).
|
||||
|
||||
Our project has a sidecar service running alongside the blockchain node (smart contracts virtual machine). It is
|
||||
essential that node <-> sidecar connectivity stays stable for TXs processing. So when the communication breaks we need
|
||||
|
||||
@ -95,6 +95,7 @@ All fields in the `UpgradeInstructions` are optional.
|
||||
| `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. |
|
||||
| `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. |
|
||||
If defined, then the app supervisors (e.g. Cosmovisor) MUST NOT run `app pre-run`.
|
||||
|
||||
* `post_run` is a command to run after the upgraded chain has been started. If defined, this command MUST be only executed at most once by an upgrading node.
|
||||
The output and exit code SHOULD be logged but SHOULD NOT affect the running of the upgraded chain.
|
||||
The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`.
|
||||
|
||||
@ -195,6 +195,7 @@ Messages that have a custom encoding, including `google.protobuf.Timestamp`, `go
|
||||
#### Examples
|
||||
|
||||
Message header screen is stripped, one-level of indentation removed:
|
||||
|
||||
```
|
||||
/cosmos.gov.v1.Vote
|
||||
> Proposal id: 4
|
||||
@ -210,6 +211,7 @@ Message header screen is stripped, one-level of indentation removed:
|
||||
```
|
||||
|
||||
Message with custom encoding:
|
||||
|
||||
```
|
||||
/cosmos.base.v1beta1.Coin
|
||||
> 10uatom
|
||||
@ -271,8 +273,9 @@ Examples:
|
||||
* The hexadecimal string is finally separated into groups of 4 digits, with a space `' '` as separator. If the bytes length is odd, the 2 remaining hexadecimal characters are at the end.
|
||||
|
||||
The number 35 was chosen because it is the longest length where the hashed-and-prefixed representation is longer than the original data directly formatted, using the 3 rules above. More specifically:
|
||||
- a 35-byte array will have 70 hex characters, plus 17 space characters, resulting in 87 characters.
|
||||
- byte arrays starting from length 36 will be be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters.
|
||||
|
||||
* a 35-byte array will have 70 hex characters, plus 17 space characters, resulting in 87 characters.
|
||||
* byte arrays starting from length 36 will be be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters.
|
||||
Also, secp256k1 public keys have length 33, so their Textual representation is not their hashed value, which we would like to avoid.
|
||||
|
||||
Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](./adr-050-sign-mode-textual.md#invertible-rendering) for a discussion.
|
||||
|
||||
@ -424,6 +424,7 @@ way that requires duplication and differing sets of design principles (protobuf
|
||||
while golang APIs would forbid it).
|
||||
|
||||
Other downsides to this approach are:
|
||||
|
||||
* no clear roadmap to supporting modules in other languages like Rust
|
||||
* doesn't get us any closer to proper object capability security (one of the goals of ADR 033)
|
||||
* ADR 033 needs to be done properly anyway for the set of use cases which do need it
|
||||
@ -447,6 +448,7 @@ languages, possibly executed within a WASM VM.
|
||||
|
||||
To declare minor API revisions of proto files, we propose the following guidelines (which were already documented
|
||||
in [cosmos.app.v1alpha module options](../proto/cosmos/app/v1alpha1/module.proto)):
|
||||
|
||||
* proto packages which are revised from their initial version (considered revision `0`) should include a `package`
|
||||
* comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current
|
||||
revision number.
|
||||
@ -522,6 +524,7 @@ func ProtoImage(protoImage []byte) Option {}
|
||||
```
|
||||
|
||||
This approach allows us to support several ways protobuf files might be generated:
|
||||
|
||||
* proto files generated internally to a module (use `ProtoFiles`)
|
||||
* the API module approach with pinned file descriptors (use `ProtoImage`)
|
||||
* gogo proto (use `GzippedProtoFiles`)
|
||||
|
||||
@ -64,6 +64,7 @@ A code generator is included with the ORM which creates type safe wrappers aroun
|
||||
implementation and is the recommended way for modules to use the ORM.
|
||||
|
||||
The ORM tests provide a simplified bank module demonstration which illustrates:
|
||||
|
||||
* [ORM proto options](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.proto)
|
||||
* [Generated Code](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.cosmos_orm.go)
|
||||
* [Example Usage in a Module Keeper](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/model/ormdb/module_test.go)
|
||||
|
||||
@ -303,15 +303,17 @@ Code generation requires that all providers and invokers and their parameters ar
|
||||
|
||||
When we start creating semantically versioned SDK modules that are in standalone go modules, a state machine breaking
|
||||
change to a module should be handled as follows:
|
||||
- the semantic major version should be incremented, and
|
||||
- a new semantically versioned module config protobuf type should be created.
|
||||
|
||||
* the semantic major version should be incremented, and
|
||||
* a new semantically versioned module config protobuf type should be created.
|
||||
|
||||
For instance, if we have the SDK module for bank in the go module `github.com/cosmos/cosmos-sdk/x/bank` with the module config type
|
||||
`cosmos.bank.module.v1.Module`, and we want to make a state machine breaking change to the module, we would:
|
||||
- create a new go module `github.com/cosmos/cosmos-sdk/x/bank/v2`,
|
||||
- with the module config protobuf type `cosmos.bank.module.v2.Module`.
|
||||
|
||||
This _does not_ mean that we need to increment the protobuf API version for bank. Both modules can support
|
||||
* create a new go module `github.com/cosmos/cosmos-sdk/x/bank/v2`,
|
||||
* with the module config protobuf type `cosmos.bank.module.v2.Module`.
|
||||
|
||||
This *does not* mean that we need to increment the protobuf API version for bank. Both modules can support
|
||||
`cosmos.bank.v1`, but `github.com/cosmos/cosmos-sdk/x/bank/v2` will be a separate go module with a separate module config type.
|
||||
|
||||
This practice will eventually allow us to use appconfig to load new versions of a module via a configuration change.
|
||||
@ -320,7 +322,7 @@ Effectively, there should be a 1:1 correspondence between a semantically version
|
||||
versioned module config protobuf type, and major versioning bumps should occur whenever state machine breaking changes
|
||||
are made to a module.
|
||||
|
||||
NOTE: SDK modules that are standalone go modules _should not_ adopt semantic versioning until the concerns described in
|
||||
NOTE: SDK modules that are standalone go modules *should not* adopt semantic versioning until the concerns described in
|
||||
[ADR 054: Module Semantic Versioning](./adr-054-semver-compatible-modules.md) are
|
||||
addressed. The short-term solution for this issue was left somewhat unresolved. However, the easiest tactic is
|
||||
likely to use a standalone API go module and follow the guidelines described in this comment: https://github.com/cosmos/cosmos-sdk/pull/11802#issuecomment-1406815181. For the time-being, it is recommended that
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# ADR 062: Collections, a simplified storage layer for cosmos-sdk modules.
|
||||
# ADR 062: Collections, a simplified storage layer for cosmos-sdk modules
|
||||
|
||||
## Changelog
|
||||
|
||||
@ -18,30 +18,32 @@ storage in a simple and straightforward manner, whilst offering safety, extensib
|
||||
Module developers are forced into manually implementing storage functionalities in their modules, those functionalities include
|
||||
but are not limited to:
|
||||
|
||||
- Defining key to bytes formats.
|
||||
- Defining value to bytes formats.
|
||||
- Defining secondary indexes.
|
||||
- Defining query methods to expose outside to deal with storage.
|
||||
- Defining local methods to deal with storage writing.
|
||||
- Dealing with genesis imports and exports.
|
||||
- Writing tests for all the above.
|
||||
* Defining key to bytes formats.
|
||||
* Defining value to bytes formats.
|
||||
* Defining secondary indexes.
|
||||
* Defining query methods to expose outside to deal with storage.
|
||||
* Defining local methods to deal with storage writing.
|
||||
* Dealing with genesis imports and exports.
|
||||
* Writing tests for all the above.
|
||||
|
||||
|
||||
This brings in a lot of problems:
|
||||
- It blocks developers from focusing on the most important part: writing business logic.
|
||||
- Key to bytes formats are complex and their definition is error-prone, for example:
|
||||
- how do I format time to bytes in such a way that bytes are sorted?
|
||||
- how do I ensure when I don't have namespace collisions when dealing with secondary indexes?
|
||||
- The lack of standardisation makes life hard for clients, and the problem is exacerbated when it comes to providing proofs for objects present in state. Clients are forced to maintain a list of object paths to gather proofs.
|
||||
|
||||
* It blocks developers from focusing on the most important part: writing business logic.
|
||||
* Key to bytes formats are complex and their definition is error-prone, for example:
|
||||
* how do I format time to bytes in such a way that bytes are sorted?
|
||||
* how do I ensure when I don't have namespace collisions when dealing with secondary indexes?
|
||||
* The lack of standardisation makes life hard for clients, and the problem is exacerbated when it comes to providing proofs for objects present in state. Clients are forced to maintain a list of object paths to gather proofs.
|
||||
|
||||
### Current Solution: ORM
|
||||
|
||||
The current SDK proposed solution to this problem is [ORM](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-055-orm.md).
|
||||
Whilst ORM offers a lot of good functionality aimed at solving these specific problems, it has some downsides:
|
||||
- It requires migrations.
|
||||
- It uses the newest protobuf golang API, whilst the SDK still mainly uses gogoproto.
|
||||
- Integrating ORM into a module would require the developer to deal with two different golang frameworks (golang protobuf + gogoproto) representing the same API objects.
|
||||
- It has a high learning curve, even for simple storage layers as it requires developers to have knowledge around protobuf options, custom cosmos-sdk storage extensions, and tooling download. Then after this they still need to learn the code-generated API.
|
||||
|
||||
* It requires migrations.
|
||||
* It uses the newest protobuf golang API, whilst the SDK still mainly uses gogoproto.
|
||||
* Integrating ORM into a module would require the developer to deal with two different golang frameworks (golang protobuf + gogoproto) representing the same API objects.
|
||||
* It has a high learning curve, even for simple storage layers as it requires developers to have knowledge around protobuf options, custom cosmos-sdk storage extensions, and tooling download. Then after this they still need to learn the code-generated API.
|
||||
|
||||
### CosmWasm Solution: cw-storage-plus
|
||||
|
||||
@ -56,11 +58,11 @@ We propose to port the `collections` API, whose implementation lives in [NibiruC
|
||||
|
||||
Collections implements four different storage handlers types:
|
||||
|
||||
- `Map`: which deals with simple `key=>object` mappings.
|
||||
- `KeySet`: which acts as a `Set` and only retains keys and no object (usecase: allow-lists).
|
||||
- `Item`: which always contains only one object (usecase: Params)
|
||||
- `Sequence`: which implements a simple always increasing number (usecase: Nonces)
|
||||
- `IndexedMap`: builds on top of `Map` and `KeySet` and allows to create relationships with `Objects` and `Objects` secondary keys.
|
||||
* `Map`: which deals with simple `key=>object` mappings.
|
||||
* `KeySet`: which acts as a `Set` and only retains keys and no object (usecase: allow-lists).
|
||||
* `Item`: which always contains only one object (usecase: Params)
|
||||
* `Sequence`: which implements a simple always increasing number (usecase: Nonces)
|
||||
* `IndexedMap`: builds on top of `Map` and `KeySet` and allows to create relationships with `Objects` and `Objects` secondary keys.
|
||||
|
||||
All the collection APIs build on top of the simple `Map` type.
|
||||
|
||||
@ -77,9 +79,10 @@ which is relevant for swapping serialisation frameworks and enhancing performanc
|
||||
These default implementations also offer safety around proper lexicographic ordering and namespace-collision.
|
||||
|
||||
Examples of the collections API can be found here:
|
||||
- introduction: https://github.com/NibiruChain/collections/tree/main/examples
|
||||
- usage in nibiru: [x/oracle](https://github.com/NibiruChain/nibiru/blob/master/x/oracle/keeper/keeper.go#L32), [x/perp](https://github.com/NibiruChain/nibiru/blob/master/x/perp/keeper/keeper.go#L31)
|
||||
- cosmos-sdk's x/staking migrated: https://github.com/testinginprod/cosmos-sdk/pull/22
|
||||
|
||||
* introduction: https://github.com/NibiruChain/collections/tree/main/examples
|
||||
* usage in nibiru: [x/oracle](https://github.com/NibiruChain/nibiru/blob/master/x/oracle/keeper/keeper.go#L32), [x/perp](https://github.com/NibiruChain/nibiru/blob/master/x/perp/keeper/keeper.go#L31)
|
||||
* cosmos-sdk's x/staking migrated: https://github.com/testinginprod/cosmos-sdk/pull/22
|
||||
|
||||
|
||||
## Consequences
|
||||
@ -92,17 +95,17 @@ the upgrade to the new storage layer non-state breaking.
|
||||
|
||||
### Positive
|
||||
|
||||
- ADR aimed at removing code from the SDK rather than adding it. Migrating just `x/staking` to collections would yield to a net decrease in LOC (even considering the addition of collections itself).
|
||||
- Simplifies and standardises storage layers across modules in the SDK.
|
||||
- Does not require to have to deal with protobuf.
|
||||
- It's pure golang code.
|
||||
- Generalisation over `KeyEncoders` and `ValueEncoders` allows us to not tie ourself to the data serialisation framework.
|
||||
- `KeyEncoders` and `ValueEncoders` can be extended to provide schema reflection.
|
||||
* ADR aimed at removing code from the SDK rather than adding it. Migrating just `x/staking` to collections would yield to a net decrease in LOC (even considering the addition of collections itself).
|
||||
* Simplifies and standardises storage layers across modules in the SDK.
|
||||
* Does not require to have to deal with protobuf.
|
||||
* It's pure golang code.
|
||||
* Generalisation over `KeyEncoders` and `ValueEncoders` allows us to not tie ourself to the data serialisation framework.
|
||||
* `KeyEncoders` and `ValueEncoders` can be extended to provide schema reflection.
|
||||
|
||||
### Negative
|
||||
|
||||
- Golang generics are not as battle-tested as other Golang features, despite being used in production right now.
|
||||
- Collection types instantiation needs to be improved.
|
||||
* Golang generics are not as battle-tested as other Golang features, despite being used in production right now.
|
||||
* Collection types instantiation needs to be improved.
|
||||
|
||||
### Neutral
|
||||
|
||||
@ -110,8 +113,8 @@ the upgrade to the new storage layer non-state breaking.
|
||||
|
||||
## Further Discussions
|
||||
|
||||
- Automatic genesis import/export (not implemented because of API breakage)
|
||||
- Schema reflection
|
||||
* Automatic genesis import/export (not implemented because of API breakage)
|
||||
* Schema reflection
|
||||
|
||||
|
||||
## References
|
||||
|
||||
@ -463,10 +463,11 @@ module manager and follow the Cosmos SDK's existing [0-based versioning](https:/
|
||||
versioning as well as runtime modularity, new officially supported runtime modules will be created under the
|
||||
`cosmossdk.io/runtime` prefix. For each supported consensus engine a semantically-versioned go module should be created
|
||||
with a runtime implementation for that consensus engine. For example:
|
||||
- `cosmossdk.io/runtime/comet`
|
||||
- `cosmossdk.io/runtime/comet/v2`
|
||||
- `cosmossdk.io/runtime/rollkit`
|
||||
- etc.
|
||||
|
||||
* `cosmossdk.io/runtime/comet`
|
||||
* `cosmossdk.io/runtime/comet/v2`
|
||||
* `cosmossdk.io/runtime/rollkit`
|
||||
* etc.
|
||||
|
||||
These runtime modules should attempt to be semantically versioned even if the underlying consensus engine is not. Also,
|
||||
because a runtime module is also a first class Cosmos SDK module, it should have a protobuf module config type.
|
||||
|
||||
@ -29,10 +29,11 @@ Suggested this new lifecycle method.
|
||||
|
||||
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.
|
||||
* 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 finalize context:
|
||||
|
||||
```
|
||||
app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())
|
||||
```
|
||||
@ -55,6 +56,7 @@ The new ctx must be passed to all the other lifecycle methods.
|
||||
## Test Cases
|
||||
|
||||
## References
|
||||
|
||||
* [1] https://github.com/cosmos/cosmos-sdk/issues/16494
|
||||
* [2] https://github.com/cosmos/cosmos-sdk/pull/16583
|
||||
* [3] https://github.com/cosmos/cosmos-sdk/pull/17421
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Dec 4, 2023: Initial Draft (@yihuang, @tac0turtle, @alexanderbez)
|
||||
- Jan 30, 2024: Include section on deterministic transaction encoding
|
||||
- Mar 18, 2025: Revise implementation to use Cosmos SDK KV Store and require unique timeouts per-address (@technicallyty)
|
||||
- Apr 25, 2025: Add note about rejecting unordered txs with sequence values.
|
||||
* Dec 4, 2023: Initial Draft (@yihuang, @tac0turtle, @alexanderbez)
|
||||
* Jan 30, 2024: Include section on deterministic transaction encoding
|
||||
* Mar 18, 2025: Revise implementation to use Cosmos SDK KV Store and require unique timeouts per-address (@technicallyty)
|
||||
* Apr 25, 2025: Add note about rejecting unordered txs with sequence values.
|
||||
|
||||
## Status
|
||||
|
||||
@ -39,8 +39,8 @@ will be recorded to state.
|
||||
|
||||
New transactions will be checked against the state to prevent duplicate submissions. To prevent the state from growing indefinitely, we propose the following:
|
||||
|
||||
- Define an upper bound for the value of `timeout_timestamp` (i.e. 10 minutes).
|
||||
- Add PreBlocker method x/auth that removes state entries with a `timeout_timestamp` earlier than the current block time.
|
||||
* Define an upper bound for the value of `timeout_timestamp` (i.e. 10 minutes).
|
||||
* Add PreBlocker method x/auth that removes state entries with a `timeout_timestamp` earlier than the current block time.
|
||||
|
||||
### Transaction Format
|
||||
|
||||
|
||||
@ -25,6 +25,7 @@ This document attempts to enumerate the various potential transaction "malleabil
|
||||
### Risks Associated with Malleability
|
||||
|
||||
The malleability of transactions poses the following potential risks to end users:
|
||||
|
||||
* unsigned data could get added to transactions and be processed by state machines
|
||||
* clients often rely on transaction hashes for checking transaction status, but whether or not submitted transaction hashes match processed transaction hashes depends primarily on good network actors rather than fundamental protocol guarantees
|
||||
* transactions could potentially get executed more than once (faulty replay protection)
|
||||
@ -49,6 +50,7 @@ increasing account sequence number.
|
||||
#### Non-deterministic Protobuf Encoding
|
||||
|
||||
Cosmos SDK transactions are encoded using protobuf binary encoding when they are submitted to the network. Protobuf binary is not inherently a deterministic encoding meaning that the same logical payload could have several valid bytes representations. In a basic sense, this means that protobuf in general can be decoded and re-encoded to produce a different byte stream (and thus different hash) without changing the logical meaning of the bytes. [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) describes in detail what needs to be done to produce what we consider to be a "canonical", deterministic protobuf serialization. Briefly, the following sources of malleability at the encoding level have been identified and are addressed by this specification:
|
||||
|
||||
* fields can be emitted in any order
|
||||
* default field values can be included or omitted, and this doesn't change meaning unless `optional` is used
|
||||
* `repeated` fields of scalars may use packed or "regular" encoding
|
||||
@ -56,6 +58,7 @@ Cosmos SDK transactions are encoded using protobuf binary encoding when they are
|
||||
* extra fields may be added and are usually simply ignored by decoders. [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) specifies that in general such extra fields should cause messages and transactions to be rejected)
|
||||
|
||||
When using `SIGN_MODE_DIRECT` none of the above malleabilities will be tolerated because:
|
||||
|
||||
* signatures of messages and extensions must be done over the raw encoded bytes of those fields
|
||||
* the outer tx envelope (`TxRaw`) must follow ADR 027 rules or be rejected
|
||||
|
||||
@ -114,6 +117,7 @@ For the known malleability of the `Multisignature` type, we should make sure tha
|
||||
were encoded following canonical ADR 027 rules when doing signature verification.
|
||||
|
||||
`SIGN_MODE_DIRECT_AUX` provides the same level of safety as `SIGN_MODE_DIRECT` because
|
||||
|
||||
* the raw encoded `TxBody` bytes are signed over in `SignDocDirectAux`, and
|
||||
* a transaction using `SIGN_MODE_DIRECT_AUX` still requires the primary signer to sign the transaction with `SIGN_MODE_DIRECT`
|
||||
|
||||
@ -123,6 +127,7 @@ were encoded following canonical ADR 027 rules when doing signature verification
|
||||
Unfortunately, the vast majority of unaddressed malleability risks affect `SIGN_MODE_LEGACY_AMINO_JSON` and this
|
||||
sign mode is still commonly used.
|
||||
It is recommended that the following improvements be made to Amino JSON signing:
|
||||
|
||||
* hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleablity is addressed
|
||||
* when constructing `AminoSignDoc`, [protoreflect](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect) API should be used to ensure that there no fields in `TxBody` or `AuthInfo` which do not have a mapping in `AminoSignDoc` have been set
|
||||
* fields present in `TxBody` or `AuthInfo` that are not present in `AminoSignDoc` (such as extension options) should
|
||||
@ -133,12 +138,13 @@ be added to `AminoSignDoc` if possible
|
||||
To test that transactions are resistant to malleability,
|
||||
we can develop a test suite to run against all sign modes that
|
||||
attempts to manipulate transaction bytes in the following ways:
|
||||
- changing protobuf encoding by
|
||||
- reordering fields
|
||||
- setting default values
|
||||
- adding extra bits to varints, or
|
||||
- setting new unknown fields
|
||||
- modifying integer and decimal values encoded as strings with leading or trailing zeros
|
||||
|
||||
* changing protobuf encoding by
|
||||
* reordering fields
|
||||
* setting default values
|
||||
* adding extra bits to varints, or
|
||||
* setting new unknown fields
|
||||
* modifying integer and decimal values encoded as strings with leading or trailing zeros
|
||||
|
||||
Whenever any of these manipulations is done, we should observe that the sign doc bytes for the sign mode being
|
||||
tested also change, meaning that the corresponding signatures will also have to change.
|
||||
@ -147,8 +153,9 @@ In the case of Amino JSON, we should also develop tests which ensure that if any
|
||||
field not supported by Amino's `AminoSignDoc` is set that signing fails.
|
||||
|
||||
In the general case of transaction decoding, we should have unit tests to ensure that
|
||||
- any `TxRaw` bytes which do not follow ADR 027 canonical encoding cause decoding to fail, and
|
||||
- any top-level transaction elements including `TxBody`, `AuthInfo`, public keys, and messages which
|
||||
|
||||
* any `TxRaw` bytes which do not follow ADR 027 canonical encoding cause decoding to fail, and
|
||||
* any top-level transaction elements including `TxBody`, `AuthInfo`, public keys, and messages which
|
||||
have unknown fields set cause the transaction to be rejected
|
||||
(this ensures that ADR 020 unknown field filtering is properly applied)
|
||||
|
||||
|
||||
13
docs/docs/build/building-modules/14-simulator.md
vendored
13
docs/docs/build/building-modules/14-simulator.md
vendored
@ -18,11 +18,11 @@ Simulations are useful for testing edge cases in module implementations.
|
||||
* [Simulation Package](#simulation-package)
|
||||
* [Simulation App Module](#simulation-app-module)
|
||||
* [SimsX](#simsx)
|
||||
* [Example Implementations](#example-implementations)
|
||||
* [Example Implementations](#example-implementations)
|
||||
* [Store decoders](#store-decoders)
|
||||
* [Randomized genesis](#randomized-genesis)
|
||||
* [Random weighted operations](#random-weighted-operations)
|
||||
* [Using Simsx](#using-simsx)
|
||||
* [Using Simsx](#using-simsx)
|
||||
* [App Simulator manager](#app-simulator-manager)
|
||||
* [Running Simulations](#running-simulations)
|
||||
|
||||
@ -47,6 +47,7 @@ See an example implementation of these methods from `x/distribution` [here](http
|
||||
Cosmos SDK v0.53.0 introduced a new package, `simsx`, providing improved DevX for writing simulation code.
|
||||
|
||||
It exposes the following extension interfaces that modules may implement to integrate with the new `simsx` runner.
|
||||
|
||||
```go reference
|
||||
https://github.com/cosmos/cosmos-sdk/blob/main/testutil/simsx/runner.go#L223-L234
|
||||
```
|
||||
@ -62,9 +63,9 @@ If the module does **not** have message handlers or governance proposal handlers
|
||||
|
||||
### Example Implementations
|
||||
|
||||
- `HasWeightedOperationsXWithProposals`: [x/gov](https://github.com/cosmos/cosmos-sdk/blob/main/x/gov/module.go#L242-L261)
|
||||
- `HasWeightedOperationsX`: [x/bank](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/module.go#L199-L203)
|
||||
- `HasProposalMsgsX`: [x/bank](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/module.go#L194-L197)
|
||||
* `HasWeightedOperationsXWithProposals`: [x/gov](https://github.com/cosmos/cosmos-sdk/blob/main/x/gov/module.go#L242-L261)
|
||||
* `HasWeightedOperationsX`: [x/bank](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/module.go#L199-L203)
|
||||
* `HasProposalMsgsX`: [x/bank](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/module.go#L194-L197)
|
||||
|
||||
## Store decoders
|
||||
|
||||
@ -173,4 +174,4 @@ Example:
|
||||
|
||||
```go reference
|
||||
https://github.com/cosmos/cosmos-sdk/blob/main/simapp/sim_test.go#L53-L65
|
||||
```
|
||||
```
|
||||
|
||||
@ -18,10 +18,11 @@ sidebar_position: 1
|
||||
|
||||
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.
|
||||
* 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:
|
||||
|
||||
```
|
||||
app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())
|
||||
```
|
||||
|
||||
@ -7,4 +7,4 @@ This section is designed for developers who are using the Cosmos SDK to build ap
|
||||
|
||||
* [Setting up keys](./run-node/00-keyring.md) - Learn how to set up secure key management using the Cosmos SDK's keyring feature. This guide provides a streamlined approach to cryptographic key handling, which is crucial for securing your application.
|
||||
* [Running a node](./run-node/01-run-node.md) - This guide provides step-by-step instructions to deploy and manage a node in the Cosmos network. It ensures a smooth and reliable operation of your blockchain application by covering all the necessary setup and maintenance steps.
|
||||
* [CLI](./run-node/02-interact-node.md) - Discover how to navigate and interact with the Cosmos SDK using the Command Line Interface (CLI). This section covers efficient and powerful command-based operations that can help you manage your application effectively.
|
||||
* [CLI](./run-node/02-interact-node.md) - Discover how to navigate and interact with the Cosmos SDK using the Command Line Interface (CLI). This section covers efficient and powerful command-based operations that can help you manage your application effectively.
|
||||
|
||||
@ -1 +1 @@
|
||||
# Errors
This package provides structured error handling for Cosmos SDK apps. It supports:
- Custom error codes and messages
- Stack traces when wrapping errors
- ABCI-compatible responses for Tendermint
- Optional gRPC status codes
## Usage
### Registering Errors
Define root errors with a unique code and description:
```go
var ErrInvalidInput = errors.Register("app", 1001, "invalid input")
```
You can wrap errors to add context:
```go
return errors.Wrap(ErrInvalidInput, "missing field")
```
### Getting ABCI Error Info
To convert an error to ABCI-compatible output:
```go
codespace, code, log := errors.ABCIInfo(err, debug)
```
Set `debug = true` to include stack traces in logs.
### Suppress Duplicate Error Warnings
To prevent logging when the same error is registered twice, set:
```bash
export COSMOS_SDK_SUPPRESS_DUPLICATE_ERROR_CODE_LOG=true
```
Useful in tests or modules that may re-register the same error.
|
||||
# Errors
This package provides structured error handling for Cosmos SDK apps. It supports:
* Custom error codes and messages
* Stack traces when wrapping errors
* ABCI-compatible responses for Tendermint
* Optional gRPC status codes
## Usage
### Registering Errors
Define root errors with a unique code and description:
```go
var ErrInvalidInput = errors.Register("app", 1001, "invalid input")
```
You can wrap errors to add context:
```go
return errors.Wrap(ErrInvalidInput, "missing field")
```
### Getting ABCI Error Info
To convert an error to ABCI-compatible output:
```go
codespace, code, log := errors.ABCIInfo(err, debug)
```
Set `debug = true` to include stack traces in logs.
### Suppress Duplicate Error Warnings
To prevent logging when the same error is registered twice, set:
```bash
export COSMOS_SDK_SUPPRESS_DUPLICATE_ERROR_CODE_LOG=true
```
Useful in tests or modules that may re-register the same error.
|
||||
@ -7,8 +7,8 @@ The core goals the CacheKVStore seeks to solve are:
|
||||
* Buffer all writes to the parent store, so they can be dropped if they need to be reverted
|
||||
* Allow iteration over contiguous spans of keys
|
||||
* Act as a cache, improving access time for reads that have already been done (by replacing tree access with hashtable access, avoiding disk I/O)
|
||||
* Note: We actually fail to achieve this for iteration right now
|
||||
* Note: Need to consider this getting too large and dropping some cached reads
|
||||
* Note: We actually fail to achieve this for iteration right now
|
||||
* Note: Need to consider this getting too large and dropping some cached reads
|
||||
* Make subsequent reads account for prior buffered writes
|
||||
* Write all buffered changes to the parent store
|
||||
|
||||
@ -137,4 +137,4 @@ In the case that the size of `unsortedCache` is larger than `minSortSize`, a lin
|
||||
|
||||
Finally, part 4. is achieved with `memIterator`, which implements an iterator over the items in `sortedCache`.
|
||||
|
||||
As of [PR #12885](https://github.com/cosmos/cosmos-sdk/pull/12885), an optimization to the binary search case mitigates the overhead of sorting the entirety of the key set in `unsortedCache`. To avoid wasting the compute spent sorting, we should ensure that a reasonable amount of values are removed from `unsortedCache`. If the length of the range for iteration is less than `minSortedCache`, we widen the range of values for removal from `unsortedCache` to be up to `minSortedCache` in length. This amortizes the cost of processing elements across multiple calls.
|
||||
As of [PR #12885](https://github.com/cosmos/cosmos-sdk/pull/12885), an optimization to the binary search case mitigates the overhead of sorting the entirety of the key set in `unsortedCache`. To avoid wasting the compute spent sorting, we should ensure that a reasonable amount of values are removed from `unsortedCache`. If the length of the range for iteration is less than `minSortedCache`, we widen the range of values for removal from `unsortedCache` to be up to `minSortedCache` in length. This amortizes the cost of processing elements across multiple calls.
|
||||
|
||||
@ -87,13 +87,13 @@ to determine which heights are to be pruned (959 - 50 - 10 = 899-909 = 959 - 50)
|
||||
## Configuration
|
||||
|
||||
* `state-sync.snapshot-interval`
|
||||
* the interval at which to take snapshots.
|
||||
* the value of 0 disables snapshots.
|
||||
* if pruning is enabled, it is done after a snapshot is complete for the heights that are multiples of this interval.
|
||||
* the interval at which to take snapshots.
|
||||
* the value of 0 disables snapshots.
|
||||
* if pruning is enabled, it is done after a snapshot is complete for the heights that are multiples of this interval.
|
||||
|
||||
* `state-sync.snapshot-keep-recent`:
|
||||
* the number of recent snapshots to keep.
|
||||
* 0 means keep all.
|
||||
* the number of recent snapshots to keep.
|
||||
* 0 means keep all.
|
||||
|
||||
## Snapshot Metadata
|
||||
|
||||
|
||||
@ -6,16 +6,16 @@ setup in tests.
|
||||
|
||||
## Components
|
||||
|
||||
- **CLI**: Command-line interface wrapper for interacting with the chain or keyring
|
||||
- **Servers**: Server instances to run the blockchain environment.
|
||||
- **Events**: Event listeners
|
||||
- **RPC**: Remote Procedure Call setup for communication.
|
||||
* **CLI**: Command-line interface wrapper for interacting with the chain or keyring
|
||||
* **Servers**: Server instances to run the blockchain environment.
|
||||
* **Events**: Event listeners
|
||||
* **RPC**: Remote Procedure Call setup for communication.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- **testify**: Testing toolkit.
|
||||
- **gjson**: JSON parser.
|
||||
- **sjson**: JSON modifier.
|
||||
* **testify**: Testing toolkit.
|
||||
* **gjson**: JSON parser.
|
||||
* **sjson**: JSON modifier.
|
||||
|
||||
Server and client-side operations are executed on the host machine.
|
||||
|
||||
|
||||
@ -7,4 +7,4 @@ To run a fuzz test, use the `-fuzz` flag to `go test`. For example:
|
||||
|
||||
```shell
|
||||
go test -fuzz FuzzCryptoHDNewParamsFromPath ./tests
|
||||
```
|
||||
```
|
||||
|
||||
@ -21,4 +21,4 @@ rate will probably increase over time. This isn't really a problem for tests.
|
||||
|
||||
Obviously this module is built to DOS a node by testing the upper bounds of chain performance;
|
||||
when testing gas limits should be increased. It should not be included in chains by default but
|
||||
is enabled in simapp for testing.
|
||||
is enabled in simapp for testing.
|
||||
|
||||
@ -41,10 +41,10 @@ capabilities of your blockchain or further specialize it.
|
||||
The following modules are deprecated. They will no longer be maintained and eventually will be removed
|
||||
in an upcoming release of the Cosmos SDK per our [release process](https://github.com/cosmos/cosmos-sdk/blob/main/RELEASE_PROCESS.md).
|
||||
|
||||
* [Crisis](./crisis/README.md) - *Deprecated* halting the blockchain under certain circumstances (e.g. if an invariant is broken).
|
||||
* [Params](./params/README.md) - *Deprecated* Globally available parameter store.
|
||||
* [NFT](./nft/README.md) - *Deprecated* NFT module implemented based on [ADR43](https://docs.cosmos.network/main/architecture/adr-043-nft-module.html). This module will be moved to the `cosmos-sdk-legacy` repo for use.
|
||||
* [Group](./group/README.md) - *Deprecated* Allows for the creation and management of on-chain multisig accounts. This module will be moved to the `cosmos-sdk-legacy` repo for legacy use.
|
||||
* [Crisis](./crisis/README.md) - _Deprecated_ halting the blockchain under certain circumstances (e.g. if an invariant is broken).
|
||||
* [Params](./params/README.md) - _Deprecated_ Globally available parameter store.
|
||||
* [NFT](./nft/README.md) - _Deprecated_ NFT module implemented based on [ADR43](https://docs.cosmos.network/main/architecture/adr-043-nft-module.html). This module will be moved to the `cosmos-sdk-legacy` repo for use.
|
||||
* [Group](./group/README.md) - _Deprecated_ Allows for the creation and management of on-chain multisig accounts. This module will be moved to the `cosmos-sdk-legacy` repo for legacy use.
|
||||
|
||||
To learn more about the process of building modules, visit the [building modules reference documentation](https://docs.cosmos.network/main/building-modules/intro).
|
||||
|
||||
|
||||
@ -255,22 +255,27 @@ The `grant` command allows a granter to grant an authorization to a grantee.
|
||||
```bash
|
||||
simd tx authz grant <grantee> <authorization_type="send"|"generic"|"delegate"|"unbond"|"redelegate"> --from <granter> [flags]
|
||||
```
|
||||
- The `send` authorization_type refers to the built-in `SendAuthorization` type. The custom flags available are `spend-limit` (required) and `allow-list` (optional) , documented [here](#SendAuthorization)
|
||||
|
||||
* The `send` authorization_type refers to the built-in `SendAuthorization` type. The custom flags available are `spend-limit` (required) and `allow-list` (optional) , documented [here](#sendauthorization)
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
simd tx authz grant cosmos1.. send --spend-limit=100stake --allow-list=cosmos1...,cosmos2... --from=cosmos1..
|
||||
```
|
||||
- The `generic` authorization_type refers to the built-in `GenericAuthorization` type. The custom flag available is `msg-type` ( required) documented [here](#GenericAuthorization).
|
||||
|
||||
* The `generic` authorization_type refers to the built-in `GenericAuthorization` type. The custom flag available is `msg-type` ( required) documented [here](#genericauthorization).
|
||||
|
||||
> Note: `msg-type` is any valid Cosmos SDK `Msg` type url.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
simd tx authz grant cosmos1.. generic --msg-type=/cosmos.bank.v1beta1.MsgSend --from=cosmos1..
|
||||
```
|
||||
- The `delegate`,`unbond`,`redelegate` authorization_types refer to the built-in `StakeAuthorization` type. The custom flags available are `spend-limit` (optional), `allowed-validators` (optional) and `deny-validators` (optional) documented [here](#StakeAuthorization).
|
||||
|
||||
* The `delegate`,`unbond`,`redelegate` authorization_types refer to the built-in `StakeAuthorization` type. The custom flags available are `spend-limit` (optional), `allowed-validators` (optional) and `deny-validators` (optional) documented [here](#stakeauthorization).
|
||||
|
||||
> Note: `allowed-validators` and `deny-validators` cannot both be empty. `spend-limit` represents the `MaxTokens`
|
||||
|
||||
Example:
|
||||
|
||||
@ -245,11 +245,13 @@ Re-enable previously disabled message types (requires authorization):
|
||||
In case of a critical vulnerability in a specific message type:
|
||||
|
||||
1. Quickly disable the vulnerable message type:
|
||||
|
||||
```bash
|
||||
<appd> tx circuit trip --type-urls="/cosmos.vulnerable.v1beta1.MsgVulnerable" --from=<authorized_key> --gas=auto --gas-adjustment=1.5
|
||||
```
|
||||
|
||||
2. After a fix is deployed, re-enable the message type:
|
||||
|
||||
```bash
|
||||
<appd> tx circuit reset --type-urls="/cosmos.vulnerable.v1beta1.MsgVulnerable" --from=<authorized_key> --gas=auto --gas-adjustment=1.5
|
||||
```
|
||||
|
||||
@ -291,12 +291,12 @@ When using an external community pool with `x/distribution`, the following handl
|
||||
|
||||
**QueryService**
|
||||
|
||||
- `CommunityPool`
|
||||
* `CommunityPool`
|
||||
|
||||
**MsgService**
|
||||
|
||||
- `CommunityPoolSpend`
|
||||
- `FundCommunityPool`
|
||||
* `CommunityPoolSpend`
|
||||
* `FundCommunityPool`
|
||||
|
||||
If you have services that rely on this functionality from `x/distribution`, please update them to use the `x/protocolpool` equivalents.
|
||||
|
||||
|
||||
@ -191,9 +191,9 @@ https://github.com/cosmos/cosmos-sdk/blob/main/x/gov/keeper/tally.go#L15-L24
|
||||
This gives developers a more expressive way to handle governance on their appchains.
|
||||
Developers can now build systems with:
|
||||
|
||||
- Quadratic Voting
|
||||
- Time-weighted Voting
|
||||
- Reputation-Based voting
|
||||
* Quadratic Voting
|
||||
* Time-weighted Voting
|
||||
* Reputation-Based voting
|
||||
|
||||
##### Example
|
||||
|
||||
|
||||
@ -42,4 +42,4 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
|
||||
## [v0.1.0](https://github.com/cosmos/cosmos-sdk/releases/tag/x/nft/v0.1.0) - 2023-11-07
|
||||
|
||||
* Initial release of the standalone NFT module.
|
||||
* Initial release of the standalone NFT module.
|
||||
|
||||
@ -18,12 +18,12 @@ The following `x/distribution` handlers will now return an error when the `proto
|
||||
|
||||
**QueryService**
|
||||
|
||||
- `CommunityPool`
|
||||
* `CommunityPool`
|
||||
|
||||
**MsgService**
|
||||
|
||||
- `CommunityPoolSpend`
|
||||
- `FundCommunityPool`
|
||||
* `CommunityPoolSpend`
|
||||
* `FundCommunityPool`
|
||||
|
||||
If you have services that rely on this functionality from `x/distribution`, please update them to use the `x/protocolpool` equivalents.
|
||||
|
||||
@ -124,9 +124,9 @@ https://github.com/cosmos/cosmos-sdk/blob/release/v0.53.x/proto/cosmos/protocolp
|
||||
|
||||
The message will fail under the following conditions:
|
||||
|
||||
- The recipient address is empty or restricted.
|
||||
- The percentage is zero/negative/greater than one.
|
||||
- The Expiry time is less than the current block time.
|
||||
* The recipient address is empty or restricted.
|
||||
* The percentage is zero/negative/greater than one.
|
||||
* The Expiry time is less than the current block time.
|
||||
|
||||
:::warning
|
||||
If two continuous fund proposals to the same address are created, the previous ContinuousFund will be updated with the new ContinuousFund.
|
||||
@ -146,8 +146,8 @@ https://github.com/cosmos/cosmos-sdk/blob/release/v0.53.x/x/protocolpool/proto/c
|
||||
|
||||
The message will fail under the following conditions:
|
||||
|
||||
- The recipient address is empty or restricted.
|
||||
- The ContinuousFund for the recipient does not exist.
|
||||
* The recipient address is empty or restricted.
|
||||
* The ContinuousFund for the recipient does not exist.
|
||||
|
||||
```go reference
|
||||
https://github.com/cosmos/cosmos-sdk/blob/release/v0.53.x/x/protocolpool/keeper/msg_server.go#L188-L226
|
||||
|
||||
@ -22,9 +22,9 @@ recover from.
|
||||
* [State](#state)
|
||||
* [Events](#events)
|
||||
* [Client](#client)
|
||||
* [CLI](#cli)
|
||||
* [REST](#rest)
|
||||
* [gRPC](#grpc)
|
||||
* [CLI](#cli)
|
||||
* [REST](#rest)
|
||||
* [gRPC](#grpc)
|
||||
* [Resources](#resources)
|
||||
|
||||
## Concepts
|
||||
|
||||
Loading…
Reference in New Issue
Block a user