cfxcore/pos/mempool/
mod.rs

1// Copyright (c) The Diem Core Contributors
2// SPDX-License-Identifier: Apache-2.0
3
4// Copyright 2021 Conflux Foundation. All rights reserved.
5// Conflux is free software and distributed under GNU General Public License.
6// See http://www.gnu.org/licenses/
7
8#![forbid(unsafe_code)]
9// Increase recursion limit to allow for use of select! macro.
10
11//! Mempool is used to hold transactions that have been submitted but not yet
12//! agreed upon and executed.
13//!
14//! **Flow**: AC sends transactions into mempool which holds them for a period
15//! of time before sending them into consensus.  When a new transaction is
16//! added, Mempool shares this transaction with other nodes in the system.  This
17//! is a form of “shared mempool” in that transactions between mempools are
18//! shared with other validators.  This helps maintain a pseudo global ordering
19//! since when a validator receives a transaction from another mempool, it will
20//! be ordered when added in the ordered queue of the recipient validator. To
21//! reduce network consumption, in “shared mempool” each validator is
22//! responsible for delivery of its own transactions (we don't rebroadcast
23//! transactions originated on a different peer). Also we only broadcast
24//! transactions that have some chance to be included in next block: their
25//! sequence number equals to the next sequence number of account or sequential
26//! to it. For example, if the current sequence number for an account is 2 and
27//! local mempool contains transactions with sequence numbers 2,3,4,7,8, then
28//! only transactions 2, 3 and 4 will be broadcast.
29//!
30//! Consensus pulls transactions from mempool rather than mempool pushing into
31//! consensus. Mempool doesn't track which transactions have already been sent
32//! to Consensus; on each `get_block` request Consensus forwards a set of
33//! transactions that were pulled from Mempool but not yet committed, so
34//! Mempool can stay agnostic about Consensus proposal branches. Once a
35//! transaction is fully executed and written to storage, Consensus notifies
36//! Mempool and the transaction is dropped.
37//!
38//! **Internals**: Mempool is modeled as
39//! `HashMap<AccountAddress, AccountTransactions>` plus a TTL index used only
40//! for expiration/GC. There is no priority ordering — the PoS mempool carries
41//! only PoS-specific transactions (Election, PivotDecision, BLS signatures),
42//! not user traffic, so gas-price ranking does not apply. `get_block` iterates
43//! accounts, returning sequence-number-ordered transactions per account while
44//! skipping those that Consensus has already seen.
45//!
46//! Mempool caps both total transaction count and per-account count to bound
47//! memory use.
48//!
49//! Transactions in Mempool have two types of expirations: systemTTL and
50//! client-specified expiration. Once we hit either of those, the transaction is
51//! removed from Mempool. SystemTTL is checked periodically in the background,
52//! while the client-specified expiration is checked on every Consensus commit
53//! request. We use a separate system TTL to ensure that a transaction won't
54//! remain stuck in Mempool forever, even if Consensus doesn't make progress
55
56pub use shared_mempool::{
57    bootstrap, network,
58    types::{
59        CommitNotification, CommitResponse, CommittedTransaction,
60        ConsensusRequest, ConsensusResponse, MempoolClientSender,
61        SubmissionStatus, TransactionExclusion,
62    },
63};
64
65mod core_mempool;
66mod logging;
67mod shared_mempool;
cfxcore/pos/mempool/mod.rs

cfxcore/pos/mempool/
mod.rs
