给工程师的 ETH 2.0 指南

-特别感谢 Nic Carter 用 PowerPoint 绘制了这幅好笑的图片-

什么是以太坊 2.0？

ETH2.0 是以太坊的计划升级方案。在接下来的几年里，ETH2.0 的设计者们计划完全革新以太坊的共识系统，并引入以太坊现有的世界状态。由于涉及面极广，我们也无法准确地说明 ETH2.0 将包括或者不包括哪些内容。ETH 2.0 的研究已经有一定的规模了，有不少团队致力于早期实现。目前，ETH2.0 设计者暂时计划的工作有分片，Casper，状态租金以及 eWASM 虚拟机。初代客户端测试正在进行中，并且预计在三个月内（2019 第一季度）推出功能更精简的 ETH2.0 测试网。首先，ETH2.0 将从以太坊主链获取 ETH（但无需依赖其安全性），但是设计者计划最终能够转变这种关系：将 ETH2.0 作为主链，ETH1.X 作为其管理的一条分片链。

那么这对工程师来说意味着什么呢？

如果你是一名计划部署 ETH2.0 智能合约的 Solidity 或者 Dapp 开发者，那么你会遇上很多变化。ETH2.0 会完全替代 ETH1.0，我们在 ETH1.0 上编写智能合约时所作的假设，到了 ETH2.0 可能就不现实了。我们为 ETH1.X 编写的工具以及合约可能需要为 ETH2.0 完全重构。值得庆幸的是，我们有几年的准备时间来建设生态系统。

ETH2.0 计划分多个阶段推出，与其说是系统升级，更像是产品发布。为了帮助推动这一计划，我想讨论一下当前的研究路线图并介绍一些工程进展。

分阶段推出

目前，分片路线图（ETH2.0 路线图的两倍）已经列出了七个阶段。只有第 0 阶段有详实规范，并且能收到定期更新。第 1 阶段的规范相比之下就没那么清晰了，而且它似乎还没有进入积极的开发阶段。第 1 阶段后的路线图变成了目标列表而不再是技术文档。例如，在第 2 阶段，路线图链接到 ethresear.ch 的次数是其链接到 github 的三倍。因为任何更进一步的内容都更像是推测，而不像是工程，因此我们具体讨论的内容只有第 0 阶段，第 1 阶段以及第 2 阶段，不过我们还将简单讨论一些后期阶段的可能方向。

第 0 阶段-信标链

第 0 阶段引入了“信标链”。ETH2.0 设计者希望信标链未来成为 ETH2.0 生态的中心，成为所有其他分片安全和验证的根源。一旦部署好，信标链将使用 Casper FFG 算法运行权益证明。 信标链的早期迭代被设计得尽可能简单，因此第 0 阶段不支持智能合约，账户，资产转移，同时也没有包含任何分片。信标链上的 ETH 无法在链上转移，这意味着用户无法将其存放在交易所。

BETH：新以太

信标 ETH（BETH）是一种只能由 stakers（“验证者”）在信标链上使用的新资产。其通过两种方式产生：1）作为验证信标链的奖励（在第 1 阶段之后，还有验证分片奖励），2）任何 ETH1.X 用户可以通过 ETH1.X 合约使用 1 ETH 购买 BETH 。该合约将这一行为称为“存款”。工程师一眼就可以看出来：该合约没有提款功能。这是因为第 0 阶段无法从信标链中提取 BETH。也就是说，一旦将 ETH 存入 ETH1.X 验证者注册合约，ETH1.X 以太就被彻底销毁了。信标链验证者一直关注该合约，并提交相应存款信息给信标链，从而为存款方生成新的 BETH 。因此我们预计在 ETH 被发送给验证者注册合约后不久，新的 BETH 就会在信标链上生成。对存款的短期审查是有可能的，但是在 Casper 规则下，永久审查不太可能。

实现第 2 阶段后我们才可以在信标链上作 ETH 转账，而且我不相信在 ETH1.X 完全融入分片生态系统前有方法将 BETH 撤回到 ETH1.X 链上。鉴于第 0 阶段还不完全，而且还没有可靠的第 1 阶段相关规范。看起来可以合理地假设，BETH 将在至少两年内作为独立且不可转移的资产存在。一旦第 2 阶段完成，BETH 将可以从分片中转入转出；而 ETH 就没有这种便利性了。

这种方式不太可能造成重大的经济问题。过去，像 BETH 这样预发行、功能少的代币都是凭借借据在交易所进行交易的。例如。在 Tezos 众筹期间推出的 HitBit 以及 BitMEX XTZ 期货市场。如果对 BETH 有相应需求，我们期待看到一个充满活力且支持 BETH 交易和质押的交易所生态系统。然而，看起来不太可能有这样的需求。因为BETH 是一个不良投资，从 ETH 到 BETH 的单向挂接给了 BETH 一个价格上限。这意味着 BETH 不可能比 ETH 更值钱，而只会比 ETH 更廉价。

第0阶段+ —— Staking

用户可以通过在信标链上质押 32 BETH 成为验证者。在第 0 阶段，验证者将只能管理信标链。从第 1 阶段开始，验证者还将管理 1024 个分片链。信标链（以及各分片链）将使用 Casper FFG 来确定最终区块。FFG 是一种权益证明算法，可以罚没恶意行为（如链中止和分叉）参与者的权益。精明的读者们会注意到“以太坊3.0”分片路线图中的Casper CBC 可以说是 FFG 的堂兄——虽然完整的讨论 FFG （当然还有 CBC！）超出了这个帖子的范围，但是我真心推荐大家阅读一下 Vitalik关于 PoW/FFG 混合共识的说明，他关于最少罚没条件的帖子以及 FFG 论文

Staker 是做什么的？

分片的目的是在节点之间拆分状态信息，而不需要任何节点掌握网络全貌。因此没有验证者可以验证所有分片。相反，信标链将协调分片的验证工作。每个轮次（64 个区块或者 6.4 分钟），信标链将对验证者进行混洗，并将他们分配给一个分片。分配到一个分片的一组验证者被称作委员会。委员会由 128 名成员组成。在第 0 阶段，这意味着每 6 分钟信标链就会重新混洗、选取一次，选出下一个六分钟里承担职责的委员会。在第 1 阶段，信标链将为 1024 个分片分别指定一个验证者委员会。这个方法看起来思路清晰但是实现十分复杂。它涉及多阶段随机数生成以及可验证的延迟函数，以进一步阻止操控委员会选择的企图。

由于委员会的工作十分重要，ETH2.0 随机选择委员会并且时常轮换委员会。委员会负责保证它们所在分片的安全性、活性以及完整性，并负责证明信标链上的分片状态。它们是信标链可以获取分片状态的唯一方式，反之亦然。随机地从验证者池中选择组成委员会的验证者可以最大限度地减少整个委员会撒谎的可能性。时常轮换委员会可以减轻恶意委员会可以造成的伤害。换句话说，对恶意验证者以及试图使自己利益最大化的验证者来说，很难将委员会选择作为攻击网络的工具。此外，如果他们偶然获得了对分片委员会的控制，他们的控制无法超过 64 个区块。

给工程师的权益证明说明

尽管总结 ETH1.X 的工作量证明以及 ETH2.0 权益证明之间的差别仍在持续进行中，但需要提醒的是，一些 PoW/PoS 特性的差异确实直接影响到了工程师。例如，PoW 链支持无状态 SPV 验证以及工作量证明的非交互证明——总的来说就是远程状态跟踪，而 PoS 则禁止任何无状态通信（low-state communication）。因为弱主观性（Subjectivity）使我们无法实现关于状态的轻量级证明。换句话说，权益证明中的远程状态证明将包含与 PoW 无状态 SPV 证明大致相同的数据量，但是需要先验证整个 PoS 历史。相反，无状态 SPV 证明不需验证其他信息。这意味着在主观的权益证明环境中，跨分片或者跨链应用减少了功能且增加了开销。

（校对注：所谓工作量证明的非交互式验证，指的是当你得到一个区块的时候，因为你可以通过难度要求、区块哈希值、Nonce 等形式上的条件来确认该区块的合法性，你不需要跟出块者（矿工）交互就可以验证区块的合法性。然后再通过最长链规则来确认哪条链是有效的。这个不需要同步区块体数据、不需要计算区块链当前状态、只需要同步区块头就可验证链正确性的方案，就是所谓的 SPV 验证。SPV 验证节点不能为网络提供安全性，但可以执行一些较为简单的功能。

但是，在 PoS 系统中，由于区块已经没有了难度条件，因此你无法根据 Hash、Nonce 这些形式上的条件来判断一个区块的合法性。你只能回溯区块历史，回溯到某个你可以信任的区块上，然后一路计算出区块链当前的状态，然后你才能判断出，这个新区块与这个状态冲不冲突、合不合法。）

第 1 阶段 —— 分片

第 1 阶段旨在对分片链的内容（而不是它的功用）建立共识。换句话说，这是对分片结构的实验性运行，而不是尝试用分片进行扩展。信标链将分片的区块视为没有结构或意义的简单比特（bits）集合。分片链目前还没有账户，资产或者智能合约。信标链在每个时间段（epoch）为每个分片随机选择的分片验证者，只负责对每个区块的内容达成共识。至于分片的区块中有什么样的信息是无关紧要的，只要所有的委员会成员能在分片上定期地达成共识并更新信标链就可以。

分片的验证者通过交联（crosslinking）的过程去验证分片的内容和状态。简单地说，委员会成员必须在信标链上写入关于分片的可验证信息（比如：默克尔根）。在第 2 阶段或者之后，交联可以支持跨片通信。一旦信标链已经从多个委员处收到了给定交联准确性的证据，那么信标链就可以信任这个交联是这个分片的真实表示，而不用去验证整个分片。如果委员会成员不能对交联的有效性达成共识，那么，肯定有委员会成员是错误的，应该被罚没（slashed）。所有分片的安全性根基是：验证者的不端行为最终会被信标链发现并给予处罚。

第 1 阶段没有什么特别有趣的东西。从根本上说，这是一个用于交联和分片引用信标链的对称机制的引导启动阶段。设计者似乎很自信这些机制能行得通。主要的开放性问题都是围绕着规范和实现策略。考虑到第 0 阶段花了大约一年多的时间才形成一个像样的规范文档，我预计第 1 阶段要用的时间也差不多。有趣的是，第 0 阶段的实现是和规范同时进行的。从测试网络发布至今不到三个月的时间，第 0 阶段的规范还在经常变化。这意味着，将来 ETH2.0 的各个阶段在开发时也会有很大的变数。虽然乐观主义者告诉我 6 个月的时间就够，但是很容易看出，第 0 阶段进入测试之后，第 1 阶段需要 12-18 个月的开发时间。

第 2 阶段 —— 智能合约

第 2 阶段最终会带来一个类似 Ethereum 的系统。伴随着第 2 阶段的发行，分片链从简单的数据容器过渡到结构化的链状态。从这一阶段开始，系统会重新引入智能合约，BETH 也会变成可以转让的资产。每个分片会管理一个基于 eWASM （我们将把它称作 “EVM2”）的虚拟机。我们希望 EVM2 可以支持账户，合约，状态这些我们在 Solidity 中熟悉的抽象概念。但是大量的后台更改可能会破坏大多数现存的工具。不过还好，eWASM 团队已经为 solc，truffle 和 ganache 做了一些基础工作。我们预期在第 2 阶段的测试网（testnet）之前或者在这期间，大多数常见的工具会被移植去支持 EVM2。

状态租金（state rent），很有可能包含在第 2 阶段中，给现在的 Solidity 工程师提出了一些有趣的挑战。状态出租将要求合约开发者和用户随着时间的迁移为 EVM2 的存储付费，而不是无期限存储代码和数据。通过确保未使用的信息随着时间的推移移出状态，可以防止状态数据膨胀。这个设计的目标是让用户而不是全节点为状态的花销买单。现在已经提出了很多不同的模型，但是还不确定采用哪种方案。

有趣的是，从一些以太坊升级计划和著名的以太坊核心开发者的推荐来看，状态租金可能是不同的路线图中唯一重叠的部分。因此我强烈建议先计划让当前部署的合约支付状态租金，并设计模型以便将来把状态租金转移到用户身上。我们不知道状态租金的具体设计，但是我们应该做计划。

除了上面那些，我不知道还应该在阶段 2 中去期待些什么。目前还处于研究的早期阶段，有一些很主要的问题没被解决。考虑到不正式的规范和开发过程，以及第 2 阶段在第 1 阶段 之上的扩展范围，认为第 2 阶段在 2020 年之前发行似乎是不合理的。也就是说，虽然 ETH2.0 可能今年发行，但是不要期望 ETH2.0 能在 2020 年前支持资产流转和智能合约。

第 3 阶段 —— 链下状态存储

现在，为了更多地讨论智能合约，我们将第 3 阶段一笔带过。第 3 阶段会尽可能地把链上的状态转移到链下，从而最小化链上状态。链上会存储一些状态信息和一个聚合器（aggregator）（聚合器是一些短的数据位，用来代表长数据列表；默克尔树（Merkle tree）就是一种聚合器）。用户负责在链下存储所有的状态。当用户想和链上状态交互时，会在交易中包含一个当前状态的证据。通过这种方式，运行一个验证节点的资源要求就会少得多。现在已知一些不同性能和运行特性的聚合器设计，但是尚未定夺用哪种方法。这时候，我们已不再能利用链上通信来协调用户，因此我们必须去计划通过其他系统同步状态。事件（event）在这里对工程师来说也变得没什么用了，因为链不再保证数据的可用性。在第 3 阶段中维护和检索链下的状态将会成为 dapp 的关键性设计约束。

第 4 阶段 —— 分片合约

然而，仍然存在着一个棘手的问题：ETH2.0 合约，虽然它们还是和以太坊合约一样强大，但被限定在一个分片里，不能够和其他分片上的合约直接交互。这是分片的直接后果。分片的目标是在分片之间分割状态，不需要对其他分片的直接知识。它通过分割状态和最小化每个验证者的负载来实现扩展。但是直接的交互需要直接的知识。从设计上来讲，一个分片没有其他分片的直接知识，只能通过交联（cross-link）到信标链上得到关于其他分片的知识。因此，无论何时我们想跨片交互，都要等待信标链来确认。具体地，这意味着如果 SafeMath 部署到分片 A 上，那么在分片 B 上的用户要么通过信标链等着去使用它，要么在分片 B 上部署一个新的 SafeMath。

简单的实用程序，比如说 SafeMath 将会在每个分片上部署——1024 个分片上 1024 个SafeMath——但是像 Maker 或者 Compound 这样大体量的合约该怎么办呢？#DeFi 可组合金融的愿景在分片面前会变得支离破碎。打开 CDP 与收到 DAI 之间的长时延会造成不可接受的金融损失。如果市场波动，CDP 在用户收到 DAI 之前就被清算了怎么办？实际上，这可能意味着用户将在每个包含强制性智能合约的分片上拥有帐户，而完全不会有人去用跨片组合。只有 Maker 和 0x 都部署在同一个分片上，且 0x 的用户还在那个分片上有资产的时候，两者才能交互。

根本的两难：同步 或 扩展

ETH2.0 的设计者们不知道跨片通信系统将会是什么样。从现在能读到的很多提案来看，在及时反馈和可预测性之间似乎根本无法两全。分片的本质不能改变：用户无论如何都必须等跨片的通信。但是我们可以紧耦合或松耦合每个分片上的交易在本地和远程的执行阶段。

在紧耦合模式中，发起交易在一开始不会产生任何影响，直至分片间通信完成。相反，在松耦合交易模式中，我们可以先执行部分交易，之后再执行一部分。交易先在本地的分片执行，当跨片通信结束后在远程分片上执行。松耦合为用户提供了更好的观感，他们即刻就能看到交易在本地执行，而且知道远程的执行将在未来的某个点发生，但是用户只有等待一段时间之后才能知道松耦合交易在远程阶段的执行结果；紧耦合的交易更好预测，用户可以更充分地知晓结果，因为远程状态不会在本地和远程执行阶段之间转移，但在结果揭晓之前，用户只能继续等待。

对于 ETH2.0 的通信模型我们了解甚少。我们知道它只有牺牲几乎所有的扩展好处才能够提供跨片的合约调用。如果你的阅读止步于此，我也不会说什么，因为第 4 阶段只有一个思维导图和一些模糊的关系。如此粗浅的认识使我们不敢打包票，会不会直到第 4 阶段，ETH2.0 才会为复杂的智能合约系统提供显著的扩展优势。在此之前，希望与其他合约交互的合约必须与分片共存，并且受限于分片的速度和规模。我们估计，与 ETH1.X 相比，分片的速度最多也就是快一个小的常数倍而已。这意味着在第 4 阶段发布之前（可能在本世纪 20 年代中期）迁移智能合约代码和用户是没有有什么意义的，因为利益很少。与此同时，为了让工程师和用户更清楚其中的疑难，我研究了几个提案的模型，并且在这里包含了简短的说明。我认为这些提案都不会被采纳，但我相信，了解这些模型有助于理解其中的疑难。再次强调：下面的一切都只是猜测。

基础模型：收据与证明

所有形式的跨片通信都需要借助信标链来完成。因为在系统实际运行过程中，信标链能够向所有分片提交状态，每个分片也能够向信标链提交状态，从而我们可以将信标链看做分片生态系统的中心。从一个分片到另一个分片的信息在某种意义上必须通过信标链进行传输。但我们不想发送完整的消息，因为这样就得让信标链处理所有跨链交易本身，导致完全抵消了可扩展性带来的好处。

相反，当分片 A 上的用户或合约想与分片 B 交互时，需要让分片 A 生成一条包含该信息的 “收据 ”。分片 A 会将它的所有收据打包到它的区块头中。信标链等待分片 A 就包含该收据的区块达成共识后，将分片 A 的区块头（包括提交的收据）打包到信标链中。分片 B 必须等待信标链完成区块共识后，才能将包含分片 A 该区块头的信标链区块头打包进分片 B 的区块中，从而达成片内共识。一旦分片 B 将该信标链区块头打包后，一笔包含该收据及其证据的交易就能够提交到分片 B 中。证据证明该收据已经在分片 A 中共识、包含该证据的分片 A 的区块头已经在信标链中达成共识、包含分片 A 该区块头的信标链区块头已经在分片 B 中达成共识。通过这种方式，分片 B 上的合约就能够相信该信息是从分片 A 发出的。如果分片 B 上的合约想要发送回复信息（也许是返回一个值或一个错误），我们需要将整个过程倒过来：分片 B 生成一条收据，最终在分片 A 中生效。

很容易看出为什么这个过程非常耗时。跨片通信的四步都需要等待几分钟才能最终完成，而我们也完全不能避免这个等待过程。如果我们想要确定远程状态，我们必须等待每一步都完成。双向通信在最佳情况时也需要消耗 4 个共识周期才能完成。也就是说，用户在 3 个周期结束后才能够确认通信过程已经完成，因为用户能够在分片 A 接收到分片 B 的收据及其证据前看到分片 B 已经对该收据完成共识了。由于 ETH 2.0 的共识周期是 6.4 分钟，分片 A 的用户必须等待 19 分钟才能看到结果，而若想在分片 A 上查询到该结果则需等待 26 分钟。

具体收据：分片之间的代币迁移

ERC20 代币的通用性使得其在现有以太坊区块链中得到广泛应用。然而，ETH2.0 给 ERC20 代币的模式引入了一些新的逻辑问题。因为，ERC20 的模式是一个智能合约管理一种代币所有账户代币余额，而在 ETH2.0 早期，合约仅能存在于单一分片内，分片 A 的代币并不能在分片 B 中存在。可是，使用某些巧妙的跨片通信方案，我们能够将同一代币部署在多个分片内，并实现片间代币迁移的功能 —— 即代币合约间高效双向锚定。

这种方案非常简单：当部署代币时（让我们称其为 “炫酷跨片代币” 或简称 “CCT”），我们将使用 ERC20 代币标准，并增加 migrateSend 以及 migrateReceive 两个新增函数。其中，migrateSend 函数用于销毁代币，并生成对应收据，收据中将包括销毁代币数量，以及接收分片信息。migrateReceive 函数用于验证其他分片发往该分片的收据，并 “开采” 相同数量的 CCT 代币。在部署过程中，我们将在每个分片部署相同的代币合约。现在，我们就可以通过在一个分片调用 migrateSend 函数销毁代币，在另一分片调用 migrateReceive 函数在另一个分片 “开采” 相同数量代币，完成高效的片间代币迁移过程。虽然，我们需要在每个分片重复部署代币合约，但这似乎是值得的。该迁移方案是单向进行的，至少需要等待两个完整共识周期。因此，在调用 migrateSend 之后，大约需要等待 10 分钟，我们的 CCT 代币才能在目的分片使用。

Yanking ( “剪切粘贴” )

收据是片间信息传递的一种通信方式。我们可以在收据中存储链上的任何信息，例如，包括全部智能合约信息。Yanking 是一个通过在收据中包含合约代码与存储内容，来跨片迁移合约的提案。分片 A 上合约将被删除（“剪切”），当其 Yanking 收据在分片 B 生效后，该合约的代码和数据将被移植到分片 B。一旦迁移合约在分片 B 部署后，便可直接与分片 B 上的合约通信，以及与分片 B 的状态交互。此外，该合约还可以被剪切粘贴回到分片 A 中。

Yanking 能够实现智能合约与任意其他用户通信（在跨片等待时间之后）。不幸的是，由于 Yanking 收据包含合约的全部内容以及数据信息，迁移数据体量大或流行度高的合约成本很高。在收据迁移期间，该合约是无法使用的，因为在此期间该合约已经从分片 A “剪切” 走了，并且还没有到达分片 B。这意味着在收据到达分片 B 之前，所有用户（其他合约/地址）都不能访问该合约。即便收据在到达分片 B 之后，也只有分片 B 上的用户能够与该合约交互。因此，Yanking 方案最适合用户量少的小型合约，其能够实现紧藕合执行，但离一种通用解决方案还差的很远。

分片配对

从这里开始，我们将一起来看看更复杂的结构。收据的设计使得我们能够进行异步通信（松藕合）。然而，我们也可能需要同步通信。为此，我们必须更具创造力一点。分片配对是一种能够在最小复杂度的情况下进行紧耦合执行的简单设计。

分片配对是一种很简单的机制。如这篇博客的第三段所述，我们将分片在每个区块高度随机分配到不同同步对中。每次某一分片与另一分片相配对时，两个分片中的用户都能够执行跨片同步状态更新。这意味着，如果分片 A 和分片 B 在高度为 7 时配对，分片 A 和 B 的验证者必须知道两个分片的全部状态，并且同时出块或不出块。在这个模型中，如果你想要发送一笔分片 A 和 B 之间的跨片交易，你需要等待分片 A 和 B 被随机分配到一个同步对中。Vitalik 描述了一种 100 个分片的情况。对于 1024 个分片的情况，由于配对是随机的，我们需要等待 512 个区块（大约一个小时），才能发送跨特定分片间的交易，在实际运行过程中，所需等待时间或长或短。正如 Vitalik 所指出的，当与多个分片交互时，这种方案可扩展性非常差。

分片空间

这是一种更广义的配对。每个周期，我们将全部分片分到几个不同的 “空间”（zones）中，每个 “空间” 有多个分片。空间内各分片处理过程必须同步，意味着空间内全部分片一起更新它们的本地状态。通过处理过程同步，“空间” 能够实现空间内跨片自由移动，“空间” 内用户也可直接与 “空间” 内任意合约交互，但是该方案并不能优化访问 “空间” 外分片的过程。此外，因为 “空间” 需要验证者清楚空间内全部分片的状态，这种数据处理方式很大程度抵消了该方案可扩展性优势。如果一个空间包括 16 个分片，那么我们将牺牲大约 15/16 (=93.75%) 的可扩展性优势，以换取全网仅仅 15/1024 （≈1.4%）的紧耦合执行范围。

Encumbrances

跨片（跨链）通信的一个不明显的属性是，对于跨片信息，用户比跨片通信所涉及的区块链更快确立信心。

Alice 从分片 A 发送 5 BETH 到分片 B，她知道只要她发出信息，不久之后就能到达分片 B。Bob 看到 Alice 的发送消息后，他知道只要该信息在分片 A 共识，不久对应数量的 BETH 就能到达分片 B。然而，分片 B 以及它的合约必须等待几分钟，以确认信标链已经完成对于分片 A 上该共识的共识。

这意味着一个复杂且乐观的钱包，资产在分片 A 上被消费后，就可以立即在分片 B 上接收与消费这笔资金。换句话说，Bob 能够在分片 B 上得到一个来自 Alice 钱包的可用借据，因为 Bob 很确信 Alice 已经发送了足够的 ETH 来支付该费用。如果分片 B 上足够多的用户愿意遵守分片 A 的规定，并且接受标准化 IOU，那么分片 A 上的 ETH 在发送跨片信息之后，能够快速在分片 B 上花费。

然而，当应用智能合约之后，该机制就变得异常复杂，由于状态并不是同质可兑换的，并且不能开出状态借据。因此，该方案并不适用于通用交互形式。这意味着，我们应该将 encumbrances 视作一种松耦合下用户体验的改进。该方案使得松耦合（异步）能够允许某些交易的快速执行来模拟 “同步” 的情况。

共识状态分离

一种更复杂、更烧脑的可能方案是将共识过程与状态更新过程分离。目前，以太坊矿工以及全节点，只有在正确执行完区块中包含的全部状态更新后才会将其接收。但实际上，不必完全遵循这个步骤。它们完全可以先接收区块，之后再更新状态。在这种情况下，我们不会像在以太坊区块链中那样，对系统状态进行共识，我们会对全部分片的所有交易历史（或顺序）进行共识。这样做意味着每个分片能够在不知道任何其他分片状态的情况下快速出块，这也是分片可扩展性的优势所在。然而，在全部分片完成共识之前，交易对于分片和整个网络的影响是不清楚的。换句话说，状态的共识滞后于分片内容的共识。

从用户角度来看：我们将立即提交交易，并且知道它们已经被打包，但是我们必须等待确认该交易的结果。随着各分片共识的进行，我们会得到越来越多关于状态更新的信息，但是在所有分片都完成共识之前，我们并不能完全确定最终状态更新结果。与 encumbrances 类似，在某些情况下，用户能够先于链上确认交易输出结果，并依据此进行操作。

结论 & 工程方向

ETH2.0 将是一个完全不同于以太坊的系统。它们将并行存在很多年，并且各有各的特点。未来几年，可以期待能够实现从 ETH 到 BETH 的单向锚定。如果你运行一个交易所或托管服务，请考虑如何支持 BETH 托管交易，并且在 BETH 能够进行链上转移前为你的用户保管好。从长远来看，请考虑你的智能合约如何适应有/没有跨片通信的分片。最重要的是，密切关注开发进程。ETH2.0 是一个复杂且不断发展的系统。所有去中心化应用（DApp）工程师都需要对 ETH2.0 的计划与进程有一个清晰的认识。

(完）

原文链接: https://hackernoon.com/what-to-expect-when-eths-expecting-80cb4951afcd
作者: James Prestwich
翻译&校对: Aisling, 奇奇, stormpang & 阿剑

本文由作者授权 EthFans 翻译及再出版。

你可能还会喜欢：

PPT | ETH2.0 测试与模拟
观点 | 以太坊 2.0 中的验证者经济模型，Part-1
干货 | 探究以太坊 2.0 的分叉选择规则