以太坊2.0入门指南我们谈到了以太坊2.0的定义，以及阶段0到阶段2的分阶段展示。今 天，我们继续剩下的阶段3和阶段4以及总结的部分。阶段3：链下状态储存现在，为了更深入地对智能合约进行讨论，我们需要跳至以太坊2. 0路 线图中的第三阶段。阶段3通过尽可能多地将状态搬到链下来使链上的 状态最小化。与其在以太坊区块链上储存所有的状态，这条链只会储存部分状态信息 以及一个聚合器（Aggrega tor聚合器的作用是代表长数据列表的短字节 的数据，一颗默克尔树就是一个聚合器）。用户将负责在链下储存完整 的状态信息。当用户希望与状态进行交互时，他们会在交易中包含一个 当前状态的证明。这样以来，运行验证节点所需的资源要求就会低很多。 当前已经存在拥有拥有不同属性和性能特征的聚合器的多个设计方案， 但具体的设计方法还没有缺确定。此时，我们将无法再利用链上通讯来 协调用户，因此我们必须制定通过其他系统来同步数据的计划。对工程 师来说，交易活动不再那么有用，因为链已不能保证随时都可获得数据。 在阶段3,对链下状态的维护和检索将成为dApp设计面临的一个关键 束缚。阶段4:分片合约然而，还存在一个难以克服的问题：虽然以太坊2.0合约和当前的以 太坊合约一样强大，但它们和单个分片绑在一起，永远不可能直接和另 个分片上的合约交互。这是分片的一个直接结果。分片的目标是在分 片之间将状态分割，不需要了解到其他分片的第一手知识。它通过分割 状态、以及最小化验证器的负载来实现扩展。直接交互需要第一手知识。 分片在设计上就没有其他分片的第一手知识。它只通过与信标链的交叉 连接来了解其他分片。因此，如果想要跨分片交互，就必须要等待信标 链的实现。更准确地说，这意味着，如果SafeMath （SafeMath是一个 Solid it数学库，专用于支持安全的数学运算）部署在分片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分钟才能获得链上结果。Cross-chaCn CommunicationShiard ABeaconShard BMake Receipt AWait for Finality (1Com mH to AWait for Ftn aLity (2)Frac ess ReceipH AMke Receipt BWait forFinJlity Cam mil Ed BWait For Fen aLity (4)Comm it tc QeacanPnaccss RE-ccipt 日具体收据：分片间的代币转移ERC20代币的多功能性使它们在以太坊中无处不在。但是，ETH2.0给代币带来了一些逻辑问题。由于智能合约管理所有代币余额，而智能合 约只存在于单个分片上，也就是说分片A上的代币在分片B上完全不 存在。然而。通过一些巧妙的跨分片通信，我们可以在多个分片上部署 同一个代币，并允许代币在分片之间转移，从而有效地在代币合约之间 双向锚定。该方案非常简单：在部署代币（就把它成为酷酷的跨分片代币或者CCT 吧）时，我们将使用ERC20，并添加两个小功能：migrateSend和 migrateReceive。我们会用migrateSend燃烧代币，并生成一个收据。 该收据会包括燃烧过的代币的数量，以及接收的分片。我们会让 migrateReceive验证收据，生成相同数量的CCT。然后我们会在每一 个分片上部署相同的代币合约。现在我们可以通过调用migrateSend有 效地在分片之间转移代币，然后调用migrateReceive来在另一个分片 上生成代币。我们需要在每个分片上重新部署代币合约，但这似乎是值 得的。虽然转移是单向的，但至少需要两个跨通信分片的最终确认期。 因为，在调用migrateSend之后，大约需要10分钟，CCT才能在接受 分片上使用。Cross-chain Token MigrationShrd ABeacon5hard Bmi jrateSe nd(burn 10 toen5. &end to B)mig rat&Snd rece-ipl:1 D iDk&ns ssnl to Sha rd EWsit for Finality i：1)Wait for Finality (2)1fCummii to Alincluding AsCommit to Btacon lintluding As rEceipts)rrbigrateRectiveproems noigrleSendreceipt and mint 10 token$)Yanking收据（Receip ts是在分片之间移动信息的一般方式。我们几乎可以把任 何链上的信息放在一个收据里。这包括整个智能合约。Yanking是一种 通过在在过中包含合约代码和存储来来跨分片迁移合约的提议。合约将 从碎片A中被删除（yanked ），然后在收据到达之后再在分片B上重 新部署。一旦部署到分片B片上之它就可以直接与的分片B上的合约 进行通信，并与分片的B状态交互。它甚至可以在删除后重新回到分片A。这允许智能合约（在跨分片等待时间过后）与其他合约进行通信。但是， 因为收据包括整个合约及其储存数据，移动或者主流的合约的约的可能 会很高。数据在传输的过程中，合约是完全不可用的。它已经从分片A 中删但尚但尚未到达分片B。这意味着在该合约到达分片B之前，所有 其他用户都将被锁定。即便如此，只有已在分片B上的用户才能与其交 互。因此，yanking最适合于用户较少的小型合约。它使得紧密耦合的 执行成为可能，但还远远不是一个可通用的解决方案。分片配对从这里开始我们来说说更具异国情调的构建。收据的设计目的是让异步（松散耦合）成可能为。但是，我们可能也需要要同通信，为此，我们 必须更有更有创意。分片配对是一个简单设计，能让我能执行们紧密耦， 且造成的最少麻烦。分片配对是一种简单的方案。在这篇文章（https:/ethresear.ch/t/synchronous-cross-shard-transactions-with-c onsolidatedconcurrencycontrol-and-consensus-or-how-i-rediscover ed-chain-fibers/2318/8的第三段，我将分片在每个高度度设置成同步 对。每当一个分片与另一个分片配对，任何一个分片的用户都可以在它 们之间执行紧密耦合的状态更新。这意味着如果分片A和B在高度7 配对，则A和B的所有验者证都必须知道A和Bd的所有状态，并且分 片必须一起更新或完全不更新。在这个模式中，如需要在A和间B之 进行跨链交易，那你必须要等到A和B随机配对。Vitali描述了 100 分片案例。在1024个分片中，我们预计要有512个区块(大约一个小 时)配对，但由于配对是随机的，可能需要更长的时间或者更短的时间。 据Vitali指出，如果你想和多个分片进行交互，那扩展性会非常差。分片区域这是一个更广泛的配对版本。在每个时间点，我们都把分片分成几个由 多个分片组成的区域”区域必须同步更新，也就是说，区域中的所有 分片要一起更新其本地状态。通过同步进行，区域提供了分片之间自由 移动和与区域内合约的直接交互，但对于与区域外的分片进行通信来 说，这没有任何优势。此外，因为区域要求验证者知道