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

在 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 由非常聰明的密碼學家組建，他們是理智的，所以如果他們提倡 l ayer 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 <- batch mechanism <- rollup 或 validium 來替代 base layer <- rollup <- validium。從某種哲學架構的角度來看，這可能是真的。但是有一個重要的區別：中間層不是一個復雜的完整 EVM 系統，而是一個簡化的和高度專業化的對象，因此它更可能是安全的，它更有可能在沒有另一個專門的 Token 的情況下構建，它更有可能被最低限度的治理，並且不會隨著時間的推移而改變。

結論：到底什麽是「Layer」？

由在其自身之上堆叠相同的縮放方案組成的三層縮放架構通常不能很好地工作。在 rollups 之上的 rollups（其中兩層 rollups 使用相同的技術）的形式也不盡人意。但是，L2 和 L3 具有不同目的的三層架構可以行得通。rollups 之上的 Validiums 確實有意義，即使它們不能確定是長期的最佳做事方式。

然而，一旦我們開始深入了解哪種架構有意義的細節，我們就會進入哲學問題：什麽是「層」，什麽不是？base layer <- batch mechanism <- rollup 或 validium 和 base layer <- rollup <- rollup or validium 做著相同的工作，但就其工作方式而言，證明聚合層看起來更像 ERC-4337，而不是 rollups。通常，我們不會將 ERC-4337 稱為「layer 2」。同樣，我們不會將 Tornado Cash 稱為「Layer 2」， 因此，如果我們要保持一致，我們不會將位於第 L2 之上的以隱私為中心的子系統稱為 L3. 因此，關於什麽應該首先被稱為「Layer」，存在一個未解決的語義爭論。

在這方面有許多可能的思想流派。我個人的偏好是將術語「Layer 2」限製為具有以下屬性的事物：

1、他們的目的是提高可擴展性

2、他們遵循「區塊鏈中的區塊鏈」模式：他們有自己的交易處理機製和自己的內部狀態

3、他們繼承了以太坊鏈的全部安全性

因此，理想的 rollups 和 ZK rollups 是 L2，但驗證、證明聚合方案、 ERC 4337 、鏈上隱私系統和 Solidity 是另一回事。將其中一些稱為 L3 可能有意義，但可能不是全部；無論如何，現在確定定義似乎還為時過早，而多匯總生態系統的架構遠非一成不變，大多數討論僅在理論上進行。

也就是說，語言上的爭論不如哪個結構實際上最有意義的技術問題重要。顯然，服務於隱私等非擴展需求的某些「layers」可以發揮重要作用，並且需要以某種方式填充證明聚合的重要功能，最好是通過開放協議來填充。但與此同時，我們有充分的技術理由使鏈接面向用戶環境和 L1 的中間層盡可能簡單；在許多情況下，作為 EVM 匯總的「粘合層」可能不是正確的方法。我猜想，隨著 L2 擴展生態系統的成熟，本文中描述的更復雜（和更簡單）的結構將開始發揮更大的作用。