緊湊區塊過濾器 (CBF)

比特幣輕客戶端的隱私保護過濾技術。

CBF 對輕錢包隱私與效率都有實質價值。

客戶端先比對 filter 再請求資料，可降低地址集合外洩。

緊湊區塊過濾器 (CBF)的核心運作邏輯

• 節點提供每區塊對應 filter，客戶端本地匹配腳本模式。
• 命中後再下載必要交易與證明，節省流量。
• 要處理 reorg 與惡意節點餵假資料情境。

實務做法：把概念變成系統

• 連接多節點交叉驗證 filter。
• 分段快取並保存掃描進度。
• 發現異常時回退到更保守驗證模式。

實務誤區：看起來對，其實錯

• 單點信任。
• 未處理重組。
• 快取不一致。

進一步探索

• 上層文章： Bitcoin Core 節點運作

實作案例：從需求到上線

以下是一個在團隊協作中可重現、可驗證的落地順序，重點是先確保行為可觀測，再做效能調優。

1. 定義需求邊界：先確認系統追求的是吞吐、延遲、可審計還是隱私。
2. 建立最小可重現環境：固定版本、固定資料集、固定驗證步驟。
3. 將觀測指標接入告警：用數據驅動調參，而不是靠直覺調整。
4. 上線前壓測失敗路徑：包含逾時、重試、回滾與資料一致性檢查。

輕客戶端最好連多節點交叉驗證 filter，降低單點餵料風險。

設計取捨：成本、風險與維運的平衡點

如果你的系統面向生產環境，優先順序應是「正確性 > 可觀測性 > 效能優化」。當三者衝突時，先守住可驗證與可回滾，再追求吞吐。

如果你要把這篇主題直接導入現有服務，建議先做小流量灰度：

• 先讓新流程與舊流程並行一段時間，確認輸出一致性。
• 指標達標後再放大流量，避免一次性切換造成不可逆影響。
• 保留回滾開關，確保故障時能在分鐘級恢復。

結論

只連單節點時，攻擊者可透過偽 filter 影響錢包可見性。

如果你要把本文主題用在生產環境，建議先完成「可重現測試、監控告警、失敗回滾」三件事，再擴大資金與流量。