曌链MIT核心技术之跨分片—Cross Sharding

2018-09-10 本文已影响0人 MITclub

跨分片合约难点

跨分片合约的难点在于：一个分片对于共同访问的状态的修改，需要及时地让另一个分片知道，否则就容易出现状态错乱。任何支持合约的分片技术，都必须要解决这个问题。目前业界大致有以下几种方案：

第一种方案：让发出交易的客户端主动维护一致性，典型的就是Omniledger。客户端负责驱动这个过程，避免分片之间的协议通信。优点是分片协议不用考虑维护一致性的问题，技术简单，且避免了分片之间一致性协议的开销。缺点显而易见，没法做到交易丢出去不管，客户端在这个过程中必须保持运行。另外，客户端去做这个事，真的安全么？实际上这个方案很难为业界所接受。我更倾向于认为，由于分片机制不完善，解决不了状态一致性而强行打的补丁。

第二种方案：基于trace对交易进行标注，典型的就是Chainspace。交易注入到网络中之前，先模拟trace，并以此标注出可能与其他交易冲突的地方，然后再根据这些冲突发到相关的分片中处理，相关的分片之间再用S-BAC去共识。这种方法，我想应该还是不能完全依照trace，还必须在代码层面进行标注，否则一个if/else语句在trace环境和实际环境下就可能走向了截然不同的分支。另外每一个交易可能的冲突都要相关的分片之间去跑一轮共识，一个分片如果牵涉到很多个这样的交易，那每一次就要跟不同的分片跑很多个这样的共识。

第三种方案：交易分裂，典型的就是Ethereum。首先要说明的是，这种方式交易只能类似于币的转移这种，从一个分片中的地址，转移到另一个分片中的地址。合约内部状态是不能共享的，必须要保证每个分片的状态是私有的。具体的做法就是将这个币的转移过程切开，分成币的发送+币的接受，并且在不同的共识周期中完成。具体在Ethereum中的话，在一个共识周期中，分片中的地址发送币，并在主链中产生一个收据，然后在下一个共识周期中，另一个分片中的地址依据这个收据接受币。看起来简单，然而并非如此，可以用火车和旅馆问题来比喻。你要去另一个城市玩，要定火车票，还要定旅馆。倘若你定了火车票，但是旅馆没订到，那就麻烦了；倘若你旅馆订到了，但是火车票没订到，你也麻烦了。要么都订到，要么都没订到，那才是良好的状态。问题产生的原因就是交易分裂到多个共识周期，破坏了原子性。Ethereum目前在这一块还处于初步的理论研究阶段，计划在分片的第四期中实现。

MIT跨分片合约

具体做法就是，将跨分片的交易在他们的父级分片中处理。以曌链MIT的多级名字空间机制作为基础，这种解决方式是直观显而易见的，而别的区块链项目因为没有多级名字空间这个基础设施，无法应用该方案。这种方案实现相对简单，稳定可靠，可以支持的交易比较灵活，适应面广，并且只需要一个共识周期就可以确认。但是，这种方案一个明显的缺点就是，父级分片存在处理压力的汇聚问题，越是上级的分片对吞吐率的要求越高。曌链MIT的解决方案是鼓励交易尽量在低层分片解决。一方面，多级分片结构具有过滤作用，需要处理的分片比例随着分片层级的升高而越来越低。需要说明的是：名字空间非常有利于数据的局部性，类似于CPU的缓存；而Ethereum那种按照地址前缀分配分片的做法，数据完全是随机的，没有局部性。另一方面，越上级的名字空间处理费用越高，通过经济激励手段让合约只在必要的时候才跨分片，只在非常必要的时候才跨高层次的分片。

图1：曌链MIT跨片示意图

跨分片消息传递

每个实体都有一个URN，结构是 : :/.

每个实习都有一个通过公钥来识别身份的邮箱. RChain分片是通过channel实现的.

每个分片都运行着一个Mailman合约来路由消息.

每条消息都包含这三个字段: destination, signature & payload

描述

同一个分片的消息传递

Mailman从消息中提取到destination，然后发送到目标邮箱

准备跨分片消息

在消息发送到其他分片前要经过共识，发送消息的意图将存储在块链中，并且只有在块完成后才发送。

图2：曌链MIT跨片消息传递

子分片到父分片交易

向父分片发送消息的总结如下：

1、就发送消息到父分片的决定达成共识；

2、validators签名然后把消息发送给父分片；

3、消息需要至少k个validators的签名；

4、获得k个签名之后，消息存储在区块链中；

5、共识达成之后，进行下一步；

图3：向父分片发送消息流程图

父分片向子分片交易

另外，MIT虚拟机实际上可以处理错误。如果在Solidity程序中有错误，那么基本上没有什么可以补救的。它会消耗掉所有代码运行成本的MIT，没法预先捕捉到错误，或从故障中恢复或恢复代码运行成本的MIT。相反，MIT具有错误处理功能，可以预先捕捉错误并确定错误发生的位置，并确定要做什么，是保留所有的代码运行成本的MIT，还是可以恢复状态，将剩下的MIT返还给执行合约的账户。这与“MIT提示”类似。智能合约开发类似于实时操作系统开发。时间没有限制，但是MIT有限。如果合约需要比预期更多的MIT，那么MIT将最终用完，而且将无法恢复它。因此部署一个计时器系统，提醒MIT消耗量，以及确定要做什么。这样如果合约运行完全出乎意料，或者MIT不够，可以回到某种紧急状态。这一块是MIT项目方目前重点研究的方向。

个人认为以太坊使用的WebAssembly非常有趣，但是它非常年轻，而且在设计上并不完善和完整，还只是一个pre-α的预测试版本。在安全性能上写起来更加复杂，因为这是非传统方法。从他们的核心开发团队也能看得出来，基本没有智能合约虚拟机开发背景的人员。所以大致可以看出来它还是主要针对浏览器，而不是智能合约。

对MIT虚拟机的介绍就到这里，如果对曌链MIT的技术感兴趣请关注我们的每周快讯和开发简报，会及时更新项目开发进度。

图4：向子分片发送消息流程图

散列锁托管转移（Hash-locked escrow transfer）

爱丽丝和鲍勃要通过代币P来交易货物，他们需要以下的一个交易机制来保证：

1、爱丽丝拥有代币P有效

2、在交易过程当中，代币P在爱丽丝的账户金额当中锁定，并且不能被其他交易使用

3、当得到了K次确认之后，交易执行成功

4、交易被取消的话，如果时间少于T，则代币会归还到爱丽丝的账户当中

图5：散列锁托管转移流程图