原文：《 Proposed milestones for rollups taking off training wheels 》by Vitalik Buterin
編譯：隔夜的粥
目前有大量的（optimistic 和ZK）rollup 項目，它們處於不同的發展階段。這些項目共有的一個模式是使用了臨時輔助輪：雖然項目的技術仍然不成熟，但為了發展生態的目的，便選擇了提前啟動，而不是完全依賴其欺詐證明或ZK 證明，然後有某種多重簽名能夠在代碼中存在漏洞的情況下強制執行特定結果。
L2beat 的風險分析頁面，顯示了有關各種rollup 項目的大量統計信息，包括它們的輔助輪狀態：
然而，截至今天，這些信息還沒有很好地被標準化，這使得用戶很難理解特定rollup 所使用的特定信任模型。 Rollup 團隊甚至可能有動力對他們當前的信任模型保持沉默，而是將討論重點放在完全無需信任的未來。
這篇文章提出了一個簡單的基於里程碑的模式，來幫助我們將Rollup 分為三個不同的階段（具體取決於它們對輔助輪的依賴程度），這樣做是為了實現以下幾個目標：
- 讓用戶更容易識別特定Rollup 在多大程度上依賴於「對特定人群的信任」以及「對代碼的信任」；
- 激勵Rollup 項目方改進他們的信任模型，降低信任最小化被取消優先級的風險；
- 給生態一些精確的里程碑來協調和慶祝，讓我們說「The Surge」何時完成一半或完全完成，這與「The Merge」是類似的。
此模式並非旨在暗示一種道德判斷，即盡快實現代碼信任最大化是唯一正確的行動方案。 Rollup 絕對應該有一個明確的摘掉輔助輪的路線圖，但只有在準備好後才應該摘掉輔助輪。
圖片來源：由無界版圖AI 工俱生成。
概要
階段0：完整的輔助輪
要求：
- 該項目應該稱自己為Rollup。
- 所有Rollup 交易都應該上鍊。
- 應該存在一個「rollup 全節點」：一個可獨立運行的軟件包，它可讀取L1 鏈，提取和rollup 鏈，併計算rollup 鏈的當前狀態。如果它不同意發佈到合約中的Rollup 狀態根，它應該發出警報。
- 應該有一種機制允許用戶發布Rollup 交易，或者至少確保在沒有運營商合作的情況下提取他們的資產。即運營商不能通過對用戶的審查來凍結或竊取用戶的資產；他們這樣做的唯一可能工具，必須是發布虛假狀態根。
- 如果發布新狀態根的鏈上機制只是一個多重簽名，其中沒有任何有效的欺詐證明或有效性證明，那也沒關係。
階段1 ：有限的輔助輪
要求：
- 必須有一個正在運行的欺詐證明或有效性證明方案，它具有接受或拒絕哪些狀態根被Rollup 合約接受的實際權限。
- 可以存在基於多重簽名的覆蓋機制（「安全委員會」），它可以覆蓋欺詐證明或有效性證明系統的輸出並發布狀態根，以防萬一證明系統代碼被利用。然而：
1)多重簽名必須是6 of 8 或更嚴格的（即>= 8 個參與者並且簽名閾值>= 75%）
2)至少有一個仲裁阻止組（即有足夠多的參與者來阻止多重簽名）必須在運行Rollup 的組織之外。
- 可以存在一種升級機制，但如果其閾值低於多重簽名，則升級必須具有至少7 天的強制激活延遲或防欺詐遊戲的最長時長（以較長者為準）。這條規則的目標是確保升級機制不能被用來介入實時糾紛。
第2 階段：摘除輔助輪
要求：
如果代碼沒有漏洞，則不得有任何一組參與者（甚至是集體）可發布除代碼輸出之外的狀態根。
這樣做（「如果代碼沒有錯誤，那麼沒有人可以覆蓋它」）的目的，是擺脫對安全委員會的過度依賴，後者只有在發生明顯錯誤的情況下才能使用，例如：
- Rollup 使用其狀態轉換功能的兩個或多個獨立實現（例如，兩個不同的欺詐證明者，兩個不同的有效性證明者，或每一個），只有當他們不同意時，安全理事會才能做出裁決——這只會在有一個漏洞時發生。
- 如果有人在處理相同的數據後，提交包含兩個不同狀態根的兩個有效證明的交易或一系列交易（即「證明者不同意自己」），控制權暫時移交給安全理事會。
- 如果>= 7 天沒有提交有效證明（即「證明者被卡住」），控制權暫時移交給安全理事會。
- 允許升級，但必須延遲>= 30 天。
APP 
