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

撰文：Vitalik，《What kind of layer 3s make sense?》

編譯：董一鳴，鏈捕手

特別感謝 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之間，存款與取款也可以非常便宜。這其中的關鍵是代幣和其他資產不必在根鏈中發行。也就是說，您可以在 Arbitrum 上擁有 ERC20 代幣，在 Optimism 上創建它的包裝器，並在兩者之間來回移動而無需任何 L1 交易！

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

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

與基於 L1 的代幣相比，這種方案有一個致命弱點（至少在optimistic rullups上是這樣）：存款還需要等待防欺詐窗口。如果代幣植根於 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 收到證明，則證明 S ~new~ = STF(S ~old~ ,D) : 新的state root必須是在舊狀態根之上正確處理交易數據或狀態增量的結果。 在這個新方案中，ZK rollup 將接受來自批量驗證者合約的消息，該消息說它已經驗證了一批語句的證明，其中每個語句的形式為 S ~new~ = STF(S ~old~ ,D)。 這種批量證明可以通過遞歸 SNARK 方案或 Halo聚合來構建。

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

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

對這種方法的一種回應可能是：但這實際上不正是另一種第 3 層方案嗎？我們將有base layer \<- batch mechanism \<- rollup 或 validium來替代base layer \<- rollup \<- validium。從某種哲學架構的角度來看，這可能是真的。 但是有一個重要的區別：中間層不是一個複雜的完整 EVM 系統，而是一個簡化的和高度專業化的對象，因此它更可能是安全的，它更有可能在沒有另一個專門的代幣的情況下構建，它更有可能被最低限度的治理，並且不會隨著時間的推移而改變。

結論：到底什麼是" 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擴展生態系統的成熟，本文中描述的更複雜（和更簡單）的結構將開始發揮更大的作用。