第一部分：通往Danksharding之路。详情请参考以太坊漫游指南(第一部分)和以太坊漫游指南(第二部分)。 　　

　　

　　第二部分 - 历史和状态管理 　　

　　

　　以下是一些基础知识的快速回顾： 　　

　　

　　历史——链条中发生的一切。历史不需要快速访问，可以放在硬盘上。从长远来看，历史是N个诚实的假设之一。状态――所有往来账户余额、智能合约等的快照。所有完整的节点(当前)需要掌握状态以验证事务。状态RAM太大，硬盘太慢(状态放SSD里)。高吞吐量区块链的状态不断扩大，其增长率远远超过了我们日常笔记本电脑上可以保存的数据量。如果日常用户无法维护这些状态，就无法充分验证，这与去中心化背道而驰。简而言之，状态非常大，所以如果让节点持有状态，会使一个节点很难运行。如果跑一个节点太难，我们普通人是不会去做的，所以需要确保不会出现这种情况。 　　

　　

　　Calldata Gas 成本降低与总 Calldata 限制（EIP-4488） 　　

　　

　　Proto-danksharding是向danksharding的一个很好的过渡，它满足了很多最终需求。在一个合理的时间框架内实现原型danksharding可以提前Danksharding到来的时间线。 　　

　　

　　一个更简单的应急方案是EIP-4488。虽然没那么优雅，但是解决了燃费的燃眉之急。不幸的是，EIP-4488没有意识到到达丹克斯哈丁所需的中间步骤，所有不可避免的变化在未来仍然需要做出。如果你觉得Proto-danksharding比我们希望的要慢，可以通过EIP-4488快速解决拥塞问题(只需要修改几行代码)，6个月后再使用Proto-danksharding(时间可能会有变化)。 　　

　　

　　EIP-4488有两个主要部件： 　　

　　

　　将calldata的成本从每字节16 gas降低到每字节3 gas，在每个块中增加1MB的calldata限额，在每个交易量中增加300字节(理论上约1.4MB)来提高限额，都是为了防止最坏的情况发生——一个块中的calldata将达到18 MB，远远超过以太坊的容量。虽然EIP-4488增加了以太坊的平均数据容量，但以太坊的突发数据容量实际上略有下降(3000万gas/16 gas=每个calldata字节1.875 MB)，这是由于其calldata的限制。 　　

　　

　　 　　

　　

　　由于EIP-4488的calldata和一个月后可以删除的Proto-danksharding的数据blob，EIP-4488的持续负载比Proto-danksharding高得多。当使用EIP-4488时，历史数据的增长将明显加快，这将成为运行节点的瓶颈。即使EIP-4444与EIP-4488同步实现，执行负载历史也只会在一年后被删除，所以很明显Proto-danksharding较低的持续负载更可取。 　　

　　

　　 　　

　　

　　在执行客户端中约束历史数据（EIP-4444） 　　

　　

　　EIP-4444允许客户端在本地删除一年以上的历史数据(块头、块体和收据)，并强制客户端停止在p2p层提供此类已删除的历史数据。删除历史数据允许客户端减少用户的磁盘存储需求(目前为数百GB，并且还在增加)。 　　

　　

　　删除历史数据是非常重要的，但如果实施EIP-4488，它将是强制性的，因为EIP-4488的实施将显著增加历史数据。不管怎样，我希望这件事能在较短的时间内完成。最终会需要某种形式的过时历史数据，所以现在是处理这些数据的好时机。 　　

　　

　　链的完全同步需要历史，但不需要验证新块(只需要状态)。因此，一旦客户端同步到链的顶端，只有在JSON-RPC上被显式请求时，或者当对等体试图同步链时，才会检索历史数据。随着EIP-4444的实施，我们需要找到替代解决方案。 　　

　　

　　客户端将无法像现在这样与devp2p“完全同步”——它们将从一个被视为创建块的弱主观检查点进行“检查点同步”。 　　

　　

　　请注意，弱主体性是转向PoS的过程中所固有的，并不是新的假设。我们需要使用有效的弱主观检查点进行同步，以防止远程攻击的可能性。这里假设客户不会从无效或旧的弱主观检查点进行同步。这个检查点必须存在于我们开始删除历史数据的时间段内(即一年内)，否则p2p层将无法提供所需的数据。 　　

　　

　　随着越来越多的客户端采用轻量级同步策略，网络的带宽使用率也会降低。 　　

　　

　　恢复历史数据 　　

　　

EIP-4444 在一年后删除历史数据， Proto-danksharding 删除 blob 的速度更快，大约一个月后删除。我们肯定需要这些，因为我们不能要求节点存储所有这些数据的同时还保持去中心化：

　　

EIP-4488 ―― 长期运行可能包括每个插槽 ~1MB，每年增加 ~2.5TB 存储空间Proto-danksharding ―― 目标是每个插槽 ~1MB，每年增加 ~2.5TB 存储空间Danksharding ―― 目标是每个插槽 ~16MB，每年增加 ~40TB 存储空间但这些被删除了的历史数据去哪里了呢？我们不是仍然需要它们吗？是的我们仍然需要。但请注意，丢失历史数据只会对个别应用程序造成风险，不会对协议造成风险，所以以太坊核心协议的工作就不应该是永久地维护所有这些达成共识的数据。

　　

那么，谁来存储这些数据呢？这里有一些潜在的贡献者:

　　

个人和机构志愿者区块探索者（如 etherscan.io），API 供应商和其它数据服务商第三方索引协议（如 TheGraph）可以创建激励性的市场，客户为历史数据和 Merkle 证明向服务器付费门户网络（目前正在开发中）客户端可以随机存储部分链历史，而门户网络会自动将数据请求定向到节点上例如 BitTorrent，每天自动生成并分发一个包含区块 blob 数据的 7GB 文件。特定于应用程序的协议，如 rollup，可以要求它们的节点存储与其应用程序相关的历史部分长期数据存储问题是一个相对容易解决的问题，因为正如前文所讨论的，它是 N 个中选 1 个的信任假设，我们距离它成为区块链可扩展性的终极限制还有很多年。

　　

弱无状态

　　

现在我们已经很好地掌握了管理历史的方法，但是处理状态呢？这实际上是目前提高以太坊 TPS 的主要瓶颈。

　　

全节点使用前状态根来执行一个区块中的所有交易，并检查后状态根是否与区块中提供的交易相符。为了知道这些交易是否有效，他们目前需要掌握状态，即验证是有状态的。

　　

进入无状态即无需用已掌握的状态来做一些作用。以太坊正努力实现 "弱无状态"，意味着验证区块不需要状态，但构建区块时需要。验证成为了一个纯函数 ―― 给我一个完全隔离的区块，我就可以告诉你它是否有效。基本上是这样的:

　　

　　

基于 PBS ，区块打包者仍然需要状态，这是可以接受的―― 无论如何它们是更中心化的高资源实体。专注于去中心化验证者，弱无状态为区块打包者带来了略多一点的工作，而使验证者的工则作少很多，这是一个很好的权衡。

　　

你将通过验证来实现这种神奇的无状态执行，区块打包者将在每个区块中包含正确状态访问的证明。验证一个区块实际上不需要完整的状态，而只需要该区块中正在被读取的或受区块中交易影响的状态。区块打包者将在一个给定的区块中包含受交易影响的状态片段，并通过验证人来证明他们正确地访问了这些状态。

　　

举个例子：Alice 想给 Bob 发送 1 个 ETH。为了验证包含这个交易的区块，我需要知道:

　　

交易之前 ―― Alice 有 1 个 ETHAlice 的公钥 ―― 由此得知签名是正确的Alice 的随机数 ―― 由此得知交易是以正确的顺序发送的执行交易后 ―― Bob 多了 1 个 ETH，Alice 少了 1 个 ETH在弱无状态的世界中，区块打包者将上述见证数据和其相应的准确性证明添加到区块中。验证者收到区块，执行它，并决定它是否有效。就是这样！

　　

以下是从验证者角度得出的一些结论:

　　

保持状态的巨大的 SSD 需求消失了 ―― 这是如今扩展面临的关键瓶颈带宽需求会增加一些，因为现在仍然需要下载见证数据和证明。这是 Merkle-Patricia 树的一个小瓶颈，但不是 Verkle tries 的瓶颈。你仍然执行交易以完全验证。无状态并不是当前扩展以太坊的瓶颈。由于状态膨胀不再是一个紧迫的问题，弱无状态也允许以太坊放宽对其执行吞吐量的自我限制，所以将 gas 限制提高 3 倍是合理的。

　　

在这一点上，大多数用户执行将在 L2 上进行，但更高的 L1 吞吐量也会对他们有利。Rollups 依靠以太坊进行数据可用性（发布到分片）和结算（需要 L1 执行）。随着以太坊扩展其数据可用性层，发布证明的摊销成本可能会占据 rollups 成本的更大份额（特别是对于 ZK-rollup）。

　　

Verkle Tries

　　

我们掩盖了这些见证的工作原理。以太坊目前使用 Merkle-Patricia 树来表示状态，但所需的 Merkle 证明对这些证人来说太大了，是切实不可行的。

　　

以太坊将转向 Verkle tries 来存储状态，Verkle 证明的效率要高得多，所以它们可以作为可行的见证来实现弱无状态。

　　

首先回顾一下 Merkle 树是什么：每笔交易开始时都会进行哈希计算 ―― 位于底部的哈希被称为 "叶子"，所有的哈希都可被称为 "节点"，每一个哈希都是是其下面两个 "子 "节点的哈希。最终产生的哈希即 "Merkle 根"。

　　

　　

这是一个用于证明包含交易的数据结构，但无需下载整个树。例如，你只需要 Merkle 证明中的 H12、H3 和 H5678 就可以验证交易 H4 被包含。我们有来自区块头的 H12345678，所以一个轻客户端可以向一个全节点索取这些哈希，然后根据树中的路由将这些值一起进行哈希计算。如果结果是 H12345678，那么我们就成功证明了 H4 在树中。

　　

不过树越深，到底部的路由就越长，因此你需要更多的项来证明。所以浅而宽的树更有助于高效证明。

　　

问题是，如果通过在每个节点下添加更多的子节点来扩宽 Merkle 树将是非常低效的，因为需要把所有兄弟哈希放在一起，以沿着树向上移动，因此需要为 Merkle 证明接收更多的兄弟哈希。这会使证明变得非常大。

　　

这里就是高效向量承诺的用武之地。请注意，Merkle 树中使用的哈希实际上是仅能有效承诺两个元素的向量承诺，而我们想要的是无需所有兄弟哈希来进行验证的、可以使树变宽并减少其深度向量承诺，这也就是我们如何获得高效的证明大小的方法，即减少需要提供的信息量。

　　

Verkle trie 类似于 Merkle 树，但是它使用高效向量承诺（因此得名 "Verkle"）而不是简单的哈希来承诺其子代。因此，基本上每个节点可以拥有许多子节点，但无需所有子节点都验证证明。无论宽度如何，这都是一个恒定大小的证明。

　　

实际上，前文提到的 KZG 承诺也可以作为向量承诺使用，且以太坊开发者最初本就计划在这里使用 KZG 承诺，只是他们后来转向了用以履行类似角色的 Pedersen 承诺。这些承诺将基于一个椭圆曲线（在本例中是 Bandersnatch），并将承诺 256 个值（比只承诺两个元素好太多了！）。

　　

那么，为什么不建立一个深且尽可能宽的树呢？这对现在拥有紧凑证明的验证者来说是件好事。但是这里有一个需要实际考虑的权衡，即证明者需要能够计算该证明，但树越宽计算就越难。因此，这些 Verkle tries 将位于两个极端之间，宽度为 256 个值。

　　

状态逾期

　　

弱无状态性消除了验证者的状态膨胀约束，但状态并不会神奇地消失。交易的成本是有限的，但它们通过增加状态给网络带来了永久的税收。状态增长仍然是对网络的一种永久性拖累，需要采取一些措施来解决根本问题。

　　

长期（比如一年或两年）不活跃的状态甚至会从区块创建者需要携带的东西中被砍掉，而活跃的用户不会注意到这些事情，也就不需要无用的状态，它们可以被删除。

　　

如果你需要恢复逾期的状态，你只需要出示一个证明以激活它，这又回到了 N 选 1 存储假设，即只要有人仍然拥有完整的历史（区块探索者，等等），你就可以从他们那里得到你需要的东西。

　　

弱无状态将削弱基础层对状态逾期的迫切需求，从长远来看，特别是随着 L1 吞吐量的增加，这是好事情。对于高吞吐量的 rollups，这将是一个更有用的工具，因为 L2 状态将以更高指数级速率增长甚至成为高性能创建者的拖累。

　　

第三部分：MEV

　　

PBS 对于安全实现 Danksharding 来说非常必要，但它最初的设计其实是为了对抗 MEV 的中心化力量，毕竟如今在以太坊研究中反复出现的一个趋势即 MEV 是目前加密货币经济学的前沿和中心。

　　

　　

在设计区块链时考虑到 MEV，对于维护安全和去中心化都至关重要。协议层的基本方法是：

　　

尽可能减轻有害的 MEV（例如，单槽最终确定性，单一的秘密领导人选举）将剩余部分民主化（例如，MEV-Boost、PBS、MEV smoothing）。其中，剩余部分必须能很容易地被捕获并在验证者中传播，否则，由于无法与复杂的搜索者竞争而使验证者集中心化。另外，合并后， MEV 将进一步占领验证者奖励中更高的份额（质押发行量远低于矿工获得的通胀），所以验证者中心化地问题不容忽视的。

　　

当前的 MEV 供应链

　　

当前的事件顺序看起来是这样的：

　　

　　

矿池在这里扮演了区块打包者的角色。MEV 检索器通过 Flashbots 将捆绑的交易（连同他们各自的出价）转交到矿池。矿池运营商聚合一个完整的区块，并沿着区块头传递给各个矿工。矿工通过 PoW 在分叉选择规则中赋予其权重来证明这一点。

　　

Flashbots 的出现是为了防止将为审查和其它不利外部因素打开大门的跨堆栈垂直整合 。当 Flashbots 开始时，矿池已经开始与交易公司达成独家交易来提取 MEV。相反，Flashbots 为他们提供了一种聚合 MEV 竞价和避免垂直整合（通过 MEV-geth 实现 ）的简单方法。

　　

合并之后矿池就会消失。家用验证者通常不似拥有一堆量化分析师的对冲基金那样擅长捕捉 MEV，如果不加以约束，在普通人无法与之竞争的情况下，这将中心化验证者集的力量。但如果结构合理，该协议可以将 MEV 收入重新定向给日常验证者的质押收益。所以我们希望有途径可以让家用验证者合理地运营，这需要找能够承担特定的构建角色的人。

　　

　　

MEV-Boost

　　

不幸的是，协议内的 PBS 在合并时根本无法做好准备。Flashbots 再次提供了一个过度解决方案 ：MEV-Boost 。

　　

合并后的验证者将默认为直接接收公共存储池中的交易到它们的执行客户端。他们可以将这些交易打包提交给共识客户端然后广播到网络。(文章第四部分将介绍以太坊的共识和执行客户端是如何一起工作的）。

　　

但是父母辈和常见的验证者并不知道如何提取我们讨论的 MEV，Flashbots 为此提供了替代方案，即 MEV-boost 将嵌入你的共识客户端，允许你外包特定的区块构建。重要的是，此时你仍可以选择使用自己的执行客户端作为后备。

　　

MEV 检索器将继续发挥它们今天已有的作用，运行特定的策略（统计套利、原子套利、三明治套利等），并竞标他们需要纳入的捆绑。然后，区块打包者将他们看到的所有捆绑以及任何私人订单流（例如，来自 Flashbots Protect）汇总到最佳完整区块中，他们通过运行在 MEV-Boost 上的中继器者把区块头传递给验证者。Flashbots 将运行中继者和区块打包者，并计划随着时间的推移逐渐去中心化，但为其它区块打包者开放白名单可能会慢很多。

　　

　　

MEV-Boost 要求验证者信任中继者 ―― 共识客户端收到区块头并对其签名，然后才显示区块体。中继者的目的是向出块者证明体区块体是存在且有效的，如此验证者就不必直接信任区块打包者。

　　

当协议内 PBS 准备就绪，它就会编码 MEV-Boost 在这期间提供的内容。PBS 提供了同样的权力分离，它使得的区块打包者更容易去中心化，以及出块者无需要信任任何人。

　　

　　

委员会驱动的 MEV 均匀分配

　　

PBS 为另一个很酷的想法提供了支持 ―― 委员会驱动的 MEV 均匀分配。

　　

我们看到提取 MEV 的能力是中心化验证者集的一种力量，但对分发也是如此。从一个区块到另一个区块的 MEV 奖励的高可变性，激励着许多验证者来均匀分配你的回报（正如我们今天在矿池中看到的，尽管在这里程度较低）。

　　

默认的做法是区块打包者将全额付款给实际的区块出块者，MEV smoothing 将把这笔付款分配给许多验证者。一个验证委员会将检查被提议的区块，并认证该区块是否为出价最高的区块。如果一切顺利，将继续生成区块，且奖励将分配给委员会和出块者。

　　

这也解决了带外行贿问题，即出块者可能会被激励提交一个次优区块，然后直接接受带外贿赂，以向隐藏它们收到的带外贿款。而这种认证（验证委员会认证区块是否为出价最高区块的行为）可以使出块者受到约束。

　　

协议内 PBS 是实现 MEV 均匀分配的先决条件。你需要对区块打包者市场和提交的标书有所了解。虽然这里有几个开放待解决的研究问题，但这依然是一个令人兴奋的提议，因为它对确保验证者去中心化来说至关重要。

　　

单槽最终确定性

　　

快速的最终确定性是非常棒的，等待 ~15 分钟对于用户体验或跨链通信来说都是次优选择。更重要的是，快速最终确定性是一个 MEV 重组问题。

　　

合并后的以太坊将会提供比今天更强大的确认 ―― 成千上万的验证者认证每个区块，以及矿工可在同一区块高度竞争和挖矿但无需投票。如此使得链重组几乎不可能实现，但仍然不是真正的最终确定性。如果最后一个区块有一些有报酬丰厚的 MEV，你可能会引诱验证者尝试链重组，并将其窃为己有。

　　

单槽最终确定性消除了这种威胁，逆转一个已完成最终确定性的区块需要至少三分之一的验证者，且他们的质押会立即被削减（数百万的 ETH）。

　　

在这里我们不过多地讨论潜在的机制。只需要知道，在以太坊的路线图中，单槽最终确定性在很久以后才会被考虑进来，以及它是一个非常开放的设计空间。

　　

在今天的共识协议中（没有单槽最终确定性），以太坊只需要 1/32 的验证者来认证每个槽（即目前超过 38 万的验证者中，约有 12000 个 验证者来认证每个槽）。在单槽中用 BLS 签名聚合将这种投票扩展到全部的验证者集需要做更多的工作 ―― 把数十万次投票压缩到一个验证中：

　　

　　

Vitalik 在文后链接 <5> 中详解了一些有趣的解决方案。

　　

单一秘密领袖选举

　　

单一秘密领袖选举（SSLE: Single Secret Leader Election）试图修补我们在合并后将面临的另一个 MEV 攻击矢量。

　　

信标链验证者名单和即将发布的领导者选举名单都是公开的，很容易对他们进行去匿名化处理以及映射他们的 IP 地址。

　　

更成熟的验证者可以使用一些技巧来更好地隐藏自己，但是小型验证者特别容易受到信息泄露和 DDOS 的影响，这很容易被 MEV 所利用。

　　

假设你是第 n 个区块的出块者，我是第 n+1 个区块的出块者，如果我知道你的 IP 地址，我可以很便宜地向你发动能致使你超时从而无法生产区块的 DDOS 攻击，如此我便可以获得我们俩的槽的 MEV ，使我的回报加倍。EIP-1559 的弹性块大小加剧了这个问题，由于 EIP-1559 每个块的最大 gas 是目标规格的两倍，所以我可以把本应该是两个块的交易塞到属于我的、是原来两倍大的单个块中。

　　

简而言之，家用验证者可能会放弃的验证，因为家用验证者容易受到攻击，可能会验证失败。SSLE 使得除了出块者之外没有人知道什么时候该轮到他们来阻止这种攻击。这在合并时还无法实现，但希望在合并后不久可以实现。

　　

第四部分 - 合并：工作原理

　　

我认为并希望合并即将到来。

　　

　　

合并是无法忽视的，没有人会对其置若罔闻，我觉得我也有可以做一些简单的发声：

　　

合并后的客户端

　　

如今，你运行的是一个处理所有交易的单片单体客户端（如 Go Ethereum、Nethermind 等）。具体来说，全节点做这两件事：

　　

执行：执行区块中的每个交易，以确保有效性。采取前状态根，执行一切，并检查产生的后状态根是否正确。共识：验证你处在完成了最多工作的、最重的（最高 PoW）链上，即中本聪共识。它们是不可分割的，因为全节点不仅遵循最重的链，而且遵循最重的有效链。这就是为什么他们是全节点而不是轻节点。即使在 51% 的攻击下，全节点也不会接受无效的交易。

　　

　　

信标链目前不运行执行，只运行共识以提供给 PoS 一个测试运行环境。最终，决定一个终端总难度的时刻将是以太坊执行区块合并到信标链区块中形成一条链的时刻：

　　

　　

然而，全节点本质上将运行两个独立的可以互操作的客户端：

　　

执行客户端（又名 "Eth 1.0 客户端"）：当前的 Eth 1.0 客户端继续处理执行。他们处理区块，维护内存池，管理和同步状态，撕掉 PoW 的基本特质。共识客户端（又名 "Eth 2.0 客户端"）：当前的信标链客户端继续处理 PoS 共识。他们跟踪链头，广播和认证区块，并接收验证者的奖励。客户端收到信标链区块，执行客户端运行交易，如果一切顺利共识客户端将遵循该链。所有的客户端都是可互操作的，你将能够混合或匹配你所选择的执行客户端和共识客户端。一个新的用于客户端之间通信的引擎 API 将被引入：

　　

　　

或者：

　　

　　

合并后的共识

　　

如今的中本共聪共识很简单：矿工创建新的区块，并将其添加到观察到的最重的有效链上。

　　

合并后的以太坊转向 GASPER ―― 结合 Casper FFG（最终确定性工具）和 LMD GHOST（分岔选择规则）来达成共识。这里简而言之是一个侧重于活性但不侧重于安全性的共识。

　　

区别在于，支持安全的共识算法（如 Tendermint）在无法获得必要的票数（验证者集的）时就会停止。支持活性的链（如 PoW + 中本聪共识）无论如何都会继续建立一个乐观的账本，但如果没有足够的票数，它们就无法获得最终确定性。今天的比特币和以太坊只是假设在足够多的区块之后不会发生重构，永远不会获得最终确定性。

　　

然而，以太坊也会在票数足够的情况下通过检查点来阶段性的实现最终确定性。每 32 个 ETH 实例就是一个独立的验证者，目前已经有超过 38 万个信标链验证者。周期由 32 个槽组成，所有验证者被分离开来，以在给定的周期内对一个槽进行认证（也就是说每个槽有 ~12000 个认证）。紧接着，分岔选择规则 LMD Ghost 根据这些证明来确定链现在的头。每个槽（12秒）都会增加一个新的区块，所以周期是 6.4 分钟。通常在两个周期后（即每 64 个槽，尽管有时可能需要 95 个槽），就会获得必要的票数以实现最终确定性。

　　

结论

　　

所有的道路都通向中心化区块生成、去中心化无信任的区块验证和抗审查。以太坊的路线图已经瞄准了这一愿景。

　　

以太坊的目标是成为统一的数据可用和结算层 ―― 在最大限度地去中心化和安全的基础上实现可扩展计算

　　

我希望你对以太坊的研究是如何交织在一起的有了更清晰的认识，它有如此多非常简短的、正在开发的组件，它们各自都有一个非常大情景需要你去理解。

　　

从根本上说，这一切都回到了那个独一无二的愿景。以太坊为我们提供了一条令人信服的通往大规模可扩展的道路，与此同时也珍视我们在这个领域非常关心的那些价值。