原文作者：Jiawei，IOSG Ventures
原文编辑：Olivia，IOSG Ventures
tl;dr：
如果「The Merge」进展顺利，分片将成为以太坊在 2023 年及之后的开发主轴，而距离 2015 年分片被提出，其含义已经发生了很大变化。
在 Vitalik 提出「以 Rollup 为中心的以太坊路线图」和以太坊的「Endgame」之后，以太坊的大方向发生了事实上的转变——「退居幕后」，作为 Rollup 的安全性保证和数据可用性层。
Danksharding 和 Proto-Danksharding 是一系列的技术组合，表现形式在于「发现问题」、引入或提出新技术来「解决问题」的一套组合拳。
时间线拉长到未来几年，Rollup 的整体价值将变大：以太坊上呈现多 Rollup 的发展格局、跨 Rollup 基础设施高度完善、Rollup 生态高度繁荣——甚至超越以太坊本身。
引言
转眼 2022 年已走过一半。我们回看 Vitalik 在 2018 年 Devcon 演讲中提出的 Serenity Roadmap，容易发现以太坊的发展路径几经更迭 — 对比当前的路线图，分片被赋予新的含义，eWASM 亦少有人提及。
为了避免潜在的欺诈和用户误导问题，今年 1 月底，以太坊基金会宣布弃用「ETH2」的说法，而是把当前的以太坊主网改称为处理交易和执行的「执行层」，把原 ETH2 的说法改称为协调和处理 PoS 的「共识层」。
当前，以太坊官方的路线图涵盖了三部分内容：信标链、合并与分片。
其中，信标链（Beacon Chain）作为以太坊向 PoS 迁移的前置工作，以及共识层的协调网络，于 2020 年 12 月 1 日启用，迄今已运行近 20 个月。
合并（The Merge）指当前以太坊主网与信标链的最终合并，也即执行层与共识层的统一，标志着以太坊正式迁移到 PoS。在 IOSG 的文章「黎明将至：以太坊合并近在咫尺」中，我们介绍了合并相关的重要进展：当前以太坊 Ropsten 与 Sepolia 测试网成功完成了合并，紧接着是 Goerli 的合并；如果一切顺利，意味着我们离主网合并不远了。
本文我们将着重讨论分片（Sharding）。原因在于：
其一，假定主网合并能够在年内顺利实现，那么分片将紧随其后，作为 2023 年以太坊的开发主轴。
其二，以太坊分片的概念最早由 Vitalik 在 2015 年的 Devcon 1 中提出，此后 GitHub 的 Sharding FAQ 中提出了分片的 6 个发展阶段（如上图）。然而，随着以太坊路线图的更新和相关 EIP 的推动，分片的含义和优先级都产生了很大变化。当我们在讨论分片时，需要先确保对其含义的理解达成一致。
综上两点，梳理清楚分片的来龙去脉是很重要的。本文将着重讨论以太坊原分片、 Danksharding 和 Proto-Danksharding 的由来、进展和未来路线，而非具体到每个技术细节。关于 Danksharding 和 Proto-Danksharding 的详细内容，可参考 IOSG 此前的文章：「扩容杀手锏 Danksharding 会是以太坊分片的未来吗」、「EIP4844：即将开启 L2 交易费降低可预见的洼地效应」。
Quick Review
这篇文章中将会多次提到 Rollup、数据可用性和分片。
我们在这里快速回看一遍三者的基本概念。
当前主流 Rollup 分为 zkRollup 和 Optimistic Rollup。前者基于有效性证明，即批量执行交易，依赖密码学证明 SNARK 来保证状态转换的正确性；后者「乐观地」假设所有状态转换是正确的，除非被证伪；即需要一段时间窗口来确保错误的状态转换能够被发现。
数据可用性对 zkRollup 和 Optimistic Rollup 都非常重要。对前者而言，用户可以基于数据可用性重建二层的所有交易，以确保抗审查；对后者而言，需要使二层的所有数据都被发布，没有被隐藏任一交易。至于当前数据可用性面临的瓶颈与相应的解决方案，在下文中会提到。
以太坊全节点对 EVM 的完整状态进行存储，并参与所有交易验证，这样确保了去中心化和安全性，但随之而来的是可扩展性的问题：交易线性执行，且需要每个节点进行逐一确认，这样无疑是低效的。
此外，随着时间推移，以太坊网络数据不断积累（当前达 786GB），运行全节点的硬件要求随之水涨船高。全节点数量下降将引发潜在的单点故障，并削弱去中心化的程度。
直观地看，分片相当于分工合作，即对所有节点进行分组，每笔交易只需要由单组节点进行验证，并定期向主链提交交易记录，以此实现交易的并行处理（比如有 1000 个节点，原来每笔交易都必须由每个节点进行验证；如果把他们分为 10 组，每组 100 个节点来验证交易，效率显然大大提升了）。采用分片使得在提高可扩展性的同时，也降低了单组节点的硬件要求，从而解决上述两个问题。
原分片
以太坊原方案中有 64 个分片，每个分片中都有独立的提议者和委员会，提议者是被随机选择的一个验证者，收集交易并进行排序；委员会是一组验证者的集合（至少由 128 个验证者组成），每隔一定时间被随机分配到各个分片上，并验证交易的有效性，如果委员会的 2/3 投票通过，则调用验证者管理合约（VMC）向信标链提交交易记录。区别于下述的「数据分片」，这种分片也被称为「执行分片」。
背景
在聊 Danksharding 之前我们不妨先花点时间了解其背景。个人猜想，Danksharding 推出的社区氛围基础主要来自 Vitalik 的两篇文章。这两篇文章为以太坊的未来发展方向定下了基调。
首先，Vitalik 于 2020 年 10 月发表了「以 Rollup 为中心的以太坊路线图」，提出以太坊需要在中短期内对 Rollup 进行集中支持。其一，以太坊基础层扩容将聚焦于扩大区块的数据容量，而非提高链上计算或 IO 操作的效率。即：以太坊分片旨在为数据 blob（而非交易）提供更多空间，以太坊无需对这些数据进行解释，只确保数据可用。其二，以太坊的基础设施进行调整以支持 Rollup（如 ENS 的 L2 支持、钱包的 L2 集成和跨 L2 资产转移）。长远来看，以太坊的未来应该作为安全性高的、人人可处理的单一执行分片，以及可扩展的数据可用性层。
此后，Vitalik 在 2021 年 12 月发表的「Endgame」中描述了以太坊的最终图景：区块产出是中心化的，但区块验证实现去信任且高度去中心化，同时确保抗审查。底层链为区块的数据可用性提供保证，而 Rollup 为区块的有效性提供保证（在 zkRollup 中，通过 SNARK 来实现；在 Optimistic Rollup 中，只需有一个诚实参与者运行欺诈证明节点）。类似于 Cosmos 的多链生态，以太坊的未来将是多 Rollup 共存的——它们都基于以太坊提供的数据可用性和共享安全性。用户依赖桥在不同 Rollup 之间活动，而无需支付主链的高额费用。
上述两篇文章基本确定了以太坊的发展方向：优化以太坊的基础层建设，为 Rollup 服务。以上论点也许基于这样一个看法：既然 Rollup 已经被验证有效并且得到良好的采用，那么「与其将花上几年时间等待一个不确定且复杂的扩容方案（注：指原分片），不如将注意力放在基于 Rollup 的方案上」。
在此之后，Dankrad 提出了新分片方案 Danksharding。以下我们把 Danksharding 的具体技术组成拆分出来理解。
Proto-Danksharding
Proto-Danksharding 提出的背景在于，虽然 Rollup 方案对比以太坊主链而言显著降低了交易费用，但还没有到足够低的理想程度。这是由于以太坊主链上提供数据可用性的 CALLDATA 仍然占据较大的花费(16gas / byte)。在原先的设想中，以太坊提出在数据分片中提供每个区块 16MB 的专用数据空间给 Rollup 使用，但距离数据分片的真正实施仍旧遥遥无期。
今年 2 月 25 日，Vitalik 和 DankRad 等提出了 EIP-4844（Shard Blob Transactions）提案，也即 Proto-Danksharding，旨在以简单、前向兼容的方式扩展以太坊的数据可用性，使其在 Danksharding 推出之后仍然可用。该提案的改动仅发生在共识层上，不需要执行层的客户端、用户和 Rollup 开发者进行额外的适配工作。
Proto-Danksharding 实际上并未执行分片，而是为将来的分片引入了一种称为「Blob-carrying Transactions」的交易格式。这种交易格式区别于普通交易在于其额外携带了称为 blob 的数据块（约为 125kB），使区块实际上变大，从而提供比 CALLDATA（约为 10kB）更加廉价的数据可用性。
然而，「大区块」的普遍问题是对磁盘空间的要求不断累加，采用 Proto-Danksharding 将使以太坊每年额外增加 2.5TB 的存储量（当前全网络数据仅为 986GB）。因此，Proto-Danksharding 设置了一段时间窗口（例如 30 天），在此之后对 blob 做删除操作，用户或者协议可以在这段时间内对 blob 数据进行备份。
即，以太坊的共识层仅仅作为一个高度安全的「实时公告板」，确保这些数据在足够长的时间里是可用的，并使其他用户或协议有足够的时间来备份数据，而非由以太坊永久保留所有的 blob 历史数据。
这么做的原因是，对存储来说，每年新增的 2.5TB 不在话下，但对以太坊节点却带来不小的负担。至于可能导致的信任假设问题，实际上只需有一个数据存储方是诚实的（1 of N)，系统就可以正常运作，而不需要实时参与验证、执行共识的验证者节点集（N/2 of N）来存储这部分历史数据。
那么，有没有激励来推动第三方对这些数据进行存储呢？笔者暂时没有发现激励方案的推出，但 Vitalik 本人提出了几个可能的数据存储方：
针对应用的协议（例如 Rollup）。它们可以要求节点存储与应用相关的历史数据，如果历史数据丢失，会对这部分应用造成风险，因此它们有动力去做存储；
BitTorrent；
以太坊的 Portal Network，这是一个提供对协议的轻量级访问的平台；
区块链浏览器、API 提供者或者其他数据服务商；
个人爱好者或者从事数据分析的学者；
The Graph 等第三方索引协议。
Danksharding 数据可用性采样（DAS）
在 Proto-Danksharding 中我们提到新的交易格式使得区块实际上变大了，并且 Rollup 也累积了大量数据，节点需要下载这些数据来保证数据可用性。
DAS 的想法是：如果可以把数据分为 N 个块，每个节点随机地下载其中的 K 个块，就能验证所有数据是否可用，而无需下载所有数据，这样就能大大减少节点的负担。但如果某个数据块丢失了怎么办？仅仅通过随机下载 K 个块很难发现某个块丢失了。
为了实现 DAS，引入了纠删码（Erasure Coding）技术。纠删码是一种编码容错技术，基本原理是把数据分段，加入一定的校验并使各个数据段之间产生关联，即使某些数据段丢失，仍然能通过算法将完整的数据计算出来。
如果把纠删码的冗余比例设置为 50%，那么意味着只需要有 50% 的区块数据可用，网络中的任何人就可以重建所有区块数据，并且进行广播。如果攻击者想要欺骗节点，则必须隐藏掉超过 50% 的区块，但只要进行多次随机采样，这种情况几乎不会发生。（例如，假设对区块进行了 30 次随机采样，这些区块都恰好被攻击者隐藏掉的几率是 2^(-30) ）……
既然节点不下载所有数据，而是依靠纠删码来重建数据，那么首先需要确保纠删码被正确编码，否则用错误编码的纠删码当然没法重建数据。
这样，进一步引入了 KZG 多项式承诺（KZG Polynomial Commitments），多项式承诺是一个「代表」多项式的简化形式，用于证明多项式在特定位置的值与指定的数值一致，而无需包含该多项式的所有数据。Danksharding 中通过采用 KZG 承诺来实现对纠删码的验证。
如果我们可以把所有数据都放在一个 KZG 承诺中当然很省事，但是构建这个 KZG 承诺，或者一旦有部分数据不可用，重建这个数据——两者的资源要求都是巨大的。（实际上，单个区块的数据需要多个 KZG 承诺来保证）而同样为了降低节点负担从而避免中心化，Danksharding 中把 KZG 承诺进行了进一步的拆分，提出了二维 KZG 承诺框架。
当我们依次解决上述问题之后，依靠 DAS，节点或者轻客户端只需要随机下载 K 个数据块，就能够验证所有数据是可用的；这样一来，即便引入「大区块」之后，也不会过多地加重节点的负担。
（注：特别地，Danksharding 中采用的纠删码算法是 Reed-Solomon 编码；KZG 承诺是由 Kate、Zaverucha 和 Goldberg 发表的多项式承诺方案。在此暂不做展开，对算法原理感兴趣的读者可自行拓展。此外，确保纠删码正确性的方案还有在 Celestia 中采用的欺诈证明）
区块提议者与构建者分离（PBS）
在当前情况下，PoW 矿工和 PoS 验证者既是区块构建者（Builder），又是区块提议者（Proposer）——在 PoS 中，验证者可以用 MEV 的利润获取更多新的验证者席位，从而有更多机会去实现 MEV；此外，大型验证池显然比普通验证人有更强大的 MEV 捕获能力，这样导致了严重的中心化问题。于是，PBS 提出把 Builder 和 Proposer 进行分离。
PBS 的想法如下：Builder 们构建一个排好序的交易列表，并且把出价提交给 Proposer。Proposer 只需要接受出价最高的交易列表，且任何人在拍卖的获胜者被选出之前，无法知道交易列表的具体内容。
这种分离和拍卖的机制引入了博弈和 Builder 之间的「内卷」：毕竟每个 Builder 捕获 MEV 的能力不尽相同，Builder 需要权衡潜在的 MEV 利润、以及拍卖出价之间的关系，这样实际上减少了 MEV 的净收入；而无论最终 Builder 提交的区块是否能够顺利产出，都需要向 Proposer 支付竞价的费用。这样一来，Proposer（广义上是所有验证者集，一定时间内随机重选）相当于分享了一部分 MEV 的收入，削弱了 MEV 的中心化程度。
以上介绍了 PBS 在解决 MEV 方面的优势，而引入 PBS 还有另一个原因。在 Danksharding 中，对 Builder 的要求是：在 1 秒左右计算出 32MB 数据的 KZG 证明，这需要 32-64 核的 CPU；并且在一定时间内以 P2P 的方式广播 64MB 的数据，这需要 2.5Gbit/s 的带宽。显然验证者无法满足这样的要求。
于是 PBS 把两者分开，Proposer 仍然作为一般验证者节点，负责选择交易列表，并广播区块头；而 Builder 作为一个专门的角色，负责上述工作和构建交易列表。
去年 10 月，Vitalik 提出了双 Slot PBS 方案（注：每个 Slot 为 12 秒，是信标链的时间单位），但具体的 PBS 方案仍然在讨论中。
抗审查列表（crList）
但 PBS 也带来一个问题，如果某个 Builder 总是出最高价（甚至宁愿承担经济损失）来赢得拍卖，那么他实际上有了审查交易的能力，可以选择性地不把某些交易包含在区块中。
为此，Danksharding 进一步引入了抗审查列表 crList（即 Censorship Resistance List），即 Proposer 有权利指定一个交易列表，这个交易列表必须被 Builder 所包含；在赢得拍卖后，Builder 需要证明 crList 中的交易都已经被包含在内（或区块已满），否则该区块将被视为无效。
小结
把上述的数据可用性采样（DAS）、区块构建者和提议者分离（PBS）以及抗审查列表（crList）组合起来，就得到了完整的 Danksharding。我们发现，「分片」的概念其实已经被淡化了，尽管保留了 Sharding 的叫法，但实际上的重点已经放在对数据可用性的支持上。
那么 Danksharding 对比原分片有哪些优势呢？
（Dankrad 本人在这里列举了 Danksharding 的 10 个优点，我们选取两个来具体解释）
在原分片中，每个单独的分片都有其提议者和委员会，分别对分片内的交易验证进行投票，并由信标链的提议者收集所有投票结果，这项工作很难在单个 Slot 内完成。而在 Danksharding 中只在信标链上存在委员会（广义的验证者集，一定时间内随机重选），由这个委员会来验证信标链区块和分片数据。这相当于把原来的 64 组提议者和委员会简化为 1 组，无论是理论还是工程实现的复杂度都大大降低了。
Danksharding 的另一个优点是，以太坊主链和 zkRollup 之间有可能实现同步调用。上文我们谈到，在原分片中信标链需要收集所有分片的投票结果，这会产生确认的延迟。而在 Danksharding 中，信标链的区块和分片数据由信标链的委员会进行统一认证，也即同个信标区块的交易可以即时访问分片的数据。这样激发了更多可组合性的想象空间：例如 StarkWare 提出的分布式 AMM（dAMM），能够跨 L1/L2 进行 Swap 或共享流动性，从而解决流动性碎片化的问题。
在 Danksharding 得到实施之后，以太坊将变成 Rollup 的统一结算层和数据可用性层。
Closing Thoughts
在上图中，我们对 Danksharding 进行一个总结。
综上，我们大致可以看到，未来的 2 至 3 年内，以太坊路线图的指向性是非常明显的——围绕服务 Rollup 而展开。尽管在此过程中路线图改动与否仍然是未知数：Danksharding 预计将在未来 18-24 个月内实现，而 Proto-Danksharding 将在 6-9 个月内实现。但至少我们明确了 Rollup 作为以太坊的扩容基础，占据着一定的主导地位。
根据 Vitalik 提出的展望，在此我们也提出一些预测性思考和猜想：
一是类似 Cosmos 的多链生态，未来以太坊上将出现多 Rollup 的竞争格局，由以太坊为它们提供安全性和数据可用性的保证。
二是跨 L1/Rollup 基础设施将成为刚需。跨域 MEV 将带来更加复杂的套利组合，类似上述提到的 dAMM 带来更丰富的可组合性。
三是多 Rollup 的生态应用将超越以太坊本身。由于以太坊的定位退居其次，作为 Rollup 的数据可用性层，我们猜测更多的应用会迁移到 Rollup 上面去做（若第二点成立）；或者至少在以太坊和 Rollup 上面同时做应用。
参考材料：
https://consensys.net/blog/blockchain-explained/the-roadmap-to-serenity-2/
https://www.web3.university/article/ethereum-sharding-an-introduction-to-blockchain-sharding
https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698
https://twitter.com/pseudotheos/status/1504457560396468231https://ethos.dev/beacon-chain/
https://notes.ethereum.org/@fradamt/H1ZqdtrBF
https://cloud.tencent.com/developer/article/1829995
https://medium.com/coinmonks/builder-proposer-separation-for-ethereum-explained-884c8f45f8dd
https://dankradfeist.de/ethereum/2021/10/13/kate-polynomial-commitments-mandarin.html
https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum
