Wallet Pools上線：Fireblocks讓金庫交易不再卡關

數位資產託管業者Fireblocks推出新功能「Wallet Pools」，把多個金庫帳戶整合成單一交易來源，一旦某個金庫的交易卡住，系統就能把新交易改送到狀態正常的金庫，藉此繞開延遲瓶頸。

根據Crypto Briefing的報導，於8月5日（當地時間）指出，Fireblocks將多個金庫組成統一資源池，透過「依狀態分級的輪詢」演算法繞過堵塞環節。這項功能主要針對以太幣(ETH)這類帳戶模式區塊鏈常見的問題：只要前一筆交易因「nonce」順序卡住，後面的交易也得跟著等。

「nonce」是帳戶模式區塊鏈用來決定交易順序的編號。同一個帳戶裡，先送出的交易如果手續費偏低，或剛好碰上網路手續費飆升，就可能長時間卡在記憶池（mempool）裡，導致後面送出的交易也得排隊等候。

這種連鎖延遲對經常處理出金與結算的交易所、支付公司與金融科技業者來說，會直接影響客服應對與內部作業。當交易集中湧向同一個金庫帳戶，特定nonce或手續費問題造成的瓶頸也可能隨之擴大。

Fireblocks開發者文件說明，手續費偏低或網路手續費突然上升，都可能讓交易滯留在記憶池。部分網路上，這還會連帶拖住同一金庫帳戶的後續交易。

過去業界的因應方式，多是調整卡住交易本身的手續費以提高處理機會：EVM相容網路常用「RBF」（Replace By Fee，替代手續費），比特幣(BTC)則多用「CPFP」（Child Pays For Parent，子付父費）。

Wallet Pools走的是不同路線，不是提高卡住交易的手續費，而是把交易來源分散到多個金庫。就算某個金庫發生瓶頸，新交易也能改走其他暢通的路徑，等於從運作結構上做了調整。

Fireblocks的Python SDK發行說明顯示，6月11日發布的v21.0.0版本起，交易來源類型新增了「WALLET_POOL」選項，讓客戶能把Wallet Pools設為交易來源，並依此篩選相關交易。

Fireblocks另於7月27日公布支援高頻直接託管作業的產品更新，內容包括△批次核准△Solana(SOL)多目的地交易△UTXO Manager△廣播子狀態（Broadcasting sub-statuses）△帳戶流量控管（Account Traffic Control）。

Account Traffic Control負責偵測卡在記憶池的交易，並提供即時排解協助。開發者文件顯示，處於測試階段的webhook「transaction.alert.stuck_confirming」會在EVM區塊鏈交易卡在「CONFIRMING」狀態、且可能阻擋後續交易時觸發。

該webhook的範例欄位包含低手續費交易偵測結果、卡住的交易數量、最後完成的nonce，以及滯留時間等資訊。如果說Wallet Pools是替新交易分散路徑，Account Traffic Control則更像是在延遲發生後負責偵測與應對。

Fireblocks表示，客戶透過其平台在數十條鏈上處理支付，並為數百萬名終端用戶發行內建錢包。公司介紹資料提到，包括Worldpay、BNY Mellon、Galaxy、Revolut在內，共有數千家機構採用Fireblocks的服務。

評論：這次更新談的是託管與結算基礎設施的運作穩定度，不涉及代幣價格或籌碼變化。Fireblocks並未公開Wallet Pools適用的鏈別、客戶端啟用條件，也沒有揭露具體的故障率下降幅度或處理量提升程度，實際效果仍待後續觀察。