作者:Vitalik Buterin
编译:Karen,Foresight News
特别鸣谢 Justin Drake、Francesco、Hsiao-wei Wang、@antonttc 和 Georgios Konstantopoulos。
起初,以太坊的路线图中有两种扩容策略。一种(参见 2015 年的一篇早期论文)是「分片」(sharding):每个节点只需要验证和存储一小部分交易,而不是验证和存储链中的所有交易。其他任何点对点网络(例如 BitTorrent)也是这样工作的,所以我们当然可以让区块链以同样的方式工作。另一种是 Layer2 协议:这些网络将位于以太坊之上,使其能够充分受益于其安全性,同时使大部分数据和计算保持在主链之外。Layer2 协议是指 2015 年的 state channels,2017 年的 Plasma,然后是 2019 年的 Rollup。Rollup 比 state channels 或 Plasma 更强大,但它们需要大量的链上数据带宽。幸运的是,到 2019 年,分片研究已经解决了大规模验证「数据可用性」的问题。结果,两条路径融合在一起,我们得到了以 Rollup 为中心的路线图,该路线图今天仍然是以太坊的扩展策略。
The Surge,2023 路线图版
以 Rollup 为中心的路线图提出了一个简单的分工:以太坊 L1 专注于成为一个强大且去中心化的基础层,而 L2 则承担帮助生态系统扩展的任务。这种模式在社会上无处不在:法院系统(L1)的存在不是为了追求超高速和高效,而是为了保护合同和财产权,而创业者(L2)则要在这一稳固的基础层之上进行建设,带领人类走向(无论是字面还是比喻意义上的)火星。
今年,以 Rollup 为中心的路线图取得了重要成果:随着 EIP-4844 blobs 的推出,以太坊 L1 的数据带宽大幅增加,多个以太坊虚拟机(EVM)Rollup 已进入第一阶段。每个 L2 都作为具有自身内部规则和逻辑的「分片」存在,分片实现方式的多样性和多元化如今已成为现实。但正如我们所见,走这条路也面临着一些独特的挑战。因此,我们现在的任务是完成以 Rollup 为中心的路线图,并解决这些问题,同时保持以太坊 L1 所特有的稳健性和去中心化。
The Surge:关键目标
1、未来以太坊通过 L2 可以达到 10 万以上的 TPS;
2、保持 L1 的去中心化和鲁棒性;
3、至少一些 L2 完全继承了以太坊的核心属性(去信任、开放、抗审查);
4、以太坊应该感觉像一个统一的生态系统,而不是 34 个不同的区块链。
本章内容
可扩展性三角悖论
数据可用性采样的进一步进展
数据压缩
Generalized Plasma
成熟的 L2 证明系统
跨 L2 互操作性改进
在 L1 上扩展执行
可扩展性三角悖论
可扩展性三角悖论是 2017 年提出的一个想法,它认为区块链的三个特性之间存在矛盾:去中心化(更具体地说:运行节点的成本低)、可扩展性(处理的交易数量多)和安全性(攻击者需要破坏网络中很大一部分节点才能使单笔交易失败)。
值得注意的是,三角悖论不是一个定理,介绍三角悖论的帖子也没有附带数学证明。它确实给出了一个启发式的数学论点:如果一个去中心化友好的节点(例如消费类笔记本电脑)每秒可以验证 N 笔交易,并且你有一个每秒处理 k*N 笔交易的链,那么 (i) 每笔交易只能被 1/k 个节点看到,这意味着攻击者只需破坏少数节点就能通过一笔恶意交易, 或 (ii) 你的节点将变得强大,而你的链不会去中心化。这篇文章的目的从不是证明打破三角悖论论是不可能的;相反,它旨在表明打破三元悖论是困难的,它需要在某种程度上跳出该论证所隐含的思维框架。
多年来,一些高性能链常声称它们在不从根本上改变架构的情况下就解决了三元悖论,通常是通过运用软件工程技巧来优化节点。这总是具有误导性的,在这些链上运行节点比在以太坊上运行节点要困难得多。本篇文章将探讨为何会如此,以及为什么仅凭 L1 客户端软件工程本身无法扩展以太坊?
然而,数据可用性采样与 SNARKs 的结合确实解决了三角悖论:它允许客户端在仅下载少量数据并执行极少量计算的情况下,验证一定数量的数据是可用的,并且一定数量的计算步骤是正确执行的。SNARKs 是无需信任的。数据可用性采样具有一种微妙的 few-of-N 信任模型,但它保留了不可扩容链所具有的基本特性,即即使是 51% 的攻击也无法强制坏块被网络接受。
解决三难困境的另一种方法是 Plasma 架构,它使用巧妙的技术,以激励兼容的方式将监视数据可用性的责任推给用户。早在 2017-2019 年,当我们只有欺诈证明这一手段来扩展计算能力时,Plasma 在安全执行方面非常受限,但随着 SNARKs(零知识简洁非交互式论证)的普及,Plasma 架构对于比以往更广泛的使用场景变得更加可行。
数据可用性采样的进一步进展
我们正在解决什么问题?
2024 年 3 月 13 日,当 Dencun 升级上线时,以太坊区块链每 12 秒的 slot 有 3 个约 125 kB blob,或每个 slot 的数据可用带宽约 375 kB。假设交易数据直接在链上发布,则 ERC20 转账约为 180 字节,因此以太坊上 Rollup 的最大 TPS 为:375000 / 12 / 180 = 173.6 TPS
如果我们加上以太坊的 calldata(理论最大值:每个 slot 3000 万 Gas / 每字节 16 gas = 每个 slot 1,875,000 字节),则变为 607 TPS。使用 PeerDAS,blob 数量可能会增加到 8-16,这将为 calldata 提供 463-926 TPS。
这是对以太坊 L1 的重大提升,但还不够。我们想要更多的可扩展性。我们的中期目标是每个 slot 16 MB,如果结合 Rollup 数据压缩的改进,将带来 ~58000 TPS。
它是什么?如何运行?
PeerDAS 是「1D sampling」的一个相对简单的实现。在以太坊中,每个 blob 都是一个在 253 位素数域(prime field)上的 4096 次多项式(polynomial)。我们广播多项式的 shares,其中每个 shares 包含从总共 8192 个坐标中相邻的 16 个坐标上的 16 个评估值。在这 8192 个评估值中,任何 4096 个(根据当前提出的参数:128 个可能样本中的任何 64 个)都可以恢复 blob。
PeerDAS 的工作原理是让每个客户端侦听少量子网,其中第 i 个子网广播任何 blob 的第 i 个样本,并通过询问全球 p2p 网络中的对等方(谁将侦听不同的子网)来请求它需要的其他子网上的 blob。更保守的版本 SubnetDAS 仅使用子网机制,而没有额外的询问对等层。当前的提案是让参与权益证明的节点使用 SubnetDAS,而其他节点(即客户)使用 PeerDAS。
从理论上讲,我们可以将一「1D sampling」规模扩展得相当大:如果我们将 blob 的最大数量增加到 256(目标为 128),那么我们就能达到 16MB 的目标,而数据可用性采样中每个节点 16 个样本 * 128 个 blob * 每个 blob 每个样本 512 字节 = 每个 slot 1 MB 的数据带宽。这只是勉强在我们的容忍范围内:这是可行的,但这意味着带宽受限的客户端无法采样。我们可以通过减少 blob 数量和增加 blob 大小来对此进行一定程度的优化,但这会使重建成本更高。
因此,我们最终想要更进一步,进行 2D 采样(2D sampling),这种方法不仅在 blob 内进行随机抽样,还在 blob 之间进行随机抽样。利用 KZG 承诺的线性属性,通过一组新的虚拟 blob 来扩展一个区块中的 blob 集,这些虚拟 blob 冗余地编码了相同的信息。
因此,最终我们想更进一步,进行 2D 采样,它不仅在 blob 内,而且在 blob 之间进行随机采样。KZG 承诺的线性属性用于扩展一个区块中的 blob 集,其中包含对相同信息进行冗余编码的新虚拟 blob 列表。
2D 采样。资料来源:a16z crypto
至关重要的是,计算承诺的扩展并不需要有 blob,因此该方案从根本上来说对分布式区块构建是友好的。实际构建区块的节点只需要拥有 blob KZG 承诺,并且它们可以依赖数据可用性采样(DAS)来验证数据块的可用性。一维数据可用性采样(1D DAS)本质上也对分布式块构建友好。
有哪些与现有研究的链接?
介绍数据可用性的原始帖子 (2018):https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
Follow-up paper: https://arxiv.org/abs/1809.09044
关于 DAS 的解释文章,paradigm: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 几乎与整个 blob 一样大。
我认为的长期现实路径是:
实施理想的 2D DAS;
坚持使用 1D DAS,牺牲采样带宽效率,为了简单性和鲁棒性而接受较低的数据上限
放弃 DA,完全接受 Plasma 作为我们关注的主要 Layer2 架构。
请注意,即使我们决定直接在 L1 层扩展执行,这种选择也是存在的。这是因为如果 L1 层要处理大量的 TPS,L1 区块将变得非常大,客户端将希望有一种高效的方法来验证它们的正确性,因此我们将不得不在 L1 层使用与 Rollup(如 ZK-EVM 和 DAS)相同的技术。
如何与路线图的其他部分交互?
如果实现数据压缩,对 2D DAS 的需求会有所减少,或者至少会延迟,如果 Plasma 被广泛使用,则需求会进一步减少。DAS 也对分布式区块构建协议和机制提出了挑战:虽然 DAS 理论上对分布式重建友好,但这在实践中需要与包 inclusion list 提案及其周围的分叉选择机制相结合。
数据压缩
我们在解决什么问题?
Rollup 中的每笔交易都会占用大量的链上数据空间:ERC20 传输大约需要 180 字节。即使有理想的数据可用性采样,这也限制了 Layer 协议的可扩展性。每个 slot 16 MB,我们得到:
16000000 / 12 / 180 = 7407 TPS
如果我们不仅能解决分子的问题,还能解决分母的问题,让每个 Rollup 中的交易在链上占用更少的字节,那会怎样?
它是什么,如何工作?
在我看来,最好的解释是两年前的这张图:
零字节压缩中,用两个字节替换每个长的零字节序列,表示有多少个零字节。更进一步,我们利用了交易的特定属性:
签名聚合:我们从 ECDSA 签名切换到 BLS 签名,BLS 签名的特性是多个签名可以组合成一个单一的签名,该签名可以证明所有原始签名的有效性。在 L1 层中,由于即使进行聚合,验证的计算成本也较高,因此不考虑使用 BLS 签名。但在 L2 这样数据稀缺的环境中,使用 BLS 签名是有意义的。ERC-4337 的聚合特性为实现这一功能提供了一条途径。
用 pointers 替换地址:如果以前使用过某个地址,我们可以将 20 字节的地址替换为指向历史记录中某个位置的 4 字节 pointer。
交易值的自定义序列化——大多数交易值的位数很少,例如,0.25 ETH 表示为 250,000,000,000,000,000 wei。最大基础手续费和优先手续费也类似。因此,我们可以使用自定义的十进制浮点格式,来表示大多数货币值。
有哪些与现有研究的链接?
探索 sequence.xyz:https://sequence.xyz/blog/compressing-calldata
L2 Calldata 优化合约:https://github.com/ScopeLift/l2-optimizoooors
基于有效性证明的 Rollups(又名 ZK rollups)发布状态差异而不是交易:https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
BLS 钱包 - 通过 ERC-4337 实现 BLS 聚合:https://github.com/getwax/bls-wallet
还需做什么,有哪些权衡?
接下来主要要做的是实际实现上述方案。主要的权衡包括:
1、切换到 BLS 签名需要付出很大努力,并且会降低与能够增强安全性的可信硬件芯片的兼容性。可以使用其他签名方案的 ZK-SNARK 封装来替代它。
2、动态压缩(例如,用 pointers 替换地址)会使客户端代码变得复杂。
3、将状态差异发布到链上而不是交易,会降低可审计性,并使很多软件(例如区块浏览器)无法工作。
如何与路线图的其他部分交互?
采用 ERC-4337,并最终将其部分内容纳入 L2 EVM 中,可以大大加快聚合技术的部署。将 ERC-4337 的部分内容放在 L1 上可以加快其在 L2 上的部署。
Generalized Plasma
我们正在解决什么问题?
即使使用 16 MB 的 blob 和数据压缩,58,000 TPS 也未必足以完全满足消费者支付、去中心化社交或其他高带宽领域的需求,尤其是当我们开始考虑隐私因素时,这可能会使可扩展性降低 3-8 倍。对于高交易量、低价值的应用场景,目前的一种选择是使用 Validium,它将数据保存在链下,并采用了一种有趣的安全模型:运营商无法窃取用户的资金,但他们可能会暂时或永久冻结所有用户的资金。但我们可以做得更好。
它是什么,如何工作?
Plasma 是一种扩容解决方案,它涉及到一个运营商将区块发布到链下,并将这些区块的 Merkle 根放到链上(与 Rollup 不同,Rollup 会将完整的区块放到链上)。对于每个区块,运营商会向每个用户发送一个 Merkle 分支来证明该用户的资产发生了什么变化,或者没有发生什么变化。用户可以通过提供 Merkle 分支来提取他们的资产。重要的是,这个分支不必以最新状态为根。因此,即使数据可用性出现问题,用户仍然可以通过提取他们可用的最新状态来恢复他们的资产。如果用户提交了一个无效的分支(例如,提取他们已经发送给其他人的资产,或者运营商自己凭空创造了一个资产),则可以通过链上的挑战机制来判断资产的合法归属。
Plasma Cash chain 图。花费硬币 i 的交易被放在 tree 中的第 i 个位置。在此示例中,假设所有先前的 tree 都有效,我们知道 Eve 当前拥有代币 1,David 拥有代币 4,George 拥有代币 6。
早期的 Plasma 版本仅能处理支付用例,无法有效地进一步推广。然而,如果我们要求每个根都用 SNARK 进行验证,那么 Plasma 就会变得强大得多。每个挑战游戏都可以大大简化,因为我们排除了运营商作弊的大部分可能路径。同时,也开辟了新的路径,使 Plasma 技术能够扩展到更广泛的资产类别。最后,在运营商不作弊的情况下,用户可以立即提取资金,而无需等待一周的挑战期。
制作 EVM Plasma 链的一种方法(不是唯一的方法):使用 ZK-SNARK 构建一个并行的 UTXO 树,该 tree 反映了 EVM 所做的余额变化,并定义了在历史不同时间点的「同一代币」的唯一映射。然后可以在其上构建 Plasma 结构。
一个关键的见解是,Plasma 系统并不需要完美。即使你只能保护资产的子集(例如,仅仅是过去一周内未移动的代币),你也已经大大改善了当前超可扩展 EVM(即 Validium)的现状。
另一类结构是是混合 Plasma/Rollup,例如 Intmax。这些构造将每个用户的极少量数据放到链上(例如,5 个字节),这样做可以获得介于 Plasma 和 Rollup 之间的某些特性:在 Intmax 的情况下,你可以获得非常高的可扩展性和隐私性,尽管即使在 16 MB 的容量中,理论上也限制在大约 16,000,000 / 12 / 5 = 266,667 TPS 之间。
有哪些与现有研究相关的链接?
Original Plasma paper: https://plasma.io/plasma-deprecated.pdf
Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#?-Exit
Intmax (2023): https://eprint.iacr.org/2023/1082
还需做什么?有哪些权衡?
剩下的主要任务是将 Plasma 系统投入实际生产应用。如上所述 Plasma 与 Validium”并非是一个非此即彼的选择:任何 Validium 都可以通过在其退出机制中融入 Plasma 特性来至少在一定程度上提升其安全属性。研究的重点在于为 EVM 获得最佳属性(从信任需求、最坏情况下的 L1 Gas 成本以及抵御 DoS 攻击的能力等方面考虑),以及替代的特定应用结构。此外,相对于 Rollup,Plasma 在概念上的复杂性更高,这需要通过研究和构建更好的通用框架来直接解决。
使用 Plasma 设计的主要权衡在于它们更多地依赖于运营商,并且更难 based,尽管混合 Plasma/Rollup 设计通常可以避免这一弱点。
如何与路线图的其他部分交互?
Plasma 解决方案越有效,L1 具有高性能数据可用性功能的压力就越小。将活动移至 L2 还可以减少 L1 上的 MEV 压力。
成熟的 L2 证明系统
我们正在解决什么问题?
目前,大多数 Rollup 实际上还不是去信任的。存在一个安全委员会,它有能力 override(optimistic 或 validity)证明系统的行为。在某些情况下,证明系统甚至完全不运行,或者即使运行,也仅具有「咨询」功能。最先进的 Rollup 包括:(i)一些去信任的应用特定 Rollup,如 Fuel;(ii)截至本文撰写之时,Optimism 和 Arbitrum 是两个实现了被称为「第一阶段」的部分无需信任里程碑的全 EVM Rollup。Rollup 未能取得更大进展的原因是担心代码中存在 bug。我们需要无需信任的 Rollup,因此必须直面并解决这个问题。
它是什么,如何工作?
首先,让我们回顾一下本文中最初介绍的 「stage」 系统。
阶段 0:用户必须能够运行节点并同步链。如果验证是完全可信 / 集中的,那也没关系。
阶段 1:必须有一个(无需信任的)证明系统,确保只有有效的交易才会被接受。允许有一个可以推翻证明系统的安全委员会,但必须有 75% 的门槛投票。此外,委员会中 quorum-blocking 部分(即 26%+)必须在构建 Rollup 的主公司之外。允许使用功能较弱的升级机制(例如 DAO),但它必须有足够长的延迟,如果它批准了恶意升级,用户可以在资金上线之前撤出他们的资金。
阶段 2:必须有一个(无需信任的)证明系统,确保只有有效的交易才会被接受。安全委员会只允许在代码中存在可证明的错误时进行干预,例如。如果两个冗余的证明系统彼此不一致,或者如果一个证明系统接受同一个区块的两个不同的后 post-state 根(或在足够长的时间内不接受任何内容,例如一周)。允许使用升级机制,但必须具有很长的延迟。
我们的目标是达到第 2 阶段。达到第 2 阶段的主要挑战是获得足够的信心,证明系统实际上足够值得信赖。有两种主要方法可以执行此操作:
形式化验证:我们可以使用现代数学和计算技术来证明(optimistic 和 validity)证明系统只接受通过 EVM 规范的区块。这些技术已经存在了几十年,但最近的进步(如 Lean 4)使它们更加实用,而 AI 辅助证明的进步可能会进一步加速这一趋势。
多证明(Multi-provers):制作多个证明系统,并将资金投入这些证明系统与安全委员会(或其他具有信任假设的小工具,例如 TEE)。如果证明系统同意,安全委员会就没有权力;如果他们不同意,安全委员会只能在其中之一之间做出选择,它不能单方面强加自己的答案。
多证明者的程式化图,结合了一个 optimistic 证明系统、一个有效性证明系统和一个安全委员会。
有哪些与现有研究的链接?
EVM K Semantics (formal verification work from 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 证明者的正式验证版本。这是一个极其复杂的项目,尽管我们已经开始进行了。有一个技巧可以大大简化这项任务:我们可以为一个最小化的虚拟机(例如 RISC-V 或 Cairo)创建一个经过形式化验证的 SNARK 证明器,然后在该最小化虚拟机中实现 EVM(并形式化证明它与其他以太坊虚拟机规范的等效性)。
对于多证明而言,还有两个主要的部分尚未完成。首先,我们需要对至少两个不同的证明系统有足够的信心,既要确保它们各自都相当安全,也要确保如果它们出现问题,那么这些问题应该是不同且不相关的(因此它们不会同时出现问题)。其次,我们需要对合并证明系统的底层逻辑有非常高的信任度。这部分代码要少得多。有一些方法可以使其非常小,只需将资金存储在一个由代表各个证明系统的合约作为签署者的安全多签(Safe multisig)合约中,但这会增加链上的 Gas 成本。我们需要在效率和安全性之间找到某种平衡。
如何与路线图的其他部分交互?
将活动移至 L2 可降低 L1 上的 MEV 压力。
跨 L2 互操作性改进
我们正在解决什么问题?
当今 L2 生态系统面临的一个主要挑战是用户难以在其中导航。此外,最简便的方法通常又会重新引入信任假设:中心化跨链、RPC 客户端等等。我们需要让使用 L2 生态系统的感觉就像是在使用一个统一的以太坊生态系统一样。
它是什么? 如何工作?
跨 L2 互操作性改进有很多类别。从理论上讲,以 Rollup 为中心的以太坊与执行分片 L1 是一回事。当前以太坊 L2 生态系统在实践中距离理想状态还有这些不足:
1、特定链的地址:地址中应包含链信息(L1、Optimism、Arbitrum……)。一旦实现这一点,就可以通过简单地将地址放入“发送”字段来实现跨 L2 发送流程,此时钱包可以在后台自行处理如何发送(包括使用跨链协议)。
2、特定链的支付请求:应能够轻松且标准化地创建形式为「在链 Z 上向我发送 X 个 Y 类型的代」的消息。这主要有两个应用场景:(i)无论是人与人之间的支付还是人与商户服务之间的支付;(ii)DApp 请求资金。
3、跨链兑换和 Gas 支付:应有一个标准化的开放协议来表达跨链操作,如「我将向在 Arbitrum 上向我发送 0.9999 个以太币的人发送 1 个以太币(在 Optimism 上)」,以及「我将向在 Arbitrum 上包含此交易的人发送 0.0001 个以太币(在 Optimism 上)」。ERC-7683 是对前者的尝试,而 RIP-7755 是对后者的尝试,尽管这两者的应用范围都比这些特定用例更广。
4、轻客户端:用户应能够实际验证他们正在交互的链,而不仅仅是信任 RPC 提供商。a16z crypto 的 Helios 可以做到这一点(针对以太坊本身),但我们需要将这种去信任性扩展到 L2 上。ERC-3668(CCIP-read)是实现这一目标的一种策略。
轻客户端如何更新其 Ethereum header chain 的视图。拥有 header chain 后,可以使用 Merkle 证明来验证任何状态对象。一旦你有了正确的 L1 状态对象,就可以使用 Merkle 证明(如果你想检查预确认,还可以使用签名)来验证 L2 上的任何状态对象。Helios 已经做到了前者。扩展到后者是一项标准化挑战。
1、Keystore 钱包:如今,如果你想更新控制你的智能合约钱包的密钥,你必须在该钱包存在的所有 N 条链上都进行更新。Keystore 钱包是一种技术,它允许密钥只存在于一个地方(要么在 L1 上,要么以后可能在 L2 上),然后任何拥有钱包副本的 L2 都可以从中读取密钥。这意味着更新只需进行一次。为了提高效率,Keystore 钱包要求 L2 具有一种标准化的方式来无成本地读取 L1 上的信息;对此有两个提案,分别是 L1SLOAD 和 REMOTESTATICCALL。
Keystore 钱包工作原理
2、更激进的「共享代币桥」理念:想象一下,在一个所有 L2 都是有效性证明 Rollup 且每个 slot 都向以太坊提交的世界。即使在这样的世界中,要在原生状态下将一个 L2 的资产转移到另一个 L2,仍然需要提现和存款,这需要支付大量的 L1 Gas 费。解决这一问题的一种方法是创建一个共享的极简 Rollup,它的唯一功能就是维护每种类型的代币由哪个 L2 拥有以及各拥有多少余额,并允许这些余额通过任何 L2 发起的一系列跨 L2 发送操作进行批量更新。这将使得跨 L2 转账无需每次转账都支付 L1 燃气费,也无需使用如 ERC-7683 等基于流动性提供者的技术。
3、同步组合性:允许在特定 L2 与 L1 之间或多个 L2 之间发生同步调用。这有助于提高 DeFi 协议的财务效率。前者可以在没有任何跨 L2 协调的情况下实现;后者则需要共享排序。基于 Rollup 的技术自动适用于所有这些技术。
有哪些与现有研究的链接?
链特定地址: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
Scroll keystore 钱包设计式样: https://hackmd.io/@haichen/keystore
Helios: https://github.com/a16z/helios
ERC-3668(有时称为 CCIP 读取):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
REMOTESTATICCALL in Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
AggLayer,其中包括共享代币桥的想法:https://github.com/AggLayer
还需做什么?有哪些权衡?
上面的许多示例都面临着何时标准化以及标准化哪些层的标准困境。如果标准化过早,可能会使一个较差的解决方案根深蒂固。如果标准化过晚,则可能会造成不必要的碎片化。在某些情况下,既存在一种属性较弱但更容易实施的短期解决方案,也存在一种「最终正确」但需要数年时间才能实现的长期解决方案。
这些任务不仅仅是技术问题,它们也是(甚至可能主要是)社会问题,需要 L2 和钱包以及 L1 合作。
如何与路线图的其他部分交互?
这些提案中的大多数都是 「更高层」结构,因此对 L1 层面的考虑影响不大。一个例外是共享排序,它对最大可提取价值(MEV)有着重大影响。
在 L1 上扩展执行
我们正在解决什么问题?
如果 L2 变得非常可扩展和成功,但 L1 仍然只能处理非常少量的交易量,那么以太坊可能会出现许多风险:
1、ETH 资产的经济状况将变得更加不稳定,这反过来又会影响网络的长期安全性。
2、许多 L2 受益于与 L1 上高度发达的金融生态系统的紧密联系,如果这个生态系统大大削弱,那么成为 L2(而不是成为独立的 L1)的激励就会减弱。
3、L2 要达到与 L1 完全相同的安全保障还需要很长时间。
4、如果 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 (single instruction multiple data) 是一种允许对值数组有效执行相同指令的提案。两者一起可以在 EVM 旁边创建一个强大的协处理器,可用于更高效地实现加密操作。这对于隐私协议和 L2 防护系统特别有用,因此它将有助于 L1 和 L2 扩展。
这些改进将在以后的 Splurge 文章中更详细地讨论。
最后,第三种策略是原生 Rollups(或 enshrined rollups):本质上,创建许多并行运行的 EVM 副本,从而产生一个等同于 Rollup 可以提供的模型,但更多地原生集成到协议中。
有哪些与现有研究的链接?
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
Native rollups: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
Max Resnick 采访中关于扩展 L1 的价值:https://x.com/BanklessHQ/status/1831319419739361321
Justin Drake 谈使用 SNARK 和原生 Rollups 进行扩展:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
还需做什么,有哪些权衡?
L1 扩展有三种策略,可以单独或并行进行:
改进技术(例如客户端代码、无状态客户端、历史过期)以使 L1 更易于验证,然后提高 Gas 限制。
降低特定操作的成本,在不增加最坏情况风险的情况下增加平均容量;
原生 Rollups (即,创建 EVM 的 N 个并行副本)。
了解了这些不同的技术,我们会发现各有不同的权衡取舍。例如,原生 Rollups 在组合性方面存在许多与普通 Rollups 相同的弱点:你不能发送一个单一交易来跨多个 Rollup 同步执行操作,就像你可以在同一个 L1(或 L2)上的合约中做的那样。提高 Gas 上限会削弱通过简化 L1 验证可以实现的其他好处,比如增加运行验证节点的用户比例,以及增加 solo 质押者数量。根据实现方式的不同,使 EVM(以太坊虚拟机)中的特定操作更便宜可能会增加 EVM 的整体复杂性。
任何 L1 扩容路线图都需要回答的一个重大问题是:L1 和 L2 的最终愿景分别是什么?显然,把所有内容都放在 L1 上是荒谬的:潜在的应用场景可能涉及每秒数十万笔交易,这将使 L1 完全无法进行验证(除非我们采用原生 Rollup 的方式)。但我们确实需要一些指导原则,以确保我们不会陷入这样一种境地:Gas 上限提高 10 倍,严重损害以太坊 L1 的去中心化。
L1 和 L2 之间分工的一种观点
如何与路线图的其他部分交互?
将更多用户引入 L1 不仅意味着要提升扩展,还意味着要改善 L1 的其他方面。这意味着更多的 MEV 将留在 L1 上(而不是仅仅成为 L2 的问题),因此,明确处理 MEV 的需求将变得更加迫切。这将极大地提升 L1 上快速 slot 时间的价值。同时,这也极大地依赖于 L1(the Verge)验证的顺利进行。
推荐阅读:《Vitalik 新文:以太坊可能的未来,the Merge》