《四种跨分片交易方案》

  • A+
所属分类:RChain新闻

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

第一种方案:让发出交易的客户端主动维护一致性,典型的就是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才能解决。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: