diff --git a/cometbft/next/docs/experimental/krakatoa-mempool.mdx b/cometbft/next/docs/experimental/krakatoa-mempool.mdx deleted file mode 100644 index 55b2eb8e..00000000 --- a/cometbft/next/docs/experimental/krakatoa-mempool.mdx +++ /dev/null @@ -1,299 +0,0 @@ ---- -order: 2 -title: "Krakatoa: Application-Side Mempool" -description: "Allowing application-side mempool management" -icon: "flame" ---- - -> Experimental: The Krakatoa mempool is an upcoming feature and is subject to change. - -# Krakatoa: Application-Side Mempool - -The Krakatoa mempool is a new CometBFT mempool type (`app`) that delegates -transaction storage, validation, and rechecking entirely to the application. -CometBFT acts as a thin proxy — receiving transactions from RPC and P2P, -forwarding them to the application via ABCI, and broadcasting application-reaped -transactions to peers. - -This design replaces the traditional `flood` mempool model where CometBFT -stores transactions in-process and drives rechecking via repeated `CheckTx` -calls. - -## Motivation - -The traditional mempool architecture has several limitations: - -**ABCI lock contention**: In the `flood` mempool, `CheckTx` calls hold the ABCI -connection lock. This lock is shared with consensus-critical operations like -`PrepareProposal` and `FinalizeBlock`. Since `CheckTx` volume is directly -proportional to network load and fully driven by external actors submitting -transactions, this means an externally influenced workload can hold up block -building and finalization. During rechecking after a committed block, the -problem compounds — all incoming transactions and consensus operations must -wait for the full recheck pass to complete. - -**Limited application control**: The application has no control over when -rechecking occurs, how transactions are prioritized during recheck, or how the -mempool interacts with block building. CometBFT drives the entire lifecycle. - -**Redundant state management**: CometBFT maintains its own transaction storage -(the concurrent linked list) even though the application often needs its own -mempool for ordering and prioritization. This leads to duplicated state and -synchronization overhead. - -The `app` mempool eliminates these issues by making the application the single -source of truth for mempool state. CometBFT no longer holds the ABCI lock for -mempool operations — `InsertTx` and `ReapTxs` are called concurrently and the -application is responsible for its own synchronization. - -## Quick Start - -To enable the Krakatoa `app` mempool, set the mempool type in your CometBFT `config.toml`: - -```toml -[mempool] -type = "app" -``` - -This switches CometBFT from the default `flood` mempool to the application-delegated model. CometBFT will forward transactions to your application via `InsertTx` and pull validated transactions back via `ReapTxs`, rather than managing mempool state itself. - -Your application must implement the `InsertTx` and `ReapTxs` ABCI handlers. - -## New ABCI Methods - -Two new methods are added to the ABCI `Application` interface as part of the -mempool connection: - -### InsertTx - -```protobuf -service ABCIApplication { - rpc InsertTx(RequestInsertTx) returns (ResponseInsertTx); -} - -message RequestInsertTx { - bytes tx = 1; -} - -message ResponseInsertTx { - uint32 code = 1; -} -``` - -`InsertTx` is called when CometBFT receives a transaction, either from an RPC -client (`BroadcastTxSync`, `BroadcastTxAsync`) or from a peer via P2P gossip. -The application is expected to validate and store the transaction in its own -mempool. - -**Response codes**: - -| Code | Meaning | CometBFT Behavior | -|------|---------|-------------------| -| `0` (OK) | Transaction accepted | Transaction is marked as seen and will not be re-inserted | -| `1` - `31,999` | Transaction rejected | Transaction is marked as seen and will not be retried | -| `>= 32,000` (Retry) | Temporary rejection | Transaction is removed from the seen cache so it can be retried later | - -The retry mechanism is useful when the application's mempool is temporarily at -capacity. By returning a retry code, the application signals that the -transaction is not inherently invalid — it simply cannot be accepted right now. -When the transaction is received again (from a peer or resubmitted via RPC), it -will be forwarded to the application again. - -**Concurrency guarantee**: `InsertTx` calls are thread-safe from CometBFT's -perspective. Multiple goroutines may call `InsertTx` concurrently (e.g., -transactions arriving from different peers simultaneously). The application is -responsible for its own internal synchronization. - -**No ABCI lock**: Unlike `CheckTx` in the `flood` mempool, `InsertTx` does not -hold the ABCI connection lock. This means `InsertTx` calls do not block -consensus operations, and consensus operations do not block `InsertTx`. - -### ReapTxs - -```protobuf -service ABCIApplication { - rpc ReapTxs(RequestReapTxs) returns (ResponseReapTxs); -} - -message RequestReapTxs { - uint64 max_bytes = 1; - uint64 max_gas = 2; -} - -message ResponseReapTxs { - repeated bytes txs = 1; -} -``` - -`ReapTxs` is called periodically by the `AppReactor` to retrieve new, validated -transactions from the application for peer-to-peer broadcast. The application -should return transactions that are ready for gossip — typically transactions -that have been validated and are eligible for block inclusion. - -When `max_bytes` and `max_gas` are both zero, the application should return all -available transactions without limits. - -**Important**: `ReapTxs` is used for broadcasting, not for block building. -Block building is handled through `PrepareProposal`, where the application -constructs the block directly from its own mempool state. - -## AppMempool - -The `AppMempool` is the CometBFT-side implementation that fulfills the -`Mempool` interface while delegating all real work to the application. - -### What AppMempool does - -- Proxies incoming transactions to the application via `InsertTx` -- Maintains a seen cache (LRU, 100k entries) to avoid re-inserting duplicate - transactions -- Validates transaction size against `max_tx_bytes` before forwarding -- Handles retry semantics by removing retryable transactions from the seen cache - -### What AppMempool does NOT do - -- Store transactions — the application owns all mempool state -- Call `CheckTx` — validation is the application's responsibility within `InsertTx` -- Call `Update` after blocks — rechecking is the application's responsibility -- Provide transactions for `ReapMaxBytesMaxGas` — always returns nil, since the - application builds blocks via `PrepareProposal` - -## AppReactor - -The `AppReactor` replaces the traditional mempool reactor (`Reactor`) for P2P -transaction gossip. - -### Broadcasting - -The reactor runs a background loop that: - -1. Calls `ReapTxs` on the application every 500ms -2. Chunks the returned transactions into batches (up to `MaxBatchBytes`) -3. Broadcasts each batch to all connected peers - -### Receiving - -When a peer sends transactions, the reactor: - -1. Deserializes the transaction batch from the P2P envelope -2. Calls `InsertTx` on the `AppMempool` for each transaction -3. Logs and discards transactions that fail insertion (already seen, too large, - or rejected by the application) - -## Transaction Lifecycle - -With the `app` mempool, the transaction lifecycle changes significantly: - -### Previous Lifecycle (flood mempool) - -1. Transaction arrives via RPC or P2P -2. CometBFT validates size and checks the seen cache -3. CometBFT calls `CheckTx` on the application (holds ABCI lock) -4. If valid, CometBFT stores the transaction in its linked list -5. CometBFT broadcasts the transaction to all peers -6. At block proposal time, CometBFT calls `ReapMaxBytesMaxGas` and passes - transactions to `PrepareProposal` -7. After block commit, CometBFT rechecks all remaining transactions via - `CheckTx` (holds ABCI lock for the entire recheck) - -### Updated Lifecycle (app mempool) - -1. Transaction arrives via RPC or P2P -2. CometBFT validates size and checks the seen cache -3. CometBFT calls `InsertTx` on the application (no ABCI lock) -4. The application validates and stores the transaction in its own mempool -5. The `AppReactor` periodically calls `ReapTxs` and broadcasts returned - transactions to peers -6. At block proposal time, `PrepareProposal` receives no transactions from - CometBFT — the application builds the block from its own mempool -7. After block commit, the application runs its own recheck logic on its own - schedule - -## Block Building - -Since the `AppMempool` returns nil from `ReapMaxBytesMaxGas`, the block -executor passes no mempool transactions to `PrepareProposal`. The application's -`PrepareProposalHandler` is expected to select transactions directly from its -own mempool. - -This gives the application full control over transaction ordering, -prioritization, and inclusion. - -## Application Guarantees and Responsibilities - -When implementing `InsertTx` and `ReapTxs`, applications should be aware of the -following: - -### CometBFT guarantees to the application - -- `InsertTx` will not be called with empty transactions -- `InsertTx` will not be called with transactions exceeding `max_tx_bytes` -- Transactions returning a retry code will be removed from the seen cache and - may be re-submitted -- `ReapTxs` will be called periodically (every 500ms) regardless of whether new - transactions have arrived -- `InsertTx` and `ReapTxs` will not hold the ABCI connection lock - -### Application responsibilities - -- **Concurrency**: The application must handle concurrent `InsertTx` calls safely -- **Rechecking**: The application must implement its own transaction revalidation - after blocks are committed -- **Block building**: The application must select transactions for blocks in its - `PrepareProposalHandler` — CometBFT will not provide mempool transactions -- **Storage**: The application must manage its own transaction storage and eviction - -## Configuration - -To enable the `app` mempool, set the mempool type in `config.toml`: - -```toml -[mempool] -type = "app" -``` - -The following options apply to the `app` mempool: - -### Shared options - -These options are shared with other mempool types: - -| Option | Description | Default | -|--------|-------------|---------| -| `max_tx_bytes` | Maximum size of a single transaction (checked before `InsertTx`) | `1048576` (1 MB) | -| `max_batch_bytes` | Maximum size of a broadcast batch | `0` (no limit) | -| `broadcast` | Enable or disable P2P transaction broadcasting | `true` | - -### App mempool options - -These options only apply when `type = "app"`: - -| Option | Description | Default | -|--------|-------------|---------| -| `seen_cache_size` | Size of the LRU cache for deduplicating seen transactions. Prevents re-inserting transactions already forwarded to the application. | `100000` | -| `reap_max_bytes` | Maximum bytes passed to `ReapTxs` per call. `0` means no limit. | `0` | -| `reap_max_gas` | Maximum gas passed to `ReapTxs` per call. `0` means no limit. | `0` | -| `reap_interval` | Interval between `ReapTxs` calls when streaming transactions from the application for peer broadcast. | `"500ms"` | - -#### Example - -```toml -[mempool] -type = "app" -max_tx_bytes = 1048576 - -# App mempool options -seen_cache_size = 100000 -reap_max_bytes = 0 -reap_max_gas = 0 -reap_interval = "500ms" -``` - -Options specific to the `flood` mempool (`size`, `max_txs_bytes`, `cache_size`, -`recheck`, etc.) have no effect when using the `app` mempool. - -## Related Documentation - -- [Cosmos EVM Krakatoa Mempool](/evm/next/documentation/concepts/experimental/krakatoa-mempool) - Cosmos EVM's implementation of the Krakatoa specification -- [Mempool](/cometbft/next/docs/core/mempool) - Overview of CometBFT mempool types -- [ABCI Methods](/cometbft/next/spec/abci/Methods) - ABCI method specification diff --git a/docs.json b/docs.json index 500fed53..81324456 100644 --- a/docs.json +++ b/docs.json @@ -2004,13 +2004,7 @@ "evm/next/documentation/concepts/single-token-representation", "evm/next/documentation/concepts/tokens", "evm/next/documentation/concepts/transactions", - "evm/next/documentation/concepts/eip-1559-feemarket", - { - "group": "Experimental", - "pages": [ - "evm/next/documentation/concepts/experimental/krakatoa-mempool" - ] - } + "evm/next/documentation/concepts/eip-1559-feemarket" ] }, { @@ -5210,7 +5204,6 @@ { "group": "Experimental", "pages": [ - "cometbft/next/docs/experimental/krakatoa-mempool" ] }, { diff --git a/evm/next/documentation/concepts/experimental/krakatoa-mempool.mdx b/evm/next/documentation/concepts/experimental/krakatoa-mempool.mdx deleted file mode 100644 index e1d3c4b1..00000000 --- a/evm/next/documentation/concepts/experimental/krakatoa-mempool.mdx +++ /dev/null @@ -1,285 +0,0 @@ ---- -title: "Krakatoa Mempool" -description: "Application-side mempool management for Cosmos EVM" -icon: "flame" ---- - -> Experimental: The Krakatoa mempool is an upcoming feature and is subject to change. - -## Overview - -CometBFT's [Krakatoa specification](/cometbft/next/docs/experimental/krakatoa-mempool) introduces a new `app` mempool type that delegates transaction storage, validation, and rechecking to the application via two new ABCI methods: `InsertTx` and `ReapTxs`. This page documents **Cosmos EVM's implementation** of that specification. - -The `ExperimentalEVMMempool` is the application-side mempool that fulfills the Krakatoa contract. It manages two sub-pools — an EVM LegacyPool and a Cosmos RecheckMempool — handling transaction insertion, nonce gap queuing, application-side rechecking, and reaping for peer broadcast, all without relying on CometBFT for mempool state. - - -For details on the CometBFT-side changes — the `AppMempool`, `AppReactor`, new ABCI methods, their guarantees, and how to enable your application to take advantage of Krakatoa — see the [CometBFT Krakatoa documentation](/cometbft/next/docs/experimental/krakatoa-mempool). - - -## Quick Start - -Enabling the Krakatoa mempool requires configuring both CometBFT and `evmd`. - -**1. Configure CometBFT** to use the `app` mempool type. See the [CometBFT Krakatoa quick start](/cometbft/next/docs/experimental/krakatoa-mempool#quick-start) for details. - -**2. Enable `operate-exclusively` on `evmd`** so the application mempool takes full ownership of transaction management. - -Via CLI flag: - -```bash -evmd start --evm.mempool.operate-exclusively=true -``` - -Or in `app.toml`: - -```toml -[evm.mempool] -operate-exclusively = true -``` - -When `operate-exclusively` is `true`, `evmd` initializes the Krakatoa mempool and registers the `InsertTx` and `ReapTxs` ABCI handlers. CometBFT **must** be configured with `type = "app"` — if CometBFT is still using the `flood` mempool, the application-side handlers will never be called. - -### Key Features - -- **Krakatoa ABCI integration**: Implements `InsertTx` and `ReapTxs` handlers, enabling all the advantages of the Krakatoa specification — no ABCI lock contention, application-owned mempool state, and decoupled transaction gossip - - **Insert queue**: Fully async insertion via background queues, allowing `InsertTx` to return immediately without blocking on pool validation - - **Reap list**: A staging area that tracks validated transactions and manages which are returned to CometBFT via `ReapTxs` for peer broadcast -- **Application-side rechecking**: Transaction revalidation runs within the application after each block, replacing CometBFT's `CheckTx`-driven recheck pass and giving the application full control over recheck timing and cancellation -- **Non-blocking transaction collection**: A height-aware transaction store allows block builders to collect rechecked transactions as they become available, without waiting for a full recheck pass to complete — enabling proposals to be built from partial recheck results when block time is tight - -## Krakatoa ABCI Integration - -The `ExperimentalEVMMempool` registers `InsertTx` and `ReapTxs` handlers on BaseApp. Together, these two handlers form the core loop: CometBFT pushes transactions in via `InsertTx`, and pulls validated transactions back out via `ReapTxs` for peer broadcast. - -### InsertTx and the Insert Queue - -Instead of validating transactions synchronously inside the `InsertTx` ABCI call, the mempool pushes them onto **insert queues** — one for EVM, one for Cosmos. A background goroutine drains each queue, batches the pending items, and inserts them into the underlying pool. - -Each queued item carries a **subscription channel** that delivers the insertion result. This supports two calling patterns: - -- **Local RPC** (`Insert`): Blocks on the channel, so the caller gets the real result (accepted, queued with nonce gap, or rejected) -- **P2P / ABCI** (`InsertAsync`): Returns immediately — gossip-sourced transactions don't need to wait - -``` -RPC caller ──Insert──▶ queue.Push(tx) ──▶ background loop ──▶ pool.Add(tx) - │ │ - ◀──────── subscription channel ◀───────┘ - (blocks until result) - -P2P peer ──InsertAsync──▶ queue.Push(tx) ──▶ (returns immediately) -``` - -#### ABCI handler wiring - -The ABCI handler wires this up in `evmd`: - -```go -func (app *EVMD) NewInsertTxHandler(evmMempool *evmmempool.ExperimentalEVMMempool) sdk.InsertTxHandler { - return func(req *abci.RequestInsertTx) (*abci.ResponseInsertTx, error) { - // ... decode tx bytes ... - - code := abci.CodeTypeOK - if err := evmMempool.InsertAsync(ctx, tx); err != nil { - switch { - case errors.Is(err, evmmempool.ErrQueueFull): - code = abci.CodeTypeRetry // CometBFT removes from seen cache, will retry - default: - code = CodeTypeNoRetry // permanent rejection - } - } - return &abci.ResponseInsertTx{Code: code}, nil - } -} -``` - -### ReapTxs and the Reap List - -The **reap list** tracks transactions that are ready for broadcast. It replaces the old `BroadcastTxFn` callback pattern — instead of the application pushing transactions to CometBFT, CometBFT pulls them via `ReapTxs`. - -#### Adding transactions - -When a transaction enters the reap list depends on its type: - -| Transaction type | Added to reap list | Why | -|---|---|---| -| **EVM** | On promotion to pending (`OnTxPromoted`) | Nonce-gapped transactions stay local until their dependencies are satisfied | -| **Cosmos** | Immediately after pool insertion | No queued/pending distinction — ready for broadcast once validated | - -#### Removing transactions - -Transactions leave the reap list in two ways: - -| Path | Trigger | Behavior | -|---|---|---| -| **Reap** (normal) | `AppReactor` calls `ReapTxs` | Drained in FIFO order. Hash stays in the index as a guard to prevent double-broadcasting. | -| **Drop** (invalidation) | `OnTxRemoved` (EVM) or `removeCosmosTx` (Cosmos) | Fully removed from slice and index — if the tx is re-gossiped later, it can re-enter the reap list. | - -#### ABCI handler wiring - -The `ReapTxsHandler` drains the reap list and returns the encoded bytes: - -```go -func (app *EVMD) NewReapTxsHandler(evmMempool *evmmempool.ExperimentalEVMMempool) sdk.ReapTxsHandler { - return func(req *abci.RequestReapTxs) (*abci.ResponseReapTxs, error) { - txs, err := evmMempool.ReapNewValidTxs(req.GetMaxBytes(), req.GetMaxGas()) - if err != nil { - return nil, err - } - return &abci.ResponseReapTxs{Txs: txs}, nil - } -} -``` - -## Application-Side Rechecking - -With Krakatoa, the application rechecks its own mempool after each block — CometBFT no longer drives this via `CheckTx`. Both sub-pools use a `Rechecker` to assist with this that wraps an `sdk.Context` and the ante handler, threading state forward as each transaction is validated. - -### EVM Rechecking - -On a new block, the LegacyPool runs a two-phase recheck: - -1. **`promoteExecutables`** — promotes queued transactions that are now executable. Rechecking does **not** write state back during a block reset, since these will be re-validated next. -2. **`demoteUnexecutables`** — validates all pending transactions on a fresh context, writing state back to the recheck context after each success. - -Outside of block processing (e.g., a new tx fills a nonce gap), `promoteExecutables` *does* write state back to the recheck context — it builds on the context `demoteUnexecutables` already established. - -### Cosmos Rechecking - -Transactions are rechecked in `Select` order, committing state forward. Failed transactions — and dependents from the same account — are removed. - -New inserts must validate against post-recheck state, so the pool holds an exclusive lock for the full recheck pass. - -### Cancellation - -If a new block arrives mid-recheck, the current pass is cancelled and restarted against the new state. Both sub-pools check a cancellation channel between transactions — no partial results are committed. - -## Non-Blocking Transaction Collection - -Rechecking holds the pool lock, but since Krakatoa removes the ABCI lock, `PrepareProposal` can arrive mid-recheck. We can't block the proposer waiting for a full recheck to finish. - -Both pools solve this with a `HeightSync` store — as each transaction passes recheck, it's pushed into a lock-free, height-indexed store. The proposer reads from this store directly: - -- **Recheck complete** → proposer gets the full set immediately -- **Recheck in progress** → proposer waits up to a configurable timeout, then takes whatever's been validated so far - -This timeout lets operators tune the tradeoff between block fullness and proposal latency. A longer timeout means more transactions in the block but slower proposals; a shorter timeout prioritizes speed at the cost of potentially smaller blocks. - -The block builder collects from both the EVM and Cosmos stores to assemble a proposal. - -## Address Reservation - -Previously, an account could have transactions in both the EVM and Cosmos pools simultaneously. With Krakatoa, this is no longer allowed — a single account can only have transactions in one pool at a time. - -Each pool gets its own `ReservationHandle` with a unique ID. The handle's `Hold` method is idempotent within the same pool (holding an already-held address is a no-op) but fails across pools. - -### Why - -Each pool needs to recheck, insert, and invalidate transactions independently — without consulting the other pool's state. By guaranteeing an address only exists in one pool, each pool can validate and evict transactions in isolation, with no cross-pool coordination required. - -## Transaction Lifecycle Diagrams - -The following diagrams trace a nonce-gapped EVM transaction through its full lifecycle — from submission through rechecking across multiple blocks. - -**Scenario**: Account sends tx with nonce 5, but the pool expects nonce 4. The tx is queued until nonce 4 arrives in a later block. - -### Local RPC Submission (`eth_sendRawTransaction`) - -```mermaid -sequenceDiagram - participant User - participant RPC as JSON-RPC - participant Queue as Insert Queue - participant Pool as LegacyPool - participant RL as Reap List - participant Comet as CometBFT - participant HS as HeightSync Store - - Note over User,HS: Block N — Nonce-gapped tx arrives - - User->>RPC: eth_sendRawTransaction(tx nonce=5) - RPC->>Queue: Insert(tx) — blocks on subscription channel - Queue->>Pool: background loop → txPool.Add(tx) - Pool-->>Pool: address reserved via reserver - Pool-->>Pool: nonce gap detected (expected 4, got 5) - Pool-->>Pool: tx enters queued pool - Pool->>Pool: OnTxEnqueued fires - Pool-->>Queue: result: success (queued) - Queue-->>RPC: subscription channel delivers result - RPC-->>User: tx hash returned - - Note over User,HS: Block N+1 — New block triggers recheck - - Comet->>Pool: new block event - Pool-->>Pool: promoteExecutables — tx still gapped, stays queued - Pool-->>Pool: demoteUnexecutables — validates pending txs - Pool->>HS: valid pending txs → HeightSync store - - Note over User,HS: Block N+2 — Gap-filling tx (nonce=4) arrives - - User->>RPC: eth_sendRawTransaction(tx nonce=4) - RPC->>Queue: Insert(tx) - Queue->>Pool: txPool.Add(tx) - Pool-->>Pool: nonce 4 fills gap → promotes nonce 5 - Pool->>Pool: OnTxPromoted fires for both txs - Pool->>RL: both txs pushed to reap list - Pool->>HS: both txs added to HeightSync store - - Comet->>RL: ReapTxs (500ms poll) - RL-->>Comet: returns both txs - Comet-->>Comet: broadcasts to peers - - Comet->>Pool: PrepareProposal - Pool->>HS: collect txs from HeightSync store - HS-->>Pool: validated txs - Pool-->>Comet: proposal built -``` - -### Local RPC Submission — Cosmos tx (`BroadcastTxSync`) - -```mermaid -sequenceDiagram - participant User - participant Comet as CometBFT - participant App as InsertTx (ABCI) - participant Queue as Insert Queue - participant Pool as RecheckMempool - participant RL as Reap List - participant HS as HeightSync Store - - Note over User,HS: Block N — Cosmos tx arrives - - User->>Comet: BroadcastTxSync(tx) - Comet->>App: InsertTx(tx) - App->>Queue: InsertAsync(tx) — returns immediately - App-->>Comet: ResponseInsertTx{Code: OK} - Comet-->>User: tx hash returned - - Queue->>Pool: background loop → insertCosmosTx(tx) - Pool-->>Pool: ante handler validation passes - Pool-->>Pool: address reserved via reserver - Pool->>RL: tx pushed to reap list - - Comet->>RL: ReapTxs (500ms poll) - RL-->>Comet: returns tx - Comet-->>Comet: broadcasts to peers - - Note over User,HS: Block N+1 — New block triggers recheck - - Comet->>Pool: new block event → TriggerRecheck - Pool-->>Pool: write lock acquired - Pool-->>Pool: recheck tx via ante handler, commit state forward - Pool->>HS: tx marked as rechecked in HeightSync store - Pool-->>Pool: write lock released - - Comet->>Pool: PrepareProposal - Pool->>HS: collect rechecked txs from HeightSync store - HS-->>Pool: validated txs - Pool-->>Comet: proposal built -``` - -## Related Documentation - -- [CometBFT Krakatoa](/cometbft/next/docs/experimental/krakatoa-mempool) - AppMempool, ABCI methods, and CometBFT-side architecture -- [Mempool](/evm/next/documentation/concepts/mempool) - Current mempool architecture and configuration -- [Transactions](/evm/next/documentation/concepts/transactions) - Transaction types and lifecycle -- [Gas and Fees](/evm/next/documentation/concepts/gas-and-fees) - Fee calculation and EIP-1559 integration