Resolv 駭客事件及其未吸取的教訓 這次的損失完全是 Resolv 本身造成的，而且本來可以避免。 Resolv 5000 萬美元 + 3000 萬美元的增發是“未經授權的”，這意味著其私鑰被洩露，就像朝鮮式的黑客攻擊。這種「泡菜溢價」本來可以輕鬆避免。這不是市場失靈、價格下跌或抵押品貶值造成的。這完全是無能造成的，是典型的搬石頭砸自己的腳。 自 2013 年比特幣引入多重簽名以來，13 年來我們一直知道如何避免私鑰被未經授權使用： - 首先不要使用私鑰，而是使用多重簽名錢包 - 使用額外簽名保護的硬體安全模組 (HSM) 但 Resolv 為什麼要這麼做呢？這其實並不複雜。 導致未經授權的原因 「SERVICE_ROLE 是 Resolv USR 協議合約中的一個特權角色（兩階段請求/完成鑄幣/兌換流程的一部分）。Resolv 沒有提供任何詳細的官方文件來解釋其用途、安全模型、分配流程或風險。無論是公開的精簡版文件、用戶文件 (|_2024111120230_HubADS4411111202304111120230)」。 （Grok 引述） 經過 18 次審計 為什麼 Resolv 在多次審計後仍然沒有發現這個問題？因為除了像 @sherlockdefi 這樣的少數例外，審計人員並不關心專案是否被駭客攻擊。他們對已部署的系統不承擔任何責任。他們沒有切身利益。他們只關心現金報酬，以及「代碼看起來沒問題」。 即便如此，所有這些審計人員仍然未能指出這個顯而易見的問題。我們有一個可以無限量鑄造我們穩定幣的服務角色，但沒有任何文件記錄。 拜託！ “系統裡有這麼個無所不能的私鑰”，但只要你付給我們一點費用，你的軟體就沒問題，我們不在乎之後會發生什麼。只要別持有不當就行，好嗎？ Coinbase 投資，Steakhouse 讚譽 布萊恩的認可也無濟於事。 就在六天前，Steakhouse 在他們的《Steakhouse Financial Insights》中寫道： “在運營方面，Resolv 通過第三方託管、多預言機冗餘和程序化安全措施展現了機構級的嚴謹性。Resolv 迄今為止運行良好，並且在不利條件下展現了自我糾正能力。” kitchen.steakhouse.financial/p... 這種說法太籠統了，簡直可以當成 ISO 9001 品質審核報告，因為它根本沒提到實際的系統、流程及其特性。 “我和他們一起吃了頓午飯，喝了一杯法國紅酒後，我就確信這套系統沒問題了。” 第三方託管？這難道意味著他們用了 Fireblocks 來保護私鑰嗎？一個由前摩薩德特工編寫的私鑰錢包仍然是一個私鑰錢包，而且風險更大，因為密鑰很可能直接被你的閉源軟體即服務提供商竊取，你根本無法知道他們的軟體內部究竟有多糟糕。 如何避免未來重蹈覆轍？ 其實並不難。尤其是在擁有 1000 萬美元種子資金，並且最高投資額達到 5 億美元的情況下，完全可以做得更好。 1. 降低私鑰權限 2. 使用利害關係人審計員 3. 保持透明並遵循去中心化金融 (DeFi) 的發展方向 身為 DeFi 用戶，您如何避免這些事件？ 這是一個棘手的問題。 問題在於底層智慧合約是用 Solidity 編寫的，這是一種拼湊而成的自研語言。 Solidity 智能合約的安全特性很難評估。雖然有更好的語言，但我們似乎只能繼續使用傳統的 Solidity。儘管 Solidity 的缺陷眾所周知，但很少人真正努力改善它的安全性，例如忽略事件本身，或花錢請人從語言層面找出這些漏洞。 人工智慧將大有幫助。由於我們無法追究安全審計員的責任（他們的信譽似乎與駭客攻擊無關），因此未來的出路似乎是取消安全審計員。在不久的將來，任何人都可以將人工智慧代理指向一個複雜的已部署智慧合約系統，它會給出「贊成」或「反對」的報告。 關於這一點，我已經在這裡做了一個小型試點項目 github.com/tradingstrategy-ai/...…，Claude Code 成功地從我們合作夥伴的系統中，在一個已部署的智能合約上找到了一個不應該存在的特權私鑰。 附註：對於硬體安全模組 (HSM)：您沒有任何其他商業化的不透明方案來保護您的關鍵私鑰。如果您正在建立需要鏈下高度可信任私鑰的安全關鍵型智慧合約系統，您可以使用 Google Cloud。 這是我們為 Google Cloud 提供的免費開源以太坊簽名模組：web3-ethereum-defi.tradingstra...… - 只需記住相應地設定組織策略即可。 感謝 @zacodil 和 @omeragoldberg 的研究。