以太坊進化的最后夜晚程序員的ETH20指

　　以太坊进化的“最后夜晚”：程序员的ETH2.0指南

　　近日，“以太坊君士坦丁堡分叉”成为区块链技术领域热门话题，而作为以太坊的计划替代方案，真正的“硬菜”——ETH2.0也将逐渐揭开面目抛开对于枯燥术语定义的解读，James Prestwich讨论下当前的以太坊路线图同时，他脑洞大开，在这些具体讨论中假想关于以太坊后期阶段可能方向文章来自Medium，以下为编译全文

　　ETH2.0是什么

　　ETH2.0是以太坊的计划替换方案在接下来的几年里，ETH2.0的开发者们打算将现在以太坊的共鸣系统以及状态完全纳入其中由于其范围如此广泛，我们也无法准确地转达出ETH2.0将会包含或不包括的具体内容确切，我们已建构部分切实可行的操作规范，同时也有相当多的团队力量致力于开发初期的实现ETH2.0开发者暂时计划包括分片技术（Sharding）、Casper协议、状态租赁（State Rent）、以太坊虚拟机EVM的升级项目eWASM

　　如今，ETH2.0初始客户端已上线测试，并预计在三个月内（2019年第一季度）推出轻量级ETH2.0测试络首先，ETH2.0会让以太坊链中的以太币映射过去，但ETH2.0设计者最终计划通过将ETH2.0成为主链，而Ethereum 1.X则是其管理下的分支链来改变这种局面

　　对工程师意味着甚么

　　如果你是专业的Solidity程序员或Dapp开发人员，并且是部署ETH2.0智能合约“铁杆粉丝”那末，你可能需要进行大量的更新迭代ETH2.0是以太坊的完全替代品，其将推翻我们在编写智能合约时所做的诸多假设其计划的多年阶段性推出并不像是升级周期，更像是一个产品发布周期我们为ETH1.X编写的工具和智能合约或需要推倒重来幸运的是，我们有几年的时间来建构这个生态系统

　　为了推动这项工作，我打算讨论下当前的路线图，并介绍一些工程上的影响

　　分阶段推出

　　目前，分片路线图（ETH2.0路线图的两倍）列出了七个阶段只有阶段0有明确的规范，并定期更新阶段1规范的严格性、准确性要低很多，且可能处于消极的开发状态从阶段1后，路线图转变为目标列表，而不再是技术文档

　　举个例子，在阶段2中，路线图链接到的次数是链接到Github的三倍由于未来的任何一步都更像是推测，而不是工程，因此我们的具体讨论仅限于阶段0、1、2同时，在这些具体讨论中也触及几个关于后期阶段可能方向的粗略轮廓概述

　　阶段0:信标链（The Beacon Chain）

　　阶段0引入了“信标链”，（Odaily星球注：信标链是一条全新的区块链，并且在新的以太坊中占据核心位置这条链承当的其中一个职能是让验证者可以参与质押系统、替换矿工的角色而成为链的构建者另一个职能是存储分片状态的索引）ETH2.0设计者希望信标链能够成为ETH2.0生态系统的核心，成为其他分片的安全和验证的根源信标链部署终了后，将使用PoW/PoS混合机制的Casper the Friendly Finality Gadget（Casper FFG）进行股权证明

　　明显，像“信标链”的这种早期迭代在设计之初就尽可能简单，这也是阶段0其实不支持智能合约、账户、资产转移，也不包括任何分片的缘由同时，基于信标链上的以太币也无法实现链上转移，这意味着用户不能将其存入交易所

　　BETH：新的以太币

　　作为一种新资产类型，Beacon ETH（BETH）仅由信标链上的Stakers（持币者或用户）使用BETH能够以下两种方式创建

　　作为验证信标链的奖励（和阶段1之后的分片）；

　　任何ETH1.X用户可以通过ETH1.X合约购买1个ETH的BETH，合约将其称为“存款/充值“（Deposit）

　　工程师可能会注意到，合约内并未提到撤消功能这是由于阶段0，用户无法从信标链中撤回BETH也就是说，用户一旦在存储在ETH1.X验证者注册合约中，ETH1.X以太币则被烧毁信标链验证者会视察该合约，并向信标链提交充值信息，信标链将向充值用户发行新的BETH

　　因此，在ETH发送给验证注册合约不久，用户便会收到信标链发布的对应数量的BETH这一过程中，可以对充值进行临时审查，但根据Casper协议规定，不能对其进行永久性审查

　　1直到阶段2，以太币才能够在信标链上进行传输在我看来，在ETH1.X没有完全融入分片生态系统之前，没有任何办法可以将BETH移回ETH1.X鉴于阶段0其实不完整，且不存在可靠明确的阶段1规范，因此可以合理的假设：BETH作为独立切不可转让的资产类型至少还需两年当阶段2完成，BETH实现分片转移自然“瓜熟蒂落”，但ETH却不会，而这并不会造成不可逆的经济困难

　　过去，一些类似BETH这类低功能的Token项目已通过IOU（欠条）在交易所进行交易例如，在Tezos众筹期间，其就曾推出HitBit和BitMEX XTZ期货市场因此，若是对BETH存在需求，我们应当致力于构建一个支持受托管BETH的交易和入股（Staking）的交易所生态系统然而，用户当下对BETH的需求或许存在怀疑由于从ETH到BETH的单向挂钩导致BETH价格上限为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计划和进度

　　以太坊本日价格以太坊浏览器君士坦丁堡之战以太坊区块浏览器以太坊价格走势eth 君士坦丁堡城墙以太坊价格以太坊行情以太坊官查询君士坦丁堡战役君士坦丁堡的陷落以太坊钱包1453——君士坦丁堡之战以太坊最新价格eth 200以太坊钱包imtoken