以太坊协议的可能未来 ❷ :Surge
作者:维塔利克·布特林 2024 年 10 月 17 日 原文链接
一开始,以太坊在其路线图中制定了两种扩容策略。一种是 (比如见 2015 年的这份早期论文) 是"分片"(sharding):与其让每个节点验证和存储链上的所有交易,不如让每个节点只需验证和存储交易的一小部分。这也是任何其他点对点网络 (如 BT 种子) 的工作方式,所以我们当然也可以让区块链以同样的方式运作。
另一种是二层协议(Layer 2 protocol, L2):建立在以太坊之上的网络,一方面可以充分利用以太坊的安全性,另一方面将绝大部分数据和计算保留在主链之外。"二层协议"在 2015 年指的是状态通道、在 2017 年指的是Plasma、而在 2019 年则是指Rollup。Rollup 比状态通道或 Plasma 更强大,但需要大量的链上数据带宽。
幸运的是,到 2019 年,分片研究已经解决了大规模验证"数据可用性"的问题。因此,这两条路径最终汇合,形成了以 Rollup 为中心的路线图,这一直是以太坊至今的扩容策略。
特别鸣谢 Justin Drake、Francesco、Hsiao-wei Wang、@antonttc 和 Georgios Konstantopoulos

以 Rollup 为中心的路线图提出了一种简单的分工:以太坊 L1 专注于成为一个稳固和去中心化的基础层,而将帮助生态系统扩展的重任交给 L2。这种模式无处不在:司法体系 (L1) 存在的目的并非要追求极致的高速和高效,而是为了保护合同和产权;由创新者们 (L2) 在这个坚实的基础层之上建设创新,将人类带往火星,无论是比喻或字面意义上的。
今年,以 Rollup 为中心的路线图取得了重要进展:以太坊 L1 的数据带宽通过 EIP-4844(blobs)大幅提高,多个 EVM Rollup 现已进入第 1 阶段(Stage 1)。一种高度异构且多元化的分片实现形式已成为现实,其中每个 L2 都像一个"分片",拥有自己的内部规则和逻辑。但正如我们所见,走这条路径有着自身独特的挑战。因此,我们现在的任务是完成以 Rollup 为中心的路线图,解决这些问题,同时保持使以太坊 L1 与众不同的去中心化和稳健性。
说明
为 Vitalik 文章的全文翻译,为便于阅读增加少量标签式图示展示重要术语。
The Surge:关键目标
- L1+L2 上的 TPS 超过 100,000+
- 保持 L1 的去中心化和鲁棒性
- 至少部分 L2 完全继承以太坊的核心属性 (不可篡改、开放、抗审查)
- 最大化 L2 之间的互操作性。以太坊应该感觉就像一个生态系统,而非 34 条不同的区块链。
本章内容
- 补充说明:可扩展性三难困境
- 数据可用性采样的进一步进展
- 数据压缩
- 通用 Plasma
- 成熟的 L2 证明系统
- 跨 L2 互操作性和用户体验改进
- 在 L1 上扩展执行
可扩展性三难困境
可扩展性三难困境(scalability trilemma)是2017 年提出的一个概念,认为区块链存在三个相互矛盾的特性:去中心化(具体是运行节点的成本较低)、可扩展性(具体是处理的交易数量较高) 和安全性(具体是攻击者需要破坏整个网络中大部分节点才能令单个交易失效)。

这个三难困境并非定理,提出它的文章也未附带数学证明。它确实提供了一个启发式数学论证:如果一个有利于去中心化的节点 (如消费级笔记本电脑) 每秒可以验证 N 笔交易,而你有一条链每秒处理 k * N 笔交易,那么要么 (i) 每笔交易只被 1/k 的节点看到,这意味着攻击者只需要破坏少数几个节点便可推送错误交易;要么 (ii) 你的节点会变得非常强大,链条也就无法真正去中心化了。该文章的目的不是要证明打破三难困境是不可能的;相反,它是要表明打破三难困境并跳出框框思考是很有挑战的。
多年来,一些声称具有高性能的链一直宣称,在不采取任何根本性架构层面的聪明做法的情况下,它们解决了三难困境,它们通常只是使用软件工程技巧来优化节点。这是有误导性的,在此类链上运行节点最终会远比在以太坊上困难得多。这篇文章探讨了为什么会出现这种情况的许多细微差别 (以及为什么单靠 L1 客户端软件工程无法扩展以太坊本身)。
然而,数据可用性采样与 SNARK 的结合确实解决了三难困境:它允许客户端验证某量数据是可用的,并且某数量的计算步骤被正确执行,同时只下载该数据的一小部分并运行较少的计算。SNARK 具有不可篡改性。数据可用性采样有一个 几个 N 的信任模型,但它保留了非可扩展链所具有的基本属性,即即使 51% 的攻击也无法迫使网络接受错误的块。
解决区块链所面临的三难困境的另一种方式是 Plasma 架构。这种架构采用巧妙的方法,以符合经济激励的方式将监视数据可用性的责任转移给用户。回到 2017-2019 年,当时我们仅能通过"欺诈证明"(fraud proofs) 来扩展计算能力,因此 Plasma 在可安全执行的应用场景上存在很大限制。但现在随着"零知识证明"(ZK-SNARKs) 技术的日益普及,Plasma 架构的适用范围比以前更广,可满足更多种类的使用场景需求。
数据可用性采样
数据可用性采样的进一步进展
我们要解决什么问题?
2024 年 3 月 13 日的坎昆升级(Dencun)上线后,以太坊区块链在每 12 秒的时隙内会生成三个约 125kB 大小的 blob,也就是每个时隙约有375kB的数据可用性带宽。假设交易数据直接在链上发布,ERC20 转账约占 180 字节,那么基于以太坊的 Rollup 的最大 TPS 为:
375000 / 12 / 180 = 173.6 TPS
如果我们增加以太坊的 calldata(理论最大值:每个 Slot 30,000,000 gas / 16 gas 每字节 = 1,875,000 字节每 Slot),这个数字将变成 607 TPS。使用 PeerDAS 后,我们计划将 blob 数量的目标提升至 8-16 个,这样我们在 calldata 上就能获得463-926 TPS。
这对于以太坊 L1 来说是一个重大提升,但还远远不够。我们的中期目标是每个时隙 16 MB,如果结合 Rollup 数据压缩的改进,将能为我们提供约 58,000 TPS。
PeerDAS
它是什么?工作原理是什么?
PeerDAS 是"1D 采样"的一种相对简单的实现方式。以太坊中的每个 blob 本质上是一个在 253 位素数域上的 4096 次多项式。我们会广播这个多项式的"份额",其中每个份额包含从总共 8192 个坐标点中相邻的 16 个坐标点处的 16 次评估值。只要有任何 4096 个 (根据当前建议的参数是任意 64 个中的 128 个可能的样本) 评估值,就能恢复整个 blob。

PeerDAS 的工作原理是,每个客户端只需监听少量子网,其中第 i 个子网会广播任何 blob 的第 i 个样本。如果客户端需要获取其他子网中的 blob 样本,它可以向全局 p2p 网络中的其他节点 (监听不同子网) 请求。另一种更保守的方式叫做SubnetDAS,它只使用子网机制,不引入额外的节点请求层。目前有一个建议是,参与权益证明的节点使用 SubnetDAS,而普通客户端使用 PeerDAS。
理论上,我们可以将 1D 采样扩展得相当大程度:如果我们将 blob 数量上限增加到 256 个 (目标设为 128 个),那就能达到我们的 16MB 带宽目标,而数据可用性采样只会让每个节点增加 16 个样本* 128 个 blob * 512 字节/样本/blob = 1 MB 的数据带宽/时隙。这只是勉强在我们的容忍范围内,意味着带宽受限的客户端可能无法进行采样。我们可以通过减少 blob 数量、增加 blob 大小来稍作优化,但这会加大重构的计算开销。
因此,我们最终希望采用2D 采样,它不仅在 blob 内部进行随机采样,而且还在 blob 之间进行采样。2D 采样利用了 KZG 承诺的线性特性,通过生成一系列新的"虚拟 blob"来冗余编码相同信息,从而扩展了原有的 blob 集合。

2D 采样 来源:a16z crypto
关键在于,计算承诺扩展时并不需要实际的 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 的解释文章,paradigm: https://www.paradigm.xyz/2022/08/das
- 使用 KZG 承诺的 2D 可用性:https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
- PeerDAS 在 ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541,及论文:https://eprint.iacr.org/2024/1362
- Francesco 关于 PeerDAS 的演讲:https://www.youtube.com/watch?v=WOdpO1tH_Us
- EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
- SubnetDAS 在 ethresear.ch: 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 上的数据块数量,同时仔细监视网络并改进软件以确保安全性。与此同时,我们希望在形式化 PeerDAS 和其他 DAS 版本及其与问题 (如分叉选择规则的安全性) 之间的交互方面有更多的学术研究工作。
展望更远的将来,我们需要做更多研究来确定理想的 2D DAS 版本,并证明其安全性特性。我们最终还希望摆脱 KZG,改用量子密码学抗性且无需可信设置的替代方案。目前,我们还没有发现对分布式块构建友好的候选技术。即使使用递归 STARK 来生成重建行和列有效性证明的昂贵的"暴力"技术,也是不够的,因为虽然理论上 STARK 的大小为 O(log(n) * log(log(n)))
哈希值 (STIR),但在实践中,STARK 几乎和整个数据块一样大。
我看到的长期现实路径有:
- 实施理想的2D DAS
- 坚持使用1D DAS,牺牲采样带宽效率,为简单性和稳健性接受较低的数据上限
- (大幅转变) 放弃 DA,完全接受 Plasma 作为我们关注的主要第 2 层架构
我们可以将这些选择看作一个权衡光谱:

值得注意的是,即使我们决定直接在第一层链上扩展执行能力,这种选择也是存在的。原因在于,如果第一层要支持大量的交易,区块会变得非常大,因此客户端需要一种有效的方式来验证它们是否正确,所以我们将不得不在第一层使用与 Rollup(ZK-EVM 和 DAS) 相同的技术。
与路线图其他部分的关系
如果能实现数据压缩 (见下文),理想的 2D DAS 的需求在某种程度上会降低,或至少推迟;如果 Plasma 被广泛使用,这种需求就会进一步降低。同时,DAS 也给分布式块构建协议和机制带来了挑战:虽然理论上 DAS 有利于分布式重建,但在实践中,还需要与被称为"包含列表 (inclusion list)"的提案及其周围的分叉选择机制相结合。
数据压缩
我们要解决什么问题?
Rollup 中的每笔交易在链上都占用相当大的数据空间:一笔 ERC20 转账大约需要 180 个字节。即使实现了理想的数据可用性抽样,这也给第二层协议的可扩展性设置了上限。如果每个时隙有 16 MB 的容量,我们可以计算得到:
16000000 / 12 / 180 = 7407 TPS
如果除了减小分子 (每笔交易的字节数),我们还可以减小分母 (让每笔 Rollup 交易在链上占用更少的字节空间),会怎样?
它是什么?工作原理是什么?
在我看来,最好的解释是这张图两年前发的:
最简单的压缩方式是零字节压缩:用两个字节来表示一长串连续的零字节。为了获得更大的压缩效果,可以利用交易本身的一些特性:
签名聚合 - 我们从 ECDSA 签名切换到 BLS 签名,BLS 签名有这样一个特性:多个签名可以合并成单个签名,来证明所有原始签名的有效性。这种方式在第一层 (Layer 1) 不被考虑,因为即使进行了聚合,验证的计算成本仍然较高。但在数据资源匮乏的第二层环境中,做出这种权衡或许是有意义的。ERC-4337 的聚合功能为实现此功能提供了一种途径。
用指针替代地址 - 如果一个地址之前被使用过,我们可以用一个 4 字节的指针来替代 20 字节的地址,该指针指向历史数据中的某个位置。要获得最大的压缩收益,这是必需的,不过实现起来需要一些努力,因为它需要 (至少部分) 区块链历史成为状态的一部分。
交易金额的自定义序列化 - 大多数交易金额只有很少的几位数字,例如 0.25 ETH 被表示为 250,000,000,000,000,000 wei。gas 的 maxpriority 费和 basefee 也是如此。因此,我们可以使用自定义的十进制浮点格式或者常用值的字典来非常紧凑地表示大多数货币值。
查看更多:现有研究资料链接
现有研究资料链接
- sequence.xyz 的探索性研究:https://sequence.xyz/blog/compressing-calldata
- ScopeLift 为第二层设计的代码优化合约,减少了 calldata 的大小:https://github.com/ScopeLift/l2-optimizoooors
- 一种替代策略 - 基于有效性证明的 Rollup(又称 ZK Rollup) 在链上发布状态差异而非交易数据: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 包装器来替代其他签名方案。
- 动态压缩 (如用指针替代地址) 会使客户端代码变得更加复杂。
- 在链上发布状态差异而非交易数据,会降低可审计性,并使诸如区块浏览器等许多软件无法正常工作。
与路线图其他部分的关系
采用 ERC-4337 标准,最终将其部分内容纳入第二层 EVM,可以大大加快签名聚合技术的部署进度。在第一层 (Layer 1) 上支持 ERC-4337 的部分内容,也可以加快它在第二层的部署。
Plasma
通用化 Plasma
我们要解决什么问题?
即便采用了 16MB 的数据块和数据压缩,58,000 TPS 也不一定足以完全支持消费支付、去中心化社交或其他高带宽领域。尤其是如果考虑隐私性的话,可扩展性可能会下降 3-8 倍。对于高容量、低价值的应用程序,当今一个选项是 validium。validium 将数据保存在链下,具有一种有趣的安全模型,其中操作者无法窃取用户的资金,但他们可能会消失并暂时或永久冻结所有用户的资金。但我们可以做得更好。
它是什么?工作原理是什么?
Plasma 是一种扩容解决方案,运营商(Operator)在链下发布区块,并将这些区块的默克尔树根放置在链上 (与 Rollup 不同,Rollup 是将完整的区块放置在链上)。对于每个区块,运营商都会向每个用户发送一个默克尔证明,证明该用户的资产发生了什么变化,或者没有发生变化。用户可以通过提供一个默克尔证明来提取他们的资产。重要的是,这个证明不必根植于最新的状态 - 由于这个原因,即使数据可用性失效,用户仍然可以通过提取他们拥有的最新可用状态来恢复资产。如果用户提交了无效的证明 (例如退出已转移给他人的资产,或者运营商自己创建资产),链上的挑战机制可以裁定资产归属。

早期版本的 Plasma 只能处理支付用例,无法有效地推广到更多场景。但是,如果我们要求每个默克尔树根都经过零知识证明 (ZK-SNARK) 验证,Plasma 就会变得更加强大。每个挑战游戏都可以大大简化,因为我们消除了运营商作弊的大部分可能路径。新的途径也为让 Plasma 技术扩展到更广泛的资产类别开辟了机会。最后,在运营商没有作弊的情况下,用户可以立即提取他们的资金,而无需等待一周的挑战期。

一个关键见解是,Plasma 系统不需要完美无缺。即使你只能保护一部分资产 (例如,只保护过去一周内没有移动过的代币),你已经大大改善了当前极度可扩展性以太坊虚拟机 (EVM) 的现状,即 validium。
另一类构造是混合 Plasma/Rollup 模式,如 Intmax。这些构造要求每个用户只需在链上保留少量数据 (例如 5 字节),并通过这种方式获得介于 Plasma 和 Rollup 之间的属性:在 Intmax 的情况下,你可以获得很高的可扩展性和隐私性,尽管即使在 16MB 的区块大小下,理论上的最大吞吐量也被限制在大约 16,000,000 / (12 个交易/块) / 5 (字节/用户) = 266,667 TPS。
查看更多:现有研究资料链接
现有研究资料链接
- 原始 Plasma 论文:https://plasma.io/plasma-deprecated.pdf (注:该文件名中的 "deprecated" 表示此版本已被废弃)
- Plasma 现金 (Plasma Cash): https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
- Plasma 现金流 (Plasma Cashflow): https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
- Intmax (2023): https://eprint.iacr.org/2023/1082
待解决的问题及权衡考虑
主要的剩余任务是将 Plasma 系统投入生产。如前所述,Plasma 与 Validium 不是非黑即白的选择:任何 Validium 都可以通过在退出机制中添加 Plasma 功能至少在一定程度上改善其安全性。研究部分是为以太坊虚拟机 (EVM) 及其他特定应用获得最优性能 (在信任要求、最坏情况下的第 1 层 Gas 成本和抵御 DoS 攻击方面)。此外,相对于 Based Rollups,Plasma 更大的概念复杂性需要直接解决,既可通过研究,也可通过构建更好的通用框架来完成。
主要的权衡取舍在于,使用 Plasma 设计会更加依赖运营商,并且较难实现类似于 Based Rollups 的特性,尽管混合 Plasma/Rollup 设计通常可以避免这一缺陷。
与路线图其他部分的关系
Plasma 解决方案越有效,第 1 层(L1)就越不需要具备高性能的数据可用性功能。另外,将更多活动迁移到第 2 层(L2),也会减轻 L1 所面临的 MEV 压力。
Layer 2, L2
第二层证明系统正在走向成熟
我们要解决什么问题?
现在,大多数 Rollup 实际上还不是真正无需信任的,因为有一个安全委员会(security council) 能够凌驾于 (乐观或有效性)证明系统之上。在某些情况下,证明系统根本就没有启用,或者即使启用了,它也只是提供"建议"性质的功能。目前最先进的是 (i) 一些特定应用的 Rollup,比如 Fuel,它们是无需信任的,以及 (ii) 在撰写本文时,Optimism 和 Arbitrum 这两个已经达到被称为"阶段 1"的部分无需信任里程碑的完整 EVM rollup。Rollup 还没有走得更远的原因是对代码中的 bug 存有顾虑。我们需要无需信任的 Rollup,因此我们需要正视这个问题。
它是什么?工作原理是什么?
首先,让我们回顾一下最初在这篇文章中引入的"阶段"系统。总的来说,要求如下:
阶段 0(Stage 0):必须让用户能够运行节点并同步链。验证可以是完全受信任/集中式的。
阶段 1(Stage 1):必须有一个 (无需信任的) 证明系统((trustless) proof system),确保只有有效的交易才能被接受。允许有一个安全委员会可以否决证明系统,但只能在75% 的门槛投票时这样做。此外,委员会中至少应该有一部分 (比如 26%+) 成员来自构建 Rollup 的主要公司之外,能够阻挠决策。可以有一个具有较弱功能 (如 DAO) 的升级机制,但它必须设置足够长的延迟,以便如果它批准了恶意升级,用户可以在升级生效前退出资金。
阶段 2(Stage 2):必须有一个 (无需信任的) 证明系统,确保只有有效的交易被接受。安全委员会只允许在代码中存在可证明的 bug 的情况下介入,例如,如果两个冗余的证明系统相互矛盾,或者如果一个证明系统为同一区块接受了两个不同的状态根 (或在足够长的时间内,比如一周,未能对任何内容做出响应)。允许有升级机制,但必须设置很长的延迟期。
目标是达到第 2 阶段。达到第 2 阶段的主要挑战是获得足够的信心,证明系统实际上确实值得信赖。有两种主要方法可以做到这一点:
- 形式验证(Formal verification):我们可以使用现代数学和计算技术,证明 (乐观或有效性) 证明系统只接受符合 EVM 规范的区块。这些技术已经存在数十年了,但最近的进展,比如Lean 4,使它们变得更加实用,而 AI 辅助证明可能会进一步推动这一趋势。
- 多证明者(Multi-provers):创建多个证明系统,并将资金存放于这些证明系统与安全委员会 (和/或其他具有信任假设的机制,如 TEE) 之间的 2/3(或更高比例) 的多重签名合约中。如果证明系统达成一致,安全委员会就没有权力;如果它们存在分歧,安全委员会只能在它们之间做出选择,而不能单方面强加自己的答案。

这是一个多重证明人组合的图解,包括一个乐观性证明系统、一个有效性证明系统和一个安全委员会。
查看更多:现有研究资料链接
现有研究资料链接
- EVM K 语义形式化验证工作 (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 消耗较高。因此,需要在效率和安全性之间寻求平衡。
与路线图其他部分的关系
将活动转移到第 2 层,可以减轻第 1 层的 MEV 压力。
L2 互操作性
改进 L2 之间的互操作性
我们要解决什么问题?
当前 L2 生态系统面临的一个主要挑战是用户难以顺畅使用。更重要的是,现有的一些使用方式往往重新引入了信任假设:如中心化跨链桥、RPC 客户端等。如果我们认真地将 L2 视为以太坊生态的组成部分,就需要确保用户在使用 L2 生态系统时能获得与使用统一的以太坊生态系统相同的体验。
这是一个病态的、糟糕的 (甚至存在风险的) 跨 L2 用户体验示例 —— 尽管这不是 Polymarket 的错,但跨 L2 互操作性本应是钱包和以太坊标准 (ERC) 社区应该承担的责任。在一个运行良好的以太坊生态系统中,从 L1 到 L2,或从一个 L2 到另一个 L2 转移资产,应该就像在同一个 L1 进行转账一样简单。
它是什么?工作原理是什么?
跨 L2 互操作性改进涵盖多个类别。总的来说,提出这些改进的方法是注意到理论上Rollup 为中心的以太坊实际上等同于第一层执行分片,然后问当前以太坊第二层生态系统在实践中与这一理想状态有何差距。以下是一些例子:
特定链地址:地址中应包含区块链信息 (第一层、Optimism、Arbitrum 等)。一旦实现,跨 L2 发送流程就可以通过将地址放入"发送"字段来完成,之后钱包可在后台计算如何进行发送 (包括使用桥接协议)。
特定链支付请求:应该有一个标准化且简单的方法能够发送形如"请向我在链 Z 上发送 X 个类型为 Y 的代币"的消息。这两个主要用途是:(i) 个人对个人或个人对商家服务的支付;(ii) DApp 请求资金,如上文 Polymarket 的例子。
跨链交换和手续费支付:应该有一个标准的开放协议来表达诸如"我在 Optimism 链上发送 1 ETH 以换取有人在 Arbitrum 链上发送给我 0.9999 ETH",以及"我在 Optimism 链上支付 0.0001 ETH 作为手续费以让有人在 Arbitrum 链上打包这笔交易"这样的跨链操作。ERC-7683 针对前一种情况提出了一种解决方案,RIP-7755 针对后一种情况提出了一种解决方案,尽管两者的应用场景都不仅限于此。
轻客户端:客户端应该能够真正验证他们正在交互的区块链,而不仅仅是盲目信任 RPC 提供商。A16z crypto 的 Helios 轻客户端 已经能够验证以太坊本身,但我们需要将这种无需信任的特性扩展到第二层。ERC-3668(CCIP-read) 就是实现这一目标的一种策略。

轻客户端如何更新其对以太坊区块头链(header chain)的视图。一旦获得区块头链,就可以使用默克尔证明来验证任何状态对象。而且一旦获得了正确的 L1(第一层)状态对象,也可以使用默克尔证明(如果需要检查预确认状态,可能还需要签名验证)来验证 L2(第二层)上的任何状态对象。Helios 已经实现了前者,但要扩展到后者仍面临标准化的挑战。
密钥存储钱包:目前,如果想更新控制智能合约钱包的密钥,你需要在该钱包存在的所有 N 条链上进行操作。密钥存储钱包是一种使密钥只需存在于一个位置 (可以在 L1 或将来潜在的 L2 上) 的技术,任何拥有该钱包副本的 L2 都可以从中读取。这意味着只需更新一次即可。为了高效,密钥存储钱包需要 L2 能够以标准化且无成本的方式读取 L1;两种建议分别是L1SLOAD和REMOTESTATICCALL。
更激进的"共享代币桥" 概念:设想这样一个世界,所有 L2 都是有效性证明 Rollup,并在每个时隙都向以太坊提交数据。在这种情况下,将资产从一个 L2"原生"转移到另一个 L2 仍需要提取和存入操作,从而需要支付大量的 L1 gas 费。解决方案之一是创建一个共享的最小 Rollup,其唯一功能是维护每个 L2 拥有的代币类型及数量余额,并允许通过任意 L2 发起的一系列跨 L2 转账操作来批量更新这些余额。这将使得无需为每笔跨 L2 转账支付 L1 gas 费,也不需要像 ERC-7683 那样依赖流动性提供者。
同步可组合性:允许同步调用发生在特定 L2 和 L1 之间,或多个 L2 之间。这可能有助于提高 DeFi 协议的资金利用效率。前者无需任何跨 L2 协调即可实现;后者需要共享排序器。Based Rollups天然就适配这些技术。
查看更多:现有研究资料链接
现有研究资料链接
- 特定链地址:EIP-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
- Optimism 中的 REMOTESTATICCALL: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
- 包含共享代币桥理念的 AggLayer: https://github.com/AggLayer
待解决的问题及权衡考虑
上述许多例子都面临着标准化时机的选择问题,也面临着那些层可以标准的问题。如果过早确定标准,可能会将次优方案固化下来。如果标准化时机太晚,则可能导致不必要的碎片化。在某些情况下,可能存在着一种短期过渡性方案,虽然属性较弱但更易于实现;同时也有最终的"正确"长期解决方案,但要实现需时数年。
本节独特之处在于,这些任务不仅是技术性质的,它们更多体现为社会性挑战,需要 L2、钱包和 L1 之间的通力合作。我们能否成功应对这一问题,将检验我们作为一个社区保持团结协作的能力。
与路线图其他部分的关系
这些提议大多数属于"高阶层面"的设计,不会对第一层 (底层) 产生重大影响。但共享排序则是一个例外,它对 MEV 有重大影响。
L1 执行
在 L1 上扩展执行能力
我们要解决什么问题?
如果 L2 变得非常可扩展和成功,但 L1 仅能处理极低的交易量,以太坊可能会面临以下风险:
- ETH 资产的经济状况将变得更加不稳定,这反过来会影响网络的长期安全性。
- 许多 L2 都依赖于与在 L1 上高度发达的金融生态系统的紧密联系,如果这个生态系统大大衰弱,成为 L2(而非独立的 L1) 的动力也将减弱。
- L2 需要很长时间才能获得与 L1 完全相同的安全保证。
- 如果 L2 失败 (例如由于恶意或缺失的运营商),用户仍需通过 L1 来恢复资产。因此,L1 需要足够强大,至少能够偶尔应对 L2 高度复杂和混乱的清算过程。
出于上述原因,持续扩展 L1 本身并确保它能够支持不断增长的用途是非常有价值的。
它是什么?工作原理是什么?
最直接的扩展方式是增加 gas 限制。然而,这可能会集中化 L1,从而削弱使以太坊 L1 如此强大的另一个重要属性:作为可靠底层的可信度。关于简单的 gas 限制提高到何种程度是可持续的,正在进行讨论,这也取决于部署了哪些其他技术来更轻松地验证较大的区块 (例如历史过期、无状态性、L1 EVM 有效性证明)。另一项重要工作是继续优化以太坊客户端软件的效率,它比五年前经过了更多优化提升。一个有效的 L1 gas 限制提高策略将涉及加速部署这些有助于提高 gas 限制的验证技术。
另一种扩展策略是确定在不损害网络去中心化或安全性属性的情况下,可以降低成本的特定功能和计算类型。例子包括:
EOF - 一种新的 EVM 字节码格式,更利于静态分析,从而允许更高效的实现。EOF 字节码可以被指定较低的 gas 成本来利用这些效率提升。
多维 gas 定价 - 为计算、数据和存储建立独立的基本费用和限制,从而在不增加网络最大容量 (引发新的安全风险) 的情况下,提高以太坊 L1 的平均处理能力。
降低特定操作码和预编译的 gas 成本 - 历史上我们确实有几轮提高某些操作的 gas 成本,以避免由于定价过低而导致的拒绝服务攻击。但我们很少做的是降低那些定价过高操作的 gas 成本,这也是我们可以做的。例如,加法比乘法便宜很多,但
ADD
和MUL
操作码目前的费用相同。我们可以使ADD
更便宜,甚至更简单的操作码如PUSH
也可以降低成本。EVM-MAX 和 SIMD: EVM-MAX 是一个提议,允许以更高效的原生方式进行大数的模运算,作为 EVM 的一个单独模块。EVM-MAX 计算得到的值只能由其他 EVM-MAX 操作码访问,除非有意导出;这为将这些值存储在优化格式中提供了更大空间。SIMD("单指令多数据") 则是一个提议,允许在数组值上有效地执行相同的指令。两者结合可以为 EVM 创建一个强大的协处理器,用于更高效地实现密码学操作。这将特别有利于隐私协议,以及 L2 的证明系统,因此有助于 L1 和 L2 的扩展。
最后,第三种扩展策略是原生 Rollup("Native Rollups"或 "Enshrined Rollups")。本质上是在以太坊协议内原生创建多个并行运行的 EVM 副本,这与通过部署 Rollup 合约在以太坊之上实现 Rollup 的效果等同,但在协议层面上更好地集成和优化。通过更深度地将 Rollup 机制纳入协议,可以进一步提升性能和效率。
Native Rollups
查看更多:现有研究资料链接
现有研究资料链接
- 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
- 关于扩展 L1 价值的 Max Resnick 采访:https://x.com/BanklessHQ/status/1831319419739361321
- Justin Drake 关于使用 SNARK 和原生 Rollup 进行扩展:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
待解决的问题及权衡考虑
L1 扩展有三种策略,可单独或并行推进:
- 改进技术 (如客户端代码、无状态客户端、历史过期) 来使 L1 更容易验证,然后提高 gas 上限
- 使特定操作更便宜,提高平均容量,而无需增加最坏情况风险
- 原生 Rollup(即"创建 N 个并行 EVM 副本",但可让开发人员灵活设置部署副本的参数)
值得理解的是,这些是不同的技术,存在不同的权衡。例如,原生 Rollup 与常规 Rollup 在可组合性方面存在许多相同的缺陷:你无法发送一笔可跨多个 Rollup 同步执行操作的单一交易,就像你可以在同一 L1(或 L2) 上的合约中那样。提高 gas 上限会牺牲使 L1 更易验证可实现的其他好处,例如增加运行验证节点的用户比例,以及增加单个质押者。使 EVM 中的特定操作更便宜,这种方式取决于其实现,可能会增加 EVM 的总体复杂性。
任何 L1 扩展路线图都需要回答一个重大问题:究竟什么属于 L1,什么属于 L2?显然,让所有东西都在 L1 上是荒谬的:潜在用例可能达到每秒数十万笔交易,这将使 L1 完全无法验证 (除非我们采用原生 Rollup 路线)。但我们确实需要一些指导原则,以确保我们不会造成这样一种情况:我们将 gas 上限提高 10 倍,严重损害以太坊 L1 的去中心化,结果发现我们只是将 99% 的活动从 L2 转移到 90%,而失去了使以太坊 L1 与众不同的许多特性。
一种关于 L1 和 L2 之间"分工"的观点, source
与路线图其他部分的关系
将更多用户引入 L1,不仅意味着需要扩容,还意味着需要改进 L1 的其他方面。这意味着更多的 MEV 将留在 L1(而不是成为 L2 的问题),因此显式地处理 MEV 问题将变得更加迫切。它也让 L1 上实现快速时隙时间变得更为重要。它也很大程度上依赖于 L1 的验证情况,这是 the Verge 阶段要处理的。