本文的原作者是连锁和跨连锁金融服务商Summa的创始人James Prestwich。本文由洒脱和Apatheticco编译.
特别感谢Nic Carter在PowerPoint上制作了这张有趣的图片
以太坊2.0是以太坊的计划替代品。在接下来的几年里，邰方2.0的设计者打算完全整合邰方的共识系统和状态。因为以太坊2.0的范围太广了，我们无法确切说出它会包括什么，不会包括什么。我们确实有一些关于以太坊2.0的规范，很多团队都在致力于早期的实现。此时，以太坊2.0的设计师们正在临时规划设计，包括切片、Casper、状态租赁和eWASM虚拟机。的初始客户端测试正在进行中，预计开发者将在三个月内(2019年第一季度)推出轻型以太坊2.0测试网络。起初，以太坊2.0会从以太坊主链获取以太坊，但设计师最终计划让以太坊2.0成为主链，而以太坊1。x将是其管理下的碎片链。
如果你是Solidity或者Dapp开发者，想要部署以太坊2.0智能合约，那么你将需要学习很多东西。以太坊2.0完全取代以太坊，将改变我们在写智能合约时所做的很多假设。以太坊2.0的计划推出计划是多阶段的，更新是产品发布周期，不是升级周期。我们为以太坊1编写的工具和智能合约。x可能需要针对以太坊2.0重新设计重写。幸运的是，我们有几年时间来准备生态系统。为了帮助您实现这一目标，我想讨论一下当前的路线图，并介绍一些工程影响。
目前切片路线图列出了7个阶段(以太坊2.0路线图的2倍)。其中只有0期(Phase 0)有实质性的规范，会定期更新。而第一阶段(Phase 1)规范的精度要低很多，似乎也没有积极开发。在第一阶段之后，路线图就变成了目标列表，而不是技术文档。比如第二阶段(Phase 2)，路线图链接到ethreaser.ch的次数会是github的三倍。因为任何进一步的讨论似乎都是推测，而不是工程，所以我们的具体讨论仅限于0阶段、1阶段和2阶段，并且我们已经包含了一些后期可能方向的大致轮廓。
接下来，我们将介绍各个阶段的发展状况。
阶段0介绍“信标链”。以太坊2.0的设计者希望将信标链打造成以太坊2.0生态系统的中心，成为其他所有碎片的安全和验证的根源。一旦信标链被部署，它将运行卡斯珀FFG，一个PoS机制。信标链的早期迭代被设计为尽可能简单，这就是为什么Phase 0不支持智能合约、账户、资产转移，并且不包括任何碎片化。信标链上的以太坊不能在链上转移，也就是说用户不能存放在交易所。
信标ETH(BETH)是信标链上被验证者使用的唯一新资产。它是通过两种方式创建的：1)作为验证信标链(以及阶段1后的切片)的奖励，2)任何以太坊1.x的用户都可以通过以太坊1.x合约购买贝丝。合同称之为“保证金”。工程师可能会注意到合同没有取消功能。这是因为在阶段0中，我们不能将BETH从信标链中撤出。也就是说，一旦存储在以太坊1.x验证者注册契约中，以太坊1.x以太坊将被有效烧毁。信标验证者检查合同，并将存款信息提交给信标链，信标链将向存款者发出新的BETH。所以我们的目标是：存款人将Taicoin发送给验证者注册合同后不久，就会收到信标链发出的相应BETH号。 对存款进行临时审查是可能的，但根据Casper的规则，永久审查不太可能发生。
以太坊在信标链上的传输需要等到Phase 2(第二阶段)。我相信我们不会有任何办法让贝丝回到以太坊1。x直到以太坊1。x完全被折叠进了碎片化的生态系统。鉴于0阶段的不完全性和缺乏可靠的1阶段规范，我们可以合理假设贝丝作为一项独立且不可转让的资产的时间将至少持续2年。一旦第二阶段完成，贝丝将能够转移到或从碎片；然而以太坊不会。这不太可能造成严重的经济困难。
以前很多交易所都是通过IOU (IOU)提前交易像BETH这样的token。比如Tezos众筹期间，Hitbit和Bitmex交易所推出了相应的期货市场。如果市场上有贝丝的交易需求，我们可能会看到一些交易所会支持贝丝的托管交易和投资。但是，贝丝的市场需求似乎存在一些问题。由于ETH和BETH单向1:1联动，BETH有一个最高价，不是一个好的投资标的。换句话说，贝丝的价值永远不可能超过以太坊，可能低于以太坊。
用户可以在信标链上下注32 BETH，然后成为验证者。在阶段0中，验证者将只管理信标链。从第一阶段开始，验证者还将管理1024个碎片链。信标链(和每个片段链)将使用卡斯帕FFG机制来确定阻塞。Casffg是一个惩罚链暂停、审查等不良行为的PoS算法。敏锐的读者会注意到FFG的“表亲”，Casper CBC，被列在碎片化路线图的“以太坊3.0”部分。(对FFG和CBC的全面讨论超出了本文的范围。我建议你读一下Vitalik关于混合粉末和FFG的笔记，以及他关于最小化切割条件的文章和FFG论文。
分段的目的是在节点间划分状态信息，没有任何节点具有网络的完整图像。因此，没有验证者会验证所有的片段。相反，信标链将协调所有其他片段的验证，并且所有验证器将验证该信标链。每个时间段(64个块或6.4分钟)，信标链将洗牌验证器并将其分配给一个片。分配给一个切片的一组检验员称为委员会。委员会将有128名成员。在阶段0中，这意味着每6分钟，信标链将选择可用的验证器，并在接下来的6分钟内组成一个委员会。在第一阶段，信标链将为1024件产品指定一个验证委员会。确切的方法很复杂。它包括一个多阶段随机数生成过程和一个可验证的延迟功能，以进一步挫败操纵委员会选择过程的企图。
以太坊2.0随机选择委员会，关键工作经常轮换委员会。每个委员会负责维护其碎片的安全性、活动性和完整性，并证明信标链上的碎片状态。它们是信标链了解碎片状态的唯一方式，反之亦然。从所有核查人员中随机选择他们可以最大限度地减少整个委员会撒谎或作弊的可能性。而轮换他们往往是为了减轻一个不好的委员会可能带来的伤害。换句话说，一个怀有恶意或追求利润最大化的验证者很难成为委员会的成员，并对网络发起攻击。另外，即使他们有机会控制一个切片委员会，控制时间也不会超过64块(6.4分钟)。工程师的
虽然以太坊1.x的工作量认证(PoW)和以太坊2.0的股权认证在哲学上的差异是一个持续的过程，但是值得注意的是pow/pos特性的一些差异确实会直接影响到工程师。例如，虽然PoW chain支持NiPoPow总结的无状态SPV证明和远程状态跟踪，但PoS禁止任何低状态通信。主观性阻碍了光状态认证。 换句话说，PoS的远程状态证书将包含与POW的无状态SPV证书大约相同的数据量，但是需要预先验证整个PoS历史。相反，无状态SPV证明不需要其他信息来验证。这意味着在主观PoS环境中，交叉切片或交叉链接会减少功能并增加管理开销。
阶段1的目标是对碎片化链的内容达成共识，而不是对其含义达成共识。换句话说，这是一次碎片化结构的试运营，而不是试图通过碎片化来扩大容量。信标链会将碎片链视为一组没有结构或意义的简单比特。链中没有帐户、资产或智能合约。验证者由信标链在每个周期为每个段随机选择，它们只是对每个块的内容达成一致。只要所有委员会达成共识，并定期更新瓦片上的信标链，瓦片中出现的信息就不重要。
片段验证程序通过称为交联的过程来验证片段中的内容和状态。简而言之，委员会必须在信标链中包含关于片段(如merkle root)的可验证信息。在第二阶段或更高阶段，交联将支持跨碎片化通信。一旦信标链从多个委员会接收到特定交叉链接的准确性证据，信标链就可以相信该交叉链接是该片段的真实代表，而无需验证整个片段。如果委员会不同意交联的有效性，显然这个委员会是错误的，应该受到惩罚。这是所有碎片化的安全根源：验证者的错误行为最终会被发现，会受到信标链的惩罚。
阶段1没有什么特别有趣的东西。从根本上说，它是一个交叉链接的引导阶段，也是一个片段引用信标链的对称机制。设计者似乎相信这些机制会起作用。主要的公开问题集中在规范和实现策略上。考虑到0期用了一年左右的时间才达到合理的标准水平，我觉得1期用的时间也差不多。有趣的是，阶段0的实现与规范一致。即使在以太坊2.0测试网发布不到三个月的今天，0期规范也会定期更改。这意味着以太坊2.0未来的发展时间将会大不相同。虽然乐观主义者告诉我需要6个月的时间，但是我们可以很容易地预测，在0期测试之后，1期还需要12-18个月的时间才能开发出来。
第二阶段最终会给我们带来一个我们熟悉的类似以太坊的系统。随着第二阶段的发布，碎片链将从简单的数据容器过渡到结构化的链状态。届时，BETH将是可转让的，智能合约将被重新引入。每个切片将管理一个基于eWASM的虚拟机(我们称之为“EVM2”)，我们希望EVM2能够支持账户、合同、状态等我们在Solidity中熟悉的抽象内容。然而，大量的幕后变化可能会破坏大多数现有的工具。幸运的是，eWASM团队为solc、truffle和ganache做了一些基础工作。我们可以期待在第二阶段测试网络启动之前或期间看到一些熟悉的工具移植到EVM2。第二阶段很可能出现的
状态租赁(State lease)对当前的Solidity工程师提出了一些有趣的挑战。Lease将要求合同开发者和用户在一段时间内支持EVM2存储费用，而不是无限期存储代码和数据。这可以通过确保未使用的信息随着时间的推移离开状态来防止状态扩展。目标是让用户(而不是整个节点)支付状态成本。开发人员提出了许多不同的模型，但目前没有明确的赢家。
有趣的是，随着一些以太坊升级计划的发布，以及优秀的以太坊核心开发者的推荐，状态租赁可能是不同路线图中唯一重叠的部分。 因此，我强烈建议在当前部署的合同中包含对状态租赁的支持，并设计一个模型，以便将来可以将状态租赁传递给用户。我们不知道国家租赁的确切设计，但我们应该为成本做好计划。
另外，我们也不知道第二阶段会发生什么。目前还处于前期研究阶段，包括几大未解决的问题。考虑到非正式的规范和开发流程，以及二期在一期的拓展范围，二期在2020年前落地的可能性似乎不大。也就是说，虽然以太坊2.0可能会在今年推出，但至少在2020年之前，我们不应该指望以太坊2.0支持资产转移或智能合约。
为了讲述更多与智能合约相关的问题，我们将简要提及阶段3的内容。阶段3:通过尽可能多地将状态转移到链上，尽可能地减少链上的状态。链存储的不是整个状态，而是一些状态信息和聚合器(聚合器是代表长数据列表的短数据；Merkle树是一种聚合器)。用户将负责存储链下的完整状态。当用户希望与状态进行交互时，他们会在事务中包含当前状态的证明。这样，运行验证节点的资源需求可以低得多。现在有一些聚合器的设计，有不同的特点和性能特点，但还没有具体的选择。在这个阶段，我们停止使用链式通信来协调用户，因此我们必须计划通过其他系统来同步状态。链上的事件对工程师来说用处不大，因为链不再能保证数据的可用性。在第三阶段，保持和获取离线状态将是限制dapp设计的关键因素。
然而，一个不可克服的问题仍然存在：ETH2.0合约虽然会像以太坊合约一样强大，但它必然会绑定到一个shard上，无法与另一个shard上的合约直接交互。这是碎片化的直接结果。分片的目的是将状态拆分，放在不同的分片中，不需要直接知道其他分片。它通过划分状态来扩展容量，尽可能地减少验证者的工作量。直接的互动需要直接的知识。但是，根据设计，一个片段没有其他片段的直接知识。它仅通过与信标链的交叉链接通信来了解其他片段。因此，每当我们想要跨分片交互时，我们必须等待信标链。具体来说，这意味着如果SafeMath部署在shard A上，shard B上的用户将不得不等待一段时间才能访问它，或者在shard B上部署新的safe math。
safe math之类的简单实用程序将部署到——1024个shard中的每个shard，其中有1024个SafeMath3354，但Maker或Compound之类的市场呢？#DeFi可组合金融的目标在跨越碎片化的边界时是非常具有挑战性的。CDP激活和DAI收集之间的长延迟将导致不可接受的经济损失。如果市场发生变化，CDP在用户收到DAI之前被清算，怎么办？在实践中，这可能意味着用户需要在包含智能合约的每个分片上拥有一个帐户，跨分片结构完全没有用。只有当Maker和0x都部署在同一个shard上时，它们才能交互，并且0x用户在shard上也有资产。
ETH2.0设计师不知道片间通信系统最后会是什么样子。阅读了许多提案后，似乎在即时反馈和可预测性之间有一个基本的权衡。碎片化的本质不会改变：用户无论如何都要等待跨碎片化的交流。但是，我们可以将事务的本地和远程执行阶段紧密或松散地耦合到每个片上。
紧耦合优先等待。在碎片通信之前，事务不执行任何操作。相比之下，我们可以通过先执行部分，后执行部分来松散地耦合事务。 事务在本地片上执行，然后在跨片通信后在远程片上执行。松耦合为用户提供了更好的体验。他们可以立即看到他们的事务是在本地执行的，并且知道它们是远程的。执行将在未来的某个时刻发生。不幸的是，他们无法在不需要等待的情况下知道松散耦合交易远程阶段的结果。紧密耦合的交易更具可预测性。用户更了解结果，因为远程状态不会在本地和远程执行阶段之间转换。但是，紧耦合需要用户在看到任何结果之前等待。
我们关于ETH2.0通信模型的信息非常少。我们知道它不能在不牺牲几乎所有扩容优势的情况下提供跨分片合约调用。如果你在这里停止阅读，我不会责怪你，因为第4阶段只有思维导图和一些模糊的链接。这种情况的一个非显性的结果就是，ETH2.0在第4阶段之前不会为复杂的智能合约系统带来明显的扩容优势。在此之前，希望与其他合约交互的智能合约必须与一个分片共存，并且受限于那个分片的速度和扩容效果。与ETH1.X相比，我们预计分片最多只能获得一个小的常数因子的加速量。这意味着在第4阶段发布（2025年左右）之前，几乎没有理由将智能合约代码或用户迁移进来，因为优势很小。与此同时，为了更好地理解工程师和dapp用户的权衡，我研究了一些社区或者开发者建议的模型。我认为这些都不会被采纳，但我相信它们有助于理解这里所涉及的权衡。再说一遍：接下来所有的内容都是推测性的。
所有形式的跨链通信都利用了信标链。因为信标链可以检索所有分片的状态，并且每个分片会影响信标链的状态，所以我们可以将它用作分片链生态系统中的中心。消息从某个链到另一个链在某种意义上必须通过信标链传输。我们不会想要发送完整的消息，因为这需要信标链来处理每个交易本身，完全无法实现扩容的效果。
相反，每当分片A上的用户或合约想要与分片B交互时，我们都会让分片 A生成带有该消息的“收据”。分片A在其区块头中提交其所有收据。信标链等待A最终确认，然后提交到A的区块头（包括对收据的提交）。分片B必须等待信标的最终确认，然后提交到信标区块头。这时，可以向B提交新的交易，包含收据和证明。证明显示收据包含在A中，A包含在信标中，并且信标包含在B中。这样，B上的合约可以信任从A发送的消息。如果B上的合约想要发送回复（返回值或错误），我们反过来重复整个过程：分片B发出一个收据，最终收据一路到分片 A。
很容易理解为什么这个过程需要花费很多时间。四个通信步骤中的每一个都需要等待几分钟才能完成！不幸的是，我们完全无法避免等待。如果我们想确定远程状态，那么我们必须在每一步都等待最终结果。往返通信的最佳情况是四个最终确认周期。也就是说，用户可以在三个周期后获得信心，因为用户可以在分片尚力财经小编2022 A看到分片B的收据之前看到它们。使用ETH2.0的6.4分钟时间段（epoch）长度，用户必须等待19分钟才能看到结果，并且需要26分钟才能获得链上结果。
ERC20代币的多功能性使它们在今天的以太坊中无处不在。但是，ETH2.0给代币带来了一些逻辑问题。因为智能合约管理所有代币余额，并且智能合约仅存在于单个分片上，所以分片 B上根本不存在来自分片 A的代币。但是，通过一些聪明的跨分片通信，我们可以在多个分片上部署相同的代币并允许在分片之间迁移代币——有效地在代币合约之间建立双向挂钩。
该方案非常简单：在部署代币时（让我们称之为“酷酷的跨分片代币”或“CCT”），我们将使用ERC20添加两个小的附加功能：migrateSend和migrateReceive函数。我们将使用migrateSend销毁代币并生成收据。收据将包括已销毁的代币数和接收的分片。我们将使用migrateReceive验证收据并生成相同数量的CCT。然后我们将在每个分片上部署相同的代币合约。现在我们可以通过调用migrateSend来销毁一个分片上代币，然后在另一个上调用migrateReceive来有效地生成代币。我们需要在每个分片上重新部署我们的代币合约，但这似乎是值得的。迁移是单向的，至少需要两个跨分片通信的最终确认。因此，在我们调用migrateSend之后，将在我们的CCT在接收分片上可以运行之前大约需要10分钟尚力财经小编2022。
收据是跨分片传递信息的一般方式。我们可以在收据中放置任何链上信息。这包括整个智能合约。 Yanking是一种通过将合同的代码和收据中的存储信息囊括在内来跨分片迁移合约的提议。合约将从分片 A中删除（yanked），然后在收据到达之后在分片B上重新部署。一旦该合约在分片B上了，它可以直接与分片 B的合约进行通信，并与分片 B的状态进行交互。它甚至可以被yank回分片 A。
这将允许任何一个智能合约与任何其他智能合约进行通信（在跨分片等待时间之后）。很遗憾，由于收据包括整个合约及其所有存储，因此迁移大型或者用户量大的合约花费会很高。收据在传输过程中，合约完全无法使用。它已从分片 A中抽出但尚未到达分片B。这意味着所有其他用户都无法使用该合约，直到它到达分片 B。而且，只有已经在分片 B上的用户才能与之交互。因此，yanking最适合用户很少的小合约。它使紧密耦合的执行成为可能，但远非通用的解决方案。
从这里我们转而谈谈更有创意的一些构建想法。收据旨在使异步（松散耦合）通信成为可能。但是，我们也可能想要进行同步通信。为此，我们必须更有创意。分片配对是一个简单的设计，可以让我们在进行紧密耦合执行时为我们带来尽可能小的麻烦。
碎片配对是一个简单的方案。在这篇文章的第三段中我们讲到过，我们在每个高度将分片排序成同步对。每次一个分片与另一个分片配对时，任一分片的用户都可以跨越这两个分片执行紧密耦合的状态更新。这意味着如果分片A和B在高度7处配对，则A和B的所有验证者必须都知道A和B的所有状态，并且分片必须一起前进或根本不前进。在此模型中，如果你需要在A和B之间进行跨链交易，则需要等待A和B的随机配对。但是Vitalik提出了100分片的情况。有1,024个碎片，我们预计它需要512个区块——大约一个小时——但由于配对是随机的，它所需的时间可能更长或更短。正如Vitalik所说，当你想要与多个分片交互时，这种扩容效果很差。
这是配对的更广泛版本。每个时间段（epoch）我们将分片分成几个由多个分片组成的“区域”。区域内的分片必须同步进行，这意味着区域中的所有分片一起更新其本地状态。通过同步进行，区域保证了分片之间的自由迁移，以及与区域中的任何合约的直接交互，但与区域外的任何分片进行通信则没有任何优势。此外，由于区域需要验证者来了解区域中所有分片的状态，因此它们否定了分片的许多扩容优势。如果一个区域由16个分片组成，我们牺牲了大约15/16（= 94％）的扩容优势，同时获得总网络15 / 1,024（= 1％）的紧密耦合执行。
跨分片（和跨链）通信的一个非显性的特性是，用户可以比所涉及的链更快地获得对消息的信任。Alice从分片 A向分片 B发送5 BETH，知道它会在发送后立即到达。Bob看到交易的发送，知道一旦发送到分片 A上确认，BETH将到达分片 B。然而，分片 B及其合约必须等待几分钟才能使信标链对分片 A的最终确认进行最终确认。这意味在资金于分片A上花费以后，一个钱包可以很快在分片 B上接收和花费这些资金。换句话说，Bob将从分片 B上的Alice的钱包中获得可执行的IOU（欠条），因为Bob很有信心Alice已经发送了足够的ETH。如果分片B足够多的用户愿意观察分片 A并接受标准化的IOU，那么分片 A ETH可能会在发送后很快在分片 B上花费。然而，当应用于智能合约时，这种方案变得异常复杂，因为状态是不可替代的，所以状态的欠条是不可能实施的，故而它不适合通用交互。这意味着我们应该将产权负担视为松散耦合中的用户体验改进。它允许松耦合模拟紧密耦合，快速执行某些交易。
更复杂和更让人感兴趣一种方案是将共识过程和状态更新过程分离。当前以太坊矿工和完整节点只有在执行了区块中包含的所有状态更新后才接受区块。其实不必这样。相反，他们可以先接受区块，稍后更新状态。在这种情况下，我们不会像在以太坊中那样就系统状态达成共识，而是会对所有分片中所有交易的总历史（或“总顺序”）达成共识。这样做意味着每个分片都可以快速添加区块而无需知道任何其他分片的状态，这就是怎么样用分片扩容的原理。但是，在所有分片完成之前，交易对分片状态和整个网络的影响将不会被知道。换句话说，状态的最终确认落后于分片内容的最终确认。
从用户的角度来看：我们会立即提交交易，并且我们知道它们已被包含在内，但我们必须等待一些时间来确定该交易的结果。随着分片的最终确定，我们逐渐获得上述文章内容就是状态的更多信息，但在所有分片达到最终确认之前无法完全确定。与产权负担相似，在某些情况下，用户可以提前确定交易的结果并相应地采取行动。
ETH2.0将是与以太坊完全不同的系统。它们将并行存在多年并具有非常不同的特征集。在不久的将来，我们预计会出现从ETH到BETH的单向挂钩。如果你经营交易所或托管服务，请考虑怎么样在BETH在链上可转移之前支持你的用户进行BETH托管交易和staking（押注）。从长远来看，我们需要考虑智能合约怎么样在有和没有跨分片通信的情况下适应分片。最重要的是，密切关注研发过程。 ETH2.0是一个复杂且不断发展的系统。所有dapp工程师都需要清楚地了解ETH2.0计划和进度。
标签： 谂
微信咨询
