Ethereum 2.0即将到来,在市场充塞着“区块链3.0”时

向方 · 发表于 2019-3-16 18:48:19

最根本的权衡：同步性或可拓展性

即使以太坊 2.0 设计人员也不知道跨分片的通信系统会是怎样的。通过阅读许多提案，似乎在即时反馈和可预测性之间存在着根本性的权衡，但分片的本质不会随之改变：无论哪种跨分片通信用户都必须等待。只是我们可以选择交易在本地和在每个分片链上远程执行阶段耦合的紧密程度。

紧密耦合使得等待先行。在分片链之间通信之前，交易不执行任何操作，与此对应的是，我们可以通过现在执行部分，剩下的稍后执行来松散地耦合交易。交易先在本地分片链上执行，跨分片通信之后在远程分片上执行。松散的耦合为用户提供了更好的使用体验，用户将看到自己的交易立即在本地执行，并且知道在未来的某个时刻交易将继续在远程执行，但不幸的是，除非等待否则他们不能了解松散耦合中交易的远程执行阶段。紧密耦合的交易更具可预测性，其中用户更清楚执行的结果，因为交易在本地和远程执行阶段之间远程状态并不会变化。但是，紧密耦合中用户也需要等待才能看到结果。

我们对于以太坊 2.0 通信模型的信息知之甚少。我们只知道它不能在不牺牲几乎所有可扩展性优势的情况下提供跨分片智能合约调用。而设计人员对于第四阶段只给出了思维导图和一些模棱两可的链接。这种情况的一个非显而易见的结果是，以太坊 2.0 在第四阶段之前不会为复杂的智能合约系统提供显著的可拓展性支持。在此之前，有与其他智能合约交互需求的智能合约必须与其存在于同一个分片链上，并且还会受到分片链速度和规模的限制，因此，我们预计引入分片技术后以太坊 2.0 与以太坊 1.X 版本相比速度也就只能快几倍，而不会有翻天覆地的变化。这意味着在第四阶段发布之前（可能在 21 世纪 20 年代中期），没有必要将智能合约代码以及用户迁移到以太坊 2.0 中，因为迁移带来的优势很小。与此同时，为了更好地理解开发人员和 Dapp 用户之间的权衡，我研究了一些模型，并给出了简短的描述。我认为这些最终可能并不会被采纳，但我相信它们有助于理解所涉及到的权衡。请注意：这里说的一切都是推测性的。

向方 · 发表于 2019-3-16 18:48:38

基本模型：收据和证明

所有形式的跨链通信都用到了 Beacon 链。因为 Beacon 链管理所有分片链的状态，并且每个分片链都将状态提交到 Beacon 链，所以我们可以将Beacon 链看作分片链生态系统的核心。从某种意义上来说，从某条分片链到另一条分片链的消息必须通过 Beacon 链传输。我们不希望发送完整的消息，因为如果需要 Beacon 链处理每笔交易，这样分片技术还有什么意义。

相反，每当分片 A 上的用户或智能合约想要与分片 B 交互时，分片 A 生成带有该消息的“收据”。分片A在其区块头中提交其所有的收据。Beacon 链等待 A 最终确认，然后提交到 A 的区块头部（包括对收据的承诺）。分片 B 必须等待 Beacon 链最终确认，然后提交到 Beacon 链的区块头部。这样的流程完成之后，分片 A 就可以直接向分片 B 提交包含收据和证明的新交易。证明显示收据包含在分片A中，分片 A 包含在 beacon 链中，并且 beacon 链包含在分片 B 中。这样，分片 B 中的智能合约可以信任从分片 A 发送过来的消息，如果分片 B 中的智能合约想要回复信息（可能是返回值或是错误），我们需要反过来重复整个过程：分片 B 发出一个收据，最终传到分片 A。

不难看出这个过程很浪费时间。四个通信步骤中的每一个都需要等待几分钟才能最终确认！而且不幸的是，我们无法完全避免等待。如果我们想确定远程的状态，那么我们必须留意执行的每一步以获得最终的结果。在最理想的情况下，两方相互通信需要等待四个最终确认时间，也就是说，用户在三个最终确认时间后就能确信交易成功，因为用户可以在分片 A 正式收到之前看到分片 B 的收据，鉴于以太坊 2.0 的 6.4 分钟时间周期，用户必须等待 19 分钟才能看到交易结果，并且需要 26 分钟才能看到交易结果被加入到区块链中。

向方 · 发表于 2019-3-16 18:49:23

向方 · 发表于 2019-3-16 18:49:44

具体的收据：分片链之间的通证转移

ERC-20 通证的强大功能使得它们在今天的以太坊生态系统中无处不在。但是，以太坊 2.0 给通证的运行逻辑带来了一些问题。因为智能合约管理所有的通证余额，并且智能合约仅存在于单个分片链上，所以分片A中的通证并不存在于分片 B 中。不过，通过一些巧妙的跨分片通信机制，我们可以在几个分片链上部署相同的通证从而允许在分片链之间转移通证，即在通证智能合约之间建立有效的双向锚定（two-way peg）。

这个方案非常简单：在部署我们的通证（让我们称之为“酷酷的跨分片通证”或“CCT”）时，我们在 ERC-20 中添加两个小的附加函数：migrateSend（转移发送功能）函数和 migrateReceive（转移接收功能）函数，函数 migrateSend 用来销毁通证并生成收据。收据中将包含已销毁了的通证数以及接收信息的分片链。函数 migrateReceive 验证收据并生成相同数量的通证，我们将在每个分片链上部署相同的通证智能合约，这样我们就可以通过调用 migrateSend 函数在一个分片链上销毁通证，然后在另一个分片链上调用 migrateReceive 函数来重新生成通证。虽说需要在每个分片上重新部署通证智能合约，但这看起来是十分值得的。这种转移是单向的，至少需要两个跨分片通信的最终确认周期。因此，在我们调用 migrateSend 函数之后，大约 10 分钟之后就可以在接收分片上使用这些通证了。

向方 · 发表于 2019-3-16 18:50:24

向方 · 发表于 2019-3-16 18:50:59

拖拽（Yanking）

收据是跨分片转移信息的一种通用方式。我们可以在收据中加入任何链上信息，甚至可以加入整个智能合约。拖拽是一项通过将智能合约的代码和存储包含在收据中从而跨分片转移智能合约的提案。在拖拽机制中，智能合约将被加入到收据中并被分片 A 删除（拖拽），在收据到达分片 B 之后在分片 B 上重新部署。一旦到达分片 B，它可以直接与分片 B 中的智能合约进行通信，并与分片 B 的状态进行交互，甚至可以被拖拽回分片 A。

拖拽机制将允许智能合约与任何其他智能合约进行通信（在等待跨分片时间之后）。不幸的是，由于收据包括完整的智能合约及其所有的存储，因此转移大型智能合约的成本会很高。收据在转移过程中，智能合约将无法使用，因为分片A已把它删除，而它还尚未到达分片 B，这意味着在它到达分片 B 之前，所有相关用户都被锁定在该智能合约之中，而且只有已经在分片 B 上拥有账户的用户才能与之交互。因此，拖拽最适合用户很少的小型智能合约。它使紧密耦合的执行成为可能，但并非通用的解决方案。

向方 · 发表于 2019-3-16 18:51:18

分片配对（Shard Pairings）

收据旨在使异步（松散耦合）通信成为可能。但在某些场合下，我们还可能需要同步通信。为此，我们必须加入一点创新。分片配对是一个简单的设计，让我们以最少的麻烦进行紧密耦合的状态更新。

分片配对是一个简单的方案，其原理是，我们在每个高度将分片混合成同步对。每次分片与另一个分片配对时，任一分片的用户都可以跨分片执行紧密耦合的状态更新。这意味着如果分片 A 和分片 B 在高度 7 处配对，则分片 A 和分片 B 的所有验证者都会知道分片 A 和分片 B 的所有状态，并且分片必须一起执行或根本不执行。在这个模型中，如果你需要在分片 A 和分片 B 之间执行跨分片交易，你需要等待分片 A 和分片 B 随机配对。Vitalik 分析了 100 个分片的案例，对于 1024 个分片，我们预计它需要经历 512 个区块，大约需要一个小时，但由于分片配对是随机的，时间可能需要更长或更短。正如 Vitalik 所说，当你想要与多个分片交互时，这时可扩展性很差。

向方 · 发表于 2019-3-16 18:52:01

向方 · 发表于 2019-3-16 18:52:20

分片区域（Shard Zones）

分片区域是更广义版本的分片配对。其原理是，每个时间段内我们将分片分成几个由多个分片组成的“区域”。区域必须同步执行，这意味着区域中的所有分片一起更新其本地状态。通过同步执行，区域提供内部分片之间的自由转移，并可与区域中的其他智能合约直接交互，但是这种机制在与区域外的其他分片进行通信时没有任何优势。此外，由于分片区域机制需要验证者了解区域中所有分片的状态，因此分片区域的存在大大降低了分片带来的可拓展性优势。如果一个区域由 16 个分片组成，那么这个区域牺牲了大约 15/16（= 94％）的可拓展性优势，以换取总网络 15 / 1024（= 1％）紧密耦合的执行。

产权负担（Encumbrances）

跨分片（以及跨链）通信的一个不明显的特性就是，用户可以在区块链正式接收之前更快地获得交易的信息。就比如说，爱丽丝从分片 A 向分片 B 发送 5 BETH，知道它会在发送后立即到达分片 B。鲍勃看到了爱丽丝在发送，他知道一旦发送在分片 A 上最终确认，BETH 将到达分片 B。然而，分片 B 及其上的智能合约必须等待几分钟，等 Beacon 链最终确认分片 A 的最终确认。这意味着资金在分片 A 上花费之后，我们可以很快在分片 B 接收并花费这笔资金。换句话说，鲍勃将从分片 B 上爱丽丝的钱包中获得可执行的 IOU（债券），因为鲍勃相信爱丽丝已经发送了足够多的以太币。如果分片 B 的大部分用户都愿意留意分片 A 上的交易并接受标准化的 IOU，那么分片 A 上的以太币可能在发送后很快在分片 B 上花费。然而，当应用于智能合约时，这种方案变得异常复杂，因为状态是不可替代的，状态的债券是不可能的，因此它不适用于一般的交互。这意味着我们应该将产权负担视为松散耦合中的用户体验改进，它允许用松耦合模拟紧密耦合以快速执行某些交易。

共识和状态分离

一个更复杂也更为烧脑的可能是共识过程将脱离状态更新过程。当下，以太坊矿工和完整节点只有在执行了区块中包含的所有状态更新后才接受该区块，其实没有必要，因为在接受区块之后再更新状态也不迟，只是在这种情况下，矿工不会像当下在以太坊中那样就区块链系统状态达成共识，而是会对所有分片链中所有交易的全部历史（或“全部顺序”）达成共识。这样做意味着每个分片链都可以在无需知道其他分片链状态的前提下快速添加区块，这就是分片机制带来可拓展性优势的原因。但是，在所有分片最终确认之前，交易对分片链状态和整个区块链网络的影响将不得而知。换句话说，在所有分片内容的最终确认之后才能完成状态的最终确认。

从用户的角度来看：我们提交交易后就知道交易已被包含在区块链中，但我们必须等待一段时间来确定该交易执行的结果。随着分片的最终确定，我们逐渐获得有关区块链状态的更多信息，但在所有分片链都最终确定之前还无法完全肯定。与产权负担相似，在某些情况下，用户可以在区块链之前确定交易的结果并采取相应的行动。

向方 · 发表于 2019-3-16 18:53:03

结论 & 开发人员的前进方向

以太坊 2.0 将会是与以太坊完全不同的区块链系统，在未来的几年里，它们将本着不同的特征共同存在，不过在不久的将来，预计将会出现从以太币到 BETH 的单向挂钩。如果你经营加密货币交易所或托管服务，那么你就要思考如何在官方支持链上转移之前为你的用户提供 BETH 托管交易和抵押服务，从长远来看，你还需要考虑智能合约如何在有和没有跨分片通信的情况下适配分片技术。当然了，最重要的是你需要密切关注以太坊 2.0 项目的研究和开发进程。以太坊 2.0 是一个复杂且不断发展的系统，为了更好地抢占先机，所有 Dapp 开发人员都需要清楚地了解以太坊 2.0 的计划和进度。