一种基于双链结构的高性能联盟区块链

摘要

本发明公开了一种基于双链结构的高性能联盟区块链，包含一个输入共识链和多个业务逻辑链。输入共识链节点个数为Ni，其中最多包含的恶意节点数为fi，根据BFT类算法的要求，Ni大于等于3fi+1；本发明相比于Fabric，不限制业务逻辑的开发平台、开发语言和基础服务，同时提出了“基于可观测状态的共识”的新选择，将状态指纹的产生效率提升到O(1)的复杂度。与此同时，传统“基于完整状态的共识”的选择仍然对设计者开放。

说明书

技术领域

本发明涉及一种基于双链结构的高性能联盟区块链,在现有区块链技术的基础上，修改了联盟区块链中关于共识架构和扩展性方面的设计，形成了一种基于双链结构的高性能联盟区块链。

背景技术

区块链中存在两个独立层面的共识，其一可称为“输入共识”，其含义是各节点对指令的顺序及内容达成共识，类似传统数据通信的会话层，不牵涉业务操作；其二可称为“输出共识”，其含义是业务系统受输入的驱动，状态不断发生跃迁，同时产生一系列输出，此时各参与方对业务系统进入的状态及产生的输出达成共识。

这两层共识在设计上可以分离，但不同区块链在这里的设计差别很大，总的来说有三种方式：

第一种方式是只提供输入共识，此以Factom项目为例。Factom只对数据内容和顺序进行共识，把对数据的后续检验及处理交给其他应用程序完成。其缺点是：不支持应用程序结果的比对和校验，无法抗击应用逻辑执行时的拜占庭错误。

第二种方式是以紧耦合的方式提供输入共识和输出共识，典型案例如以太坊。以太坊的区块头中不仅包含交易根，也包含状态根，通过统一的机制串行地达成对交易和状态的共识，也就是串行完成输入共识和输出共识。其缺点是无关的业务逻辑也不能并行执行，且业务逻辑执行和输入共识执行的串行化会极大降低系统的总吞吐量。

第三种方式是以分离的方式提供输入共识和输出共识。比如在Fabric 1.0中，输入共识在Orderer之间达成，Orderer只看到数据，并不理解任何业务含义，输出共识则通过Endorsor和Committer及应用层CheckPoint机制另外实现。Fabric的输出共识机制所用的状态指纹生成方式乃是把全部智能合约(Chain Code)所访问的KV数据库组织成许多逻辑有序的桶，以各桶为叶节点组织成一棵Merkle树生成，利用哈希操作自底向上逐层计算出树根的值。其缺点是：计算无法个性化定制，即使只有一个桶的内容发生改变，重新计算Merkle根也会带来O(logN)的开销(N是作为叶节点的桶的个数)。另一方面，业务逻辑所需持久化操作若需进入输出共识就必须基于Fabric提供的API、Fabric选用的KV数据库进行，同时开发语言也只能局限于Fabric目前支持的两种语言(golang和java)，很大程度上限制了现有代码的重复利用、限制了现有程序员技能的重复利用，限制了开发业务逻辑所能利用的数据库。

发明内容

本发明的目的在于针对现有技术的不足，提供一种基于双链结构的高性能联盟区块链。

本发明的目的是通过以下技术方案实现的：一种基于双链结构的高性能联盟区块链BC，包含一个输入共识链和多个业务逻辑链。输入共识链节点个数为Ni，其中最多包含的恶意节点数为fi，根据BFT类算法的要求，Ni大于等于3fi+1；所述业务逻辑链中最多包含的恶意节点个数为fb。

客户端提交请求，输入共识链的节点基于共识算法为BC的全部客户发送的全部请求提供拜占庭容错的全序组播服务；输入共识链的全部正确节点都将看到全局一致的客户请求流。每个输入共识链的正确节点将客户请求流仍按请求流内的交易顺序向其下游的“业务逻辑链”发布。

业务逻辑链中的正确节点nd与输入共识链的Ni–fi个不同节点建立连接,获取客户请求流,若业务逻辑链中的正确节点nd获取大于等于fi+1个的一致的输入,则读取该输入中的序列<i1,i2,i3,…>，驱动业务逻辑链内部状态发生改变，同时产生有序的输出流<o1,o2,o3,…>，每个nd都向联盟链BC的客户c发送此输出流<o1,o2,o3,…>中和c在业务上相关的应答信息。

BC的客户c比对来自业务逻辑链各个节点的应答信息，并在获得fb+1个一致应答信息后可确信应答信息无误,fb为业务逻辑链中最多包含的恶意节点个数。

进一步地，客户端提交请求时，采用“多业务逻辑链和主题”的设计，为每个请求附带一个主题标签。

进一步地，客户端在对比应答时，采用“基于可观测状态的共识”的方法进行比对。

本发明的有益效果在于：本发明相比于Fabric，不限制业务逻辑的开发平台、开发语言和基础服务，同时提出了“基于可观测状态的共识”的新选择，将状态指纹的产生效率提升到O(1)的复杂度。与此同时，传统“基于完整状态的共识”的选择仍然对设计者开放。

附图说明

图1为该方法的整体架构图。

具体实施方式

一种基于双链结构的高性能联盟区块链BC，包含一个输入共识链和多个业务逻辑链。输入共识链节点个数为Ni，其中最多包含的恶意节点数为fi，根据BFT类算法的要求，Ni大于等于3fi+1；所述业务逻辑链中最多包含的恶意节点个数为fb。

客户端提交请求，输入共识链的节点基于共识算法为BC的全部客户发送的全部请求提供拜占庭容错的全序组播服务，例如，可以采用PBFT共识算法实现。输入共识链中每个正确节点都遵照协议规定的pre-prepare、prepare、commit三阶段算法运行，唯一的变化是：commit成功后只执行空操作，也即完全不执行业务相关逻辑，且不向client发送reply消息。

客户端提交请求m时，采用“多业务逻辑链和主题”的设计，可以为每个m附带一个主题标签，方法如下：

(a)可以采用的最简单的主题标签设计是：每个m只能赋予1个主题，想要把一个消息发送给多个主题，可以打上不同topic标签，提交多次。

(b)可以采用的复杂标签设计则是：可以附带许多个主题标签。

备注：同一BC的不同业务逻辑链对主题的订阅是独立的。订阅的本质是从单一的输入共识链输出流中根据m的主题标签过滤出自己关心的部分进行处理。如果需要有多个不同的输入共识链输出流，将其分在不同分区中就可以了，本专利不阐述这部分设计。

共识算法执行后，输入共识链的全部正确节点都将看到全局一致的客户请求流。一致性体现在：在正确节点看到的客户请求流中，下标seq相同的消息，其内容一定一致。

每个输入共识链的正确节点将客户请求流仍按请求流内的交易顺序向其下游的“业务逻辑链”发布。

业务逻辑链”中的正确节点nd与输入共识链的Ni–fi个不同节点建立连接,进行客户请求流获取,若“业务逻辑链”中的正确节点nd读到大于等于fi+1个的一致的输入m,则可以确定出现在全局输入流的seq位置上的消息确实是m(因为Ni≥3fi+1，故nd建立有至少Ni-fi≥2fi+1个这样的连接，其中至少fi+1个连接到业务逻辑链中的正确节点。此种方式下，业务逻辑链和一般的拜占庭容错集群存在少许不同，因为其正确节点的输入流已可确保一致，所以确保正确的条件可以放宽到Nb≥2fb+1)，nd就可以据此执行业务逻辑。

当Ni＝Nb时,还可以采用：在业务逻辑链节点和输入共识链节点之间建立一一对应关系,进行发布。由于此时两层链之间的耦合关系被强化，业务逻辑层看到的输入也不能确保正确，所以就应该把对应的一对业务逻辑链节点/输出共识链节点看作一个整体，fi＝fb，且必须Nb≥3fb+1。

业务逻辑链的每个正确节点nd读取输入共识链发布的客户请求流中的序列<i1,i2,i3，…>，驱动业务逻辑链内部状态发生改变，同时产生有序的输出流<o1,o2,o3,…>，每个nd都向联盟链BC的客户c发送此输出流<o1,o2,o3,…>中和c在业务上相关的应答信息。

BC的客户c比对来自业务逻辑链各个节点的应答信息，并在获得fb+1个一致应答信息后可确信应答信息无误,fb为业务逻辑链中最多包含的恶意节点个数。

客户端在对比应答时，采用“基于可观测状态的共识”的设计，根据应答中包含的信息量不同，实现这种比对所需的开销和能确保的内容也有所不同：

(a)可以采用的最简单的O(1)的做法是：<o1,o2,o3，…>不包含任何状态指纹，客户c满足于看到的应答顺序和内容经过共识确保正确。

(b)可以采用的另一种O(1)的做法是：oi中纳入一个preHash字段，o1.preHash＝0，oi.preHash＝hash(oi-1)，在输出序列上构成一个类区块链结构。

备注：有些区块链设计中，在应答之中会嵌入业务逻辑节点执行后系统完整状态的指纹(如fabric中的状态根)。这种指纹将系统内部状态作为白盒进行汇总，哪怕对最终客户而言某些信息与其无关也仍然要汇总。这种设计在本专利中仍然可以使用，但缺点前面也已指出。本专利提出“基于可观测状态的共识”这一新思路，也就是站在客户角度将系统看作黑盒。如果系统对客户展现出的可观测状态(通常是输出，查询的返回也是一种输出)确保是经过共识确保一致的，而客户又确实以此为足，则此时状态指纹的创建可以采用其他方式。