發生什麼：SwiftSync 進了 Floresta 主分支
以 Rust 撰寫、主打 Utreexo 的輕量比特幣全節點 Floresta，在 2026-10-15（UTC）把開發者 JoseSK999 的 PR #1115「Assume-Valid SwiftSync with accumulator building」合併進 master 分支。這個 PR 從 2026-06-03 開啟，共 10 個 commit、改動 23 個檔案，新增 1,749 行、刪除 148 行。開發者 rustaceanrob 於 2026-10-18 在 Delving Bitcoin 的 SwiftSync 討論串轉告了這項合併。
需要先講清楚狀態：這是程式碼合併，不是正式版本。截至本文撰寫時，Floresta 官方發版頁最新版本仍是 2026-04-27 的 v0.9.1，一般使用者要用到這項功能，得自己從主分支編譯，並以 --no-assume-utreexo 參數啟動，同時把對應網路的 hints 檔（例如 bitcoin.hints）放進資料夾。找不到 hints 時，節點會退回原本較慢、依賴大量 Merkle 證明的 Utreexo 順序同步。
原始證據：兩個想法怎麼拼在一起
Utreexo 把整個 UTXO 集合壓成少數幾個 Merkle 樹根，節點不必保存十幾 GB 的 UTXO 資料庫，但代價是每次花費一筆輸出都要附上存在證明。Delving Bitcoin 作者 Davidson 在 2026-09-05 的文章中估計，若不做快取，證明的額外負擔約等於區塊本身大小，整個初始區塊下載（IBD）需要的資料量約是鏈大小的兩倍，以當時的鏈計約 1.3 TB。
SwiftSync 則是 Ruben Somsen 提出的同步方法：事先提供一份 hints 檔，標明每個輸出在某個目標高度時是否已被花掉，節點邊下載邊累加一個可交換的雜湊總和，最後總和必須歸零，才能證明 hints 沒有說謊。因為累加順序不影響結果，區塊可以亂序、平行處理。
兩者結合的關鍵叫「implicit deletion（隱式刪除）」：既然 hints 已經說某個輸出之後會被花掉，加進 Utreexo 樹時就乾脆不提交它，等同提前刪除，之後遇到花費它的交易也不需要 Merkle 證明。Floresta 的追蹤議題寫明，這等於在 Utreexo IBD 中省下約 1 TB 的 Merkle 證明。
開發者公布的數字與尚未完成的部分
依 Floresta 追蹤議題，目前實作的是「Witnessless」版本：在 assume-valid 範圍內不驗證輸入腳本，因此也不下載見證資料，開發者估計可再省下約 35% 的總下載量，接近 300 GB。開發者列出的最快一次實測，是一台約 4 Gbps、32 vCPU、一開始就連上 30 個節點的 VPS，同步耗時 19 分鐘；另有 2014 年款 MacBook Pro 與約 300 Mbps 機器的測試圖表。Davidson 也在 Delving 文章中表示，在約 30 Mbps 到 2 Gbps 的測試中，瓶頸一直在網速，連 Raspberry Pi 也是如此。這些都是開發者自測結果，尚非第三方基準。
追蹤議題同時列出仍未完成的項目，包括：中斷後續傳 SwiftSync、在 AV SwiftSync 中檢查絕對 locktime、動態下載窗口、限制 StumpUpdater 快取大小、完全驗證版 SwiftSync 等。其中快取問題被明確標為潛在 DoS 向量：累加器更新必須依高度順序套用，等待前一個區塊時會暫存後續資料；以約 1.65 億個 UTXO 計，最壞情況需 5–6 GB 記憶體，惡意 hints 若把所有輸出都標成未花費，就可能耗盡記憶體。開發者稱 1 Gbps 以下連線的峰值通常低於 300 MB。
與既有做法差在哪裡
Bitcoin Core 的 assumevalid 同樣會略過舊區塊的簽名檢查，但仍逐塊依序維護完整 UTXO 資料庫；Floresta 過去的 Utreexo 同步則省掉資料庫、改下載大量證明。新路徑同時拿掉兩者的主要成本：不維護大型 UTXO 資料庫、也不下載舊歷史的存在證明，並允許平行處理區塊。
代價是信任模型多了一層：hints 檔目前可從 2140-dev 的伺服器下載。hints 錯誤時最終總和不會歸零，節點能發現，但開發者也承認在發現之前，錯誤 hints 可能先拖垮記憶體。此外 witnessless 模式意味著節點沒有親自看過舊見證資料，開發者主張這與修剪節點不重做 IBD 的模型相同。
AI 觀點分析與推論
AI 觀點：真正的改變是「輕節點不必再選邊」
我傾向認為這次合併最重要的意義，不是 19 分鐘這個漂亮數字，而是 Utreexo 長期最大的缺點被拿掉了。過去選 Utreexo 等於用頻寬換硬碟：省下 UTXO 資料庫，卻要多下載約一倍的資料，對網速一般的家用使用者並不划算。若隱式刪除在主網長期穩定，低儲存的手機、單板電腦或錢包內嵌節點，就有機會用接近甚至低於 Core 的下載量完成同步。
受益者是想自己驗證、但不想維護大硬碟的錢包與家用使用者；壓力則落在 hints 的生產與分發。如果 hints 長期只由少數伺服器提供，這會變成新的單點，即使它在數學上無法讓節點接受錯誤狀態，也能拖慢或擊垮同步。反面情境是：快取上限與續傳遲遲無法做好，功能就只適合高網速、不中斷的機器，難以進入一般用戶的正式版。
下一個會讓我修正判斷的訊號有三個：正式版本是否預設啟用、是否有獨立團隊重現同步時間與記憶體峰值，以及完全驗證版 SwiftSync 能否在不依賴 assume-valid 的情況下維持同樣的頻寬優勢。
接下來可觀察的事
短期內可觀察 Floresta 下一個正式版本是否納入此功能，以及追蹤議題中續傳、locktime 檢查與快取上限等項目的進度。讀者若要試用，應理解它目前是主分支功能、仍採 assume-valid 與 witnessless 假設，不宜當成已完成第三方審查的正式產品。
