探索 ETH 2.0：跨片通信是如何处理的？

来源：Adiasg.me

翻译：头等仓（First.VIP）

编者注：原标题为《探索ETH 2.0的跨片通信》

随着Eth2.0的阶段深入，研究重点正在转移到阶段2：状态执行。此阶段最重要的一个方面是跨片通信的处理，它影响了分片化区块链系统的可扩展性，执行环境容量以及用户体验。这篇文章旨在帮助读者了解跨片通信的设计，并探讨可用方式。

跨片通信的设计可以分为两层：

1. 共识层（Consensus layer）： 用于处理跨片消息传递。这个设计会影响分片式区块链系统的可扩展性。

2. 执行层（Consensus layer）： 包括跨片传输和合约调用的接口。这个设计选择会影响执行环境的容量。

共识层

跨片通信的共识层负责在区块链系统的各个分区传递跨片消息。主要挑战是在保持可扩展性的同时，为跨片消息的有效性提供强有力的保证。该层可分为两部分：

• 发送/接收最终确定性（Send/Receive finality）
• 数据传送（Data delivery）

发送/接收最终确定性

源分片（source shard）和目标分片（destination shard）必须分别完成跨片消息的发送和接收。为实现此目标可采用的设计有：

• 异步（Asynchronous） ：源分片发送消息，而目标分片可以在将来的任何时间接收此消息。
• 同步（Synchronous） ：目标分片在源分片确定发送之后的有限时间内接受消息。有多种方法可以实现此目的：· 分片之间运行某种共识协议，并决定同时发送和接收，例如：分片拜占庭式原子提交（ Sharded Byzantine Atomic Commit ）。· 源分片先发送，而相应的目标分片必须在一段时间内接收，例如：CBC Casper跨片消息传递（ CBC Casper cross-shard messaging ）。此方法要求在源分片和目标分片之间存在层次结构，否则，由于发送和接收冲突而可能导致僵局。· 将跨片消息放置在信标链上，并强制目标分片在下一个交叉之前接收它们。（注意：这可能限制了可扩展性。）

同步与Eth2.0的设计不兼容，因为它需要分片以某种方式协调发送和接收最终确定性。

数据传送

先前的机制涉及发送和接收的最终确定性，这与实际完成消息的发送或接收不同。这是数据传送机制的任务。（这两者之间的区别将在本节的“用户交付”方法中突出显示）

ETH 2.0的设计要求所有共识活动仅在信标链中发生。这意味着所有跨片消息都必须“流经”信标链。这为我们提供了跨片数据传递的两种选择：

• 协议交付（Protocol-delivered） ：协议通过使跨片消息在信标链上可用，来交付跨片消息的完整数据。这增加了信标链的开销，并严重影响了系统的可扩展性。
• 用户交付（User-delivered） ：该协议仅在跨片消息的最少信息（来自每个分片的跨片消息的Merkle根）上达成共识。然后，用户负责将与跨片消息关联的Merkle分支传递到目标分片。此方法更适合Eth2.0，因为它遵循仅在信标链上的merkle根上形成共识的一般原理。

共识层的拟议设计

为了优先权衡系统可扩展性， 异步发送/接收最终确定性和用户交付数据的解决方案是更可行的 。在shard 分片（shard ）A上的用户 1发送Ether给在分片（shard） B的用户2如下：

1. 用户1在 shard A上创建事务TX1，从EE1标记余额，并声明目标是用户2。

2. 当来自shard A的crosslink包含在信标链中时，收集最后一个crosslink以来的所有跨片交易的merkle根出现在信标链上。这是shard A中包含TX1的证据。

3. shard B发现了信标链上的这个merkle根，用户2创建交易TX2，显示shard B包含TX1的merkle证明。这允许将适当的金额标记到用户2在EE2上的余额。

执行层

跨片通信的执行层为用户和合约提供接口，以进行跨片传输和合约调用。该层的设计空间尚未得到很好的探索。关于此层的最新讨论包括：

• 执行环境中的跨片调用
• 分片之间可靠的价值转移

跨片调用

基本问题是：当不同的分片上调用另一个分片的功能时会发生什么？对于分片式区块链来说，设计并不是唯一的。它与在多个分区中分开执行应用程序的系统相同，例如：

• 单线程与多线程系统
• 单一算机与网络应用系统

受到上述系统的启发，简单设计可以是以下几种类型的调用：

• 异步调用，无返回
• 指定了回调的异步调用
• 同步调用

替代方法包括各种高级并发编程范例，例如 protolambda’s commit capabilities post 。

转载请保留版权信息。