什么是ETH2.0？
ETH2.0是以太坊的计划替代品。在接下来的几年里，ETH2.0开发者打算完全融入以太坊的共识系统和状态。由于涉及面广，我们无法准确传达ETH2.0会包含或不会包含的具体内容。事实上，我们已经构建了一些实际的操作规范，同时，相当多的团队力量致力于开发早期的实现。ETH2.0开发者的设想包括分片技术、Casper协议、State Rent以及以太坊虚拟机EVM的升级项目eWASM。
如今，ETH2.0初始客户端已经上线测试，预计三个月内(2019年第一季度)将推出轻量级的ETH2.0测试网络。首先，过去ETH2.0会将以太坊制作在以太坊链图中，但是ETH2.0的设计者最终计划通过将ETH2.0制作为主链，以太坊1来改变这种情况。十、所管理的分支机构。
对工程师意味着什么？
如果你是专业的Solidity程序员或者Dapp开发者，并且是部署ETH2.0智能合约的“铁杆粉丝”。然后，您可能需要进行大量的更新迭代。ETH2.0是以太坊的完美替代品，它将颠覆我们在写智能合约时所做的许多假设。它计划的多年分阶段推出不像是一个升级周期，更像是一个产品发布周期。我们为ETH1编写的工具和智能合约。x可能需要重新发明。幸运的是，我们有几年时间来构建这个生态系统。
为了推动这项工作，我打算讨论目前的路线图，并介绍一些工程影响。
逐步淘汰
目前碎片化路线图(两倍于ETH2.0路线图)列出了七个阶段。只有阶段0有明确的规范，定期更新。阶段规范的严格性和准确性要低很多，可能处于一种消极的发展状态。在第一阶段之后，路线图将转化为目标列表，而不是技术文档。
例如，在第2阶段，路线图链接到ethresear.ch的次数是链接到Github的三倍。由于未来的任何步骤更像是推测而非工程，我们的具体讨论仅限于阶段0、1和2。同时，这些具体的讨论也涉及到后期可能方向的几个大概的轮廓。
0:信标链(信标链)
0介绍了“灯塔链”，(Odaily Daily Planet注：灯塔链是一个全新的区块链，在新以太坊中占据核心地位。这个链条承担的功能之一就是让验证者参与到质押系统中，取代矿工的角色，成为链条的建设者。另一个功能是存储碎片状态的索引)。ETH2.0的设计者希望信标链能够成为ETH2.0生态系统的核心，成为其他碎片的安全和验证的根源。在部署信标链之后，将使用PoW/PoS混合机制的友好精细度小工具(Casper FFG)来证明公平性。
显然，像“信标链”这样的早期迭代在设计之初就尽可能简单，这也是为什么Phase 0不支持智能合约、账户、资产转移，也不包括任何碎片化。同时，基于信标链的以太坊无法实现链转移，也就是说用户无法将其存放在交易所。
贝丝：新以太坊
作为一种新的资产类型，信标ETH(BETH)仅由信标链上的利益相关者(持有人或用户)使用。贝丝可以通过以下两种方式创建。
作为对验证信标链(以及阶段1之后的分段)的奖励；任何ETH1。x用户可以通过ETH1购买1 eth的BETH。x合同，也就是所谓的“定金”。工程师可能注意到合同中没有提到取消功能。这是因为由于阶段0，用户不能从信标链中撤销BETH。也就是说，一旦用户处于存储在ETH1中的注册契约中。x验证器，ETH1。以太坊被摧毁了。信标验证者将遵守合同并将收费信息提交给信标链，信标链将向收费用户发布新的BETH。
所以ETH发送到验证注册契约后不久，用户就会收到信标链下发的相应的BETH号。在此过程中，充值可以临时审核，但根据Casper协议，不能永久审核。
直到阶段2，以太坊才能在信标链上传输。在我看来，没有办法把BETH搬回ETH1。ETH1之前的x。x完全融入了碎片化的生态系统。由于0阶段是不完整的，也没有可靠清晰的1阶段规范，因此可以合理假设，BETH作为一个独立的、不可转让的资产类型，至少需要两年的时间。第二阶段完成，贝斯自然会实现碎片化转移，而ETH不会，不会造成不可逆转的经济困难。
过去，一些像BETH这样功能较低的Token项目一直通过IOU(欠条)在交易所进行交易。例如，在Tezos的众筹期间，它推出了HitBit和BitMEX XTZ期货市场。因此，如果有BETH的需求，我们应该致力于建立一个支持交易和托管BETH的交易生态系统。但是，目前用户可能对贝丝的需求有疑问。BET由于ETH到BETH的单向挂钩
H 价格上限为1 ETH，BETH 并不是一个绝佳的投资标的。换言之，BETH 永远不会比 ETH 更值钱，甚至有可能价值更低。0 阶段+：入股（staking）
在信标链上，用户可以投注 32 个 BETH 保证金成为验证者。在阶段 0 中，验证者只需管理信标链即可；而从阶段 1 伊始，验证者在管理信标链的同时，还将管理 1024 条分片链。信标链以及每一条分片链将使用 Casper FFG 来完成出块。FFG 是一种权益证明算法（Proof of Stake），用于对链上不良行为实施罚没（即削减权益）。
细心的读者会发现 FFG 在分片路线图的“以太坊 3.0”部分的表兄弟 Casper CBC。虽然对 FFG（当然还有 CBC）的细致解读已超出本文的讨论范围。若是感兴趣，可以阅读以太坊创始人 V 神（Vitalik Buterin）关于混合 PoW / FFG 的说明，以及其关于最小化削减条件和 FFG 论文。
用户（stakers）需做些什么？
分片目的在于节点之间分割（Split）分片的状态信息，而无需要求任何节点都同时具备网络的全部图景。基于此，验证者不会验证所有分片。相反，信标链将协调其他分片的验证，所有验证者将进行信标链的验证。
经过一个固定时期（64 个块或约 6.4 分钟），信标链将对验证者进行“洗牌”，并将其随机分配给分片。分配给分片的一组验证者被称为委员会（Committee），其中包括 128 名委员。在阶段 0 中，委员会机制意味着信标链大约每隔 6 分钟就需要选择可用的验证者，随后在接下来的 6 分钟内组成一个完整的委员会；在阶段 1 中，信标链将 1024 个分片指定一个验证者委员会。指定的过程是极其复杂的，涉及多阶段随机数生成过程以及可验证的延迟函数，从而能够阻止试图操纵委员会遴选的过程。
委员会将负责保护其分片的安全性、活跃度以及完整性，同时还需证实（Attest）信标链上的分片状态，其存在的重要性不言而喻，ETH2.0 因此会随机进行委员会的选择，并经常轮换委员会成员。同时，这也是信标链能够知悉分片状态的唯一方式，反之亦然。
从所有的验证池中随机选择验证者，可以做大限度地减少委员会作为一个整体撒谎或欺骗的可能性。委员会的轮换也能够降低糟糕的委员会可能造成的伤害。换句话说，对于目的不纯或者试图利益最大化的验证者很难将委员会作为攻击网络任何部分的工具。退一步讲，假如验证者获得对分片委员会的控制权，其能够控制的区块也不会超过 64 个。
PoS证明的影响有哪些？
虽然，ETH1.X 的工作量证明（Proof of Work）与 ETH2.0 权益证明（Proof-of-Stake）之间的哲学差异记录是一个持续过程，但值得注意的是，一些 PoW/PoS 特性的差异确实会直接影响到工程师。例如，PoW 链支持无状态简化支付验证（SPV）和工作量证明的非交互式证明（NIPoPoW）远程状态跟踪，但 PoS 则禁止任何低状态通信。主观性阻碍轻状态（State-light）查看证明（Attestations）。
换句话说，关于权益证明的远程状态证明将包含 PoW 无状态 SPV 验证大致相同的数据量，但需要对整个 PoS 历史进行预先验证。相比之下，无状态 SPV 验证不需要其他信息进行验证。这意味着在主观权益证明环境中，跨分片或跨链应用程序功能减少，但开销增加。
阶段 1：分片
阶段 1 旨在就分片链的内容达成共识，并非对其意义达成共识。换言之，这是一次对分片结构的“试运行”，而不是尝试使用分片进行扩容（Scale）。信标链将分片链视为没有结构或意义简单的位（Bit）集合。分片链尚未拥有账户、资产或智能合约。分片验证者是由信标链为每个时间段（Epoch）的分片进行随机选择产生的。其仅仅对每个块的内容达成一致。在分片中出现什么信息并不重要，只要所有委员会成员达成共识，并定期更新分片上的信标链即可。
通过一个称为交联（Crosslinking）的过程，分片验证者可以验证分片的内容及状态。简单来说，委员会必须在信标链中包含关于分片（例如根哈希）的可验证信息。在阶段 2 甚至更高阶段，交联将支持跨分片通信（Cross-Shard Communication）。信标链从多个委员会收到给定交联的准确性证据后，信标链就可以相信交联是分片的真实表示，而无需验证整个分片。如果委员会对交联的有效性存在分歧，即很明显其中一个委员会是错误的，验证者应该予以罚没。
这是所有分片的安全根源，即其验证者的不当行为最终会被信标链发现并受到惩罚。
阶段 1 并不存在任何特别有趣的内容。从根本上说，这只是用于交联的引导阶段，也可以说是分片引用信标链的对称机制。设计者们似乎对这些工作机制充满信心，这些机制开放问题主要围绕规范和策略实施。鉴于阶段 0 花费一年多的时间才达到合理的规范水平，阶段 1 估计亦是如此。
有趣的是，阶段 0 的实现与规范的制定同时推进。即使当下――距离测试网络还不到三个月的时间，阶段 0 规范也会定期修改。对于时间线的预估也意味着未来 ETH2.0 阶段在开发时间上会存在极大的差异。乐观主义者告诉我 6 个月就已足够，但在我看来，在看到阶段 0 进入测试之后，阶段 1 需要 12 个月至 18 个月的开发周期。
阶段 2：智能合约
最终，阶段 2 会带来一个与我们所熟悉的以太坊相似的系统。随着阶段 2 发布，分片链从简单的数据容器过渡至结构化的链状态。此时，新的以太币 BETH 可实现转让，并且将重新引入智能合约。每个分片将基于 eWASM（我们称之为“EVM2”）管理一个虚拟机。
在这个阶段，EVM2 将支持我们熟悉的账户、合约、状态以及其他抽象内容。然而，大量的幕后更改可能会破坏大多数现有工具。幸运的是，eWASM 技术团队已为 Solc 编译器、以太坊的开发和测试框架 Truffle、Ganache 做了一些基础工作。在阶段 2 的测试网络之前或期间，我们能够看到最常用的工具移植于此支持 EVM2。
状态租赁（State Rent）或包含在阶段 2，这也对当前 Solidity 编程语言工程师们提出一些有意思的挑战。状态租赁并不是无限期地存储代码和数据，而是要求合约开发者以及用户在一段时间内为 EVM2 存储付费。通过确保未使用的信息随着时间的推移而脱离状态来防止状态膨胀，最终实现其目标――让用户而不是让整个节点来支付状态成本。人们为此提出不同的模式，“百家争鸣”，但仍没有明确的定论。
随着一些以太坊升级计划推进，以及著名以太坊核心开发者极力举荐，状态租赁可能是不同路线图中唯一重叠的部分。因此，我强烈建议计划在当前部署的合约上对状态租赁的支持，并设计模型，以便未来将状态租赁转移至用户。虽然我们还不曾参透状态租赁的精确设计，但当下能做的是应该为成本制定具体计划。
此外，我们并不知道阶段 2 的最终归处，其依然处于早期的研究阶段，包括几个尚未解决的主要问题。鉴于非正式规范和开发过程，以及阶段 2 在阶段 1 的拓展范围。在 2020 年之前启动阶段 2 似乎并不合理。也就是说，虽然 ETH2.0 或在今年推出，但预计 ETH2.0 版本至少要到 2020 年才能支持资产转移或智能合约。
阶段 3：链下状态存储
现在，为了更好地讨论智能合约，我们将几乎完全跳过阶段 3。
通过尽可能多地将状态转移至链下，阶段 3 尽可能减少链上状态。链上存储时并不用存储整个状态，只需将一些状态信息和聚合器（聚合器是表示长数据列表的短数据；Merkle 树即为聚合器的一种）进行存储。用户将负责在链下存储完整的状态。
当用户与状态进行交互时，其会在交易中包含当前状态的证明。这样，运行验证节点的资源要求便会相对低很多。如今已经出现一些聚合器的设计，其存在不同特性和性能特征，但目前尚未作出具体选择。在这个阶段，由于链不再能够保证数据的可用性，我们会停止使用链上通信来进行用户协调。在阶段 3 中，维护和获取链下状态将成为限制设计 DApp 的关键性因素之一。
阶段 4：分片智能合约
然而，一个不可逾越的问题依然存在。虽然 ETH2.0 合约与以太坊的合约同样强大，但其必然会被绑定到一个分片上，且永远无法与另一个分片上的合约进行直接交互。这是分片的直接结果，分片目的在于在分片之间实现状态分割，而无需直接了解其他分片。通过分割状态以及尽可能的减少验证者的工作量来实现拓展。
直接交互需要直接知识储备。根据设计，分片不具有其他分片的直接知识。它仅通过与信标链的跨链通信来了解其他分片。因此，当用户要进行跨分片交互时，就必须等待信标链。具体来说，这意味着如果在分片 A 上部署 SafeMath 模块，分片 B 上的用户必须等待访问，或者在分片 B 上部署新的 SafeMath 模块。
像 SafeMath 这样的简单实用程序将被部署到每个分片，即 1024 个分片上会部署 1024 个SafeMath。但是像 Maker 或 Compound 这样的市场呢？#DeFi 对可组合金融的允诺或许会变得难以跨越分片边界。
CDP 激活与 DAI 收取之间的长时间延迟会导致难以负担的经济损失。若市场发生变化，同时 CDP 在用户收到 DAI 之前被清算情况又会如何？在实际操作中，这可能意味着用户需要在每个包含智能合约的分片上拥有一个账户，但跨分片的结构则毫无用武之地。Maker 和 0x 只有在其均部署在同一个分片上时才能进行交互，并且 0x 用户也需要在该分片上拥有一定数量的资产。
根本性权衡：同步或是扩展
ETH2.0 版本的设计人员并不知晓跨分片通信系统的最终模样。通过阅读诸多提案，该系统或许会在即时反馈与可预测性之间进行根本性权衡。分片的本质不会改变，任何用户都必须等待跨分片通信。但是，我们可以紧密或松散地将交易的本地和远程执行阶段耦合到每个分片上。
紧密耦合会使得等待处于优先级。在分片通信之前，交易不会执行任何操作。相反，我们可以通过现在执行部分以及稍后执行部分来松散地进行耦合交易。交易在本地分片上执行，然后在跨分片通信之后在远程分片上执行。
松散耦合提供了更好的用户体验。用户能够即时看到其交易在本地执行，且知道远程执行将在未来的某个时刻发生。但福祸相依，用户必须在等待的情况下才能够知道松散耦合交易远程阶段的结果。相较于松散耦合交易，紧密耦合的交易更具可预测性。同时，由于远程状态不会在本地和远程执行阶段之间转换，用户更了解结果。但“心急吃不了热豆腐”，紧密耦合需要用户在看到任何结果之前必须等待。
关于 ETH2.0 通信模型的信息少之又少。我们知道，该模型必须在牺牲几乎所有扩展优势的情况下提供跨分片合约调用。如果你在这里停止阅读，我不会责怪你，因为阶段 4 只存在思维导图和一些模糊的链接。这种情况的一个不明显的结果就是，ETH2.0 在阶段 4 之前并不会为复杂的智能合约系统提供显著的扩容优势。在此之前，希望与其他合约交互的智能合约必须与一个分片共存，并且局限于该分片的速度和扩容效果。与 ETH1.X 相比，分片可能最多只能获得一个小常数因子的加速量。这意味着在阶段 4 发布之前（2025 年前后），由于其优势不大，没有理由将智能合约代码或用户进行迁移。
与此同时，为了更好地理解工程师和 DApp 用户的权衡，我研究了一些社区或者开发者建议的模型。在我看来，这些模型都不会被采用，但我相信这些模型有助于理解这其中所涉及的权衡。划重点：下面所有的内容都是推测性的。
基本模型：收据（Receipt）和证明（Proof）
所有形式的跨链通信都借助信标链。由于信标链能够检索所有分片的状态，并且每个分片会影响到信标链的状态，因此将其用作分片链生态系统中的核心。从某个链到另一个链的信息在某种意义上必须通过信标链传输，考虑到这需要信标链来处理每笔交易本身，完全无法实现扩容的效果，故并不希望发送完整的消息。
相反，当分片 A 上的用户或合约想要与分片 B 进行交互时，分片 A 会生成带有该交互消息的“收据”。分片 A 在其块头中提交其所有收据，信标链再等待 A 确认完成后，将提交至分片 A 的块头（包括对收据的提交）。分片 B 也必须等待信标的最终确认，之后提交至信标块头。
该阶段完成之后，可以向分片 B 提交新交易，包括收据和证明。证明显示收据包含在分片 A 中，分片 A 包含在信标中，且信标包含在分片 B 中。这样，分片 B 上的用户或合约可以信任从分片 A 发送的消息。如果分片 B 上的合约想要发送回复（或返回值、错误），则需要反过来重复整个过程：分片 B 发出一个收据，最终回至分片 A。
不难看出，该过程需要消耗大量时间。四个通信步骤中的每一步都需要等待几分钟才能完成。不幸的是，我们无法完全避免等待。如果我们想确定远程状态，那么在每一步都必须等待最终结果。往返通信的最佳情况是四个最终确认周期。换言之，由于用户可以在分片 A 看到分片 B 的数据之前看到它们，在三个确认周期后用户可获得信心。使用 ETH2.0 的 6.4 分钟的时间段（Epoch）长度，用户必须等待 19 分钟才能看到结果，并且需要 26 分钟才能获得链上结果。
具体收据（Concrete Receipts）：分片之间的代币迁移
ERC20 Token 的多功能性使其在如今的以太坊中无处不在。但是，ETH2.0 也给 Token带来部分逻辑问题。由于智能合约管理所有的 Token 余额，且智能合约仅存在于单个分片上。因此，分片 B 上根本不存在来自分片 A 的 Token。但通过一些智能跨分片通信，我们可以在多个分片上部署相同的 Token，并允许在分片之间进行 Token 转移，有效地在 Token 合约之间建立双向挂钩。
解决方案非常简单。
在部署 Token 时（让我们称之为“酷酷的跨分片 Token”或“CCT”），我们将基于 ERC20 添加两个小附加功能――MigrateSend 和 MigrateReceive 函数功能。借助使用 MigrateSend 销毁 Token 并生成收据，其中将包括已销毁的 Token 和接收的分片。之后，通过调用 MigrateSend 来销毁一个分片上的 Token，然后在另一个分片上调用 MigrateReceive 来有效地进行 Token 转移。
我们需要在每个分片上重新部署我们的 Token 合约，但这似乎是值得的。迁移是单向的，至少需要两个跨分片通信的最终确认。因此，我们调用 MigrateSend 之后大约需要 10 分钟，“CCT”才可以在接收分片上使用。
Yanking（拉拽）
收据是跨分片进行信息传递的一种通用方式。我们可以在收据中放置任何链上信息，甚至包括整个智能合约。Yanking 是一种通过将合同的代码存储包含在收据中，从而实现跨分片合同迁移的提议。合约将从分片 A 中删除（Yanked），然后在收据到达之后在分片 B 上重新部署。合约一旦进入分片 B，其可以直接与分片 B 合约进行通信，并且与分片 B 的状态进行交互。同时，该合约甚至可以被 Yank 回至分片 A。
这将允许任何一个智能合约与任何其他智能合约进行通信（在跨分片等待时间之后）。但由于收据包含整个合约及其所有存储，因此转移大型或用户体量大合约的成本会很高。收据在运输过程中，合约将完全无法使用。其已从分片 A 中抽出，但尚未到达分片 B。这意味着所有其他用户均无法使用该合约，直到其到达分片 B。同时，只有已在分片 B 上的用户才能与之进行交互。因此，Yank 最适合用户很少的小智能合约，它使紧密耦合的执行成为可能，但并非是通用的解决方案。
分片配对（Shard Pairings）
我们转而谈谈一些更具创意的构建想法。
收据旨在使异步（松散耦合）通信成为可能。但我们也可能需要同步通信。为此，我们必须更有创意。通过一个简单设计，分片配对可以实现在紧密耦合执行的同时，尽可能地将麻烦最小化。
分片配对是一个简单的解决方案。在文章的第三段中就已经提到，我们在每个高度将分片混合成同步对。每次一个分片与另一个分片进行配对时，任一分片的用户都可以跨越这两个分片执行紧密耦合的状态更新。如果分片 A 和 B 在高度 7 处配对，则 A 和 B 的所有验证者必须知道 A 和 B 的全部状态，并且分片必须一起前进或根本不前进。
在此模型中，如果 A 和 B 之间需要进行跨链交易，则需要等待 A 和 B 随机配对。但是 Vitalik 描述了 100 种分片案例。存在 1024 个分片，我们预计其需要 512 个区块，因此大约需要一个小时。但由于配对是随机的，它可能需要更长或更短。正如 Vitalik 所说，当你想要与多个分片进行交互时，这种扩容性并不好。
分片区域（Shard Zones）
这是分片配对的更广泛版本。
每个时间段（Epoch），我们将分片分成几个由多个分片组成的“区域”。区域内的分片必须同步进行，因此需要共同更新其本地状态。通过同步进行，区域保证了分片之间的自由移动，以及与区域中的任何合约直接交互，但与区域外的任何分片进行通信则没有任何优势。
此外，由于区域需要验证者知悉区域中所有分片的状态，会导致其否定分片的许多扩容优势。假如一个区域由 16 个分片组成，则牺牲约 15/16（ 94％）的扩容优势，仅获得总网络的 15 / 1024（1％）的紧密耦合的执行。
产权负担（Encumbrances）
跨分片（和跨链）通信的一个不明显的特性是，用户可以比所涉及的链更快地获得对消息的信任。Alice 从分片 A 向分片 B 发送 5 BETH，其知道这些资产会在发送后立即到达。Bob 看到交易发送，知道一旦发送至分片 A 上进行确认后，BETH 将到达分片 B。然而，分片 B 及其合约必须等待几分钟，才能使信标链对分片 A 的确认进行最终确认。这意味着资金在分片 A 上花费以后，一个钱包能够很快在分片 B 上进行接收和花费这些资金。换句话说，由于 Bob 很有信心 Alice 已发送足够的 ETH，其将从分片 B 上 Alice 的钱包中获得可执行的 IOU（欠条）。如果分片 B 存在足够多的用户愿意观察分片 A 并接受标准化的 IOU，则分片 A 上的 ETH 可能会在发送之后很快在分片 B 上花费。
然而，当应用于智能合约时，由于状态永远不可替代，这种解决方案就变得异常复杂。状态的欠条是不可能实施的，因此其亦不适用通用交互。我们应该将产权负担视为松散耦合中的用户体验进行改进，允许松耦合模拟紧耦合，快速执行某些交易。
共识和状态分离
更复杂和更让人感兴趣的一种方案是将共识过程与状态更新过程分离。
只有在执行区块中包含的所有状态更新后，以太坊矿工和完整节点才接受区块。事实并非如此。相反，其可以先接受区块，而后进行状态更新。在这种情况下，我们不会像在以太坊中那样就系统状态达成共识，而是会对所有分片中所有交易的总历史（或“总顺序”）达成共识。
这种解决方案意味着每个分片都可以快速添加区块，而无需知道任何其他分片的状态，这就是利用分片进行扩容的原理。但在所有分片完成之前，交易对分片状态和整个网络的影响将会被隐匿。换句话说，状态的最终确认落后于分片内容的最终确认。
从用户的角度来看，我们会立即提交交易，且知道该交易已被包含在内。但用户必须等待一定时间来确定该交易的结果。随着分片的最终确定，我们逐渐获得有关状态的更多信息，但在所有分片达到最终确认之前，用户并不能完全确定。与产权负担相似，在某些情况下，用户可以提前确认交易的结果并相应地采取行动。
小结
ETH2.0 将是与以太坊完全不同的系统，二者将并行存在多年并具有不同的特征集。在不久的将来，预计会出现从 ETH 到 BETH 的单向挂钩。如果你经营交易所或托管服务，可以考虑 BETH 在链上实现转移之前支持用户进行 BETH 托管交易和押注。从长远来看，还需要考虑智能合约如何在有无跨分片通信的情况下适应分片。
最重要的是要密切关注研发过程。ETH2.0 是一个复杂且不断发展的系统，所有 DApp 工程师都需要清楚地了解 ETH2.0 计划和进度。
