chore!: remove bank & genutil legacy migrations (#17818)
This commit is contained in:
Marko
@@ -17,7 +17,7 @@ evidence can be submitted, evaluated and verified resulting in some agreed upon
|
||||
penalty for any misbehavior committed by a validator, such as equivocation (double-voting),
|
||||
signing when unbonded, signing an incorrect state transition (in the future), etc.
|
||||
Furthermore, such a mechanism is paramount for any
|
||||
[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md) or
|
||||
[IBC](https://github.com/cosmos/ibc) or
|
||||
cross-chain validation protocol implementation in order to support the ability
|
||||
for any misbehavior to be relayed back from a collateralized chain to a primary
|
||||
chain so that the equivocating validator(s) can be slashed.
|
||||
@@ -178,5 +178,5 @@ type GenesisState struct {
|
||||
## References
|
||||
|
||||
* [ICS](https://github.com/cosmos/ics)
|
||||
* [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md)
|
||||
* [IBC Architecture](https://github.com/cosmos/ibc/blob/main/spec/ics-001-ics-standard/README.md)
|
||||
* [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md)
|
||||
|
||||
@@ -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
|
||||
@@ -446,7 +447,8 @@ languages, possibly executed within a WASM VM.
|
||||
### Minor API Revisions
|
||||
|
||||
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)):
|
||||
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`)
|
||||
|
||||
@@ -56,7 +56,7 @@ Tests which exercise a whole module's function with dependencies mocked, are *jo
|
||||
These are almost like integration tests in that they exercise many things together but still
|
||||
use mocks.
|
||||
|
||||
Example 1 journey vs illustrative tests - [depinject's BDD style tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/features/bindings.feature), show how we can
|
||||
Example 1 journey vs illustrative tests - depinject's BDD style tests, show how we can
|
||||
rapidly build up many illustrative cases demonstrating behavioral rules without [very much code](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/binding_test.go) while maintaining high level readability.
|
||||
|
||||
Example 2 [depinject table driven tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/provider_desc_test.go)
|
||||
|
||||
+2
-2
@@ -74,8 +74,8 @@ As a result of this architecture, building a Cosmos SDK application usually revo
|
||||
|
||||
While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them:
|
||||
|
||||
* **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./06-keeper.md).
|
||||
* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../learn/advanced/10-ocap.md) of the Cosmos SDK.
|
||||
* **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-cosmos-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./06-keeper.md).
|
||||
* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../develop/advanced/10-ocap.md) of the Cosmos SDK.
|
||||
* **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some modules to be malicious. That is why module developers need to carefully think not only about how their module interacts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](./06-keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`.
|
||||
|
||||
## Main Components of Cosmos SDK Modules
|
||||
|
||||
+2
-1
@@ -43,7 +43,7 @@ In general, the getter function does the following:
|
||||
* If applicable, the command's arguments are parsed. In this example, the arguments `[to_address]` and `[amount]` are both parsed.
|
||||
* A [message](./02-messages-and-queries.md) is created using the parsed arguments and information from the `clientCtx`. The constructor function of the message type is called directly. In this case, `types.NewMsgSend(fromAddr, toAddr, amount)`. Its good practice to call, if possible, the necessary [message validation methods](../building-modules/03-msg-services.md#Validation) before broadcasting the message.
|
||||
* Depending on what the user wants, the transaction is either generated offline or signed and broadcasted to the preconfigured node using `tx.GenerateOrBroadcastTxCLI(clientCtx, flags, msg)`.
|
||||
* **Adds transaction flags:** All transaction commands must add a set of transaction [flags](#flags). The transaction flags are used to collect additional information from the user (e.g. the amount of fees the user is willing to pay). The transaction flags are added to the constructed command using `AddTxFlagsToCmd(cmd)`.
|
||||
* **Adds transaction flags:** All transaction commands must add a set of transaction flags. The transaction flags are used to collect additional information from the user (e.g. the amount of fees the user is willing to pay). The transaction flags are added to the constructed command using `AddTxFlagsToCmd(cmd)`.
|
||||
* **Returns the command:** Finally, the transaction command is returned.
|
||||
|
||||
Each module can implement `NewTxCmd()`, which aggregates all of the transaction commands of the module. Here is an example from the `x/bank` module:
|
||||
@@ -159,6 +159,7 @@ Modules that want to expose REST queries should add `google.api.http` annotation
|
||||
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89
|
||||
```
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml).
|
||||
|
||||
The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered.
|
||||
|
||||
+2
-8
@@ -37,7 +37,7 @@ for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled)
|
||||
to their corresponding types. In particular, it matches the key to a concrete type
|
||||
and then unmarshals the value from the `KVPair` to the type provided.
|
||||
|
||||
You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.
|
||||
You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/main/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.
|
||||
|
||||
### Randomized genesis
|
||||
|
||||
@@ -48,13 +48,7 @@ Once the module genesis parameter are generated randomly (or with the key and
|
||||
values defined in a `params` file), they are marshaled to JSON format and added
|
||||
to the app genesis JSON to use it on the simulations.
|
||||
|
||||
You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/staking/simulation/genesis.go).
|
||||
|
||||
### Randomized parameter changes
|
||||
|
||||
The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan.
|
||||
|
||||
You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/staking/simulation/params.go)
|
||||
You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/main/x/staking/simulation/genesis.go).
|
||||
|
||||
### Random weighted operations
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ must equal the constant `"message"`. The `@type` field corresponds to the type o
|
||||
structure the user will be signing in an application. For now, a user is only
|
||||
allowed to sign bytes of valid ASCII text ([see here](https://github.com/cometbft/cometbft/blob/v0.37.0/libs/strings/string.go#L35-L64)).
|
||||
However, this will change and evolve to support additional application-specific
|
||||
structures that are human-readable and machine-verifiable ([see Future Adaptations](#futureadaptations)).
|
||||
structures that are human-readable and machine-verifiable.
|
||||
|
||||
Thus, we can have a canonical JSON structure for signing Cosmos messages using
|
||||
the [JSON schema](http://json-schema.org/) specification as such:
|
||||
|
||||
@@ -277,9 +277,9 @@ func CacheWrap(
|
||||
```
|
||||
|
||||
### Implementation details
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
The inter-block cache implementation uses a fixed-sized adaptive replacement cache (ARC) as cache. [The ARC implementation](https://github.com/hashicorp/golang-lru/blob/master/arc.go) is thread-safe. ARC is an enhancement over the standard LRU cache in that tracks both frequency and recency of use. This avoids a burst in access to new entries from evicting the frequently used older entries. It adds some additional tracking overhead to a standard LRU cache, computationally it is roughly `2x` the cost, and the extra memory overhead is linear with the size of the cache. The default cache size is `1000`.
|
||||
|
||||
<!-- markdown-link-check-enable -->
|
||||
## History
|
||||
|
||||
Dec 20, 2022 - Initial draft finished and submitted as a PR
|
||||
|
||||
Reference in New Issue
Block a user