ETH2.0是以太坊的计划升级方案。在接下来的几年里，ETH2.0的设计者们计划完全革新以太坊的共识系统，并引入以太坊现有的世界状态。由于涉及面极广，我们也无法准确地说明ETH2.0将包括或者不包括哪些内容。ETH2.0的研究已经有一定的规模了，有不少团队致力于早期实现。目前，ETH2.0设计者暂时计划的工作有分片，Casper，状态租金以及eWASM虚拟机。初代客户端测试正在进行中，并且预计在三个月内推出功能更精简的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计划分多个阶段推出，与其说是系统升级，更像是产品发布。为了帮助推动这一计划，我想讨论一下当前的研究路线图并介绍一些工程进展。
分阶段推出
目前，分片路线图已经列出了七个阶段。只有第0阶段有详实规范，并且能收到定期更新。第1阶段的规范相比之下就没那么清晰了，而且它似乎还没有进入积极的开发阶段。第1阶段后的路线图变成了目标列表而不再是技术文档。例如，在第2阶段，路线图链接到ethresear.ch的次数是其链接到github的三倍。因为任何更进一步的内容都更像是推测，而不像是工程，因此我们具体讨论的内容只有第0阶段，第1阶段以及第2阶段，不过我们还将简单讨论一些后期阶段的可能方向。
第0阶段-信标链
第0阶段引入了“信标链”。ETH2.0设计者希望信标链未来成为ETH2.0生态的中心，成为所有其他分片安全和验证的根源。一旦部署好，信标链将使用CasperFFG算法运行权益证明。信标链的早期迭代被设计得尽可能简单，因此第0阶段不支持智能合约，账户，资产转移，同时也没有包含任何分片。信标链上的ETH无法在链上转移，这意味着用户无法将其存放在交易所。
BETH：新以太
信标ETH是一种只能由stakers在信标链上使用的新资产。其通过两种方式产生：1）作为验证信标链的奖励，2）任何ETH1.X用户可以通过ETH1.X合约使用1ETH购买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以及BitMEXXTZ期货市场。如果对BETH有相应需求，我们期待看到一个充满活力且支持BETH交易和质押的交易所生态系统。然而，看起来不太可能有这样的需求。因为BETH是一个不良投资，从ETH到BETH的单向挂接给了BETH一个价格上限。这意味着BETH不可能比ETH更值钱，而只会比ETH更廉价。
第0阶段+——Staking
用户可以通过在信标链上质押32BETH成为验证者。在第0阶段，验证者将只能管理信标链。从第1阶段开始，验证者还将管理1024个分片链。信标链将使用CasperFFG来确定最终区块。FFG是一种权益证明算法，可以罚没恶意行为参与者的权益。精明的读者们会注意到“以太坊3.0”分片路线图中的CasperCBC可以说是FFG的堂兄——虽然完整的讨论FFG超出了这个帖子的范围，但是我真心推荐大家阅读一下Vitalik关于PoW/FFG混合共识的说明，他关于最少罚没条件的帖子以及FFG论文
Staker是做什么的？
分片的目的是在节点之间拆分状态信息，而不需要任何节点掌握网络全貌。因此没有验证者可以验证所有分片。相反，信标链将协调分片的验证工作。每个轮次，信标链将对验证者进行混洗，并将他们分配给一个分片。分配到一个分片的一组验证者被称作委员会。委员会由128名成员组成。在第0阶段，这意味着每6分钟信标链就会重新混洗、选取一次，选出下一个六分钟里承担职责的委员会。在第1阶段，信标链将为1024个分片分别指定一个验证者委员会。这个方法看起来思路清晰但是实现十分复杂。它涉及多阶段随机数生成以及可验证的延迟函数，以进一步阻止操控委员会选择的企图。
由于委员会的工作十分重要，ETH2.0随机选择委员会并且时常轮换委员会。委员会负责保证它们所在分片的安全性、活性以及完整性，并负责证明信标链上的分片状态。它们是信标链可以获取分片状态的唯一方式，反之亦然。随机地从验证者池中选择组成委员会的验证者可以最大限度地减少整个委员会撒谎的可能性。时常轮换委员会可以减轻恶意委员会可以造成的伤害。换句话说，对恶意验证者以及试图使自己利益最大化的验证者来说，很难将委员会选择作为攻击网络的工具。此外，如果他们偶然获得了对分片委员会的控制，他们的控制无法超过64个区块。
给工程师的权益证明说明
尽管总结ETH1.X的工作量证明以及ETH2.0权益证明之间的差别仍在持续进行中，但需要提醒的是，一些PoW/PoS特性的差异确实直接影响到了工程师。例如，PoW链支持无状态SPV验证以及工作量证明的非交互证明——总的来说就是远程状态跟踪，而PoS则禁止任何无状态通信。因为弱主观性使我们无法实现关于状态的轻量级证明。换句话说，权益证明中的远程状态证明将包含与PoW无状态SPV证明大致相同的数据量，但是需要先验证整个PoS历史。相反，无状态SPV证明不需验证其他信息。这意味着在主观的权益证明环境中，跨分片或者跨链应用减少了功能且增加了开销。
第1阶段——分片
第1阶段旨在对分片链的内容建立共识。换句话说，这是对分片结构的实验性运行，而不是尝试用分片进行扩展。信标链将分片的区块视为没有结构或意义的简单比特集合。分片链目前还没有账户，资产或者智能合约。信标链在每个时间段为每个分片随机选择的分片验证者，只负责对每个区块的内容达成共识。至于分片的区块中有什么样的信息是无关紧要的，只要所有的委员会成员能在分片上定期地达成共识并更新信标链就可以。
分片的验证者通过交联的过程去验证分片的内容和状态。简单地说，委员会成员必须在信标链上写入关于分片的可验证信息。在第2阶段或者之后，交联可以支持跨片通信。一旦信标链已经从多个委员处收到了给定交联准确性的证据，那么信标链就可以信任这个交联是这个分片的真实表示，而不用去验证整个分片。如果委员会成员不能对交联的有效性达成共识，那么，肯定有委员会成员是错误的，应该被罚没。所有分片的安全性根基是：验证者的不端行为最终会被信标链发现并给予处罚。
第1阶段没有什么特别有趣的东西。从根本上说，这是一个用于交联和分片引用信标链的对称机制的引导启动阶段。设计者似乎很自信这些机制能行得通。主要的开放性问题都是围绕着规范和实现策略。考虑到第0阶段花了大约一年多的时间才形成一个像样的规范文档，我预计第1阶段要用的时间也差不多。有趣的是，第0阶段的实现是和规范同时进行的。从测试网络发布至今不到三个月的时间，第0阶段的规范还在经常变化。这意味着，将来ETH2.0的各个阶段在开发时也会有很大的变数。虽然乐观主义者告诉我6个月的时间就够，但是很容易看出，第0阶段进入测试之后，第1阶段需要12-18个月的开发时间。
第2阶段——智能合约
第2阶段最终会带来一个类似Ethereum的系统。伴随着第2阶段的发行，分片链从简单的数据容器过渡到结构化的链状态。从这一阶段开始，系统会重新引入智能合约，BETH也会变成可以转让的资产。每个分片会管理一个基于eWASM的虚拟机。我们希望EVM2可以支持账户，合约，状态这些我们在Solidity中熟悉的抽象概念。但是大量的后台更改可能会破坏大多数现存的工具。不过还好，eWASM团队已经为solc，truffle和ganache做了一些基础工作。我们预期在第2阶段的测试网之前或者在这期间，大多数常见的工具会被移植去支持EVM2。
状态租金，很有可能包含在第2阶段中，给现在的Solidity工程师提出了一些有趣的挑战。状态出租将要求合约开发者和用户随着时间的迁移为EVM2的存储付费，而不是无期限存储代码和数据。通过确保未使用的信息随着时间的推移移出状态，可以防止状态数据膨胀。这个设计的目标是让用户而不是全节点为状态的花销买单。现在已经提出了很多不同的模型，但是还不确定采用哪种方案。
有趣的是，从一些以太坊升级计划和著名的以太坊核心开发者的推荐来看，状态租金可能是不同的路线图中唯一重叠的部分。因此我强烈建议先计划让当前部署的合约支付状态租金，并设计模型以便将来把状态租金转移到用户身上。我们不知道状态租金的具体设计，但是我们应该做计划。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。