编者按：近日，“以太坊君士坦丁堡分叉”成为区块链领域热门话题，而作为以太坊的计划替代方案，真正的“硬菜”——ETH2.0也将逐渐揭开面目。抛开对于枯燥术语定义的解读，JamesPrestwich讨论下当前的以太坊路线图。同时，他脑洞大开，在这些具体讨论中设想关于以太坊后期阶段可能方向。文章来自Medium，以下为编译全文。作者|JamesPrestwich编译|袁辉腾编辑|卢晓明ETH2.0是什么？
ETH2.0是以太坊的计划替代方案。在接下来的几年里，ETH2.0的开发者们打算将现在以太坊的共识系统以及状态完全纳入其中。由于其范围如此广泛，我们也无法准确地传达出ETH2.0将会包含或不包含的具体内容。确实，我们已建构部分切实可行的操作规范，同时也有相当多的团队力量致力于开发早期的实现。ETH2.0开发者暂时计划包括分片技术、Casper协议、状态租赁、以太坊虚拟机EVM的升级项目eWASM。如今，ETH2.0初始客户端已经上线测试，并预计在三个月内推出轻量级ETH2.0测试网络。首先，ETH2.0会让以太坊链中的以太币映射过去，但ETH2.0设计者最终计划通过将ETH2.0成为主链，而Ethereum1.X则是其管理下的分支链来改变这种局面。对工程师意味着什么？
如果你是专业的Solidity程序员或Dapp开发人员，并且是部署ETH2.0智能合约“铁杆粉丝”。那么，你可能需要进行大量的更新迭代。ETH2.0是以太坊的完全替代品，其将推翻我们在编写智能合约时所做的诸多假设。其计划的多年阶段性推出并不像是升级周期，更像是一个产品发布周期。我们为ETH1.X编写的工具和智能合约或需要推倒重来。幸运的是，我们有几年的时间来建构这个生态系统。为了推动这项工作，我打算讨论下当前的路线图，并介绍一些工程上的影响。分阶段推出
目前，分片路线图列出了七个阶段。只有阶段0有明确的规范，并定期更新。阶段1规范的严格性、准确性要低很多，且可能处于消极的开发状态。从阶段1后，路线图转变为目标列表，而不再是技术文档。举个例子，在阶段2中，路线图链接到ethresear.ch的次数是链接到Github的三倍。由于未来的任何一步都更像是推测，而不是工程，因此我们的具体讨论仅限于阶段0、1、2。同时，在这些具体讨论中也涉及几个关于后期阶段可能方向的粗略轮廓概述。阶段0:信标链
阶段0引入了“信标链”，。ETH2.0设计者希望信标链能够成为ETH2.0生态系统的核心，成为其他分片的安全和验证的根源。信标链部署完毕后，将使用PoW/PoS混合机制的CaspertheFriendlyFinalityGadget进行股权证明。显然，像“信标链”的这种早期迭代在设计之初就尽可能简单，这也是阶段0并不支持智能合约、账户、资产转移，也不包括任何分片的原因。同时，基于信标链上的以太币也无法实现链上转移，这意味着用户不能将其存入交易所。BETH：新的以太币
作为一种新资产类型，BeaconETH仅由信标链上的Stakers使用。BETH能够以下两种方式创建。作为验证信标链的奖励；任何ETH1.X用户可以通过ETH1.X合约购买1个ETH的BETH，合约将其称为“存款/充值“。工程师可能会注意到，合约内并未提到撤销功能。这是由于阶段0，用户无法从信标链中撤回BETH。也就是说，用户一旦在存储在ETH1.X验证者注册合约中，ETH1.X以太币则被销毁。信标链验证者会观察该合约，并向信标链提交充值信息，信标链将向充值用户发行新的BETH。因此，在ETH发送给验证注册合约不久，用户便会收到信标链发布的对应数量的BETH。这一过程中，可以对充值进行临时审查，但根据Casper协议规定，不能对其进行永久性审查。一直到阶段2，以太币才能够在信标链上进行传输。在我看来，在ETH1.X没有完全融入分片生态系统之前，没有任何办法可以将BETH移回ETH1.X。鉴于阶段0并不完整，且不存在可靠明确的阶段1规范，因此可以合理的假设：BETH作为独立切不可转让的资产类型至少还需两年。当阶段2完成，BETH实现分片转移自然“水到渠成”，但ETH却不会，而这并不会造成不可逆的经济困难。过去，一些类似BETH这种低功能的Token项目已通过IOU在交易所进行交易。例如，在Tezos众筹期间，其就曾推出HitBit和BitMEXXTZ期货市场。因此，若是对BETH存在需求，我们应该致力于构建一个支持受托管BETH的交易和入股的交易所生态系统。然而，用户当下对于BETH的需求或许存在怀疑。由于从ETH到BETH的单向挂钩导致BETH价格上限为1ETH，BETH并不是一个绝佳的投资标的。换言之，BETH永远不会比ETH更值钱，甚至有可能价值更低。0阶段+：入股
在信标链上，用户可以投注32个BETH保证金成为验证者。在阶段0中，验证者只需管理信标链即可；而从阶段1伊始，验证者在管理信标链的同时，还将管理1024条分片链。信标链以及每一条分片链将使用CasperFFG来完成出块。FFG是一种权益证明算法，用于对链上不良行为实施罚没。细心的读者会发现FFG在分片路线图的“以太坊3.0”部分的表兄弟CasperCBC。虽然对FFG的细致解读已超出本文的讨论范围。若是感兴趣，可以阅读以太坊创始人V神关于混合PoW/FFG的说明，以及其关于最小化削减条件和FFG论文。用户需做些什么？
分片目的在于节点之间分割分片的状态信息，而无需要求任何节点都同时具备网络的全部图景。基于此，验证者不会验证所有分片。相反，信标链将协调其他分片的验证，所有验证者将进行信标链的验证。经过一个固定时期，信标链将对验证者进行“洗牌”，并将其随机分配给分片。分配给分片的一组验证者被称为委员会，其中包括128名委员。在阶段0中，委员会机制意味着信标链大约每隔6分钟就需要选择可用的验证者，随后在接下来的6分钟内组成一个完整的委员会；在阶段1中，信标链将1024个分片指定一个验证者委员会。指定的过程是极其复杂的，涉及多阶段随机数生成过程以及可验证的延迟函数，从而能够阻止试图操纵委员会遴选的过程。委员会将负责保护其分片的安全性、活跃度以及完整性，同时还需证实信标链上的分片状态，其存在的重要性不言而喻，ETH2.0因此会随机进行委员会的选择，并经常轮换委员会成员。同时，这也是信标链能够知悉分片状态的唯一方式，反之亦然。从所有的验证池中随机选择验证者，可以做大限度地减少委员会作为一个整体撒谎或的可能性。委员会的轮换也能够降低糟糕的委员会可能造成的伤害。换句话说，对于目的不纯或者试图利益最大化的验证者很难将委员会作为攻击网络任何部分的工具。退一步讲，假如验证者获得对分片委员会的控制权，其能够控制的区块也不会超过64个。PoS证明的影响有哪些？
虽然，ETH1.X的工作量证明与ETH2.0权益证明之间的哲学差异记录是一个持续过程，但值得注意的是，一些PoW/PoS特性的差异确实会直接影响到工程师。例如，PoW链支持无状态简化支付验证和工作量证明的非交互式证明远程状态跟踪，但PoS则禁止任何低状态通信。主观性阻碍轻状态查看证明。换句话说，关于权益证明的远程状态证明将包含PoW无状态SPV验证大致相同的数据量，但需要对整个PoS历史进行预先验证。相比之下，无状态SPV验证不需要其他信息进行验证。这意味着在主观权益证明环境中，跨分片或跨链应用程序功能减少，但开销增加。阶段1：分片
阶段1旨在就分片链的内容达成共识，并非对其意义达成共识。换言之，这是一次对分片结构的“试运行”，而不是尝试使用分片进行扩容。信标链将分片链视为没有结构或意义简单的位集合。分片链尚未拥有账户、资产或智能合约。分片验证者是由信标链为每个时间段的分片进行随机选择产生的。其仅仅对每个块的内容达成一致。在分片中出现什么信息并不重要，只要所有委员会成员达成共识，并定期更新分片上的信标链即可。通过一个称为交联的过程，分片验证者可以验证分片的内容及状态。简单来说，委员会必须在信标链中包含关于分片的可验证信息。在阶段2甚至更高阶段，交联将支持跨分片通信。信标链从多个委员会收到给定交联的准确性证据后，信标链就可以相信交联是分片的真实表示，而无需验证整个分片。如果委员会对交联的有效性存在分歧，即很明显其中一个委员会是错误的，验证者应该予以罚没。这是所有分片的安全根源，即其验证者的不当行为最终会被信标链发现并受到惩罚。阶段1并不存在任何特别有趣的内容。从根本上说，这只是用于交联的引导阶段，也可以说是分片引用信标链的对称机制。设计者们似乎对这些工作机制充满信心，这些机制开放问题主要围绕规范和策略实施。鉴于阶段0花费一年多的时间才达到合理的规范水平，阶段1估计亦是如此。有趣的是，阶段0的实现与规范的制定同时推进。即使当下——距离测试网络还不到三个月的时间，阶段0规范也会定期修改。对于时间线的预估也意味着未来ETH2.0阶段在开发时间上会存在极大的差异。乐观主义者告诉我6个月就已足够，但在我看来，在看到阶段0进入测试之后，阶段1需要12个月至18个月的开发周期。阶段2：智能合约
最终，阶段2会带来一个与我们所熟悉的以太坊相似的系统。随着阶段2发布，分片链从简单的数据容器过渡至结构化的链状态。此时，新的以太币BETH可实现转让，并且将重新引入智能合约。每个分片将基于eWASM管理一个虚拟机。在这个阶段，EVM2将支持我们熟悉的账户、合约、状态以及其他抽象内容。然而，大量的幕后更改可能会破坏大多数现有工具。幸运的是，eWASM技术团队已为Solc编译器、以太坊的开发和测试框架Truffle、Ganache做了一些基础工作。在阶段2的测试网络之前或期间，我们能够看到最常用的工具移植于此支持EVM2。状态租赁或包含在阶段2，这也对当前Solidity编程语言工程师们提出一些有意思的挑战。状态租赁并不是无限期地存储代码和数据，而是要求合约开发者以及用户在一段时间内为EVM2存储付费。通过确保未使用的信息随着时间的推移而脱离状态来防止状态膨胀，最终实现其目标——让用户而不是让整个节点来支付状态成本。人们为此提出不同的模式，“百家争鸣”，但仍没有明确的定论。随着一些以太坊升级计划推进，以及著名以太坊核心开发者极力举荐，状态租赁可能是不同路线图中唯一重叠的部分。因此，我强烈建议计划在当前部署的合约上对状态租赁的支持，并设计模型，以便未来将状态租赁转移至用户。虽然我们还不曾参透状态租赁的精确设计，但当下能做的是应该为成本制定具体计划。此外，我们并不知道阶段2的最终归处，其依然处于早期的研究阶段，包括几个尚未解决的主要问题。鉴于非正式规范和开发过程，以及阶段2在阶段1的拓展范围。在2020年之前启动阶段2似乎并不合理。也就是说，虽然ETH2.0或在今年推出，但预计ETH2.0版本至少要到2020年才能支持资产转移或智能合约。阶段3：链下状态存储
现在，为了更好地讨论智能合约，我们将几乎完全跳过阶段3。通过尽可能多地将状态转移至链下，阶段3尽可能减少链上状态。链上存储时并不用存储整个状态，只需将一些状态信息和聚合器进行存储。用户将负责在链下存储完整的状态。当用户与状态进行交互时，其会在交易中包含当前状态的证明。这样，运行验证节点的资源要求便会相对低很多。如今已经出现一些聚合器的设计，其存在不同特性和性能特征，但目前尚未作出具体选择。在这个阶段，由于链不再能够保证数据的可用性，我们会停止使用链上通信来进行用户协调。在阶段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发布之前，由于其优势不大，没有理由将智能合约代码或用户进行迁移。与此同时，为了更好地理解工程师和DApp用户的权衡，我研究了一些社区或者开发者建议的模型。在我看来，这些模型都不会被采用，但我相信这些模型有助于理解这其中所涉及的权衡。划重点：下面所有的内容都是推测性的。基本模型：收据和证明
所有形式的跨链通信都借助信标链。由于信标链能够检索所有分片的状态，并且每个分片会影响到信标链的状态，因此将其用作分片链生态系统中的核心。从某个链到另一个链的信息在某种意义上必须通过信标链传输，考虑到这需要信标链来处理每笔交易本身，完全无法实现扩容的效果，故并不希望发送完整的消息。相反，当分片A上的用户或合约想要与分片B进行交互时，分片A会生成带有该交互消息的“收据”。分片A在其块头中提交其所有收据，信标链再等待A确认完成后，将提交至分片A的块头。分片B也必须等待信标的最终确认，之后提交至信标块头。该阶段完成之后，可以向分片B提交新交易，包括收据和证明。证明显示收据包含在分片A中，分片A包含在信标中，且信标包含在分片B中。这样，分片B上的用户或合约可以信任从分片A发送的消息。如果分片B上的合约想要发送回复，则需要反过来重复整个过程：分片B发出一个收据，最终回至分片A。不难看出，该过程需要消耗大量时间。四个通信步骤中的每一步都需要等待几分钟才能完成。不幸的是，我们无法完全避免等待。如果我们想确定远程状态，那么在每一步都必须等待最终结果。往返通信的最佳情况是四个最终确认周期。换言之，由于用户可以在分片A看到分片B的数据之前看到它们，在三个确认周期后用户可获得信心。使用ETH2.0的6.4分钟的时间段长度，用户必须等待19分钟才能看到结果，并且需要26分钟才能获得链上结果。具体收据：分片之间的代币迁移
ERC20Token的多功能性使其在如今的以太坊中无处不在。但是，ETH2.0也给Token带来部分逻辑问题。由于智能合约管理所有的Token余额，且智能合约仅存在于单个分片上。因此，分片B上根本不存在来自分片A的Token。但通过一些智能跨分片通信，我们可以在多个分片上部署相同的Token，并允许在分片之间进行Token转移，有效地在Token合约之间建立双向挂钩。解决方案非常简单。在部署Token时，我们将基于ERC20添加两个小附加功能——MigrateSend和MigrateReceive函数功能。借助使用MigrateSend销毁Token并生成收据，其中将包括已销毁的Token和接收的分片。之后，通过调用MigrateSend来销毁一个分片上的Token，然后在另一个分片上调用MigrateReceive来有效地进行Token转移。我们需要在每个分片上重新部署我们的Token合约，但这似乎是值得的。迁移是单向的，至少需要两个跨分片通信的最终确认。因此，我们调用MigrateSend之后大约需要10分钟，“CCT”才可以在接收分片上使用。Yanking
收据是跨分片进行信息传递的一种通用方式。我们可以在收据中放置任何链上信息，甚至包括整个智能合约。Yanking是一种通过将合同的代码存储包含在收据中，从而实现跨分片合同迁移的提议。合约将从分片A中删除，然后在收据到达之后在分片B上重新部署。合约一旦进入分片B，其可以直接与分片B合约进行通信，并且与分片B的状态进行交互。同时，该合约甚至可以被Yank回至分片A。这将允许任何一个智能合约与任何其他智能合约进行通信。但由于收据包含整个合约及其所有存储，因此转移大型或用户体量大合约的成本会很高。收据在运输过程中，合约将完全无法使用。其已从分片A中抽出，但尚未到达分片B。这意味着所有其他用户均无法使用该合约，直到其到达分片B。同时，只有已在分片B上的用户才能与之进行交互。因此，Yank最适合用户很少的小智能合约，它使紧密耦合的执行成为可能，但并非是通用的解决方案。分片配对
我们转而谈谈一些更具创意的构建想法。收据旨在使异步通信成为可能。但我们也可能需要同步通信。为此，我们必须更有创意。通过一个简单设计，分片配对可以实现在紧密耦合执行的同时，尽可能地将麻烦最小化。分片配对是一个简单的解决方案。在文章的第三段中就已经提到，我们在每个高度将分片混合成同步对。每次一个分片与另一个分片进行配对时，任一分片的用户都可以跨越这两个分片执行紧密耦合的状态更新。如果分片A和B在高度7处配对，则A和B的所有验证者必须知道A和B的全部状态，并且分片必须一起前进或根本不前进。在此模型中，如果A和B之间需要进行跨链交易，则需要等待A和B随机配对。但是Vitalik描述了100种分片案例。存在1024个分片，我们预计其需要512个区块，因此大约需要一个小时。但由于配对是随机的，它可能需要更长或更短。正如Vitalik所说，当你想要与多个分片进行交互时，这种扩容性并不好。分片区域
这是分片配对的更广泛版本。每个时间段，我们将分片分成几个由多个分片组成的“区域”。区域内的分片必须同步进行，因此需要共同更新其本地状态。通过同步进行，区域保证了分片之间的自由移动，以及与区域中的任何合约直接交互，但与区域外的任何分片进行通信则没有任何优势。此外，由于区域需要验证者知悉区域中所有分片的状态，会导致其否定分片的许多扩容优势。假如一个区域由16个分片组成，则牺牲约15/16的扩容优势，仅获得总网络的15/1024的紧密耦合的执行。产权负担
跨分片通信的一个不明显的特性是，用户可以比所涉及的链更快地获得对消息的信任。Alice从分片A向分片B发送5BETH，其知道这些资产会在发送后立即到达。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计划和进度。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。