2018-05-11 [四种跨分片交易方案](https://zhuanlan.zhihu.com/p/36706657）

《四种跨分片交易方案》

《合约分片执行中的状态问题》一文提到了，跨分片合约的难点在于：一个分片对于共同访问的状态的修改，需要及时地让另一个分片知道，否则就容易出现状态错乱。

任何支持合约的分片技术，都必须要解决这个问题。目前业界大致有以下几种方案：

第一种方案：

让发出交易的客户端主动维护一致性，典型的就是Omniledger。客户端负责驱动这个过程，避免分片之间的协议通信。

优点是分片协议不用考虑维护一致性的问题，技术简单，且避免了分片之间一致性协议的开销。

缺点显而易见，没法做到交易丢出去不管，客户端在这个过程中必须保持运行。

另外，客户端去做这个事，真的安全么？实际上这个方案很难为业界所接受。我更倾向于认为，由于分片机制不完善，解决不了状态一致性而强行打的补丁。

第二种方案：

基于trace对交易进行标注，典型的就是Chainspace。交易注入到网络中之前，先模拟trace，并以此标注出可能与其他交易冲突的地方，然后再根据这些冲突发到相关的分片中处理，相关的分片之间再用S-BAC去共识。

这种方法，我想应该还是不能完全依照trace，还必须在代码层面进行标注，否则一个if/else语句在trace环境和实际环境下就可能走向了截然不同的分支。

另外每一个交易可能的冲突都要相关的分片之间去跑一轮共识，一个分片如果牵涉到很多个这样的交易，那每一次就要跟不同的分片跑很多个这样的共识。

第三种方案：

交易分裂，典型的就是Ethereum。

首先要说明的是，这种方式交易只能类似于币的转移这种，从一个分片中的地址，转移到另一个分片中的地址。合约内部状态是不能共享的，必须要保证每个分片的状态是私有的。具体的做法就是将这个币的转移过程切开，分成币的发送+币的接受，并且在不同的共识周期中完成。具体在Ethereum中的话，在一个共识周期中，分片中的地址发送币，并在主链中产生一个收据，然后在下一个共识周期中，另一个分片中的地址依据这个收据接受币。

看起来简单，然而并非如此，可以用火车和旅馆问题来比喻。你要去另一个城市玩，要定火车票，还要定旅馆。倘若你定了火车票，但是旅馆没订到，那就麻烦了；倘若你旅馆订到了，但是火车票没订到，你也麻烦了。要么都订到，要么都没订到，那才是良好的状态。问题产生的原因就是交易分裂到多个共识周期，破坏了原子性。

• Ethereum目前在这一块还处于初步的理论研究阶段，计划在分片的第四期中实现。
• Zilliqa的白皮书中将跨分片作为future work，据说正在研究，但从他们和Ethereum社区的交互来看，应该是同一种思想。
• RChain支持多种跨链方案，合约可以根据性能和开销的要求进行自由选择。其中一种跨链方案核心思想就是这种，当然表现形式不一样，具体是一个分片中的主钱包分裂出子钱包，另一个分片中的主钱包再合并这个子钱包。RChain由于是CasperCBC共识框架下，可以原生支持多级分片，并且由强大的RSpace对continuation的加持，这块要容易得多，官方没有指出这块还有待解决的问题，并且7月份上线的测试网将实现进去。这种方案一个很显而易见的开销，是需要至少个共识周期参与，需要双倍的时间。

第四种方案：

坐电梯楼上处理，典型的就是RChain。

具体做法就是，将跨分片的交易在他们的父级分片中处理。以RChain的多级名字空间机制作为基础，这种解决方式是直观显而易见的，而别的区块链项目因为没有多级名字空间这个基础设施，无法应用该方案。这种方案实现相对简单，稳定可靠，可以支持的交易比较灵活，适应面广，并且只需要一个共识周期就可以确认。但是，这种方案一个明显的缺点就是，父级分片存在处理压力的汇聚问题，越是上级的分片对吞吐率的要求越高。

RChain的解决方案是鼓励交易尽量在低层分片解决。一方面，多级分片结构具有过滤作用，需要处理的分片比例随着分片层级的升高而越来越低。

需要说明的是：

• 名字空间非常有利于数据的局部性，类似于CPU的缓存；
• 而Ethereum那种按照地址前缀分配分片的做法，数据完全是随机的，没有局部性。

另一方面，越上级的名字空间处理费用越高，通过经济激励手段让合约只在必要的时候才跨分片，只在非常必要的时候才跨高层次的分片。

这个过程可以类比汇款：同城汇款免费秒到，北京的汇款在北京分行内部就解决了，跟上海分行没关系；跨省汇款可能有时延，并且收首先费，总行可以解决；跨国汇款价格贵多了，而且要好几天的时间，通过swift才能解决。