Skip to content
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

Merged
merged 137 commits into from
Jul 18, 2019
Merged

tx-lifecycle concept doc #4497

merged 137 commits into from
Jul 18, 2019

Conversation

glozow
Copy link
Contributor

@glozow glozow commented Jun 6, 2019

  • 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 explorer


For Admin Use:

  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)
  • Reviewers Assigned
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

@glozow
Copy link
Contributor Author

glozow commented Jun 6, 2019

#3108

@codecov
Copy link

codecov bot commented Jun 6, 2019

Codecov Report

Merging #4497 into master will increase coverage by 1.33%.
The diff coverage is 53.53%.

@@            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

@fedekunze
Copy link
Collaborator

shouldn't this be rebased to @gamarin2 branch ? #4426

@alexanderbez
Copy link
Contributor

Thanks @gzhao408!

@fedekunze probably? @gamarin2 what are your thoughts?

Copy link
Contributor

@gamarin2 gamarin2 left a 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


## 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)
Copy link
Contributor

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
Copy link
Contributor

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)

* 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.
Copy link
Contributor

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

Copy link
Contributor

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


## 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.
Copy link
Contributor

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

Copy link
Contributor

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

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).
Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Developer -> Developers

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

He -> They

Copy link
Contributor Author

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

-----------------------
```
#### 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.
Copy link
Contributor

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

Copy link
Contributor

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

`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
Copy link
Contributor

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


#### 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.
Copy link
Contributor

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

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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?

[`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.
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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()

@glozow glozow changed the title create tx-lifecycle.md, skeleton, recycle diagrams tx-lifecycle concept doc Jun 12, 2019
@glozow glozow requested a review from fedekunze as a code owner July 18, 2019 14:51
@jackzampolin jackzampolin merged commit c03f969 into master Jul 18, 2019
@fedekunze
Copy link
Collaborator

Why are there so many files on the diff?

@glozow
Copy link
Contributor Author

glozow commented Jul 18, 2019

Why are there so many files on the diff?

My apologies, I didn't realize Gautier had moved tx-lifecycle.md and deleted the concepts folder to reorganize docs, so in my git-confused-ness I had added it back in the merging. Just made a new PR to undo the changes: #4739

@alexanderbez alexanderbez deleted the gloria/tx-lifecycle-doc branch August 28, 2019 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T:Docs Changes and features related to documentation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.