荐读｜重新认识分片：以太坊扩容的未来

免责声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表MarsBit官方立场。

小编：记得关注哦

来源：MarsBit News

在 The Merge 后，原本最令人期待的就是分片链的来临，分片链上线后可以大大增加以太坊的吞吐量。在原本 Eth 2.0 的规划是分片链加上全新的执行层，因为执行层的实作遇到难题，加上 rollups 随着时间技术越趋成熟，Vitalik 于 2020 年 10 月提出以 rollup 为中心的规划，后来的方向朝向分片链（储存数据）加上 rollups。去年（2021）底，以太坊研究员Dankrad Feist提出 Danksharding，完全颠覆了原本分片链的设计，进而成为以太坊未来扩容新的方向。本文会一步步分析何谓 Danksharding，及其优异之处。

这篇 Delphi Digital 的文章，对于 Danksharding 技术细节与未来以太蓝图有非常详尽的解释，欲更深入了解者，推荐一读（文长请小心服用）。

前情提要

现在 PoW 主链负责了共识，执行跟数据储存。Eth 2.0 的设计是将这三个功能分开，共识层由信标链（Beacon chain）负责，资料层由分片链（shard chains），在分片链上做各自的执行层有研究上的挑战，且执行的服务可由 rollups 提供，所以不作执行层的分片。

source: https://vitalik.ca/general/2021/04/07/sharding.html

分片链有 64 条，每条有自己的数据跟一组的验证节点，验证节点们负责验证所属分片链。为避免验证节点被买通或互相串通，所以每过一段时间，验证节点就会被分配到到不同的分片链上，对不同分片做验证。切换到不同的分片，需要先同步新的分片链上的数据，所以每一段时间，就会有一次大范围节点间的同步，而这过程复杂，难以确保时间内都能及时同步完成。此外，跨分片链的沟通也是一个复杂的问题，而此设计也加深了 MEV 问题。

以 rollups 为中心的蓝图

Vitalik 这个提案奠定了以太坊未来发展的方向，将 L1 定位成资料公证的链，任何 rollups、L2 的交易或是任何需要公证的数据，都放到链上，验证节点不需验证数据的有效性*，只需要确保数据可取用性（data availability），而数据有效性的验证都让其他 rollups 或 L2 处理。

以 optimistic rollups 来说，sequencer 可以放一个不合法的 state 到链上，宣称自己账户（凭空）多了 100 万，但正常运作的节点都能验证这是一个不合法的 state。

当时的时空背景，各家 optimistic rollups 已经准备主网上线，zk rollups 不支持合约的版本也已经上线一阵子，rollups 的技术已相对成熟。以安全性、复杂度或完成度来说，将主链的交易在不同的分片执行，最终再由信标链对跨分片交易取得共识的方式，不如把主链当作数据公证层，再单纯对数据做共识 ，并将执行的责任就交给已经准备上线的 rollups，如此设计会更加简单且快速。

A rollup-centric ethereum roadmapWhat would a rollup-centric ethereum roadmap look like? Last week the Optimism team announced the launch of the first…ethereum-magicians.org

Danksharding

Danksharding由以太坊研究员Dankrad Feist于 2021 年底提出，是一个全新的设计，不再是补强原本分片链的设计，而是取代原本分片的设计。Danksharding 不把数据放在不同的链，而是把所有的数据都放一起，产生一个超大区块，区块中数据会被分成 256 组（每组可容纳 ~125KB，目前区块平均大小约 ~90KB）。可以想象一组数据对应原本的一个分片链，所以相当于扩展成 256 条分片链的交易量，而且 256 条链会同时完成验证（因为是同一个区块），不像先前设计，还需要互等（因为会有跨链交易，所以自己分片验证完后，还需要等其他分片也验证完）。不过可以想象的是，如果全部资料都塞成到一个区块，在网络带宽、储存空间跟运算能力等都会有问题。我们下面一一来解释。

新的设计中没有了分片链，因此，数据可取用性（data availability）的责任就落在信标链身上了。

source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_690

如图中所示，所有数据都在绿色的这个大区块中，包含了原本的 beacon block 跟分组后的数据，且所有验证者都一起验证，不再是分开不同委员会来做验证。

透过抽样挑战来验证数据可取用性（Data Availability Sampling）

数据抽样挑战这个概念在当初设计 Eth 2.0 轻节点时就有提出了，概念上不变，细节可以参考这篇

Data Availability on Ethereum 2.0 Light Node本来是要展开一个叫做「与大神(C.C. Liang)共笔系列」，无奈C.C.太忙，最终还是只能自干，不过依旧感谢 C.C. Liang 提供素材跟观念厘清medium.com

快速介绍一下，这个设计使用了纠删码（Erasure Coding）的技术。纠删码是现今常使用的一项技术，例如磁盘阵列或是网络通讯。简单来说，就是将原本数据做复制，所以遗失了部分数据，仍能重组回原本数据。

使用纠删码的好处是，就算是区块建造者窝藏部分数据也没关系。举例来说，把数据被分成 100 份，没有使用纠删码，验证节点在抽样时，就要确保数据要 100% 都有被取到，只要缺了 1 份，数据就无法再重组起来。但是透过纠删码，将数据延展为 200 份，只需要确保总抽样数有 50% +1 份，剩下的就算是区块建造者窝藏起来，也没关系，因为只要有 50% +1 份数据，就足够能重建回原本的数据。而这 50% +1 的抽样总数，就需要有足够的验证节点一起来做抽样挑战。纠删码加上足够的抽样挑战，就能确保数据可取用性。

Chih-Cheng Liang写的数据可得性，写得很清楚且简单易懂，十分推荐！数据可得性 - HackMD数据可得性 在数据分片的环境底下，我们不能让全节点去完整下载其他分片上所有的数据，否则就失去分片的意义了。 但我们仍然要顾虑一种情况：某个分片上的恶意节点，发布了承诺，却窝藏承诺背后的资料没有hackmd.io

2 维 KZG 机制

使用了纠删码，会将原本的数据加了备用的信息，使数据量变大，但是要怎么确保备用信息是使用纠删码产生的还是只是无意义的垃圾数据呢？我们可以透过密码学的承诺，来确保资料是如我们预期的。这边选用了 KZG 承诺来作为数据有效的确认。（何谓密码学的承诺，可以参考下文 “多项式承诺” 一节。）

暸解 Plonk在撰写 SNARKs 的应用程序时，最令人头痛的就是可信任设置，每个应用都需要建立自己的可信任设置。在 Plonk 出现后，一切就不一样了，Plonk 的可信任设置是通用的且可以更新的，因此在未来 SNARKs…medium.com

在实务上，不会产生一个大的 KZG 承诺，因为重建区块可能会很常发生，而重建后需要确认承诺是否一致，但要产生整个大区块的 KZG 承诺需要强大的节点才能完成（除了产生区块的节点需要产生承诺，验证节点也需要产生承诺，来确保下载的数据是正确的），因此这样一个区块一个承诺并不符合需求，强大的验证节点也不符合去中心化的愿景。所以会将每个分片数据产生一个 KZG 承诺，当验证节点需要重建数据时，只需确认多个分片的 KZG 承诺即可。为了更有效率，采用 2 维 KZG 的机制，将 256 个分片的 KZG 承诺也使用了纠删码，扩展成 512个。

source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_705

扩展成 2 维后，经过计算，所需的抽样挑战数就会增加为 75 次，才能确保数据可取用性，如此验证节点所需带宽则为

512 bytes * 1 block * 75 samples / 16 secs = 2.5 KB/s ＊

相较于之前 64 个分片需要带宽 60KB/s 减少了许多。

在 Danksharding 中，提议将 slot 的时间从 12 秒改为 8 秒，这里分母的 16 秒则是两个 slot 的时间，原因下面章节会再解释。

验证机制

刚刚 75 次的抽样挑战是在说明，512 x 512 组资料中一节点若任意取 75 组且都有取得，有非常高的机率代表数据的可取用性（完整存在且可取得的）。但若只有单一节点成功完成抽样挑战，仍无法保证数据可取用性，需要整个网络一起抽样挑战，当有足够多的抽样总数时（这里我们需要 75% + 1 组），就算区块建造者藏数据，依然可以透过已取得的样本来重建区块。

在每个 epoch 有 32 个 slot，验证者会被平均分配到这 32 slots 中，每个验证者需要任意取两个横列及两个直行做验证，验证节点需要确保这四组数据在 32 slots（一个epoch ）的时间内都一直存在，才在所属的 slot 中对此区块做投票。整个网络上需要足够多的验证者，才能确保区块的可取用性，因此降低对验证节点的需求，以提升验证者数量是非常重要的，而 2 维 KZG 的设计正是大大的减轻了验证节点的负担。

有了抽样挑战的设计，网络中人人都可以是轻节点（除了少数的出块的节点），使得运行节点变得更容易、成本更低。

分离区块发布者跟区块建造者（Proposer-Builder Separation, PBS）

在现今，矿工为了得到最大利润，会有很多复杂的策略从交易中提取额外获利，在未来区块变大后，提取额外利润的可能性更多了，即使运行相同的策略对节点的负担也更吃重，再加上产生 KZG 承诺需要强大的运算能力，如此会使节点更加中心化。为了降低节点的硬件需求，使得网络更加去中心化＊，将生产区块跟发布区块的角色分开。区块建造者（builder），在利润最大化的前提下将交易排序，产生出区块，而区块发布者（proposer），负责发布由区块建造者所产生的区块。若同时有多位区块建造者产生区块，则透过竞价机制来决定发布谁的区块。这个分工有没有觉得很熟悉？这个跟现在 Flashbots的机制一样，将产块的功能独立出来，让区块建造者可以从交易中抽取他们利益，矿工只需发布区块。在这个分离的架构中，区块建造者的收入是 priority fee 跟他们从交易中抽取的价值，区块发布者则收区块建造者给的竞价费。但是在协议层做这样的分工设计，会加重 MEV 的现象及造成审查攻击。

＊在 Vitalik Endgame 一文中也认为需要部分的中心化来扩大规模，但只需要去中心和去信任的验证，就可以维持权力的平衡。因此在 Danksharding 中强大的区块建造者也呼应了 Vitalik 的想法。

两阶段 PBS

source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_673

为了使整个网络更有效率，且进一步减少 MEV 的产生，使用 commit-reveal 两阶段的机制。就是在竞价的阶段，区块建造者只提供区块标头（block header）给区块发布者，等此区块标头赢得竞标后，到下一个 slot 区块建造者再将区块内容公开，验证者再对区块内容做验证。此两阶段的方法，一方面降低网络流量，另一方面可避免被再度 MEV。因为如果区块发布者将整个区块内容都散布到网络中，其他的区块建造者就可拆解其交易策略，再做微调，提出一个更有竞争力的区块。甚至，区块发布者可以直接复制其区块内容，就不用再给区块建造者任何费用了。

但两阶段最大的缺点就是交易会被延迟确认，本来只需要一个 slot（12 秒） 就会可以确认打包，现在就变成两个 slot（24 秒） 了。目前有在计划将一个 slot 改为 8 秒，这样就可以减少确认的时间，不过仍在讨论中。

抗审查清单（Censorship Resistance List, crList）

PBS 的架构，给予了区块建造者更高的审查交易能力，他们可以根据自己的喜好，选择想要打包的交易或是忽略特定的交易。因此，提出了混合式 PBS（hybrid PBS），建立在原本的两阶段 PBS 之上。两个方案最大的差异是，区块建造者可以打包的交易受到限制，区块发布者会提供交易列表，而区块建造者必须将列表内的交易都打包才行，如下图

1. source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_780区块发布者提供一份抗审查列表，列表内的所有交易要尽可能地被打包（原则上是都要被打包，不过可能有些例外状况可以不用，但目前规格也尚未确定）
2. 区块建造者根据抗审查清单产生出区块，然后竞价，竞价内容必须包含抗审查清单的哈希值（如同二阶段 PBS，只有揭露区块标头）
3. 区块发布者接受区块建造者的出价
4. 区块建造者发布其区块，证明包含了所有来自抗审查列表里的交易，否则不会被验证者接受
5. 验证者确认区块内容的有效性

但此提案还是有些漏洞，例如说，区块发布者提交了一份空的清单，那这个机制就被绕过了。最终 PBS 的设计还在讨论中，还需要更多的研究。

Proto-Danksharding（EIP-4844）

proto-danksharding 就是 EIP-4844，是 post-merge 一个重要的更新。 Danksharding 大幅引进了新的技术，将复杂度大大增加，这项 EIP 可以视为将 Danksharding 拆成两阶段，将有解决方案且风险较低的的部分先更新，替为未来的 Danksharding 的上线做铺路。此外，此 EIP 也能大幅降低 rollups 的上链成本。现今 rollups 都是使用 calldata 将事务数据永久储存在链上，但对 rollups 来说，这些历史交易其实只需要储存一段时间就足够，不需要永久储存，若对历史交易有需求的人，可以自行下载并储存。

proto-danksharding 主要是引进了一种新的交易类别，这个交易类别可以携带新的数据类型 blob，且此类型数据会在固定时间（30 至 60 天）后被删除。blob 跟 calldata 的不同在于，blob 可携带数据量非常大（有 128KB）但成本很低（120K gas），此外，EVM 也无法取得 blob 的内容。

应该不少人会有疑问，为什么不降低 calldata 成本就好？因为要预防在最极端状况下，区块会变超大。目前最大的 gas limit 是 30M，calldata 每 byte 需 16 gas，以此状况，区块约是 1.8MB，若我们将 calldata 成本便宜 5倍甚至 10 倍，那极端状况下区块大小就会是 9MB 或 18MB。一般状况下两者没有太大的差距，但在极端状况下，这是 calldata 成本降低后会碰到最直接的问题。

那我们来算算 proto-Danksharding 极端状况下的资料量。每个 blob 会有 4096 个 32 bytes 的数据，目前规格每个区块最多有 16 个 blob（Danksharding 后预计有 256 个），因此我们可以得出 4096 * 32 * 16 = 2MB，相较于直接降低 calldata 成本，blob 的形式可以乘载的数据更多，在极端状况却不会让区块大小增长太大。

此外，历史数据的储存不该是协议层需要在意的，有需求者可以透过其他第三方项目（例如，etherscan, the graph）获取历史数据，加上在 PoS 的设计下，交易是有最终确定性的，因此历史数据对于协议层来说，更加没意义。

像是 Mina 使用零知识证明的方式证明区块的有效性，新的同步节点并不需要去下载全部交易并跑过一次做确认，只需要从有被证明过的区块开始进行同步即可。Mina 设计之初就是以不需历史数据为目标。

小结

未来，在以 rollups 为主轴的路线下，链上的数据将都是 blob，而 blob 过一段时间后，就会被删除，解决了因历史交易而日益增长的储存空间。而透过 PBS 机制，让需要强大运算的责任外包给区块建造者（builder），加上产生多组 KZG 承诺，减少了验证节点在重建时的运算需求。透过二维纠删码，虽然抽样挑战次数变多，但只须对单一链做抽样挑战，所以带宽要求也减少了。原本分片设计把验证者拆分成 32 组，分组做验证，而现今的设计，全部的验证节点一起验证数据，也因此有更高的安全性。

此外，比起原本分片链的设计，现在只有一个大的信标链区块，所以 L2 的交易被打包成 blob 写进 L1 后会直接被确认（原本需要等待所有分片的结果），因此 zk-rollups 可以做到与 L1 做实时互动。

不过，这个全新设计，引入了不少的未知数，至于什么时候能上线，可能还需要再等等。

【责任编辑：徐来】