WO2020168937A1

WO2020168937A1 - Block chain multi-party witness method, apparatus and device, and computer-readable storage medium

Info

Publication number: WO2020168937A1
Application number: PCT/CN2020/074687
Authority: WO
Inventors: 陈宇; 李辉忠; 张开翔; 范瑞彬
Original assignee: 深圳前海微众银行股份有限公司
Priority date: 2019-02-20
Filing date: 2020-02-11
Publication date: 2020-08-27
Also published as: CN109936457A; CN109936457B

Abstract

Disclosed is a block chain multi-party witness method, comprising: obtaining data to be witnessed, calculating the hash value of the data to be witnessed, signing the hash value by using a witness initiator private key, and generating a witness request message according to the hash value signed by the witness initiator private key and preset multi-party witness completion condition information; transmitting the data to be witnessed and the witness request message to a preset witness participant node, and receiving a witness response message returned by each witness participant node; obtaining, from the witness response message, signature information that each witness participant node signs the hash value by using its own private key so as to form a signature list; initiating an on-chain consensus based on the signature list; and when the on-chain consensus is achieved, determining that the multi-party witness of the data to be witnessed is completed. Also disclosed are a block chain multi-party witness apparatus and device, and a storage medium. The present application can improve the execution performance of multi-party witness based on a block chain and reduce data storage pressure.

Description

Block chain multi-party witness method, device, equipment and computer readable storage medium

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on February 20, 2019, the application number is 201910135223.1, and the invention title is "blockchain multi-party witness method, device, equipment and computer-readable storage medium". The entire content is incorporated in the application by reference.

Technical field

This application relates to the field of blockchain (Blockchain) technology, and in particular to methods, devices, equipment, and computer-readable storage media for blockchain multi-party witness.

Background technique

In recent years, with the continuous development of Fintech, especially Internet finance, Blockchain technology has been gradually introduced into the business transactions of financial institutions such as banks. The core value of the blockchain lies in the authenticity of data brought by multi-party witness and non-tampering. Among them, multi-party witness means that an organization with specific qualifications proves the integrity and authenticity of the data in the name of its organization, and does An activity that proves responsibility. The application scenarios of multi-party witness in the blockchain include deposit certificates, voting, etc.

In the prior art, a blockchain-based multi-party witness scheme is generally: a business organization generates a Hash (hash) value of the data that needs to be witnessed, signs the hash value of the data and then uploads it to the chain, and then notifies other institutions to After other institutions confirm the hash value, they need to add their respective institution’s signature based on the hash value on the chain. The relevant institution has uploaded the signature and the multi-party witness process is now complete.

The disadvantages of the above multi-party witness scheme are: 1) Performance limitations. All kinds of institutions need to perform the chain operation on the signature of the data Hash value. A complete witness process will include multiple chain operations, which affects the efficiency of the witness and restricts the large-scale application of multi-party witness. 2) Storage restrictions. Each chain operation of signature is a transaction that executes a smart contract, and the transaction and its data need to be recorded in the blockchain. The need for signatures from multiple parties in a single witness process will increase the transaction volume/data volume.

Summary of the invention

technical problem

The solution to the problem

Technical solutions

The main purpose of this application is to propose a blockchain multi-party witness method, device, equipment, and computer-readable storage medium, aiming to improve the execution performance of multi-party witness based on the blockchain and reduce data storage pressure, thereby facilitating multi-party witness Large-scale application.

In order to achieve the above purpose, this application provides a blockchain multi-party witness method, which includes the following steps:

Obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-saved witness initiator private key to sign the hash value, according to the signature of the witness initiator private key Hash value and preset multi-party witness completion condition information generates a witness request message;

Sending the data to be witnessed and the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

Obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

Initiate an on-chain consensus based on the signature list;

When the consensus on the chain is reached, it is determined that the data to be witnessed has completed multi-party witness.

In addition, in order to achieve the above objective, this application also provides a block chain multi-party witness device, which includes:

The request generation module is used to obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-stored private key of the witness initiator to sign the hash value according to the private key of the witness initiator. Generating a witness request message after the hash value signed by the key and preset multi-party witness completion condition information;

A request sending module, configured to send the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

The obtaining module is used to obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

The consensus initiation module is used to initiate an on-chain consensus based on the signature list;

The judging module is used to judge that the data to be witnessed has completed multi-party witness when the consensus on the chain is reached.

In addition, in order to achieve the above object, this application also provides a blockchain multi-party witness device, the blockchain multi-party witness device includes: a memory, a processor, and stored in the memory and capable of running on the processor A multi-party witness program that implements the steps of the blockchain multi-party witness method described above when the multi-party witness program is executed by the processor.

In addition, in order to achieve the above objective, the present application also provides a computer-readable storage medium on which a multi-party witness program is stored. When the multi-party witness program is executed by a processor, the block as described above is realized. The steps of the chain multi-party witness method.

In the blockchain multi-party witness method proposed in this application, the mechanism for witnessing initiator nodes to collect signatures is changed from the existing "on-chain signature transaction collection" to "on-chain communication collection", that is, when collecting the signatures of each witness participant node , The witness initiator node and the witness participant node do not need to sign the hash value of the data to be witnessed before sending the transaction on the chain. Instead, the witness initiator node collects the signature list that meets the witness completion condition and then initiates the signature list based on the signature list. On-chain consensus, that is, the signature list is uploaded to the chain at one time. When the on-chain consensus is reached, it is determined that the data to be witnessed has completed multi-party witness. In this way, the performance of multi-party witness is improved and the data storage pressure is reduced, thereby facilitating Large-scale application of multiple witnesses.

The beneficial effects of the invention

Brief description of the drawings

Description of the drawings

FIG. 1 is a schematic diagram of a device structure of a hardware operating environment involved in a solution of an embodiment of the present application;

FIG. 2 is a schematic flowchart of a first embodiment of a multi-party witness method for applying a blockchain;

FIG. 3 is a schematic diagram of the system architecture of multi-party witness in an embodiment of the application.

The realization, functional characteristics, and advantages of the purpose of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings.

Invention embodiment

Embodiments of the invention

It should be understood that the specific embodiments described here are only used to explain the application, and are not used to limit the application.

As shown in FIG. 1, FIG. 1 is a schematic diagram of the device structure of the hardware operating environment involved in the solution of the embodiment of the present application.

The terminal in the embodiment of the present application may be a PC or a server device.

As shown in FIG. 1, the terminal may include a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to implement connection and communication between these components. The user interface 1003 may include a display screen (Display) and an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as a magnetic disk memory. Optionally, the memory 1005 may also be a storage device independent of the foregoing processor 1001.

Those skilled in the art can understand that the structure of the device shown in FIG. 1 does not constitute a limitation on the device, and may include more or fewer components than those shown in the figure, or a combination of certain components, or different component arrangements.

As shown in FIG. 1, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a multi-party witness program.

In the device shown in FIG. 1, the network interface 1004 is mainly used to connect to witness participant nodes and perform data communication with the witness participant nodes; the user interface 1003 is mainly used to connect to the client (user side) and perform data communication with the client ; And the processor 1001 can be used to call the multi-party witness program stored in the memory 1005, and perform operations in each embodiment of the following blockchain multi-party witness method.

Based on the above hardware structure, an embodiment of the blockchain multi-party witness method of this application is proposed.

Referring to Fig. 2, Fig. 2 is a schematic flowchart of a first embodiment of a blockchain multi-party witness method according to the application, and the method includes:

Step S10: Obtain the data to be witnessed, calculate the hash value of the data to be witnessed, and sign the hash value using the pre-stored private key of the witness initiator. Generating a witness request message from the hash value and preset multi-party witness completion condition information;

The blockchain multi-party witness method of this embodiment is applied to the witness initiator node, where the witness initiator can be a witness initiator in the alliance chain. In the context of the alliance chain, an organization refers to a logically participating network area For the members of the blockchain, each organization will provide its own node to participate in the physical networking, which means that multiple nodes in the blockchain networking may belong to the same organization.

In order to ensure the normal implementation of this application, the initial deployment of the blockchain needs to be completed first. The initial deployment involves the node deployment, networking, and deployment of smart contracts of the blockchain. The details are as follows:

a. Node deployment. Each organization deploys one or more blockchain nodes, and the local configuration information of the node includes a unique identification ID and the organization information to which it belongs.

b. Networking. The initial state of the node's local configuration only contains the node's own information (unique identification ID and organization information), and the information of other newly-connected nodes will be dynamically written later. The node reads the local configuration at startup, obtains the node information and loads it into its own cache, and directly obtains it from the cache when it needs to obtain the node structure related information later. When a new node joins the existing blockchain network, it notifies other nodes of the entire network of its own information, and realizes that the information of all nodes in the network is consistent throughout the network (local configuration and cache are consistent) through a consensus mechanism.

c. Deploy smart contracts. The smart contract is used to subsequently determine the validity of the signature list and whether it meets the multi-party witness completion conditions, and records them. The witness completion conditions are defined by the witness initiator and the witness participating institutions through negotiation. The smart contract also provides a query interface for the witnessed data and its completion conditions.

After the initial deployment of the blockchain is completed, multi-party witness based on the data to be witnessed can be executed. The application scenarios of multi-party witness in the blockchain include evidence deposit, voting, etc.

Referring to FIG. 3, FIG. 3 is a schematic diagram of the system architecture of multi-party witness in an embodiment of the application. The figure shows the relationship between institutions, nodes, and message flows. Institutions and nodes can be connected directly or through agents. Institution ACD (nodes 1, 2, 4, 5) participates in this multi-party witness process. Let institution A be the witness initiator, node 1 under institution A is the witness initiator node, and institutions C and D are witness participants. , The message flow process in FIG. 3 will be described in conjunction with specific implementations.

First, the witness initiator node (node 1) obtains the data to be witnessed, calculates the hash value of the data to be witnessed, and signs the calculated hash value with its own private key. The algorithm for calculating the hash value includes But it is not limited to hash algorithms such as MD4, MD5, SHA1; then, the witness initiator node generates a witness request message according to the hash value signed by its own private key and the preset multi-party witness completion condition information.

In one embodiment, in order to distinguish different witness request messages, the step of generating a witness request message based on the hash value signed by the witness initiator private key and preset multi-party witness completion condition information may include : Generate unique identification information of the witness request message; package the unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information into a witness request message.

Here, you might as well set the unique identification information of the witness request message as Seq, the hash value signed by the private key of the witness initiator A is Hash(A), the preset multi-party witness completion condition information is Condition, and these three are packaged into The witness request message can be expressed as: <Seq, Hash(A), Condition, Request>, where Request represents the request field.

Further, in this embodiment, in order to facilitate user identification, the completion conditions of multi-party witness can be described formally. For example, when the completion condition of multi-party witness stipulates that the completion of multi-party witness requires the signature of two institutions, including the signature of institution A and the institution When signing by any institution in the CD, the completion condition of the multi-party witness can be expressed as: [A(CD)]. Of course, the description form of the completion condition of multi-party witness is not limited to the examples given, and it can be flexibly set during specific implementation.

Step S20: Send the data to be witnessed and the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

In this step, the witness initiator node (node 1) sends the data to be witnessed and the witness request message to the preset witness participant nodes (nodes 4, 5). Among them, sending the data to be witnessed to the preset witness participant nodes can be sent through a private network independent of the blockchain, so that even if the amount of data to be witnessed is large, it will not affect the blockchain Of course, sending the data to be witnessed to the preset witness participant node can be sent in the form of on-chain communication; while sending the witness request message to the preset witness participant node is generally in the form of on-chain communication Send, that is, the witness request message will be sent to the preset witness participant node through the communication broadcast on the chain.

After receiving the witness request message, the witness participant node performs the following judgment operations:

1) Whether the hash value signature is true and valid. Specifically, the witness participant node uses the pre-saved witness initiator public key to decrypt the hash value signature. When the hash value signature can be decrypted by the witness initiator public key, it is determined that the hash value signature is true and valid;

2) Whether it is an unprocessed witness request message. Specifically, the unique identification information Seq of the witness request message is used to identify whether it is an unprocessed witness request message;

3) Whether the hash value in the witness request message is consistent with the hash value of the data to be witnessed stored by itself. Specifically, when the data to be witnessed sent by the witness participant is received, the hash value of the data to be witnessed is calculated, and when the witness request message is subsequently received, it is determined whether the hash value in the witness request message is consistent with its own storage requirements. The hash value of the witness data is consistent.

4) Whether to approve the witness completion condition in the witness request message. Specifically, the witness participant users make artificial judgments based on actual business scenarios.

If the judgment result of any of the above conditions is no, the witness participant node discards the witness request message; if the above conditions are all judged to be yes, the witness participant node uses its own private key to sign the hash value of the data to be witnessed. For example, when institution A sends a witness request message <Seq, Hash(A), Condition, Request> to institution C, the node of institution C uses its private key to sign the hash value of the data to be witnessed, and the signed hash The value is Hash(C). At this time, the organization C node further packs the unique identification information Seq of the witness request message, the hash value Hash(C) signed by its own private key, and the preset multi-party witness completion condition information Condition into a witness The response message is returned to node A, and the witness response message can be expressed as: <Seq, Hash(C), Condition, Response>, where Response represents the response field. After that, the witness initiator node receives the witness response message returned by each witness participant node.

Step S30: Obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

In this step, the witness initiator node obtains the signature information of each witness participant node using its own private key to sign the hash value from the received witness response message to form a signature list, where the signature information includes each witness participant node Organization ID, node ID, and hash value signed by the witness participant's private key.

Step S40, initiate an on-chain consensus based on the signature list;

In this step, the witness initiator node initiates an on-chain consensus based on the signature list. Specifically, this step S40 may further include: generating an on-chain transaction based on the hash value signed by the witness initiator private key, the signature list, and the multi-party witness completion condition information; and executing the The on-chain operation of the on-chain transaction, so that all nodes in the blockchain can reach a consensus on the on-chain transaction.

In this embodiment, when the witness initiator node initiates an on-chain consensus, it generates an on-chain transaction based on the hash value signed by its own private key, the signature list, and the completion condition information of the multi-party witness, and then executes the on-chain transaction. The on-chain operation is to call the smart contract to send an on-chain transaction so that all nodes in the blockchain can reach a consensus on the on-chain transaction. For example, when the witness initiator is institution A, the transaction data can be expressed as: <Hash(A), Sign List, Condition>, where Sign List is the signature list (as shown in Figure 3, the signature list contains the signatures of institution A, Sign A and Sign D of Institution D).

It should be noted that the nodes participating in the consensus are all nodes of all institutions in the blockchain, that is, as shown in Figure 3, it includes both witness initiator nodes 1, 2, and

witness participant nodes

4, 5, and also Node 3 other than the witness initiator node and the witness participant node. All nodes of all institutions in the blockchain verify the validity and authenticity of the signatures in the signature list, and verify whether the signature list meets the multi-party witness completion conditions specified by the smart contract. The verification result will affect the consensus result and then affect the transaction. The chain succeeded.

Among them, the completion conditions of multi-party witness can be flexibly set, including but not limited to:

1) It is a general witness requirement to collect the signatures of specific institutions, for example, the signatures of business institutions/depositing institutions/arbitration institutions must be collected for certificate deposit business;

2) It is required to collect signatures for a certain number of blockchain nodes, which embodies the principle that the minority obey the majority in democratic centralism;

3) In order to prevent a certain organization from deploying a large number of nodes to become the majority of nodes, resulting in a situation where only the signatures of nodes under the organization can meet the witness completion conditions, the signatures of multiple nodes under an organization are only counted at most when statistics are required The two signatures of the organization are combined with the principle of the minority to obey the majority to determine whether the multi-party witness can be completed. This rule requires the collection of a certain number of signatures of the organization;

4) It only needs to be signed by any institution in some institutions.

The completion conditions of the above-mentioned multi-party witness can be used singly or mixed. The above completion conditions can be described formally and recorded on the chain. For example, there is an institution ABCD, and the completion condition of multi-party witness is described as [A(CD)], which means that the completion of this multi-party witness requires the signatures of two institutions, including the signature of institution A , And the signature of any institution in institution CD (B institution does not need to participate in this witness).

Step S50: When the consensus on the chain is reached, it is determined that the data to be witnessed has completed multi-party witness.

In this embodiment, when the on-chain consensus based on the signature list is reached, it is determined that the data to be witnessed has completed multi-party witness. In specific implementation, the blockchain consensus algorithm can use the existing PBFT (Practical Byzantine Fault Tolerance, Byzantine Fault Tolerance) algorithm or RAFT algorithm (a distributed consensus algorithm), and the consensus reaching conditions are determined by the specific consensus algorithm used. This embodiment will not repeat this description.

The transaction data <Hash(A), Sign List, Condition> is confirmed when it is uploaded to the chain. The data on the entire network is consistent, and all blockchain nodes can be checked and verified. The witness initiating/participating agency ACD can set a transaction callback, and be notified when the transaction data is successfully connected to the chain (the witness process is completed).

If a business organization needs to initiate an inspection, the organization with inspection function (C in Figure 3 is the inspection organization) based on the hash value of the data to be witnessed (the unique identifier of the data to be witnessed) that is unified by each organization, from the block The transaction data is extracted on the chain, and the validity, authenticity of the data and whether it meets the completion conditions of the multi-party witness is determined, thereby realizing the inspection of the multi-party witness data.

In the blockchain multi-party witness method proposed in this embodiment, the mechanism for witnessing initiator nodes to collect signatures is changed from the existing "on-chain signature transaction collection" to "on-chain communication collection", that is, the signature of each witness participant node is collected At the time, the witness initiator node and the witness participant node do not need to sign the hash value of the data to be witnessed before sending the transaction on the chain. Instead, the witness initiator node collects the signature list that meets the witness completion condition and then initiates the list based on the signature On-chain consensus, that is, the signature list is put on the chain at a time. When the on-chain consensus is reached, it is determined that the data to be witnessed has completed multi-party witness. In this way, the performance of multi-party witness is improved and the data storage pressure is reduced. Large-scale application to facilitate multi-party witness.

Further, based on the first embodiment of the blockchain multi-party witness method of the present application, a second embodiment of the blockchain multi-party witness method of the present application is proposed.

In this embodiment, before the above step S40, it may further include: verifying the validity of the signature information in the signature list; when the validity verification is passed, determining whether the signature information satisfies the multi-party witness completion The multi-party witness completion condition specified in the condition information; if the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information, the execution step is to initiate an on-chain consensus based on the signature list.

Specifically, before initiating an on-chain consensus based on the signature list, the witness initiator node may first verify the validity of the signature information in the signature list, and the step of verifying the validity of the signature information in the signature list may include : Use the pre-saved witness participant public key to decrypt the signature information in the signature list; when the signature information in the signature list can be decrypted by the witness participant public key, determine the signature information in the signature list It is vaild. For example, the witness initiator institution A pre-stores the public key of the witness participant institution C, and the public key can be used to decrypt the signature information of the institution C. If the signature information of the decryption institution C can be decrypted by the public key, the signature list is determined The signature information of organization C in is valid.

When the validity verification is passed, the witness initiator node further determines whether the signature information in the signature list meets the multi-party witness completion conditions specified in the multi-party witness completion condition information according to the smart contract. For the multi-party witness completion conditions, refer to the description of the first embodiment above. ; If it is satisfied, the steps of initiating an on-chain consensus based on the signature list can be executed.

In this embodiment, the witness initiator node initiates an on-chain consensus based on the signature list only after collecting the signature information that meets the completion conditions of the multi-party witness. In this way, the accuracy and authenticity of the on-chain transaction data are guaranteed and further improved The efficiency of multi-party witness.

Further, based on the first embodiment of the blockchain multi-party witness method of the present application, a third embodiment of the blockchain multi-party witness method of the present application is proposed.

In this embodiment, the above step S20 may include: reading a list of topic nodes pre-stored locally, where the topic node list is used to record witness initiator nodes and witness participant nodes that have paid attention to the same topic in advance, where Topic represents The hash value of the data to be witnessed; randomly select a preset number of target nodes from the Topic node list, send the data to be witnessed and the witness request message to the target node, and receive all The witness response message returned by the target node.

In this embodiment, considering the limited network reliability (for example, node 5 cannot connect to node 1), in order to reduce network pressure and improve performance, the process of collecting signatures on the chain can be optimized. The optimization is mainly by introducing It is realized based on the mechanism of Topic's attention, grouping, multicasting, message forwarding, and witness response message return.

First, the witness initiator node locally pre-stores a topic node list, which is used to record witness initiator nodes and witness participant nodes that have paid attention to the same topic in advance, where Topic represents the hash of the data to be witnessed After the witness initiator node generates a witness request message, it can read the Topic node list and randomly select a preset number of target nodes from it, and then send the data to be witnessed and the witness request message to the selected target node, and Receive the witness response message returned by the target node.

Taking Figure 3 as an example, when node 1 is ready to send a witness request message based on a topic, a certain number of target nodes are selected from the local Topic node list (including nodes 1, 2, 4, and 5) to send the witness request message. The selected target node does not include its own node. After receiving the witness request message, the target node judges whether it pays attention to the topic. If so, it records the previous source node of the witness request message locally, forwards the message, and forwards the route The rule is: select a certain number of nodes from the local record of the node list that pays attention to the topic to send the witness request message, and the selected node cannot be the previous source node and the own node of the witness request message. After that, the node that receives the witness request message returns the corresponding witness response message, and the routing rule for the node to send the witness response message is: according to the Seq field of the witness response message, find the previous source node of the message from the local record as the response message The next forwarding node until it is sent to the source node of the original witness request message.

For example, node 1 sends a witness request message to node 4, node 4 constructs a witness response message and sends it to 1, and records the source of the witness request message, node 1, and forwards the message to node 5, which is the witness response constructed after node 5 receives the message The message will be routed to node 4 and then routed to node 1. In this way, if node 5 is not connected to node 1, node 5 and node 1 can also realize the corresponding witness request and witness response through message forwarding from other nodes This process further improves the network performance and ensures that the witness initiator node can successfully collect the signatures of the witness participant nodes.

Further, based on the third embodiment of the blockchain multi-party witness method of the present application, a fourth embodiment of the blockchain multi-party witness method of the present application is proposed.

In this embodiment, before step S20, it may further include: creating a Topic node list; when receiving a Topic message sent by another node, decrypting the Topic message using the witness initiator private key, where the Topic message is initiated using the witness A message in which the public key of the party encrypts the hash value of the data to be witnessed; when the Topic message can be decrypted by the private key of the witness initiator, the sending node of the Topic message is added to the Topic Node list.

In this embodiment, the witness initiator node can first create a Topic node list, and subsequently when receiving Topic messages sent by other nodes, use its own private key to decrypt the received Topic messages, where the Topic message is the public using the witness initiator. The key encrypts the hash value of the data to be witnessed; if the Topic message can be decrypted by its own private key, the witness initiator node adds the sending node of the Topic message to the Topic node list, indicating itself Knowing that the sending node of the Topic message pays attention to the Topic in the Topic message.

Taking Figure 3 as an example, organizations A, C, and D each calculate a hash value (namely Topic) for the data to be witnessed, and use the public key of the other organization to encrypt the data and send it to the other organization to show that its own node pays attention to the Topic. The nodes of common concern for a topic will participate in the multi-party witness process based on the topic. For example, the content sent by node A from node 1 to node 4 under the organization is: Topic signed with the public key of organization C to which node 4 belongs, which means that node 4 knows that node 1 pays attention to the topic. Note: The counterparty organization here includes organization B.

All

nodes

1, 2, 3, 4, and 5 of organizations A, B, C, and D, after receiving the Topic message, use the private key of their own organization to decrypt the hash value, and add the sending node of the Topic message to the local Topic Node list. Ideally, the surviving and

interconnected blockchain nodes

1, 2, 4, and 5 deployed by institutions A, C, and D all have a consistent list of Topic nodes (that is,

nodes

1, 2, 4, and 5 each record the node locally 1, 2, 4, 5 follow the same topic).

By introducing the follow process of Topic, subsequent witness request messages based on the hash value of a certain data to be witnessed (ie Topic) witness process are only sent between nodes that follow the topic, such as the witness request of node 1 in Figure 3 Messages are only sent within the communication range of the Topic packet as shown in the figure, which limits the communication range of messages on the chain, reduces the bandwidth occupation, and improves the processing capability of concurrent witnesses.

This application also provides a block chain multi-party witness device. The multi-party witness device for the blockchain of this application includes:

Further, the request generation module is also used for:

Generate the unique identification information of the witness request message;

The unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information are packaged into a witness request message.

Further, the blockchain multi-party witness device further includes:

The verification module is used to verify the validity of the signature information in the signature list;

A judging module, used for judging whether the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information when the validity verification is passed;

The consensus initiation module is also configured to initiate an on-chain consensus based on the signature list when the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information.

Further, the verification module is also used for:

Decrypt the signature information in the signature list using the pre-saved public key of the witness participant;

When the signature information in the signature list can be decrypted by the public key of the witness participant, it is determined that the signature information in the signature list is valid.

Further, the consensus initiation module is also used for:

Generate an on-chain transaction based on the hash value signed by the witness initiator private key, the signature list, and the multi-party witness completion condition information;

The on-chain operation of the on-chain transaction is performed so that all nodes in the blockchain can reach a consensus on the on-chain transaction.

Further, the request sending module is also used for:

Read a list of topic nodes pre-stored locally, where the topic node list is used to record witness initiator nodes and witness participant nodes that have paid attention to the same topic in advance, where Topic represents the hash value of the data to be witnessed;

A preset number of target nodes are randomly selected from the Topic node list, the data to be witnessed and the witness request message are sent to the target node, and the witness response message returned by the target node is received.

Further, the blockchain multi-party witness device further includes:

Create module to create a list of Topic nodes;

The decryption module is used to decrypt the Topic message using the private key of the witness initiator when a Topic message sent by another node is received, where the Topic message is a hash of the data to be witnessed using the public key of the witness initiator The value of the encrypted message;

The adding module is configured to add the sending node of the Topic message to the Topic node list when the Topic message can be decrypted by the private key of the witness initiator.

For the operations performed by the above-mentioned program modules, refer to the embodiment of the blockchain multi-party witness method of this application, which will not be repeated here.

The application also provides a computer-readable storage medium.

A multi-party witness program is stored on the computer-readable storage medium of the present application, and the multi-party witness program is executed by a processor to realize the steps of the blockchain multi-party witness method as described above.

The method implemented when the multi-party witness program running on the processor is executed can refer to the various embodiments of the blockchain multi-party witness method of the present application, which will not be repeated here.

It should be noted that in this article, the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, It also includes other elements that are not explicitly listed, or elements inherent to the process, method, article, or system. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, article or system that includes the element.

The serial numbers of the foregoing embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method of the above embodiments can be implemented by means of software plus the necessary general hardware platform. Of course, it can also be achieved by hardware, but in many cases the former is better.的实施方式。 Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium (such as ROM/RAM) as described above. , Magnetic disk, optical disk), including several instructions to make a terminal device (can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) execute the method described in each embodiment of the present application.

The above are only preferred embodiments of this application, and do not limit the scope of this application. Any equivalent structure or equivalent process transformation made using the content of the description and drawings of this application, or directly or indirectly used in other related technical fields , The same reason is included in the scope of patent protection of this application.

Claims

A block chain multi-party witness method, wherein the block chain multi-party witness method includes the following steps:

Obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-saved witness initiator private key to sign the hash value, according to the signature of the witness initiator private key Hash value and preset multi-party witness completion condition information generates a witness request message;

Sending the data to be witnessed and the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

Obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

Initiate an on-chain consensus based on the signature list;

When the consensus on the chain is reached, it is determined that the data to be witnessed has completed multi-party witness.
The blockchain multi-party witness method according to claim 1, wherein the step of generating a witness request message based on the hash value signed by the witness initiator private key and preset multi-party witness completion condition information include:

Generate the unique identification information of the witness request message;

The unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information are packaged into a witness request message.
The blockchain multi-party witness method of claim 1, wherein before the step of initiating an on-chain consensus based on the signature list, the method further comprises:

Verify the validity of the signature information in the signature list;

When the validity verification is passed, determine whether the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information;

If the signature information satisfies the multi-party witness completion condition specified in the multi-party witness completion condition information, perform the step of initiating an on-chain consensus based on the signature list.
The blockchain multi-party witness method according to claim 3, wherein the step of verifying the validity of the signature information in the signature list comprises:

Decrypt the signature information in the signature list using the pre-saved public key of the witness participant;

When the signature information in the signature list can be decrypted by the public key of the witness participant, it is determined that the signature information in the signature list is valid.
The blockchain multi-party witness method according to claim 1, wherein the step of initiating an on-chain consensus based on the signature list comprises:

Generate an on-chain transaction based on the hash value signed by the witness initiator private key, the signature list, and the multi-party witness completion condition information;

The on-chain operation of the on-chain transaction is performed so that all nodes in the blockchain can reach a consensus on the on-chain transaction.
The blockchain multi-party witness method according to claim 1, wherein said sending said data to be witnessed and said witness request message to a preset witness participant node, and receiving a return from each witness participant node The steps to witness the response message include:

Read a list of topic nodes pre-stored locally, where the topic node list is used to record witness initiator nodes and witness participant nodes that have paid attention to the same topic in advance, where Topic represents the hash value of the data to be witnessed;

A preset number of target nodes are randomly selected from the Topic node list, the data to be witnessed and the witness request message are sent to the target node, and the witness response message returned by the target node is received.
The blockchain multi-party witness method according to claim 6, wherein said sending said data to be witnessed and said witness request message to a preset witness participant node, and receiving a return from each witness participant node Before witnessing the response message, it also includes:

Create a list of Topic nodes;

When a Topic message sent by another node is received, the witness initiator private key is used to decrypt the Topic message, where the Topic message is the result of using the witness initiator public key to encrypt the hash value of the data to be witnessed news;

When the Topic message can be decrypted by the witness initiator private key, the sending node of the Topic message is added to the Topic node list.
A block chain multi-party witness device, wherein the block chain multi-party witness device includes:

The request generation module is used to obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-stored private key of the witness initiator to sign the hash value according to the private key of the witness initiator. Generating a witness request message after the hash value signed by the key and preset multi-party witness completion condition information;

A request sending module, configured to send the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

The obtaining module is used to obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

The consensus initiation module is used to initiate an on-chain consensus based on the signature list;

The judging module is used to judge that the data to be witnessed has completed multi-party witness when the consensus on the chain is reached.
The blockchain multi-party witness device according to claim 8, wherein the request generation module is further used for:

Generate the unique identification information of the witness request message;

The unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information are packaged into a witness request message.
The block chain multi-party witness device according to claim 8, wherein the block chain multi-party witness device further comprises:

The verification module is used to verify the validity of the signature information in the signature list;

A judging module, used for judging whether the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information when the validity verification is passed;

The consensus initiation module is also configured to initiate an on-chain consensus based on the signature list when the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information.
The block chain multi-party witness device of claim 10, wherein the verification module is further used for:

Decrypt the signature information in the signature list using the pre-saved public key of the witness participant;

When the signature information in the signature list can be decrypted by the public key of the witness participant, it is determined that the signature information in the signature list is valid.
The blockchain multi-party witness device according to claim 8, wherein the consensus initiation module is further used for:

Generate an on-chain transaction based on the hash value signed by the witness initiator private key, the signature list, and the multi-party witness completion condition information;

The on-chain operation of the on-chain transaction is performed so that all nodes in the blockchain can reach a consensus on the on-chain transaction.
The blockchain multi-party witness device according to claim 8, wherein the request sending module is further used for:

Read a list of topic nodes pre-stored locally, where the topic node list is used to record witness initiator nodes and witness participant nodes that have paid attention to the same topic in advance, where Topic represents the hash value of the data to be witnessed;

A preset number of target nodes are randomly selected from the Topic node list, the data to be witnessed and the witness request message are sent to the target node, and the witness response message returned by the target node is received.
The block chain multi-party witness device according to claim 13, wherein the block chain multi-party witness device further comprises:

Create module to create a list of Topic nodes;

The decryption module is used to decrypt the Topic message using the private key of the witness initiator when a Topic message sent by another node is received, where the Topic message is a hash of the data to be witnessed using the public key of the witness initiator The value of the encrypted message;

The adding module is configured to add the sending node of the Topic message to the Topic node list when the Topic message can be decrypted by the private key of the witness initiator.
A blockchain multi-party witness device, wherein the blockchain multi-party witness device includes: a memory, a processor, and a multi-party witness program stored on the memory and running on the processor. The multi-party witness The following steps are implemented when the program is executed by the processor:

Obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-saved witness initiator private key to sign the hash value, according to the signature of the witness initiator private key Hash value and preset multi-party witness completion condition information generates a witness request message;

Sending the data to be witnessed and the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

Obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

Initiate an on-chain consensus based on the signature list;

When the consensus on the chain is reached, it is determined that the data to be witnessed has completed multi-party witness.
The blockchain multi-party witness device of claim 15, wherein the following steps are further implemented when the multi-party witness program is executed by the processor:

Generate the unique identification information of the witness request message;

The unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information are packaged into a witness request message.
The blockchain multi-party witness device of claim 15, wherein the following steps are further implemented when the multi-party witness program is executed by the processor:

Verify the validity of the signature information in the signature list;

When the validity verification is passed, determine whether the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information;

If the signature information satisfies the multi-party witness completion condition specified in the multi-party witness completion condition information, perform the step of initiating an on-chain consensus based on the signature list.
A computer-readable storage medium, wherein a multi-party witness program is stored on the computer-readable storage medium, and the following steps are implemented when the multi-party witness program is executed by a processor:

Obtain the data to be witnessed, calculate the hash value of the data to be witnessed and use the pre-saved witness initiator private key to sign the hash value, according to the signature of the witness initiator private key Hash value and preset multi-party witness completion condition information generates a witness request message;

Sending the data to be witnessed and the witness request message to a preset witness participant node, and receive a witness response message returned by each witness participant node;

Obtain the signature information of each witness participant node using its own private key to sign the hash value from the witness response message to form a signature list;

Initiate an on-chain consensus based on the signature list;

When the consensus on the chain is reached, it is determined that the data to be witnessed has completed multi-party witness.
18. The computer-readable storage medium of claim 18, wherein the following steps are further implemented when the multi-party witness program is executed by the processor:

Generate the unique identification information of the witness request message;

The unique identification information, the hash value signed by the private key of the witness initiator, and preset multi-party witness completion condition information are packaged into a witness request message.
18. The computer-readable storage medium of claim 18, wherein the following steps are further implemented when the multi-party witness program is executed by the processor:

Verify the validity of the signature information in the signature list;

When the validity verification is passed, determine whether the signature information meets the multi-party witness completion condition specified in the multi-party witness completion condition information;

If the signature information satisfies the multi-party witness completion condition specified in the multi-party witness completion condition information, perform the step of initiating an on-chain consensus based on the signature list.