當一個功能檔案讓網路炸鍋

這篇文章闡述了我們如何看待本週 Cloudflare 停機事件，為什麼具有時間鎖的純智能合約控制平面能改變故障模式，以及零知識證明如何發揮作用。

週二停機摘要

在 2025 年 11 月 18 日 19:20（UTC +8），Cloudflare 的邊緣節點開始對大量流量返回 5xx 錯誤。根本原因不是攻擊者；而是一個 ClickHouse 權限變更，導致查詢返回重複行。該查詢生成了一個每隔幾分鐘就發送到每個邊緣節點的機器人管理 "功能文件"。

重複項 使文件大小增加了一倍，並將 功能計數增加到超過 200。機器人模組有一個硬上限和一個在溢出時會崩潰的 unwrap() 函數。當節點每五分鐘在"舊-好"和"新-壞"輸出之間交替時，整個機群開始震盪，直到所有分片都更新並保持在壞狀態。

Cloudflare 在 22:24（UTC +8）停止了發布程序，在 22:30（UTC +8）發送了最後一個已知良好的文件，並在 01:06（UTC +8）報告完全恢復。他們列出的後續行動：強化內部配置的攝取，添加全局終止開關，並審查各模組的故障模式。

查看 Cloudflare 自己的事後分析以獲取完整時間線和代碼片段。

這個故事中有兩個獨立的問題：

1. 控制平面故障：生成器產生了不符合規格的成品（重複項、過多功能、過大）。
2. 數據平面脆弱性：消費者崩潰而不是優雅降級。

你仍然可以在代碼審查中修復 (2)。但 (1) 是區塊鏈大放異彩的地方：作為部署前的 防篡改、可編程閘門。

公共區塊鏈上的"攜帶證明的配置"

如果將這個想法壓縮為一句話：除非智能合約允許，否則配置不會成為"當前"配置，而合約只有在時間鎖和證明成品遵守不變量後才會翻轉該標誌。這一句話暗示了一個完整的架構。

事實證明，公共區塊鏈，特別是建立在 Ethereum 上的，運行 Ethereum 虛擬機和共識層的 EVM 鏈，為該問題提供了一個很好的解決方案。

作為晉升閘門的鏈上配置註冊表

• 一個在快速、可信的 EVM（通常是 L2）上的智能合約記錄每個候選成品，以及對任何證明的承諾。
• 寫入由 時間鎖 和 多重簽名 控制；暫停/終止開關 和 回滾指針 是一等公民。
• 只有 哈希值 甚至完整腳本可以上鏈。如果是鏈下，blob 存在於對象存儲中，但提供較少的保證。如果由於大小原因無法完全上鏈，且數據是臨時的，使用 EIP-4844 blob 是個好主意。雖然是獨立存儲，但你可以將真正的鏈上哈希與保留 18 天的 blob 配對，這對於滾動回滾窗口非常好。

延遲適配。 Ethereum 以週期為單位完成最終確認，但 L2 在 幾秒鐘 內確認（OP Stack 目標約 2 秒；zkSync 約 1 秒；許多系統提供快速認證）。這對於五分鐘的控制平面節奏來說已經足夠好了，例如 OP 區塊時間討論或 Circle 的認證時間）。

強制證明：讓閘門變得智能

為每個成品附加一個簡潔的證明並在鏈上驗證它。這正是我們為 Chainwall 協議所做的，儘管是針對不同類型的數據！

核心目標是證明基本屬性：row_count <= 200，按鍵排序 + 唯一，模式匹配正則表達式和類型規則，文件大小 <= N。你可以將整個邏輯放在鏈上，或者依賴 Plonk/Groth 電路處理更大的表達式。例如，zk-VM 客戶可以解析 CSV/Parquet/JSON 並發出 SNARK。你不必揭示內容，只需提供承諾。ZK 中的正則表達式已有研究和生產系統（例如，Reef 和相關的 zk-regex 工作），這使得模式檢查變得現實。

有兩條實用路徑：

• zkVM 路線：在 zkVM 內運行檢查器並在鏈上驗證收據；參見 RISC Zero 驗證器合約和 Succinct 的 SP1 鏈上證明包裝。
• 電路路線：上述不變量的小型固定電路；對於 CSV/JSON + 正則表達式，你可以結合解析小工具和 zk-regex 技術。

不引入新信任的分發

邊緣節點輪詢註冊表，只採用鏈上 獲得綠燈 的成品。為避免信任第三方 RPC，在你的控制平面中運行 輕客戶端（例如，Helios）或計劃使用 Portal Network。這樣，邊緣節點在接受任何"新當前"狀態之前在本地驗證頭部和包含證明。

終止開關和回滾 只是合約中的位元，由邊緣節點遵守。Cloudflare 明確指出需要更強大的全局終止開關；將該開關放在一個小型、經過審計的合約中，可以在壓力下提供單一的真相來源。

這真的會改變 CloudFlare 故障嗎？

• 重複項膨脹的文件會突破由證明而非最佳努力強制執行的 計數/大小限制。晉升失敗。
• 即使有人手動將 blob 上傳到存儲，沒有鏈上"當前"標誌和證明驗證，邊緣節點也會拒絕採用它。
• 你仍然需要修復代理中的崩潰，但你已經將風險的最尖銳邊緣移到了證明系統和時間鎖非常有效的領域。

為什麼我們堅持為數字資產使用純鏈上控制平面

CloudFlare 事件不是攻擊，但他們最初認為是，而且確實很可能是！正如我們在加密安全中所見：攻擊者不僅追逐密鑰；他們還 脅迫控制平面。

• 前端或簽名者 UI 篡改：Bybit 盜竊案顯示了操縱簽名者 所見 內容如何推動災難性批准。分析指向網絡釣魚和 交易批准流程的 UI 操縱，而非智能合約漏洞。閱讀 NCC Group 的技術說明和 Ledger Insights 的報導。
• 第三方 API 權限：SwissBorg/Kiln 不是 Solidity 錯誤；它是一個鏈下 API 路徑，讓攻擊者重新洗牌質押權限並耗盡 ~193k SOL，如 Kiln 的聯合聲明所解釋。
• 從開發者筆記本到雲憑證再到一切：Lazarus/TraderTraitor 不斷證明 受損的開發者機器 和被欺騙的構建流程可以讓你獲得雲立足點和扭曲團隊所見和簽署內容的能力。例如，參見 CISA 的建議或 Elastic 對 AWS 憑證如何從開發者機器洩露的模擬。

結論

我們的立場：數字資產的 控制 必須存在於由 時間鎖 和 多重簽名 保護的 智能合約 中，而不是私人憑證、CI 令牌、雲 ACL 或管理儀表板中。如果你的部署或"更改所有者"操作 必須 通過合約的 schedule() 和 execute() 路徑，即使開發者筆記本上有 rootkit 也無法插隊。時間延遲是你可以依賴的斷路器，而鏈上審計跟踪是客觀的。這只留下了"如果我們正在推廣的東西格式錯誤怎麼辦？"的問題，這正是"攜帶證明的配置"所回答的。

我們也相信 最小化信任的應用程序 有相當大的市場。我們現在只是在 OKcontract Labs 為第一個明確定義的用例構建正確的基礎。

《當功能文件絆倒了互聯網》最初發表在 Medium 上的 Coinmonks，人們通過突出顯示和回應這個故事繼續對話。