在昨天的文章《以太坊2.0指南（上）》中，我们谈到了以太坊2.0的定义，以及阶段0到阶段2的分阶段展示。今天，我们继续剩下的阶段3和阶段4以及总结的部分。
阶段3：链下状态储存
现在，为了更深入地对智能合约进行讨论，我们需要跳至以太坊2.0路线图中的第三阶段。阶段3通过尽可能多地将状态搬到链下来使链上的状态最小化。
与其在以太坊区块链上储存所有的状态，这条链只会储存部分状态信息以及一个聚合器(Aggregator,聚合器的作用是代表长数据列表的短字节的数据，一颗默克尔树就是一个聚合器)。用户将负责在链下储存完整的状态信息。当用户希望与状态进行交互时，他们会在交易中包含一个当前状态的证明。这样以来，运行验证节点所需的资源要求就会低很多。当前已经存在拥有拥有不同属性和性能特征的聚合器的多个设计方案，但具体的设计方法还没有缺确定。此时，我们将无法再利用链上通讯来协调用户，因此我们必须制定通过其他系统来同步数据的计划。对工程师来说，交易活动不再那么有用，因为链已不能保证随时都可获得数据。在阶段3，对链下状态的维护和检索将成为 dApp 设计面临的一个关键束缚。
阶段4：分片合约
然而，还存在一个难以克服的问题：虽然 以太坊2.0 合约和当前的以太坊合约一样强大，但它们和单个分片绑在一起，永远不可能直接和另一个分片上的合约交互。这是分片的一个直接结果。分片的目标是在分片之间将状态分割，不需要了解到其他分片的第一手知识。它通过分割状态、以及最小化验证器的负载来实现扩展。直接交互需要第一手知识。分片在设计上就没有其他分片的第一手知识。它只通过与信标链的交叉连接来了解其他分片。因此，如果想要跨分片交互，就必须要等待信标链的实现。更准确地说，这意味着，如果 SafeMath (SafeMath 是一个 Solidity 数学库，专用于支持安全的数学运算)部署在分片A上，那分片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发布之前，迁移智能合约代码或者用户没有任何意义。由于优势很小，阶段4的发布时间预计在2020年的年中。同时，为了更好地理解 dApp 设计者和 dApp 用户的权衡，我已经调查了几个提议过的模式，在这里给大家简要描述一下。我不认为这些模式中的任何一个会被采用，但我相信它们对理解所涉及的权衡来说很有用。再次声明：以下内容都是我推测的。
基本模式：收据和证明
所有形式的跨链通信都需要利用信标链。因为信标链提交所有分片的状态，而每个分片也都提交信标链的状态，我们可以将它作为分片链生态系统中的中心点。从一条链到另一条链的消息在某种意义上必须通过信标链传输。我们不想发送完整的消息，因为这需要信标链自己来处理每个交易，这样就完全否定了扩展的好处。
相反，每当分片A上的用户或合约想要与分片B交互时，我们都会让分片A生成一个带有该消息的“收据(receipts)”。分片A在其区块头（头块）中提交所有收据。信标链等待分片提交A完成，然后提交到A的区块头（包括提交收据）。分片B必须等到信标最终确认，然后才提交给信标头。一旦发生这种情况，就可以向分片B提交新的交易，包括收据和证明。证明显示收据包含在分片A中，分片A包含在信标中，而那个信标包含在分片B中。这样一来，分片B上的合约可以信任从分片A发送的消息，如果分片B上的合约想要作出回应（可能是返回价值或者某个错误）。反过来重复整个过程：分片B做出一个收据，最终回到分片A。
很容易理解为什么这个过程需要时间。四个通信步骤中的每一步都需要等待几分钟才能最终确认。不幸的是，我们无法完全避免等待。 如果我们想要确定远程状态，那么我们必须在每一步都等待最终确认。往返通信的最佳情况是有四个最终确认周期。 也就是说，用户在三个周期后获得信心，因为他们可以在分片A之前先看到分片B的收据。 因为ETH2.0的6.4分钟时间长度，用户必须等待19分钟才能看到结果，需要等待26分钟才能获得链上结果。
具体收据：分片间的代币转移
ERC20代币的多功能性使它们在以太坊中无处不在。但是，ETH2.0给代币带来了一些逻辑问题。由于智能合约管理所有代币余额，而智能合约只存在于单个分片上，也就是说分片A上的代币在分片B上完全不存在。然而。通过一些巧妙的跨分片通信，我们可以在多个分片上部署同一个代币，并允许代币在分片之间转移，从而有效地在代币合约之间双向锚定。
该方案非常简单：在部署代币（就把它成为酷酷的跨分片代币或者CCT吧）时，我们将使用ERC20，并添加两个小功能： migrateSend 和migrateReceive。我们会用migrateSend 燃烧代币，并生成一个收据。该收据会包括燃烧过的代币的数量，以及接收的分片。我们会让migrateReceive 验证收据，生成相同数量的CCT。然后我们会在每一个分片上部署相同的代币合约。现在我们可以通过调用migrateSend有效地在分片之间转移代币，然后调用 migrateReceive来在另一个分片上生成代币。我们需要在每个分片上重新部署代币合约，但这似乎是值得的。虽然转移是单向的，但至少需要两个跨通信分片的最终确认期。因为，在调用migrateSend之后，大约需要10分钟，CCT才能在接受分片上使用。
Yanking
收据(Receipts)是在分片之间移动信息的一般方式。我们几乎可以把任何链上的信息放在一个收据里。这包括整个智能合约。Yanking 是一种通过在在过中包含合约代码和存储来来跨分片迁移合约的提议。合约将从碎片A中被删除（yanked），然后在收据到达之后再在分片B上重新部署。一旦部署到分片B片上之它就可以直接与的分片B上的合约进行通信，并与分片的B状态交互。它甚至可以在删除后重新回到分片A。
这允许智能合约（在跨分片等待时间过后）与其他合约进行通信。但是，因为收据包括整个合约及其储存数据，移动或者主流的合约的约的可能会很高。数据在传输的过程中，合约是完全不可用的。它已经从分片A中删但尚但尚未到达分片B。这意味着在该合约到达分片 B之前，所有其他用户都将被锁定。即便如此，只有已在分片B上的用户才能与其交互。因此，yanking最适合于用户较少的小型合约。它使得紧密耦合的执行成为可能，但还远远不是一个可通用的解决方案。
分片配对
从这里开始我们来说说更具异国情调的构建。收据的设计目的是让异步（松散耦合）成可能为。但是，我们可能也需要要同通信，为此，我们必须更有更有创意。分片配对是一个简单设计，能让我能执行们紧密耦，且造成的最少麻烦。
分片配对是一种简单的方案。在这篇文章（https://ethresear.ch/t/synchronous-cross-shard-transactions-with-consolidated-concurrency-control-and-consensus-or-how-i-rediscovered-chain-fibers/2318/8）的第三段，我将分片在每个高度度设置成同步对。每当一个分片与另一个分片配对，任何一个分片的用户都可以在它们之间执行紧密耦合的状态更新。这意味着如果分片A和B在高度7配对，则A和B的所有验者证都必须知道A和Bd的所有状态，并且分片必须一起更新或完全不更新。在这个模式中，如需要在A和间B之进行跨链交易，那你必须要等到A和B随机配对。Vitalik 描述了100分片案例。在1024个分片中，我们预计要有512个区块（大约一个小时）配对，但由于配对是随机的，可能需要更长的时间或者更短的时间。据Vitalik指出，如果你想和多个分片进行交互，那扩展性会非常差。
分片区域
这是一个更广泛的配对版本。在每个时间点，我们都把分片分成几个由多个分片组成的“区域”。区域必须同步更新，也就是说，区域中的所有分片要一起更新其本地状态。通过同步进行，区域提供了分片之间自由移动和与区域内合约的直接交互，但对于与区域外的分片进行通信来说，这没有任何优势。此外，因为区域要求验证者知道区域中所有分片的状态，所以它们否定了分片的许多可扩展优势性。如果一个区域由16个分片组成，我们将牺牲大约15/16(=94%)的扩展性优势，同时仅以整个网络的15/1,024(=1%)获得紧密耦合执行的。
障碍 Encumbrance
跨分片（和跨链）通信的一个不明显的特性是，用户在一条消息中所获得的信心比所涉及的链更快。假设Alice要从分片A发送5个BETH到分片B，她知道这笔款项会在她发送的同时到达。而Bob，看到这笔款项的发送过程，知道这笔BETH会在分片A上发送完成的同时到达分片B。然而，分片B上以及其合约，必须等几分钟，知道信标链最终确认分片A已确认完毕。这意味着，一个复杂的乐观的钱包可以在发送分片A了一笔款项的同时，在分片B上接受到这笔款项可以说把它花出去。
换句话说，Bob 将在分片B上从 Alice 的钱包中提取一张可强制执行的借条（IOU），因为 Bob 相信 Alice 已经发送了足够的ETH。如果有足够多的分片 B用户愿意观察分片 A并接受标准化借条，则分片A 的ETH 在发送后可能很快就可以在分片 B上使用。然而，当应用于智能合约时，该方案变得异常复杂，因为状态是不可替代的，状态是不可能有借条的，所以它不适用于普通的交互。也就是说，我们应该把障碍看作是松散耦合中的一种UX（用户体验）改进。这允许松散耦合对某些交易用快速执行来模拟紧密耦合。
分离共识与状态
其中一个更复杂、更能启迪思维的可能性是，共识的过程将与更新状态的过程分离。今天，以太坊挖矿程序和完整节点仅在对该区块中的所有状态进行更新后才能接受区块。但不一定非要这样。他们可以先接受区块，并在稍后才对状态进行更新。在这种情况下，我们不会像在以太坊中那样，就系统的状态达成共识，而是会就分片中所有交易的总历史（或“总订单”）达成共识。这样做意味着，每个分片在不知道其他分片状态的情况下，都能快添加速添快区这这是片片可扩展性有优势的地方。但是，只有等到所所分片最终确定后，才会知道交易对分片状态和整个网络的影响响换句话说，状态的确定滞后于分片内容的确定。
从用户的角度来看：我们会立即提交交易，而且我们知道这些交易包括在内。但我们必须等待，以确定该交易的节骨。随着分片的最终确定，我们将逐步获得更多有关状态的信息，但在有分片状态确定状态之前，我们还不能完全确定。与障碍类似，在某些情况下，用户可能会在交易链之间确定交易的结果，并据此采取行动。
总结与工程方向
ETH2.0 将是一个与以太坊完全不同的系统。二者将并行存在数年，并且具有完全不同的功能集。在不远的将来，预期会有一个从 ETH 到 BETH 的单向锚定。如果有交易所或托管服务，请想想 BETH 可在链上转移之前，如何提供 BETH 托管交易以如何及为你的用户提供质押服务。从长远来看，你应该想想智能合约如何在有和没有跨分片通信的情况下适应分片。最重要的是，要密切关注研发过程。ETH2.0 是一个复杂的、不断发展的系统。所有dApp 设计者都需要清楚地了解ETH2.0的计划和进展。
原文作者：James Prestwich
翻译：Iris, Echo
校对：Jhonny
【文章版权归原作者所有，其内容与观点不代表Unitimes立 场。转载文章仅为传播更有价值的信息，合作或授权请联系我们】
