Vitalik新文丨以太坊协议可能的未来:The Surge
摘要: 以太坊 L1 专注于成为一个强大的去中心化基础层,而 L2 则承担起帮助生态扩展的任务。比如法院系统(L1)并不是为了超高的案件处理效率而存在的,它是为了保护合同和产权,而企业家们(L2)则是为了在这个坚固的基础层之上,将人类带上火星。
撰文:Vitalik Buterin
编译:Yangz,Techub News
起初,以太坊的路线图中有两种扩展策略。其一(可参见 2015 年的早期论述)是「分片」(sharding):每个节点只需验证和存储链上的一小部分交易,而不是所有交易。任何其他点对点网络(如 BitTorrent)都是这样运行的,因此我们肯定也能让区块链以同样的方式运行。
另一种方法是 Layer 2 协议,即在以太坊之上建立网络,使其能够充分受益于以太坊的安全性,同时将大部分数据和计算放到主链之外。「Layer 2 协议」从 2015 年的状态通道(state channels),到 2017 年的 Plasma,最后在 2019 年发展为 Rollups。Rollups 比前两者更强大,但也需要大量链上数据带宽。幸运的是,到 2019 年,分片研究已经解决了大规模验证「数据可用性」的问题。
因此,这两条道路交汇在了一起,我们有了以 Rollup 为中心的路线图,这也是以太坊今天的扩展策略。
The Surge,2023 年路线图版本
以太坊 L1 专注于成为一个强大的去中心化基础层,而 L2 则承担起帮助生态扩展的任务。这种模式在社会中随处可见,比如法院系统(L1)并不是为了超高的案件处理效率而存在的,它是为了保护合同和产权,而企业家们(L2)则是为了在这个坚固的基础层之上,将人类带上火星。
今年,以太坊以 Rollup 为中心的路线图取得了重大成功:以太坊 L1 数据带宽随着 EIP-4844 blobs 的使用而大大增加,多个 EVM Rollups 现在处于第一阶段。此外,分片的异构和多元化实现已经成为现实,每个 L2 都可作为一个「分片」,有自己的内部规则和逻辑。但是,正如我们所看到的,走这条路本身也有一些独特的挑战。因此,我们目前的任务是完成以 Rollup 为中心的路线图,并解决这些问题,同时保持以太坊 L1 的鲁棒性和去中心化特性。
The Surge 的主要目标:
- 在 L1+L2 上实现 10 万+ TPS
- 保留 L1 的去中心化和鲁棒性
- 至少有一些 L2 完全继承以太坊的核心属性(去信任、开放、抗审查)
- L2 之间最大程度的互操作性。以太坊应该是一个生态系统,而不是 34 条不同的区块链
不可能三角
区块链「不可能三角」是我在 2017 年提出的一个观点,认为区块链的三个特性之间存在矛盾,包括去中心化(以低成本运行节点)、可扩展性(处理的交易数量多)和安全性(攻击者需要破坏整个网络中的大部分节点,才能使单笔交易失败)。
值得注意的是,不可能三角并不是一个定理,介绍该困境的帖子也没有附带数学证明。它确实给出了一个启发式的数学论证:如果一个对去中心化友好的节点(如消费者的笔记本电脑)每秒可以验证 N 笔交易,而你有一条每秒处理 k*N 笔交易的链,那么要么每笔交易只被 1/k 个节点看到,意味着攻击者只需要破坏几个节点就能将一笔糟糕的交易推送出去,要么节点就会变得很强大,而链就丢失了去中心化这一特性。当时的帖子并不是要说明打破不可能三角是不可能的;
相反,我想说明的是,打破该困境是很难的,需要以某种方式跳出论证所暗示的框框。 多年来,一些高性能链通常会称自己无需在基本架构层面做任何提升(通常是通过使用软件工程技巧来优化节点),就能解决不可能三角问题。这种说法往往具有误导性,在这种链上运行节点的难度其实比在以太坊上要大得多。这篇文章深入探讨了为什么会出现这种情况的许多微妙之处,同时也解释了为什么仅靠 L1 客户端软件工程无法扩展以太坊本身。
不过,数据可用性采样和 SNARKs 的结合确实解决了该困境。通过两者的结合,客户端可以验证一定数量的数据是否可用,以及一定数量的计算步骤是否正确执行,同时只下载其中一小部分数据,并运行小得多的计算量。SNARK 是去信任的,而数据可用性采样则有一个细微的 few-of-N 信任模型,但它保留了不可扩展链所具有的基本特性,即即使是 51% 的攻击也无法迫使网络接受有害区块。
解决不可能三角的另一种方法是 Plasma 架构,这种架构使用巧妙的技术,以一种激励兼容的方式将观察数据可用性的责任推给用户。早在 2017-2019 年,当我们只能通过欺诈证明来扩展计算规模时,Plasma 能安全完成的工作非常有限,但 SNARKs 的主流化使得 Plasma 架构在更广泛的用例中比以前更可行数据可用性采样的进一步进展。
数据可用性采样的进一步进展,我们要解决什么问题?
截至 2024 年 3 月 13 日,即 Dencun 升级上线之时,以太坊在每 12 秒 slot 中有三个约 125 kB 大小的「blob」,即每个 slot 有约 375 kB 的数据可用性带宽。假设交易数据是直接在链上发布的,ERC20 的传输量约为 180 字节,因此以太坊上 Rollups 的最大 TPS 为:375000/12/180 = 173.6 TPS 如果我们加上以太坊的 calldata(理论上最大值为:每 slot 3000 万 gas/每字节 16 gas = 每 slot 187.5 万字节),这就变成了 607 TPS。
对于 PeerDAS,我们的计划是将 blob 计数目标提高到 8-16,这将为我们提供 463-926 TPS 的 calldata。 这比以太坊 L1 有了很大的提升,但还不够。我们想要更高的可扩展性。我们的中期目标是每 slot 16 MB,如果结合 Rollup 数据压缩方面的改进,我们将获得约 5.8 万 TPS。
PeerDAS 是什么,如何运作?
PeerDAS 是「1D sampling」的一种相对简单的实现方式。以太坊中的每个 blob 都是 253 位素数域上的一个 4096 度多项式。我们广播多项式的「份额」(shares),每个份额由相邻 16 个坐标的 16 次估算组成,这些坐标取自总共 8192 个坐标。8192 次评估中的任意 4096 次估算(使用当前建议的参数:128 个可能样本中的任意 64 个)都可以恢复 blob。
PeerDAS 的运作原理是让每个客户端监听少数几个子网,其中第 i 个子网广播任何 blob 的第 i 个样本,并通过向全球 p2p 网络中的同行(监听不同子网的同行)询问它所需的其他子网上的 blob。一个更保守的版本是 SubnetDAS,它只使用子网机制,而没有询问同行的附加层。目前的建议是,参与权益证明的节点使用 SubnetDAS,其他节点使用 PeerDAS。
从理论上讲,我们可以将 1D sampling 扩展到相当大的范围。如果我们将 blob 计数最大值提高到 256(因此,目标值为 128),那么我们就能达到 16 MB 的目标值,而数据可用性采样只需耗费每 slot 1 MB (每个节点 16 个样本 * 128 个 blob * 每个 blob 每个样本 512 字节)的数据带宽即可。然而,这只勉强在我们的承受范围之内。我们可以做到,但这意味着带宽受限的客户端无法采样。我们可以通过减少 blob 数量和增大 blob 大小来进行优化,但这又会使重构成本提高。
因此,我们希望更进一步,进行 2D sampling,即不仅在 blob 内,而且在 blob 之间进行随机采样。我们利用 KZG 承诺的线性特性,通过冗余编码相同信息的新「虚拟 blobs」列表来「扩展」区块中的 blobs 集。
2D sampling;来源:a16z crypto
最重要的是,计算承诺的扩展并不需要拥有 blobs,因此该方案从根本上有利于分布式区块构建。实际构建区块的节点只需拥有 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
- Paradigm 关于 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 sampling 中可恢复性的细微差别:https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
还有哪些工作要做,如何权衡?
当务之急是完成 PeerDAS 的实施和推广。我们需要逐步增加 PeerDAS 上的 blob 数量,同时仔细观察网络并改进软件,以确保安全。与此同时,我们希望开展更多的学术工作,使 PeerDAS 和其他版本的 DAS 及其与分叉选择规则安全等问题的交互正规化。 未来,我们还需要做更多的工作,找出理想版本的 2D DAS 并证明其安全属性。我们还希望最终从 KZG 迁移到抗量子、无可信设置的替代方案。
目前,我们还不知道有哪些候选方案对分布式区块构建友好。即使使用费用极高的「暴力」技术,即使用递归 STARK 生成有效性证明来重建行和列也是不够的,因为从技术上讲,一个 STARK 的大小(使用 STIR)是 O(log(n) * log(log(n)) 哈希值,但实际上一个 STARK 几乎和整个 blob 一样大。 从长远来看,我认为最现实的途径是:
- 实现理想的 2D DAS
- 坚持 1D DAS,牺牲采样带宽效率并接受较低的数据上限,以求简单和稳健
- (硬支点)放弃 DA,完全采用 Plasma 作为我们关注的主要 layer 2 架构
我们可以根据下图来权衡这些问题:
请注意,即使我们决定直接在 L1 上扩展执行,这种选择也是存在的。因为,如果 L1 要处理大量的 TPS,那么 L1 区块就会变得非常大,而客户端需要一种有效的方式来验证它们是否正确,因此我们必须在 L1 上使用与 Rollup(ZK-EVM 和 DAS)相同的技术。
对路线图的其他部分有何影响?
如果实现了数据压缩(见下文),那么对 2D DAS 的需求就会有所减少,或者至少会有所延迟;如果 Plasma 得到广泛应用,那么对它的需求就会进一步减少。DAS 还对分布式区块构建协议和机制提出了挑战:虽然 DAS 在理论上对分布式重构是友好的,但在实践中需要与包含列表建议及其周围的分叉选择机制相结合。
数据压缩
我们要解决什么问题?
Rollup 中的每笔交易都会占用链上大量的数据空间:ERC20 的传输大约需要 180 个字节。即使有理想的数据可用性采样,也会对 Layer 2 协议的可扩展性造成限制。每个 slot 16 MB,我们可以得到:16000000/12/180 = 7407 TPS 如果除了解决分子的问题,我们还能解决分母的问题,让 Rollup 中的每笔交易在链上占用更少的字节,那会怎样?
如何进行数据压缩?
在我看来,两年前的这张图就是最好的解释: 最简单的增益就是零字节压缩:用代表零字节数量的两个字节替换每个长的零字节序列。为更进一步,我们利用了交易的特殊属性:
- 签名聚合:我们将 ECDSA 签名转换为 BLS 签名。BLS 签名的特性是,许多签名可以合并为一个签名,证明所有原始签名的有效性。这种方法在 L1 中没有被应用,因为即使使用聚合的方式,验证的计算成本也会更高,但在像 L2 这样数据稀缺的环境中,可以说这是合理的。ERC-4337 的聚合功能提供了一种实现途径。
- 用 pointer 取代地址:如果一个地址以前使用过,我们可以用一个指向历史位置的 4 字节 pointer 取代 20 字节的地址。要想获得最大收益,就必须这样做,不过实施起来需要付出努力,因为这需要(至少一部分)区块链历史有效地成为状态的一部分。
- 交易值的自定义序列化:大多数交易值的数字很少,例如 0.25 ETH 表示为 250,000,000,000,000,000 wei。Gas max-basefees 和优先级费用的工作原理类似。因此,我们可以使用自定义的十进制浮点格式,甚至是特别常用值的归集来简洁地表示大多数币值。
现有的相关研究
- 来自 sequence.xyz 的探索:https://sequence.xyz/blog/compressing-calldata
- 来自 ScopeLift 的针对 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
还有哪些工作要做,如何权衡?
剩下要做的主要是实际实施上述计划。主要的权衡是:
- 改用 BLS 签名需要耗费大量精力,而且会降低与可提高安全性的可信硬件芯片的兼容性。可以使用其他签名方案的 ZK-SNARK wrapper 来替代。
- 动态压缩(如用 pointers 替换地址)会使客户端代码复杂化。
- 将状态差异发布到链上而不是交易上会降低可审计性,并使许多软件(如区块浏览器)无法工作。
对路线图的其他部分有何影响?
采用 ERC-4337 并最终将其部分内容纳入 L2 EVM,可以大大加快聚合技术的部署。将 ERC-4337 的部分内容纳入 L1 可以加快其在 L2 上的部署。
Plasma
我们要解决什么问题?
即使使用 16 MB blobs 和数据压缩技术,58000 TPS 也不一定足以完全接管消费支付、去中心化社交或其他高带宽领域,如果我们开始考虑隐私问题,情况会变尤其明显,可能会使可扩展性下降 3-8 倍。对于高流量、低价值的应用,目前的一种选择是 validium,它将数据保存在链外,并有一个有趣的安全模型,即运营商无法窃取用户的资金,但他们可以消失,并暂时或永久冻结所有用户的资金。然而,我们可以做得更好。
Plasma 是什么,如何运作?
Plasma 是一种扩展解决方案,涉及运营商在链外发布区块,并将这些区块的 Merkle 根放到链上(与 Rollup 不同,Rollup 是将整个区块放到链上)。对于每个区块,运营者都会向每个用户发送一个 Merkle 分支,证明该用户的资产发生了什么或没有发生什么。用户可以通过提供 Merkle 分支来提取资产。
重要的是,该分支不必植根于最新状态。因此,即使数据可用性失效,用户仍可通过提取其可用的最新状态来恢复资产。如果用户提交了一个无效的分支(例如,撤回已经发送给他人的资产,或者运营者自己凭空创建了一个资产),链上质疑机制可以裁定资产的合法归属。
Plasma Cash chain 示意图
Plasma 的早期版本只能处理支付用例,无法有效地进一步推广。然而,如果我们要求每个根都要经过 SNARK 验证,Plasma 就会变得更加强大。每个挑战都可以大大简化,因为我们消除了运营者作弊的大部分可能途径。我们还开辟了新的途径,使 Plasma 技术可以扩展到更广泛的资产类别。最后,在运营者没有作弊的情况下,用户可以立即提取资金,而无需等待一周的挑战期。
打造 EVM plasma chain 的一种方法(并非唯一方法):使用 ZK-SNARK 构建一个平行的 UTXO 树,该树反映了 EVM 所做的平衡变化,并定义了历史上不同时刻「相同币」的独特映射。然后在此基础上构建 Plasma 结构。
需要注意的是,Plasma 系统并不需要完美无缺。即使你只能保护资产的一个子集,你也已经大大改善了超可扩展 EVM 的现状,这就是有效的。 另一类结构是混合 Plasma 和 Rollup,如 Intmax。这些结构将每个用户的极少量数据(例如 5 字节)放在链上,从而获得了介于 Plasma 和 Rollup 之间的特性:在 Intmax 中,你可以获得极高的可扩展性和隐私性,不过即使在 16 MB 的世界里,理论上容量上限也只有大约 16,000,000 / 12 / 5 = 266,667 TPS。
现有的相关研究
- Plasma: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#
- Intmax (2023):https://eprint.iacr.org/2023/1082
还有哪些工作要做,如何权衡?
剩下的主要任务是将 Plasma 系统投入生产。如上所述,Plasma 与 validium 并不是二元对立的:任何 validium 都可以通过在退出机制中加入 Plasma 特性,至少可在一定程度上提高其安全性能。研究工作的重点在于为 EVM 获取最佳特性(在信任要求、最坏情况下的 L1 gas 成本和 DoS 脆弱性方面),以及其他特定应用结构。此外,相对于 Rollup,Plasma 的概念复杂性更高,这需要通过研究和构建更好的通用框架来直接解决。 使用 Plasma 设计的主要代价是,它们更依赖于运营者,并且更难实现通用,尽管 Plasma 和 Rollup 的混合设计通常可以避免这一弱点。
对路线图的其他部分有何影响?
Plasma 解决方案越有效,L1 拥有高性能数据可用性功能的压力就越小。将活动转移到 L2 还能减少 L1 的 MEV 压力。
成熟的 L2 证明系统
我们要解决什么问题?
如今,大多数 Rollup 实际上还不是去信任的;安全委员会有能力推翻(optimistic 或 validity)证明系统的行为。在某些情况下,证明系统甚至根本不存在,即使存在,也只有「咨询」功能。目前走得最远的是一些针对特定应用的 Rollup,如 Fuel,它是去信任的;其次,截至本文撰写时,Optimism 和 Arbitrum,这两全 EVM Rollup 已经达到了部分去信任的里程碑,也就是我们所称的「stage 1」。Rollup 没有进一步实现去信任的原因是担心代码中的错误。我们需要去信任的升级,因此我们需要正面解决这个问题。
如何实现去信任的升级?
首先,让我们回顾一下最初介绍的「stage」系统,大致情况如下:
- Stage 0:用户必须能够运行节点并同步链。如果验证是完全可信的/中心化的,就没问题。
- Stage 1:必须有一个(去信任的)证明系统,确保只有有效的交易才能被接受。允许安全委员会推翻证明系统,但必须达到 75% 的投票门槛。此外,委员会中法定人数限制的部分(26% 以上)必须在 Rollup 构建者之外。允许使用功能较弱的升级机制(如 DAO),但必须有足够长的延迟时间,如果批准恶意升级,用户可以在升级上线前退出资金。
- Stage 2:必须有一个(去信任的)证明系统,确保只有有效的交易才能被接受。只有在代码中出现可证明的错误时,例如两个冗余的证明系统相互不同意,或一个证明系统接受了同一区块的两个不同的后状态根(或在足够长的时间内(如一周)不接受任何东西),安全委员会才被允许干预。升级机制是允许的,但必须有很长的延迟时间。
我们的目标是达到 Stage 2。主要的挑战是获得足够的信心,证明系统确实足够可信。要做到这一点,主要有两种方法:
- 形式验证:我们可以使用现代数学和计算技术来证明(optimistic 或 validity)证明系统只接受通过 EVM 规范的区块。这些技术已经存在了几十年,但最新的进展(如 Lean 4)使其更加实用。此外,人工智能辅助证明的进步有可能进一步加快这一趋势。
- 多验证器:制作多个验证系统,并将资金投入到这些验证系统与安全委员会(和/或其他具有信任假设的小工具,如 TEE)之间的 2-of-3(或更大)多验证器中。如果证明系统同意,安全委员会就没有权力;如果证明系统不同意,安全委员会只能选择其中之一,不能单方面强加自己的答案。
结合 optimistic 证明系统、 validity 证明系统和安全委员会的多验证器样式图
现有的相关研究
- 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 验证器创建一个经过形式验证的版本。这是一个非常复杂的项目,但我们已经开始实施了,且有一个小窍门可以大大简化这项任务:我们可以构建一个最小虚拟机(如 RISC-V 或 Cairo)的经过正式验证的 SNARK 验证器,然后在该最小虚拟机中编写 EVM 的实现(并正式证明其与其他 EVM 规范的等价性)。
对于多验证器来说,剩下的重点包括两个部分。首先,我们需要对至少两个不同的证明系统有足够的信心,既要相信它们各自都是相当安全的,又要相信如果它们发生故障,故障的原因是不同的、互不相关的(因此它们不会同时发生故障)。其次,我们需要在合并证明系统的底层逻辑中获得极高的保证。这是一段小得多的代码,有一些方法(只需将资金存储在一个 Safe 多签合约中,其签名者代表各个证明系统的合约)可以让它变得非常小,但这样做的代价是高昂的链上 gas 成本。我们需要在效率和安全之间找到某种平衡。
对路线图的其他部分有何影响?
将活动转移到 L2 可以减少 L1 的 MEV 压力。
改进跨 L2 的互操作性
我们要解决什么问题?
目前,L2 生态面临的一个主要挑战是用户难以跨 L2 进行互操作,而最简单的方法往往会重新引入信任假设,包括中心化跨链桥、RPC 客户端等。如果我们认真对待「L2 是以太坊一部分」的理念,我们就需要让使用 L2 生态的感觉就像使用统一的以太坊生态一样。
跨 L2 用户体验极差的一个例子(我个人就因为链选择错误损失了 100 美元):虽然这不是 Polymarket 的错,但跨 L2 互操作性应该是钱包和以太坊标准(ERC)社区的责任。在一个运作良好的以太坊生态中,从 L1 向 L2 或从一个 L2 向另一个 L2 发送代币,应该感觉就像在同一个 L1 中发送代币一样。
跨 L2 的互操作性如何改进?
跨 L2 的互操作性改进有很多方法。一般来说,只要意识到从理论上讲,以 Rollup 为中心的以太坊与 L1 执行分片是一回事,然后观察当前的各以太坊 L2 在实践中与这一理想有哪些差距,就可以得出结论。下面是一些例子:
- 特定链地址:链(L1、Optimism、Arbitrum......)可以是地址的一部分。一旦实现了这一点,只需将地址放入「send」字段,就能实现跨 L2 发送流程,此时钱包就能在后台找出发送方法(包括使用跨链协议)。
- 特定链的支付请求:「向我发送 Z 链上 Y 类型的 X 代币」这一信息应该是简单而标准化的。这有两种主要用例:首先是支付,无论是个人对个人还是个人对商家服务;其次是请求资金的 Dapp,例如上面的 Polymarket。
- 跨链兑换和 gas 支付:应该有一个标准化的开放协议来表达跨链操作,例如「我在 Optimism 上向 Arbitrum 上向我发送 0.9999 ETH 的人发送 1 ETH」,以及「我在 Optimism 上向 Arbitrum 上包含此交易的人发送 0.0001 ETH」。ERC-7683 是对前者的一种尝试,而 RIP-7755 则是对后者的一种尝试,尽管两者都比这些特定用例更通用。
- 轻客户端:用户应能实际验证与之交互的链,而不仅仅是信任 RPC 提供商。A16z crypto 的轻客户端 Helios 帮以太坊做到了这一点,但我们需要将这种去信任扩展到 L2。ERC-3668(CCIP-read)是实现这一目标的策略之一。
轻客户端如何更新以太坊 header chain:一旦拥有了 header chain,就可以使用 Merkle 证明来验证任何状态对象。一旦有了正确的 L1 状态对象,就可以使用 Merkle 证明(如果你想检查预先确认,还可以使用签名)来验证 L2 上的任何状态对象。Helios 已经实现了前者,扩展至后者则是一个标准化的挑战。
密钥存储钱包:如今,如果要更新控制智能合约钱包的密钥,必须在该钱包所在的所有 N 个链上进行更新。密钥存储钱包是一种技术,允许密钥存在于一个地方(或者在 L1 上,或者以后可能在 L2 上),然后可以从任何拥有钱包副本的 L2 上读取。这意味着更新只需进行一次。为了提高效率,密钥存储钱包要求 L2 有一种标准化的方式来低成本地读取 L1;有两个关于这方面的提议:L1SLOAD 和 REMOTESTATICCALL。
密钥存储钱包工作原理示意图 更激进的「共享代币桥」方案:想象一下这样一种情况,即所有的 L2 都是有效性证明 Rollup,每个 slot 都会提交到以太坊上,那么将资产「原生得」从一个 L2 转移到另一个 L2 也需要提款和存款,需要支付大量的 L1 gas。解决这个问题的一种方法是创建一个共享的最小 Rollup,其唯一的功能就是维护哪个 L2 拥有多少代币的余额,并允许通过任何一个 L2 发起的一系列跨 L2 发送操作来大规模更新这些余额。这将允许跨 L2 传输,而无需为每次传输支付 L1 gas,也无需使用基于流动性提供者的技术(如 ERC-7683)。
同步可合成性:允许在特定 L2 和 L1 之间或多个 L2 之间进行同步调用。这有助于提高 DeFi 协议的财务效率。前者可以在没有任何跨 L2 协调的情况下完成;后者则需要共享排序。Based Rollups 自动适用于所有这些技术。
现有的相关研究
- 特定链地址(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 密钥存储钱包设计: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
- Optimism 的 REMOTESTATICCALL: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 本身的规模并确保它能继续支持越来越多的用例是非常有价值的。
如何扩展 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 的文章中详细讨论。 最后,第三种策略是原生 Rollup 或「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
- 原生 Rollup:https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
- Bankless 与 Max Resnick 就扩展 L1 的价值采访:https://x.com/BanklessHQ/status/1831319419739361321
- Justin Drake 关于使用 SNARKs 和原生 Rollup 进行扩展的思考:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
还有哪些工作要做,如何权衡?
扩展 L1 有三种策略,可单独或同时进行:
- 改进技术(如客户端代码、无状态客户端、历史过期),使 L1 更容易验证,然后提高 gas 上限
- 降低特定操作的成本,在不增加最坏情况风险的情况下提高平均容量
- 原生 Rollup,即「创建 EVM 的 N 个并行副本」,但保留允许开发人员在部署副本参数上有很大灵活性的可能
值得注意的是,这些技术各不相同,各有利弊。例如,原生 Rollup 在可组合性方面有许多与普通 Rollup 相同的弱点。提高 gas 限制会影响其他好处,而这些好处可以通过让 L1 更容易验证来实现,比如增加运行验证节点的用户比例,以及增加单一质押者。降低 EVM 中特定操作的成本(取决于如何操作)会增加 EVM 的总复杂度。 L1 扩展路线图需要回答的一个大问题是:什么应归属于 L1,什么应归属于 L2?
显然,将所有东西都放在 L1 上是荒谬的。高达每秒数十万笔交易的潜在用例,将使 L1 完全无法验证(除非我们走原生 Rollup 路线)。我们确实需要一些指导原则,这样才能确保我们不会造成这样一种情况,即我们将 gas 限制提高了 10 倍,严重破坏了以太坊 L1 的去中心化,却发现我们只是实现了 90% 的活动都在 L2 上,而不是 99%,除了不可逆转地丧失了以太坊 L1 的大部分特色之外,其他结果看起来几乎是一样的。
有观点认为 L1 和 L2 之间存在「分工」;来源:@0xBreadguy
对路线图的其他部分有何影响?
让更多用户使用 L1 意味着不仅规模将得到改善,还可以改善 L1 的其他方面。这意味着更多的 MEV 将留在 L1 上(而不是仅仅成为 L2 的问题),因此明确处理 MEV 的需求将更加迫切。这将大大提高 L1 快速 slot 时间的价值。而这在很大程度上也取决于 L1 验证(the Verge)是否顺利。 相关阅读:Vitalik 新作:以太坊 The Merge 后路线图的潜在技术路线
作者:TechubNews;来自链得得内容开放平台“得得号”,本文仅代表作者观点,不代表链得得官方立场凡“得得号”文章,原创性和内容的真实性由投稿人保证,如果稿件因抄袭、作假等行为导致的法律后果,由投稿人本人负责得得号平台发布文章,如有侵权、违规及其他不当言论内容,请广大读者监督,一经证实,平台会立即下线。如遇文章内容问题,请联系微信:chaindd123
评论(0)
Oh! no
您是否确认要删除该条评论吗?