fatxpool: Master issue for upcoming work
#5472
Assignees
Labels
T0-node
This PR/Issue is related to the topic “node”.
Comments
michalkucharczyk
changed the title
fatxpool: Master issue for upcoming workfatxpool: Master ☔ issue for upcoming work
michalkucharczyk
changed the title
fatxpool: Master ☔ issue for upcoming workfatxpool: Master issue for upcoming work
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 15, 2024
### Fork-Aware Transaction Pool Implementation This PR introduces a fork-aware transaction pool (fatxpool) enhancing transaction management by maintaining the valid state of txpool for different forks. ### High-level overview The high level overview was added to [`sc_transaction_pool::fork_aware_txpool`](https://github.com/paritytech/polkadot-sdk/blob/3ad0a1b7c08e63a2581595cb2cd55f11ccd60f4f/substrate/client/transaction-pool/src/fork_aware_txpool/mod.rs#L21) module. Use: ``` cargo doc --document-private-items -p sc-transaction-pool --open ``` to build the doc. It should give a good overview and nice entry point into the new pool's mechanics. <details> <summary>Quick overview (documentation excerpt)</summary> #### View For every fork, a view is created. The view is a persisted state of the transaction pool computed and updated at the tip of the fork. The view is built around the existing `ValidatedPool` structure. A view is created on every new best block notification. To create a view, one of the existing views is chosen and cloned. When the chain progresses, the view is kept in the cache (`retracted_views`) to allow building blocks upon intermediary blocks in the fork. The views are deleted on finalization: views lower than the finalized block are removed. The views are updated with the transactions from the mempool—all transactions are sent to the newly created views. A maintain process is also executed for the newly created views—basically resubmitting and pruning transactions from the appropriate tree route. ##### View store View store is the helper structure that acts as a container for all the views. It provides some convenient methods. ##### Submitting transactions Every transaction is submitted to every view at the tips of the forks. Retracted views are not updated. Every transaction also goes into the mempool. ##### Internal mempool Shortly, the main purpose of an internal mempool is to prevent a transaction from being lost. That could happen when a transaction is invalid on one fork and could be valid on another. It also allows the txpool to accept transactions when no blocks have been reported yet. The mempool removes its transactions when they get finalized. Transactions are also periodically verified on every finalized event and removed from the mempool if no longer valid. #### Events Transaction events from multiple views are merged and filtered to avoid duplicated events. `Ready` / `Future` / `Inblock` events are originated in the Views and are de-duplicated and forwarded to external listeners. `Finalized` events are originated in fork-aware-txpool logic. `Invalid` events requires special care and can be originated in both view and fork-aware-txpool logic. #### Light maintain Sometime transaction pool does not have enough time to prepare fully maintained view with all retracted transactions being revalidated. To avoid providing empty ready transaction set to block builder (what would result in empty block) the light maintain was implemented. It simply removes the imported transactions from ready iterator. #### Revalidation Revalidation is performed for every view. The revalidation process is started after a trigger is executed. The revalidation work is terminated just after a new best block / finalized event is notified to the transaction pool. The revalidation result is applied to the newly created view which is built upon the revalidated view. Additionally, parts of the mempool are also revalidated to make sure that no transactions are stuck in the mempool. #### Logs The most important log allowing to understand the state of the txpool is: ``` maintain: txs:(0, 92) views:[2;[(327, 76, 0), (326, 68, 0)]] event:Finalized { hash: 0x8...f, tree_route: [] } took:3.463522ms ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ unwatched txs in mempool ────┘ │ │ │ │ │ │ │ │ │ │ watched txs in mempool ───────┘ │ │ │ │ │ │ │ │ │ views ───────────────┘ │ │ │ │ │ │ │ │ 1st view block # ──────────┘ │ │ │ │ │ │ │ number of ready tx ───────┘ │ │ │ │ │ │ numer of future tx ─────┘ │ │ │ │ │ 2nd view block # ──────┘ │ │ │ │ number of ready tx ──────────┘ │ │ │ number of future tx ───────┘ │ │ event ────────┘ │ duration ──────────────────────────────────────────────────┘ ``` It is logged after the maintenance is done. The `debug` level enables per-transaction logging, allowing to keep track of all transaction-related actions that happened in txpool. </details> ### Integration notes For teams having a custom node, the new txpool needs to be instantiated, typically in `service.rs` file, here is an example: https://github.com/paritytech/polkadot-sdk/blob/9c547ff3e36cf3b52c99f4ed7849a8e9f722d97d/cumulus/polkadot-omni-node/lib/src/common/spec.rs#L152-L161 To enable new transaction pool the following cli arg shall be specified: `--pool-type=fork-aware`. If it works, there shall be information printed in the log: ``` 2024-09-20 21:28:17.528 INFO main txpool: [Parachain] creating ForkAware txpool. ```` For debugging the following debugs shall be enabled: ``` "-lbasic-authorship=debug", "-ltxpool=debug", ``` *note:* trace for txpool enables per-transaction logging. ### Future work The current implementation seems to be stable, however further improvements are required. Here is the umbrella issue for future work: - #5472 Partially fixes: #1202 --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>
|
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/the-fork-aware-transaction-pool/10468/1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following issues are planned for fork-aware transaction pool (follow-up of #4639).
Tasks
fatxpool: improve documentation #5473fatxpool: add heavy load testsuits #5497fatxpool: size limits shall be obeyed #5476fatxpool: implementLocalTransactionPool#5493fatxpool: add retracted event #5479fatxpool: cross check (and improve) support for mortal transactions #5626fatxpool: cross check (and improve) support for priority transactions #5809fatxpool: cross check (and improve) warp-sync scenarios #5483fatxpool: check (and improve) behaviour for finality stalls #5482networking::TransactionPoolshould acceptArc. #5978fatxpool: transaction reported as invalid during block building shall be removed from the pool #6008fatxpool: check old/new pool network interactions #6070Known bugs
fatxpool: improve handling of limits insubmit_and_watch. #5494fatxpool: peer is sometimes not reconnecting after multiplecloggedissue #5487fatxpool: networking::transaction subsystemcloggedissue with many transactions #5486Improvements
fatxpool: add LRUCache for views. #5474fatxpool: API considerations #5491fatxpool: improve event listeners #5495fatxpool: improve handle finalization #5492fatxpool: usetracinginstead oflog#5490fatxpool: usedyninstead ofTransactionPoolWrapper#5489fatxpool: view revalidation shall revalidate futures transactions #5496fatxpool: usefatxpoolin tests of other components #5485fatxpool:ready_at_lightoptimization #6056Add missing unit tests
fatxpool: add tests for light maintain #5475fatxpool: add tests for limits #5478fatxpool: add tests for rejecting invalid transactions #5477fatxpool: add tests for view revalidation #5480fatxpool: add tests for mempool revalidation #5481fatxpool: add test forready_at_with_timeout#5488fatxpool: prepare zombienet scenarios for CI #5484And the following improvements are required in transaction test tool:
ttxttaskssubmitrpc call michalkucharczyk/tx-test-tool#10The text was updated successfully, but these errors were encountered: