免责声明：本文不构成任何投资建议。

小编：记得

文章来源：区块链大本营

翻译：王国玺；

一文读懂以太坊 2.0。

今天，V 神在 Twitter 上表示，君士坦丁堡升级的再度延迟完全不会影响以太坊 2.0 的 Casper/分片/宁静 的研发团队和研发进度：

V 神是在转推以太坊核心开发人员 Afri Schoedon 发表在以太坊 Reddit 论坛上的一段声明时强调这些话。后者在 Reddit 上的声明中表示，以太坊 2.0 的 宁静/PoS/分片 与以太坊 1.0 完全无关，负责君士坦丁堡升级的团队与开发以太坊 2.0 的团队是完全独立的。

而说到以太坊 2.0，V 神前两天刚刚推荐了一篇解读以太坊 2.0 路线图最好的文章：

这篇文章详细解释了以太坊 2.0 各个阶段的技术发展状况，并对 Beacon 链、EVM2、分片、分片后的智能合约及 DApp 开发等技术如何组装出新一代的以太坊做出了详细的介绍。

那么，相比以太坊 1.0，以太坊 2.0 到底有什么不同？请看区块链大本营对这篇长文的完整翻译：

什么是以太坊 2.0？

以太坊 2.0 是以太坊已充分规划好的替代品，按照日程，在接下来的几年里，以太坊 2.0 的设计人员会将当下以太坊的共识系统以及区块链状态悉数打包，加入到以太坊 2.0 中。

如此一项庞大的工程以至于我们无法准确地预测以太坊 2.0 将会包含哪些内容又会舍弃哪些内容。根据当前掌握的信息，已经有一些团队开始了早期开发，根据当前的计划，以太坊 2.0 的设计人员在其中加入当下的一些先进技术，如分片技术、Casper 协议、状态租金（state rent，即向用户收取存储数据费用的机制）和以太坊新一代虚拟机项目 eWASM。客户端的开发也早已提上日程，早期的开发测试工作正在有条不紊地进行中，一个功能强大的以太坊 2.0 测试网络预计将会在三个月内（2019 年第一季度）与我们见面。

届时，以太坊 2.0 中的以太币将全部来源于当下以太坊主链，但设计人员计划通过不断地更新迭代来改变两条区块链之间的关系，以太坊 2.0 将逐步成为主链，而当下的以太坊 1.X 区块链将会成为受其管理的分片链。

以太坊2.0对开发人员意味着什么？

如果你是希望在以太坊 2.0 中抢占先机的 Solidity 智能合约开发人员或 Dapp 开发人员，你将不得不面对很多的改动。以太坊 2.0 是以太坊的完整替代品，在其中我们当下编写智能合约时所做的许多假设都不再成立。通过以太坊 2.0 的时间轴你会发现，团队计划在未来几年分阶段完成，从这一点看以太坊 2.0 更像是一次新品发布，而不是修修补补的产品升级，那就不难想象当下我们为以太坊 1.X 版本编写的工具和智能合约可能都需要完全推倒重来，为以太坊 2.0 重新设计并重新编写代码。不过不要害怕，幸运的是，我们有几年的时间来为这个新的生态系统做充分的准备。为了帮助大家推动这项工作，我们会帮大家分析当前以太坊 2.0 项目的路线图并介绍一些工程上的波及面。

分阶段推出

目前，分片技术路线图（两倍于以太坊 2.0 的路线图）共规划出了七个阶段。只有第零阶段列出了详细具体的规划，即进行定期更新。第一阶段的规划就没有那么详细了，看起来还没有进入到开发阶段。在第一阶段之后，路线图逐渐成为了预期目标的列表，而不再是一份技术文档。例如，在第二阶段中，路线图链接到以太坊研究网站 https://ethresear.ch/ 的次数是 github 的三倍。因为每个更前一步的进展看起来都更像是愿景而不是工程实现，在本文中我们的介绍会集中在路线图的第零阶段、第一阶段和第二阶段，不过针对后面的几个阶段我们也会简单分析一下可能的发展方向。

△分阶段推出

第零阶段：Beacon 链

第零阶段的核心任务是“Beacon 链”。以太坊 2.0 的设计人员希望 Beacon 链成为以太坊 2.0 生态系统的核心，成为所有其他分片链安全性和最终确认的根源。一旦部署，Beacon 链将使用实用的终极小工具 Casper（Casper the Friendly Finality Gadget，Casper FFG）这种权益证明机制。Beacon 链的早期迭代版本被设计的尽可能简单，这就是第零阶段不支持智能合约、账户、资产转移以及不包括任何分片链的原因。Beacon 链上的以太币不可在区块链上转移，这意味着用户无法将其存入加密货币交易所。

BETH：新的以太币

Beacon 以太币（BETH）是一种仅供 Beacon 链上权益所有人（验证者）持有的新的加密资产。它可以通过以下两种方法生成：

1）作为为 Beacon 链提供验证服务的奖励（以及第一阶段完成后在分片链上提供验证服务）

2）任何以太坊 1.X 版本的用户都可以通过以太坊 1.X 版本的智能合约

用 1 个以太币购买 1 个 BETH，这是一种被称为“存款”的智能合约，仔细研究你可能会注意到这个智能合约没有撤回交易功能。这是因为在第零阶段中还无法从 Beacon 链中撤回 BETH，也就是说，一旦在以太坊 1.X 版本的验证者注册智能合约中进行存款操作，以太坊 1.X 版本中的以太币就会被有效销毁。

Beacon 链中的验证者看到这个智能合约执行后会向 Beacon 链提交存款信息，Beacon 链将向存款人发放新的 BETH。因此，你可以认为在将以太币发送给验证者注册智能合约后不久就会在 Beacon 链上收到新的 BETH，同时你还可以对存款进行临时审查，但根据 Casper 协议的规定，你不可能永久性地进行审查。

等到第二阶段Beacon 链上才会允许以太币转账，我认为除非以太坊 1.X 版本已经被完整整合到以太坊 2.0 的分片链生态系统中，否则没有任何方法可以将 BETH 转回到以太坊 1.X 版本中。当下路线图的第零阶段还不完善，第一阶段的规范也还不可靠，鉴于此我们似乎可以合理地认为在未来两年内 BETH 将作为一种独立且不可转移的加密资产存在，不过只要第二阶段顺利完成，BETH 将可以在分片链和 Beacon 链之间自由地转账，但以太币将不会。

现阶段交易的不便应该不会给加密经济生态带来什么不可解决的难题，因为在过去，像 BETH 这样的预发布或者功能不全的通证已经有通过 IOU（类似于债券，区块链上的个人或机构，小范围的发行基于该区块链的通证，它不同于 ICO 这样的众筹，只是代表对现实或者其他的通证一种链上映射权益）在交易所进行交易的先例。

例如，在 Tezos 众筹（crowdsale）期间就在 HitBit 和 BitMEX 两家加密货币交易所推出了 XTZ 通证期货。如果加密货币市场上有对BETH的需求，加密货币交易所会纷纷开始提供 BETH 交易和抵押的托管服务。然而，加密货币市场对 BETH 的需求谁也说不准，BETH 并不适合投资，因为从以太币到 BETH 的单向挂钩人为规定了其 1 以太币的价格上限。也就是说，BETH 永远不会比以太币更值钱，只会价格更低。

第 0+ 阶段：抵押

用户可以在 Beacon 链上抵押 32 个 BETH 成为验证者。在第零阶段中，验证者仅仅管理 Beacon 链，但从第一阶段开始，验证者还将管理 1024 个分片链。Beacon 链（以及每个分片链）将使用实用的终极小工具 Casper（Casper FFG）权益证明机制来生成区块，这种机制将在区块链停止或经审查等不良行为出现时削减验证者的权益，聪明的读者应该会注意到 Casper FFG 的表亲 Casper CBC（建构修正 Casper）出现在了分片路线图的“以太坊 3.0”部分中，虽然对实用的终极小工具 Casper、建构修正 Casper两种协议的全面讨论超出了本文的范围，不过我强烈建议你阅读 Vitalik 关于混合 PoW / FFG 的说明，以及他关于最小削减条件的帖子和FFG的论文。

https://vitalik.ca/files/casper_note.htmlhttps://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6chttps://arxiv.org/abs/1710.09437

这些验证者需要做什么？

分片技术旨在跨节点分割（分片）区块链状态信息，从而不需要任何节点保存区块链网络的完整信息。因此，没有哪个验证者可以验证所有的分片。相反，Beacon 链将协调所有其他分片链的验证者执行验证，并且所有验证者都将验证 Beacon 链。每个规定的时间段（64 个区块时间，大约 6.4 分钟），Beacon 链将对验证者进行洗牌并将他们分配给分片链。分配给分片链的一组验证者称为该分片链的验证者委员会。按照规定验证者委员会需要 128 名成员。在第零阶段中，这意味着每个 6 分钟的时间段内 Beacon 链都需要选择验证者以组成接下来 6 分钟的验证者委员会。在第一阶段中，Beacon 链将需要为所有 1024 个分片各自分配一个验证者委员会。实际执行的分配算法十分复杂，它涉及多阶段随机数生成过程以及可验证的延迟函数，以杜绝某些利益方操纵生成验证者委员会的可能。

由于工作的重要性，以太坊 2.0 随机选择验证者委员会并经常轮换验证者委员会。验证者委员会负责保护其分片链的安全性，存活和完整性，以及向 Beacon 链上报分片的状态，分片链验证者委员会是 Beacon 链了解分片链状态的唯一途径，反之亦然。从所有验证者库中随机选择验证者可以最大限度地减少验证者委员会穿一条裤子作为一个整体撒谎或欺骗的可能性，经常轮换他们也是旨在减轻恶意的验证者委员会可能造成的伤害。换句话说，有了这样的机制恶意或旨在利润最大化的验证者很难拿验证者委员会来攻击区块链网络任何部分。此外，如果他们偶然地获得了对验证者委员会的控制权，他们控制的时间也不会超过 64 个区块。

开发人员眼中的权益证明

比较以太坊 1.X 版本的工作量证明与以太坊 2.0 的权益证明之间的差异正在有条不紊地推进中，值得注意的是，一些工作量证明和权益证明之间的差异的的确确直接影响到了开发人员，就比如说，虽然工作量证明区块链支持无状态 SPV（Simplified Payment Verification，简单支付验证）证明和 NiPoPow（Non-interactive Proofs of Proof of Work，非交互式工作量证明）等等的远程状态跟踪机制，但权益证明禁止任何低状态通信，主观性阻断了轻状态验证的可能。换句话说，关于权益证明的远程状态证明将包括与工作量证明无状态 SPV 证明大致相同数量的数据，但是需要事先验证整个权益证明的历史。相比之下，无状态 SPV 证明不需要其他信息来验证。这意味着跨分片或跨链应用程序在这种主观的权益证明环境中功能大大减少但开销大大增加。

第一阶段：分片

第一阶段旨在就分片链的内容达成共识，但不是关于它们的含义。换句话说，它是区块链分片架构的一次试验，而不是尝试使用分片技术来扩容。Beacon 链将分片链上的区块视为没有结构或含义的简单数据集合，因为分片链尚未拥有帐户，资产以及智能合约，此时，在每个周期内由 Beacon 链为每个分片链随机选择的分片链验证者委员会仅仅就每个分片的内容达成一致，也就是说只要所有验证者委员会达成共识并定期更新分片链区块数据即可，哪些信息出现在分片链区块中并不重要。

分片链验证者委员会通过一项被称为交联（crosslinking）的操作证明分片链的内容和状态。简而言之，验证者委员会必须在 Beacon 链中提交有关分片的可验证信息（如默克尔树根节点的哈希值）。在第二阶段或以后，交联操作将支持跨分片的通信。

一旦 Beacon 链从多个验证者委员会处收到给定交联准确性的证据，Beacon 链就可以相信交联是分片链的真实表示从而不再验证整个分片链。如果验证者委员会对交联的有效性持不同意见，显然至少有一个验证者委员会是错误的，应该收到权益削减的惩罚。这是所有分片链安全性的根源：验证者的不当行为最终会被 Beacon 链发现并受到惩罚。

在第一阶段中没有什么特别有趣的内容。从根本上说，它是交联以及分片链与 Beacon 链数据同步机制的开发测试。设计人员似乎对这些机制充满信心。目前主要问题来自于规范和实施的策略。鉴于第零阶段花费大约一年多的时间才能达到合理规范的水平，我认为第一阶段至少需要花费相同的时间。有趣的是，第零阶段实现与规范是同时推进的。

即使在今天，距离测试网发布不到三个月，第零阶段的规范也会定期更改。这意味着在未来开发期间，以太坊 2.0 可能会有很大的变化。虽然乐观主义者告诉我开发大概需要六个月，但我认为不然，在第零阶段开发完成进入测试阶段之后，第一阶段可能还需要 12-18 个月的开发时间。

△分片机制

第二阶段：智能合约

到了第二阶段，以太坊 2.0 就有点类似于我们熟悉的以太坊了。随着第二阶段成果的不断发布，分片链将从简单的数据容器逐渐转变为结构化的区块链状态。这时 BETH 将可以自由地转移，并且系统将重新引入智能合约。每个分片链都将通过基于 eWASM 的以太坊虚拟机（我们称之为“EVM2”）进行管理。我们希望 EVM2 支持我们当下所熟悉的帐户，智能合约，状态以及其他 Solidity 中的抽象概念。然而，底层的大规模改动让这种想法成为我们的一厢情愿，大多数现有的工具都不再适用于以太坊2.0。

不过幸运的是，eWASM 团队为以太坊智能合约命令行编译工具 Solc、开发框架 Truffle 和测试环境 Ganache 做了一些底层的工作，所以在第二阶段的测试网络发布之前最迟发布期间，我们可以看到一些最常用的工具开始支持 EVM2 虚拟机。

在第二阶段中很可能会加入状态租金，这对当下的 Solidity 开发人员提出了一些有趣的挑战。状态租金机制下区块链并不会无限期地存储代码和数据，而是要求智能合约开发人员和用户随着时间的推移为 EVM2 虚拟机的存储付费，这样做是为了确保未使用的信息随着时间的推移而逐渐脱离状态，防止状态规模膨胀，它的目标是让用户而不是完整节点支付状态的费用。业界针对状态租金已经提出了许多不同的模型，但最终花落谁家还未成定局。

https://ethresear.ch/t/improving-the-ux-of-rent-with-a-sleeping-waking-mechanism/1480

有趣的是，随着一些以太坊升级计划和著名的以太坊核心开发者推荐，状态租金可能是不同路线图中唯一的相同点。因此，我强烈建议在当前部署的智能合约中支付状态租金，并设计模型来转移状态租金给未来的用户。虽然我们不知道状态租金机制的精确设计，但我们应该准备好支付状态租金。

除此之外，我觉得第二阶段没有什么值得期待的了，因为它仍处于早期研究的阶段，还有几个核心问题亟待解决。考虑到当下非正式的规范和开发流程，以及第二阶段在第一阶段上的升级范围，2020 年之前启动第二阶段的建议似乎并不合理，也就是说，虽然以太坊 2.0 可能在今年推出，但是预计至少要到 2020 年以太坊 2.0 才能支持资产转移和智能合约。

第三阶段：链下状态存储

为了更多地讨论大家关心的智能合约，我们将几乎完全跳过第三阶段。第三阶段通过尽可能多地将状态存储到链下来最小化区块链上的状态。以太坊2.0的区块链上将只存储一些状态信息和聚合器（aggregator，聚合器是表示长数据列表的短数据字节，默克尔树就是一种聚合器），而不是像以太坊一样存储所有的状态。用户将负责在链下存储完整的状态信息，当用户想要与状态进行交互时，他们需要在交易中包含当前状态的证明。这样可以大大降低运行验证节点的资源需求。

目前已有几种不同特性和性能的聚合器设计方案，但设计人员还没有选择任何方案。因为我们不能使用链上通信来协调各个用户，我们必须通过其他系统同步状态。这种设计下区块链不再保证数据的可用性，这里的事件对开发人员来说并没有太大的意义。在第三阶段中，维护和检索链下状态将成为Dapp的关键设计要素。

第四阶段：分片智能合约

做了这么多工作，目前还有一个无法克服的核心问题：以太坊 2.0 的智能合约，虽说它们将与以太坊智能合约一样强大，但它们必然会绑定在一个分片链上，并且永远无法与另一个分片链上的智能合约直接进行交互。这是分片技术带来的直接后果。分片技术的目标是在分片链之间分割状态，每个分片链都不需要直接了解其他分片，通过分割状态和最小化验证者的负载来实现区块链的可拓展性提升。而不同分片链上智能合约的直接交互需要了解彼此的状态。

根据设计，分片链不存有其他分片链的状态，它们仅通过与 Beacon 链的交联来了解其他分片链。因此，每当我们想要跨分片访问状态时，我们就必须等待 Beacon 链提供服务。具体来说，这意味着如果在分片 A 上部署 SafeMath 库函数，分片 B 上的用户将不得不等待 Beacon 链提供服务来访问 SafeMath 库函数或在分片 B 上部署新的 SafeMath 库函数。

这意味着每个分片链上都需要部署像 SafeMath 库函数这样通用的底层库函数，也就是说 1024 个分片链上会有 1024 个SafeMath库函数，那么像 Maker 或者 Compound 这样的市场该怎么办呢？如何跨越分片的边界已成为去中心化金融的一大考验。在开放抵押债仓（CDP）到收到贷款（DAI）之间的长时间延迟可能会导致难以接受的经济损失。

如果市场大环境发生变化并且抵押债仓在用户收到贷款之前被清算会怎么样？在实践中，这可能意味着用户需要在每个包含必要的智能合约的分片链上开设帐户，并且跨分片的组合将完全丢失。去中心化交易所中创建订单的人（Maker）和用户只有都被部署在同一个分片链上时才能进行交互，并且用户在该分片链上的账户需要有资产。

最根本的权衡：同步性或可拓展性

即使以太坊 2.0 设计人员也不知道跨分片的通信系统会是怎样的。通过阅读许多提案，似乎在即时反馈和可预测性之间存在着根本性的权衡，但分片的本质不会随之改变：无论哪种跨分片通信用户都必须等待。只是我们可以选择交易在本地和在每个分片链上远程执行阶段耦合的紧密程度。

紧密耦合使得等待先行。在分片链之间通信之前，交易不执行任何操作，与此对应的是，我们可以通过现在执行部分，剩下的稍后执行来松散地耦合交易。交易先在本地分片链上执行，跨分片通信之后在远程分片上执行。松散的耦合为用户提供了更好的使用体验，用户将看到自己的交易立即在本地执行，并且知道在未来的某个时刻交易将继续在远程执行，但不幸的是，除非等待否则他们不能了解松散耦合中交易的远程执行阶段。紧密耦合的交易更具可预测性，其中用户更清楚执行的结果，因为交易在本地和远程执行阶段之间远程状态并不会变化。但是，紧密耦合中用户也需要等待才能看到结果。

我们对于以太坊 2.0 通信模型的信息知之甚少。我们只知道它不能在不牺牲几乎所有可扩展性优势的情况下提供跨分片智能合约调用。而设计人员对于第四阶段只给出了思维导图和一些模棱两可的链接。这种情况的一个非显而易见的结果是，以太坊 2.0 在第四阶段之前不会为复杂的智能合约系统提供显著的可拓展性支持。

在此之前，有与其他智能合约交互需求的智能合约必须与其存在于同一个分片链上，并且还会受到分片链速度和规模的限制，因此，我们预计引入分片技术后以太坊 2.0 与以太坊 1.X 版本相比速度也就只能快几倍，而不会有翻天覆地的变化。这意味着在第四阶段发布之前（可能在 21 世纪 20 年代中期），没有必要将智能合约代码以及用户迁移到以太坊 2.0 中，因为迁移带来的优势很小。与此同时，为了更好地理解开发人员和 Dapp 用户之间的权衡，我研究了一些模型，并给出了简短的描述。我认为这些最终可能并不会被采纳，但我相信它们有助于理解所涉及到的权衡。请注意：这里说的一切都是推测性的。

基本模型：收据和证明

所有形式的跨链通信都用到了 Beacon 链。因为 Beacon 链管理所有分片链的状态，并且每个分片链都将状态提交到 Beacon 链，所以我们可以将Beacon 链看作分片链生态系统的核心。从某种意义上来说，从某条分片链到另一条分片链的消息必须通过 Beacon 链传输。我们不希望发送完整的消息，因为如果需要 Beacon 链处理每笔交易，这样分片技术还有什么意义。

相反，每当分片 A 上的用户或智能合约想要与分片 B 交互时，分片 A 生成带有该消息的“收据”。分片A在其区块头中提交其所有的收据。Beacon 链等待 A 最终确认，然后提交到 A 的区块头部（包括对收据的承诺）。分片 B 必须等待 Beacon 链最终确认，然后提交到 Beacon 链的区块头部。这样的流程完成之后，分片 A 就可以直接向分片 B 提交包含收据和证明的新交易。证明显示收据包含在分片A中，分片 A 包含在 beacon 链中，并且 beacon 链包含在分片 B 中。这样，分片 B 中的智能合约可以信任从分片 A 发送过来的消息，如果分片 B 中的智能合约想要回复信息（可能是返回值或是错误），我们需要反过来重复整个过程：分片 B 发出一个收据，最终传到分片 A。

不难看出这个过程很浪费时间。四个通信步骤中的每一个都需要等待几分钟才能最终确认！而且不幸的是，我们无法完全避免等待。如果我们想确定远程的状态，那么我们必须留意执行的每一步以获得最终的结果。在最理想的情况下，两方相互通信需要等待四个最终确认时间，也就是说，用户在三个最终确认时间后就能确信交易成功，因为用户可以在分片 A 正式收到之前看到分片 B 的收据，鉴于以太坊 2.0 的 6.4 分钟时间周期，用户必须等待 19 分钟才能看到交易结果，并且需要 26 分钟才能看到交易结果被加入到区块链中。

△跨链通信

具体的收据：分片链之间的通证转移

ERC-20 通证的强大功能使得它们在今天的以太坊生态系统中无处不在。但是，以太坊 2.0 给通证的运行逻辑带来了一些问题。因为智能合约管理所有的通证余额，并且智能合约仅存在于单个分片链上，所以分片A中的通证并不存在于分片 B 中。不过，通过一些巧妙的跨分片通信机制，我们可以在几个分片链上部署相同的通证从而允许在分片链之间转移通证，即在通证智能合约之间建立有效的双向锚定（two-way peg）。

这个方案非常简单：在部署我们的通证（让我们称之为“酷酷的跨分片通证”或“CCT”）时，我们在 ERC-20 中添加两个小的附加函数：migrateSend（转移发送功能）函数和 migrateReceive（转移接收功能）函数，函数 migrateSend 用来销毁通证并生成收据。收据中将包含已销毁了的通证数以及接收信息的分片链。函数 migrateReceive 验证收据并生成相同数量的通证，我们将在每个分片链上部署相同的通证智能合约，这样我们就可以通过调用 migrateSend 函数在一个分片链上销毁通证，然后在另一个分片链上调用 migrateReceive 函数来重新生成通证。虽说需要在每个分片上重新部署通证智能合约，但这看起来是十分值得的。这种转移是单向的，至少需要两个跨分片通信的最终确认周期。因此，在我们调用 migrateSend 函数之后，大约 10 分钟之后就可以在接收分片上使用这些通证了。

△跨链通证转移

拖拽（Yanking）

收据是跨分片转移信息的一种通用方式。我们可以在收据中加入任何链上信息，甚至可以加入整个智能合约。拖拽是一项通过将智能合约的代码和存储包含在收据中从而跨分片转移智能合约的提案。在拖拽机制中，智能合约将被加入到收据中并被分片 A 删除（拖拽），在收据到达分片 B 之后在分片 B 上重新部署。一旦到达分片 B，它可以直接与分片 B 中的智能合约进行通信，并与分片 B 的状态进行交互，甚至可以被拖拽回分片 A。

https://ethresear.ch/t/cross-shard-contract-yanking/1450

拖拽机制将允许智能合约与任何其他智能合约进行通信（在等待跨分片时间之后）。不幸的是，由于收据包括完整的智能合约及其所有的存储，因此转移大型智能合约的成本会很高。收据在转移过程中，智能合约将无法使用，因为分片A已把它删除，而它还尚未到达分片 B，这意味着在它到达分片 B 之前，所有相关用户都被锁定在该智能合约之中，而且只有已经在分片 B 上拥有账户的用户才能与之交互。因此，拖拽最适合用户很少的小型智能合约。它使紧密耦合的执行成为可能，但并非通用的解决方案。

分片配对（Shard Pairings）

收据旨在使异步（松散耦合）通信成为可能。但在某些场合下，我们还可能需要同步通信。为此，我们必须加入一点创新。分片配对是一个简单的设计，让我们以最少的麻烦进行紧密耦合的状态更新。

分片配对是一个简单的方案，其原理是，我们在每个高度将分片混合成同步对。每次分片与另一个分片配对时，任一分片的用户都可以跨分片执行紧密耦合的状态更新。这意味着如果分片 A 和分片 B 在高度 7 处配对，则分片 A 和分片 B 的所有验证者都会知道分片 A 和分片 B 的所有状态，并且分片必须一起执行或根本不执行。在这个模型中，如果你需要在分片 A 和分片 B 之间执行跨分片交易，你需要等待分片 A 和分片 B 随机配对。Vitalik 分析了 100 个分片的案例，对于 1024 个分片，我们预计它需要经历 512 个区块，大约需要一个小时，但由于分片配对是随机的，时间可能需要更长或更短。正如 Vitalik 所说，当你想要与多个分片交互时，这时可扩展性很差。

△四个分片的分片配对

分片区域（Shard Zones）

分片区域是更广义版本的分片配对。其原理是，每个时间段内我们将分片分成几个由多个分片组成的“区域”。区域必须同步执行，这意味着区域中的所有分片一起更新其本地状态。通过同步执行，区域提供内部分片之间的自由转移，并可与区域中的其他智能合约直接交互，但是这种机制在与区域外的其他分片进行通信时没有任何优势。此外，由于分片区域机制需要验证者了解区域中所有分片的状态，因此分片区域的存在大大降低了分片带来的可拓展性优势。如果一个区域由 16 个分片组成，那么这个区域牺牲了大约 15/16（= 94％）的可拓展性优势，以换取总网络 15 / 1024（= 1％）紧密耦合的执行。

产权负担（Encumbrances）

跨分片（以及跨链）通信的一个不明显的特性就是，用户可以在区块链正式接收之前更快地获得交易的信息。就比如说，爱丽丝从分片 A 向分片 B 发送 5 BETH，知道它会在发送后立即到达分片 B。鲍勃看到了爱丽丝在发送，他知道一旦发送在分片 A 上最终确认，BETH 将到达分片 B。然而，分片 B 及其上的智能合约必须等待几分钟，等 Beacon 链最终确认分片 A 的最终确认。这意味着资金在分片 A 上花费之后，我们可以很快在分片 B 接收并花费这笔资金。

换句话说，鲍勃将从分片 B 上爱丽丝的钱包中获得可执行的 IOU（债券），因为鲍勃相信爱丽丝已经发送了足够多的以太币。如果分片 B 的大部分用户都愿意留意分片 A 上的交易并接受标准化的 IOU，那么分片 A 上的以太币可能在发送后很快在分片 B 上花费。然而，当应用于智能合约时，这种方案变得异常复杂，因为状态是不可替代的，状态的债券是不可能的，因此它不适用于一般的交互。这意味着我们应该将产权负担视为松散耦合中的用户体验改进，它允许用松耦合模拟紧密耦合以快速执行某些交易。

共识和状态分离

一个更复杂也更为烧脑的可能是共识过程将脱离状态更新过程。当下，以太坊矿工和完整节点只有在执行了区块中包含的所有状态更新后才接受该区块，其实没有必要，因为在接受区块之后再更新状态也不迟，只是在这种情况下，矿工不会像当下在以太坊中那样就区块链系统状态达成共识，而是会对所有分片链中所有交易的全部历史（或“全部顺序”）达成共识。

这样做意味着每个分片链都可以在无需知道其他分片链状态的前提下快速添加区块，这就是分片机制带来可拓展性优势的原因。但是，在所有分片最终确认之前，交易对分片链状态和整个区块链网络的影响将不得而知。换句话说，在所有分片内容的最终确认之后才能完成状态的最终确认。

从用户的角度来看：我们提交交易后就知道交易已被包含在区块链中，但我们必须等待一段时间来确定该交易执行的结果。随着分片的最终确定，我们逐渐获得有关区块链状态的更多信息，但在所有分片链都最终确定之前还无法完全肯定。与产权负担相似，在某些情况下，用户可以在区块链之前确定交易的结果并采取相应的行动。

结论 & 开发人员的前进方向

以太坊 2.0 将会是与以太坊完全不同的区块链系统，在未来的几年里，它们将本着不同的特征共同存在，不过在不久的将来，预计将会出现从以太币到 BETH 的单向挂钩。如果你经营加密货币交易所或托管服务，那么你就要思考如何在官方支持链上转移之前为你的用户提供 BETH 托管交易和抵押服务，从长远来看，你还需要考虑智能合约如何在有和没有跨分片通信的情况下适配分片技术。

当然了，最重要的是你需要密切

参考链接：

https://hackernoon.com/what-to-expect-when-eths-expecting-80cb4951afcd

https://www.reddit.com/r/ethereum/comments/agcrcb/what_to_expect_when_eths_expecting_hacker_noon/ee64r3n/

https://www.reddit.com/r/ethereum/comments/ahqmmx/serenity_proofofstake_sharding_all_that_is/

https://medium.com/rocket-pool/ethereum-2-0-whos-building-it-54a735442e

https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605