Bitcoin Core v32.0rc1 改動錢包協議　RPC 介面或致應用短暫失靈

Bitcoin Core v32.0rc1 將 9 月 14 日至 10 月 10 日這段時間，變成節點營運者、錢包供應商，以及依賴 Bitcoin Core RPC 介面的各類服務的一次集中相容性壓力測試。該候選版本已於 9 月 14 日以已驗證簽名完成標記；官方發布時間表把 10 月 10 日列為最終 v32.0 標記的目標日期，期間相隔 26 日。CryptoSlate 8 月的前瞻曾記錄 RC1 目標為 9 月 10 日，而最新時間表顯示為 9 月 14 日，出現 4 日差距，但未能證明原定期限在不變的情況下被錯過。 v32.0rc1 的標記屬預發布軟件，並非可直接視作生產環境的最終升級；同時亦不代表有任何新的共識規則啟動。版本中有一項與 BIP 323 草案相關的改動，會調整 Bitcoin Core 對訊號位（signaling bits）及「未知部署」警告的處理方式，但該提案仍屬 Draft 狀態。 官方最新的 RC 測試指引建議營運者先從高層流程入手：把常用功能放到獨立的臨時資料目錄中反覆演練，再把候選版與上一個正式版比對。下載頁面目前以 31.1 為基準版本。透過對照測試，可在不把 RC 當作例行生產升級的前提下，及早發現節點啟動、錢包行為及 RPC 回應的差異。 草案 v32 發布說明中最顯著的效能改動，是在連接區塊（block connection）時並行預取交易輸出（transaction outputs）。該設定預設使用 8 個工作執行緒，最高支援 16 個，亦可關閉。對於磁碟受限（disk-bound）的驗證工作負載，建議以不同設定做對照，評估加快區塊處理是否會在 CPU、記憶體或儲存延遲上帶來難以接受的成本。 錢包與服務整合則面臨另一類「斷裂」風險：有 4 個 RPC 會預設改用 PSBTv2，其餘介面亦會移除已棄用欄位，或拒絕舊版本曾容許的參數。涉及建立、轉換或調高手續費（feebump）PSBT 的團隊，需要把相關交易在下游解析器與簽署流程中逐段追蹤，確認不會因格式變動而失敗。 手續費處理亦要覆蓋失敗路徑。預設的 estimatesmartfee 流程會把 blockpolicy 與 mempool 兩種估算器合併使用，可能回傳較低估算，並在任一組件失效時報錯。營運者應在啟動階段，以及 mempool 稀疏或不健康的情況下觀察行為，並核實監控告警與明確的 blockpolicy 後備方案能否如預期運作。 HTTP 伺服器重寫把測試範圍由節點本體擴展到周邊基建。新版本加入 8,192 位元組的 header 上限、對異常 header 更嚴格的處理、預設 16 條 RPC 連線上限、新的 REST 快取控制，以及對未授權客戶端位址即時斷線等機制。這些變更可能在反向代理、健康檢查、客戶端連線池及錯誤處理器上被放大。 回滾同樣需要重點驗證。重建後的交易索引（transaction index）可把磁碟佔用降至原來的一半以下，但舊版本無法讀取新格式；一旦降級，可能觸發再度重建，耗時可達數小時。重視私隱的營運者亦宜重現與 Tor 後備修正相關的私密廣播（private broadcast）失敗情境，包括 10,000 筆佇列上限、1,000 次嘗試限制，以及高負載下的轉發行為。 由於最終 v32.0 標記目前仍屬「目標」，上述邊界情況的驗證，正是 RC 視窗期最實際的工作重點。 （原文：CryptoSlate）