ETH2.0：迷雾重重，以太坊替代品将走向何方？

前言：对很多以太坊投资者来说，ETH2.0都是模糊不清的，甚至对于很多开发者来说，它也不够清晰。那么，作为未来的以太坊替代品，ETH2.0的发展路线图包括哪些内容？有哪些值得我们关注的地方？

作者/James Prestwich

来源/hackernoon

编译/蓝狐笔记

接《ETH2.0:它会是什么？（一）》

阶段4 —— 分片合约

然而，一个不可逾越的问题依然存在：ETH2.0合约。尽管它们跟以太坊合约会一样强大，但注定是一个分片，且永远无法与另外一个分片的合约直接交互。这是分片的直接后果。分片的目标是在分片之间分离状态，而不要求直接了解其他分片信息。

它通过分离状态和最小化各验证者的负载来实现扩展。直接交互需要直接获取信息。根据设计，分片没有其他分片的直接信息。它只通过与beacon链的交联来获得其他分片的信息。因此，每当我们想要跨分片交互，我们必须等待beacon链。具体来说，这意味着如果SafeMath部署在分片A，在分片B的用户要么不得不等待以访问它，要么直接在分片B上部署新的SafeMath。

像SafeMath这样的简单基础程序将被部署到每个分片——1024分片上的1024个SafeMaths——但像Maker或Compound这样的市场呢？#DeFi对可组合金融的承诺变得有挑战，因为要跨越分片边界。在CDP的开放和DAI的收据之间的长时间延迟会导致不可接受的经济损失。万一市场发生变动，在用户收到DAI之前CDP就被清算了呢？实践中，这可能意味着用户将在每个包含引人注目的智能合约的分片上拥有账户，并且完全丢失跨分片组合。只有Maker和0x都部署在同一个分片上时，它们才能进行交互，并且0x用户也在该分片上有资产。

基本权衡：同步或扩展

ETH2.0设计者并没确定跨分片通信系统具体什么样。通过阅读很多提案，它貌似在即时反馈和可预测性之间有一个根本的权衡。分片的本质不会改变：无论如此，用户必须等待跨分片通信。然而，我们可以在每个分片上紧密或松散地耦合交易的本地或远程执行阶段。

紧耦合使得等待先行。在完成分片通信之后，交易才执行操作。相比之下，我们可以通过现在执行部分操作以及后续再执行部分操作的方式实现松耦合交易。交易首先在本地分片上执行，然后在跨分片通信之后在远程分片上执行。松耦合为用户提供更好的样貌。他们立即看到他们的交易在本地执行，同时也知道在未来的某个时刻将会远程执行。不幸的是，他们要想知道松耦合交易的远程阶段结果就必须等待。紧耦合交易更具有可预测性。用户更了解结果，因为远程状态在本地和远程执行阶段之间没有发生切换。但是，紧耦合需要用户在看到任何结果之前等待。

关于ETH2.0的通信模型的信息很少。我们知道除非牺牲几乎所有扩展的好处，不然无法提供跨分片合约调用。如果你在这里停止了阅读，我不会指责你，因为阶段4只有思维导图和一些模糊的链接。

这种情况的一个非显而易见的结果是，在阶段4之前，ETH2.0将不会为复杂的智能合约系统提供重大的扩展好处。在此之前，如合约希望与其他合约交互则必须在一个分片内，且受制于该分片的速度和规模。

与ETH1.X相比，我们预计分片最多只能获得一个小的常数因子加速。这意味着，在阶段4发布之前，没什么理由迁移智能合约代码或用户，也就是可能在2020年中期之前，因为没多大优势。

与此同时，为了更好理解为工程师和DApp用户做的权衡，我研究了一些提案的模型，在这里也有一些简短描述。我认为这些都不会被采用，但我相信它们对理解所涉及的权衡有帮助。再说一遍：下面说的一切都是预测。

基本模型：收据和证明

所有形式的跨链通信都利用了beacon链。因为beacon链提交所有分片的状态，每个分片提交到beacon链的状态，我们可以把它当作是分片链生态系统中的枢纽。一条链的信息转入另外一条链，在某种意义上，必须通过beacon链进行。我们不想发送全部信息，因为这要求beacon链处理每个交易本身，会完全否定扩展的好处。

相反，不管什么时候，分片A上的用户或合约想与分片B的用户或合约进行交互，我们让分片A生成有该消息的“收据”。分片A提交其所有“收据”到区块头。beacon链等待分片A的完成，之后提交到分片A的区块头（包括对收据的承诺）。分片B必须等待beacon链完成最终性，然后提交到beacon区块头。一旦这些完成，新的交易就能提交到分片B，包括收据和证明。证明显示该收据已经在包含在分片A中，A也包含在beacon中，该beacon也包含在B中。通过这样的方式，在分片B上的合约可以相信从分片A发过来的消息。如果在分片B上的合约想发送回复（可能是返回值或错误），我们反过来把过程重复一遍：分片B发出收据，最终回到分片A。

很容易理解为什么这个过程需要耗费时间。四个通信步骤中的每一步都需要等待几分钟才能完成。不幸的是，我们无法完全避免等待。如果我们想确认远程状态，我们不得不等待每一步的最终结果。往返通信的最好情况是四个完成周期。也就是说，在三个周期之后，用户获得信心，因为用户可以在分片A看到之前看到分片B的收据。用ETH2.0的6.4分钟时间周期长度，用户必须等待19分钟才能看到结果，且需要等待26分钟才能获得链上的结果。

具体的收据：分片间的代币转移

ERC20代币的多样性让如今的以太坊无处不在。然而，ETH2.0给代币带来一些逻辑问题。因为智能合约管理所有代币余额，并且智能合约只在单个分片上，在分片A上的代币并不存在分片B上。不过，用一些聪明的跨分片通信，我们可以在几个分片上部署相同代币，允许在分片之间进行代币转移——有效地实现代币合约之间的双向锚定。

这个方案非常简单：当部署我们代币时（称为Cool Cross-shard Token或CCT），我们将使用ERC20添加两个小的附件功能：migrateSend和migrateReceive函数。我们将使用migrateSend燃烧代币，并产生收据。收据将包含被烧掉代币的数量以及接收的分片。我们将使用migrateReceive验证收据，且铸造相同数量的CCT。然后，我们将在每个分片上部署相同的代币合约。

现在，我们可以有效地在一个分片上发起migrateSend请求烧毁，然后发起migrateReceive请求在另外一个分片上铸造相同代币，以此实现分片之间的代币转移。我们需要在每个分片上重新部署我们的代币合约。但这似乎是值得的。转移代币，是单向的，至少需要两个跨分片通信的完成时期。因此，在我们调用migrateSend之后，在我们的CCT在接收分片可用之前还需要花费大约10分钟。

Yanking

收据是跨分片之间移动信息的一般方式。我们可以在收据上放置任何链上信息。这包括整个智能合约。通过在收据中包含合约代码和存储的方式，Yanking是一种跨分片转移合约的提案。合约将从分片A中删除，然后在收据抵达之后在分片B上重新部署。一旦在分片B部署，它可以直接与分片B的合约进行通信，并与分片B的状态进行交互。它甚至能够被拉回分片A。

这将允许任何智能合约跟其他智能合约进行通信（在跨分片等待时间之后）。不幸的是，因为收据包含整个合约和其所有存储，它移动大的或流行的合约成本很高。并且，在收据转移过程中，合约是完全不可使用的。它已经从分片A中抽出但还没有抵达分片B。这意味着所有其他用户在抵达分片B之前都被锁定在该合约之外。即便这样，只有已经在分片B上的用户才能与之交互。因此，yanking最适合用户少的小合约。它使紧耦合执行变得可能，但远非一般解决方案。

分片配对

从这里，我们转向更多异国风情的解释。收据设计的目的在于让异步（松耦合）通信成为可能。但是，我们也可能需要同步通信。为此，我们必须更有创意。分片配对是一个简单设计，可以让我们紧耦合执行最小的事情。

分片配对是简单的方案。在文中第三段描述中，我们在每个高度将分片洗牌成同步对。每次一个分片跟另一个分片配对，任一分片的用户都可以跨越分片执行紧耦合状态更新。这意味着，如果分片A和B在区块高度7配对，所有分片A和B的验证者必须知道分片A和B的所有状态，且配对的分片必须同进退。

在这个模型中，如果你需要A和B之间进行跨链交易，你将要等待A和B的随机配对。Vitalik描述了100个分片案例。有1024个分片，我们预计它花费512个区块——大概1个小时时间——但由于配对是随机但，它可能花费更长或更短的时间。正如Vitalik所说，当你想要与多个分片交互时，它的扩展性很差。

分片区

这是配对方案的更广泛的版本。每个周期我们把分片分配进入一些“区域”，每个区域由多个分片组成。区域必须同步处理，这意味着一个区的所有分片一起更新他们的本地状态。通过同步进行，区域在分片之间提供自由移动，并可与区域内任何合约直接交互。但，与区域外的任何分片进行通信没有任何优势。此外，由于区域要求验证者了解区域内所有分片的状态，因此，它们牺牲了分片中的很多扩展优势。如果一个区域由16个分片组成，我们牺牲了大约15/16（94%）的扩展优势，尽管赢得了只有15/1024（总网络的1%）的紧耦合执行。

Encumbrances

跨分片（和跨链）通信的一个非显而易见的特性是用户比所涉及的链更快地获得对消息的信任。从分片A发送5BETH到分片B，Alice知道它会在发送后立即到达。Bob看到发送则知道，BETH只要发送在分片A上完成，它会立即抵达分片B。然而，分片B和它的合约，必须等待几分钟，等待beacon链在分片A的完成上达成最终性。这意味着，复杂的乐观钱包只要它们在分片A上花费，则可以在分片B上接收和发送资金。换言之，Bob将从Alice在分片B上的钱包获得可执行的IOU，因为Bob非常相信Alice已经发送足够的ETH来覆盖它。

如果分片B上有足够用户希望观察分片A，并接受标准化的IOU，那么，分片A的ETH可能在发送后很快就可以在分片B上消费。然而，当应用于智能合约时，这个机制变得异常复杂，因为状态永远不可替换，对状态的IOU几乎是不可能的，因此它不适合一般的交互。

这意味着我们应该在松耦合中将encumbrances视为用户体验改进。它允许松耦合模拟紧耦合，以快速执行某些交易。

分离共识和状态

其中一个更复杂和具有智力刺激的可能性是共识过程将从状态更新过程中分离。如今，以太坊矿工和全节点仅在执行包含在区块中的所有状态更新之后才接受区块。并不是非得要这样。相反，他们可以先接受区块，但稍后再更新状态。在这种情况下，与其像以太坊那样就系统状态达成共识，不如就跨分片的交易总历史（或者“总顺序”）达成共识。

这样做意味着每个分片能够快速增加区块，而无需了解其他任何分片的状态，这就是分片如何产生扩展优势。然而，在所有分片达成最终确定之前，还无法知道交易对分片状态和整体网络的影响。换句话说，状态的最终确定延后于分片内容的最终确定。

从一个用户的视角：我们会立即提交交易，且我们知道它们已被包括进去，但我们必须等待该交易结果的确定。随着分片的最终确定，我们逐渐获得更多状态相关的信息，但无法完全肯定，直到所有分片都达成最终性。类似于encumbrances，用户可能在某些情况下先于链确定交易结果，并采取行动。

结论和工程方向

ETH2.0是跟以太坊完全不同的系统。它们将并行多年，且有非常不同的功能。在不久的将来，预计会有一个从ETH到BETH的单向锚定。如果你运行交易所或托管服务，考虑一下，在它可进行链上转账之前，你如何能为用户提供支持BETH托管交易和权益服务。

从长远看，可以考虑你的智能合约如何适应分片，它们可能有，也可能没有跨分片通信。最重要的是，密切关注研究和研发进程。ETH2.0是复杂且进化的系统。所有DApp工程师需要对ETH2.0计划和进展有清晰理解。

------

风险警示：蓝狐笔记所有文章都不构成投资推荐，投资有风险，投资应该考虑个人风险承受能力，建议对项目进行深入考察，慎重做好自己的投资决策。

（作者：蓝狐笔记，内容来自链得得内容开放平台“得得号”；本文仅代表作者观点，不代表链得得官方立场）