這起事故跟一般的智能合約漏洞攻擊，本質上有什麼不同？
多數智能合約漏洞（例如重入攻擊）發生在單一合約的邏輯裡，通常可以透過仔細的程式碼審計找出來，因為問題就是「這段邏輯寫錯了」。Liquid 這次的漏洞不同之處在於，它不是單一一行程式碼寫錯，而是一個效能優化手段（快取機制）在設計時遺漏了部分上下文資訊，這個遺漏本身在正常情況下完全不會造成問題——直到有人刻意構造出位元層級的碰撞，讓系統誤判兩筆不同的交易是同一筆。
這也解釋了為什麼這個漏洞能潛伏八年：它不是「功能壞了」，而是「功能在絕大多數情況下都正常運作，只有在極特定的位元組合下才會出錯」，這種類型的漏洞對標準審計流程來說特別難以發現，因為審計通常測試邏輯是否符合預期行為，而不會窮舉所有可能的位元組合。
攻擊者在事後歸還了 3,400 顆比特幣並自稱「白帽」，這改變了這起事故的性質嗎？
從資金流向的結果來看，部分歸還確實降低了實際損失金額（從約 3.19 億美元降到約 4,800 萬美元左右的未歸還部分），但這不代表這起事故可以被重新定義成一次「善意的漏洞揭露」。真正的白帽行為，通常是在不實際執行攻擊的前提下，私下向專案方回報漏洞；這次攻擊者是先完整執行了鑄造無抵押資產、提領真實比特幣的整套流程，取得了實際控制權之後，才選擇歸還大部分資金。
這種「先拿到手、再部分歸還」的模式，近年在多起鏈上事故中重複出現，通常被歸類為攻擊者在發現自己的身份可能被鏈上足跡追蹤、或面臨法律與聲譽風險後，採取的風險管理策略，而不是單純的善意之舉。從讀者角度看，無論攻擊者事後動機如何，協議方在漏洞被實際利用之前，顯然沒有機制可以攔截這類交易，這才是真正該被檢視的問題。
8 月初就已經回報並修補了 Bug A，為什麼修補動作本身反而製造出 Bug B，而且沒有人注意到？
這正是這起事故裡最值得深思的一層：修補一個已知漏洞的過程，本身引入了新的漏洞。8 月 3 日的修補動作，解決了「快取鍵值遺漏關鍵欄位」這個問題，做法是把遺漏的欄位加回去——但加回去的方式是直接位元串接，而不是帶長度前綴的序列化。這兩種做法在「大多數情況」下產出的結果是一樣的，差別只有在特定的邊界條件下才會顯現，也就是當不同的欄位組合，剛好能排列組合出完全相同的位元組序列時。
這類問題通常被稱為「長度前綴混淆」（length-prefix confusion），是序列化與雜湊設計裡一種經典但容易被忽略的陷阱——因為修補當下的焦點通常放在「有沒有解決回報的那個具體問題」，而不是「這個修補方式本身有沒有引入新的邊界情況」。9 月 1 日修補公開合併後，直到 9 月 6 日才被利用，中間這段時間沒有人發現，說明這類位元層級的碰撞漏洞，即使程式碼本身是公開透明的，也不代表會被及時發現。
我沒有直接持有 L-BTC，但如果我用的協議裡接受某種包裝資產作為抵押品，這起事故跟我有關係嗎？
有關係，而且是間接但真實的曝險。如果你使用的借貸或衍生品協議接受某種包裝比特幣（不論是 WBTC、L-BTC 或其他變體）作為合格抵押品，而這個包裝資產的底層驗證機制出現類似漏洞，攻擊者理論上可以用同樣的手法鑄造無抵押的包裝資產，再拿去你所使用的協議裡借出其他資產——這會製造出協議層級的壞帳，而壞帳通常由所有存款人共同承擔，不只是直接持有該包裝資產的人。
實際檢查方式：查詢你使用的協議，確認它接受哪些包裝資產作為抵押品，並查這些包裝資產各自的技術文檔，確認其鑄造與贖回驗證機制上一次公開稽核或安全事件是什麼時候。包裝資產的種類越多、底層實現越不透明，協議整體面臨這類「驗證邏輯漏洞」的潛在曝險就越分散且難以追蹤。
2026 年 9 月 6 日，由 Blockstream 營運的比特幣側鏈 Liquid Network 遭到攻擊，約 3,998.5 顆沒有任何真實比特幣支撐的 L-BTC（Liquid Bitcoin）被憑空鑄造出來，其中約 3,996.02 顆比特幣在幾十分鐘內被提領到比特幣主鏈，總價值約 3.19 億美元。這起事故並非包裝資產信任結構被突破的典型案例（例如多簽金鑰遭竊），而是一個隱藏在開源程式碼裡長達八年的邏輯漏洞，在今年 9 月因為另一次修補動作意外被重新激活。
Liquid 是一個營運中的比特幣側鏈，由 15 個分散在全球的「功能節點」（functionary node）共同治理，任何區塊驗證需要至少 11 個節點聯合簽署才能通過。使用者把比特幣鎖定在主鏈上，就能在 Liquid 鏈上取得對應的 1:1 L-BTC（這個動作叫做 peg-in）；反過來銷毀 L-BTC，則能透過聯盟的「提領授權金鑰」（PAK，Peg-out Authorization Key）機制，在比特幣主鏈上釋放對應的比特幣（這個動作叫做 peg-out）。PAK 機制本身採用雙金鑰設計：一把離線金鑰負責驗證資金要匯往的目的地位址是否合法，另一把上線金鑰負責授權誰可以執行提領——這整套設計的前提是，Liquid 鏈上每一顆 L-BTC 背後，都確實對應著主鏈上被鎖定的等量比特幣。
根據 Blockstream 官方的事故分析報告，問題源頭其實是 2018 年就存在的程式碼簡化：Liquid 節點在驗證交易裡的金額範圍證明（range proof，一種加密技術，用來證明交易金額落在合法範圍內而不洩漏實際數字）時，會把驗證結果快取起來以提升效能，但當時設計快取鍵值時，漏掉了資產承諾（asset commitment）與目標位址腳本（scriptPubKey）這兩項關鍵資訊。這意味著一筆交易的驗證結果，可能被錯誤套用到另一筆本應被拒絕的交易上——只要兩者的快取鍵值恰好相同。2026 年 8 月 2 日，外部研究者 stutxo 向 Blockstream 回報了這個根本漏洞，團隊於 8 月 3 日迅速部署修補，做法是把缺失的欄位直接串接進快取鍵值的計算裡。問題在於，這次修補採用的是「直接位元串接」而非「帶長度前綴的序列化」，這留下了第二個漏洞：只要攻擊者能構造出經過調整長度的 range proof 跟對應腳本，讓兩者位元串接後產生的位元組，恰好跟另一筆合法交易完全相同，就能讓驗證結果發生碰撞，使一筆本應被拒絕的無效交易被誤判為合法。
9 月 6 日 13 時 53 分 10 秒（UTC），攻擊者利用這個位元碰撞漏洞，在區塊高度 4,050,336 鑄造出約 4,000 顆沒有真實比特幣支撐的 L-BTC。攻擊者先用 2.5 顆 L-BTC 進行小額測試，透過第三方服務 SideSwap 的提領功能確認資金能順利轉出；確認可行後，於 14 時 05 分把約 4,000 顆無抵押 L-BTC 存入 SideSwap 的提領服務。14 時 28 分 56 秒，Liquid 聯盟節點依照正常流程處理了這筆提領請求，在比特幣主鏈區塊 965,783 釋出約 3,996.02 顆真實比特幣——從鑄造到主鏈資金被提走，整個過程不到 35 分鐘。Blockstream 在 18 時 26 分發現異常並緊急暫停橋接節點，但此時資金已經流出。值得一提的是，攻擊者在 18 時 30 分於鏈上留言：「我們是白帽，請透過鏈上訊息聯繫我們」，隔天（9 月 7 日）16 時 09 分便主動歸還了 3,400 顆比特幣，目前仍有約 602 顆比特幣尚未收回。
Blockstream 於 9 月 7 日凌晨部署緊急過渡修補，9 月 8 日合併了徹底強化的修復方案（Elements PR #1600），改用帶長度前綴的序列化方式計算快取鍵值，確保不同的交易輸入組合，不會再產生相同的快取鍵值位元組；9 月 9 日清晨發布 Elements v23.3.4 正式版本，同日晚間 Liquid 鏈恢復產出區塊。恢復過程中，團隊透過停用快取機制重新驗證交易，確定性地找出了兩筆原始的無效輸出及其衍生的四筆後續交易，並據此重建正確的鏈上狀態。Liquid 的比特幣儲備一度從約 4,205 顆驟降至 197 顆，在攻擊者歸還 3,400 顆後回升，剩餘約 602 顆比特幣的追回工作仍在進行。
如果你持有任何形式的包裝資產（不只是 L-BTC，WBTC 或其他鏈上包裝資產都適用同樣的邏輯），這起事故提醒你，「這個包裝資產有沒有被駭」跟「包裝資產的信任結構建立在什麼技術基礎上」是兩個分開的問題。多簽金鑰被竊取、或治理權限被社交工程手法騙取，是過去多數包裝資產事故的共同模式；但這次完全不同——程式碼邏輯本身正確執行了它被設計要做的事，只是驗證機制裡一個八年前的簡化決定，留下了一道後來才被發現的縫隙。下次評估一個包裝資產時，除了看它的多簽治理架構，也值得問一句：這個資產的鑄造與贖回驗證邏輯，上一次經過獨立的程式碼稽核是什麼時候？