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

docs: appside mempool #13875

Merged
merged 4 commits into from
Nov 25, 2022
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/docs/building-apps/00-app-go.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,10 @@ sidebar_position: 1

:::note Synopsis

Since `v0.47.0`, the Cosmos SDK allows much easier wiring an `app.go` with App Wiring and the tool [`depinject`](../tooling/02-depinject.md).
The Cosmos SDK allows much easier wiring an `app.go` with App Wiring and the tool [`depinject`](../tooling/02-depinject.md).
Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md).

Depinject, a tool used by this version of app.go is not stable and may still land breaking changes.
:::

:::note
Expand Down
2 changes: 1 addition & 1 deletion docs/docs/building-apps/01-app-legacy-go.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ sidebar_position: 1

# Overview of `app_legacy.go`

This section is intended to provide an overview of the `SimApp` `app_legacy.go` (or `app.go` pre-`v0.47.0`) file and is still a work in progress.
This section is intended to provide an overview of the `SimApp` `app_legacy.go` (or `app.go`) file and is still a work in progress.
For now please instead read the [tutorials](https://tutorials.cosmos.network) for a deep dive on how to build a chain.

## Complete `app_legacy.go`
Expand Down
51 changes: 51 additions & 0 deletions docs/docs/building-apps/02-app-mempool.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
sidebar_position: 1
---

# Application mempool

:::note Synopsis
This sections describes how the app side mempool can be used and replaced.
:::


Since `0.47` the application has its own mempool to allow much more granular block building than previous versions. This change was enabled by [ABCI 1.0](https://github.com/tendermint/tendermint/blob/main/spec/abci/README.md). Notably it introduces the prepare and process proposal steps of ABCI.

## Prepare Proposal

Prepare proposal handles construction of the block, meaning that when a proposer is preparing to propose a block it asks the application if the txs it collected from the mempool are the right ones, at which point the application will check its own mempool for txs that it would like to include. Now, reading mempool twice in the previous sentence is confusing, lets break it down. Tendermint has a mempool that handles bradcasting transactions to other nodes in the network, but it does not handle ordering of these transactions. The ordering happens at the application level in its own mempool. Allowing the application to handle ordering enables the application to define how it would like the block constructed.

Currently, there is a default `PrepareProposal` implementation provided by the application.

```go reference
https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/baseapp.go#L866-L904
```

This default implementation can be overridden by the application developer in favor of a custom implementation:

```go reference
https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app.go#L197-L199
```


## Process Proposal

Process proposal handles the validation of what is in a block, meaning that after a block has been proposed the other validators have the right to vote no or yes on a block. The validator in the default implementation of `PrepareProposal` runs the transaction in a non execution fashion, it runs the antehandler and gas operations to make sure the transaction is valid.

Here is the implementation of the default implementation:

```go reference
https://github.com/cosmos/cosmos-sdk/blob/bcff22a3767b9c5dd7d1d562aece90cf72e05e85/baseapp/baseapp.go#L906-L930
```

Like `PrepareProposal` this implementation is the default and can be modified by the application developer.

```go reference
https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app.go#L200-L203
```

## Mempool

Now that we have walked through the `PrepareProposal` & `ProcessProposal`, we can move on to walking through the mempool.

There are countless designs that an application developer can write for a mempool, the core team opted to provide a simple implementation of a nonce mempool. The nonce mempool is a mempool that keeps transactions sorted by nonce.
tac0turtle marked this conversation as resolved.
Show resolved Hide resolved
17 changes: 17 additions & 0 deletions simapp/app_legacy.go
Original file line number Diff line number Diff line change
Expand Up @@ -222,6 +222,23 @@ func NewSimApp(
) *SimApp {
encodingConfig := makeEncodingConfig()

// var (
// Below we could construct and set an application specific mempool and ABCI 1.0 Prepare and Process Proposal
// handlers. These defaults are already set in the SDK's BaseApp, this shows an example of how to override
// them.
//
//nonceMempool = mempool.NewNonceMempool()
//mempoolOpt = baseapp.SetMempool(nonceMempool)
//prepareOpt = func(app *baseapp.BaseApp) {
// app.SetPrepareProposal(app.DefaultPrepareProposal())
//}
//processOpt = func(app *baseapp.BaseApp) {
// app.SetProcessProposal(app.DefaultProcessProposal())
//}
//
// )
//baseAppOptions = append(baseAppOptions, mempoolOpt, prepareOpt, processOpt)

appCodec := encodingConfig.Codec
legacyAmino := encodingConfig.Amino
interfaceRegistry := encodingConfig.InterfaceRegistry
Expand Down