以太坊2.0将加速落地，简化分片方案

昨天在日本大阪举行的 Devcon 5 大会上，ConsenSys 创始人透露，以太坊 2.0 的 phase 1-2 将提前上线，可能会在 2020 年底上线，比 2020 年提前了近两年。原计划。

那么发生了什么？ 是因为开发人员太优秀了，团队才能提前完成任务吗？

当然，这不是理由。 真正的原因是：以太坊2.0原有的分片方案实现难度太大。 为了加快实施速度，研发团队对其进行了简化。

为此，以太坊创始人 Vitalik 刚刚发布了“减少分片数量，加快跨分片通信”的提案。

那么这个新提案的具体内容是什么？

原文在这里：@vbuterin/HkiULaluS

懒得读书？ 给你核心点：

不再有持久分片链的概念，取而代之的是每个分片块都是一个直接的交叉链接。 提案人提出提案，交联委员会通过，完成任务；

分片数量从1024个减少到64个，分片块大小从（16目标值，64上限）kB增加到（128目标值，512上限）kB，分片总容量为1.3- 2.7 MB /s，取决于时隙时间。 如果需要，分片的数量和块的大小可以随着时间的推移而增加，比如说 10 年后最终达到 1024 个分片和 1 MB 的块。

在 L1 和 L2 层做了很多简化：（i）需要更少的分片逻辑，（ii）不需要 layer-2 跨分片加速，因为“本地”跨分片通信发生在 1 个时隙时间内，是的， (iii) 不需要DEX来方便支付跨分片txfee（交易费）， (iv) EE（执行环境）可以变得更简单， (v) 不需要混合序列化（serialization）和散列；

主要缺点：(i) 信标链开销会更大，(ii) 分片出块时间会更长，(iii) 更高的“突发”带宽要求，但“平均”带宽要求会更低。

（注：以下为具体方案说明）

序言/根本原因

当前的以太坊 2.0 架构过于复杂，尤其是在费用市场层面，这是由为 eth2 基础层的主要故障创建的 layer-2 解决方案造成的：虽然分片内的出块时间很短（3-6s），但是分片之间的底层通信时间非常长，需要1-16个epoch周期，如果超过1/3的验证者离线，这个时间会更长。 这使得“乐观”解决方案成为必要的先决条件：分片内的子系统“假装”提前知道其他分片的状态根，通过一些适度安全的机制（例如轻客户端）了解它们，并处理交易使用这些（可能但不确定的）状态根来计算它自己的状态。 一段时间后，“守卫”进程遍历所有分片，检查哪些计算使用了关于其他分片状态的“正确”信息，并丢弃所有未使用此“正确”信息的计算。

而这个过程是有问题的，因为虽然它在许多情况下有效地模拟了超高速通信时间，但复杂性源于“乐观”的 ETH 和“真实”的 ETH 之间的差距。 具体来说，我们不能合理地期望区块提议者“知道”乐观的 ETH，因此如果分片 A 上的用户将 ETH 发送给分片 B 上的用户，则分片 B 上的用户拥有协议层 ETH（这是唯一可以用于发送交易费用），会有时间延迟。 解决这个问题需要去中心化交易所（它们有其自身的复杂性和低效率）或中继市场（这引起了对垄断中继审查用户的担忧）。

此外，当前的交联机制增加了很多复杂性。 实际上，它需要一整套区块链逻辑，包括奖惩计算、分叉选择规则等，这些都需要包含在分片链中，作为Phase Part of 1（Phase 1）。

本文档提出了一个彻底的替代方案，可以消除所有这些问题，使以太坊 2.0 的使用速度更快，而且风险更低（文档中也记录了一些权衡）。

节目详情

我们将 SHARD_COUNT（分片计数）从 1024 减少到 64，并将每个槽的最大分片数量从 16 增加到 64。这意味着“最佳”工作流现在位于每个信标链块之间，而以前每个分片都会发出交联（为了清楚起见，让我们去掉“交联”这个词，因为我们不“链接”到分片链，而是直接使用术语“分片块”）。

注意一个关键细节：现在有一条路径，任何分片的插槽 N+1 中的任何块都知道所有分片的插槽 N 中的所有块。 因此，我们现在拥有一类单时隙跨分片通信（通过 Merkle 收据）。

现状（大概地图）

新提案

我们更改了证明链接的结构：它不再包含“交叉链接”（包括以某种复杂的序列化形式表示许多分片块的“数据根”），而仅包含单个块内容的数据根，其内容为完全取决于“提议者”。 分片块还将包括提议者的签名。 提议者的计算方式和之前一样，基于persistent-committee（常务委员会）算法，这是为了鼓励p2p网络的稳定。 如果没有可用的提案，CrossLink 委员会成员可以投票支持一个空的“零提案”。

在这个状态下，我们和之前一样存储一个maplatest_shard_blocks：shard -> (block, slot)，不同的是存储的周期变成了epoch，而不是之前的slot。 在“乐观的情况下”，我们希望为每个插槽更新此地图。

将 online_validators 定义为活跃验证者的子集（那些在过去 8 个时期中有 1 个时期至少包含一个证明的人）。 如果 2/3 的 online_validators（按总余额计算）同意给定分片的相同新块，则地图将更新。

如果当前slot为n，但对于给定的shard i，latest_shard_blocks[i].slot < n-1（即在上一个slot循环中shard中出现了skipped block），我们需要shard提供数据[latest_shard_blocks[i].slot + 1....min(latest_shard_blocks[i].slot + 8, n-1)] 范围内所有槽的根。 分片块仍然需要指向“以前的分片块”，我们仍然要强制一致性，所以协议要求这样的多时隙证明是一致的。 我们希望委员会使用以下“分叉选择规则”：

对于每个有效+可用的分片块 B（该块的祖先块也必须是有效+可用的），计算其最新消息支持 B 或 B 的后代的验证者的总权重，我们称之为 B 的“分数”，空分片块也可以有分数。

为latest_shard_blocks[i].slot + 1选择得分最高的分片区块；

为latest_shard_blocks[i].slot + k (k > 1)选择得分最高的分片区块；

概述

发布信标块 N 和信标块 N+1 之间的过程如下：

信标块 N 被释放；

对于任何给定的分片 i，分片 i 的提议者提议一个分片块。 执行这个块可以看到信标块 N 和旧块的根（如果需要以太坊有哪些落地应用，我们可以降低块 N-1 和旧块的可见性，这允许并行提出信标块和分片块）；

映射到分片 i 的证明者进行证明，其中包括对分片 i 上的槽 N 信标块和槽 N 分片块的意见（在特殊情况下，也包括分片 i 上的旧分片块）；

信标区块 N+1 发布，其中包括所有分片的证明，区块 N+1 的状态转换函数将处理这些证明并更新所有分片的“最新状态”；

成本分析

请注意，不需要参与者主动下载分片块数据，而是提议者在发布提案时只需在不到 3 秒的时间内上传最多 512 kB 的数据（假设有 400 万验证者，每个提议者每 128,000 上传一次slot cycles average），然后委员会只需要在不到 3 秒的时间内下载最大 512 kB 的数据来验证提案（每个验证者将被要求在每个 epoch 周期执行一次此操作）。

请注意，这低于当前每个验证器的平均负载（即每个时期约 2MB）。 但是，“突发”负载会更高：之前 3 秒高达 64KB，现在 3 秒高达 512KB。

从证明（来自 400 万验证器）加载的信标链数据变化如下：每个证明大约 300 字节的固定数据，加上一个位域，即每个时期 400 万位，或每个槽 8192 字节。 因此，当前方案的最大负载为 128 * 300 + 8192 = 46592，尽管平均负载可能更接近 32 * 300 + 8192 = 17792，甚至可以通过压缩减少（证明包含冗余信息）。

然而，在这个提案中，我们将看到两种负载：

最大负载为128*300+128*200+8192=72192，平均负载可能为80*300+10*200+8192=34192。

另请注意，证明聚合的开销为每个分片每个插槽 65536 * 300 / 64 = 307200 字节。 这为系统运行节点提供了一个基础要求，因此使块数据比这小得多没有什么价值。

从计算上来说，唯一显着增加的开销是更多的配对（pairing，更具体地说，更多的米勒循环），具体的数据从每块最多 128 个增加到最多 192 个，而这会增加块处理时间大约 200 毫秒。

分片“基本操作系统”

每个分片都有一个映射 ExecEnvID -> (state_hash, balance) 的状态。 分片块分为一组块，其中每个块指定一个执行环境（EE）。 一个chunk的执行以state root和chunk的内容（即shard块数据的一部分）作为输入，输出一个[shard, EE_id, value, msg_hash]元组列表，每个shard只能有一个 EE_id（我们添加了两个“虚拟”分片：转移到分片 -1 代表验证者向信标链的存款，转移到分片 -2 以支付提案）。 我们还从 EE 余额中减去价值总和。

在分片块头中，我们放置了一个“收据根”，其中包含一个映射分片 -> [[EE_id, value, msg_hash]...]（每个分片最多 8 个元素）。

分片 i 上的分片块需要包含分片 j 相互收据的 Merkle 分支，它位于其他分片（任何分片 i 知道任何分片 j 的收据根）的“收据根”（receipt root）中。 接受的值分配给它的EE（Execution Environment），EE执行可以访问msg_hash。

这允许在分片之间的 EE 之间即时传输 ETH，每个块的开销为 (32 * log(64) + 48) * 64 = 15360 字节。 msg_hash 可用于减少跨分片传递信息所需的见证大小，因此在高度活跃的系统中，15360 字节通常是必不可少的。

主要好处：更简单的费用市场

我们可以通过以下方式修改执行环境（EE）：每个分片都有一个状态，其中包含状态根和执行环境（EE）的余额。 执行环境将能够将收据和硬币直接发送到其他分片上的相同执行环境。 这将使用 Merkle 分支机制来完成，其中每个分片 EE 状态都为其他分片存储一个随机数作为重放保护。 EE 也可以直接向区块提议者支付费用。

这样，除了提供足够的功能（允许用户将硬币存入分片，使用这些硬币发送交易费用，以及轻松地在分片内移动这些硬币）之外，它还消除了中继市场的需要。 迫切需要，它还消除了执行环境 (EE) 的负担，以乐观地跨分片执行状态。

优化证明

为了提高效率，我们还做了如下优化： 如前所述，查找槽 n 的证明可以完全包含在槽 n+1 中。 但是，如果这样的证明包含在后面的槽中，则必须包含在仅包含信标块（head、target、source）且不包含任何交联（crosslink）数据的“简化形式”中。

这种方法不仅减少了数据，而且重要的是，它通过强制“旧证明”保存相同的数据来减少验证证明所需的配对数量：在大多数情况下，来自同一插槽的所有证明旧证明都可以通过一个单一配对。 如果链条没有分叉，那么在最坏的情况下，验证旧证明所需的对数将限制为纪元长度的两倍。 如果链确实分叉以太坊有哪些落地应用，包含所有证明的能力将取决于更高百分比的提议者（例如 1/32 而不是 1/64）是诚实的并且还包含早期证明的条件。

继续支持轻客户端

每天，我们随机选择一个由 256 名验证者组成的委员会，他们可以签署每个区块，其签名可以包含在区块 n+1 中以获得奖励。 这样做是为了让低权限的轻客户端也可以工作。

其他可能的扩展

slot n 的分片块必须查询 slot n-1（不是 slot n）的信标链块。 这将允许每个时隙并行发生而不是串联发生，以减少时隙时间为代价将跨分片通信时间从 1 个时隙时间增加到 2 个时隙时间；

如果区块提议者想让区块大于64KB（注意：目标是128KB），他们首先生成64KB的数据，然后让交联委员会对其进行签名，然后他们可以添加另一部分引用A签名的64KB，等等。 这将鼓励区块生产者每隔几秒发布其区块的部分最终版本，从而创建预确认；

加快秘密领导人选举的发展（为简单起见，即使是匿名集为 8-16 的基于环签名的版本也会有所帮助）；

对于这种新的分片方案，一些社区成员也提出了自己的质疑。 例如，雷蒙德杜克写道：

“如果现在这样做，未来分片（以太坊2.0）的数量将扩大到1024个，它的实施会不会很复杂？”

对此，Vitalik 的回复是“不复杂”。

你有什么意见？