L Wang 平台 5 月在以太坊針對 Lup 15 月 5 月 5 月針對的去中心化安全性問題發表了看法，引來了以太坊創辦人 Vitalik Buterin 的回應。兩人討論的焦點集中在 Rollup 何時應從中心化或部分去中心化（Stage 0 或 Stage 1）轉向完全去中心化（Stage 2），以及如何確保這一過程的安全性。

Daniel Wang：程式碼成熟度是 Rollup 安全的關鍵

Daniel Wang 強調，程式碼的實戰成熟度對確保系統穩定性至關重要。他認為，即使 Rollup 達到完全去中心化的第二階段（Stage 2），若其代碼未經真實環境的壓力測試，仍可能存在漏洞，無法抵禦以利潤為動機的黑客攻擊，例如國家支持的 Lazarus 集團。

因此 Daniel Wang 指出，Rollup 管理大量資產，必須在高經濟壓力下證明程式碼的可靠性。對此他提出了「#BattleTested」標籤作為獨立評估標準，專注於程式碼成熟度，與 L2Beat 的階段模型（Stage 0-2）分開評估。具體標準包括：

· 代碼在以太坊主網上運行超過 6 個月；

· 持續保護至少 1 億美元的總鎖定價值（TVL），其中至少 5,000 萬美元為 ETH 和主要穩定貨幣；

·每次通過測試代碼

Daniel Wang 在推文中這樣寫道：

1/ 並非所有程式碼都生而平等。 一個 Rollup 可能達到第二階段，但執行的卻是從未在真實壓力下測試的新程式碼。

2/ 我提議一個獨立的標籤：#BattleTested。一個 Rollup 若其當前代碼和配置已在以太坊主網上運行超過 6 個月，且持續保護超過 1 億美元的總鎖定價值（TVL），其中至少 5,000 萬美元為 ETH 和主要穩定幣，則可稱為 #BattleTested。

3/ #BattleTested 並非永久的。 任何升級都會重設計時。 Rollup 必須再次透過在實際價值下的生產環境證明其運作來重新獲得此標籤。

4/ 此標籤獨立於 @l2beat 的階段模型。 一個 Rollup 可能達到第二階段但未獲 #BattleTested，或者已獲 #BattleTested 但未達第二階段。一個關於去中心化，另一個關於程式碼成熟度。

5/ @taikoxyz 的目標是達到第二階段，並使用 #BattleTested 的程式碼進行升級（我們可能需要另一個以太坊測試 Rollup…）。

Vitalik Buterin：去中心化需證明系統足夠可靠

對於 Daniel Wang 的觀點，Vitalik 則強調，Rollup 去中心化故障的時機是基於其係統可靠Stage 2。他提出了一個簡化數學模型，假設安全委員會成員有 10% 的獨立故障機率（包括活性失敗或安全性失敗），比較 Stage 0（4-of-7 多重簽名）、Stage 1（6-of-8 多重簽名）與 Stage 2 的個別安全性。

Vitalik 續指出，現實中安全委員會可能因共謀或同時被攻擊而出現「共同模式失敗」，使得 Stage 0 和 Stage 1 的安全性低於模型預測，因此實際上應更早進入 Stage 2。他主張將證明系統設計為多重簽章結構，以降低故障機率，並建議 L2Beat 納入證明系統的稽核與成熟度指標，以提升跨專案評估效率：

以下是顯示何時進入第二階段的簡化數學模型。

> 假設：每個安全委員會成員有獨立的 10%「故障」機率。

> 我們將活性失敗（拒絕簽署或金鑰無法存取）與安全性失敗（簽署錯誤內容或金鑰被駭）視為同等機率。

> 目標：在上述假設下最小化協議故障的機率。

> 第零階段安全委員會為 7 人中需 4 人同意，第一階段為 8 人中需 6 人同意。

請注意，這些假設非常不完美。現實中，安全委員會成員存在「共同模式失敗」：他們可能共謀，或全被脅迫，或以相同方式被駭等。這使得第零階段和第一階段的安全性低於模型顯示，因此進入第二階段的最佳時機比模型暗示的更早。

此外，證明系統的故障機率可透過將證明系統本身設為多個獨立系統的多重簽章來大幅降低。我猜測最初幾年的所有第二階段部署都將採用這種方式。考慮到這些，以下是圖表。 X 軸為證明系統故障的機率，Y 軸為協定故障的機率。

隨著證明系統品質提高，最佳階段從第零階段轉向第一階段，再從第一階段轉向第二階段。使用第零階段品質的證明系統進行第二階段是最糟糕的。簡而言之：@l2beat 理想上應展示證明系統的審計和成熟度指標（最好針對證明系統實現，而不是整個 Rollup，以便重複使用），並與階段一同顯示。

原文連結