# 多簽為什麼仍有單點故障？Ronin 的 5 of 9 如何被湊齊 > Ronin 2022 的 5 of 9 顯示，4 把金鑰與未撤銷的 allowlist 可以讓同一環境取得足夠簽章。本文依官方記載檢查控制權如何集中，並為多簽設計提出可執行的驗收條件。 原文：https://sheng.page/posts/multisig-still-a-single-point-of-failure/ · 發布：2026-11-03 · 作者：Sheng 5 of 9 的多簽，不保證攻擊者得攻破五個獨立對象。Ronin 的官方公告與事後報告記載，2022 年 3 月的攻擊者從 Sky Mavis 的環境取得足以偽造提款的簽章：9 把 validator 私鑰中的 5 把受到控制，4 把屬於 Sky Mavis，1 把屬於 Axie DAO。設計多簽時，除了金鑰數，也要看單一環境失陷後，攻擊者能取得多少簽署權。 本文以 Ronin 為主，搭配 Harmony Horizon 與 BNB Token Hub，分別看簽署權失守與證明驗證出錯的情況。設計建議都附驗收條件：假設某個環境已被攻破，檢查攻擊者還能拿到哪些權限。幣安 2026 的簽署授權只作補充，公開資料不足以還原它的完整入侵路徑。 ## Ronin 2022：攻擊路徑與後續調整 Ronin 官方 X 在 2022 年 3 月 29 日 15:29 UTC 宣布安全事件，第二則寫 Ronin bridge 被提走 173,600 Ethereum 與 25.5M USDC，bridge 與 Katana Dex 已暫停。 同日的〈Community Alert: Ronin Validators Compromised〉（Wayback 2022 年 3 月 29 日 22:08 快照）記載：Ronin 鏈當時有 9 個 validator 節點，要承認一筆存款或提款事件需要 9 個簽章中的 5 個；攻擊者取得了 Sky Mavis 的 4 個 Ronin validator，以及 Axie DAO 營運的一個第三方 validator 的控制權。發現經過是 3 月 29 日有使用者回報無法從橋提出 5k ETH。短期處置是把 validator 門檻從 5 提到 8，節點數仍是 9。同一篇當時寫多數被盜資金仍在攻擊者錢包，並給出地址。 4 月 27 日的〈Back to Building: Ronin Security Breach Postmortem〉（Wayback 2022 年 12 月 6 日快照）補充了時間與入口：攻擊發生在 3 月 23 日，3 月 29 日才被 Sky Mavis 團隊發現，原因是當時沒有監控橋大額流出的系統；Sky Mavis 員工長期受到進階的 spear-phishing，一名員工失陷，攻擊者藉此進入 Sky Mavis 的 IT 基礎設施，取得 validator 節點的存取權，該員工已離職。 這篇也寫 9 把私鑰中 5 把受控，其中 4 把屬於 Sky Mavis、1 把屬於 Axie DAO，攻擊者用這些簽署權偽造提款。報告記載的是控制權失守，沒有說明私鑰是否被匯出。 攻擊到發現隔了六天。Community Alert 說團隊收到使用者無法提出 5k ETH 的回報後才發現事件，Back to Building 則說當時缺乏大額流出監控。 Community Alert 的正文說明了第 5 個簽章的路徑。Sky Mavis 在 2021 年 11 月因使用者負載龐大，請 Axie DAO 幫忙分發免費交易，Axie DAO 因此將 Sky Mavis 加入 allowlist，允許它代簽。業務在 2021 年 12 月停止，存取權卻未撤銷，攻擊者取得 Sky Mavis 系統的存取權後，便透過 gas-free RPC 節點取得 Axie DAO validator 的簽章。 短期處置與後續擴充要分開看。Community Alert 的短期動作是門檻從 5 提到 8。Back to Building 的擴充段落寫「Sky Mavis 有 9 個 validator 節點」，但 Community Alert 寫的是 Ronin 全鏈有 9 個，同篇 postmortem 也寫 Sky Mavis 當時控制 4/9 validators，不能把這句讀成它持有全部金鑰。擴充段落接著寫，節點已增至 11，即將再加 3 個，三個月內目標 21 個，長期目標超過 100 個。 4 月 5 日的〈Securing Ronin〉寫正在讓 Nansen、Delphi Digital、Stable Node、Animoca Brands、Dialectic 加入 validator 節點池，三個月內目標是至少 21 個獨立的 validator 節點共同保護網路。文件沒有列出擴充後的完整控制權分配，加入名單也不能用 9 加 5 算成已上線的 14。 Back to Building 預期橋會在 5 月中下旬重開，前提是進度順利；實際重啟公告是 6 月 28 日的〈[The Ronin Bridge Is Open](https://blog.roninchain.com/p/the-ronin-bridge-is-open-)〉，文中寫開放前完成一次內部稽核，以及 Verichains 與 Certik 兩次外部稽核。當時公告的提款分級要求分別為 70%、90%，以及 90% 加人工審查，最後一級另須經過 7 天審查流程。公告也設了初始每日上限，但管理員可提前重設，Tier 3 則不計入，金額與例外見設計建議第 3 條。 治理方面，governor 可投票增刪 validator、升級合約或調整門檻，一次投票完成後才能開始下一次。公告把 governor 比作 cold wallet、validator 比作 hot wallet，這是角色類比，無法據此判斷金鑰實際存放在哪裡。 Ronin Docs 的〈[Withdrawal limits](https://docs.roninchain.com/apps/ronin-bridge/withdrawal-limits)〉以代幣種類與數量分級，和 6 月 28 日的美元規則分開閱讀。文件說，數量愈大，需要愈多 bridge operator 核准；Tier 3 要人工審查，費用約 0.001%，且不計入每個代幣的每日上限。以下是頁面列出的兩種代幣，單位都是代幣數量。 | 代幣 | 每日上限 | Tier 1 | Tier 2 | Tier 3 | |---|---:|---:|---:|---:| | WETH | 4,500 | 小於 1,000 | 大於等於 1,000 | 大於等於 4,000 | | USDC | 2,500,000 | 小於 1,000,000 | 大於等於 1,000,000 | 大於等於 2,000,000 | 頁尾標示最後更新於 2026 年 5 月 12 日，本文未核對鏈上參數是否與表格一致。 歸因也各有出處。Back to Building 寫 FBI 把這次事件歸因於北韓的 Lazarus Group，財政部制裁了收款地址。FBI 2022 年 4 月 14 日的聲明原文是，Lazarus Group 與 APT38 對 3 月 29 日公布的 6.2 億美元 Ethereum 盜竊負責，聲明沒有寫 Ronin、Axie 或 173,600 ETH。 財政部 2022 年 5 月 6 日的新聞稿寫，2022 年 3 月 23 日 Lazarus Group 從一個與線上遊戲 Axie Infinity 有關的區塊鏈專案竊取接近 6.2 億美元，Blender 處理了其中超過 2,050 萬美元；新聞稿正文沒有出現 Ronin 這個詞，也沒有印出十六進位地址。 OFAC 2022 年 4 月 14 日的制裁更新把 ETH 地址 `0x098B716B8Aaf21512996dC57EB0615e2383E2f96` 加到 LAZARUS GROUP 名下，這個地址與 Community Alert 給的攻擊者錢包相同，只差大小寫；那一頁是地址清單，沒有把事件稱為 Ronin。 Back to Building 說 Sky Mavis 委託了 CrowdStrike 與 Polaris Infosec 處理內部監控與鑑識，這是 Sky Mavis 對委託關係的說明。 ## 把九把鑰匙畫成控制圖 把 9 把金鑰按「哪個環境失陷後能取得簽章」分組。依公告正文，從 Sky Mavis 的環境可取得自家 4 個 validator 的簽署權，再經 gas-free RPC 節點與 allowlist 取得 Axie DAO 的簽章，合計 5，達到門檻。剩下 4 個 validator 未列入這段入侵路徑；「5 等於 4 加 1」說明的是公告已揭露的控制關係，不能證明其餘節點未受影響。 ![Ronin 2022 的控制圖：攻擊者以進階 spear-phishing 讓 Sky Mavis 一名員工失陷，官方寫攻擊者利用該存取進入 IT 基礎設施並取得 validator 節點；Sky Mavis 環境的存取權讓攻擊者控制四個 validator，並使用 gas-free RPC 節點，RPC 節點經 2021 年 11 月設立、12 月停用但未撤銷的 allowlist 取得 Axie DAO validator 的簽章，五個簽章湊齊 5 of 9 門檻，偽造提款 173,600 ETH 與 25.5M USDC；資產在 3 月 23 日轉出，3 月 29 日才發現，官方說明當時沒有大額流出監控](/images/multisig-still-a-single-point-of-failure/five-of-nine.zh.png) 圖上的環境代表入侵後可取得的權限，不表示所有節點都放在同一台主機。員工到 IT 與 validator 節點之間只畫一條連線，因為官方對 4 把金鑰受控的細節只寫到這裡。 allowlist 保留了代簽權，讓 1 個環境可取得的簽章達到 5 個。業務需求在 2021 年 12 月結束，權限卻仍有效，驗收代簽關係時就得檢查它何時到期、到期後是否確實拒絕請求。 多簽錢包從事先指定的 n 把金鑰中取得至少 m 個有效簽章，交易才能成立，m of n 的 m 就是門檻。金鑰增加，不代表控制它們的組織也增加。門檻密碼學則可把同一把金鑰分成 n 份，至少 t 份共同參與簽章，不必先重組完整私鑰；Ronin 文件描述的是多個簽章與私鑰，不能直接改稱秘密分享。單點故障指某個元件失效就足以讓系統無法正常運作，本文關心的是會讓簽署權一起失守的共同依賴。 共同原因可能讓多個元件一起失效，不能假設它們的故障彼此獨立。若兩個元件總是一起失效，增加備援也不會降低共同失效的機率。百科條目 [Common cause and special cause (statistics)](https://en.wikipedia.org/w/index.php?oldid=1381012247#Common_mode_failure_in_engineering) 的 Common mode failure 節用這個角度說明問題，但該節標有「可能包含原創研究」，這裡只作背景。套用到多簽，本文的設計檢查是：提高簽章門檻後，同一營運者或共用核准路徑是否仍能取得足夠簽章。實體隔離可減少共用環境造成的風險，還得另外檢查權限是否相通。 職務分離則要求多人參與，將授權、保管、紀錄與核對分開。百科條目 [Separation of duties](https://en.wikipedia.org/w/index.php?oldid=1378917027) 引述 Botha 與 Eloff 在 IBM Systems Journal 2001 的文章，以支票須有兩人簽名為例。這裡只用百科頁內的引述，未另核 IBM 原文或 NIST SP 800-53 的 AC-5。對多簽設計而言，仍要檢查這些角色是否由同一環境控制，不能只看角色名稱；Ronin 公告的 governor 與 validator 分工也適用這項檢查。NIST CSRC 的 [Multi-Party Threshold Cryptography](https://csrc.nist.gov/projects/threshold-cryptography) 專案頁則說明，門檻方案用 MPC 分散密碼學運算所需的信任，這是技術範圍的說明。 ## 多鏈與多個服務的共同依賴 同一套簽署系統替多條鏈的熱錢包簽章時，增加鏈的數量未必增加控制權的獨立性。幣安 2026 有一段相關的公開觀察。Chainalysis 2026 年 10 月 30 日的文寫，在 Ethereum 上，攻擊者用一個經 Tornado Cash 注資的操作錢包送出有效的簽署授權，讓幣安的一個熱錢包執行攻擊者部署的程式碼；這段描述限於 Ethereum，沒有寫一套簽署端跨多條鏈，也沒有寫其他鏈的授權怎麼取得。這份鏈上觀察不能證明幣安共用一套簽署端，簽署端的授權檢查可參考〈[保住私鑰之後，誰有權要求系統簽章：從 2019 年幣安事件看託管簽署的授權邊界](/posts/who-can-ask-the-signer-to-sign/)〉。 RPC、relayer、簽署端與監控即使分成不同服務，只要其中一個握有另一個的代簽權或憑證，入侵仍可能沿著這條權限跨過去。Ronin 官方記載的 gas-free RPC 節點成了取得第 5 個簽章的路徑。簽署前端與供應鏈的另一種風險，見〈[簽章都正確，交易為何還是錯的：Bybit 與 Safe 的簽署供應鏈](/posts/bybit-safe-signing-supply-chain/)〉。 Ronin 後續增加節點，9 增至 11，目標 21。8 月 17 日的〈[New Ronin Validators!](https://blog.roninchain.com/p/new-ronin-validators)〉列出三個新 validator：Efficient Frontier、Community Gaming、Nansen，總數 17；9 月 9 日〈[Google Cloud Ronin Network Validator](https://blog.roninchain.com/p/sky-mavis-adds-google-cloud-as-ronin)〉引述 Sky Mavis 共同創辦人 Aleksander Larsen，稱 Google Cloud 為第 18 個 validator。Nansen 在 4 月 5 日的加入名單裡出現過，8 月 17 日又被列為新加入者，兩份公告不能累加計數。這幾份公告沒有完整的組織持有數分配，無法單憑節點增加判斷隔離是否改善。 ## 兩個短對照 Harmony Horizon 2022 年 6 月：Harmony 官方論壇 2022 年 8 月 3 日的摘要寫，攻擊者取得了 bridge validator 四把私鑰中的至少兩把，控制了被橋接的資產，從 2022 年 6 月 23 日 11:06:46 UTC 開始把資產搬進新錢包，最後進 Tornado Cash；Harmony 表示當時沒有證據顯示橋合約或鏈本身被攻破。 原文寫的是「四把私鑰中至少兩把」，沒有把門檻參數寫成 2 of 4；本文範例裡的「4 把、門檻 2」是模型參數，與 Horizon 的官方門檻無關。 Harmony 的 Medium 事故文〈[Harmony's Horizon Bridge Hack](https://medium.com/harmony-one/harmonys-horizon-bridge-hack-1e8d283b6d66)〉在 2022 年 6 月 25 日的 Update #2 轉述創辦人 Stephen Tse：私鑰由 Harmony 加密存放，以 passphrase 與 key management service 雙重加密，沒有單一機器能取得多把明文金鑰。這是調查期間的說法，同一則也寫事件後已把 Ethereum 側的 Horizon bridge 改成 4-of-5 multisig，不能用來反推攻擊當時的門檻。該文承諾調查結束後提供完整說明，但頁面最後一則編號更新是 7 月 14 日的 Update #9，內容是回補方案的規劃進度，尚待提出方案。8 月 3 日的論壇摘要仍以「我們相信」描述入侵路徑，並說木馬的能力還在調查。 2023 年 8 月 3 日的〈[Governance Report: HIP-30v2](https://blog.harmony.one/p/governance-report-hip-30v2-on-25)〉則在說明另一項回收託管提案：Recovery Multisig 規劃採用 5-out-of-7 的 Harmony Gnosis Safe，由選出的保管人持有網路新發行的代幣，每月撥給處理脫鉤資產的 burn partners。這篇仍在邀請投票，不能據此認定安排已落實，也不能把它當作 2022 年橋上金鑰的後續配置。 BNB Token Hub 2022 年 10 月：官方寫攻擊者偽造低階證明，使 200 萬 BNB 被有效鑄出。這份說明指向證明驗證漏洞，沒有描述簽署權失陷的路徑，本文據此檢查驗證程式碼的共同風險。官方 11 月 8 日的技術更新在 BEP171 條目提出將 IAVL 證明驗證升級到 ICS23 規格，兩篇事故文則未使用 IAVL 這個詞。 ## 設計建議與驗收條件 以下是依案例提出的設計建議，驗收條件仍需按實際系統調整。 1. **先查哪些簽章會一起失守。** 把每把金鑰標上「哪個組織、哪套基礎設施、哪個身分系統失陷就能用」，任何共用依賴都要納入失陷範圍，不能只因標籤組合不同就分開計算。Ronin 的 4 把 Sky Mavis 金鑰加 1 個經 Sky Mavis 環境可取得的簽章，都可能因 1 個環境失陷而被取得。驗收：任選一個組織的全部環境（主機、CI、雲帳號、員工裝置）視為失陷，直接或透過代簽權取得的簽章，按金鑰去重後必須少於門檻。 2. **代簽權與 allowlist 要有擁有者與到期日。** Ronin 在 2021 年 11 月為分發免費交易設立 allowlist，12 月停止這項安排後，存取權仍未撤銷。驗收：列出所有「A 可以代 B 簽」的邊，每條有業務理由與到期日；業務停止後跑一次請求，必須被拒絕。 3. **大額提款要有獨立的額外核准。** Back to Building 寫，新橋部署後，這種規模的提款必須有人員介入，並規劃用 validator dashboard 核准大額交易與增刪 validator；4 月 27 日這篇沒有寫金額門檻。分級與每日上限出自 6 月 28 日的〈[The Ronin Bridge Is Open](https://blog.roninchain.com/p/the-ronin-bridge-is-open-)〉：Tier 1 要 70% 的 validator 簽章；Tier 2 金額大於等於 100 萬美元，要 90%；Tier 3 金額大於等於 1,000 萬美元，要 90% 加人工審查，並須經過 7 天審查流程。初始每日提款上限是 5,000 萬美元，每天 00:00 UTC 重設，但當天提早用完時，administrator 可以提前重設，因此它並非無法突破的每日總額。Tier 3 也不計入這 5,000 萬美元上限，公告給的理由是該級已需要行政操作。新橋另有 circuit-breaker，用來暫停可疑的大額提款。後來的代幣數量分級見前文。驗收時，持有門檻數量的金鑰，仍不得在缺少獨立人工核准時提出超過設定上限的金額；如果管理員可重設上限，或有級別不計入上限，就要逐條測試例外。同一失陷環境不得兼有簽署與額外核准的能力，也不得自行重設上限或改寫分級來繞過核准；上限與 kill switch 的故障方向見〈[沒設定就當成零：預設硬上限、four-eyes 門檻與 kill switch 故障方向](/posts/default-hard-caps-and-kill-switches/)〉。 4. **大額流出要有監控，而且監控在簽署者的環境之外。** Ronin 當時沒有大額流出監控，攻擊六天後才由使用者回報發現。驗收：模擬一筆超過閾值的提款，告警在約定時間內送達簽署環境以外的人；簽署環境失陷不能關掉這個告警。 5. **加節點之前先數控制者。** Ronin 從 9 增至 11、目標 21，官方沒有寫每個組織各持幾把。驗收：逐一檢查各組織能取得的簽章；任一組織失陷後可取得的簽章必須少於門檻，排除該組織後，其餘組織仍須足以完成簽署。 6. **驗證邏輯也可能成為單點。** BNB Token Hub 的 200 萬 BNB，官方描述的攻擊路徑是偽造證明。驗收：假設證明驗證函式庫被繞過，單位時間可鑄出或提出的金額仍須受上限限制，這項限制要獨立執行，不能因同一個漏洞而失效。 7. **多鏈共用簽署端時，每條鏈各有自己的政策與上限。** 這是共用簽署端的設計情境，不能拿幣安 2026 的 Ethereum 鏈上觀察來證明它就是入侵根因。驗收：簽署端在一條鏈上簽出授權的能力，不能延伸成其他鏈的無限額轉帳。 ## 範例：算一算失陷後拿得到幾把 下面的 `count_controllers.py` 示範第 1 條驗收的一部分。每把金鑰標示持有環境，再列出代簽關係，輸入失陷的環境集合，就能算出攻擊者可取得多少簽章、是否達到門檻。這是用來比較控制權分配的模型，沒有描述 Ronin、Harmony 或其他鏈的實際金鑰儲存方式。 模型只處理直接金鑰與單層代簽關係，不會追蹤多層授權，也未測試排除某組織後能否繼續簽署，實際驗收仍要補上這些情境。 ```python # 門檻簽章的控制圖模型。 # 每把金鑰標一個持有環境；另有一組「代簽邊」：環境 X 失陷後可取得金鑰 Y 的簽章。 # 輸入失陷的環境集合，輸出可及的簽章數與是否達門檻。 # 這只是模型，用來說明「數金鑰」和「數控制者」會給出不同答案， # 不描述 Ronin、Harmony 或任何一條鏈實際的金鑰儲存方式。 from dataclasses import dataclass, field @dataclass(frozen=True) class Scheme: threshold: int keys: dict[str, str] # 金鑰 -> 持有環境 delegations: frozenset[tuple[str, str]] = field(default_factory=frozenset) # (環境, 金鑰)：該環境可取得這把金鑰的簽章，即使金鑰在別的環境 def reachable(scheme: Scheme, compromised: set[str]) -> set[str]: direct = {k for k, env in scheme.keys.items() if env in compromised} delegated = {k for env, k in scheme.delegations if env in compromised} return direct | delegated def report(name: str, scheme: Scheme, compromised: set[str]) -> None: got = reachable(scheme, compromised) verdict = "達門檻" if len(got) >= scheme.threshold else "未達" print(f"{name}: 失陷 {sorted(compromised)} -> 可及 {len(got)} / 門檻 {scheme.threshold}，{verdict}") # 案例 1：9 把、門檻 5；A 公司持 4 把，B 組織 1 把，其餘 4 把分屬四個組織。 # B 的那把另有一條未撤銷的代簽邊，讓 A 的環境可取得它的簽章。 keys9 = {f"a{i}": "A" for i in range(1, 5)} keys9["b1"] = "B" keys9.update({"c1": "C", "d1": "D", "e1": "E", "f1": "F"}) case1 = Scheme(5, keys9, frozenset({("A", "b1")})) report("案例 1 代簽邊未撤銷", case1, {"A"}) # 案例 2：同設定，代簽邊已撤銷。 case2 = Scheme(5, keys9) report("案例 2 代簽邊已撤銷", case2, {"A"}) # 案例 3：加到 11 把、門檻 6，代簽邊已撤銷，但新增 2 把也放在 A 的環境。 keys11_same = dict(keys9, a5="A", a6="A") case3 = Scheme(6, keys11_same) report("案例 3 加節點但同一環境", case3, {"A"}) # 案例 4：11 把、門檻 6，新增 2 把分屬兩個新組織 G、H，代簽邊已撤銷。 keys11_split = dict(keys9, g1="G", h1="H") case4 = Scheme(6, keys11_split) report("案例 4 加節點且分屬新組織", case4, {"A"}) # 案例 5：4 把、門檻 2，其中 2 把在同一環境。這是模型參數，並非任何一座橋的官方門檻。 case5 = Scheme(2, {"p1": "P", "p2": "P", "q1": "Q", "r1": "R"}) report("案例 5 四把兩把同環境", case5, {"P"}) # 驗收用法：對每個環境各跑一次，全部要「未達」。 print("---") for env in sorted(set(case4.keys.values())): report("案例 4 逐環境驗收", case4, {env}) ``` ```text 案例 1 代簽邊未撤銷: 失陷 ['A'] -> 可及 5 / 門檻 5，達門檻 案例 2 代簽邊已撤銷: 失陷 ['A'] -> 可及 4 / 門檻 5，未達 案例 3 加節點但同一環境: 失陷 ['A'] -> 可及 6 / 門檻 6，達門檻 案例 4 加節點且分屬新組織: 失陷 ['A'] -> 可及 4 / 門檻 6，未達 案例 5 四把兩把同環境: 失陷 ['P'] -> 可及 2 / 門檻 2，達門檻 --- 案例 4 逐環境驗收: 失陷 ['A'] -> 可及 4 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['B'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['C'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['D'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['E'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['F'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['G'] -> 可及 1 / 門檻 6，未達 案例 4 逐環境驗收: 失陷 ['H'] -> 可及 1 / 門檻 6，未達 ``` 案例 1 與案例 2 只差一條代簽邊，撤銷後就無法達到門檻。案例 3 把門檻提高到 6、金鑰加到 11，但新增的兩把仍在同一環境，攻破它就能湊齊簽章；案例 4 同樣是 11 把、門檻 6，新增的兩把分屬新組織，在模型設定下，單一環境失陷便不足以簽署。案例 5 是四把裡兩把同環境、門檻 2 的模型，單一環境也足以達到門檻。最後八行逐一檢查各環境，全部顯示「未達」才通過這項檢查。 ## 尚未釐清的事 - 攻擊者進入 Sky Mavis 的 IT 基礎設施後，如何控制 4 把金鑰，是否曾匯出私鑰，官方報告沒有交代；受託鑑識公司的完整報告也未核得。 - 第 5 個簽章的技術形式仍有空白。Community Alert 正文寫代簽權，Q&A 一處寫 Axie DAO validator 在 2021 年 11 月加入 allowlist、12 月停用後 IP 仍在清單中，另一處又稱五把私鑰遭入侵，其中 4 把屬 Sky Mavis、1 把屬 Axie DAO。文件沒有說明這三種描述在實作上如何對應，不能推定私鑰一定遭複製。 - 2022 年 6 月 28 日的〈[The Ronin Bridge Is Open](https://blog.roninchain.com/p/the-ronin-bridge-is-open-)〉已讀全文。該文把 173,600 ETH 與 25.5M USDC 的轉出寫成「on March 29, 2022」，這是重啟公告自己的用詞。本文的攻擊日 3 月 23 日仍依〈[Community Alert: Ronin Validators Compromised](https://web.archive.org/web/20220329220845/https://roninblockchain.substack.com/p/community-alert-ronin-validators)〉與〈[Back to Building: Ronin Security Breach Postmortem](https://web.archive.org/web/20221206210351/https://roninblockchain.substack.com/p/back-to-building-ronin-security-breach)〉，發現日 3 月 29 日同樣依這兩篇。6 月 28 日這篇沒有寫重啟當日的 validator 總數，也沒有各組織持有數，這兩個數字仍未核得。 - Ronin 之後 11 個與目標 21 個 validator 的控制者分配，4 月 5 日只給了正在加入的五個組織名稱，沒有各持幾把。8 月 17 日〈[New Ronin Validators!](https://blog.roninchain.com/p/new-ronin-validators)〉的 17 個，以及 9 月 9 日〈[Google Cloud Ronin Network Validator](https://blog.roninchain.com/p/sky-mavis-adds-google-cloud-as-ronin)〉的第 18 個，也沒有各組織持有數。 - Harmony 在 2022 年 8 月 3 日以「我們相信」描述入侵路徑：至少一名開發者受釣魚誘導，在筆電安裝惡意軟體，攻擊者因此讀取聊天紀錄或非公開的橋基礎設施程式碼，並取得伺服器後門。文內的 6 月 17 日木馬仍在調查，6 月 2 日伺服器紀錄也被註明不足以單獨解釋入侵，後續鑑識結論尚未核實。本文查閱了 Harmony 部落格與論壇，尚未核得 8 月 3 日之後確認完整入侵路徑的官方鑑識報告，這不代表報告不存在。 - 幣安 2026 的簽署授權如何取得。幣安 2026 年 11 月 2 日的〈[Security Incident | Recovery Update #5](https://x.com/i/article/2117214044188766208)〉內容是 10 月 31 日的 PoR 快照驗證、回補與提款進度，沒有簽署授權、熱錢包金鑰或根因的資訊。「根因尚未公布」仍是 [TRM](https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history) 的句子，頁首日期 2026-10-29，數字截至 2026-10-30 00:30 UTC。本文未核得可完整解釋授權取得過程的官方報告。 2026-11-04 補記：幣安初步報告說明了攻擊者如何取得簽署服務存取權，這份公司說法仍待完整獨立複核，詳見〈[讀幣安初步報告：入侵路徑與 EIP-7702 授權](/posts/binance-2026-hack-initial-findings-report/)〉。 - Axie Infinity 的使用者數與橋的規模，尚缺當期官方數字。 - Numen 對 BNB 的 IAVL 分析仍自述未完成，本文只把官方記載的偽造證明當作案例依據。 所需公開資料見〈[交易所該公開什麼，外部才能持續核對資產、負債與交付能力](/posts/exchange-disclosures-for-ongoing-verification/)〉。 ## 補充筆記 - Ronin 的 5 of 9 由一家公司的 4 把金鑰，加上從同一環境可取得的第 5 個簽章湊齊。門檻要算單一環境失陷後拿得到的簽章，金鑰數或節點數單獨不夠。 - 代簽權要有到期日，業務停了權限要跟著停。 - 攻擊到發現隔了六天，官方稱事件由使用者回報揭露，當時也缺少大額流出監控；本文建議把監控放在簽署者環境之外。 - Ronin 6 月重啟公告為分級提款設了每日上限，也列出例外：管理員可重設上限，Tier 3 不計入。驗收要測試這些例外，確認失陷的簽署環境不能自行繞過核准。 - Harmony 官方寫四把私鑰中至少兩把失守，事後把 Ethereum 側改成 4-of-5，當時門檻參數沒交代；BNB 官方描述的攻擊路徑是偽造證明。 - 驗收從「某環境整個失陷」開始算，對每個環境各跑一次。 ## 修正紀錄 - 2026-11-04：將交易所揭露資料的後續預告改為已發布文章的連結。 ## 延伸閱讀 - [Community Alert: Ronin Validators Compromised（Wayback 2022-03-29 22:08:45）](https://web.archive.org/web/20220329220845/https://roninblockchain.substack.com/p/community-alert-ronin-validators)：當事方第一天的公告，門檻、allowlist 三種寫法、門檻提到 8 與攻擊者地址的出處。 - [Ronin 官方 X](https://x.com/Ronin_Network/status/1508828719711879168) 2022-03-29 的[兩則貼文](https://x.com/Ronin_Network/status/1508828722085867521)：當事方第一時間的安全事件、金額與暫停公告。 - [Securing Ronin](https://blog.roninchain.com/p/securing-ronin)：當事方 2022-04-05 的公告，五個正在加入的組織與 21 個獨立節點的目標，沒有各組織持有數。 - [Back to Building: Ronin Security Breach Postmortem（Wayback 2022-12-06）](https://web.archive.org/web/20221206210351/https://roninblockchain.substack.com/p/back-to-building-ronin-security-breach)：當事方 2022-04-27 的 postmortem，這裡引用存檔版本，是攻擊日、員工失陷到 IT 基礎設施、加節點與新橋人工核准的出處。該文寫，若進度順利，橋會在 5 月中下旬重開，實際的重開公告是 6 月 28 日。 - [The Ronin Bridge Is Open](https://blog.roninchain.com/p/the-ronin-bridge-is-open-)：當事方 2022-06-28 的重啟公告。三次稽核、分級門檻、每日上限、管理員可提前重設、Tier 3 不計入上限，以及 governor 與 validator 類比的出處。轉出日寫成 3 月 29 日。 - [New Ronin Validators!](https://blog.roninchain.com/p/new-ronin-validators)：當事方 2022-08-17 的公告，新增 Efficient Frontier、Community Gaming、Nansen，總數 17。文中的 70% 是在介紹新增 validator 的提案投票，需當時 validator 的 70% 同意，提款分級的 70% 寫在 6 月 28 日的重啟公告。沒有各組織持有數。 - [Google Cloud Ronin Network Validator](https://blog.roninchain.com/p/sky-mavis-adds-google-cloud-as-ronin)：當事方 2022-09-09 的公告，引述 Aleksander Larsen 稱 Google Cloud 為第 18 個 validator。沒有各組織持有數。 - [Withdrawal limits](https://docs.roninchain.com/apps/ronin-bridge/withdrawal-limits)：Ronin Docs 的提款頁，last updated 2026-05-12，以代幣數量分級，與 2022-06-28 的美元分級分開。本文核對的是文件頁，未驗證鏈上參數。 - [FBI 2022-04-14 聲明](https://www.fbi.gov/news/press-releases/fbi-statement-on-attribution-of-malicious-cyber-activity-posed-by-the-democratic-peoples-republic-of-korea)：執法機關歸因，原文沒有點名 Ronin。[美國財政部 2022-05-06 新聞稿](https://home.treasury.gov/news/press-releases/jy0768)：寫 Axie Infinity 與 3 月 23 日，正文沒有 Ronin 一詞與地址。[OFAC 2022-04-14 制裁更新](https://ofac.treasury.gov/recent-actions/20220414)：地址清單，沒有事件敘述。 - [Harmony's Horizon Bridge Hack](https://medium.com/harmony-one/harmonys-horizon-bridge-hack-1e8d283b6d66)：Harmony 官方 Medium，2022-06-24 起更新至 07-14。6 月 25 日 Update #2 寫金鑰存放與事後的 4-of-5。頁面最後一則編號更新是 7 月 14 日的回補方案規劃進度，尚未提出完整方案，也未確認完整金鑰取得路徑。 - [Summary of the Horizon Bridge Incident](https://talk.harmony.one/t/summary-of-the-horizon-bridge-incident/20990)：Harmony 官方論壇 2022-08-03 的當事方摘要，頁面時間沒有標時區，金鑰取得路徑用「我們相信」，部分項目寫仍在調查。 - [Governance Report: HIP-30v2](https://blog.harmony.one/p/governance-report-hip-30v2-on-25)：2023-08-03 的回收託管提案說明，規劃以 5-out-of-7 Recovery Multisig，由選出的保管人持有網路新發行的代幣，每月撥給處理脫鉤資產的 burn partners。文章仍在邀請投票，不足以證明安排已落實，也未將它列為 2022 年橋金鑰的後續配置。 - [BNB Chain Ecosystem Update](https://www.bnbchain.org/en/blog/bnb-chain-ecosystem-update)（2022-10-07）、[BNB Chain: A Decentralized Response](https://www.bnbchain.org/en/blog/bnb-chain-a-decentralized-response)（2022-10-11）與 [Technology Update of BNB Chain in Oct 2022](https://www.bnbchain.org/en/blog/technology-update-of-bnb-chain-in-october-2022)（2022-11-08）：當事方公告與修補清單，前兩篇沒有用 IAVL，第三篇的 BEP171 條目有。[Numen 的分析（Wayback 2023-02-08）](https://web.archive.org/web/20230208081055/https://www.numencyber.com/hello-world-1/)：第三方對 IAVL 的分析，存檔中的作者仍稱分析尚未完成。 - [Security Incident | Recovery Update #5](https://x.com/i/article/2117214044188766208)（[貼文](https://x.com/binance/status/2117237539098521938)）：幣安 2026-11-02 的 X 文章，談 10 月 31 日的 PoR 快照驗證、回補與提款進度，沒有簽署授權、熱錢包金鑰或根因。文中給了 Hacken 的 PoR 稽核連結，本文未另核該稽核頁。 - [Chainalysis 2026-10-30](https://www.chainalysis.com/blog/binance-exploit-latest-findings-and-response/) 與 [TRM，資料截至 2026-10-30](https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history)：分析公司的鏈上重建，並非幣安或受託鑑識報告；前者的簽名授權句只講 Ethereum，後者頁首日期 2026-10-29，數字截至 2026-10-30 00:30 UTC，寫根因尚未公布。 - [Ethereum glossary](https://ethereum.org/en/glossary/)：多簽的技術背景，案例細節仍以當事方公告為準。 - [NIST：Notes on Threshold EdDSA/Schnorr Signatures](https://csrc.nist.gov/pubs/ir/8214/b/ipd)：門檻簽章的初版公開草案，摘要說明各方可在不重組完整私鑰的情況下共同產生簽章，本文未另核 PDF 全文。 - [Multi-Party Threshold Cryptography](https://csrc.nist.gov/projects/threshold-cryptography)：NIST CSRC 專案頁，頁面標 Updated October 13, 2026。標準機構對門檻方案的範圍說明，寫的是用 MPC 分散密碼學元件的信任。 - [Cryptocurrency wallet 的 Multisignature wallet 段](https://en.wikipedia.org/w/index.php?oldid=1383170206#Multisignature_wallet)、[Single point of failure](https://en.wikipedia.org/w/index.php?oldid=1373263541)、[Threshold cryptosystem](https://en.wikipedia.org/w/index.php?oldid=1336993883)、[Common cause and special cause (statistics)](https://en.wikipedia.org/w/index.php?oldid=1381012247#Common_mode_failure_in_engineering)、[Separation of duties](https://en.wikipedia.org/w/index.php?oldid=1378917027)、[Spear phishing](https://en.wikipedia.org/w/index.php?oldid=1381339330#Spear_phishing)、[Axie Infinity](https://en.wikipedia.org/w/index.php?oldid=1382175554)、[Lazarus Group](https://en.wikipedia.org/w/index.php?oldid=1383294374)：百科條目，固定修訂版本，作背景與引用索引，不作案例證據。其中多簽段標 citation needed，Common mode failure 節標可能是 original research，Single point of failure 頁首標 needs more citations。 > 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 題目由 Sheng 選定，內文、案例整理與範例由 Claude 撰寫，範例在 Linux 上以 Python 3.13.18 實測。