Vitalik：什麼樣的Layer3才是有意義的？

特別感謝 Georgios Konstantopoulos、Karl Floersch 和 Starkware 團隊的反饋和審查。

在 layer 2 擴容討論中經常再度浮現的一個話題是「layer 3s」的概念。如果我們可以構建一個 layer 2 協議錨定到 layer 1，以實現其安全性以及增加其可擴展性為主要目的，那麼我們當然可以通過構建一個「錨定到 layer 2 以實現安全性，並在其之上增加更多可擴展性」的 layer 3 協議來擴大其規模?

這個想法的一個簡單版本是：如果你有一個方案，可以讓你實現二次方增長，你能把這個方案堆迭在其自身之上並獲得指數級增長嗎？類似的想法包括我 2015 年的可擴展性論文以及在 Plasma 論文中提到的的 multi-layer 擴展等。不幸的是，如此簡單的 layer 3s 概念卻沒那麼容易形成可行方案。由於數據可用性的限制、對緊急提取的 layer 1 帶寬的依賴或許多其他問題，設計中總有一些東西是不可堆迭的，並且只能給你一次可擴展性的提升。

圍繞 layer 3s 的較新想法，如 Starkware 提出的框架，更加複雜：它們不僅僅是將相同的東西堆迭在自身之上，它們還為 layer 2 和 layer 3 分配了不同的用途。如果它以正確的方式完成，這種方法的潛在形式可能行得通。這篇文章將詳細介紹在三層架構中哪些可能有意義，哪些可能沒有意義。

為什麼你不能通過 stacking rollups 在 rollups 之上來保持擴容？

Rollups（請參閱我在此處的較長文章）是一種擴展技術，它結合了不同的技術來解決運行區塊鏈的兩個主要擴展瓶頸：計算和數據。計算已由「欺詐證明」或 SNARK等方式解決了，它們依賴於極少數參與者來處理和驗證每個塊，要求其他人只執行少量計算來檢查證明過程是否正確完成。這些方案，尤其是 SNARK，幾乎可以無限制地擴展；我們可以繼續製作「許多 SNARK 的 SNARK」，以將更多計算縮減為單個證明。

數據不一樣。Rollups 使用一系列壓縮技巧來減少交易需要在鏈上儲存的數據量：簡單的貨幣轉賬從 約 100 字節減少到 約 16 字節，在 EVM 兼容鏈中的 ERC20 轉賬從 約 180 字節減少到 約 23 個字節，一個保護隱私的 ZK-SNARK 交易可以從 約 600 字節壓縮到 約 80 個字節。在所有情況下大約有 8 倍壓縮。但是 rollup 仍然需要在保證用戶能夠訪問和驗證的介質中使數據在鏈上可用，以便用戶可以獨立計算 rollup 的狀態，並在現有證明者離線時作為證明者加入。數據可以壓縮一次，但不能再次壓縮 - - - 如果可以，那麼通常有一種方法可以將第二個壓縮器的邏輯放入第一個壓縮器中，並通過壓縮一次獲得相同的好處。因此，「在 Rollups 之上的 Rollups」實際上並不能在可擴展性方面提供巨大的收益，但是，正如我們將在下面看到的，這種模式可以用於其他目的。

那麼 layer 3 的「sane」版本是什麼？

好吧，讓我們看看 Starkware 在他們關於 layer 3s 的帖子中所提倡的有什麼。Starkware 由非常聰明的密碼學家組建，他們是理智的，所以如果他們提倡 layer 3s，他們的版本將比「如果 rollups 壓縮數據 8 倍，那麼顯然 rollups 之上的 rollups 將壓縮數據 64 倍」要複雜得多。

這是 Starkware 帖子中的圖：

引用幾句：

上圖描繪了這種生態系統的一個示例。它的 L3 包括：

1、具有 Validium 數據可用性的 StarkNet，如，常用於對定價極其敏感的應用程序中。

2、為獲得更好的應用程序性能而定製的特定於應用程序的 StarkNet 系統，例如，通過採用指定的儲存結構或數據可用性壓縮來實現。

3、StarkEx 系統（例如服務於 dYdX、Sorare、Immutable 和 DeversiFi 的系統）具有 Validium 或 Rollup 數據可用性，立即為 StarkNet 帶來久經考驗的可擴展性優勢。

4、隱私 StarkNet 實例（在此示例中也作為 L4）允許隱私保護類型的交易存在，而不將它們包含在公共 StarkNet 中。

我們可以將文章壓縮為「『L3s』的三個願景」：

· L2 用於擴容，L3 用於定製功能，例如隱私。在這個願景中，沒有嘗試提供「可擴展性二次方增長」；相反，堆棧中有一層可以幫助應用程序擴展，然後有獨立的層來滿足不同用例的定製功能需求。

· L2 用於通用擴容，L3 用於可定製化擴容。可定製化擴容可能有不同的形式：使用除 EVM 之外的其他東西進行計算的專用應用程序，數據壓縮針對特定應用程序的數據格式進行優化的 rollups（包括每個塊中將「數據」與「證明」分開，並用單個 SNARK 替換證明）等。

· L2 用於無信任擴展（rollups），L3 用於弱信任擴展（validiums）。 Validium 是使用 SNARK 來驗證計算的系統，但將數據可用性留給受信任的第三方或委員會。在我看來，Validium 被嚴重低估了：特別是，許多「企業區塊鏈」應用程序實際上可能最好由運行 validium 的證明者提供服務，並定期將哈希提交到鏈的集中式服務器來提供最佳服務。Validium 的安全等級低於 rollups，但可以便宜得多。

在我看來，所有這三個願景基本上都是合理的。專用數據壓縮需要自己的平台的想法可能是最薄弱的主張 - - - 設計具有通用基礎層壓縮方案的 L2 非常容易，用戶可以使用特定於應用程序的子壓縮器自動擴展，但除此之外，這些使用案例都是合理的。但這仍然留下一個大問題：三層結構是實現這些目標的正確方法嗎？將驗證、隱私系統和定製環境錨定到 L2 而不是僅僅錨定到 L1 有什麼意義？事實證明，這個問題的答案相當複雜。

在 L2 的子集樹中，存款和取款是否變得更便宜、更容易？

三層模型優於兩層模型的一個可能論點是：三層模型允許整個子生態系統存在於單個 rollup 中，這允許該生態系統內的跨域操作可以非常便宜地發生，而無需通過昂貴的 L1 完成。

但事實證明，即使在兩個 L2s 甚至 L3s 之間，存款與取款也可以非常便宜。這其中的關鍵是Token和其他資產不必在根鏈中發行。也就是說，您可以在 Arbitrum 上擁有 ERC20 Token ，在 Optimism 上創建它的包裝器，並在兩者之間來回行動而無需任何 L1 交易！

讓我們來看看這樣一個系統是如何工作的。有兩種智能合約：Arbitrum 上的基礎合約和 Optimism 上的封裝 Token 合約。要從 Arbitrum 轉移到 Optimism，您需要將 Token 發送到基礎合約，這將生成收據。一旦 Arbitrum 最終確定，您可以獲取該收據的 Merkle 證明並植根於 L1 狀態，然後將其發送到 Optimism 上的包裝 Token 合約中，該合約對其進行驗證並向您發放一個包裝 Token 。要將令牌移回，您可以反向執行相同的操作。

儘管在證明 Arbitrum 上的存款所需的 Merkle 路徑要通過 L1 狀態，Optimism 只需要讀取 L1 狀態根來處理存款 - - - 不需要 L1 交易。請注意，由於 rollups 數據是最稀缺的資源，因此這種方案的實際實現將使用 SNARK 或 KZG 證明，而不是直接使用 Merkle 證明，以節省空間。

與基於 L1 的 Token 相比，這種方案有一個致命弱點（至少在 optimistic  rullups 上是這樣）：存款還需要等待防欺詐窗口。如果 Token 植根於 L1，從 Arbitrum 或 Optimism 撤回到 L1 需要一周的延遲，但存款是即時的。然而，在這個方案中，存款和取款都需要一周的延遲。也就是說，尚不清楚理想的 rollups 上的三層架構是否更好：要確保在本身運行在防欺詐遊戲上的系統內部發生的防欺詐遊戲是安全的，存在很多技術複雜性。

幸運的是，這些問題都不會成為 ZK rollups 的問題。出於安全原因，ZK rollups 不需要長達一周的等待窗口，但由於其他兩個原因，它們仍然需要更短的窗口（第一代技術可能需要 12 小時）。首先，特別是更複雜的通用 ZK-EVM  rollups 需要更長的時間來覆蓋區塊的不可並行（non-parallelizable）計算時間。其次，出於經濟考慮，需要很少提交證明以最小化與證明交易相關的固定成本。包括專用硬體在內的下一代 ZK-EVM 技術將解決第一個問題，而架構更好的批量驗證可以解決第二個問題。我們接下來要討論的正是優化和批量提交證明的問題。

Rollups 和 validiums 有一個確認時間與固定成本的權衡。L3 可以幫助解決這個問題，但還有什麼也可以做到這些呢？

每個事務的 rollups 成本很便宜：它只是 16-60 字節的數據，具體取決於應用程序。但是 rollups 每次提交一批交易到鏈上時也必須支付高昂的固定成本：optimistic rollups 每批需要21000 L1 gas，ZK rollups 則超過 400,000 gas（如果你想只用 STARKS 提供量子安全的東西，則需要數百萬 gas）。

當然，rollup 可以簡單地選擇等到有 1000 萬 gas 價值的 L2 交易來提交整批 (交易)，但這會給他們帶來非常長的批次間隔，迫使用戶等待更長的時間以獲得高安全性確認。因此，它們需要權衡：較長的批次間隔和最佳成本，或者較短的批次間隔和大大增加的成本。

為了給我們一些具體的數字，讓我們考慮一個每批成本為 600,000 gas ZK rollup 並處理每筆交易成本為 368 gas 的完全優化的 ERC20 傳輸（23 字節）。假設此 rollups 處於採用的早期到中期，TPS 為 5。我們可以計算每筆交易與批次間隔的 gas：

如果我們進入一個擁有大量定製驗證和特定應用環境的世界，那麼其中許多每秒處理量將遠低於 5TPS。因此，確認時間和成本之間的權衡開始變得非常重要。事實上，「L3」範式確實解決了這個問題！ZK rollup 中的 ZK rollup，即使是簡單的實現，也只有大約 8,000 layer-1 gas 的固定成本（500 字節用於證明）。這會將上表更改為：

問題基本解決了，所以 L3s 是不是很好？也許是的。但需要注意的是，解決這一問題還有一個方法受到了ERC 4337 聚合驗證的啟發。

策略如下。今天，如果每個 ZK rollup 或 validium 收到證明，則證明 Snew = STF(Sold,D): 新的 state root 必須是在舊狀態根之上正確處理交易數據或狀態增量的結果。在這個新方案中，ZK rollup 將接受來自批量驗證者合約的消息，該消息說它已經驗證了一批語句的證明，其中每個語句的形式為 Snew = STF(Sold,D)。這種批量證明可以通過遞歸 SNARK 方案或 Halo 聚合來構建。

這將是一個開放的協議：任何 ZK-rollup 都可以加入，並且任何批量證明者都可以從任何兼容的 ZK-rollup 聚合證明，並從聚合器獲得交易費用的補償。批處理程序合約將驗證一次證明，然後將一條消息傳遞給每個 rollups, 並帶有該 sollups 的 (Sold, Snew, D) triple. Triple 來自批處理程序合約的事實會被作為證據來證明轉換是有效的。

如果優化得當，此方案中每次匯總的成本可能接近 8000，其中 5000 用於添加新更新的狀態寫入，1280 用於舊根和新根，以及額外的 1720 用於雜項數據處理。因此，它會給我們同樣的節省。Starkware 實際上已經有了類似的東西，稱為 SHARP，儘管它（還）不是一個無需許可的開放協議。

對這種方法的一種回應可能是：但這實際上不正是另一種第 3 層方案嗎？我們將有 base layer

原文連結