Vitalik：什么樣的 Layer 3 才有意義？

Unitimes
2022年9月19日06時

撰文：Vitalik Buterin，以太坊聯合創始人

編譯：董一鳴，鏈捕手

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

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

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

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

為什么你不能通過在 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 3 的帖子中所提倡的有什么。Starkware 由非常聰明的密碼學家組建，他們是理智的，所以如果他們提倡 layer 3s，他們的版本將比“如果 Rollups 壓縮數據 8 倍，那么顯然 Rollups 之上的 Rollups 將壓縮數據 64 倍”要復雜得多。

這是 Starkware 帖子中的圖：

引用幾句：

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

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

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

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

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

我們可以將文章壓縮為“L3”的三個愿景：

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 字節用于證明）。這會將上表更改為：

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

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

這將是一個開放的協議：任何 ZK-Rollup 都可以加入，并且任何批量證明者都可以從任何兼容的 ZK-Rollup 聚合證明，并從聚合器獲得交易費用的補償。批處理程序合約將驗證一次證明，然后將一條消息傳遞給每個 Rollup, 并帶有該sollups的(Sold,Snew,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 擴展生態系統的成熟，本文中描述的更復雜（和更簡單）的結構將開始發揮更大的作用。

原文鏈接：

https://vitalik.ca/general/2022/09/17/layer_3.html

**本文僅代表原作者觀點，不構成任何投資意見或建議。

-END-

來了就點個“贊”唄