一种委员会决策投票方法、系统、介质、设备及终端

1.本发明属于区块链与智能合约技术领域，尤其涉及一种委员会决策投票方法、系统、介质、设备及终端。


背景技术：

2.目前，随着加密数字货币的快速发展和区块链技术在各行业的应用，区块链渐渐引起了全球的关注。随着智能合约与应用相结合，大量数字资产在智能合约上储存和交易。但是智能合约在区块链上运行，具有一经部署就无法对其进行篡改的特点，所以智能合约如果存在安全漏洞，就无法对已经部署在区块链上的智能合约代码进行修改。所以在区块链与智能合约结合的应用中，管理好智能合约和保证智能合约安全有序的运行是非常必要的。
3.在hyperledger fabric中，通常智能合约定义的是控制世界状态中业务对象生命周期的交易逻辑，随后该交易逻辑被打包进链码，紧接着链码会被部署到区块链网络中。fabric的角色按照功能可以分为客户端节点、peer节点和order节点。客户端节点是负责与用户交互的节点，peer节点是负责存放区块数据的节点，order节点是负责将交易排序和打包进区块的节点。fabric交易都是通过链码来完成的，用户只能通过链码来与账本交互，每一条链码都会在安装的时候设置背书策略，设置链码需要哪些成员参与背书。在客户端发起交易请求时会根据链码设置的背书策略，将该交易提案发送到对应的背书节点进行背书。
4.当背书节点收到来自客户端的背书请求时会自动进行如下操作。首先，背书节点用客户端的公钥验证它的签名、客户端是否有权限可以在该通道进行交易、交易是否已被提交、交易提议组织是否正确。验证通过后背书节点会模拟执行交易提案，将执行的结果反馈给客户端。客户端收到足够多的背书节点的结果后，表示这个交易已经正确背书。如果客户端没有搜集到足够多的背书节点反馈的背书信息，这个交易就会被舍弃。fabric背书的过程完全是由fabric底层背书节点自动完成的，无法人为的干预参与背书，只要链码语法逻辑符合语法规则，那么客户端发起请求调用链码就能成功与账本交互，背书节点无法控制是否要参与本次的交易背书，以及背书用户无法给出主观意见进行判断背书结果。如果联盟内部出现了恶意节点，恶意的使用链码来修改账本中的数据，从而导致了账本数据混乱不安全的情况。
5.针对这种情况，fabric有着一些关于链码管理的相关措施，比如自定义背书策略来实现对链码的控制；开发系统链码插件来拒绝一些不规范的链码调用；或者是自定义背书逻辑和自定义验证逻辑的插件来自定义链码背书过程。但是这些方案背书的过程也都是自动的，不能有效地有效地干预背书节点背书的过程，不能彻底地解决问题。
6.在联盟链fabric中，每个链码都有一个背书策略与之相关联，这个背书策略定义了在智能合约生成的交易被认证为有效之前，需要通过制定好的组织认可才可以被提交到链上。当用户调用智能合约发送一次交易请求时，客户端会自动将交易提案发送给该链码
背书策略指定的背书节点，背书节点会模拟执行该交易，并为执行结果签名返回给客户端。背书节点背书的过程是自动的，只验证交易结果是否正确，无法对联盟成员提出的交易内容进行审查。
7.通过上述分析，现有技术存在的问题及缺陷为：
8.1.在fabric中，交易的背书过程完全是由背书节点自动完成，只验证交易格式是否正确，但无法判断交易的内容是否符合交易对象的主观意愿。现有技术方案不能有效地有效地干预背书节点背书的过程，无法对联盟成员提出的交易内容进行审查，从而会导致一些不合规范的或者是错误的数据上链，最终导致链上数据混乱、不可靠、不安全的问题。
9.2.联盟链的优点就是在于它由权限控制，但是联盟链fabric中没有一个特殊的机构来管理和保证联盟内的事务有序运作，也没有机构来管理链码的发布以及使用状况，从而导致无法保证交易内容以及上链数据的事实正确性的问题。


技术实现要素：

10.针对现有技术存在的问题，本发明提供了一种委员会决策投票方法、系统、介质、设备及终端，尤其涉及一种基于联盟链的委员会决策投票方法、系统、介质、设备及终端。
11.本发明是这样实现的，一种委员会决策投票方法，所述委员会决策投票方法包括：(1)设计联盟决策委员会的组织结构，通过该委员会来对联盟事务进行管理；(2)设计了针对安全等级较高的账本写入操作设置投票机制，并且设计和实现了针对不同事务类型的审批的流程；(3)设计并实现了在投票机制中的身份验证机制，使用非对称密钥技术和门限群签名技术核验审批人的身份。
12.进一步，所述委员会决策投票方法包括以下步骤：
13.步骤一，基于fabric底层组织结构的联盟决策委员会的设计；
14.步骤二，基于fabric链码的投票机制的设计；
15.步骤三，基于fabric-msp的权限管理与身份验证的设计。
16.进一步，所述步骤一中的联盟决策委员会的设计包括：
17.(1)联盟事务管理：用于管理联盟内部事务以及联盟内链码生命周期。
18.联盟决策委员会对联盟内部事务管理，包括需要修改的重要信息的操作，以及联盟内对链码发布的管理。联盟决策委员对联盟内部的事务进行审批，当联盟成员向委员会发起一次事务请求，联盟决策委员会成员依次对事务进行投票审批，委员会成员审批同意事务请求后自动累计票数，在绝大多数成员审批同意后，事务继续执行，否则事务将被无视并销毁。
19.(2)委员会内部事务管理：用于联盟决策委员会对自身事务的管理。
20.联盟决策委员会对自身事务的管理又称作委员会自身运行机制的日常管理，包括联盟成员的加入与联盟决策委员会成员退出两个方面。
21.当联盟内成员加入委员会时，在绝大委员会成员同意批准后，成员加入委员会参与后续的决策；当有新的成员加入后，自动的更新委员会成员信息，并在下一次决策新成员将参与决策，请求需要满足的最低同意票数随着成员的加入而更新。委员会成员主动提出请求退出委员会，如果委员会成员出现不合规定的操作导致联盟内部运转出现问题，则委员会的其他成员有权力发起强制提出请求，在绝大多数委员会成员的同意后，委员会成员
被强制踢出委员会。
22.进一步，所述步骤二中的投票机制设计包括：
23.投票过程在fabric底层环境链码votingdecision中实现，设计与开发实现votingdecision链码的功能分为三个部分：创建申请请求包createapplication、处理申请请求包processapplication以及查看申请包状态checkapplication。
24.其中，所述链码包含成员结构体和申请包结构体，所述申请包结构体包括事件结信息构体、申请人信息结构体、记录委员会成员批准状态结构体、投票计数和申请包状态。
25.进一步，所述步骤二中的投票机制设计具体包括：
26.(1)申请请求包设计：
27.申请人提出申请，填写信息，调用链码中createapplication方法，创建新申请包，创建完毕将请求包上链；其中，所述新申请包括申请人信息、事件信息、委员会成员批准状态、投票计数以及申请包状态。
28.请求包内容包括事件信息、申请人信息、委员会成员投票信息、申请包得到同意的票数、申请包状态。事件信息包括事件id和事件类型。客户端通过唯一的事件id来查询请求包的具体内容。事件类型根据业务和委员会机制分为加入委员会、退出委员会和链码发布等。申请人信息包含申请人节点信息、请求描述和请求人证书。
29.委员会成员投票信息记录着现有委员会成员对请求包的审批情况。申请包状态根据申请步骤分为三种：新申请包创建的状态为create，第一次由委员会成员审批后申请包状态变为process，当请求包达到决策票数后变为success。
30.创建申请包的流程如下：1)初始化申请人信息：查询该成员信息，取出成员的publickey存入申请包；2)初始化事件信息；3)初始化委员会成员批准状态approvalstatus：查询委员会成员信息，使用委员会的节点名称存入approvalstatus，并初始化为false；4)初始化请求包计数为0；5)初始化申请包状态为create；6)将本次创建请求的交易id作为请求包的id，请求包以请求包的id当作key存入账本。
31.(2)审批请求包设计：
32.委员会成员审批时，调用链码中processapplication方法，验证批准人是否为委员会成员，判断申请是否满足条件，满足则对事件做出响应。
33.请求包的审批由委员会成员执行，委员会成员通过使用非对称密钥验证身份，验证成功后则调用链码执行审批操作，如果验证不成功则返回错误身份权限不够。其中，链码审批操作的过程如下：
34.①
根据请求包的id取出请求包内容，设置申请包状态为process；
35.②
根据节点名获取节点信息：查询成员信息，判断成员是否为委员会成员；
36.③
委员会成员使用私钥对申请包id进行签名；
37.④
获取委员会成员的公钥，验证签名，如果签名验证成功则计数加一，遍历状态切片，修改成员的批准状态，找到委员会成员的节点名称，并将状态修改为true；
38.⑤
判断请求结果，申请满足绝大部分委员会成员同意后，批准申请人的申请并执行事件；
39.⑥
判断请求的结果，如果没有达到委员会决策的人数，则将签名验证后的申请包上链，提供其他批准人审批。
40.进一步，所述步骤三中的身份验证设计包括：
41.(1)签名与验签
42.采用基于shamir密钥共享算法之上的椭圆曲线的分布式(k,v)门限签名方案。
43.(2)批准人身份验证
44.使用联盟成员的公私钥对核验成员的身份；创建申请时，将公钥保存到链上；在审批过程中使用批准人的私钥为申请人的公钥进行签名；获取批准人的公钥验证委员会成员的身份，公钥存于委员会成员信息中；如果在委员会成员信息中没有找到符合的公钥或公私钥不匹配，则身份验证不成功，审批不生效。
45.基于fabric证书体系的身份验证机制将联盟决策委员会成员的信息记录在联盟内的账本中，当委员会成员进行对联盟事务的审批时，通过本地的私钥对该请求包加密，再使用该成员存储在链上信息中的公钥对该加密后的信息进行验证，验证成功将加密后的数据写进申请包中并更新链上的申请包状态；联盟内的所有成员均可查询联盟决策委员会成员的信息，使用其中委员会成员的公钥验证申请审批中签名以后的内容，实现身份验证机制。
46.本发明的另一目的在于提供一种应用所述的委员会决策投票方法的委员会决策投票系统，所述委员会决策投票系统包括：
47.联盟决策委员会设计模块，用于进行基于fabric底层组织结构的联盟决策委员会的设计；
48.投票机制设计模块，用于进行基于fabric链码的投票机制的设计；
49.身份验证设计模块，用于进行基于fabric-msp权限管理与身份验证的设计。
50.本发明的另一目的在于提供一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述的委员会决策投票方法的步骤。
51.本发明的另一目的在于提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述的委员会决策投票方法的步骤。
52.本发明的另一目的在于提供一种信息数据处理终端，所述信息数据处理终端用于实现所述的委员会决策投票系统。
53.结合上述的技术方案和解决的技术问题，本发明所要保护的技术方案所具备的优点及积极效果为：
54.为了能够使用户有意识地判断交易内容，并参与到背书的过程中，本发明实现了一种委员会决策投票机制，通过投票的方式来判断交易是否同意执行。联盟成员执行交易需要通过联盟决策委员会人为地去判断交易内容，才能做出最后决策来决定该交易是否允许进行。
55.1)本发明设计了联盟决策委员会的组织结构，该组织内成员代表所有的联盟成员，可以参与联盟内事务的管理，共同维护联盟有序运行。
56.2)本发明针对安全等级较高的账本写入操作设置了投票机制，执行一次重要的交易需要发起申请请求，需要通过绝大多数委员会成员同意交易申请后该交易才可以进行。
57.3)本发明还在投票机制中增加了身份验证的机制，通过fabric中的身份权限管理，使用非对称密钥技术和门限群签名技术核验审批人的身份。
58.通过上述方案，可以成功解决背书成员无法根据交易内容判断交易是否合法的缺点，通过委员会成员投票决策来对交易进行审批判断，并且审批过程都记录在链上，具有公开透明、可追溯、不可篡改等特点，保证了投票决策的过程的安全性与可靠性。
59.本发明针对用户无法判断交易内容的合法性，通过联盟决策委员会成员的审批，在链码层面针对用户与账本之间的操作加入投票决策与身份验证的机制，限制了应用层随便调用链码修改账本数据，避免现有技术存在的问题。
60.本发明主要分为三大模块：
61.1)基于fabric底层组织结构的联盟决策委员会的设计。本发明设计了一种联盟决策委员会的特殊组织结构，联盟决策委员会在联盟内是一个特殊的组织，该组织下的成员共同管理这整个联盟。联盟内成员可以通过向联盟委员会申请来加入该委员会，成为参与管理联盟事务的委员会成员。同样当委员会成员出现了问题违背了联盟内的规则，那么其他委员会成员也有权利发起强制剔除该委员会成员。联盟内重要事务的决策都需要通过联盟决策委员会成员来共同商讨，最终才能判断该事务是否可以在联盟内进行。本发明针对联盟内事务主要是指联盟内链码发布与部署，因为链码是用户为了实现某种业务的逻辑代码，如果用户编写的链码存在安全漏洞或者是恶意节点故意传播存在漏洞的链码，都会导致区块链网络变得混乱或者是瘫痪。因此本发明主要针对用户发布的链码进行审批，来避免上述问题的产生。
62.2)基于fabric链码的投票机制的设计。本发明设计了一种在链码层面的投票机制，联盟决策委员会通过投票的方式来共同决策判断联盟事务。事务类型可以分为两个：联盟内部事务和委员会事务。联盟内部事务针对的是链码生命周期的管理，而委员会事务针对的是联盟决策委员会人员管理。这些事务只有通过绝大多数的委员会成员同意才会被执行，否则事务将会被舍弃。最后投票的过程与结果都会被详细地记录在链上，来保证投票决策的过程是安全、公开、可追溯的，使得决策结果是可靠、可信、具有说服力的。
63.3)基于fabric-msp的权限管理与身份验证的设计。本发明通过fabric自带的权限管理之上使用链码逻辑实现了签名验证的功能。该链码可以将公钥上传到区块链网络中，当要进行验证身份的时候，只要是在该区块链网络成员都可以使用公钥对私钥签名后的数据验证身份。在联盟决策委员中，链上会保存委员会成员的信息(成员名称、节点名称、公钥等)，每次委员会成员对事务审批时，都会从链上读取该委员会成员的公钥，来验证该委员会成员是否为委员会成员，只有通过验证的成员才有权限继续对事务的审批。
64.本发明在fabric基础之上，构建了用于管理联盟的联盟决策委员会的特殊组织结构，并且在委员会中采用决策投票的机制来进行联盟内各种重大事务的审批，最后结合fabric自身的身份权限管理实现投票机制中的权限管理与身份验证，使联盟管理与决策更加科学和安全可靠。通过以上三个模块，本发明实现了在背书节点背书之前需要经过联盟决策委员会投票审批的过程，来解决背书节点不能主观判断交易内容是否合法的问题；另一方面，通过联盟决策委员会对联盟内链码部署的控制，减少了问题链码和恶意链码的部署和使用。
65.本发明提出了一种基于联盟链的委员会决策投票系统，通过构建联盟决策委员会，通过委员会投票的机制来管理整个联盟。本发明运用pki证书体系、背书机制、msp权限策略和链码生命周期等技术和方案制定了实现了联盟内部事务管理，为委员会成员提供了
检查交易内容的权限，为联盟内部事务的执行提供了一个有序的安全的可靠的环境。本发明设计并且实现了三种基本类型的联盟事务管理，可以满足绝大多数联盟管理要求，并且投票机制中结合分布式门限签名技术保证了联盟事务的安全性，最后通过实验与分析证明了本发明提出的委员会决策投票系统具有良好的性能与安全性。
66.本发明的技术方案转化后的预期收益和商业价值为：本发明的技术方案可以对交易内容的真实性进行评估，避免恶意交易的发生，防止有不合法的数据上链，为用户提供一个更为安全的交易运行环境。
67.本发明的技术方案填补了国内外业内技术空白：本发明的技术方案在交易机制方面，通过使用委员会投票机制来管理联盟内部事务，填补了无法针对交易背书进行主观控制的技术空白。
68.本发明的技术方案是否解决了人们一直渴望解决、但始终未能获得成功的技术难题：本发明的技术方案通过构建联盟决策委员会，并通过投票决策的机制，解决了上链数据是否真实有效的问题。
附图说明
69.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图做简单的介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下还可以根据这些附图获得其他的附图。
70.图1是本发明实施例提供的委员会决策投票方法流程图；
71.图2是本发明实施例提供的委员会决策投票方法原理图；
72.图3是本发明实施例提供的委员会组织结构与映射关系示意图；
73.图4是本发明实施例提供的联盟事务管理流程图；
74.图5是本发明实施例提供的链码结构示意图；
75.图6是本发明实施例提供的申请包结构体设计示意图；
76.图7是本发明实施例提供的身份验证流程图；
77.图8是本发明实施例提供的智能合约性能测试结果示意图。
具体实施方式
78.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
79.针对现有技术存在的问题，本发明提供了一种委员会决策投票方法、系统、介质、设备及终端，下面结合附图对本发明作详细的描述。
80.为了使本领域技术人员充分了解本发明如何具体实现，该部分是对权利要求技术方案进行展开说明的解释说明实施例。
81.如图1所示，本发明实施例提供的委员会决策投票方法包括以下步骤：
82.s101，基于fabric底层组织结构的联盟决策委员会的设计；
83.s102，基于fabric链码的投票机制的设计；
84.s103，基于fabric-msp(成员关系服务提供者)权限管理与身份验证设计。
85.作为优选实施例，如图2所示，本发明实施例提供的委员会决策投票方法具体包括以下步骤：
86.(1)联盟决策委员会设计：
87.基于fabric地层特点，设计与实现针对联盟内部的事务管理的联盟决策委员会。联盟决策委员会功能主要分为两部分：委员会内部事务管理和联盟事务管理。
88.(2)投票机制设计：
89.实现了联盟内部事件决策投票过程，该过程的投票权在联盟决策委员会，只有联盟决策委员会成员才可以对事件进行审批，该过程大致分为以下几个部分：申请人提出申请、委员会成员审批、查看请求的审批进度。
90.(3)身份验证设计：
91.基于fabric证书体系，进行对身份的验证。该模块分为两大部分：非对称密钥签名验签的实现和审批人身份验证的设计。
92.本发明实施例提供的委员会决策投票的设计方法如下：
93.(1)联盟决策委员会设计
94.如图3所示，联盟决策委员会的设计是本发明的分析基础，下面的投票机制是基于委员会结构来实现的。联盟决策委员会是针对联盟内部进行设计的，该联盟决策委员会主要用于两大方面：委员会内部事务管理和联盟事务管理。
95.概念解释：1)通道：通道是基于数据隔离和保密构建的通信信道，是若干个特定网络成员之间通信的专用子网，用于进行私有和机密的交易。网络中每个通道都是独立、隔离的，并且都维护一个账本，保证了一个通道内事务的隐私性与安全性：在联盟链中一个通道就代表一个联盟。2)组织：网络中的参与者，一般代表机构或团体，组织下面有不同类型的成员：节点，管理员与用户，一个组织可以加入不同的通道，若干个组织可组成一个业务联盟。
96.该联盟中一共有三个组织，其中组织一为委员会组织，该组织下面节点为各个组织管理员，各个组织管理员必须都加入委员会组织，并且对新加入该联盟的组织进行审批投票，获得委员会绝大多数人的同意才可加入，并在委员会组织中增加一个节点分配给新组织管理员。如果通道中的一个用户需要发布链码，该链码需要满足通道内定义的链码生命周期背书策略“绝大多数”组织管理员同意后才可以发布。简单来说，委员会机制就是将通道内的组织管理员映射成为委员会审批链码的成员，这些管理员拥有审批链码发布的功能，并且通道内的链码需要满足通道内链码生命周期的策略，这条链码才可以被投入通道内供其他成员使用。
97.1)联盟事务管理：
98.该部分的设计用于管理联盟内部事务以及联盟内链码生命周期的管理。联盟内发布链码需要经过委员会的审批，只有通过了委员会的审批，链码才会被认可才可以被安装和使用。
99.联盟事务管理具体包括：
100.联盟决策委员会对联盟内部事务管理，一共分为两个部分：一是针对需要修改一些较为重要的信息的操作，那么就需要联盟决策委员会的介入。二是联盟内对链码发布的
管理，只有经过委员会审核的链码才可以在该联盟内使用，避免了恶意链码的安装。
101.如图4所示，联盟决策委员会对联盟内部的事务进行审批，当联盟成员向委员会发起一次事务请求，联盟决策委员会成员依次会对该事务进行投票审批，委员会成员审批同意事务请求后自动累计票数，在绝大多数成员审批同意后，该事务才可以继续执行，否则该事务将被无视并销毁。
102.2)委员会内部事务管理：
103.该部分为联盟决策委员会对自身事务的管理。联盟决策委员会为联盟中一个特殊的组织，该组织内的成员需要有效的管理，才能让联盟内部有序的运作。
104.委员会内部事务管理具体包括：
105.联盟决策委员会对自身事务的管理，又可以称作委员会自身运行机制的日常管理。本发明将从联盟成员的加入与联盟决策委员会成员退出两个方面进行展开。
106.当联盟内成员想要加入委员会时，在绝大委员会成员同意批准之后，该成员才可以加入委员会参与后续的决策。当有新的成员加入后，会自动地更新委员会成员信息，并且在下一次决策新成员将参与决策，请求需要满足的最低同意票数也会随着成员的加入而更新。
107.委员会成员也可以主动提出请求退出委员会。同样如果委员会成员出现了不合规定的操作导致联盟内部运转出现了问题，那么委员会的其他成员有权力发起强制提出请求，在绝大多数委员会成员的同意之后，该委员会成员会被强制踢出委员会。
108.(2)投票机制设计
109.该模块内容的设计为本发明的核心内容，也是联盟决策委员会内部运转的机制。其中投票过程实在fabric底层环境链码votingdecision(投票链码)中实现。设计与开发实现votingdecision链码，功能主要分为三个部分：createapplication(创建申请请求包)、processapplication(处理申请请求包)、checkapplication(查看申请包状态)。
110.该链码包含了以下几个结构体：成员结构体、申请包结构体(事件结信息构体、申请人信息结构体、记录委员会成员批准状态结构体、投票计数、申请包状态)，如图5所示。
111.投票机制主要分为以下两个模块：
112.1)申请请求包设计：
113.申请人提出申请。填写信息，调用链码中createapplication方法，创建新申请包(申请人信息、事件信息、委员会成员批准状态、投票计数、申请包状态)创建完毕将请求包上链。
114.申请请求包设计过程具体包括：
115.请求包内容主要有以下几个部分：事件信息、申请人信息、委员会成员投票信息、申请包得到同意的票数、申请包状态。事件信息包括事件id和事件类型。客户端可以通过唯一的事件id来查询请求包的具体内容。事件类型根据业务和委员会机制可以分为加入委员会、退出委员会和链码发布等。申请人信息包含了申请人节点信息、请求描述和请求人证书。
116.委员会成员投票信息记录着现有委员会成员对请求包的审批情况。申请包状态根据申请步骤分为三种：新申请包创建的状态为create，第一次由委员会成员审批后申请包状态变为process，当请求包达到了决策票数后变为success。
117.创建申请包的主要流程如下：1.初始化申请人信息：查询该成员信息，取出该成员的publickey(公钥)存入该申请包。2.初始化事件信息。3.初始化approvalstatus(委员会成员批准状态)：查询委员会成员信息，使用委员会的节点名称存入approvalstatus，并初始化为false。4.初始化请求包计数为0。5.初始化申请包状态为create。6.将本次的创建请求的交易id作为该请求包的id，并且该请求包以该请求包的id当作key存入账本。
118.2)审批请求包设计：
119.委员会成员审批时候，调用链码中processapplication方法，验证批准人是否为委员会成员，判断申请是否满足条件，满足则对事件做出响应。
120.审批请求包设计过程具体包括：
121.请求包的审批是由委员会成员来进行的，委员会成员通过使用非对称密钥来验证自己的身份，验证成功之后则会调用链码执行审批操作，如果验证不成功则返回错误身份权限不够。链码审批操作的过程如下：
122.①
根据请求包的id取出请求包内容，设置申请包状态为process。
123.②
根据节点名获取本节点信息：查询该成员信息，判断成员是否为委员会成员。
124.③
该委员会成员使用私钥对申请包id进行签名。
125.④
获取该委员会成员的公钥，验证签名，如果签名验证成功则计数加一，遍历状态切片，修改该成员的批准状态，找到该委员会成员的节点名称，并将其状态修改为true。
126.⑤
判断请求结果，申请满足绝大部分委员会成员同意后，批准申请人的申请并执行事件。
127.⑥
判断该请求的结果，如果没有达到委员会决策的人数，那么将签名验证后的申请包上链，提供其他批准人审批。
128.(3)身份验证设计
129.本发明设计了一种基于fabric证书体系的身份验证机制。该模块为本发明提供了安全保障，在联盟决策委员会成员审批操作时，需要提供该成员私钥进行签名，使用委员会成员公钥进行验证，确定为委员会成员才可以进行审批的操作。
130.1)签名与验签
131.本发明采用基于shamir密钥共享算法之上的椭圆曲线的分布式(k,v)门限签名方案。该方案相比于传统的shamir密钥共享方案上进一步地做了适应区块链环境的优化。该方案不需要可信中心参与初始化工作与秘密发分发，而是区块链节点之前探讨得出组密钥，更加地安全避免中心化带来的风险。其次采用椭圆曲线算法可以降低密钥长度，相比于其他的加密算法，安全性更高，计算量更小。再有该方案在区块链节点不泄露密钥信息的条件下，区块链节点可以验证其他节点发送过来的消息是否有效。
132.2)批准人身份验证
133.如图7所示，本发明通过使用联盟成员的公私钥对来核验成员的身份。首先在创建申请时，会将公钥保存到链上，然后在审批过程中使用批准人的私钥为申请人的公钥进行签名，最后获取批准人的公钥来验证委员会成员的身份，该公钥存于委员会成员信息中，如果在委员会成员信息中没有找到符合的公钥或者是公私钥不匹配，则身份验证不成功，这次的审批也不会生效。
134.基于fabric证书体系的身份验证机制将联盟决策委员会成员的信息记录在联盟
内的账本中，当委员会成员进行对联盟事务的审批时，需要通过本地的私钥对该请求包加密，然后使用该成员存储在链上信息中的公钥对该加密后的信息进行验证，验证成功将加密后的数据写进申请包中并更新链上的申请包状态。此外，联盟内的所有成员都可以查询联盟决策委员会成员的信息，使用其中委员会成员的公钥来验证申请审批中签名以后的内容，保证了只有委员会成员才有审批申请包进行投票决策的权限，实现了公开、透明的身份验证机制。
135.为了证明本发明的技术方案的创造性和技术价值，该部分是对权利要求技术方案进行具体产品上或相关技术上的应用实施例。本发明已经在基于fabric的区块链基础设施平台、面向制造业的dapp平台以及基于hyperledger fabric联盟链的链码管理与安全系统投入使用并取得不错的成效。
136.在基于fabric的区块链基础设施平台中，根据本发明的委员会组织结构，为用户提供并创建一个管理联盟的联盟决策委员会组织，将各个组织的管理员节点映射成为委员会组织的成员节点，构成联盟决策委员会来管理联盟内的事务，委员会成员可以通过投票的方式来共同决策联盟内重大事务的执行。
137.在面向制造业的dapp平台中，使用本发明的技术方案，通过联盟决策委员会成功有效地管理了联盟内的交易，各个交易事务都是经过委员会的审批认证，为该平台的交易提供了一个安全可靠的运行环境。
138.在基于hyperledger fabric联盟链的链码管理与安全系统中。使用本发明的技术方案，来管理联盟内的事务以及联盟内的链码。通过联盟决策委员会决策投票机制来对新链码的发布进行审核，只有通过审核的链码才允许被发布。除此之外，还使用该方案，针对了联盟内特殊事务的审批。
139.本发明实施例在研发或者使用过程中取得了一些积极效果，和现有技术相比的确具备很大的优势，下面内容结合实验过程的数据、图表等进行描述。
140.1、基于门限签名委员会决策投票过程实现
141.该方案有两个部分组成：创建请求包和批准申请包。创建申请请求包阶段通过门限算法各个委员会节点计算自己的公钥份额、私钥份额以及群公钥。批准申请包阶段通过门限算法计算出门限签名，然后执行该请求。在申请人提出申请创建请求包的时候，对门限签名算法进行初始化，各个委员会成员节点计算出自己的公私钥以及群公钥。其次在委员会成员审批申请的时候，每个委员会成员节点都可以独立生成自己的签名份额，当收集至少一半的签名份额后，便可以构造出完整的签名。最后使用完整的签名去执行申请请求，请求执行完毕，该请求的整个生命周期完成。
142.1.1创建请求包实现流程
143.该动作由联盟成员发起，联盟成员通过填写相关信息，来创建一个请求包。该请求需要经过委员会成员的绝大多数成员同意才可以被执行，通过门限签名算法，将该请求当作秘密进行分割，各个委员会成员计算出各自的秘密份额。
144.具体过程如下：
145.系统初始化：
146.现有委员会节点ρ＝{ρ1,ρ2,ρ3，...，ρn}，使用来id＝{id1,id2,id3，...，idn}表示委员会成员的身份，一个委员会节点ρi一个idi身份标识符，并且集合id为整数集合。
p，q为大质数，g为椭圆曲线e中元素阶为q的基点，z
p
包括p个元素的有限域。h(
·
)为哈希函数，m为代签名的消息。
147.各个委员会节点生成密钥：
148.1)子秘密份额分发
149.委员会节点ρi随机选取整数di以及构造一个t-1阶多项式，该多项式满足f
i,0
,f
i,1
,...,f
i,t-1
∈z
p
，fi(0)＝f
i,0
＝di，其中fi(x)与di都需要保密。
150.fi(x)＝f
i,0
+f
i,1
x+f
i,2
x2+...+f
i,t-1
x
t-1
modq
151.委员会节点ρi对其他n-1个委员会节点ρj(j＝1,2,3,...,n,j≠i)，计算fi(idj)，并将结果反送给ρj，计算f
i,l
·
g(l＝0,1,2,...,t-1)广播给其他所有的委员会节点。
152.2)子秘密份额验证
153.ρj收到ρi发送的fi(idj)之后，进行验证，若验证成功则fi(idj)有效。
154.3)子秘密密钥生成
155.委员会节点ρi收到其他n-1个委员会节点ρj(j＝1,2,3,...,n,j≠i)验证过后的fi(idj)之后，开始计算私钥份额(ski)，公钥份额(pki)以及群公钥(gpk)，并公布自己的公钥份额和群公钥。
[0156][0157]
pki＝ski·g[0158][0159]
1.2批准申请包实现流程
[0160]
需要满足绝大多数的委员会成员批准后，才可以同意该申请请求，并执行该请求。所以本发明将门限签名的阈值始终设置为所以本发明将门限签名的阈值始终设置为门限签名允许n参与者中的任何个成员对消息m签名，每个成员都可以独立的完成签名操作，当收集个签名以后，便可以构造出完整的签名。
[0161]
(1)委员会节点ρi使用自己的私钥份额(ski)对消息m进行签名，生成份额签名{r,si}：
[0162]
委员会节点ρi计算ei：
[0163][0164]
委员会节点ρi随机选取一个整数wi(1≤wi≤q-1)，计算ri＝wi·
g，计算椭圆曲线e上的点ρi生成签名份额{r,si}。最后将{r,si}，ri广播给其他的
委员会节点。
[0165][0166]
(2)委员会节点验证秘密份额：
[0167]
委员会节点ρj收到来自其他委员会节点ρi发送的签名份额后，验证签名的正确性：
[0168]ri
＝si·
g-r
·ai
·
pki[0169]
(3)收集验证群签名：
[0170]
收集至少份签名份额{r,si}(i＝1,2,,...,k)后，可以开始计算群签名：并且可以使用群公钥去验证群签名是否有效。验证等式如下：
[0171]
(x,y)＝s
·
g-r
·
gpk
[0172]
2、联盟事务实现
[0173]
本发明将形式多样的基于委员会的联盟管理总结为三种基本类型：申请加入委员会、申请退出委员会、申请发布链码，并详细设计了三种基本类型联盟事务管理的实现过程。
[0174]
2.1申请加入委员会
[0175]
假设联盟a中的普通成员u1想要加入该联盟决策委员会中，那么u1就需要填写相关的用户信息，例如节点名称、事务类型、事务的描述等。然后通过链码为该用户创建申请加入委员会的申请请求包。具体过程如下：
[0176]
(1)普通成员u1填写申请人信息，选择事务类型为加入委员会，并填写加入理由，填写好申请人用户所对应的节点名称。
[0177]
(2)该成员节点调用链码创建申请请求包，并完成初始化。初始化内容具体如下：初始化事务创建申请包id和事务类型；初始化请求包状态；获取该联盟内决策委员会的成员信息并初始化各个委员会成员的审批状态；委员会节点初始化门限签名密钥。
[0178]
(3)委员会节点审批：委员会成员根据具体的请求包id进行查看与审批请求。委员会成员首先输入待审批的申请包id进行查询，然后选择是否同意该请求，如果同意请求那么将进行身份的验证，通过验证后该节点才会被认可，最后执行审批的操作，同时使用智能合约更新请求包状态，修改内容主要有：审批人状态、申请包状态以及申请包投票计数。
[0179]
(4)收集到绝大多数委员会成员签名后，执行该请求内容。每一次的委员会审批操作都会区判断是否已经满足门限签名的门阀值，如果已经达到该值，就代表着已经得到了绝大多数委员会成员的同意，那么将会收集好委员会成员签名，执行该申请人加入委员会。同时将新加入委员会的成员信息上链并且参与下一次决策。
[0180]
2.2申请退出委员会
[0181]
假设联盟a中的委员会成员c1想要退出联盟决策委员会，那么c1就需要填写相关的用户信息以及退出的理由等，过程与申请加入委员会大致相同，具体过程如下：
[0182]
(1)委员会成员c1填写委员会成员信息，选择事务类型为退出委员会，并填写退出理由，填写好申请人用户所对应的节点名称。
[0183]
(2)该成员节点调用链码创建申请请求包，并完成初始化。初始化内容具体如下：初始化事务创建申请包id和事务类型；初始化请求包状态；获取该联盟内决策委员会的成员信息并初始化各个委员会成员的审批状态；委员会节点初始化门限签名密钥。
[0184]
(3)委员会节点审批：委员会成员根据具体的请求包id进行查看与审批请求，选择是否同意，如果同意请求那么进行身份的验证，最后执行审批的操作，同时使用智能合约更新请求包状态，修改内容主要有：审批人状态、申请包状态以及申请包投票计数。
[0185]
(4)收集到绝大多数委员会成员签名后，执行该申请人退出委员会。同时将该委员会的成员信息注销，并且以后不能参与委员会的决策。
[0186]
2.3申请事务状态表
[0187]
为了保证申请事务的原则性与一致性，在每一笔事务发起时，在联盟内部都会初始化一个申请事务状态表，如表1所示。将创建申请包时候的交易id作为本请求的id，即该请求包id，该请求包id是唯一的，一个请求包id对应这一个请求事务。
[0188]
表1申请事务状态表
[0189][0190]
3、实验与分析
[0191]
3.1投票智能合约性能测试
[0192]
本发明做了多组实验，对投票智能合约的性能与决策投票方案做了测评。实验环境所使用的服务器配置与fabric网络配置如表2所示。
[0193]
表2服务器配置与fabric网络配置
[0194][0195]
图8展示了投票链码吞吐量和平均延迟时间，从图中可以看出，写操作吞吐量先随着交易发送率的提高而增加，在发送率为1000时达到最高，接近1000tps，随后便略微下降。
[0196]
3.2委员会决策投票方案测试
[0197]
委员会投票方案的核心在于联盟申请的事务需要由绝大多数委员会成员的同意之后才可以执行，本发明测试设置委员会成员节点为7个，分别在0，1，3，4，7人进行投票的
时候进行了观察与记录，共5组实验，实验结果如表3所示，实验数据说明了委员会投票方案确实可行，只有在满足绝大多数委员会成员同意之后，申请请求才会被执行。
[0198]
表3委员会决策投票方案实验结果
[0199][0200]
3.3安全性分析
[0201]
数据的安全性与隐私性。首先不同联盟之间数据隔离，互相独立，其次联盟链fabric中私有数据的特点，在联盟内通过私有数据保证不同的合作群体之间有自己的专属隐私信道。
[0202]
投票方案的安全性。为了联盟内部事务便于管理的目的，设计了委员会投票方案，哪个联盟成员表现越好，得到联盟内部委员会成员的认可，加入参与委员会管理事务的机会就越大。虽然raft是cft故障容错算法，无法防止恶意类节点，但是若某个掌握领导者节点的组织恶意篡改区块数据，peer节点会验证区块失败，从而网络会迅速检测到恶意的领导者节点，注销其证书，并对该组织施以惩罚。
[0203]
门限算法执行过程中的安全性。因为门限算法中涉及随机值，在智能合约中不允许有随机数以及系统外部文件读写的操作，所以不能多个背书节点同时执行门限算法，否则会导致提案执行结果验证失败，所以涉及计算随机值的步骤需要单独发送给各个背书节点去执行。椭圆曲线公开参数与公钥份额等共享数据存于公共账本中，合法身份皆可访问。通过私有数据机制将完整的门限过程分割为不同步骤，既使得联盟链可以兼容分布式门限签名算法，又保证了重要数据的隐私安全。
[0204]
联盟事务的acid特性与安全性。本发明通过联盟事务状态表来追踪一个申请请求的进展情况，只有当半数以上的委员会成员认可该请求时，该请求才会执行。如果中间投票环节出现问题，则会采取相应取消申请操作，从而一致性与原子性得到保证。每个申请请求都绑定在一个联盟事务状态表中，由状态表单独管理，不同请求之间互不干涉，保证了隔离性。至于持久性，区块链数据原本就是持久化的。通过分布式门限签名算法将投票的过程映射成门限签名的过程，只有委员会成员参与背书才能执行该请求内容，保证了投票过程的安全性。
[0205]
3.4方案对比
[0206]
本发明将委员会决策投票机制方案与fabric中的背书机制进行了对比，以及在底层密码学签名方案中的门限签名与现有的门限签名进行了对比。委员会投票决策机制将从可追踪、抵御攻击、可控制、交易速度等几个方面展开对比。门限签名将从可追踪、匿名性、抵御攻击、有无可信赖中心几个方面展开，投票机制对比结果如表4所示。
[0207]
表4投票机制对比结果
[0208][0209]
由表4可以得出，本方案相比于fabric原本的方案在安全方面更加的可靠，并且可以通过委员会决策投票机制来管理背书，让链码的运行环境更安全。但是在交易速度方面，由于本发明设涉及了密码学算法以及投票机制，所以交易速度慢于原先fabric方案。表5是关于本方案采用的门限签名与其他现有的门限签名的对比。不同于传统的门限签名，本方案的门限签名结合分布式系统的特点，无中心化的信赖中心，产生密钥的过程是通过各个节点共同商议得出来的，避免了可信中心被攻击的安全问题。
[0210]
表5与现有门限签名方案对比
[0211][0212]
应当注意，本发明的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本发明的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体，或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。
[0213]
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，凡在本发明的精神和原则之内所做的做的任何修改、等同替换和改进等，都应涵盖在本发明的保护范围之内。