enhance codebase clarity through systematic terminology corrections (#24975)
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
* 2020/10/28: Intial draft
|
||||
* 2020/10/28: Initial draft
|
||||
|
||||
## Status
|
||||
|
||||
|
||||
@@ -199,7 +199,7 @@ func NewKeeper(logger log.Logger) Keeper {
|
||||
|
||||
Modules will provide their core services to the runtime module via extension interfaces built on top of the
|
||||
`cosmossdk.io/core/appmodule.AppModule` tag interface. This tag interface requires only two empty methods which
|
||||
allow `depinject` to identify implementors as `depinject.OnePerModule` types and as app module implementations:
|
||||
allow `depinject` to identify implementers as `depinject.OnePerModule` types and as app module implementations:
|
||||
|
||||
```go
|
||||
type AppModule interface {
|
||||
|
||||
+1
-1
@@ -53,7 +53,7 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
|
||||
* `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
|
||||
* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
|
||||
* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
|
||||
* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
|
||||
* `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
|
||||
* `ABANDONED`: the ADR is no longer pursued by the original authors.
|
||||
|
||||
## Language used in RFC
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## Background
|
||||
|
||||
Transation Validation is crucial to a functioning state machine. Within the Cosmos SDK there are two validation flows, one is outside the message server and the other within. The flow outside of the message server is the `ValidateBasic` function. It is called in the antehandler on both `CheckTx` and `DeliverTx`. There is an overhead and sometimes duplication of validation within these two flows. This extra validation provides an additional check before entering the mempool.
|
||||
Transaction Validation is crucial to a functioning state machine. Within the Cosmos SDK there are two validation flows, one is outside the message server and the other within. The flow outside of the message server is the `ValidateBasic` function. It is called in the antehandler on both `CheckTx` and `DeliverTx`. There is an overhead and sometimes duplication of validation within these two flows. This extra validation provides an additional check before entering the mempool.
|
||||
|
||||
With the deprecation of [`GetSigners`](https://github.com/cosmos/cosmos-sdk/issues/11275) we have the optionality to remove [sdk.Msg](https://github.com/cosmos/cosmos-sdk/blob/16a5404f8e00ddcf8857c8a55dca2f7c109c29bc/types/tx_msg.go#L16) and the `ValidateBasic` function.
|
||||
|
||||
@@ -16,7 +16,7 @@ With the separation of CometBFT and Cosmos-SDK, there is a lack of control of wh
|
||||
|
||||
The acceptance of this RFC would move validation within `ValidateBasic` to the message server in modules, update tutorials and docs to remove mention of using `ValidateBasic` in favour of handling all validation for a message where it is executed.
|
||||
|
||||
We can and will still support the `Validatebasic` function for users and provide an extension interface of the function once `sdk.Msg` is depreacted.
|
||||
We can and will still support the `Validatebasic` function for users and provide an extension interface of the function once `sdk.Msg` is deprecated.
|
||||
|
||||
> Note: This is how messages are handled in VMs like Ethereum and CosmWasm.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@
|
||||
> path and fall into the same pitfalls that we've since matured from. Abandoned ideas are a way to recognize that path
|
||||
> and explain the pitfalls and why they were abandoned.
|
||||
|
||||
## Descision
|
||||
## Decision
|
||||
|
||||
> This section describes alternative designs to the chosen design. This section
|
||||
> is important and if an adr does not have any alternatives then it should be
|
||||
|
||||
Reference in New Issue
Block a user