-
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
tx-lifecycle concept doc #4497
tx-lifecycle concept doc #4497
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4497 +/- ##
==========================================
+ Coverage 52.65% 53.98% +1.33%
==========================================
Files 261 272 +11
Lines 16410 17324 +914
==========================================
+ Hits 8640 9352 +712
- Misses 7124 7290 +166
- Partials 646 682 +36 |
Thanks @gzhao408! @fedekunze probably? @gamarin2 what are your thoughts? |
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.
Thanks @gzhao408. I left comments.
Also please rebase on gamarin/app-anatomy
docs/concepts/tx-lifecycle.md
Outdated
|
||
## Prerequisite Reading | ||
* [High-level overview of the architecture of an SDK application](https://github.com/cosmos/cosmos-sdk/docs/intro/sdk-app-architecture.md) | ||
* Baseapp concept doc (link in future) |
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.
baseapp can't be a prerequisite to this doc, it should be the other way around. See #3065 for an idea of the "order" of concept docs.
* [High-level overview of the architecture of an SDK application](https://github.com/cosmos/cosmos-sdk/docs/intro/sdk-app-architecture.md) | ||
* Baseapp concept doc (link in future) | ||
|
||
## Synopsis |
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.
Need to improve formatting throughout (line break after title)
docs/concepts/tx-lifecycle.md
Outdated
* Baseapp concept doc (link in future) | ||
|
||
## Synopsis | ||
1. **Definition and Creation:** Transactions are comprised of metadata and `Msg`s specified by the developer. An application user creates a transaction when he performs an action that causes state change. |
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.
Synopsis is more like a quick summary of what the doc contains + a table of contents. If you add an explanation sentence after the section title, it should be very short
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.
Like if you do want to have explanation sentences, it should really just be a very high-level overview of the tx workflow. No need to explain the details of what txs are at this point
docs/concepts/tx-lifecycle.md
Outdated
|
||
## Synopsis | ||
1. **Definition and Creation:** Transactions are comprised of metadata and `Msg`s specified by the developer. An application user creates a transaction when he performs an action that causes state change. | ||
2. **Addition to Mempool:** All full nodes that receive transactions validate them first by running stateless and stateful checks on a copy of the internal state. Approved transactions are kept in the node's Mempool pending inclusion in the next block. |
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.
Add anchor for each section title
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.
stateless/stateful/mempool -> any non-obvious word should either be explained or link to another doc that explains it. It's a bit much in the Synopsis, and that's why you don't necessarily want to go into detail on the various steps at this stage
docs/concepts/tx-lifecycle.md
Outdated
4. **State Changes:** Transactions are delivered, creating state changes and expending gas. To commit state changes, internal state is updated and all copies are reset; the new state root is returned as proof. | ||
|
||
## Definition and Creation | ||
**[Transactions](https://github.com/cosmos/cosmos-sdk/blob/97d10210beb55ad4bd6722f7186a80bf7cb140e2/types/tx_msg.go#L36-L43)** are comprised of one or multiple **Messages** (link concept doc) and trigger state changes. The developer defines the specific messages to describe possible actions for the application by implementing the [`Msg`](https://github.com/cosmos/cosmos-sdk/blob/97d10210beb55ad4bd6722f7186a80bf7cb140e2/types/tx_msg.go#L10-L31) interface. He also defines [`Handler`](https://github.com/cosmos/cosmos-sdk/blob/1cfc868d86a152b523443154c8723de832dbec81/types/handler.go#L4)s that execute the actions for each message and return the [`Result`](https://github.com/cosmos/cosmos-sdk/blob/1cfc868d86a152b523443154c8723de832dbec81/types/result.go#L14-L37). An [`AnteHandler`](https://github.com/cosmos/cosmos-sdk/blob/1cfc868d86a152b523443154c8723de832dbec81/types/handler.go#L8) can be defined to execute a message's actions in simulation mode (i.e. without persisting state changes). |
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.
You might want to rebase on branch gamarin/app-anatomy
, where I've started adding concepts docs you can reference
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.
The Developer -> Developers
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.
He -> They
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.
Ended up defaulting to plural "the nodes" and "the developers" and following one transaction tx
docs/concepts/tx-lifecycle.md
Outdated
----------------------- | ||
``` | ||
#### BeginBlock | ||
`BeginBlock` is run first, and mainly transmits important data such as block header and Byzantine Validators from the last round of consensus to be used during the next few steps. No transactions are handled 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.
Link to ./app-anatomy.md#beginblocker-and-endblocker
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.
Also not technically part of tx lifecycle, but can remain
docs/concepts/tx-lifecycle.md
Outdated
`BeginBlock` is run first, and mainly transmits important data such as block header and Byzantine Validators from the last round of consensus to be used during the next few steps. No transactions are handled here. | ||
|
||
#### DeliverTx | ||
The `DeliverTx` ABCI function defined in [`baseapp`](https://github.com/cosmos/cosmos-sdk/blob/8b1d75caa2099800ee9983e4a4528bcd00fec302/baseapp/baseapp.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.
do not link to baseapp
codebase here, but to baseapp
concept doc. Only the concept doc of component X should directly reference code of component X
docs/concepts/tx-lifecycle.md
Outdated
|
||
#### DeliverTx | ||
The `DeliverTx` ABCI function defined in [`baseapp`](https://github.com/cosmos/cosmos-sdk/blob/8b1d75caa2099800ee9983e4a4528bcd00fec302/baseapp/baseapp.go | ||
) does the bulk of the state change work: it is run for each transaction in the block in sequential order as committed to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx` but calls the [`runTx`](https://github.com/cosmos/cosmos-sdk/blob/cec3065a365f03b86bc629ccb6b275ff5846fdeb/baseapp/baseapp.go#L757-L873) function in deliver mode instead of check mode. |
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.
Same, link to ./baseapp.md#runtx
instead of the code directly
docs/concepts/tx-lifecycle.md
Outdated
The `DeliverTx` ABCI function defined in [`baseapp`](https://github.com/cosmos/cosmos-sdk/blob/8b1d75caa2099800ee9983e4a4528bcd00fec302/baseapp/baseapp.go | ||
) does the bulk of the state change work: it is run for each transaction in the block in sequential order as committed to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx` but calls the [`runTx`](https://github.com/cosmos/cosmos-sdk/blob/cec3065a365f03b86bc629ccb6b275ff5846fdeb/baseapp/baseapp.go#L757-L873) function in deliver mode instead of check mode. | ||
|
||
The application utilizes both `AnteHandler` to check and `MsgHandler` to deliver, persisting changes in both `checkTxState` and `deliverTxState`, respectively. This second check happens because nodes may not have seen the same transactions in the same order during the Addition to Mempool stage and a malicious proposer may have included invalid transactions. |
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.
DeliverTx
should be explained more in-depth, as it constitutes the bulk of the tx lifecycle:
- Should outline the routing functionality of baseapp.
- Explain the role of modules
- Explain the lifecycle of the tx inside the module.
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 I should introduce modules earlier, such as include in the short definition section?
docs/concepts/tx-lifecycle.md
Outdated
[`EndBlock`](https://github.com/cosmos/cosmos-sdk/blob/9036430f15c057db0430db6ec7c9072df9e92eb2/baseapp/baseapp.go#L875-L886) is always run at the end and is useful for automatic function calls or changing governance/validator parameters. No transactions are handled here. | ||
|
||
#### Commit | ||
The application's `Commit` method is run in order to finalize the state changes made by executing this block's transactions. A new state root should be sent back to serve as a merkle proof for the state change. Any application can inherit Baseapp's [`Commit`](https://github.com/cosmos/cosmos-sdk/blob/cec3065a365f03b86bc629ccb6b275ff5846fdeb/baseapp/baseapp.go#L888-L912) method; it synchronizes all the states by writing the `deliverTxState` into the application's internal state, updating both `checkTxState` and `deliverTxState` afterward. |
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 bit confusing: sometimes it seems like we're following the lifecycle of a specific tx, and sometimes it feels like it's more of an abstract description of the lifecycle of txS. Need to choose one or the 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.
All the internal states (LIST), always good to list stuff again. Reiteration is how people learn
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.
Re-explain why it's important that every internal state is reset after Commit()
client/input.GetConfirmation() returns true if and only if the user's input is confirmative. The function is used in places where fat-fingering may cause financial loss, e.g. gaiacli tx send command. Thus it seems wiser to provide a conservative default in order to protect users from accidental mistyping. Closes: #4564
Why are there so many files on the diff? |
My apologies, I didn't realize Gautier had moved |
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: