L2 網路的 3 大階段：從 0 到 1 再到 2，安全性由治理份額決定

以太坊 rollup安全性的三個階段可以根據安全委員會何時可以覆蓋無信任（即純加密或博弈論）組件來判定：

· 階段 0 ：安全委員會擁有完全控制權。可能有一個運作中的證明系統（Optimism 或 ZK 模式），但安全委員會可以透過簡單的多數票機制來推翻它。因此，證明系統僅為「諮詢性質」。

· 階段 1 ：安全委員會需要 75%（至少 6/8）的批准才能覆蓋運作系統。必須有一個法定人數阻止子集（如 ≥ 3）在主要組織之外。因此，控制證明系統的難度相對較高，但並非不可逾越。

· 階段 2 ：安全委員會只能在可證明的錯誤情況下採取行動。例如，可證明的錯誤可能是兩個冗餘的證明系統（例如 OP 和 ZK）相互矛盾。如果有可證明的錯誤，它只能選擇提出的答案之一：它不能任意回應某一機制。

我們可以用下面的圖表來表示安全委員會在不同階段擁有的「投票份額」：

1，以及從階段 1 發展到階段 2 的最優時機分別是什麼？

不立即進入階段 2 的唯一有效理由是，你不能完全信任證明系統——這是一種可以理解的擔憂：該系統由一大堆代碼組成，如果代碼有存在漏洞，那麼攻擊者可能竊取所有用戶的資產。你對證明系統的信心越強（或相反，你對安全委員會的信心越弱），你就越想推動整個網路生態向後一個階段發展。

事實上，我們可以用簡化的數學模型來量化這一點。首先，讓我們列出假設：

· 每個安全委員會的成員有 10% 的「單獨故障」的可能；

· 我們將活躍性故障（拒絕簽署合約或金鑰不可用）和安全性故障（簽署錯誤事項或被駭）實際上，我們只假設一個「失敗」的類別，其中「失敗」的安全理事會成員既簽署了錯誤的事項，又未能簽署推進正確的事項；

· 在階段 0，安全委員會的判定標準是 4/7，在階段 1 是 6/8 ；

我們存在一個單一的假設（p的設計機制相對，安全委員會可以在兩者意見矛盾時打破僵局）。因此，在階段 2，安全委員會的存在根本無關緊要。

在這些假設下，考慮到證明系統崩潰的特定機率，我們希望最小化 L2 網路崩潰的可能。

我們可以使用二項分佈來完成這項工作：

· 如果每個安全理事會成員有 10% 的獨立故障機會，那麼至少有 4 個在 7 個中故障的機率是 ∑= 47( 7 ) 0.18 階段的整合系統有固定的 0.2728% 的失敗機率。

· 階段 1 的整合也可能失敗，如果證明系統失敗且安全委員會驗證機制發生 ≥ 3 次失敗，無法進行網絡計算覆蓋（概率 ∑= 38( 8 )∗ 0.1 ∗ 0.98 −= 0.03809179 證明如果安全失敗率次或更多次失敗，可以自行強制產生一個錯誤的計算答案（固定 ∑= 68( 8 )∗ 0.1 ∗ 0.98 −= 0.00002341 機率）；

· 期 2 合併失敗的機率與證明系統失敗的機率一致。

這裡以圖表形式呈現：

現在，請注意上述簡化模型中的假設並不完善：

· 在現實中，安全委員會成員並不完全獨立，（他們之間可能）存在「共同模式故障」：他們可能串通一氣，或者都受到同樣的脅迫或駭客攻擊等等。要求在主要組織之外擁有一個法定人數阻止子集的目的是為了避免這一點的發生，但仍然並不完美。

· 證明系統本身可能是由多個獨立系統組合而成的（我在先前的部落格中曾提倡這樣做）。在這種情況下，（i）證明系統崩潰的機率非常低，並且（ii）即使在階段 2，安全委員會也很重要，因為它是解決爭議的關鍵。

這兩個論點都表明，與圖表所示相比，階段 1 和階段 2 更具吸引力。

如果你相信數學，那麼階段 1 的存在幾乎永遠不會被證明是合理的：你應該直接進入階段 1。我聽到的主要反對意見是：如果發生一個關鍵的錯誤，可能很難在 8 名安全委員會成員中迅速獲得 6 名成員的簽名來修復它。但有一個簡單的解決方案：賦予任何一名安全委員會成員延遲提款 1 到 2 週的權限，給其他人足夠的時間來採取（補救）行動。

同時，然而，過早地跳到階段 2 也錯誤的，尤其是如果向階段 2 過渡的工作是以犧牲加強底層證明系統的工作為代價的話。理想情況下，像 L2Beat 這樣的資料提供者應該展示證明系統稽核和成熟度指標（最好是證明系統實作而非整個匯總的指標，這樣我們可以重複使用），並附帶展示階段。

原文連結