跳至主要內容
協議 進階

記憶池

Mempool

又稱:交易池、Memory Pool

記憶池(Mempool,Memory Pool 的縮寫)是每個比特幣節點維護的待確認交易暫存區。當用戶發送交易後,它會先進入網路中各節點的記憶池等待礦工選取打包進區塊。記憶池是比特幣手續費市場的核心,交易在這裡競爭有限的區塊空間。

記憶池的本質

什麼是記憶池?

簡單理解:

記憶池 = 「等候室」
- 交易在這裡等待被確認
- 先到不一定先服務
- 「付費」越多優先級越高

技術定義:
- 未確認交易的本地快取
- 每個節點獨立維護
- 非共識層(各節點可能不同)

為什麼需要記憶池?

問題:交易不能立即入塊

原因:
1. 區塊每 10 分鐘才產生一個
2. 區塊空間有限(~4 MB)
3. 交易數量可能超過容量

記憶池的作用:
- 暫存等待確認的交易
- 提供手續費市場機制
- 讓礦工選擇最優交易
- 支援交易傳播和中繼

交易生命週期

從發送到確認

完整流程:

1. 用戶創建交易
   └→ 錢包簽名交易

2. 廣播到網路
   └→ 發送給連接的節點

3. 節點驗證
   └→ 檢查簽名、餘額、格式

4. 進入記憶池
   └→ 等待礦工選取

5. 礦工打包
   └→ 選入候選區塊

6. 區塊確認
   └→ 交易從記憶池移除

7. 確認累積
   └→ 後續區塊增加安全性

交易狀態

狀態類型:

1. 未廣播
   - 只在本地
   - 尚未發送到網路

2. 在記憶池中
   - 已驗證
   - 等待確認
   - 可能被替換(RBF)

3. 已確認
   - 在區塊中
   - 從記憶池移除

4. 被拒絕
   - 驗證失敗
   - 不會進入記憶池

記憶池特性

非共識性

每個節點的記憶池可能不同:

原因:
1. 交易傳播有延遲
2. 節點接收順序不同
3. 節點配置可能不同
4. 容量限制不同

影響:
- 交易可能在某些節點但不在其他節點
- 礦工看到的記憶池決定區塊內容
- 沒有「全局記憶池」概念

容量限制

Bitcoin Core 預設設定:

maxmempool = 300 MB

當超出限制時:
1. 計算每筆交易的「祖先費率」
2. 移除最低費率的交易
3. 釋放空間給新交易

自訂設定:
bitcoind -maxmempool=500  # 增加到 500 MB

動態清理

記憶池清理情況:

1. 新區塊到達
   - 移除已確認交易
   - 移除衝突交易

2. 超時驅逐
   - 預設 14 天(336 小時)
   - 超時交易被移除

3. 容量溢出
   - 移除低費率交易
   - 為高費率交易騰空間

4. RBF 替換
   - 新交易替換舊交易
   - 必須滿足 RBF 規則

手續費市場

優先級排序

礦工選擇交易的標準:

主要指標:費率(sat/vB)

費率 = 總手續費 / 交易虛擬大小

範例:
交易 A:1000 sat 手續費,200 vB → 5 sat/vB
交易 B:2000 sat 手續費,500 vB → 4 sat/vB
交易 A 優先級更高(費率更高)

為什麼用費率而非總額?
- 區塊空間有限
- 最大化礦工收益
- 公平競爭機制

費率區間

典型費率範圍(會隨擁堵程度變化):

| 優先級 | 費率 (sat/vB) | 預期確認時間 |
|-------|---------------|-------------|
| 最高 | 100+ | 下一區塊 |
| 高 | 50-100 | 1-2 區塊 |
| 中 | 20-50 | 3-6 區塊 |
| 低 | 10-20 | 數小時 |
| 最低 | 1-10 | 數天或永不 |

最低中繼費率:
Bitcoin Core 預設:1 sat/vB
低於此費率的交易會被拒絕中繼

祖先費率(Ancestor Feerate)

考慮交易依賴關係:

問題:
交易 B 依賴交易 A(使用 A 的輸出)
A 費率低,B 費率高
礦工必須同時打包 A 和 B

解決方案:祖先費率
祖先費率 = (A 費用 + B 費用) / (A 大小 + B 大小)

範例:
A:100 sat,100 vB → 1 sat/vB
B:900 sat,100 vB → 9 sat/vB(單獨看)
祖先費率:(100 + 900) / (100 + 100) = 5 sat/vB

CPFP(Child Pays for Parent)就是利用這個原理

記憶池政策

接受規則

交易進入記憶池的條件:

1. 格式有效
   - 正確的序列化格式
   - 符合共識規則

2. 簽名有效
   - 所有輸入有效簽名
   - 不是雙花

3. 輸入存在
   - UTXO 存在且未花費
   - 或父交易在記憶池中

4. 手續費足夠
   - ≥ 最低中繼費率
   - 通常 ≥ 1 sat/vB

5. 大小限制
   - 單筆交易 ≤ 400,000 vB
   - 祖先/後代限制

6. 標準性(可選)
   - 僅中繼「標準」交易
   - 非標準交易可直接提交給礦工

祖先/後代限制

防止過長交易鏈:

預設限制(Bitcoin Core):

祖先限制:
- 最多 25 筆祖先交易
- 祖先總大小 ≤ 101 KB

後代限制:
- 最多 25 筆後代交易
- 後代總大小 ≤ 101 KB

為什麼有這些限制?
- 防止 DoS 攻擊
- 限制驗證複雜度
- 確保快速區塊驗證

RBF(Replace-by-Fee)

交易替換規則:

啟用條件:
- 原交易必須信號 RBF(nSequence < 0xfffffffe)
- 或節點啟用完整 RBF

替換規則:
1. 新交易必須支付更高總費用
2. 費用增加必須 ≥ 最低中繼費 × 新交易大小
3. 新交易不能引入新的未確認輸入
4. 新交易必須花費原交易的所有輸入

範例:
原交易:1000 sat 費用
新交易:必須 > 1000 + (1 sat/vB × 新交易大小)

記憶池監控

關鍵指標

監控項目:

1. 記憶池大小
   - 交易數量
   - 總 vB 大小
   - MB 佔用

2. 費率分布
   - 各費率區間的交易數
   - 預估確認時間

3. 入池/出池速率
   - 新交易進入速度
   - 確認/驅逐速度

4. 最低接受費率
   - 當前能進入記憶池的最低費率

視覺化工具

推薦工具:

1. mempool.space
   - 即時記憶池視覺化
   - 費率預估
   - 區塊預測
   - 交易追蹤

2. jochen-hoenicke.de/queue
   - 歷史記憶池圖表
   - 費率趨勢

3. txstreet.com
   - 動畫視覺化
   - 有趣的呈現方式

Bitcoin Core RPC

記憶池資訊

# 獲取記憶池概況
bitcoin-cli getmempoolinfo

# 輸出範例:
{
  "loaded": true,
  "size": 15234,           # 交易數量
  "bytes": 23456789,       # 總大小(bytes)
  "usage": 89012345,       # 記憶體使用
  "total_fee": 1.23456789, # 總手續費(BTC)
  "maxmempool": 300000000, # 最大容量
  "mempoolminfee": 0.00001000,  # 最低費率
  "minrelaytxfee": 0.00001000,  # 最低中繼費率
  "incrementalrelayfee": 0.00001000
}

查詢交易

# 獲取記憶池所有交易 ID
bitcoin-cli getrawmempool

# 獲取詳細資訊
bitcoin-cli getrawmempool true

# 獲取特定交易的記憶池資訊
bitcoin-cli getmempoolentry <txid>

# 輸出範例:
{
  "vsize": 141,
  "weight": 561,
  "fee": 0.00001410,
  "modifiedfee": 0.00001410,
  "time": 1704067200,
  "height": 850000,
  "descendantcount": 1,
  "descendantsize": 141,
  "descendantfees": 1410,
  "ancestorcount": 1,
  "ancestorsize": 141,
  "ancestorfees": 1410,
  "wtxid": "...",
  "fees": {
    "base": 0.00001410,
    "modified": 0.00001410,
    "ancestor": 0.00001410,
    "descendant": 0.00001410
  },
  "depends": [],
  "spentby": [],
  "bip125-replaceable": true
}

費率估算

# 估算 N 個區塊內確認的費率
bitcoin-cli estimatesmartfee 6

# 輸出範例:
{
  "feerate": 0.00012345,  # BTC/kB
  "blocks": 6
}

# 轉換為 sat/vB:
# 0.00012345 BTC/kB = 12.345 sat/vB

提交交易

# 提交原始交易
bitcoin-cli sendrawtransaction <hex>

# 測試交易(不廣播)
bitcoin-cli testmempoolaccept '["<hex>"]'

# 輸出範例:
[{
  "txid": "...",
  "wtxid": "...",
  "allowed": true,
  "vsize": 141,
  "fees": {
    "base": 0.00001410
  }
}]

記憶池與擁堵

擁堵情況

擁堵時的現象:

1. 記憶池增大
   - 交易累積
   - 超過 300 MB 開始驅逐

2. 費率上升
   - 競爭加劇
   - 低費率交易被驅逐

3. 確認延遲
   - 等待時間增加
   - 低費率可能永遠不確認

歷史高峰:
2017 牛市:300+ sat/vB 才能快速確認
2023 Ordinals:100+ sat/vB 常態化

應對策略

用戶端:

1. 使用費率估算
   - 參考 mempool.space
   - 使用錢包的自動估算

2. 利用 RBF
   - 交易卡住時加速
   - 提高費率重新廣播

3. 批量交易
   - 合併多筆支付
   - 降低平均費率

4. 選擇時機
   - 週末/夜間費率較低
   - 避開擁堵高峰

礦工端:

1. 優化打包策略
   - 最大化費用收入
   - 包含 CPFP 交易鏈

記憶池安全

潛在攻擊

1. 記憶池泛洪
   攻擊:發送大量低費率交易
   防禦:最低費率要求、容量限制

2. 交易卡頓攻擊
   攻擊:創建大量相互依賴的交易
   防禦:祖先/後代限制

3. 費率操縱
   攻擊:人為抬高記憶池費率
   成本:需要真實支付高費用
   防禦:經濟成本抑制

4. 交易審查
   風險:礦工拒絕打包特定交易
   緩解:多個礦工競爭

隱私考量

記憶池洩露的資訊:

1. 交易關聯
   - 觀察者可以追蹤交易
   - 分析發送模式

2. IP 關聯
   - 首先廣播的節點可能是發送者
   - 網路分析可識別來源

隱私保護:
- 使用 Tor
- 等待隨機時間再廣播
- 使用隱私錢包

進階主題

Package Relay

交易包中繼(開發中):

問題:
- 父交易費率低
- 無法單獨進入記憶池
- 高費率子交易也無法廣播

解決方案:
- 允許交易包一起提交
- 按包的祖先費率評估

好處:
- 更好的 CPFP 支援
- 改善 Lightning 通道關閉
- 更靈活的費率市場

Cluster Mempool

叢集記憶池(提案中):

現狀問題:
- 祖先/後代追蹤複雜
- 替換規則難以最優化

新設計:
- 將相關交易分組為「叢集」
- 簡化依賴關係追蹤
- 更好的替換策略

好處:
- 更簡單的程式碼
- 更好的費率估算
- 更公平的替換規則

常見問題

交易卡在記憶池怎麼辦?

解決方案:

1. 等待(如果不急)
   - 擁堵會減輕
   - 交易最終會確認

2. RBF 加速
   - 如果啟用了 RBF
   - 重新廣播更高費率版本

3. CPFP 加速
   - 使用找零輸出
   - 創建高費率子交易

4. 交易加速服務
   - 部分礦池提供
   - 支付額外費用

5. 等待超時
   - 14 天後自動驅逐
   - UTXO 回到可用狀態

為什麼交易不見了?

可能原因:

1. 被驅逐
   - 費率太低
   - 記憶池滿時被清除

2. 衝突替換
   - 被 RBF 交易替換
   - 輸入被其他交易使用

3. 已確認
   - 檢查區塊鏈瀏覽器
   - 可能已入塊

4. 從未進入
   - 驗證失敗
   - 檢查錢包錯誤訊息

5. 超時
   - 超過 14 天
   - 自動移除

找回資金:
- 交易消失後,UTXO 仍屬於你
- 可以創建新交易使用相同輸入

如何估算最佳費率?

方法:

1. 使用 mempool.space
   - 即時費率建議
   - 考慮當前擁堵

2. 錢包自動估算
   - 大多數錢包有此功能
   - 通常足夠準確

3. Bitcoin Core estimatesmartfee
   - 指定確認區塊數
   - 返回建議費率

4. 觀察最近區塊
   - 查看已確認交易的費率
   - 參考最低入塊費率

建議:
- 急:使用建議費率
- 不急:使用低費率 + RBF
- 靈活:根據需求調整
已複製到剪貼簿