WO2020168937A1 - Procédé, appareil et dispositif de témoignage multipartie à chaîne de blocs, et support de stockage lisible par ordinateur - Google Patents

Procédé, appareil et dispositif de témoignage multipartie à chaîne de blocs, et support de stockage lisible par ordinateur Download PDF

Info

Publication number
WO2020168937A1
WO2020168937A1 PCT/CN2020/074687 CN2020074687W WO2020168937A1 WO 2020168937 A1 WO2020168937 A1 WO 2020168937A1 CN 2020074687 W CN2020074687 W CN 2020074687W WO 2020168937 A1 WO2020168937 A1 WO 2020168937A1
Authority
WO
WIPO (PCT)
Prior art keywords
witness
party
signature
node
hash value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2020/074687
Other languages
English (en)
Chinese (zh)
Inventor
陈宇
李辉忠
张开翔
范瑞彬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WeBank Co Ltd
Original Assignee
WeBank Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by WeBank Co Ltd filed Critical WeBank Co Ltd
Publication of WO2020168937A1 publication Critical patent/WO2020168937A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • 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.
  • 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.
  • Hash hash
  • 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.
  • 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.
  • this application provides a blockchain multi-party witness method, which includes the following steps:
  • 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.
  • 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.
  • the present application also provides a computer-readable storage medium on which a multi-party witness program is stored.
  • a multi-party witness program is stored on which a multi-party witness program is stored.
  • the block as described above is realized. The steps of the chain multi-party witness method.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the memory 1005 may also be a storage device independent of the foregoing processor 1001.
  • 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.
  • 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.
  • 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 ;
  • 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.
  • 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.
  • the witness initiator can be a witness initiator in the alliance chain.
  • an organization refers to a logically participating network area
  • 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.
  • the initial deployment involves the node deployment, networking, and deployment of smart contracts of the blockchain.
  • the details are as follows:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • Institution ACD nodes 1, 2, 4, 5
  • the message flow process in FIG. 3 will be described in conjunction with specific implementations.
  • the witness initiator node 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.
  • 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.
  • the unique identification information of the witness request message is 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
  • These three are packaged into
  • the witness request message can be expressed as: ⁇ Seq, Hash(A), Condition, Request>, where Request represents the request field.
  • the completion conditions of multi-party witness can be described formally.
  • 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)].
  • 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;
  • the witness initiator node sends the data to be witnessed and the witness request message to the preset witness participant nodes (nodes 4, 5).
  • 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
  • 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.
  • the witness participant node After receiving the witness request message, the witness participant node performs the following judgment operations:
  • the witness participant node uses the pre-saved witness initiator public key to decrypt the hash value signature.
  • 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;
  • the unique identification information Seq of the witness request message is used to identify whether it is an unprocessed witness request message;
  • 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.
  • 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).
  • 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.
  • 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;
  • 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
  • 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.
  • the witness initiator node 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.
  • 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).
  • 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.
  • the completion conditions of multi-party witness can be flexibly set, including but not limited to:
  • 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.
  • ABCD there is an institution ABCD
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the witness initiator node 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the witness initiator node 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.
  • 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.
  • 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.
  • the node that receives the witness request message returns the corresponding witness response message
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the multi-party witness device for the blockchain of this application 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.
  • request generation module is also used for:
  • 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 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.
  • verification module is also used for:
  • 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.
  • consensus initiation module is also used for:
  • 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.
  • request sending module is also used for:
  • 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 device further includes:
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de témoignage multipartie à chaîne de blocs, comprenant les étapes suivantes : obtenir des données desquelles témoigner, calculer la valeur de hachage des données desquelles témoigner, signer la valeur de hachage en utilisant une clé privée d'initiateur de témoignage, et générer un message de demande de témoignage conformément à la valeur de hachage signée par la clé privée d'initiateur de témoignage et les informations de condition d'achèvement de témoignage multipartie prédéfinies ; transmettre les données desquelles témoigner et le message de demande de témoignage à un nœud participant de témoignage prédéfini, et recevoir un message de réponse de témoin renvoyé par chaque nœud participant de témoignage ; obtenir, à partir du message de réponse de témoin, des informations de signature selon lesquelles chaque nœud participant au témoignage signe la valeur de hachage en utilisant sa propre clé privée de manière à former une liste de signatures ; initier un consensus sur la chaîne basé sur la liste de signatures ; et lorsque le consensus sur la chaîne est atteint, déterminer que le témoignage multipartie des données desquelles témoigner est terminé. L'invention concerne aussi un appareil et un dispositif de témoignage multipartie à chaîne de blocs, et un support de stockage. La présente invention peut améliorer les performances d'exécution d'un témoignage multipartie sur la base d'une chaîne de blocs et réduire la pression de stockage de données.
PCT/CN2020/074687 2019-02-20 2020-02-11 Procédé, appareil et dispositif de témoignage multipartie à chaîne de blocs, et support de stockage lisible par ordinateur Ceased WO2020168937A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910135223.1A CN109936457B (zh) 2019-02-20 2019-02-20 区块链多方见证方法、装置、设备及计算机可读存储介质
CN201910135223.1 2019-02-20

Publications (1)

Publication Number Publication Date
WO2020168937A1 true WO2020168937A1 (fr) 2020-08-27

Family

ID=66985846

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/074687 Ceased WO2020168937A1 (fr) 2019-02-20 2020-02-11 Procédé, appareil et dispositif de témoignage multipartie à chaîne de blocs, et support de stockage lisible par ordinateur

Country Status (2)

Country Link
CN (1) CN109936457B (fr)
WO (1) WO2020168937A1 (fr)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112118112A (zh) * 2020-09-08 2020-12-22 中国联合网络通信集团有限公司 证照复印件使用方法和节点设备
CN112685395A (zh) * 2020-12-28 2021-04-20 深圳前海微众银行股份有限公司 纵向联邦统计中的无序数据去重方法、装置、设备及介质
CN112738244A (zh) * 2020-12-29 2021-04-30 合肥达朴汇联科技有限公司 一种区块链审计溯源系统
CN113032489A (zh) * 2021-03-29 2021-06-25 湖北央中巨石信息技术有限公司 一种基于区块链的异步共识方法及系统及装置及介质
CN113076376A (zh) * 2021-03-29 2021-07-06 湖北央中巨石信息技术有限公司 基于区块链的多方异步抽样共识方法及系统及装置及介质
CN113225191A (zh) * 2021-03-24 2021-08-06 湖南宸瀚信息科技有限责任公司 共识节点的生成方法、装置、存储介质及处理器
CN113327059A (zh) * 2021-06-24 2021-08-31 北京中电普华信息技术有限公司 基于区块链的电力需求响应处理方法和装置
CN113378144A (zh) * 2021-07-14 2021-09-10 湖北央中巨石信息技术有限公司 基于区块链的图像文件共识方法及系统及装置及介质
CN113468574A (zh) * 2021-07-21 2021-10-01 招商华软信息有限公司 一种区块链数据上链方法和装置
CN113722137A (zh) * 2021-08-26 2021-11-30 杭州优海信息系统有限公司 用于共享工业智能设备故障修复方案的方法及设备
CN113904869A (zh) * 2021-11-10 2022-01-07 深圳前海微众银行股份有限公司 一种区块链中恶意节点的检测方法及区块链
CN114155000A (zh) * 2021-10-29 2022-03-08 国网四川省电力公司眉山供电公司 基于区块链的可追溯混凝土质量管理系统
CN114422970A (zh) * 2020-10-28 2022-04-29 中国联合网络通信集团有限公司 短信溯源方法、装置及设备
CN114444104A (zh) * 2022-01-27 2022-05-06 苏州数桐数字科技有限公司 一种会话密钥的协商方法、数据存证方法及装置
CN114647864A (zh) * 2020-12-18 2022-06-21 中国移动通信有限公司研究院 一种信息存证、查证方法、装置及系统
CN114819932A (zh) * 2020-09-21 2022-07-29 支付宝(杭州)信息技术有限公司 基于区块链的业务处理方法及装置
CN115063099A (zh) * 2022-06-08 2022-09-16 上海万向区块链股份公司 基于区块链的成本管理方法、系统及介质
CN115085926A (zh) * 2022-02-23 2022-09-20 中通服中睿科技有限公司 基于区块链和物联网数据汇聚闸道的数据采集方法及系统
CN115147133A (zh) * 2022-07-04 2022-10-04 南京邮电大学 一种基于区块链技术的地理标志产品溯源的位置证明方法
CN116126968A (zh) * 2022-12-15 2023-05-16 蚂蚁区块链科技(上海)有限公司 基于区块链即服务BaaS平台的提供数据存储服务的方法及系统
WO2024055407A1 (fr) * 2022-09-14 2024-03-21 中化现代农业有限公司 Procédé et système de données en chaîne de l'internet des objets reposant sur un dispositif terminal

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109936457B (zh) * 2019-02-20 2022-04-26 深圳前海微众银行股份有限公司 区块链多方见证方法、装置、设备及计算机可读存储介质
CN110458560B (zh) * 2019-07-12 2021-10-12 创新先进技术有限公司 用于进行交易验证的方法及装置
US10951417B2 (en) 2019-07-12 2021-03-16 Advanced New Technologies Co., Ltd. Blockchain-based transaction verification
CN110659906B (zh) * 2019-09-20 2022-06-24 腾讯科技（深圳）有限公司 票据信息处理方法、相关设备及介质
CN110688410B (zh) * 2019-09-23 2021-03-19 创新先进技术有限公司 一种基于区块链的提议处理方法、装置及电子设备
CN110689349B (zh) * 2019-10-08 2023-07-11 深圳前海微众银行股份有限公司 一种区块链中的交易哈希值存储和搜索方法及装置
CN112769742B (zh) * 2019-11-06 2024-06-14 电科云(北京)科技有限公司 Spdz系列协议中的消息验证方法、装置及存储介质
CN111523901B (zh) * 2020-07-03 2020-12-04 支付宝(杭州)信息技术有限公司 基于拜占庭容错算法的区块链的共识方法、装置及系统
CN112422290A (zh) * 2020-10-27 2021-02-26 中思博安科技（北京）有限公司 基于区块链的数据上链方法、装置及系统
CN112270556A (zh) * 2020-11-23 2021-01-26 苏州园启软件有限公司 电子合同的真实性验证方法、电子设备及存储介质
CN112380555B (zh) * 2020-11-27 2024-03-12 南京知麦信息科技有限公司 一种基于区块链智能合约的农产品溯源信息上链方法
CN112488656A (zh) * 2020-12-04 2021-03-12 紫绶(上海)信息科技有限公司 基于区块链实现对等多方数字化业务全域管理的方法、装置、处理器及其存储介质
CN112564972B (zh) * 2020-12-09 2022-04-05 华东师范大学 基于Event-B方法的区块链PBFT共识算法的形式化建模和安全性验证方法
CN112766979A (zh) * 2021-01-26 2021-05-07 特斯联科技集团有限公司 一种快速电子支付方法及装置
CN112560072B (zh) * 2021-02-18 2021-06-04 腾讯科技（深圳）有限公司 基于区块链的密钥管理方法、装置、介质及设备
CN113255001B (zh) * 2021-06-09 2023-05-23 湖北央中巨石信息技术有限公司 基于区块链的计算记账方法及系统及装置及介质
CN116506294B (zh) * 2022-01-19 2025-11-25 腾讯科技（深圳）有限公司 共识网络优化方法、装置、计算机设备和存储介质
CN114741446B (zh) * 2022-03-07 2025-09-30 杭州趣链科技有限公司 一种数据上链方法、装置、终端及存储介质
CN114338728B (zh) * 2022-03-15 2022-06-10 杭州费尔斯通科技有限公司 一种基于共享数据的共识方法及系统
CN115941191B (zh) * 2022-08-24 2023-09-22 明启智能科技(广东)有限公司 区块链中无共识区块生成与校验方法及见证节点

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108848056A (zh) * 2018-05-03 2018-11-20 南京理工大学 基于验证的区块链共识方法
US20180359096A1 (en) * 2017-06-09 2018-12-13 Ecole Polytechnique Federale De Lausanne (Epfl) Cryptographically Verifiable Data Structure Having Multi-Hop Forward and Backwards Links and Associated Systems and Methods
CN109002732A (zh) * 2018-07-17 2018-12-14 深圳前海微众银行股份有限公司 数据存证方法、设备和系统以及数据取证方法
CN109936457A (zh) * 2019-02-20 2019-06-25 深圳前海微众银行股份有限公司 区块链多方见证方法、装置、设备及计算机可读存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109165944B (zh) * 2018-08-21 2021-01-26 京东数字科技控股有限公司 基于区块链的多方签名认证方法、装置、设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180359096A1 (en) * 2017-06-09 2018-12-13 Ecole Polytechnique Federale De Lausanne (Epfl) Cryptographically Verifiable Data Structure Having Multi-Hop Forward and Backwards Links and Associated Systems and Methods
CN108848056A (zh) * 2018-05-03 2018-11-20 南京理工大学 基于验证的区块链共识方法
CN109002732A (zh) * 2018-07-17 2018-12-14 深圳前海微众银行股份有限公司 数据存证方法、设备和系统以及数据取证方法
CN109936457A (zh) * 2019-02-20 2019-06-25 深圳前海微众银行股份有限公司 区块链多方见证方法、装置、设备及计算机可读存储介质

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112118112A (zh) * 2020-09-08 2020-12-22 中国联合网络通信集团有限公司 证照复印件使用方法和节点设备
CN112118112B (zh) * 2020-09-08 2022-09-02 中国联合网络通信集团有限公司 证照复印件使用方法和节点设备
CN114819932A (zh) * 2020-09-21 2022-07-29 支付宝(杭州)信息技术有限公司 基于区块链的业务处理方法及装置
CN114819932B (zh) * 2020-09-21 2024-05-17 支付宝(杭州)信息技术有限公司 基于区块链的业务处理方法及装置
CN114422970B (zh) * 2020-10-28 2023-06-27 中国联合网络通信集团有限公司 短信溯源方法、装置及设备
CN114422970A (zh) * 2020-10-28 2022-04-29 中国联合网络通信集团有限公司 短信溯源方法、装置及设备
CN114647864A (zh) * 2020-12-18 2022-06-21 中国移动通信有限公司研究院 一种信息存证、查证方法、装置及系统
CN112685395B (zh) * 2020-12-28 2024-05-31 深圳前海微众银行股份有限公司 纵向联邦统计中的无序数据去重方法、装置、设备及介质
CN112685395A (zh) * 2020-12-28 2021-04-20 深圳前海微众银行股份有限公司 纵向联邦统计中的无序数据去重方法、装置、设备及介质
CN112738244A (zh) * 2020-12-29 2021-04-30 合肥达朴汇联科技有限公司 一种区块链审计溯源系统
CN112738244B (zh) * 2020-12-29 2022-06-24 合肥达朴汇联科技有限公司 一种区块链审计溯源系统
CN113225191A (zh) * 2021-03-24 2021-08-06 湖南宸瀚信息科技有限责任公司 共识节点的生成方法、装置、存储介质及处理器
CN113225191B (zh) * 2021-03-24 2024-02-13 湖南宸瀚信息科技有限责任公司 共识节点的生成方法、装置、存储介质及处理器
CN113076376B (zh) * 2021-03-29 2024-02-06 湖北央中巨石信息技术有限公司 基于区块链的多方异步抽样共识方法及系统及装置及介质
CN113076376A (zh) * 2021-03-29 2021-07-06 湖北央中巨石信息技术有限公司 基于区块链的多方异步抽样共识方法及系统及装置及介质
CN113032489A (zh) * 2021-03-29 2021-06-25 湖北央中巨石信息技术有限公司 一种基于区块链的异步共识方法及系统及装置及介质
CN113327059A (zh) * 2021-06-24 2021-08-31 北京中电普华信息技术有限公司 基于区块链的电力需求响应处理方法和装置
CN113378144A (zh) * 2021-07-14 2021-09-10 湖北央中巨石信息技术有限公司 基于区块链的图像文件共识方法及系统及装置及介质
CN113378144B (zh) * 2021-07-14 2022-09-02 湖北央中巨石信息技术有限公司 基于区块链的图像文件共识方法及系统及装置及介质
CN113468574A (zh) * 2021-07-21 2021-10-01 招商华软信息有限公司 一种区块链数据上链方法和装置
CN113468574B (zh) * 2021-07-21 2024-05-24 招商华软信息有限公司 一种区块链数据上链方法和装置
CN113722137A (zh) * 2021-08-26 2021-11-30 杭州优海信息系统有限公司 用于共享工业智能设备故障修复方案的方法及设备
CN114155000A (zh) * 2021-10-29 2022-03-08 国网四川省电力公司眉山供电公司 基于区块链的可追溯混凝土质量管理系统
CN113904869B (zh) * 2021-11-10 2024-04-19 深圳前海微众银行股份有限公司 一种区块链中恶意节点的检测方法及区块链
CN113904869A (zh) * 2021-11-10 2022-01-07 深圳前海微众银行股份有限公司 一种区块链中恶意节点的检测方法及区块链
CN114444104A (zh) * 2022-01-27 2022-05-06 苏州数桐数字科技有限公司 一种会话密钥的协商方法、数据存证方法及装置
CN115085926A (zh) * 2022-02-23 2022-09-20 中通服中睿科技有限公司 基于区块链和物联网数据汇聚闸道的数据采集方法及系统
CN115063099A (zh) * 2022-06-08 2022-09-16 上海万向区块链股份公司 基于区块链的成本管理方法、系统及介质
CN115147133A (zh) * 2022-07-04 2022-10-04 南京邮电大学 一种基于区块链技术的地理标志产品溯源的位置证明方法
WO2024055407A1 (fr) * 2022-09-14 2024-03-21 中化现代农业有限公司 Procédé et système de données en chaîne de l'internet des objets reposant sur un dispositif terminal
CN116126968A (zh) * 2022-12-15 2023-05-16 蚂蚁区块链科技(上海)有限公司 基于区块链即服务BaaS平台的提供数据存储服务的方法及系统

Also Published As

Publication number Publication date
CN109936457A (zh) 2019-06-25
CN109936457B (zh) 2022-04-26

Similar Documents

Publication Publication Date Title
WO2020168937A1 (fr) Procédé, appareil et dispositif de témoignage multipartie à chaîne de blocs, et support de stockage lisible par ordinateur
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
US12126732B2 (en) Blockchain consensus method, device and system
CN111314067B (zh) 区块存储方法、装置、计算机设备及存储介质
CN111427957A (zh) 区块链投票信息校验方法、装置、设备以及存储介质
CN113055188B (zh) 一种数据处理方法、装置、设备及存储介质
EP4287102A1 (fr) Procédé et appareil de traitement de transaction entre chaînes, dispositif électronique et support de stockage
CN111211911B (zh) 一种协同签名方法、装置、设备及系统
CN116112187B (zh) 一种远程证明方法、装置、设备及可读存储介质
CN113409047A (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
CN111833062B (zh) 数字资产数据包的可信性验证系统
US20200250655A1 (en) Efficient, environmental and consumer friendly consensus method for cryptographic transactions
CN113902440B (zh) 一种基于分布式密钥的联盟链跨链交易方法和装置
CN114143021B (zh) 一种基于区块链的新闻信息信用积分系统
CN111339116A (zh) 一种基于区块链的用于开放银行数据共享的方式
CN117829841A (zh) 基于区块链的业务交易监管方法、装置及电子设备
CN116155501A (zh) 区块链网络中的跨链通信方法、装置、设备以及介质
CN118473669A (zh) 区块链交易处理方法、装置、节点及存储介质
CN115641210A (zh) 电力交易存储方法、装置、设备及存储介质
CN114418769A (zh) 一种区块链交易计费方法、装置及可读存储介质
Tyou et al. Leveraging timestamps to create secure and feeless evidence management
CN115426256B (zh) 联盟链配置方法、装置及存储介质
WO2024066974A1 (fr) Procédé de traitement de données basé sur une chaîne de blocs, dispositif et support de stockage lisible
Arote et al. SC-TOF: A Secure and Reliable Task Offloading Framework for IoT Devices Using Smart Contracts and Edge Computing
CN116366254A (zh) 跨链信息生成方法、跨链信息验证方法及跨链信息验证系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20760249

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20760249

Country of ref document: EP

Kind code of ref document: A1