-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add baseapp concept doc #4691
Add baseapp concept doc #4691
Conversation
Co-Authored-By: Alessio Treglia <quadrispro@ubuntu.com>
Co-Authored-By: Alexander Bezobchuk <alexanderbez@users.noreply.github.com> Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> Co-Authored-By: Alessio Treglia <quadrispro@ubuntu.com> Co-Authored-By: frog power 4000 <rigel.rozanski@gmail.com>
Co-Authored-By: Karoly Albert Szabo <szabo.karoly.a@gmail.com> Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## master #4691 +/- ##
==========================================
+ Coverage 54.01% 54.02% +0.01%
==========================================
Files 271 271
Lines 17261 17261
==========================================
+ Hits 9324 9326 +2
+ Misses 7257 7255 -2
Partials 680 680 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few spelling and grammar fixes. Also I recommend removing the ABCI messages section in favor of the same content being covered elsewhere.
docs/core/baseapp.md
Outdated
|
||
## Introduction | ||
|
||
`baseapp` is an abstraction that implements the core of an SDK application, namely: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"abstraction" is pretty vauge. Maybe call baseapp the "base class that implements the core of an SDK application, "
} | ||
``` | ||
|
||
Extending the application with `baseapp` gives the former access to all of `baseapp`'s methods. This allows developers to compose their custom application with the modules they want, while not having to concern themselves with the hard work of implementing the ABCI, the routing and state management logic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"This allows developers to compose their custom application with the modules they want, while not having to concern themselves with the hard work of implementing ABCI, routing and state management logic." ----> took out two unneeded "the"s
docs/core/baseapp.md
Outdated
- A [query router](#query-routing). The `query router` facilitates the routing of [queries](./querier.md) to the appropriate module for it to be processed. | ||
- A [`txDecoder`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#TxDecoder), used to decode transaction `[]byte` relayed by the underlying Tendermint engine. | ||
- A [`baseKey`], to access the [main store](./store.md#main-store) in the `CommitMultiStore`. The main store is used to persist data related to the core of the application, like consensus parameters. | ||
- A [`anteHandler`](#antehandler), to handle signature verification and fee paiement when a transaction is received. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spelling "payment"
## RunTx, AnteHandler and RunMsgs | ||
|
||
### RunTx | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm this section is confusing because it collapses together a number of different subject. Also it makes it look like RunTx
is another ABCI message? Its not right? Is it a method on baseapp? The way this is written it seems like RunTx is another ABCI message called by CheckTx... but ABCI messages dont call each other....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be more clear with a proper rendering of the page. If you look at the sectioning, you'll see that ## Run Tx, AnteHandler and RunMsgs
is not under Main ABCI Messages
. These method are called from methods that implement the ABCI though, and we need to explain what they do.
docs/core/baseapp.md
Outdated
|
||
After that, `RunTx` calls `ValidateBasic()` on each `message`in the `Tx`, which runs prelimary *stateless* validity checks. If any `message` fails to pass `ValidateBasic()`, `RunTx` returns with an error. | ||
|
||
Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are cached-wrapped using the [`cacheTxContext()`](https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/baseapp.go#L781-L798) function. This allows `RunTx` not to commit the changes made to the state during the execution of `anteHandler` if it ends up failing. It also prevents the module implementing the `anteHandler` from writing to state, which is an important part of the [object-capabilities](./ocap.md) of the Cosmos SDK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all seems perhaps better suited to the Tx Lifecycle doc? This is starting to stray from baseapp
the base class, to more complex contextual info that might better fit somewhere else, with a link to it from here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only touch on what is implemented at baseapp
level here.
Thetx-lifecycle
doc is NOT a good place to detail this process, as it is an overview doc. The tx-lifecycle
doc links to this doc for people that want more detail, not the other way around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add parenthesis like so RunTx()
to demonstrate that its a method?
docs/core/baseapp.md
Outdated
- Perform preliminary *stateful* validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees. | ||
- Play a role in the incentivisation of stakeholders via the collection of transaction fees. | ||
|
||
`baseapp` holds an `anteHandler` as paraemter, which is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` today is that of the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/master/x/auth/ante.go). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spelling for "parameter"
docs/core/baseapp.md
Outdated
|
||
### RunMsgs | ||
|
||
`RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `message`s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
....."as a parameter to check the existence of a route for each message contained in the transaction, and with runTxModeDeliver
to actually process the message
s.
|
||
First, it retreives the `message`'s `route` using the `Msg.Route()` method. Then, using the application's [`router`](#routing) and the `route`, it checks for the existence of a `handler`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. If instead `mode == runTxModeDeliver`, the [`handler`](../building-modules.md#handler) function for the message is executed, before `RunMsgs` returns. | ||
|
||
## Other ABCI Messages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this feels like the wrong place to be documenting ABCI messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ABCI messages in the context of the SDK are implemented as baseapp
's methods, so it's the perfect place to document them...
Please remember that ABCI spec just specifies the interface and return format, it does not specify the actual logic implemented by the application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha. Yeah I got this wrong. I do think adding '()' might help clarify things, for CheckTx()
and the other baseapp methods that handle the ABCI messages from tendermint to distinguish them from the tendermint docs.
| CheckState(t+1)(0) | | DeliverState(t+1)(0) | | QueryState(t+1) | | ||
+----------------------+ | | | | | ||
. . . | ||
. . . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This graphic is hard to grasp.... Maybe more explanation of what each column represents? like the left most column could be labeled "Incoming ABCI Msgs"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
docs/core/baseapp.md
Outdated
- A [Router](#routing), to route [messages](./tx-msgs.md) and [queries](./querier.md) to the appropriate [module](../building-modules/modules.md). | ||
- Different [states](#states), as the state-machine can have different parallel states updated based on the ABCI message received. | ||
|
||
The goal of `baseapp` is to provide a boilerplate SDK application that developers can easily extend to build their own custom application. Usually, developers will create a custom type for their application, like so: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the goal of baseapp
to connect all the modules that make up an application and provide common utilities to them? I don't think it is to "provide boilerplate" IMO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed formulation
docs/core/baseapp.md
Outdated
- [Router](#message-routing): The `router` facilitates the routing of [`messages`](./tx-msgs.md) to the appropriate module for it to be processed. Here `message` refers to the transaction components that need to be processed by the application in order to update the state, and not to ABCI messages which implement the interface between the application and the underlying consensus engine. | ||
- [Query Router](#query-routing): The `query router` facilitates the routing of [queries](./querier.md) to the appropriate module for it to be processed. These `queries` are not ABCI messages themselves, but they are relayed to the application from the underlying consensus engine via the ABCI message [`Query`](#query). | ||
- [`TxDecoder`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#TxDecoder): It is used to decode transaction `[]byte` relayed by the underlying Tendermint engine. | ||
- [`DaseKey`]: This key is used to access the [main store](./store.md#main-store) in the `CommitMultiStore`. The main store is used to persist data related to the core of the application, like consensus parameters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've never seen this term before. Is this right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope, should be basekey
docs/core/baseapp.md
Outdated
- `checkState`: This state is updated during [`CheckTx`](#checktx), and reset on [`Commit`](#commit). | ||
- `deliverState`: This state is updated during [`DeliverTx`](#delivertx), and reset on [`Commit`](#commit). | ||
|
||
Finally, a few more important parameterd: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, a few more important parameterd: | |
Finally, a few more important parameters: |
Title
File to review:
core/baseapp.md
Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
Wrote tests
Updated relevant documentation (
docs/
)Added a relevant changelog entry:
clog add [section] [stanza] [message]
rereviewed
Files changed
in the github PR explorerFor Admin Use: