一种基于业务信任度对区块链共识进行动态调整的方法与流程

文档序号:11251683阅读:777来源:国知局
一种基于业务信任度对区块链共识进行动态调整的方法与流程

本发明属于信息技术领域,更为具体地讲,涉及区块链系统中一种基于业务信任度对共识进行动态调整的方法,以满足数据透明共享的动态需求,实现成本最小化。



背景技术:

现有基于p2p(peertopeer)对等网络的区块链系统中,并未考虑业务系统本身的可信性,均基于参与节点完全不可信的前提,完全依赖区块链提供信任机制,区块链系统对所有业务采用固定的共识方案,数据必须对系统中的所有节点完全透明,这种固化的方案一方面对数据传输和存储成本要求较高,另一方面违背了业务数据的隐私性。

而实际应用中,业务系统具有一定的可信性,例如银行、政务、大的企业集团等,他们提供的业务对用户而言是基本可信的,此时无需完全采用科技授信,所以对区块链的信任依赖主要用于监管、审计或自证清白。而某些应用场景,如银行之间的清结算、小贷行业联盟等,需要业务协作方之间共享数据、进行交互,这些协作方之间虽然是弱信任关系,但相比于完全不信任,参与节点故意捣乱的几率较小,此时数据仅需对区块链系统中的强相关业务方透明,再通过验证和共识达成可信存储。

因此,有必要提供一种基于业务信任度对共识进行动态调整的方法,能根据业务信任度对共识进行动态调整,也能定制不同业务数据在区块链系统中的共享透明程度。



技术实现要素:

本发明的目的在于克服现有技术的不足,提出一种基于业务信任度对共识进行动态调整的方法,实现对区块链系统中的共识进行动态调整,使数据可只对指定节点透明,而对其他节点只共享相应的哈希值,使区块链系统既能提供信任机制,又达到最小化成本,保护业务数据隐私的目的。

为实现上述发明目的,本发明基于业务信任度对共识进行动态调整的方法,其特征在于,包括以下步骤:

(1)、对于弱信任及完全不可信的应用场景,区块链系统中的节点代表相互协作的各个业务方,在业务部署时,为业务指定参与验证的节点集合和参与共识的节点集合:

1.1)、对于弱信任的应用场景,验证节点集合由业务协作中的强相关业务方节点构成,相互透明共享业务数据,其中的节点称之为验证节点;而共识节点集合可包含其他非强相关业务方的节点,但仅存放达成共识的操作结果hash值,其中的节点称之为共识节点;

1.2)、对于完全不可信的应用场景,为获得协作的方之间的相互信任,所有节点必须共享数据,共同验证操作的合法性和正确性,再对操作结果hash值达成共识存储,即验证节点集合和共识节点集合都包含所有节点;

(2)、对于弱信任及完全不可信的应用场景,区块链系统的工作流程为:

2.1)、业务系统向区块链系统发送数据操作命令,接收命令的服务节点为该数据操作命令对应业务的一个验证节点;

2.2)、该验证节点首先验证数据操作命令的合法性和正确性,不同的业务验证过程不同,与具体业务相关;如果验证成功,该验证节点将数据操作命令向验证节点集合中的其他节点发送,同时将该数据操作命令的操作结果hash值签名后向共识节点集合中的所有节点发送;

其他验证节点收到数据操作命令,进行同样的验证过程,如果验证成功,也将自己的该数据操作命令的操作结果hash值签名后向共识节点集合中的所有节点发送;

每个共识节点收集来自全部验证节点的操作结果hash值,进行多数一致判定,将判定结果以自己的私钥签名再转发给其他共识节点;在此基础上,所有共识节点再次进行一致性判定,达到共识后存储,验证节点得到共识的正确反馈后更新自己的链下共享数据库。

本发明的目的是这样实现的。

本发明基于业务信任度对共识进行动态调整的方法,在区块链系统中,将节点区分为验证节点和共识节点,数据只需在验证节点之间透明共享,弱信任或完全不可信的业务通过指定参与验证和共识的节点集合,既能达到协作方的信任,又能保护业务数据的隐私。

与现有技术相比,本发明具体有以下有益效果:

1、现有区块链系统采用的是一种固化不变的共识方案,以参与节点完全不可信任为前提,系统中所有节点必须拥有一份业务数据明文,在此基础上才能达成信任。而本发明基于业务信任度对共识进行动态调整的方法,在区块链系统中,通过结合业务信任、动态调整共识,使区块链系统针对不同业务信任的应用场景,降低了数据传输和存储的全网普及要求,既能保证系统受信任,又能实现成本的最小化,使区块链技术能被广泛接受使用。

2、现有区块链系统中的共识是一个单一过程,不能进行分离,而本发明中将此过程明确分为两个步骤:验证和共识。通过这样的分离,使得需要透明共享明文数据的验证节点可以和只保存数据hash值的共识节点区分开来,成为本发明动态调整共识方法的基础。

附图说明

图1是区块链系统结构示意图;

图2是本发明在弱信任及完全不可信应用场景下区块链系统与业务系统关系示意图;

图3是本发明在弱信任及完全不可信应用场景下区块链系统工作流程图;

图4是本发明在基本可信应用场景下区块链系统与业务系统关系示意图;

图5是本发明在基本可信应用场景下区块链系统工作流程图。

具体实施方式

下面结合附图对本发明的具体实施方式进行描述,以便本领域的技术人员更好地理解本发明。需要特别提醒注意的是,在以下的描述中,当已知功能和设计的详细描述也许会淡化本发明的主要内容时,这些描述在这里将被忽略。

由于现有区块链技术中固定不变的共识方法,数据必须在每个节点透明共享,使得整个区块链网络具有极大的传输和存储压力;而且,真实业务中,数据是一个业务方的核心价值所在,除了必须要进行共享的内容、以及必须要与之共享的对等业务方,业务方会强烈要求保持数据的隐私性。现有的强制透明共识,将导致依赖区块链的业务协作最终不能进行。

本发明涉及的区块链系统是一种基于p2p(peertopeer)对等网络,如图1所示,区块链系统由多个(n个)对等节点连接而成,构成网格网络,可根据业务信任,动态定制区块链系统的共识方式。

区块链的本质是采用科技手段提供信任机制,而实际应用中,业务信任度本身存在着完全可信、基本可信、弱信任和完全不可信四个等级。因此,业务系统对区块链提供的业务信任度具有弹性需求;此外,业务方也不希望区块链系统中的其他业务方节点轻易获取到自己的敏感数据。本发明的区块链系统可结合业务信任的不同等级(业务信任度),动态定制共识方案,既能满足区块链的受信任、防篡改、可追溯等特性,也能兼顾实际应用中对数据隐私保护的需求。

为了达到以上要求,在本实施例中,本发明采用以下技术方案:首先,将区块链系统中的节点区分为验证节点和共识节点,数据只需在验证节点之间透明共享,弱信任或完全不可信的业务通过指定参与验证和共识的节点集合,既能达到协作方的信任,又能保护业务数据的隐私;其次,将区块链系统中的数据链分离为链上数据和链下数据,针对基本可信场景,只使用数据链存放链上数据hash值。

1、业务信任度为弱信任及完全不可信的应用场景

对于弱信任及完全不可信的应用场景,图1所示区块链系统中的节点代表了相互协作的各个业务方,在业务部署时,在区块链系统中为业务指定参与验证的节点集合和参与共识的节点集合。

具体到弱信任的应用场景,验证节点集合由业务协作中的强相关业务方节点构成,相互透明共享业务数据,而共识节点集合可包含其他非强相关业务方的节点,但仅存放达成共识的操作结果hash值。

而对于完全不可信的应用场景,为获得协作方之间的相互信任,所有节点必须共享数据,共同验证操作的合法性和正确性,再对操作结果hash值达成共识存储,即验证节点集合和共识节点集合都包含所有节点。

在本实施例中,如图2和图3,这两种情况下区块链系统的工作流程如下:

步骤s101:业务系统向区块链系统发送数据操作命令,接收命令的服务节点为该业务(数据操作命令对应业务)的一个验证节点,如图2中的节点1或节点3。该验证节点首先验证数据操作的合法性和正确性,不同的业务验证过程不同,与具体业务相关。

步骤s102:如果验证成功,该验证节点将操作命令向验证节点集合中的其他节点发送,同时将操作结果hash值签名后向共识节点集合中的所有节点发送。

步骤s103:其他验证节点收到操作命令,进行同样的验证过程,如果验证成功,也将自己的操作结果hash值签名后发送给所有共识节点。

步骤s104:每个共识节点收集来自全部验证节点的操作结果hash值,进行多数一致判定,将判定结果以自己的私钥签名再转发给其他共识节点。

步骤s105:在此基础上,所有共识节点再次进行一致性判定,达到共识后存储,验证节点得到共识的正确反馈后更新自己的链下共享数据库,如图2中的节点1和节点3。

在本发明中,将区块链系统中达成一致性的步骤区分为两步:验证和共识。使用区块链的业务需提前在区块链系统中进行部署,部署时指定参与验证的节点集合和参与共识的节点集合。针对弱信任的应用场景,参与验证的节点集合局限于强相关业务方,并作为参与共识的节点集合的子集;而针对完全不可信的应用场景,验证和共识的节点集合应包含所有节点。弱信任、完全不可信以及强相关业务方等可以根据具体实施情况确定。

所述验证是指对发送到区块链系统的数据操作进行合法性和正确性的逻辑验证,必须基于数据明文进行,所以数据必须在验证节点之间透明共享。

所述共识是指对验证成功之后的操作结果进行一致性判定,当大多数共识节点投票结果一样则达成可信存储。

所述部署是指当业务要使用区块链系统之前,对业务进行定制和描述,即设置业务的名称、验证节点集合、共识节点集合等信息。验证节点集合由一个或多个强相关业务方的节点构成,共识节点集合除了包含验证节点集合之外,还可包含其他业务方的节点,用以共识验证阶段的操作结果hash值,所以业务数据无需对共识节点开放透明。

区块链系统中由服务节点接收外部(来自业务系统)的数据操作命令,服务节点属于该业务的验证节点集合。当它收到数据操作命令后,首先对数据操作进行逻辑验证,验证方法与具体业务相关,如数字货币应用需验证用户余额是否足够,同一货币是否被支付给两个人(即双花)。验证成功后,服务节点把数据操作命令明文和操作结果hash值广播给其他的验证节点,同时也把数据操作结果hash值广播给该业务的所有共识节点。其他验证节点收到数据操作命令后,基于自己本地的数据备份,执行验证工作,同样也将操作结果hash值进行广播。所有节点监听、收集其他节点的返回结果,进入第二个步骤的共识过程。

所述区块链系统由多个节点构成,服务节点是某个业务验证节点集合中的任意一个,可同时存在多个服务节点,负责接收来自业务系统的数据操作命令。

某个业务的所有共识节点都要对接收到的操作结果hash值进行共识。每个共识节点使用自己的私钥对操作结果hash值进行签名,其他共识节点通过公钥验签,当大多数共识节点投票结果一致则可达成该hash值的可信存储。所有节点收集一段时间内的多个hash值形成区块、再构成链。

所述共识节点,也包含了同时担当验证节点角色的共识节点。

所述公、私钥是指非对称加密算法rsa的公钥和私钥,可用于表示每个节点身份。

所述大多数节点投票,是指至少超过半数共识节点广播的hash值一样,达成一致性的节点数目可配置。

2、业务信任度为基本可信的应用场景

对于基本可信的应用场景,图1所示区块链系统中的节点由业务方以及监管方或审计方等业务相关方共同提供,仅存储数据链的链上数据hash值,而链下数据明文则由业务系统自行保存在自己的链下数据库中。

图4展示了基本可信应用场景下区块链系统与业务系统交互关系。业务系统事先确定需要存放在区块链上的数据内容,并设计链下数据库。在进行业务操作的过程中,业务系统计算出每条链下数据明文记录的hash值即链上数据hash值,通过调用区块链的上链接口,将链上数据hash值传送到区块链系统进行共识存储。

结合图4,如图5所示,基本可信应用场景下区块链系统工作流程的步骤为:

步骤s201:区块链系统由一个服务节点接收业务系统发送过来的链上数据hash值,用自己的私钥签名后广播给其他所有节点;

步骤s202:其他节点接收到服务节点发送的链上数据hash值之后,首先验证服务节点签名,确认该hash值确实是服务节点发送的消息,然后以自己的私钥签名后再次进行转发广播。

步骤s203:每个节点都会收到其他n-1个节点发送的hash值备份,再加上自身保留的hash值,每个节点对n个hash值进行多数一致判定,达成共识后存储。

在本实施例中,业务信任度为基本可信的应用场景,仅对数据链的链上数据hash值进行共识,仅支持数据的链式存储结构,将链下数据与链上数据分离。在业务基本可信的情况下,业务系统通过上链接口将链下数据对应的链上数据hash值传送给区块链系统,系统中的所有节点对链上数据hash值达成共识后存储,并收集一段时间内的多个链上数据hash值形成区块、再构成链。

区块链系统由多个对等节点构成分布式网络,节点相互通信达成数据的一致性后,采用链式结构存储。

所述链下数据是指业务相关的明文数据。

所述链上数据hash值是指针对每条明文数据的hash值。

所述链下数据与链上数据分离,是指链下数据存放在业务系统的私有数据库中,而对应的链上数据hash值由区块链系统的每个节点存放,明文数据不会在区块链系统的节点间透明。

所述共识由区块链系统中的每个节点参与,对接收到的链上数据hash值进行一致性判定,大多数节点投票达成一致后存储,大多数节点数量根据具体实施情况确定。

所述区块包含一个区块头,记录了前一个区块的hash值、块中所有数据hash值的merkle根、块中数据hash值的起始索引、块号、时间戳。

尽管上面对本发明说明性的具体实施方式进行了描述,以便于本技术领域的技术人员理解本发明,但应该清楚,本发明不限于具体实施方式的范围,对本技术领域的普通技术人员来讲,只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内,这些变化是显而易见的,一切利用本发明构思的发明创造均在保护之列。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1