協議 進階
記憶池
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
- 靈活:根據需求調整