WO2022141700A1 - 分布式节点设备的共识方法、节点设备及分布式网络 - Google Patents
分布式节点设备的共识方法、节点设备及分布式网络 Download PDFInfo
- Publication number
- WO2022141700A1 WO2022141700A1 PCT/CN2021/073329 CN2021073329W WO2022141700A1 WO 2022141700 A1 WO2022141700 A1 WO 2022141700A1 CN 2021073329 W CN2021073329 W CN 2021073329W WO 2022141700 A1 WO2022141700 A1 WO 2022141700A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node device
- information
- transaction information
- number value
- consensus
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 82
- 238000012790 confirmation Methods 0.000 claims abstract description 59
- 238000004590 computer program Methods 0.000 claims description 23
- 238000012545 processing Methods 0.000 claims description 18
- 238000012795 verification Methods 0.000 claims description 2
- 230000008569 process Effects 0.000 abstract description 20
- 238000004891 communication Methods 0.000 abstract description 8
- 230000006870 function Effects 0.000 description 9
- 230000008859 change Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000001960 triggered effect Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010187 selection method Methods 0.000 description 1
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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- 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
- H04L9/3236—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 using cryptographic hash functions
-
- 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
- H04L9/3247—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 involving digital signatures
Definitions
- the present application belongs to the technical field of distributed networks, and in particular, relates to a consensus method for distributed node devices, node devices, distributed networks, and computer-readable storage media.
- the consensus algorithm is the basis for maintaining consistency among various node devices in a distributed network.
- fault tolerance Crash
- Fault Tolerance CFT
- Byzantine Fault Tolerance Byzantine Fault Tolerance
- the consensus process and communication complexity between node devices corresponding to different consensus algorithms are different. For example, when a node device performs consensus based on the BFT consensus algorithm, each node device needs to communicate with other node devices; and when a node device performs consensus based on the CFT consensus algorithm, each slave node device only needs to communicate with the master node device. Communication is enough. It can be seen that the communication complexity of node devices based on the BFT consensus algorithm is much higher than that of the node devices based on the CFT consensus algorithm. However, although the node devices are based on the CFT consensus algorithm. The complexity is low, but the node device cannot solve the problem of node evil when consensus is based on the CFT consensus algorithm.
- the embodiments of the present application provide a consensus method for distributed node devices, a node device, a distributed network, and a computer-readable storage medium, so as to solve the problem that the existing consensus method of distributed node devices cannot solve the problem of malicious nodes or communication complexity higher technical issues.
- an embodiment of the present application provides a consensus method for distributed node devices, which is applied to master node devices in a distributed network.
- the consensus method includes:
- the confirmation information is the serial number value of the transaction information determined by the slave node device Returned when it is not occupied by other transaction information;
- consensus information for the number value is generated based on the first preset number of the confirmation information, and the consensus information is broadcast to each of the slave node devices; the consensus information is in After being confirmed as valid by the slave node device, the slave node device is instructed to submit the transaction information.
- the consensus method further includes:
- the submitting the transaction information when receiving the first preset number of confirmation information for the serial number value returned by the slave node device includes:
- the transaction information is submitted when a first preset number of its own shared keys returned from the slave node devices are received.
- generating consensus information for the serial number value based on the first preset number of the confirmation information in the trusted execution environment, and broadcasting the consensus information to each of the slave node devices include:
- the second secret information is broadcast to each of the slave node devices.
- generating the first secret information corresponding to the serial number value and the electronic signature of the first secret information in the trusted execution environment includes:
- first secret information corresponding to the serial number value and an electronic signature of the first secret information are generated in the trusted execution environment.
- the embodiments of the present application provide another consensus method for distributed node devices, which is applied to slave node devices in a distributed network.
- the consensus method includes:
- the master node device When receiving the transaction information broadcasted by the master node device and the serial number value of the transaction information, if it is determined that the serial number value of the transaction information is not occupied by other transaction information, the master node device sends a message for the serial number value to the master node device. confirmation information;
- the transaction information is submitted.
- the consensus method further includes:
- the shared key of itself and the electronic signature of the first secret information are stored in the trusted execution environment.
- the sending confirmation information for the serial number value to the master node device includes:
- the master node device when receiving consensus information for the serial number value broadcast by the master node device, if it is confirmed that the consensus information is valid, submitting the transaction information, including:
- the electronic signature of the first secret information is a hash value of the first secret information; correspondingly, the electronic signature of the first secret information is used in the trusted execution environment to perform a verify the validity of the second secret information, and submit the transaction information after confirming that the second secret information is valid, including:
- the transaction information is submitted.
- the embodiments of the present application provide another consensus method for distributed node devices, which is applied to a distributed network.
- the consensus method includes:
- the master node device numbers the transaction information sent by the client in its trusted execution environment, and broadcasts the transaction information and the number value of the transaction information to each slave node device;
- the slave node device When the slave node device receives the transaction information and the serial number value of the transaction information broadcast by the master node device, if it is determined that the serial number value of the transaction information is not occupied by other transaction information, it will report to the master node device.
- the node device sends confirmation information for the number value;
- the master node device submits the transaction information when receiving a first preset number of confirmation messages for the serial number value returned by the slave node devices;
- the master node device generates consensus information for the number value based on the first preset number of the confirmation information in its trusted execution environment, and broadcasts the consensus information to each of the slave node devices;
- the slave node device When the slave node device receives the consensus information for the serial number value broadcast by the master node device, if it is confirmed that the consensus information is valid, it submits the transaction information.
- the consensus method further includes:
- the master node device generates, in its trusted execution environment, the first secret information corresponding to the serial number value and an electronic signature of the first secret information;
- the master node device generates, in its trusted execution environment, the shared key of each node device corresponding to the serial number value based on the first secret information;
- the master node device encrypts the shared key of each of the slave node devices in its trusted execution environment to obtain the ciphertext of the shared key of each of the slave node devices;
- the master node device broadcasts the electronic signature of the first secret information and the ciphertext of the shared key of each of the slave node devices to each of the slave node devices;
- the slave node device When the slave node device receives the electronic signature of the first secret information corresponding to the serial number value broadcasted by the master node device and the ciphertext of the shared key of each of the slave node devices, in its trusted execution environment Decrypt the ciphertext of the shared key of itself in the middle to obtain the shared key of itself;
- the slave node device stores its own shared key and the electronic signature of the first secret information in its own trusted execution environment.
- the slave node device sends confirmation information for the serial number value to the master node device, including:
- the master node device submits the transaction information when receiving the first preset number of confirmation messages for the serial number value returned by the slave node devices, including:
- the master node device submits the transaction information when receiving a first preset number of the slave node devices' own shared keys returned by the slave node devices.
- the master node device generates consensus information for the serial number value based on the first preset number of the confirmation information in its trusted execution environment, and broadcasts the consensus information to each of the slave node devices.
- Consensus information including:
- the master node device generates second secret information corresponding to the serial number value based on the shared keys of the first preset number of slave node devices in its trusted execution environment, and sends the second secret information to each of the slave node devices. broadcasting the second secret information;
- the slave node device when the slave node device receives the consensus information for the number value broadcasted by the master node device, if it confirms that the consensus information is valid, then submits the transaction information, including:
- the slave node device When the slave node device receives the second secret information corresponding to the serial number value broadcast by the master node device, it adopts the electronic signature pair of the first secret information in the trusted execution environment of the slave node device. The validity of the second secret information is verified, and the transaction information is submitted after confirming that the second secret information is valid.
- an embodiment of the present application provides a node device, including:
- a number value determination unit configured to number the transaction information sent by the client in a trusted execution environment, and broadcast the transaction information and the number value of the transaction information to each slave node device;
- a first transaction processing unit configured to submit the transaction information when receiving a first preset number of confirmation information returned by the slave node device for the serial number value; the confirmation information is that the slave node device is in Returned when it is determined that the serial number value of the transaction information is not occupied by other transaction information;
- a consensus information generating unit configured to generate consensus information for the number value based on the first preset number of the confirmation information in the trusted execution environment, and broadcast the consensus to each of the slave node devices information; the consensus information instructs the slave node device to submit the transaction information after being confirmed to be valid by the slave node device;
- the confirmation information sending unit is used to, when receiving the transaction information broadcasted by the master node device and the serial number value of the transaction information, if it is determined that the serial number value of the transaction information is not occupied by other transaction information, send the transaction information to the master node device. sending a confirmation message for the numbered value;
- the second transaction processing unit is configured to submit the transaction information if it is confirmed that the consensus information is valid when the consensus information for the serial number value broadcasted by the master node device is received.
- an embodiment of the present application provides a node device, where the node device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, where the processor executes the The computer program implements the consensus method described in the first aspect, any optional manner of the first aspect, the second aspect, or any optional manner of the second aspect.
- an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, implements any of the first aspect and the first aspect.
- an embodiment of the present application provides a computer program product that, when the computer program product runs on a node device, enables the node device to execute the first aspect, any optional manner of the first aspect, the second aspect, or the second aspect The consensus method described in any optional manner of the aspect.
- an embodiment of the present application provides a distributed network, including multiple node devices, where the node devices are configured to perform the first aspect, any optional manner of the first aspect, the second aspect, or any optional method of the second aspect.
- the consensus method described in the selection method is configured to perform the first aspect, any optional manner of the first aspect, the second aspect, or any optional method of the second aspect.
- the master node device since the master node device numbers the transaction information sent by the client in a trusted execution environment, and the master node device broadcasts the transaction information and the transaction information to the slave node devices After the serial number value is sent to, the slave node device will detect the serial number value of the transaction information, and will only return the confirmation of the serial number value of the transaction information to the master node device when it is confirmed that the serial number value of the transaction information is not occupied by other transaction information. information; and after the master node device broadcasts the consensus information for the number value of the transaction information to the slave node device, the slave node device will verify the validity of the consensus information, and will submit the transaction information only after confirming that the consensus information is valid.
- each slave node device only needs to communicate with the master node device, which reduces the communication complexity in the node device consensus process compared to the node device consensus based on the existing BFT consensus algorithm. .
- FIG. 1 is a schematic structural diagram of a distributed network according to an embodiment of the present application.
- FIG. 2 is a schematic flowchart of a consensus method for distributed node devices according to an embodiment of the present application
- FIG. 3 is a schematic flowchart of a consensus method for distributed node devices according to another embodiment of the present application.
- FIG. 4 is a schematic structural diagram of a node device according to an embodiment of the present application.
- FIG. 5 is a schematic structural diagram of a node device according to another embodiment of the present application.
- FIG. 1 is a schematic structural diagram of a distributed network according to an embodiment of the present application.
- the distributed network may include a plurality of distributed node devices 11 , and each node device 11 can perform peer-to-peer (P2P) communication with any other node device 11 in the distributed network.
- P2P peer-to-peer
- the above-mentioned distributed network may be a blockchain, or may be other types of distributed networks, and the specific type of the distributed network is not particularly limited here.
- the node device 11 may be an electronic device with computing and storage functions.
- the node device 11 may communicate with the corresponding client, for example, the node device 11 may receive transaction information sent by the corresponding client, and perform consensus on the transaction information.
- the corresponding client may be the client of the application.
- the central processing unit (central processing unit) of each node device 11 A trusted execution environment (Trusted Execution Environment) is configured in the processing unit, CPU) Execution Environment, TEE).
- Trusted execution environment is an instruction set extension based on CPU. It can divide a secure area in the CPU that is completely isolated from the outside as a secure execution environment. Any program or data can be run or stored in this secure area. .
- the trusted execution environment can ensure the confidentiality and integrity of the programs and data running or stored in the secure area, thereby ensuring that the programs or data running or stored in the secure area will not be leaked.
- the part of the CPU other than the trusted execution environment is an untrusted space.
- the untrusted space cannot interfere with the running process of the program in the trusted execution environment, and the data generated in the trusted execution environment cannot be stored in the untrusted space. It is tampered with, that is, the consensus process of distributed node devices based on a trusted execution environment will only have the problem of node collapse, but not the problem of node evil (that is, Byzantine error).
- the Trusted Execution Environment may be an Intel chip based software guard extension (software guard) extension, SGX).
- SGX software guard extension
- SGX allows applications to implement a container called enclave, and at the same time, a protected exclusive area is divided in the address space of the corresponding application, which is the enclave container.
- the programs and data in the enclave container provide confidentiality and integrity protection, so that even if the operating system of the node device is compromised, the programs and data in the enclave container will not be affected.
- Each node device 11 in the distributed network ensures the consistency of data among each other through consensus operation.
- each node device 11 in the distributed network will first vote to select one node device 11 as the master node device (ie, the leader) when performing the consensus operation.
- the master node device ie, the leader
- the node device 11 will always act as the master node device; when the master node change event is triggered, each node device 11 will re-vote to select another node device 11
- the master node device that is, the master node device may be any node device 11 in the distributed network, and each node device 11 in the distributed network may be selected as the master node device.
- each node device 11 in the distributed network performs a consensus operation
- other node devices 11 in the distributed network except the master node device are all slave node devices (ie followers), and the distributed network only allows There is one master node device.
- the consensus process of the node device 11 may be divided into one term of office, and each time the master node device changes, it enters a new term.
- the embodiment of the present application may identify the tenure by the master node tenure value, that is, each tenure has a corresponding master node tenure value, and the master node tenure values corresponding to different tenures are different.
- the node device 11 may determine the term value of the master node for each term based on a term value increment policy incremented by a first value.
- the initial value of the tenure value of the master node that is, the tenure value of the master node in the first term
- the first value can be determined according to actual needs.
- the term of the second term corresponds to a term of 2
- the term of the third term corresponds to 3
- the nth term corresponds to a term of 2.
- the term value of the master node corresponding to each term is n.
- FIG. 2 is a schematic flowchart of a consensus method for distributed node devices provided by an embodiment of the present application.
- the execution body of the consensus method for distributed node devices may be the distributed network shown in FIG. 1. .
- FIG. 2 takes a slave node device as an example to illustrate the interaction process between the master node device and the slave node device in the consensus process of the distributed node device.
- the consensus method of distributed node devices can include S21 ⁇ S25, which are detailed as follows:
- the master node device numbers the transaction information sent by the client in its trusted execution environment, and broadcasts the transaction information and the number value of the transaction information to each slave node device.
- the master node device when the master node device receives the transaction information sent by the client, it can number the transaction information in its trusted execution environment to determine the number value of the transaction information.
- the transaction information sent by the client may be one or more.
- the serial number value of the transaction information may be composed of the term value of the master node corresponding to the current term and the sequence number of the transaction information in the current term.
- the current term refers to the term in which the master node device receives the transaction information.
- the master node device may determine the sequence number of each transaction information in the current term based on a sequence number incrementing strategy in which the increment is a second value.
- the second value may be set according to actual requirements, for example, the second value may be 1.
- the transaction information when the master node device broadcasts transaction information and the serial number value of the transaction information to the slave node devices, the transaction information can be associated with the serial number value of the transaction information, and broadcast to each slave node device. Transaction information with an associated relationship and the serial number value of the transaction information.
- each slave node device receives the transaction information broadcast by the master node device and the number value of the transaction information. After that, it can be detected whether the serial number value of each transaction information has been occupied by other transaction information.
- the slave node device may compare the serial number value of each transaction information with the serial number value of each other transaction information received from the slave node device.
- the slave node device may send confirmation information for the serial number value of the transaction information to the master node device.
- the confirmation information for the serial number value of the transaction information is used to indicate that the slave node device has confirmed that the serial number value of the transaction information is not occupied by other transaction information.
- the slave node device determines that the serial number value of other transaction information has the same serial number value as the serial number value of the transaction information, it means that the serial number value of the transaction information has been occupied by other transaction information, At this point, the slave node device can trigger the master node change event. After the master node change event is triggered, each node device enters the master node election link. Since the specific process of the master node election link is the prior art, it will not be described in detail here.
- the master node device submits the transaction information when receiving a first preset number of confirmation messages for the serial number value returned by the slave node devices.
- the master node device obtains the confirmation information of the serial number value of a certain transaction information from more than half of the node devices (including itself), it is considered that the serial number value of the transaction information has been confirmed by all the node devices.
- the node device submitting the transaction information may specifically be: the node device executes a transaction operation corresponding to the transaction information.
- the master node device may also send the transaction information to the client that sends the transaction information and the serial number value of the transaction information, so that the client can determine whether the transaction information sent by it has been agreed by various node devices.
- the master node device generates consensus information for the number value based on the first preset number of the confirmation information in its trusted execution environment, and broadcasts the consensus information to each of the slave node devices .
- the master node device in order to ensure the consistency of operations or data of each node device, after submitting the transaction information, the master node device also targets the transaction information in its trusted execution environment based on the first preset number received.
- the consensus information for the serial number value of a certain transaction information is used to indicate that the serial number value of the transaction information has been confirmed by most of the node devices.
- the master node device After the master node device generates consensus information on the serial number value of a certain transaction information, it broadcasts the consensus information on the serial number value of the transaction information to each slave node device.
- the slave node device after receiving the consensus information for the serial number value of a certain transaction information broadcast by the master node device, the slave node device needs to verify whether the consensus information is valid, that is, verify whether the consensus information can indeed represent the transaction information. The number value has been confirmed by most node devices.
- the slave node device can detect whether the consensus information for a certain transaction information number value includes confirmation information for the number value by a second preset number of node devices in the consensus information. efficient.
- the second preset number is the sum of the first preset number and 1.
- the slave node device confirms that the consensus information for the number value of a certain transaction information includes the confirmation information of the second preset number of node devices for the number value, the consensus information is confirmed to be valid; if the slave node device confirms that the number value is valid for If the consensus information of the serial number value of a certain transaction information does not include the confirmation information of the second preset number of node devices for the serial number value, the consensus information is confirmed to be invalid.
- the slave node device if it confirms that the consensus information for the serial number value of a certain transaction information is valid, it submits the transaction information.
- submitting the transaction information from the node device may be: executing the transaction operation corresponding to the transaction information from the node device.
- the slave node device if the slave node device confirms that the consensus information for the serial number value of a certain transaction information is invalid, the master node change event is triggered.
- the slave node device can also send the transaction information and the serial number value of the transaction information to the client that sent the transaction information, so that the client can determine Whether the transaction information sent by it has been agreed by all node devices.
- the client determines that the transaction information has been agreed by each node device.
- the master node device since the master node device numbers the transaction information sent by the client in a trusted execution environment, and the master node device broadcasts the transaction to the slave node devices After the information and the serial number value of the transaction information are sent to, the slave node device will detect the serial number value of the transaction information, and will only return the transaction information to the master node device when it confirms that the serial number value of the transaction information is not occupied by other transaction information.
- each slave node device only needs to communicate with the master node device, which reduces the communication complexity in the consensus process of node devices compared to the node device consensus based on the existing BFT consensus algorithm. .
- FIG. 3 is a schematic flowchart of a consensus method for distributed node devices provided by another embodiment of the present application.
- the consensus method of the distributed node device in this embodiment may further include S31 to S36 after S21, which are described in detail as follows:
- the master node device generates, in its trusted execution environment, first secret information corresponding to the serial number value and an electronic signature of the first secret information.
- the master node device may randomly generate a first secret information corresponding to the serial number value of the transaction information in its trusted execution environment.
- the master node device can call the random number generation function TEE.Random() provided by the trusted execution environment to generate a random number for each transaction information, and determine the random number to be the same as the The first secret information corresponding to the serial number value of the transaction information.
- TEE.Random() provided by the trusted execution environment to generate a random number for each transaction information, and determine the random number to be the same as the The first secret information corresponding to the serial number value of the transaction information.
- the electronic signature of the first secret information is used to verify the first secret information.
- the electronic signature of the first secret information may be a hash value of the first secret information. Based on this, after obtaining the first secret information corresponding to the serial number value of the transaction information, the master node device calculates the hash value of the first secret information, and the hash value of the first secret information is the electronic value of the first secret information. sign.
- S31 may specifically include the following steps:
- the master node device If the master node device confirms that the transaction information corresponding to the serial number value has not been submitted, it generates first secret information corresponding to the serial number value and an electronic signature of the first secret information in its trusted execution environment.
- each node device may record the serial number value of the submitted transaction information. Based on this, after the master node device numbers each transaction information, the serial number value of the transaction information can be compared with the serial number value of each transaction information submitted by the master node device. When the master node device detects that the number value of the submitted transaction information does not have the same number value as the number value of the transaction information, it confirms that the transaction information has not been submitted. At this time, the master node device is in its trusted execution environment. generate the first secret information corresponding to the serial number value of the transaction information and the electronic signature of the first secret information.
- the master node device generates a shared key of each node device corresponding to the serial number value based on the first secret information in its trusted execution environment.
- the master node device can split the first secret information into n shares of shared keys based on a preset secret sharing algorithm in its trusted execution environment , where n is the total number of node devices included in the distributed network, that is, each shared key obtained by splitting corresponds to one node device.
- the master node device since the key splitting operation of the first secret information is performed in the trusted execution environment of the master node device, the master node device itself does not know the n shares of the shared key. Only after the slave node device informs the master node device of its shared key, the master node device will have the shared key of the slave node device.
- the first secret information can be restored based on the second preset number of shared keys.
- the preset secret sharing algorithm may be any existing secret sharing algorithm.
- the master node device encrypts the shared key of each of the slave node devices in its trusted execution environment to obtain the ciphertext of the shared key of each of the slave node devices.
- the master node device broadcasts the shared key of the slave node device to the slave node devices.
- the shared key of each slave node device can be encrypted in its trusted execution environment to obtain the ciphertext of the shared key of each slave node device.
- the master node device may use the public key in the asymmetric key possessed by each slave node device to encrypt the shared key of each slave node device respectively. In this way, after the slave node device receives the ciphertext of the shared key, it can only decrypt its own shared key through the private key in the asymmetric key it owns, but cannot decrypt the shared keys of other slave node devices. , thereby ensuring that each slave node device only knows its own shared key.
- the master node device broadcasts the electronic signature of the first secret information and the ciphertext of the shared key of each of the slave node devices to each of the slave node devices.
- the master node device After obtaining the ciphertext of the shared key of each slave node device corresponding to the serial number value of the transaction information, the master node device broadcasts the electronic signature of the first secret information and the shared secret key of each slave node device to each slave node device The ciphertext of the key.
- the slave node device After the slave node device receives the electronic signature of the first secret information corresponding to the serial number value of a certain transaction information broadcast by the master node device and the ciphertext of the shared key of each slave node device corresponding to the serial number value, the slave node device can In the trusted execution environment, the private key of the asymmetric key owned by it is used to decrypt the ciphertext of its own shared key to obtain its own shared key.
- the slave node device can trigger a master node change event if a slave node device cannot correctly decrypt its own shared key.
- the slave node device stores its own shared key and the electronic signature of the first secret information in its own trusted execution environment.
- the first secret information corresponding to the serial number value of the transaction information and its own shared key can be stored in its trusted execution environment.
- S22 may specifically include the following steps:
- the slave node device sends the shared key of the slave node device itself to the master node device.
- S23 may specifically include the following steps:
- the master node device submits the transaction information when receiving a first preset number of the slave node devices' own shared keys returned by the slave node devices.
- the slave node device when the slave node device determines that the serial number value of a certain transaction information is not occupied by other transaction information, the slave node device sends its own shared key corresponding to the serial number value to the master node device.
- the master node device After the master node device receives the first preset number of shared keys for the serial number value of the transaction information returned by the slave node devices, it confirms that the serial number value of the transaction information has been confirmed by most of the node devices. At this time, the master node device can Submit the transaction information.
- S24 may specifically include the following steps:
- the master node device generates second secret information corresponding to the serial number value based on the shared keys of the first preset number of slave node devices in its trusted execution environment, and sends the second secret information to each of the slave node devices.
- the second secret information is broadcast.
- S25 may specifically include the following steps:
- the slave node device When the slave node device receives the second secret information corresponding to the serial number value broadcast by the master node device, it adopts the electronic signature pair of the first secret information in the trusted execution environment of the slave node device. The validity of the second secret information is verified, and the transaction information is submitted after confirming that the second secret information is valid.
- the master node device may use the first preset number of shared keys in its trusted execution environment
- the shared key and the shared key of the master node device itself generate second secret information corresponding to the serial number value of the transaction information.
- the master node device may aggregate the first preset number of shared keys and its own shared keys into the second secret information based on a preset secret sharing algorithm.
- the master node device After obtaining the second secret information corresponding to the serial number value of the transaction information, the master node device broadcasts the second secret information to each slave node device. After receiving the second secret information corresponding to the serial number value of a certain transaction information broadcast by the master node device, the slave node device can use the electronic signature pair of the first secret information corresponding to the serial number value of the transaction information in its trusted execution environment. The validity of the second secret information is verified. When the slave node device confirms that the second secret information corresponding to the serial number value of the transaction information is valid, it indicates that the second secret information is indeed generated by the master node device based on the shared keys of the second preset number of node devices, that is, the master node. The device has indeed received the first preset number of shared keys for the serial number value of the transaction information sent from the node device. The second preset number is the sum of the first preset number and 1.
- S25 may specifically include the following steps:
- the slave node device If the slave node device confirms that the hash value of the second secret information is the same as the hash value of the first secret information, it submits the transaction information.
- the slave node device determines that the hash value of the second secret information corresponding to the serial number value of a certain transaction information is the same as the serial number value of the first secret information corresponding to the serial number value, it means that the first secret information corresponding to the serial number value is the same.
- the second secret information is the same as the first secret information for the serial number value, that is, it indicates that the second secret information corresponding to the serial number value of the transaction information is valid.
- the master node device can return the transaction information, the serial number value of the transaction information and the serial number of the transaction information to the client that sent the transaction information The value corresponds to the second secret information.
- the slave node device After confirming that the second secret information corresponding to the serial number value of the transaction information is valid, the slave node device can also return the transaction information, the serial number value of the transaction information, and the serial number value of the transaction information to the client that sent the transaction information. Second Secret Information.
- the consensus algorithm of the distributed node device splits the first secret information corresponding to the serial number value of the transaction information into multiple shared keys, and uses the multiple shared keys to separate Represents the confirmation information of each slave node device for the serial number value of the transaction information. Therefore, when the master node device receives the first preset number of slave node devices to return the shared key for the serial number value, it can be based on the first preset number. Set a number of shared keys and their own shared keys to restore the first secret information of the number value.
- the slave node device can directly verify the validity of the second secret information for the number value recovered by the master node device through the electronic signature of the first secret information corresponding to the number value, which can not only avoid the occurrence of node device consensus process Nodes do evil, and it can improve the consensus efficiency between nodes.
- the embodiments of the present application further provide embodiments of node devices that implement the foregoing method embodiments.
- FIG. 4 is a schematic structural diagram of a node device according to an embodiment of the present application.
- each unit included in the node device is used to execute each step in the method embodiment.
- the node device 40 may include: a number value determination unit 41 , a first transaction processing unit 42 and a consensus information generating unit 43 ; and/or a confirmation information sending unit 44 and a second transaction processing unit 45 . in:
- the number value determination unit 41 is used for the master node device to number the transaction information sent by the client in its trusted execution environment, and to broadcast the transaction information and the number value of the transaction information to each slave node device.
- the first transaction processing unit 42 is used for the master node device to submit the transaction information when receiving confirmation information for the serial number value returned by a first preset number of the slave node devices.
- the consensus information generating unit 43 is used for the master node device to generate consensus information for the serial number value based on the first preset number of the confirmation information in its trusted execution environment, and report it to each of the slave node devices. Broadcast the consensus information.
- the confirmation information sending unit 44 is used for the slave node device, when receiving the transaction information and the serial number value of the transaction information broadcast by the master node device, if it is determined that the serial number value of the transaction information is not matched by other transaction information. If it is occupied, then send confirmation information for the number value to the master node device.
- the second transaction processing unit 45 is configured to, when the slave node device receives the consensus information for the serial number value broadcast by the master node device, submit the transaction information if it is confirmed that the consensus information is valid.
- the node device 40 further includes a secret information generation unit, a shared key generation unit, an encryption/decryption unit, a shared key distribution unit, and a first storage unit. in:
- the secret information generating unit is used for the master node device to generate the first secret information corresponding to the serial number value and the electronic signature of the first secret information in its trusted execution environment.
- the shared key generation unit is used for the master node device to generate the shared key of each node device corresponding to the serial number value based on the first secret information in its trusted execution environment.
- the encryption and decryption unit is used for the master node device to encrypt the shared key of each of the slave node devices in its trusted execution environment to obtain the ciphertext of the shared key of each of the slave node devices.
- the shared key distribution unit is used for the master node device to broadcast the electronic signature of the first secret information and the ciphertext of the shared key of each of the slave node devices to each of the slave node devices.
- the encryption and decryption unit is also used for the electronic signature of the first secret information corresponding to the number value broadcast by the slave node device and the shared key of each of the slave node devices when the slave node device receives the electronic signature.
- the ciphertext is decrypted in its trusted execution environment, the ciphertext of its own shared key is obtained to obtain its own shared key.
- the first storage unit is used for the slave node device to store its own shared key and the electronic signature of the first secret information in its own trusted execution environment.
- the secret information generating unit is specifically configured to: if the master node device confirms that the transaction information corresponding to the serial number value has not been submitted, generate the first secret information corresponding to the serial number value in its trusted execution environment. and an electronic signature of the first secret message.
- the confirmation information sending unit 44 is specifically configured to: the slave node device sends the shared key of the slave node device itself to the master node device.
- the first transaction processing unit 42 is specifically configured to: the master node device submits the transaction information when receiving the shared key of the slave node device itself returned by the first preset number of the slave node devices .
- the consensus information generating unit 43 is specifically configured to: the master node device in its trusted execution environment generates a corresponding number value based on the shared keys of the first preset number of slave node devices. second secret information, and broadcast the second secret information to each of the slave node devices.
- the second transaction processing unit 45 is specifically configured to: when the slave node device receives the second secret information corresponding to the serial number value broadcast by the master node device, perform trusted execution of the slave node device
- the environment uses the electronic signature of the first secret information to verify the validity of the second secret information, and submits the transaction information after confirming that the second secret information is valid.
- the second transaction processing unit 45 is specifically used for:
- the slave node device If the slave node device confirms that the hash value of the second secret information is the same as the hash value of the first secret information, it submits the transaction information.
- FIG. 5 is a schematic structural diagram of a node device according to another embodiment of the present application.
- the node device 5 provided in this embodiment includes: a processor 50 , a memory 51 , and a computer program 52 stored in the memory 51 and running on the processor 50 , such as a distributed node device The corresponding procedure of the consensus method.
- the processor 50 executes the computer program 52
- the steps in the above-mentioned embodiments of the consensus method for each distributed node device are implemented, for example, S21 to S25 shown in FIG. 2 .
- the processor 50 executes the computer program 52
- the computer program 52 may be divided into one or more modules/units, which are stored in the memory 51 and executed by the processor 50 to complete the present application.
- the one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program 52 in the node device 5 .
- the computer program 52 can be divided into a number value determination unit, a first transaction processing unit, and a consensus information generating unit; and/or a confirmation information sending unit and a second transaction processing unit. Please refer to FIG. 2 for specific functions of each unit. The relevant descriptions in the examples will not be repeated here.
- the node device 5 may include, but is not limited to, a processor 50 and a memory 51 .
- FIG. 5 is only an example of the node device 5, and does not constitute a limitation on the node device 5. It may include more or less components than the one shown, or combine some components, or different components
- the node device 5 may also include an input and output device, a network access device, a bus, and the like.
- the processor 50 may be a central processing unit (Central Processing Unit, CPU), other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
- CPU Central Processing Unit
- DSP Digital Signal Processor
- ASIC Application Specific Integrated Circuit
- FPGA off-the-shelf programmable gate array
- a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
- the memory 51 may be an internal storage unit of the node device 5 , such as a hard disk or a memory of the node device 5 .
- the memory 51 can also be an external storage device of the node device 5, for example, a plug-in hard disk equipped on the node device 5, a smart memory card (Smart Media Card, SMC), secure digital (Secure Digital, SD) card, flash memory card (Flash Card), etc.
- the memory 51 may also include both an internal storage unit of the node device 5 and an external storage device.
- the memory 51 is used to store computer programs and other programs and data required by the node device.
- the memory 51 can also be used to temporarily store data that has been output or is to be output.
- Embodiments of the present application also provide a computer-readable storage medium.
- a computer program is stored in the computer-readable storage medium, and when the computer program is executed by the processor, the above consensus method of the distributed node device can be implemented.
- the embodiments of the present application provide a computer program product, when the computer program product runs on a node device, the node device implements the consensus method that can implement the above-mentioned distributed node device.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请适用于分布式网络技术领域，提供了一种分布式节点设备的共识方法、节点设备、分布式网络及介质，其中，共识方法包括：在可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播该交易信息以及该交易信息的编号值；在接收到第一预设数目个从节点设备返回的针对该编号值的确认信息时提交该交易信息；确认信息为从节点设备在确定该交易信息的编号值未被其他交易信息占用时生成；在可信执行环境中基于第一预设数目个确认信息生成针对该编号值的共识信息，并向各个从节点设备广播该共识信息；共识信息用于在被从节点设备确认有效后指示从节点设备提交交易信息，通信复杂度较低，且可以避免共识过程中节点作恶情况的发生。
Description
本申请要求于2020年12月30日提交中国专利局、申请号为202011630328.3，名称为“分布式节点设备的共识方法、节点设备及分布式网络”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
本申请属于分布式网络技术领域，尤其涉及一种分布式节点设备的共识方法、节点设备、分布式网络及计算机可读存储介质。
共识算法是分布式网络中各个节点设备之间保持一致性的基础。随着分布式网络技术的快速发展，现有技术针对不同的分布式网络提出了不同的共识算法。例如，针对包含故障节点的分布式网络提出故障容错（Crash
Fault Tolerance，CFT）共识算法，针对包含故障节点以及作恶节点的分布式网络提出拜占庭容错（Byzantine
Fault Tolerance）共识算法。
不同共识算法对应的节点设备之间的共识过程以及通信复杂度均不同。例如，节点设备基于BFT共识算法进行共识时，每个节点设备均需要与其他各个节点设备均进行通信；而节点设备基于CFT共识算法进行共识时，每个从节点设备只需要与主节点设备进行通信即可，可见，节点设备基于BFT共识算法进行共识时的通信复杂度远高于节点设备基于CFT共识算法进行共识时的通信复杂度，然而，虽然节点设备基于CFT共识算法进行共识时的通信复杂度较低，但节点设备基于CFT共识算法进行共识时无法解决节点作恶问题。
本申请实施例提供了一种分布式节点设备的共识方法、节点设备、分布式网络及计算机可读存储介质，以解决现有的分布式节点设备的共识方法无法解决节点作恶问题或者通信复杂度较高的技术问题。
第一方面，本申请实施例提供一种分布式节点设备的共识方法，应用于分布式网络中的主节点设备，所述共识方法包括：
在可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；
在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；所述确认信息为所述从节点设备在确定所述交易信息的编号值未被其他交易信息占用时返回的；
在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；所述共识信息在被所述从节点设备确认有效后指示所述从节点设备提交所述交易信息。
可选的，所述在可信执行环境中对客户端发送的交易信息进行编号之后，所述共识方法还包括：
在所述可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名；
在所述可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥；
在所述可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文；
向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文。
可选的，所述在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息，包括：
在接收到第一预设数目个所述从节点设备返回的其自身的共享密钥时提交所述交易信息。
可选的，所述在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息，包括：
在所述可信执行环境中基于所述第一预设数目个所述从节点设备的共享密钥生成所述编号值对应的第二秘密信息；
向各个所述从节点设备广播所述第二秘密信息。
可选的，所述在所述可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名，包括：
若所述编号值对应的交易信息未被提交，则在所述可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名。
第二方面，本申请实施例提供另一种分布式节点设备的共识方法，应用于分布式网络中的从节点设备，所述共识方法包括：
在接收到主节点设备广播的交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；
在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
可选的，所述共识方法还包括：
在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及所述从节点设备自身的共享密钥的密文时，在自身的可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥；
在所述可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
可选的，所述向所述主节点设备发送针对所述编号值的确认信息，包括：
向所述主节点设备发送自身的所述共享密钥。
可选的，所述在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息，包括：
在接收到所述主节点设备广播的所述编号值对应的第二秘密信息时，在所述可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息。
可选的，所述第一秘密信息的电子签名为所述第一秘密信息的哈希值；相应地，所述在所述可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息，包括：
在所述可信执行环境中生成所述第二秘密信息的哈希值；
若所述第二秘密信息的哈希值与所述第一秘密信息的哈希值相同，则提交所述交易信息。
第三方面，本申请实施例提供又一种分布式节点设备的共识方法，应用于分布式网络，所述共识方法包括：
主节点设备在其可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；
所述从节点设备在接收到所述主节点设备广播的所述交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；
所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；
所述主节点设备在其可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；
所述从节点设备在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
可选的，所述主节点设备在其可信执行环境中对客户端发送的交易信息进行编号之后，所述共识方法还包括：
所述主节点设备在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名；
所述主节点设备在其可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥；
所述主节点设备在其可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文；
所述主节点设备向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文；
所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及各个所述从节点设备的共享密钥的密文时，在其可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥；
所述从节点设备在自身的可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
可选的，所述从节点设备向所述主节点设备发送针对所述编号值的确认信息，包括：
所述从节点设备向所述主节点设备发送所述从节点设备自身的所述共享密钥；
相应地，所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息，包括：
所述主节点设备在接收到第一预设数目个所述从节点设备返回的所述从节点设备自身的共享密钥时提交所述交易信息。
可选的，所述主节点设备在其可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息，包括：
所述主节点设备在其可信执行环境中基于所述第一预设数目个所述从节点设备的共享密钥生成所述编号值对应的第二秘密信息，并向各个所述从节点设备广播所述第二秘密信息；
相应地，所述从节点设备在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息，包括：
所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第二秘密信息时，在所述从节点设备的可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息。
第四方面，本申请实施例提供一种节点设备，包括：
编号值确定单元，用于在可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；
第一交易处理单元，用于在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；所述确认信息为所述从节点设备在确定所述交易信息的编号值未被其他交易信息占用时返回的；
共识信息生成单元，用于在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；所述共识信息在被所述从节点设备确认有效后指示所述从节点设备提交所述交易信息；和/或
确认信息发送单元，用于在接收到主节点设备广播的交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；
第二交易处理单元，用于在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
第五方面，本申请实施例提供一种节点设备，所述节点设备包括处理器、存储器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面、第一方面的任意可选方式、第二方面或第二方面的任意可选方式所述的共识方法。
第六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面、第一方面的任意可选方式、第二方面或第二方面的任意可选方式所述的共识方法。
第七方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在节点设备上运行时，使得节点设备执行上述第一方面、第一方面的任意可选方式、第二方面或第二方面的任意可选方式所述的共识方法。
第八方面，本申请实施例提供一种分布式网络，包括多个节点设备，节点设备用于执行上述第一方面、第一方面的任意可选方式、第二方面或第二方面的任意可选方式所述的共识方法。
本申请实施例提供的分布式节点设备的共识方法，由于主节点设备是在可信执行环境中对客户端发送的交易信息进行编号，且主节点设备向从节点设备广播交易信息以及交易信息的编号值发送给后，从节点设备会对交易信息的编号值进行检测，在确认该交易信息的编号值未被其他交易信息占用时才会向主节点设备返回针对该交易信息的编号值的确认信息；且主节点设备在向从节点设备广播针对交易信息的编号值的共识信息后，从节点设备会对该共识信息的有效性进行验证，在确认该共识信息有效后才会提交该交易信息，从而避免了共识过程中节点作恶情况的发生。另外，在节点设备的共识过程中，各个从节点设备只需与主节点设备进行通信，相对于节点设备基于现有的BFT共识算法进行共识而言，降低了节点设备共识过程中的通信复杂度。
图1为本申请实施例提供的一种分布式网络的结构示意图；
图2为本申请实施例提供的一种分布式节点设备的共识方法的示意性流程图；
图3为本申请另一实施例提供的一种分布式节点设备的共识方法的示意性流程图；
图4为本申请实施例提供的一种节点设备的结构示意图；
图5为本申请另一实施例提供的一种节点设备的结构示意图。
请参阅图1，图1为本申请实施例提供的一种分布式网络的结构示意图。如图1所示，该分布式网络可以包括多个分布式的节点设备11，每个节点设备11均可以与分布式网络中任意一个其他节点设备11进行点对点（peer to peer，P2P）通信。
在具体应用中，上述分布式网络可以为区块链，也可以为其他类型的分布式网络，此处不对分布式网络的具体类型做特别限定。
节点设备11可以为具有计算及存储功能的电子设备。节点设备11可以与对应的客户端进行通信，例如，节点设备11可以接收对应的客户端发送的交易信息，并对该交易信息进行共识。作为示例而非限定，当节点设备11为某个应用程序的服务器时，对应的客户端可以为该应用程序的客户端。
本申请实施例中，每个节点设备11的中央处理器（central
processing unit，CPU）中都配置有可信执行环境（Trusted
Execution Environment，TEE）。可信执行环境是基于CPU的一种指令集扩展，它可以在CPU中划分出一块与外部完全隔离的安全区域作为一个安全的执行环境，任何程序或数据均可以运行或存储在该安全区域中。可信执行环境可以保证运行或存储在安全区域中的程序及数据的机密性和完整性，进而保证运行或存储在安全区域中的程序或数据不会被泄露出去。CPU中除了可信执行环境之外的部分为非可信空间，非可信空间无法干预可信执行环境中程序的运行过程，且在可信执行环境中生成的数据也无法在非可信空间中被篡改，即基于可信执行环境的分布式节点设备的共识过程只会出现节点崩溃问题，而不会出现节点作恶问题（即拜占庭错误）。
作为示例而非限定，可信执行环境可以是基于英特尔（Intel）芯片的软件保护扩展（software guard
extension，SGX）。SGX通过在Intel架构上增加新的指令集和内存访问机制，允许应用程序实现一个被称为enclave的容器，同时会在相应应用程序的地址空间中划分出一块被保护的专属区域，为enclave容器中的程序和数据提供机密性和完整性的保护，这样，即使节点设备的操作系统被攻破也不会影响enclave容器中的程序和数据。
分布式网络中的各个节点设备11是通过共识操作来保证彼此之间数据的一致性的。本实施例中，分布式网络中的各个节点设备11在进行共识操作时，会先投票选择选出一个节点设备11作为主节点设备（即领导者）。在整个共识过程中，只要主节点变更事件未被触发，则该节点设备11将会一直作为主节点设备；当主节点变更事件被触发时，各个节点设备11会重新投票选择出另一个节点设备11作为主节点设备，即主节点设备可以是分布式网络中的任一节点设备11，分布式网络中的每个节点设备11均有可能被选为主节点设备。
分布式网络中的各个节点设备11在进行共识操作时，分布式网络中除了主节点设备之外的其他节点设备11均为从节点设备（即跟随者），且分布式网络在任一时刻仅允许有一个主节点设备。
本申请实施例可以将节点设备11的共识过程分为一个一个的任期，主节点设备每变更一次，则进入一个新的任期。为了对不同的任期进行区分，本申请实施例可以通过主节点任期值来标识任期，即每个任期都有对应的主节点任期值，不同任期对应的主节点任期值不同。
在本申请的一个实施例中，节点设备11可以基于增量为第一数值的任期值递增策略确定每个任期的主节点任期值。其中，主节点任期值的初始值（即第一个任期的主节点任期值）以及第一数值均可以根据实际需求确定。
例如，假如第一个任期的主节点任期值为1，第一数值为1，则第二个任期对应的主节点任期值为2，第三个任期对应的主节点任期值为3，第n个任期对应的主节点任期值为n。
以下对本申请实施例提供的分布式节点设备的共识方法进行详细说明：
请参阅图2，图2为本申请实施例提供的一种分布式节点设备的共识方法的示意性流程图，该分布式节点设备的共识方法的执行主体可以为图1所示的分布式网络。图2以一个从节点设备为例，对分布式节点设备的共识过程中主节点设备与从节点设备之间的交互过程进行说明。如图2所示，分布式节点设备的共识方法可以包括S21~S25，详述如下：
S21：主节点设备在其可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值。
本实施例中，当主节点设备接收到客户端发送的交易信息时，可以在其可信执行环境中对该交易信息进行编号，确定该交易信息的编号值。
在具体应用中，客户端发送的交易信息可以为一个或多个。
在本申请的一个实施例中，交易信息的编号值可以由当前任期对应的主节点任期值以及该交易信息在当前任期内的序号构成。当前任期指主节点设备接收到该交易信息时所在的任期。
在本实施例的一种实现方式中，主节点设备可以基于增量为第二数值的序号递增策略确定每个交易信息在当前任期内的序号。其中，第二数值可以根据实际需求设置，例如，第二数值可以为1。
在本申请的一个实施例中，主节点设备向从节点设备广播交易信息以及所述交易信息的编号值时，可以将交易信息与该交易信息的编号值进行关联，并向各个从节点设备广播具有关联关系的交易信息以及交易信息的编号值。
S22：所述从节点设备在接收到所述主节点设备广播的所述交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息。
本实施例中，为了防止多条不同的交易信息采用同一个编号值，进而影响节点设备对交易信息的共识结果，各个从节点设备接收到主节点设备广播的交易信息以及该交易信息的编号值后，可以检测每个交易信息的编号值是否已被其他交易信息占用。
具体地，从节点设备可以将每个交易信息的编号值与从节点设备接收到的各个其他交易信息的编号值进行比较。
在本申请的一个实施例中，从节点设备若确定其他交易信息的编号值中不存在与该交易信息的编号值相同的编号值，则说明该交易信息的编号值未被其他交易信息占用，此时从节点设备可以向主节点设备发送针对该交易信息的编号值的确认信息。其中，针对交易信息的编号值的确认信息用于表示从节点设备已确认该交易信息的编号值未被其他交易信息占用。
在本申请的另一个实施例中，从节点设备若确定其他交易信息的编号值中存在与该交易信息的编号值相同的编号值，则说明该交易信息的编号值已被其他交易信息占用，此时从节点设备可以触发主节点变更事件。主节点变更事件被触发后，各个节点设备进入主节点选举环节，由于主节点选举环节的具体过程为现有技术，因此此处不对其进行详细描述。
S23：所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息。
通常，主节点设备获得一半以上的节点设备（包括其自身）针对某个交易信息的编号值的确认信息时，即认为该交易信息的编号值已被所有节点设备确认，基于此，第一预设数目不小于n/2，其中，n为分布式网络包括的节点设备的总数量。示例性的，例如，若n=5，则第一预设数目可以为3；若n=4，则第一预设数目也可以为3；若n=3，则第一预设数目可以为2。
在本申请的一个实施例中，节点设备提交交易信息具体可以为：节点设备执行该交易信息对应的交易操作。
本申请实施例中，主节点设备在接收到第一预设数目个从节点设备返回的针对某个交易信息的编号值的确认信息后，还可以向发送该交易信息的客户端发送该交易信息以及该交易信息的编号值，以便客户端确定其发送的该交易信息是否已被各个节点设备共识。
S24：所述主节点设备在其可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息。
本申请实施例中，为了保证各个节点设备的操作或者数据的一致性，主节点设备在提交交易信息后，还在其可信执行环境中基于接收到的第一预设数目个针对该交易信息的编号值的确认信息以及主节点设备自身生成的针对该编号值的确认信息，生成针对该编号值的共识信息。
其中，针对某个交易信息的编号值的共识信息用于表示该交易信息的编号值已被大部分节点设备确认。
主节点设备生成针对某个交易信息的编号值的共识信息后，向各个从节点设备广播针对该交易信息的编号值的共识信息。
S25：所述从节点设备在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
本申请实施例中，从节点设备接收到主节点设备广播的针对某个交易信息的编号值的共识信息后，需要验证该共识信息是否有效，即验证该共识信息是否确实能够表示该交易信息的编号值已被大部分节点设备确认。
在本申请的一个实施例中，从节点设备可以通过检测针对某个交易信息的编号值的共识信息中是否包括第二预设数目个节点设备针对该编号值的确认信息来检测该共识信息是否有效。其中，第二预设数目为第一预设数目与1之和。
具体地，从节点设备若确认针对某个交易信息的编号值的共识信息中包括第二预设数目个节点设备针对该编号值的确认信息，则确认该共识信息有效；从节点设备若确认针对某个交易信息的编号值的共识信息中未包括第二预设数目个节点设备针对该编号值的确认信息，则确认该共识信息无效。
在本申请的一个实施例中，从节点设备若确认针对某个交易信息的编号值的共识信息有效，则提交该交易信息。其中，从节点设备提交交易信息可以为：从节点设备执行该交易信息对应的交易操作。
在本申请的另一个实施例中，从节点设备若确认针对某个交易信息的编号值的共识信息无效，则触发主节点变更事件。
在具体应用中，从节点设备在确认针对某个交易信息的编号值的共识信息有效后，还可以向发送该交易信息的客户端发送该交易信息以及该交易信息的编号值，以便客户端确定其发送的该交易信息是否已被各个节点设备共识。
具体地，针对客户端发送的某个交易信息，客户端若接收到第二预设数目个不同节点设备发送的该交易信息的编号值，且该第二预设数目个编号值相同，则客户端确定该交易信息已被各个节点设备共识。
以上可以看出，本申请实施例提供的分布式节点设备的共识方法，由于主节点设备是在可信执行环境中对客户端发送的交易信息进行编号，且主节点设备向从节点设备广播交易信息以及交易信息的编号值发送给后，从节点设备会对交易信息的编号值进行检测，在确认该交易信息的编号值未被其他交易信息占用时才会向主节点设备返回针对该交易信息的编号值的确认信息；且主节点设备在向从节点设备广播针对交易信息的编号值的共识信息后，从节点设备会对该共识信息的有效性进行验证，在确认该共识信息有效后才会提交该交易信息，从而避免了共识过程中节点作恶情况的发生。另外，在节点设备的共识过程中，各个从节点设备只需与主节点设备进行通信，相对于节点设备基于现有的BFT共识算法进行共识而言，降低了节点设备共识过程中的通信复杂度。
请参阅图3，图3为本申请另一实施例提供的一种分布式节点设备的共识方法的示意性流程图。相对于图2对应的实施例，本实施例中的分布式节点设备的共识方法在S21之后，还可以包括S31~S36，详述如下：
S31：所述主节点设备在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名。
本实施例中，针对每个交易信息，主节点设备可以在其可信执行环境中随机生成一个与该交易信息的编号值对应的第一秘密信息。
具体地，在本申请的一个实施例中，主节点设备可以调用可信执行环境提供的随机数生成函数TEE.Random()为每个交易信息生成一个随机数，并将该随机数确定为与该交易信息的编号值对应的第一秘密信息。
第一秘密信息的电子签名用于对第一秘密信息进行校验。
在本申请的一个实施例中，第一秘密信息的电子签名可以为第一秘密信息的哈希值。基于此，主节点设备在得到交易信息的编号值对应的第一秘密信息后，计算该第一秘密信息的哈希值，该第一秘密信息的哈希值即为该第一秘密信息的电子签名。
在本申请的另一实施例中，S31具体可以包括以下步骤：
所述主节点设备若确认所述编号值对应的交易信息未被提交，则在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名。
本实施例中，为了避免节点设备重复对同一个交易信息进行多次共识操作，各个节点设备可以对其已提交的交易信息的编号值进行记录。基于此，主节点设备在为每个交易信息进行编号后，可以将该交易信息的编号值与主节点设备已提交的各个交易信息的编号值进行比较。主节点设备在检测到已提交的交易信息的编号值中不存在与该交易信息的编号值相同的编号值时，确认该交易信息未被提交，此时主节点设备才在其可信执行环境中生成该交易信息的编号值对应的第一秘密信息以及该第一秘密信息的电子签名。
S32：所述主节点设备在其可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥。
本实施例中，主节点设备生成交易信息的编号值对应的第一秘密信息后，可以在其可信执行环境中基于预设秘密共享算法将该第一秘密信息拆分为n份共享密钥，其中，n为分布式网络包括的节点设备的总数量，即拆分得到的每份共享密钥分别对应一个节点设备。
需要说明的是，由于第一秘密信息的密钥拆分操作是在主节点设备的可信执行环境中执行的，因此，主节点设备自身并不知晓该n份共享密钥。只有从节点设备将其共享密钥告知主节点设备后，主节点设备才会拥有该从节点设备的共享密钥。
本申请实施例中，主节点设备拥有第二预设数目个节点设备（包括其自身）的共享密钥后，即可基于该第二预设数目个共享密钥还原出第一秘密信息。
在具体应用中，预设秘密共享算法可以是现有的任一秘密共享算法。
S33：所述主节点设备在其可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文。
本实施例中，为了提高从节点设备的共享密钥的安全性，保证每个从节点设备的共享密钥不被其他从节点设备获知，主节点设备向从节点设备广播从节点设备的共享密钥时，可以在其可信执行环境中对各个从节点设备的共享密钥进行加密，得到各个从节点设备的共享密钥的密文。
在本申请的一个实施例中，主节点设备可以采用每个从节点设备所拥有的非对称密钥中的公钥分别对每个从节点设备的共享密钥进行加密。这样，从节点设备接收到共享密钥的密文后，只能通过其拥有的非对称密钥中的私钥解密出其自身的共享密钥，而无法解密出其他从节点设备的共享密钥，从而可以保证各个从节点设备只知晓其自身的共享密钥。
S34：所述主节点设备向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文。
本实施例中，主节点设备得到交易信息的编号值对应的各个从节点设备的共享密钥的密文后，向各个从节点设备广播第一秘密信息的电子签名以及各个从节点设备的共享密钥的密文。
S35：所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文时，在其可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥。
从节点设备接收到主节点设备广播的某个交易信息的编号值对应的第一秘密信息的电子签名以及该编号值对应的各个从节点设备的共享密钥的密文后，从节点设备可以在其可信执行环境中采用其拥有的非对称密钥的私钥解密其自身的共享密钥的密文，得到其自身的共享密钥。
需要说明的是，在本申请另一个实施例中，若某个从节点设备无法正确解密出其自身的共享密钥，则该从节点设备可以触发主节点变更事件。
S36：所述从节点设备在自身的可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
本实施例中，从节点设备得到其自身的共享密钥后，可以将交易信息的编号值对应的第一秘密信息以及其自身的共享密钥存储在其可信执行环境中。
基于图3对应的实施例，在一种实现方式中，S22具体可以包括以下步骤：
所述从节点设备向所述主节点设备发送所述从节点设备自身的所述共享密钥。
相应地，S23具体可以包括以下步骤：
所述主节点设备在接收到第一预设数目个所述从节点设备返回的所述从节点设备自身的共享密钥时提交所述交易信息。
本实施中，从节点设备在确定某个交易信息的编号值未被其他交易信息占用时向主节点设备发送自身的与该编号值对应的共享密钥。
主节点设备接收到第一预设数目个从节点设备返回的针对该交易信息的编号值的共享密钥后，确认该交易信息的编号值已被大部分节点设备确认，此时主节点设备可以提交该交易信息。
在另一种实现方式中，S24具体可以包括以下步骤：
所述主节点设备在其可信执行环境中基于所述第一预设数目个所述从节点设备的共享密钥生成所述编号值对应的第二秘密信息，并向各个所述从节点设备广播所述第二秘密信息。
相应地，S25具体可以包括以下步骤：
所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第二秘密信息时，在所述从节点设备的可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息。
本实施例中，主节点设备接收到第一预设数目个从节点设备返回的针对该交易信息的编号值的共享密钥后，可以在其可信执行环境中基于该第一预设数目个共享密钥以及主节点设备自身的共享密钥，生成该交易信息的编号值对应的第二秘密信息。
在具体应用中，主节点设备可以基于预设秘密共享算法将该第一预设数目个共享密钥与其自身的共享密钥聚合为第二秘密信息。
主节点设备得到该交易信息的编号值对应的第二秘密信息后，向各个从节点设备广播该第二秘密信息。从节点设备接收到主节点设备广播的某个交易信息的编号值对应的第二秘密信息后，可以在其可信执行环境中采用该交易信息的编号值对应的第一秘密信息的电子签名对该第二秘密信息的有效性进行验证。从节点设备在确认该交易信息的编号值对应的第二秘密信息有效时，说明该第二秘密信息确实为主节点设备基于第二预设数目个节点设备的共享密钥生成的，即主节点设备确实接收到了第一预设数目个从节点设备发送的针对该交易信息的编号值的共享密钥。其中，第二预设数目为第一预设数目与1之和。
在具体应用中，当第一秘密信息的电子签名为第一秘密信息的哈希值时，S25具体可以包括以下步骤：
从节点设备在其可信执行环境中生成所述第二秘密信息的哈希值；
从节点设备若确认所述第二秘密信息的哈希值与所述第一秘密信息的哈希值相同，则提交所述交易信息。
本实施例中，从节点设备在确定某个交易信息的编号值对应的第二秘密信息的哈希值与针对该编号值的第一秘密信息的编号值相同，则说明针对该编号值的第二秘密信息与针对该编号值的第一秘密信息相同，即说明该交易信息的编号值对应的第二秘密信息是有效的。
在具体应用中，主节点设备生成某个交易信息的编号值对应的第二秘密信息后，可以向发送该交易信息的客户端返回该交易信息、该交易信息的编号值以及该交易信息的编号值对应的第二秘密信息。
从节点设备在确认该交易信息的编号值对应的第二秘密信息有效后，也可以向发送该交易信息的客户端返回该交易信息、该交易信息的编号值以及该交易信息的编号值对应的第二秘密信息。
基于此，针对某个交易信息，当客户端接收到的来自第二预设数目个不同节点设备的该交易信息的编号值以及该交易信息的编号值对应的第二秘密信息均相同时，可以认为该交易信息已被各个节点设备共识。
以上可以看出，本实施例提供的分布式节点设备的共识算法，由于将交易信息的编号值对应的第一秘密信息拆分为多个共享密钥，并通过该多个共享密钥来分别表示各个从节点设备针对该交易信息的编号值的确认信息，因此，当主节点设备接收到第一预设数目个从节点设备返回的针对该编号值的共享密钥时便可基于该第一预设数目个共享密钥与其自身的共享密钥对该编号值的第一秘密信息进行恢复。基于此，从节点设备可以直接通过该编号值对应的第一秘密信息的电子签名验证主节点设备恢复出的针对该编号值的第二秘密信息的有效性，不仅可以避免节点设备共识过程中出现节点作恶问题，而且可以提高各节点之间的共识效率。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
基于上述实施例所提供的分布式节点设备的共识方法，本申请实施例进一步给出实现上述方法实施例的节点设备的实施例。
请参阅图4，图4为本申请实施例提供的一种节点设备的结构示意图。本申请实施例中，节点设备包括的各单元用于执行方法实施例中的各步骤。具体请参阅方法实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。如图4所示，节点设备40可以包括：编号值确定单元41、第一交易处理单元42及共识信息生成单元43；和/或确认信息发送单元44及第二交易处理单元45。其中：
编号值确定单元41用于主节点设备在其可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值。
第一交易处理单元42用于所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息。
共识信息生成单元43用于所述主节点设备在其可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息。
确认信息发送单元44用于所述从节点设备在接收到所述主节点设备广播的所述交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息。
第二交易处理单元45用于所述从节点设备在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
可选的，节点设备40还包括秘密信息生成单元、共享密钥生成单元、加解密单元、共享密钥分发单元以及第一存储单元。其中：
秘密信息生成单元用于所述主节点设备在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名。
共享密钥生成单元用于所述主节点设备在其可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥。
加解密单元用于所述主节点设备在其可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文。
共享密钥分发单元用于所述主节点设备向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文。
所述加解密单元还用于所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文时，在其可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥。
第一存储单元用于所述从节点设备在自身的可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
可选的，秘密信息生成单元具体用于：所述主节点设备若确认所述编号值对应的交易信息未被提交，则在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名。
可选的，确认信息发送单元44具体用于：所述从节点设备向所述主节点设备发送所述从节点设备自身的所述共享密钥。
相应的，第一交易处理单元42具体用于：所述主节点设备在接收到第一预设数目个所述从节点设备返回的所述从节点设备自身的共享密钥时提交所述交易信息。
可选的，共识信息生成单元43具体用于：所述主节点设备在其可信执行环境中基于所述第一预设数目个所述从节点设备的共享密钥生成所述编号值对应的第二秘密信息，并向各个所述从节点设备广播所述第二秘密信息。
相应的，第二交易处理单元45具体用于：所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第二秘密信息时，在所述从节点设备的可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息。
可选的，第二交易处理单元45具体用于：
从节点设备在其可信执行环境中生成所述第二秘密信息的哈希值；
从节点设备若确认所述第二秘密信息的哈希值与所述第一秘密信息的哈希值相同，则提交所述交易信息。
上述模块之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参照方法实施例部分，此处不再赘述。
图5为本申请另一实施例提供的一种节点设备的结构示意图。如图5所示，该实施例提供的节点设备5包括：处理器50、存储器51以及存储在所述存储器51中并可在所述处理器50上运行的计算机程序52，例如分布式节点设备的共识方法对应的程序。处理器50执行所述计算机程序52时实现上述各个分布式节点设备的共识方法实施例中的步骤，例如图2所示的S21~S25。或者，所述处理器50执行所述计算机程序52时实现上述各节点设备实施例中各模块/单元的功能，例如图4所示单元41~45的功能。
示例性的，计算机程序52可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在存储器51中，并由处理器50执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序52在节点设备5中的执行过程。例如，计算机程序52可以被分割成编号值确定单元、第一交易处理单元及共识信息生成单元；和/或确认信息发送单元及第二交易处理单元，各单元具体功能请参阅图2对应地实施例中的相关描述，此处不赘述。
节点设备5可包括但不仅限于，处理器50、存储器51。本领域技术人员可以理解，图5仅仅是节点设备5的示例，并不构成对节点设备5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如节点设备5还可以包括输入输出设备、网络接入设备、总线等。
处理器50可以是中央处理单元(Central
Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器
(Digital Signal Processor，DSP)、专用集成电路 (Application
Specific Integrated Circuit，ASIC)、现成可编程门阵列
(Field-Programmable Gate Array，FPGA)
或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器51可以是节点设备5的内部存储单元，例如节点设备5的硬盘或内存。存储器51也可以是节点设备5的外部存储设备，例如节点设备5上配备的插接式硬盘，智能存储卡（Smart
Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。进一步地，存储器51还可以既包括节点设备5的内部存储单元也包括外部存储设备。存储器51用于存储计算机程序以及节点设备所需的其他程序和数据。存储器51还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例还提供了一种计算机可读存储介质。计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时可实现上述分布式节点设备的共识方法。
本申请实施例提供了一种计算机程序产品，当计算机程序产品在节点设备上运行时，使得节点设备执行时实现可实现上述分布式节点设备的共识方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。
Claims (14)
- 一种分布式节点设备的共识方法，应用于分布式网络中的主节点设备，其特征在于，所述共识方法包括：在可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；所述确认信息为所述从节点设备在确定所述交易信息的编号值未被其他交易信息占用时返回的；在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；所述共识信息在被所述从节点设备确认有效后指示所述从节点设备提交所述交易信息。
- 根据权利要求1所述的共识方法，其特征在于，所述在可信执行环境中对客户端发送的交易信息进行编号之后，所述共识方法还包括：在所述可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名；在所述可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥；在所述可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文；向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文。
- 根据权利要求2所述的共识方法，其特征在于，所述在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息，包括：在接收到第一预设数目个所述从节点设备返回的其自身的共享密钥时提交所述交易信息。
- 根据权利要求3所述的共识方法，其特征在于，所述在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息，包括：在所述可信执行环境中基于所述第一预设数目个所述从节点设备的共享密钥生成所述编号值对应的第二秘密信息；向各个所述从节点设备广播所述第二秘密信息。
- 一种分布式节点设备的共识方法，应用于分布式网络中的从节点设备，其特征在于，所述共识方法包括：在接收到主节点设备广播的交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
- 根据权利要求5所述的共识方法，其特征在于，所述共识方法还包括：在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及所述从节点设备自身的共享密钥的密文时，在自身的可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥；在所述可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
- 根据权利要求6所述的共识方法，其特征在于，所述在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息，包括：在接收到所述主节点设备广播的所述编号值对应的第二秘密信息时，在所述可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息。
- 根据权利要求7所述的共识方法，其特征在于，所述第一秘密信息的电子签名为所述第一秘密信息的哈希值；相应地，所述在所述可信执行环境中采用所述第一秘密信息的电子签名对所述第二秘密信息的有效性进行验证，并在确认所述第二秘密信息有效后提交所述交易信息，包括：在所述可信执行环境中生成所述第二秘密信息的哈希值；若所述第二秘密信息的哈希值与所述第一秘密信息的哈希值相同，则提交所述交易信息。
- 一种分布式节点设备的共识方法，应用于分布式网络，其特征在于，所述共识方法包括：主节点设备在其可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；所述从节点设备在接收到所述主节点设备广播的所述交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；所述主节点设备在其可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；所述从节点设备在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
- 根据权利要求9所述的共识方法，其特征在于，所述主节点设备在其可信执行环境中对客户端发送的交易信息进行编号之后，所述共识方法还包括：所述主节点设备在其可信执行环境中生成所述编号值对应的第一秘密信息以及所述第一秘密信息的电子签名；所述主节点设备在其可信执行环境中基于所述第一秘密信息生成所述编号值对应的各个节点设备的共享密钥；所述主节点设备在其可信执行环境中加密各个所述从节点设备的所述共享密钥得到各个所述从节点设备的所述共享密钥的密文；所述主节点设备向各个所述从节点设备广播所述第一秘密信息的电子签名以及各个所述从节点设备的所述共享密钥的密文；所述从节点设备在接收到所述主节点设备广播的所述编号值对应的第一秘密信息的电子签名以及各个所述从节点设备的共享密钥的密文时，在其可信执行环境中解密自身的所述共享密钥的密文，得到自身的所述共享密钥；所述从节点设备在自身的可信执行环境中存储自身的所述共享密钥以及所述第一秘密信息的电子签名。
- 根据权利要求10所述的共识方法，其特征在于，所述从节点设备向所述主节点设备发送针对所述编号值的确认信息，包括：所述从节点设备向所述主节点设备发送所述从节点设备自身的所述共享密钥；相应地，所述主节点设备在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息，包括：所述主节点设备在接收到第一预设数目个所述从节点设备返回的所述从节点设备自身的共享密钥时提交所述交易信息。
- 一种节点设备，其特征在于，包括：编号值确定单元，用于在可信执行环境中对客户端发送的交易信息进行编号，并向各个从节点设备广播所述交易信息以及所述交易信息的编号值；第一交易处理单元，用于在接收到第一预设数目个所述从节点设备返回的针对所述编号值的确认信息时提交所述交易信息；所述确认信息为所述从节点设备在确定所述交易信息的编号值未被其他交易信息占用时返回的；共识信息生成单元，用于在所述可信执行环境中基于所述第一预设数目个所述确认信息生成针对所述编号值的共识信息，并向各个所述从节点设备广播所述共识信息；所述共识信息在被所述从节点设备确认有效后指示所述从节点设备提交所述交易信息；和/或确认信息发送单元，用于在接收到主节点设备广播的交易信息以及所述交易信息的编号值时，若确定所述交易信息的编号值未被其他交易信息占用，则向所述主节点设备发送针对所述编号值的确认信息；第二交易处理单元，用于在接收到所述主节点设备广播的针对所述编号值的共识信息时，若确认所述共识信息有效，则提交所述交易信息。
- 一种节点设备，其特征在于，所述节点设备包括处理器、存储器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至4任一项或者如权利要求5至8任一项所述的共识方法。
- 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至4任一项或者如权利要求5至8任一项所述的共识方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011630328.3 | 2020-12-30 | ||
| CN202011630328.3A CN112865959B (zh) | 2020-12-30 | 2020-12-30 | 分布式节点设备的共识方法、节点设备及分布式网络 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2022141700A1 true WO2022141700A1 (zh) | 2022-07-07 |
Family
ID=75999805
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/073329 WO2022141700A1 (zh) | 2020-12-30 | 2021-01-22 | 分布式节点设备的共识方法、节点设备及分布式网络 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN112865959B (zh) |
| WO (1) | WO2022141700A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115002143A (zh) * | 2022-08-01 | 2022-09-02 | 北京奥星贝斯科技有限公司 | 一种节点选举的方法、装置、存储介质及电子设备 |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113923093B (zh) * | 2021-10-29 | 2024-02-06 | 博雅正链(北京)科技有限公司 | 一种基于可信执行环境的新型拜占庭容错共识方法 |
| CN115134145B (zh) * | 2022-06-28 | 2023-10-20 | 蚂蚁区块链科技(上海)有限公司 | 区块链系统中的共识方法、装置、计算设备和计算机可读存储介质 |
| CN115048337B (zh) * | 2022-08-15 | 2022-11-08 | 南方科技大学 | 基于tee的拜占庭容错共识方法及相关设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108111604A (zh) * | 2017-12-21 | 2018-06-01 | 广州广电运通金融电子股份有限公司 | 区块链共识方法、装置和系统、标识信息处理方法和装置 |
| EP3337126A1 (en) * | 2016-12-13 | 2018-06-20 | Nxp B.V. | Legitimacy verification of a node in a distributed network |
| CN109727029A (zh) * | 2018-12-18 | 2019-05-07 | 杭州茂财网络技术有限公司 | 一种联盟链共识方法和系统 |
| CN109995536A (zh) * | 2019-03-15 | 2019-07-09 | 广州杰赛科技股份有限公司 | 一种区块链共识方法、装置及可读存储介质 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107392040B (zh) * | 2017-04-28 | 2019-08-09 | 阿里巴巴集团控股有限公司 | 一种共识验证的方法及装置 |
| CN107220130B (zh) * | 2017-05-12 | 2021-12-07 | 北京众享比特科技有限公司 | 一种在区块链的节点处实现的信息共识方法、装置及系统 |
| US10887090B2 (en) * | 2017-09-22 | 2021-01-05 | Nec Corporation | Scalable byzantine fault-tolerant protocol with partial tee support |
| CN109064328B (zh) * | 2018-07-09 | 2022-04-15 | 夸克链科技（深圳）有限公司 | 一种区块链的共识方法 |
| RU2726157C1 (ru) * | 2018-11-07 | 2020-07-09 | Алибаба Груп Холдинг Лимитед | Восстановление зашифрованной информации транзакций в конфиденциальных транзакциях с цепочками блоков |
| CN110636113A (zh) * | 2019-08-23 | 2019-12-31 | 上海电力大学 | 区块链的拜占庭容错共识方法、系统、设备和存储介质 |
| CN114401150B (zh) * | 2019-09-05 | 2023-10-20 | 创新先进技术有限公司 | 区块链网络中加入节点的方法和区块链系统 |
| CN111191292A (zh) * | 2019-12-16 | 2020-05-22 | 平安壹钱包电子商务有限公司 | 记账方法、装置、系统及计算机可读存储介质 |
| CN111612455A (zh) * | 2020-04-21 | 2020-09-01 | 国网江苏省电力有限公司电力科学研究院 | 一种面向用电信息保护的拜占庭容错联盟链共识方法及其系统、存储介质 |
-
2020
- 2020-12-30 CN CN202011630328.3A patent/CN112865959B/zh active Active
-
2021
- 2021-01-22 WO PCT/CN2021/073329 patent/WO2022141700A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3337126A1 (en) * | 2016-12-13 | 2018-06-20 | Nxp B.V. | Legitimacy verification of a node in a distributed network |
| CN108111604A (zh) * | 2017-12-21 | 2018-06-01 | 广州广电运通金融电子股份有限公司 | 区块链共识方法、装置和系统、标识信息处理方法和装置 |
| CN109727029A (zh) * | 2018-12-18 | 2019-05-07 | 杭州茂财网络技术有限公司 | 一种联盟链共识方法和系统 |
| CN109995536A (zh) * | 2019-03-15 | 2019-07-09 | 广州杰赛科技股份有限公司 | 一种区块链共识方法、装置及可读存储介质 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115002143A (zh) * | 2022-08-01 | 2022-09-02 | 北京奥星贝斯科技有限公司 | 一种节点选举的方法、装置、存储介质及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112865959A (zh) | 2021-05-28 |
| CN112865959B (zh) | 2022-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11405372B2 (en) | Retrieving access data for blockchain networks using highly available trusted execution environments | |
| US11323271B2 (en) | Retrieving public data for blockchain networks using highly available trusted execution environments | |
| KR102392420B1 (ko) | 다중키 쌍 시그너처를 사용한 프로그램 실행 및 데이터 증명 체계 | |
| CN110914851B (zh) | 提高区块链网络与外部数据源之间的通信的完整性 | |
| CN111095256B (zh) | 在可信执行环境中安全地执行智能合约操作 | |
| US11621843B2 (en) | Trusted remote proving method, apparatus and system | |
| WO2019119929A1 (zh) | 区块链共识方法、装置和系统、标识信息处理方法和装置 | |
| WO2022199290A1 (zh) | 多方安全计算 | |
| WO2022141700A1 (zh) | 分布式节点设备的共识方法、节点设备及分布式网络 | |
| AU2019204708A1 (en) | Retrieving public data for blockchain networks using highly available trusted execution environments | |
| CN112651037B (zh) | 区块链系统的链外数据访问方法和系统 | |
| WO2023283305A1 (en) | Secure and trustworthy bridge for transferring assets across different networks with an updating pool of wardens | |
| CN114329566A (zh) | 基于门限加密的区块链上随机数的生成方法和系统 | |
| EP4315118A1 (en) | Secure multi-party computation with attestation using a trusted execution environment | |
| CN115378725A (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: 21912480 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: 21912480 Country of ref document: EP Kind code of ref document: A1 |