以太坊已经转向以 rollup 为中心的路线图。
原文：The Hitchhiker's Guide to Ethereum（Delphi Digital）
作者：Jon Charbonneau
编译：zCloak Network
原用标题（译后）：以太坊漫游指南（中篇）
封面：William Tempest（Ethereum）
第一部分：通往 Danksharding 之路，前文内容详见——以太坊漫游指南（上篇）
Danksharding
PBS（出块者-区块打包者分离）的设计最初只是为了削弱验证者集群的 MEV 中心化力量。然而，Dankrad 最近利用这一设计解锁了一个更好的分片结构 —— Danksharding。
Danksharding 利用特定的区块打包者来创建更紧密的信标链执行区块和分片集成。如果没有 PBS ，Danksharding 就无法实现，因为常规的验证者无法处理充满 rollup 数据 blob 的区块占用的巨大带宽，所以现在我们有专门创建整个区块的区块打包者、在某时刻对该区块进行投票的委员会，以及出块者。
分片 1.0 有 64 个独立的委员会和出块者，因此每个分片都可能单独不可用。但在 Danksharding 中，信标链执行区块和分片之间更紧密的集成能够一次性确保数据可用性。本质上 Danksharding 中的数据仍然是 "分片化的 "，但实际使用者会感觉更像是大区块，这是一件好事。
Danksharding – 诚实多数验证
验证者证明数据的可用性，如下所示：
这依赖于验证者中大多数诚实 —— 单个验证者检测到的行和列的可用性不足以让该验证者在统计上相信整个区块是可用的，验证者中大多数诚实决定整个区块是否可用，这也是为什么去中心化验证如此重要。
这与我们之前讨论的 75 个随机样本有所不同。隐私随机抽样是资源匮乏的个体检查可用性时使用的方法（例如，我可以运行一个数据可用性抽样轻节点并知道区块是可用的），但是，验证者将继续使用检查行和列的方法来检查可用性以及引导区块重构。
Danksharding – 重构
只要单个行或列的 50% 是可用的，那么数据可用性抽样验证者就可以轻易地、完整地重构该行或列。当它们重构行或/和列中缺失的数据块时，它们会将这些数据块重新分配到正交线上。这有助于其它验证者根据需要从相交的行和列中重建任何丢失的数据块。
重构一个行或/和列中可用数据块的安全假设是：
- 有足够多的节点执行采样请求，以便它们共同拥有足够的数据来进行重构
- 用于节点间广播各自区块碎片的同步假设
那么，多少个节点是足够的呢？粗略估计大约需要 64,000 个实例（目前有超过 380,000 个实例）。这也是一个非常悲观的计算，因为它假设同一验证者运行的节点没有交叉（这与节点被限制为 32 个 ETH 实例的情况相去很远）。如果你的采样超过 2 行和 2 列，你就会因为交叉而增加集体检索到用于重构的数据的几率，这会以平方扩展 —— 如果有 10 个或 100 个验证者正在运行，需要的实例可以减少几个数量级。
如若在线验证者的数量非常低，可以通过设置 Danksharding 来自动减少分片数据 blob 计数。因此，安全假设就会被降低到安全水平。
Danksharding - 恶意多数安全与隐私随机抽样
我们看到，Danksharding 验证依赖于诚实多数对区块进行证明，单个验证者无法通过下载几行和几列来证明一个区块是否可用，但隐私随机抽样允许单个验证者在无需信任任何人的情况下确保某区块是可用的，这就是前面讨论的节点检查 75 个随机样本。
隐私随机抽样在网络方面是一个非常难解决的问题，所以 Danksharding 在初始阶段不会包含该组件。
"隐私"是尤其重要的，如果攻击者对你进行去匿名化处理，他们就能欺骗少量的采样节点。攻击者可以只返回验证者请求的数据块，扣留其余的请求不作回应，所以验证者无法从自己的抽样中知道是否所有的数据都是可用的。
Danksharding – 关键要点
Danksharding 除了名字好听，其性能也令人难以置信。它可以实现以太坊统一结算和数据可用层的愿景。这种信标区块和分片的紧密耦合本质上是假装没有分片。
让我们明确一下为什么 Danksharding 甚至被认为是 "分片"。“分片" 唯一剩下的部分就是验证者不负责下载所有数据，而这就是为什么 Proto-danksharding 不被认为是 "分片的" 的原因（尽管它的名字里有 "分片 sharding"）。Proto-danksharding 要求每个验证者完整地下载所有分片 blob ，以验证它们的可用性；Danksharding 则随后将引入抽样，单个验证者只需下载分片 blob 的片段。
值得庆幸的是，最小分片是比分片 1.0 更简单的设计（所以有更快的交付不是吗？）。更简单的意思是：
- 与分片 1.0 规范相比，Danksharding 规范少了数百行代码（客户端少了数千行）
- 不再有分片委员会基础设施，委员会只需在主链上投票
- 不再追踪独立分片 blob 的确认，因为现在它们都在主链上得到确认，或者不被确认。
这样做的一个好处是合并了数据收费市场。分片 1.0 中，独立出块者们各自提交不同的区块使数据收费市场非常零碎。
取消分片委员会也加强了反贿赂性。Danksharding 的验证者每个周期对整个区块投票一次，因此数据会立即被整个验证者集的 1/32 确认（每个周期有 32 个槽）。虽然分片 1.0 的验证者同样是每个周期投票一次，但每个分片的委员会都会被轮换，因此每个分片只被 1/2048 的验证者集（64 个分片中所有验证者的 1/32）确认。
区块与二维 KZG 承诺方案相结合也大大提高了数据可用性采样的效率。分片 1.0 需要 60KB/s 的带宽来检查所有分片的全部数据可用性，而 Danksharding 只需要 2.5KB/s。
Danksharding 还保留了 ZK-rollups 和 L1 以太坊执行之间的同步调用，也就是说，来自分片 blob 的交易可以立即被确认并写入 L1，因为一切都发生在同一个信标链区块中，这实在太棒了。但在分片 1.0 中，由于独立分片各自确认，使得其不具备这种可能性。这形成了一个令人兴奋的设计空间，对共享流动性（如 dAMM）等可能是非常有价值的。
Danksharding – 区块链可扩展性的限制
模块化的基础层可以优雅地扩展 —— 更大程度的去中心化带来了更多的扩展，向数据可用性层添加更多节点可以安全地增加数据吞吐量（即上面有更多的空间进行 rollup)。这与我们今天看到的情况有本质性区别。
虽然区块链的可扩展性仍将受到限制，但相比目前的情况，我们可以将区块链的可扩展性提高几个数量级。安全和可扩展的基础层允许执行量的激增，并且随着时间的推移，数据存储和带宽的改进也将允许更高的数据吞吐量。
想要超越这里考虑的数据可用性吞吐量是有完全可能的，但很难预估这个最大值最终会达到多少。这里没有一条明确的界限，只有一个包含一些让人感到不舒服的假设的区域:
- 数据存储 —— 这与数据可用性和数据可检索性有关。共识层的作用不是无限期地保证数据可检索性，而是让数据在足够长的时间内可用，让任何想下载它的人都能下载，以满足我们的安全假设，然后数据可以被转储到任何其它地方，因为历史是 N 个信任假设中的 1 个，而且从整体局面来看我们实际上不会谈论这么多的数据。不过，几年后，随着吞吐量的指数级增加，这可能依然会成为人们非常关注的一个问题。
- 验证者 —— 数据可用性抽样需要足够多的节点来共同重构区块，否则攻击者可以在周围侍机而待，仅对他们收到的查询做出回应。如果提供的这些查询不足以重构区块，攻击者可以扣留其余的数据，那么重构就没戏了。为了安全地增加吞吐量，我们需要增加更多的数据可用性抽样节点或提高它们的数据带宽要求，这些对于这里讨论的吞吐量来说是合理的。不过，如果吞吐量在这个设计的基础上再增加几个数量级，可能就会变得棘手不那么容易处理了。
请注意，区块打包者并不是重构的瓶颈。如果你需要为 32MB 的数据快速生成 KZG 证明，最好有一个 GPU 或相当强大的 CPU 加上至少 2.5G Bit/s 的带宽。当然，区块打包者是一个专门的角色，对他们而言，上面提到的这些都是可以忽略不计的业务成本。
Proto-danksharding (EIP-4844)
好东西总是值得耐心等待，比如 Danksharding。Proto-danksharding 旨在帮助我们渡过这个等待期 —— 为过渡期提供数量级的扩展，Proto-danksharding 实现了必要的向前兼容步骤（指上海硬分叉），以加速通往 Danksharding。然而，它实际上还没有实现数据分片（验证者目前还是需要逐一下载所有的数据）。
Rollups 现在使用 L1 "calldata " 进行链上永久存储。但 rollups 只是在一些合理的时间段内执行数据可用性，以便任何对数据可用性感兴趣的人都有足够的时间下载它们。
EIP-4844 引入了新的携带 blob 的交易格式，rollups 将使用这种格式进行数据存储。Blob 携带的大量数据（~ 125KB）比相同数量的 calldata 便宜得多。由于数据 blob 将在一个月后从节点上被删除 ，所以有足够的时间来满足数据可用性安全假设，同时删除数据 blob 也降低了存储需求。
在扩容语境下，目前以太坊区块的平均大小通常为 ~ 90 KB（calldata 占用其中的 ~10 KB）。由于数据 blob 在一个月后会被删除，所以 Proto-danksharding 为 blob 释放了更多的数据可用性带宽（目标是 ~1MB，最大为 ~2MB），不会对节点造成永久性的拖累。
一个 blob 是一个包含 4096 个字段元素的矢量，每个字段元素有 32 字节。Proto-danksharding 允许每个区块最多有 16 个 blob ，而 Danksharding 会将其提升到 256 个。
Proto-danksharding 数据可用性带宽 = 4096 x 32 x 16 = 每区块 2 MiB，目标是 1 MiB
Danksharding 数据可用性带宽 = 4096 x 32 x 256 = 每区块 32 MiB，目标是 16 MiB
每一步都是数量级级别的扩展。Proto-danksharding 仍然需要共识节点来完整地下载数据，所以它比较保守。Danksharding 在验证者之间分配存储和传播数据的负载。
以下是 EIP-4844 在通往 Danksharding 的道路上引入的一些好东西：
- 携带数据 blob 的交易格式
- 对 blob 的 KZG 承诺
- Danksharding 所需的所有执行层逻辑
- Danksharding 所需的所有执行/共识交叉验证逻辑
- 信标区块验证和数据可用性抽样 blob 之间的层分离
- Danksharding 所需的大部分信标区块逻辑
- Blob 有可以自我调节的独立 gas 价格（具有指数定价规则的多维 EIP-1559）。
紧接着，Danksharding 将进一步增加：
- PBS（出块者-区块打包者分离）
- 数据可用性抽样
- 二维 KZG 方案
- 监管证明（Proof-of-custody）或类似的协议内条件，以使每个验证者都能验证每个区块中分片数据特定部分的可用性（可能需要一个月左右的时间）。
注意这些数据 blob 是作为链上执行的新交易类型引入的，但它们不会给执行方带来的额外要求。EVM 只查看附在 blob 上的承诺。使用 EIP-4844 进行的执行层更改也向前兼容 Danksharding ，在这方面不需要进行更多的改动。从 Proto-danksharding 升级到 Danksharding 只需要更改共识层。
数据 blob 由共识客户端在 Proto-danksharding 中完整下载。Blob 目前在信标区块体中被引用，但没有被完全编码。Blob 的内容以 “sidecar” 的形式单独传播，而不是将其全部嵌入区块体。在 Proto-danksharding 中完整下载的每个区块都有一个 blob sidecar，Danksharding 验证者将在这上面执行数据可用性抽样。
我们在前面讨论了如何使用 KZG 多项式承诺对 blob 进行承诺。然而，EIP-4844 没有直接使用 KZG，但实现了我们实际需要的东西 —— 带版本哈希。这是一个单一的 0x01 字节（表示版本），后面接着 KZG 的 SHA256 哈希的最后 31 字节。
这样做是为了更容易地实现 EVM 兼容和向前兼容：
- EVM 兼容 —— KZG 承诺有 48 字节，而 EVM 更自然地使用 32 字节的值。
- 前向兼容性 —— 如果我们从 KZG 转向其它东西（比如可用于抗量子的 STARKs），承诺可以继续是 32 字节的。
多维 EIP-1559
Proto-danksharding 最终创造了一个量身定制的数据层 —— 数据 blob 将拥有自己独特的收费市场，即有独立浮动的 gas 价格和限制。因此，即使某个 NFT 项目在 L1 上卖了一堆猴子土地，你的 rollup 数据成本也不会增加（尽管证明结算成本会增加），这也承认了现在任何 rollup 项目的主要成本来自于将其数据发布到 L1（而不是证明）。
gas 费市场不变，新增数据 blob 市场：
Blob 费是以 gas 收取的，但它是一个根据自身 EIP-1559 机制的可变的金额。每个区块的长期平均 blob 数量应等于目标数量。
验证者实际上在并行运行两个拍卖 —— 一个用于计算，一个用于数据可用性。这是高效资源定价的一个巨大飞跃。
这里有一些有趣的设计，例如，将目前的 gas 和 blob 定价机制从线性 EIP-1559 改为新的指数 EIP-1559 机制，这或许是合理的。目前的实现在实践中并没有平均到我们的目标区块大小，今天的基本费用还没有完全稳定下来，所以观察到的块均 gas 消耗平均超过目标值 ~3%。
（因本文篇幅过长，后续详见下篇）
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
