原標題：Possible futures for the Ethereum protocol, part 2: The Surge
作者：Vitalik，以太坊創始人，編譯：鄧通，金色財經
特別感謝 Justin Drake、Francesco、Hsiao-wei Wang、@antonttc 和 Georgios Konstantopoulos
一開始，以太坊的路線圖中有兩種擴展策略。其中之一是“分片”：每個節點只需要驗證和存儲一小部分交易，而不是驗證和存儲鏈中的所有交易。這也是任何其他點對點網絡（例如 BitTorrent）的工作原理，因此我們當然可以使區塊鏈以同樣的方式工作。另一個是第 2 層協議：網絡將位於以太坊之上，使它們能夠充分受益於其安全性，同時使大多數數據和計算遠離主鏈。 “第 2 層協議”指的是 2015 年的狀態通道、2017 年的 Plasma，以及 2019 年的 Rollups。Rollup 比狀態通道或 Plasma 更強大，但它們需要大量的鏈上數據帶寬。幸運的是，到 2019 年，分片研究已經解決了大規模驗證“數據可用性”的問題。結果，兩條路徑融合了，我們得到了以彙總為中心的路線圖，這仍然是以太坊今天的擴展策略。
The Surge，2023 年路線圖版。
以 rollup 為中心的路線圖提出了一個簡單的分工：以太坊 L1 專注於成為一個強大且去中心化的基礎層，而 L2 則承擔幫助生態系統擴展的任務。這是社會各處反覆出現的模式：法院系統（L1）並不是為了超快速和高效，而是為了保護合同和財產權，而企業家（L2）則需要在此基礎上進行構建堅固的基礎層並將人類帶到（隱喻和字面上的）火星。
今年，以彙總為中心的路線圖取得了重要成功：以太坊 L1 數據帶寬通過 EIP-4844 blob 大幅增加，並且多個 EVM 彙總現在處於第一階段。分片的非常異構和多元化的實現，其中每個 L2 充當具有自己的內部規則和邏輯的“碎片”現在已成為現實。但正如我們所看到的，走這條路有其自身的一些獨特的挑戰。因此，現在我們的任務是完成以 Rollup 為中心的路線圖，並解決這些問題，同時保留使以太坊 L1 與眾不同的穩健性和去中心化性。
Surge：關鍵目標
L1+L2 上 100,000+ TPS
保持 L1 的去中心化和穩健性
至少一些 L2 完全繼承了以太坊的核心屬性（去信任、開放、抗審查）
L2 之間的最大互操作性。以太坊應該感覺像是一個生態系統，而不是 34 個不同的區塊鏈。
可擴展性的三難困境
可擴展性三難困境是 2017 年提出的一個想法，它認為區塊鏈的三個屬性之間存在緊張關係：去中心化（更具體地說：運行節點的低成本）、可擴展性（更具體地說：處理大量交易）和安全性（更具體地說：攻擊者需要破壞整個網絡中的大部分節點才能使單個交易失敗）。
值得注意的是，三難困境不是定理，介紹三難困境的帖子沒有附帶數學證明。它給出了一個啟發式的數學論證：如果一個去中心化友好的節點（例如消費者筆記本電腦）每秒可以驗證 N 個交易，並且您有一個每秒處理 k*N 個交易的鏈，那麼（i）每個交易只能被看到1/k 的節點，這意味著攻擊者只需破壞幾個節點即可推動不良交易，或者 (ii) 您的節點將變得強大並且您的鏈不是去中心化的。這篇文章的目的從來不是為了表明打破三難困境是不可能的；相反，它是為了表明打破三難困境是困難的——它需要以某種方式跳出論證所暗示的框框進行思考。
多年來，一些高性能鏈經常聲稱他們解決了三難困境，而沒有在基礎架構層面採取任何巧妙的措施，通常是通過使用軟件工程技巧來優化節點。這總是具有誤導性，並且在此類鏈中運行節點總是比在以太坊中困難得多。這篇文章探討了為什麼會出現這種情況的許多微妙之處（以及為什麼 L1 客戶端軟件工程無法單獨擴展以太坊本身）。
然而，數據可用性採樣和 SNARK 的結合確實解決了三難困境：它允許客戶端驗證一定數量的數據是否可用，以及是否正確執行了一定數量的計算步驟，同時僅下載該數據的一小部分並且運行的計算量要小得多。 SNARK 是不可信的。數據可用性採樣具有微妙的少數 N 信任模型，但它保留了不可擴展鏈所具有的基本屬性，即使 51% 攻擊也無法迫使網絡接受壞塊。
解決三難困境的另一種方法是 Plasma 架構，它使用巧妙的技術以激勵兼容的方式將監視數據可用性的責任推給用戶。早在 2017-2019 年，當我們擴展計算所需的只是欺詐證明時，Plasma 的安全功能非常有限，但 SNARK 的主流化使得 Plasma 架構比以前更適用於更廣泛的用例。
數據可用性抽樣的進一步進展
我們要解決什麼問題？
截至 2024 年 3 月 13 日，當 Dencun 升級上線時，以太坊區塊鏈每 12 秒時段有 3 個約 125 kB 的“blob”，或者每個時段約 375 kB 的數據可用帶寬。假設交易數據直接發佈到鏈上，ERC20傳輸約為180字節，因此以太坊上rollups的最大TPS為：
375000 / 12 / 180 = 173.6 TPS
如果我們添加以太坊的 calldata（理論最大值：每個插槽 3000 萬個 Gas / 每字節 16 個 Gas = 每個插槽 1,875,000 字節），這將變為 607 TPS。對於 PeerDAS，計劃將 blob 計數目標增加到 8-16，這將為我們提供 463-926 TPS 的 calldata。
這相對於以太坊 L1 來說是一個重大的提升，但這還不夠。我們想要更多的可擴展性。我們的中期目標是每個插槽 16 MB，如果與彙總數據壓縮的改進相結合，將為我們提供約 58,000 TPS。
它是什麼以及它是如何工作的？
PeerDAS 是“一維採樣”的相對簡單的實現。以太坊中的每個 blob 都是 253 位素數域上的 4096 次多項式。我們廣播多項式的“份額”，其中每個份額由從總共 8192 個座標集中獲取的相鄰 16 個座標處的 16 個評估組成。 8192 次評估中的任意 4096 次（使用當前建議的參數：128 個可能樣本中的任意 64 個）都可以恢復該 blob。
PeerDAS 的工作原理是讓每個客戶端偵聽少量子網，其中第 i 個子網廣播任何 Blob 的第 i 個樣本，並另外通過詢問全球 p2p 網絡中的對等方來請求其他子網上所需的 Blob （誰會監聽不同的子網）。更保守的版本 SubnetDAS 僅使用子網機制，沒有額外的請求對等層。當前的建議是參與權益證明的節點使用 SubnetDAS，其他節點（即“客戶端”）使用 PeerDAS。
理論上，我們可以將 1D 採樣擴展得相當遠：如果我們將 blob 計數最大值增加到 256（因此，目標為 128），那麼我們將達到 16 MB 目標，而數據可用性採樣只需每個節點花費 16 個樣本 * 128 blobs * 每個 blob 每個樣本 512 字節 = 每個槽 1 MB 的數據帶寬。這剛好在我們的容忍範圍之內：它是可行的，但這意味著帶寬受限的客戶端無法採樣。我們可以通過減少 blob 數量和增加 blob 大小來對此進行優化，但這會使重建更加昂貴。
因此最終我們想要更進一步，進行 2D 採樣，它不僅通過在blob內進行隨機採樣，而且還在blob之間進行隨機採樣。 KZG 承諾的線性屬性用於通過對相同信息進行冗餘編碼的新“虛擬 blob”列表來“擴展”區塊中的 blob 集。
2D sampling.來源：a16z
至關重要的是，計算承諾的擴展不需要 blob，因此該方案從根本上對分佈式塊構建是友好的。實際構建區塊的節點只需要有 Blob KZG 承諾，並且自己可以依賴 DAS 來驗證 Blob 的可用性。 1D DAS 本質上對分佈式區塊構建也很友好。
與現有研究有哪些聯繫？
介紹數據可用性的原始文章（2018）：https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
後續論文：https://arxiv.org/abs/1809.09044
DAS 的解釋者帖子，範式：https://www.paradigm.xyz/2022/08/das
KZG 承諾的 2D 可用性：https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
ethresear.ch 上的 PeerDAS： https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 和論文：https://eprint.iacr.org/2024/1362
EIP-7594：https://eips.ethereum.org/EIPS/eip-7594
ethresear.ch 上的 SubnetDAS：https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
2D 採樣中可恢復性的細微差別：https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
還需要做什麼，需要權衡什麼？
下一步是完成 PeerDAS 的實施和推出。從那時起，不斷增加 PeerDAS 上的 blob 計數是一項漸進的工作，同時仔細觀察網絡並改進軟件以確保安全。與此同時，我們希望開展更多關於 PeerDAS 和其他版本的 DAS 形式化及其與分叉選擇規則安全性等問題的交互方面的學術工作。
展望未來，我們需要做更多的工作來找出 2D DAS 的理想版本並證明其安全特性。我們還希望最終從 KZG 遷移到抗量子、無需可信設置的替代方案。目前，我們不知道有哪些候選者對分佈式區塊構建友好。即使使用遞歸 STARK 來生成重建行和列的有效性證明的昂貴“強力”技術也不夠，因為從技術上講，STARK 的哈希值大小為 O(log(n) * log(log(n)) (與 STIR），實際上 STARK 幾乎和整個斑點一樣大。
從長遠來看，我認為現實的路徑是：
理想的 2D DAS 工具；
堅持使用 1D DAS，為了簡單性和robustness而犧牲採樣帶寬效率並接受較低的數據上限；
（硬樞軸）放棄 DA，並完全擁抱 Plasma 作為我們關注的主要第 2 層架構。
我們可以通過權衡範圍來看待這些：
請注意，即使我們決定直接在 L1 上擴展執行，這種選擇仍然存在。這是因為如果 L1 要處理大量 TPS，L1 塊將變得非常大，客戶將需要一種有效的方法來驗證它們是否正確，因此我們必須使用支持彙總的相同技術（ZK-EVM 和DAS）和 L1。
它如何與路線圖的其他部分交互？
如果實施數據壓縮（見下文），對 2D DAS 的需求會有所減少，或者至少會延遲，如果 Plasma 得到廣泛使用，則對 2D DAS 的需求會進一步減少。 DAS 也對分佈式區塊構建協議和機制提出了挑戰：雖然 DAS 理論上對分佈式重構很友好，但在實踐中需要與包含列表提案及其周圍的分叉選擇機制相結合。
數據壓縮
我們要解決什麼問題？
Rollup 中的每筆交易都會佔用大量鏈上數據空間：ERC20 傳輸大約需要 180 個字節。即使採用理想的數據可用性採樣，這也會限制第 2 層協議的可擴展性。每個插槽 16 MB，我們得到：
16000000 / 12 / 180 = 7407 TPS
如果除了解決分子之外，我們還可以解決分母，並使彙總中的每個交易在鏈上佔用更少的字節怎麼辦？
它是什麼以及它是如何工作的？
我認為最好的解釋是兩年前的這張圖：
最簡單的增益就是零字節壓縮：用兩個表示零字節數量的字節替換每個長的零字節序列。更進一步，我們利用交易的特定屬性：
簽名聚合 - 我們從 ECDSA 簽名切換到 BLS 簽名，BLS 簽名具有可以將許多簽名組合在一起形成單個簽名的屬性，該簽名可以證明所有原始簽名的有效性。 L1 沒有考慮這一點，因為驗證的計算成本（即使使用聚合）也更高，但在像 L2 這樣的數據稀缺環境中，它們可以說是有意義的。 ERC-4337 的聚合功能提供了實現此目的的一種途徑。
用指針替換地址 - 如果以前使用過地址，我們可以用指向歷史位置的 4 字節指針替換 20 字節地址。這是實現最大收益所必需的，儘管需要付出努力才能實現，因為它需要（至少一部分）區塊鏈的歷史才能有效地成為國家的一部分。
交易值的自定義序列化 - 大多數交易值只有很少的數字，例如。 0.25 ETH 表示為 250,000,000,000,000,000 wei。 Gas max-basefees 和優先級費用的工作原理類似。因此，我們可以使用自定義十進制浮點格式，甚至是特別常見值的字典，非常緊湊地表示大多數貨幣值。
與現有研究有哪些聯繫？
來自sequence.xyz的探索：https://sequence.xyz/blog/compressing-calldata
針對 L2 的 Calldata 優化合約，來自 ScopeLift：https://github.com/ScopeLift/l2-optimizoooors
另一種策略 - 基於有效性證明的彙總（又名 ZK 彙總）發佈狀態差異而不是交易：https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975 上的-l2-數據足跡
BLS 錢包 - 通過 ERC-4337 實現 BLS 聚合：https://github.com/getwax/bls-wallet
還需要做什麼，需要權衡什麼？
剩下要做的主要工作就是將上述方案落到實處。主要的權衡是：
切換到 BLS 簽名需要付出巨大的努力，並且會降低與可提高安全性的可信硬件芯片的兼容性。可以使用其他簽名方案的 ZK-SNARK 包裝器來替代它。
動態壓縮（例如用指針替換地址）使客戶端代碼變得複雜。
將狀態差異發佈到鏈而不是交易會降低可審計性，並使許多軟件（例如區塊瀏覽器）無法工作。
它如何與路線圖的其他部分交互？
ERC-4337 的採用，以及最終將其部分內容納入 L2 EVM 中，可以大大加快聚合技術的部署。將 ERC-4337 的部分內容納入 L1 可以加速其在 L2 上的部署。
廣義Plasma
我們要解決什麼問題？
即使使用 16 MB blob 和數據壓縮，58,000 TPS 也不一定足以完全接管消費者支付、去中心化社交或其他高帶寬領域，如果我們開始考慮隱私，情況就尤其如此，這可能會使可擴展性下降 3 -8x。對於大容量、低價值的應用程序，當今的一個選擇是 validium，它使數據處於鏈下狀態，並具有有趣的安全模型，操作員無法竊取用戶的資金，但它們可以消失並暫時或永久凍結所有用戶的資金資金。但我們可以做得更好。
它是什麼以及它是如何工作的？
Plasma 是一種擴展解決方案，涉及運營商在鏈外發布區塊，並將這些區塊的 Merkle 根放在鏈上（與 Rollups 不同，rollups 是將整個區塊放在鏈上）。對於每個區塊，運營商向每個用戶發送一個 Merkle 分支，證明該用戶的資產發生了什麼或沒有發生什麼。用戶可以通過提供Merkle分支來提取資產。重要的是，該分支不必紮根於最新狀態 - 因此，即使數據可用性失敗，用戶仍然可以通過撤回可用的最新狀態來恢復其資產。如果用戶提交無效分支（例如，退出他們已經發送給其他人的資產，或者運營商自己憑空創建資產），鏈上挑戰機制可以裁定該資產正確屬於誰。
Plasma Cash 鏈圖。花費幣 i 的交易被放入樹中的第 i 個位置。在這個例子中，假設所有之前的樹都是有效的，我們知道 Eve 目前擁有硬幣 1，David 擁有硬幣 4，George 擁有硬幣 6。
Plasma 的早期版本只能處理支付用例，無法有效地進一步推廣。然而，如果我們要求每個根都用 SNARK 進行驗證，那麼 Plasma 就會變得更強大。每個挑戰遊戲都可以大大簡化，因為我們消除了操作員作弊的大多數可能路徑。新的路徑也開闢了，使 Plasma 技術能夠擴展到更廣泛的資產類別。最後，在運營商不作弊的情況下，用戶可以立即提取資金，無需等待一週的挑戰期。
製作 EVM Plasma鏈的一種方法（不是唯一方法）：使用 ZK-SNARK 構建並行 UTXO 樹，反映 EVM 所做的餘額變化，並定義什麼是“同幣”的唯一映射歷史上的不同點。然後可以在此基礎上構建Plasma結構。
一個重要的見解是 Plasma 系統不需要完美。即使您只能保護一部分資產（例如，即使只是過去一週沒有移動的代幣），您也已經大大改善了超可擴展 EVM 的現狀，這是一個驗證。
另一類結構是混合Plasma/rollups結構，例如 Intmax。這些結構將每個用戶的非常少量的數據放在鏈上（例如 5 字節），通過這樣做，可以獲得介於Plasma和彙總之間的屬性：在 Intmax 情況下，您可以獲得非常高水平的可擴展性和隱私性，即使在 16 MB 世界中，理論上容量上限也約為 16,000,000 / 12 / 5 = 266,667 TPS。
與現有研究有哪些聯繫？
原始 Plasma 論文：https://plasma.io/plasma-deprecated.pdf
Plasma現金：https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
Plasma現金流： https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit
Intmax（2023）：https://eprint.iacr.org/2023/1082
還需要做什麼，需要權衡什麼？
剩下的主要任務是將 Plasma 系統投入生產。如上所述，“plasma 與 validium”不是二元對立：任何 validium 都可以通過將 Plasma 功能添加到退出機制中來至少提高一點點安全性能。研究部分是為了獲得 EVM 的最佳屬性（在信任要求、最壞情況的 L1 Gas 成本和 DoS 脆弱性方面）以及替代的特定於應用程序的結構。此外，Plasma 相對於 rollups 的概念複雜性更大，需要通過研究和構建更好的通用框架來直接解決。
使用 Plasma 設計的主要缺點是它們更多地依賴於操作員並且更難“基於”，儘管混合 Plasma/rollup 設計通常可以避免這個弱點。
它如何與路線圖的其他部分交互？
Plasma 解決方案越有效，L1 擁有高性能數據可用性功能的壓力就越小。將活動移至 L2 還可減少 L1 上的 MEV 壓力。
成熟的 L2 證明系統
我們要解決什麼問題？
如今，大多數彙總實際上還不是去信任的；有一個安全理事會有能力推翻（樂觀或有效性）證明系統的行為。在某些情況下，證明系統甚至根本不存在，或者即使存在也僅具有“諮詢”功能。最領先的是 (i) 一些特定於應用程序的彙總，例如 Fuel，它們是去信任的，以及 (ii) 截至撰寫本文時，Optimism 和 Arbitrum，這兩個完整的 EVM 彙總已經實現了部分去信任里程碑稱為“第一階段”。 Rollups 沒有進一步發展的原因是擔心代碼中的 bug。我們需要去信任的彙總，因此我們需要正面解決這個問題。
它是什麼以及它是如何工作的？
首先，讓我們回顧一下本文最初介紹的“stage”系統。還有更詳細的要求，但總結如下：
第 0 階段：用戶必須能夠運行節點並同步鏈。如果驗證是完全可信/集中的就可以了。
第一階段：必須有一個（去信任的）證明系統，確保只接受有效的交易。允許存在一個可以推翻證明系統的安全委員會，但只有 75% 的投票門檻。此外，理事會的法定人數阻止部分（即 26% 以上）必須位於構建彙總的主要公司之外。允許使用功能較弱的升級機制（例如 DAO），但必須有足夠長的延遲，以便如果批准惡意升級，用戶可以在升級上線之前退出資金。
第二階段：必須有一個（不信任的）證明系統來確保只接受有效的交易。僅當代碼中存在可證明的錯誤時，才允許安理會進行干預，例如。如果兩個冗餘證明系統彼此不一致，或者如果一個證明系統接受同一塊的兩個不同的後狀態根（或者在足夠長的時間內不接受任何內容，例如一週）。允許升級機制，但必須有很長的延遲。
我們的目標是達到第二階段。達到第二階段的主要挑戰是獲得足夠的信心，證明證明系統實際上足夠值得信賴。有兩種主要方法可以做到這一點：
形式驗證：我們可以使用現代數學和計算技術來證明（樂觀或有效性）證明系統只接受通過 EVM 規範的區塊。這些技術已經存在了幾十年，但最近的進步（例如精益 4）使它們更加實用，而人工智能輔助證明的進步可能會進一步加速這一趨勢。
多重證明者：製作多重證明系統，並將資金投入這些證明系統和安全委員會（和/或其他具有信任假設的小工具，例如 TEE）之間的 2-of-3（或更大）多重簽名。如果證明系統同意，則安理會沒有權力。如果他們不同意，安理會只能選擇其中之一，而不能單方面強加自己的答案。
多證明者的程式化圖，結合了一個樂觀證明系統、一個有效性證明系統和一個安全委員會。
與現有研究有哪些聯繫？
EVM K Semantics（2017年起正式驗證工作）：https://github.com/runtimeverification/evm-semantics
關於多證明者想法的演示（2022）： https://www.youtube.com/watch?v=6hfVzCWT6YI
Taiko 計劃使用多重證明：https://docs.taiko.xyz/core-concepts/multi-proofs/
還需要做什麼，需要權衡什麼？
對於形式驗證來說，有很多。我們需要創建 EVM 的整個 SNARK 證明者的正式驗證版本。這是一個極其複雜的項目，儘管我們已經開始了。有一個技巧可以顯著簡化任務：我們可以為最小虛擬機制作一個正式驗證的 SNARK 證明者，例如。 RISC-V 或 Cairo，然後在該最小 VM 中編寫 EVM 的實現（並正式證明其與其他一些 EVM 規範的等效性）。
對於多重證明者來說，還有兩個主要的剩餘部分。首先，我們需要對至少兩個不同的證明系統有足夠的信心，它們各自都相當安全，並且如果它們崩潰，它們會因不同且不相關的原因而崩潰（因此它們不會同時崩潰）。其次，我們需要在合併證明系統的底層邏輯中獲得非常高水平的保證。這是一小段代碼。有多種方法可以使其變得非常小——只需將資金存儲在安全多重簽名合約中，其簽名者是代表個人證明系統的合約——但這需要付出高昂的鏈上Gas成本的代價。需要在效率和安全之間找到某種平衡。
它如何與路線圖的其他部分交互？
將活動移至 L2 可減少 L1 上的 MEV 壓力。
跨 L2 互操作性改進
我們要解決什麼問題？
如今 L2 生態系統的一大挑戰是用戶難以操縱。此外，最簡單的方法通常會重新引入信任假設：集中式橋、RPC 客戶端等等。如果我們認真對待 L2 是以太坊一部分的想法，我們需要讓使用 L2 生態系統感覺就像使用統一的以太坊生態系統一樣。
一個病態糟糕的例子（甚至是危險的：我個人因為這裡的鏈選擇錯誤而損失了 100 美元）跨 L2 UX - 雖然這不是 Polymarket 的錯，但跨 L2 互操作性應該是錢包和以太坊標準的責任（ERC） ） 社區。在運行良好的以太坊生態系統中，從 L1 到 L2 或從一個 L2 到另一個 L2 發送代幣應該就像在同一個 L1 中發送代幣一樣。
它是什麼以及它是如何工作的？
跨 L2 互操作性改進有很多類別。一般來說，提出這些問題的方法是注意到理論上，以彙總為中心的以太坊與 L1 執行分片是一樣的，然後詢問當前的以太坊 L2 版本在實踐中在哪些方面與理想的差距。以下是一些：
鏈特定地址：鏈（L1、Optimism、Arbitrum...）應該是地址的一部分。一旦實現，只需將地址放入“發送”字段即可實現跨 L2 發送流程，此時錢包可以在後臺弄清楚如何進行發送（包括使用橋接協議）。
特定於鏈的支付請求：製作“向我發送 Z 鏈上 Y 類型的 X 代幣”形式的消息應該是簡單且標準化的。這有兩個主要用例：（i）支付，無論是個人對個人還是個人對商家的服務，以及（ii）請求資金的 dapp，例如。上面的 Polymarket 例子。
跨鏈交換和 Gas 支付：應該有一個標準化的開放協議來表達跨鏈操作，例如“我在 Optimism 上發送 1 ETH 給在 Arbitrum 上發送 0.9999 ETH 的人”，以及“我在 Optimism 上發送 0.0001 ETH”任何人在 Arbitrum 上包含此交易”。 ERC-7683 是對前者的嘗試，而 RIP-7755 是對後者的嘗試，儘管兩者都比這些特定用例更通用。
輕客戶端：用戶應該能夠實際驗證他們正在交互的鏈，而不僅僅是信任 RPC 提供商。 A16z 加密貨幣的 Helios 為以太坊本身做到了這一點，但我們需要將這種去信任性擴展到 L2。 ERC-3668（CCIP-read）是實現此目的的一種策略。
輕客戶端如何更新其以太坊標頭鏈的視圖。一旦有了標頭鏈，您就可以使用 Merkle 證明來驗證任何狀態對象。一旦你擁有了正確的 L1 狀態對象，你就可以使用 Merkle 證明（如果你想檢查預先確認，還可能使用簽名）來驗證 L2 上的任何狀態對象。Helios 已經做到了前者。擴展到後者是標準化的挑戰。
密鑰庫錢包：如今，如果您想更新控制智能合約錢包的密鑰，則必須在該錢包所在的所有 N 個鏈上執行此操作。密鑰庫錢包是一種技術，允許密鑰存在於一個位置（無論是在 L1 上，還是稍後可能在 L2 上），然後從任何擁有錢包副本的 L2 中讀取。這意味著更新只需要發生一次。為了提高效率，密鑰庫錢包要求 L2 有一種標準化的方式來無成本地讀取 L1；對此的兩個建議是 L1SLOAD 和 REMOTESTATICCALL。
密鑰庫錢包如何工作的程式化圖表。
更激進的“共享代幣橋”想法：想象一個所有 L2 都是有效性證明彙總的世界，每個插槽都致力於以太坊。即使在這個世界上，“本地”將資產從一個 L2 轉移到另一個 L2 也需要提取和存款，這需要支付大量的 L1 Gas。解決這個問題的一種方法是創建一個共享的最小彙總，其唯一功能是維護哪個 L2 擁有多少種類型的代幣的餘額，並允許通過一系列交叉來集體更新這些餘額。由任意 L2 發起的 L2 發送操作。這將允許跨 L2 傳輸發生，而無需每次傳輸支付 L1 Gas，也不需要基於流動性提供者的技術（如 ERC-7683）。
同步可組合性：允許在特定 L2 和 L1 之間或多個 L2 之間發生同步調用。這可能有助於提高 defi 協議的財務效率。前者可以在沒有任何跨 L2 協調的情況下完成；後者需要共享測序。基於彙總自動對所有這些技術友好。
與現有研究有哪些聯繫？
鏈特定地址：ERC-3770：https://eips.ethereum.org/EIPS/eip-3770
ERC-7683：https://eips.ethereum.org/EIPS/eip-7683
RIP-7755：https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
滾動密鑰庫錢包設計：https://hackmd.io/@haichen/keystore
Helios: https://github.com/a16z/helios
ERC-3668（有時稱為 CCIP-read）：https://eips.ethereum.org/EIPS/eip-3668
Justin Drake 提出的“基於（共享）預確認”的提案：https://ethresear.ch/t/based-preconfirmations/17353
L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
樂觀中的遠程調用：https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
AggLayer，其中包括共享令牌橋的想法：https://github.com/AggLayer
還需要做什麼，需要權衡什麼？
上面的許多例子都面臨著何時標準化以及標準化哪些層的標準困境。如果標準化太早，您可能會面臨劣質解決方案的風險。如果標準化得太晚，就有可能造成不必要的碎片化。在某些情況下，既有性能較弱但更容易實施的短期解決方案，也有“最終正確”但需要相當長的時間才能實現的長期解決方案。
本節的獨特之處在於，這些任務不僅僅是技術問題：它們也是（也許主要是！）社會問題。他們需要 L2 和錢包以及 L1 進行合作。我們成功處理這個問題的能力是對我們作為一個社區團結在一起的能力的考驗。
它如何與路線圖的其他部分交互？
這些建議中的大多數都是“更高層”的結構，因此不會對 L1 考慮產生太大影響。一個例外是共享排序，它對 MEV 影響很大。
擴展 L1 上的執行
我們要解決什麼問題？
如果 L2 變得非常可擴展且成功，但 L1 仍然只能處理非常少量的交易，那麼以太坊可能會出現許多風險：
ETH 資產的經濟狀況變得更加危險，進而影響網絡的長期安全。
許多L2受益於與L1上高度發達的金融生態系統的緊密聯繫，如果這個生態系統大大削弱，成為L2（而不是獨立的L1）的動力就會減弱。
L2 需要很長時間才能擁有與 L1 完全相同的安全保證。
如果 L2 發生故障（例如，由於惡意操作或消失的運營商），用戶仍然需要通過 L1 才能恢復其資產。因此，L1 需要足夠強大，至少能夠偶爾真正處理 L2 的高度複雜和混亂的結束。
出於這些原因，繼續擴展 L1 本身並確保它能夠繼續適應越來越多的用途是很有價值的。
它是什麼以及它是如何工作的？
最簡單的擴展方法就是簡單地增加 Gas 限制。然而，這存在中心化 L1 的風險，從而削弱了使以太坊 L1 如此強大的另一個重要屬性：其作為強大基礎層的可信度。關於簡單 Gas 限制增加到什麼程度是可持續的一直存在爭論，並且這也會根據其他技術的實施而發生變化，以使更大的區塊更容易驗證（例如歷史到期、無狀態、L1 EVM 有效性證明）。另一個需要不斷改進的重要事情就是以太坊客戶端軟件的效率，它今天比五年前更加優化。有效的 L1 Gas 限制增加策略將涉及加速這些驗證技術。
另一種擴展策略涉及識別特定的功能和計算類型，這些功能和計算類型可以在不損害網絡分散性或其安全屬性的情況下變得更便宜。這方面的例子包括：
EOF - 一種新的 EVM 字節碼格式，對靜態分析更加友好，可以實現更快的實現。考慮到這些效率，可以給予 EOF 字節碼較低的 Gas 成本。
多維 Gas 定價 - 建立單獨的基本費用以及計算、數據和存儲的限制可以增加以太坊 L1 的平均容量，而不增加其最大容量（從而產生新的安全風險）。
降低特定操作碼和預編譯的 Gas 成本 - 從歷史上看，我們已經對某些定價過低的操作進行了幾輪 Gas 成本的增加，以避免拒絕服務攻擊。我們已經做得較少但可以做更多的事情，那就是降低價格過高的運營的Gas 成本。例如，加法比乘法便宜得多，但 ADD 和 MUL 操作碼的成本目前相同。我們可以使 ADD 更便宜，甚至更簡單的操作碼（例如 PUSH）更便宜。 EOF整體來說比較多。
EVM-MAX 和 SIMD：EVM-MAX（“模塊化算術擴展”）是一項提議，允許更高效的本機大數模塊化數學作為 EVM 的單獨模塊。由 EVM-MAX 計算計算出的值只能由其他 EVM-MAX 操作碼訪問，除非故意導出；這允許有更大的空間以優化的格式存儲這些值。 SIMD（“單指令多數據”）是一種允許在值數組上高效執行相同指令的提議。兩者一起可以與 EVM 一起創建一個強大的協處理器，可用於更有效地實現加密操作。這對於隱私協議和 L2 證明系統特別有用，因此它將有助於 L1 和 L2 擴展。
這些改進將在以後關於 Splurge 的文章中更詳細地討論。
最後，第三種策略是本機彙總（或“內置彙總”）：本質上，創建並行運行的 EVM 的許多副本，從而形成一個與彙總可以提供的模型等效的模型，但更原生地集成到協議中。
與現有研究有哪些聯繫？
Polynya 的以太坊 L1 擴容路線圖：https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
多維Gas定價：https://vitalik.eth.limo/general/2024/05/09/multidim.html
EIP-7706：https://eips.ethereum.org/EIPS/eip-7706
EOF：https://evmobjectformat.org/
EVM-MAX：https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
SIMD：https://eips.ethereum.org/EIPS/eip-616
本機彙總：https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
採訪 Max Resnick 關於擴展 L1 的價值：https://x.com/BanklessHQ/status/1831319419739361321
Justin Drake 關於使用 SNARK 和本機彙總進行擴展：https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
還需要做什麼，需要權衡什麼？
L1 縮放有三種策略，可以單獨或並行執行：
改進技術（例如客戶端代碼、無狀態客戶端、歷史過期）使 L1 更容易驗證，然後提高 Gas 限制
降低特定操作的成本，在不增加最壞情況風險的情況下提高平均容量
本機彙總（即“創建 EVM 的 N 個並行副本”，儘管可能為開發人員在部署副本的參數方面提供了很大的靈活性）
值得理解的是，這些是具有不同權衡的不同技術。例如，本機彙總在可組合性方面與常規彙總有許多相同的弱點：您無法發送單個事務來跨多個事務同步執行操作，就像您可以在同一 L1（或 L2）上處理合約一樣。提高 Gas 限制會剝奪通過使 L1 更易於驗證而可以實現的其他好處，例如增加運行驗證節點的用戶比例以及增加單獨的抵押者。使 EVM 中的特定操作更便宜（具體取決於操作方式）可能會增加 EVM 的總體複雜性。
任何 L1 擴展路線圖都需要回答的一個大問題是：L1 和 L2 的最終願景是什麼？顯然，所有事情都在 L1 上進行是荒謬的：潛在的用例每秒有數十萬個事務，這將使 L1 完全無法驗證（除非我們採用本機彙總路線）。但我們確實需要一些指導原則，這樣我們才能確保我們不會造成這樣的情況：我們將 Gas 限制提高 10 倍，嚴重損害以太坊 L1 的去中心化，並發現我們只是進入了一個世界，而不是99% 的活動都在 L2 上，90% 的活動都在 L2 上，因此結果看起來幾乎相同，除了以太坊 L1 的特殊性的大部分不可逆轉的損失。
一種關於 L1 和 L2 之間“分工”的提議觀點
它如何與路線圖的其他部分交互？
讓更多用戶進入 L1 意味著不僅要改善規模，還要改善 L1 的其他方面。這意味著更多的 MEV 將保留在 L1 上（而不是僅僅成為 L2 的問題），因此更迫切需要明確地處理它。它極大地增加了 L1 上快速時隙時間的價值。它還在很大程度上依賴於 L1（“The Verge”）的驗證是否順利。
