撰文：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 个不同的区块链。

本章内容

1. 可扩展性三角悖论
2. 数据可用性采样的进一步进展
3. 数据压缩
4. Generalized Plasma
5. 成熟的 L2 证明系统
6. 跨 L2 互操作性改进
7. 在 L1 上扩展执行

可扩展性三角悖论

可扩展性三角悖论是 2017 年提出的一个想法，它认为区块链的三个特性之间存在矛盾：去中心化（更具体地说：运行节点的成本低）、可扩展性（处理的交易数量多）和安全性（攻击者需要破坏网络中很大一部分节点才能使单笔交易失败）。#p#分页标题#e#

值得注意的是，三角悖论不是一个定理，介绍三角悖论的帖子也没有附带数学证明。它确实给出了一个启发式的数学论点：如果一个去中心化友好的节点（例如消费类笔记本电脑）每秒可以验证 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。#p#分页标题#e#

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）本质上也对分布式块构建友好。

有哪些与现有研究的链接？

1. 介绍数据可用性的原始帖子 （2018）：https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
2. Follow-up paper: https://arxiv.org/abs/1809.09044
3. 关于 DAS 的解释文章，paradigm：https://www.paradigm.xyz/2022/08/das
4. 带有 KZG 承诺的 2D 可用性：https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
5. ethresear.ch 上的 PeerDAS：https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 和论文：https://eprint.iacr.org/2024/1362
6. EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
7. ethresear.ch 上的 SubnetDAS：https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
8. 2D 采样中可恢复性的细微差别：https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256#p#分页标题#e#

还需做什么？又有哪些权衡？

接下来是完成 PeerDAS 的实施和推出。之后，不断增加 PeerDAS 上的 blob 数量，同时仔细观察网络并改进软件以确保安全，这是一个渐进的过程。同时，与此同时，我们希望有更多的学术工作来规范 PeerDAS 和其他版本的 DAS 及其与分叉选择规则安全等问题的交互。

在未来更远的阶段，我们需要做更多的工作来确定 2D DAS 的理想版本，并证明其安全属性。我们还希望最终能够从 KZG 转向一种量子安全且无需可信设置的替代方案。目前，我们还不清楚有哪些候选方案对分布式区块构建是友好的。即使使用昂贵的「蛮力」技术，即使用递归 STARK 来生成用于重建行和列的有效性证明，也不足以满足需求，因为虽然从技术上讲，一个 STARK 的大小为 O(log(n) * log(log(n)) 哈希值（使用 STIR），但实际上 STARK 几乎与整个 blob 一样大。

我认为的长期现实路径是：

1. 实施理想的 2D DAS；
2. 坚持使用 1D DAS，牺牲采样带宽效率，为了简单性和鲁棒性而接受较低的数据上限
3. （Hard pivot）放弃 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 的聚合特性为实现这一功能提供了一条途径。#p#分页标题#e#

用 pointers 替换地址：如果以前使用过某个地址，我们可以将 20 字节的地址替换为指向历史记录中某个位置的 4 字节 pointer。

交易值的自定义序列化——大多数交易值的位数很少，例如，0.25 ETH 表示为 250,000,000,000,000,000 wei。最大基础手续费和优先手续费也类似。因此，我们可以使用自定义的十进制浮点格式，来表示大多数货币值。

有哪些与现有研究的链接？

1. 探索 sequence.xyz：https://sequence.xyz/blog/compressing-calldata
2. L2 Calldata 优化合约：https://github.com/ScopeLift/l2-optimizoooors
3. 基于有效性证明的 Rollups（又名 ZK rollups）发布状态差异而不是交易：https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
4. 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 分支来提取他们的资产。重要的是，这个分支不必以最新状态为根。因此，即使数据可用性出现问题，用户仍然可以通过提取他们可用的最新状态来恢复他们的资产。如果用户提交了一个无效的分支（例如，提取他们已经发送给其他人的资产，或者运营商自己凭空创造了一个资产），则可以通过链上的挑战机制来判断资产的合法归属。#p#分页标题#e#

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 之间。

有哪些与现有研究相关的链接？

1. Original Plasma paper: https://plasma.io/plasma-deprecated.pdf
2. Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
3. Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#