Bybit 事件跟過去常見的「智能合約漏洞被利用」型駭客事件，本質上有什麼不同？
過去大多數重大駭客事件（例如 DAO Hack、各類 DeFi 協議的閃電貸攻擊），攻擊者利用的是合約程式碼本身邏輯上的漏洞——程式碼被寫錯了，攻擊者找到了讓合約做出非預期行為的方法。Bybit 事件完全不同：Safe 的多簽合約本身沒有任何邏輯缺陷，經過形式化驗證的核心程式碼依然如設計般正確運作。攻擊者繞過的不是合約，而是「人在簽署合約前，如何得知自己正在簽什麼」這一整層資訊管道。
這個差異很關鍵，因為它意味著「合約有沒有通過審計」這個問題，對這類攻擊完全答非所問——審計驗證的是程式碼邏輯是否符合預期，但沒有任何審計範圍涵蓋「簽名者看到的介面是否忠實呈現了合約要求」這件事，這兩者是完全獨立的信任鏈。
為什麼像 Bybit 這樣資源充足的大型交易所，也會依賴第三方服務商來管理多簽錢包，而不是自己開發？
多簽錢包的密碼學邏輯本身並不複雜，但把它包裝成一套讓多位簽名者能安全、方便地日常操作的介面系統，牽涉大量的工程與安全投入——包括交易模擬、異常偵測、跨裝置同步等功能。Safe（前身為 Gnosis Safe）之所以成為以太坊生態系最主流的多簽方案，正是因為它把這套基礎設施做到了業界公認的成熟水準，讓機構不需要重新造輪子。
但這也造成了一個結構性風險：當整個產業高度集中依賴少數幾家基礎設施供應商時，這些供應商本身就成了單一故障點——攻擊者不需要逐一攻擊每一家使用 Safe 的機構，只要成功入侵 Safe 自身的開發環境，就能同時對所有依賴這套介面的客戶造成影響。這也是為什麼事件後，「不能只信任供應商的安全聲譽，還要有獨立於供應商之外的驗證層」成為業界討論的重點。
如果連 Bybit 這麼有經驗的團隊都被騙過去，一般機構或個人有什麼具體可行的方式，能真的防住這類介面層攻擊？
業界目前討論的做法主要有三類，重點都在於「不要只依賴同一套介面來產生和核對交易內容」：第一是交易前模擬，用一套與主要簽署介面完全獨立、來源不同的工具，重新模擬這筆交易實際會執行的內容，如果模擬結果跟簽署介面顯示的不一致，這本身就是警訊；第二是硬體裝置上的原始資料核對，部分硬體錢包能顯示交易的原始呼叫資料而非只是介面產生的摘要說明，訓練簽名者實際去讀懂這些原始資料，而不是只看「看起來合理」的摘要；第三是前端程式碼的供應鏈管控，對簽署介面所依賴的每一個前端套件與雲端服務存取權限進行審查，把介面本身也當成攻擊面的一部分來管理，而不是預設信任。
對一般個人而言，這些機構級的做法不一定能完整複製，但核心原則相通：任何要求你簽署交易的畫面，都應該被當成有可能被竄改的資訊來源，尤其是金額較大的操作，值得用第二個獨立管道（例如官方 App、區塊鏈瀏覽器）交叉核對一次。
我沒有在使用多簽錢包，這起事件跟一般個人投資者有什麼實際關聯？
即使你只是用一般的軟體或硬體錢包簽署日常交易，Bybit 事件揭露的核心風險模式跟你完全相關：你在簽署任何交易前所看到的畫面——不管是錢包 App 彈出的確認視窗，還是硬體錢包螢幕上顯示的摘要——都是由某一層軟體產生的，而這層軟體本身可能遭到入侵。這正是市面上愈來愈多錢包主打「交易模擬」（transaction simulation）功能的原因：在你簽署前，額外用一個獨立的來源告訴你「這筆交易實際上會讓你的錢包發生什麼變化」，而不只是顯示介面自己宣稱的內容。
具體到日常操作，這代表面對任何要求簽署的請求，尤其是牽涉大額資產或不熟悉的智能合約互動時，值得養成兩個習慣：一是優先使用有內建交易模擬功能的錢包（例如能顯示「簽署後你的資產會如何變化」的預覽），二是對於金額特別大的操作，透過官方管道或區塊鏈瀏覽器另外核對一次收款地址，不要只依賴單一介面顯示的內容做出最終判斷。
2025 年 2 月 21 日，Bybit 執行一筆原本應該再平常不過的操作：把約 40 萬枚 ETH 從冷錢包轉往熱錢包，供日常提領使用。三名簽名者依照標準流程，在介面上核對收款地址、金額，逐一完成簽署。畫面顯示的一切都正確——除了畫面本身早已被竄改。等交易在鏈上執行完畢，Bybit 才發現這筆「例行轉帳」實際上把超過 40 萬枚 ETH 與 stETH（市值約 15 億美元）送進了攻擊者控制的地址，成為加密貨幣史上最大單一竊案，攻擊者被高度歸因為北韓國家駭客組織 Lazarus Group。
這起事件最違反直覺的地方，是多重簽名錢包本身的密碼學邏輯完全沒有被破解。Bybit 的冷錢包使用 3-of-6 多簽架構，理論上需要六位簽名者中的三位分別核准才能動用資金，這正是業界公認能防止單點失守的標準做法。問題出在 Bybit 用來管理這組多簽錢包的第三方介面服務商 Safe{Wallet}——攻擊者入侵了 Safe 開發人員的環境，取得其雲端儲存服務的存取憑證，並將惡意 JavaScript 程式碼植入 Safe 前端用來管理交易簽署介面的檔案裡。這段程式碼被設計成只在偵測到符合特定條件的交易時才啟動偽裝，平常保持沉默，讓例行的安全檢查很難察覺異狀。
當 Bybit 的簽名者依照排定流程準備執行這筆轉帳時，被植入惡意程式碼的介面在螢幕上顯示的收款地址與交易內容，跟三位簽名者實際簽署的鏈上內容完全不同。真正被送出的交易呼叫了 Safe 合約裡的 upgradeTo 函式，把整個多簽錢包背後的邏輯合約替換成攻擊者部署的惡意合約，等同把整組錢包的控制權限直接轉交出去。三位簽名者依照公司規定核對了畫面上的地址與金額，流程本身沒有任何一步被跳過，只是他們核對的畫面，從一開始就是假的。
這種攻擊手法在業界被稱為盲簽（blind signing）或介面詐騙攻擊——多簽制度的安全保證，建立在「簽名者能夠準確判讀自己正在核准什麼」這個前提之上，一旦簽名者賴以判讀的介面本身遭到入侵，這個前提就會直接崩潰。值得特別說明的是，Bybit 使用的 Safe 多簽合約本身經過業界公認嚴謹的形式化驗證，多年來核心邏輯未曾在協議層級出現重大漏洞——這起事件從頭到尾都不是合約程式碼被攻破，而是簽名者用來「看懂」合約要求他們做什麼的那層介面被動了手腳。鏈上看到的一切，包括足額的簽名數量與正確的呼叫格式，全都完全合法；區塊鏈本身沒有任何理由懷疑這是一筆惡意交易，因為就密碼學層面而言，它確實是一筆完整簽署的合法交易。
事發後，Bybit 執行長趙長鵬（Ben Zhou）迅速在社群媒體上公開說明狀況，並在事發後三天內，透過與 Galaxy Digital、Wintermute、FalconX 等機構的橋接貸款、鯨魚存款與場外交易，籌措超過 12 億美元的 ETH 補足資金缺口，恢復完整的儲備覆蓋率，並於事發後約 12 小時內恢復正常提領服務。這個應對速度之所以能夠實現，很大程度是因為 Bybit 在事發初期選擇公開承認損失規模、同步發布獨立稽核機構的儲備證明報告，而不是先隱瞞觀望——這也是為什麼這起事件常被拿來跟其他曾試圖淡化損失、結果引發用戶信心進一步崩潰的交易所案例做對比。攻擊者則將竊得資產迅速兌換成不受任何發行方凍結權限影響的原生 ETH，分散進約 50 個各持有一萬枚 ETH 的錢包，在接下來九天內逐一洗出，鏈上偵探與多家分析機構持續追蹤其後續流向。
Bybit 事件之後，多簽錢包產業開始更嚴肅地討論「介面層」本身該如何被獨立驗證——包括要求簽名者在簽署前使用與主要簽署介面完全獨立的工具重新模擬交易內容、在硬體裝置上直接核對原始交易資料而非只看螢幕呈現的摘要說明、以及對前端程式碼的每一次更新採取多方審查。這些做法背後的共同邏輯是：不能再假設「介面顯示的內容 = 你實際簽署的內容」，這個等式必須被主動驗證，而不是被動信任。
如果你是一般用戶，Bybit 事件最直接的啟示是：多簽錢包、硬體錢包、審計通過的智能合約，這些安全機制加總起來，防的是駭客直接破解密碼學或竊取單一私鑰，卻不必然防得住「你看到的畫面被動了手腳」這種攻擊路徑。無論是交易所的多簽簽名者，還是你自己在硬體錢包上核准一筆交易，關鍵防線都在於：你核對的內容，是不是真的來自你信任的裝置或獨立來源，而不是任何可能被竄改的中間層介面。下次你在錢包彈出視窗按下「確認」之前，多問一句「我看到的這串資訊，是誰產生的、能不能被獨立核實」，會比單純依賴多簽或審計報告的名聲更實際。