原文來源: Vitalik
編譯: Odaily星球日報（ @OdailyChina ）
譯者：Wenser（ @wenser 2010 ）
編按：一直以來，關於以太坊rollup 安全性的三個階段的討論都是以太坊生態社區的關注重點，這不僅僅事關以太坊主網及L2 網路的運作穩定性，更與L2網路的真實發展狀況有關。近日，以太坊社群成員Daniel Wang 於X 平台提出了L2 網路Stage 2 階段的命名標籤#BattleTested，認為只有當前代碼和配置在Ethereum 主網上線超過6 個月，並且一直保持超過1 億美元的總鎖倉價值（TVL）且其中至少有5000 萬美元的ETH和主要穩定幣的L2網路才能獲得此稱號，且該稱號動態評估，避免產生「鏈上鬼蜮」。以太坊聯合創始人Vitalik 隨後對此問題進行了詳細解答與觀點分享，Odaily星球日報編譯如下。
L2網路的 3 大階段：從 0 到 1 再到 2 ，安全性由治理份額決定
以太坊rollup 安全性的三個階段可以根據安全委員會何時可以覆蓋無信任（即純加密或博弈論）組件來判定：
階段0 ：安全委員會擁有完全控制權。可能有一個運作中的證明系統（ Optimism 或ZK 模式），但安全委員會可以透過簡單的多數票機制推翻它。因此，證明系統僅為「諮詢性質」。
階段1 ：安全委員會需要75% （至少6/8）的批准才能涵蓋運作系統。必須有一個法定人數阻止子集（如≥ 3）在主要組織之外。因此，控制證明系統的難度相對較高，但並非不可逾越。
階段2 ：安全委員會只能在可證明的錯誤情況下採取行動。例如，可證明的錯誤可能是兩個冗餘的證明系統（例如OP 和ZK）相互矛盾。如果有可證明的錯誤，它只能選擇提出的答案之一：它不能任意回應某一機制。
我們可以用下面的圖表來表示安全委員會在不同階段擁有的「投票份額」：
三個階段的治理投票結構
一個重要的問題是：L2 網路從階段0 轉換到階段1 ，以及從階段1 發展到階段2 的最優時機分別是什麼？
不立即進入階段2 的唯一有效理由是，你不能完全信任證明系統——這是一種可以理解的擔憂：該系統由一大堆代碼組成，如果代碼有存在漏洞，那麼攻擊者可能竊取所有用戶的資產。你對證明系統的信心越強（或相反，你對安全委員會的信心越弱），你就越想推動整個網路生態向後一個階段發展。
事實上，我們可以用簡化的數學模型來量化這一點。首先，讓我們列出假設：
每個安全委員會的成員有10% 的「單獨故障」的可能；
我們將活躍性故障（拒絕簽署合約或金鑰不可用）和安全故障（簽署錯誤事項或金鑰被駭）視為同等可能事項。實際上，我們只假設一個「失敗」的類別，其中「失敗」的安全理事會成員既簽署了錯誤的事項，又未能簽署推進正確的事項；
在階段0 ，安全委員會的判定標準是4/7 ，在階段1 是6/8 ；
我們假設存在一個單一的整體證明系統（與2/3 的設計機制相對，安全委員會可以在兩者意見矛盾時打破僵局）。因此，在階段2 ，安全委員會的存在根本無關緊要。
在這些假設下，考慮到證明系統崩潰的特定機率，我們希望最小化L2 網路崩潰的可能。
我們可以使用二項分佈來完成這項工作：
如果每個安全理事會成員有10% 的獨立故障機會，那麼至少有4 個在7 個中故障的機率是 ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 因此，階段0 的整合系統有固定的0.002728。
階段1 的整合也可能失敗，如果證明系統失敗且安全委員會驗證機制發生≥ 3 次失敗，無法進行網路計算覆蓋（機率 ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 乘以證明系統失敗率∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 機率）；
階段2 合併失敗的機率與證明系統失敗的機率一致。
這裡以圖表形式呈現：
L2網路不同階段證明系統故障機率
如上所推測的結果，隨著證明系統品質的提高，最佳階段從階段0 轉移到階段1 ，然後從階段1 轉移到階段2 。使用階段0 品質的證明系統進行階段2 的網路運作是最差的結果。
現在，請注意上述簡化模型中的假設並不完全：
在現實中，安全委員會成員並不完全獨立，（他們之間可能）存在「共同模式故障」：他們可能串通一氣，或者都受到同樣的脅迫或駭客攻擊等等。要求在主要組織之外擁有一個法定人數阻止子集的目的是為了避免這一點的發生，但仍然並不完美。
證明系統本身可能是由多個獨立系統組合而成的（我在先前的部落格中曾經提倡這樣做）。在這種情況下，（i）證明系統崩潰的機率非常低，並且（ii）即使在階段 2 ，安全委員會也很重要，因為它是解決爭議的關鍵。
這兩個論點都表明，與圖表所示相比，階段 1 和階段 2 更具吸引力。
如果你相信數學，那麼階段 1 的存在幾乎永遠不會被證明是合理的：你應該直接進入階段 1 。我聽到的主要反對意見是：如果發生一個關鍵的錯誤，可能很難在8 名安全委員會成員中迅速獲得6 名成員的簽名來修復它。但有一個簡單的解決辦法：賦予任何一名安全委員會成員延遲提款1 到2 週的權限，給其他人足夠的時間來採取（補救）行動。
同時，然而，過早跳到階段2 也錯誤的，尤其是如果向階段2 過渡的工作是以犧牲加強底層證明系統的工作為代價的話。理想情況下，像L2Beat這樣的數據提供者應該展示證明系統審計和成熟度指標（最好是證明系統實現而非整個匯總的指標，這樣我們可以重複使用），並附帶展示階段。
