WO2019119929A1 - 区块链共识方法、装置和系统、标识信息处理方法和装置 - Google Patents

区块链共识方法、装置和系统、标识信息处理方法和装置 Download PDF

Info

Publication number
WO2019119929A1
WO2019119929A1 PCT/CN2018/109167 CN2018109167W WO2019119929A1 WO 2019119929 A1 WO2019119929 A1 WO 2019119929A1 CN 2018109167 W CN2018109167 W CN 2018109167W WO 2019119929 A1 WO2019119929 A1 WO 2019119929A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
behavior
information
client
result
Prior art date
Application number
PCT/CN2018/109167
Other languages
English (en)
French (fr)
Inventor
徐俊
梁添才
陈秋平
高兵
姚剑萍
Original Assignee
广州广电运通金融电子股份有限公司
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 广州广电运通金融电子股份有限公司 filed Critical 广州广电运通金融电子股份有限公司
Publication of WO2019119929A1 publication Critical patent/WO2019119929A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Definitions

  • the present application relates to the field of computer technology, and in particular, to a blockchain consensus method, apparatus, and system, and method and apparatus for identifying information.
  • each node In the working process of a distributed system, each node often needs to agree on a certain data or resolution. However, abnormal nodes (such as faulty nodes and malicious nodes) or network failures may destroy the consistency of each node.
  • abnormal nodes such as faulty nodes and malicious nodes
  • network failures may destroy the consistency of each node.
  • the key problem is to solve the consistency of the accounts of the nodes in the distributed system. The reason is that the blockchain network involves the topology of P2P (Peer to Peer). There are node or network failures, even Byzantine nodes (malicious nodes). Based on this, it is necessary to introduce a Consensus mechanism to solve the consistency problem of distributed systems.
  • the consensus is mainly based on the Byzantine fault-tolerant algorithm.
  • the distributed system needs to agree at least (3f+1) nodes.
  • the slave nodes must perform the behavior request sent by the client according to the sorting result of the master node, and thus each node needs to perform multiple rounds of voting in the execution order.
  • the state of the node is modified during each transaction. To ensure that the status of each normal node in the blockchain system is consistent, the transaction must be performed on all nodes.
  • a blockchain consensus method includes: the client sends behavior information carrying a behavior request to the primary node; the master node receives the behavior information, and sends an identifier generation request that carries the behavior request to the first trusted device; The first trusted device generates identification information based on the identifier generation request, and sends the identification information to the primary node, where the identification information includes a unique number for the behavior request; the primary node receives the location The identification information is broadcasted to each of the slave nodes; the master node performs the behavior request, obtains a first execution result, and sends the first execution result to the client; each of the slaves The node receives the identifier information, and sends an identifier verification request that carries the identifier information to the corresponding second trusted device.
  • Each of the second trusted devices receives the identifier verification request, and the received identifier information is received.
  • the unique number in the verification of legality obtain the validity verification result, and send the validity verification result to the corresponding slave node; each of the slave sections Receiving the validity verification result respectively, and when the legality verification result is a legal result, executing the behavior request, and sending the generated second execution result to the client; the client is received based on The first execution result and each of the second execution results determine a consensus result.
  • the method for applying the behavior of the bearer chain to the first trusted device sends the identifier generation request that carries the behavior request to the first trusted device.
  • the identifier generation request is used to trigger the first trusted device to generate the identifier information, where the identifier information includes a unique number for the behavior request, and receive the identifier information returned by the first trusted device according to the identifier generation request. Broadcasting the identification information to each of the slave nodes, and triggering each of the slave nodes to send an identifier verification request for triggering the second trusted device to verify the validity of the unique number to the corresponding second trusted device.
  • each of the slave nodes To perform the behavior request when receiving the legality verification result returned by the corresponding second trusted device, and sending the generated second execution result to the client; Performing the behavior request, obtaining a first execution result, and transmitting the first execution result to the client; the first execution result Each of the second execution result of determination for triggering the client consensus results.
  • the method for applying the node-corresponding server includes: receiving the identifier information sent by the master node, the identifier information includes a unique number for the behavior request, and the identifier information is the first And generating, by the primary node, an identifier generation request that is sent by the primary node to carry the behavior request, where the identifier generation request is sent by the primary node when receiving the behavior information that is sent by the client and carrying the behavior request Sending, by the first trusted device, the identifier verification request that carries the identifier information to the second trusted device, where the identifier verification request is used to trigger the second trusted device to verify the validity of the unique number; Receiving a validity verification result returned by the second trusted device, and when the legality verification result is a legal result, executing the behavior request, generating a second execution result, and sending the second execution result to The second execution result is used to trigger the client to perform the behavior request based on the second execution result and the primary node The first execution result sent after the determination determines the consensus result.
  • a method for processing identification information comprising: after receiving an identifier generation request for carrying a behavior request sent by a primary node, generating identification information for the behavior request, and transmitting the identifier information to the primary node,
  • the identifier information includes a unique number for the behavior request.
  • the legality verification is performed on the unique number in the identifier information, and the validity verification result is obtained. And sending the validity verification result to the slave node, where the verification result includes a legal result or an illegal result.
  • a blockchain consensus system includes a client, a master node, a slave node, a first trusted device, and a second trusted device; the client is configured to send behavior information carrying a behavior request to the master node; The node is configured to receive the behavior information, and send an identifier generation request that carries the behavior request to the first trusted device; the first trusted device is configured to generate identifier information based on the identifier generation request, and generate the identifier Sending information to the master node, the identifier information includes a unique number for the behavior request; the master node is configured to receive the identifier information, and broadcast the identifier information to each slave node; And executing the behavior request, obtaining a first execution result, and sending the first execution result to the client; each of the slave nodes is configured to receive the identifier information, to each corresponding second trusted device Sending an identifier verification request carrying the identifier information; each of the second trusted devices is configured to receive the identifier verification request, and perform a unique number in the received identifie
  • the legal verification obtains the legality verification result, and sends the legality verification result to the corresponding slave node; each of the slave nodes is configured to respectively receive the legality verification result, and the legality verification result is legal
  • the result is performed, the behavior request is executed, and the generated second execution result is sent to the client; the client is configured to determine a consensus based on the received first execution result and each of the second execution results result.
  • the blockchain consensus device includes: a behavior information receiving module, configured to receive behavior information of a carrying behavior request sent by a client; and a certificate request sending module, configured to The trusted device sends an identifier generation request that carries the behavior request, where the identifier generation request is used to trigger the first trusted device to generate identifier information, where the identifier information includes a unique number for the behavior request; the identifier information broadcast module And receiving the identifier information returned by the first trusted device according to the identifier generation request, and broadcasting the identifier information to each slave node, and triggering each of the slave nodes to send to the corresponding second trusted device respectively.
  • an identifier verification request for triggering the validity verification of the unique number by the second trusted device, and triggering each of the slave nodes to receive a legal result of the legality verification result returned by the corresponding second trusted device, Executing the behavior request, and sending the generated second execution result to the client; the first execution result sending module, Performing the behavior request, obtaining a first execution result, and sending the first execution result to the client; the first execution result and each of the second execution results are used to trigger the client to determine a consensus result.
  • the block chain consensus device includes: an identifier information sending module, configured to receive the identifier information sent by the master node, where the identifier information includes a unique number for the behavior request, and The identifier information is generated by the first trusted device based on the identifier generation request that is sent by the primary node to carry the behavior request, where the identifier generation request is sent by the primary node to receive the behavior sent by the client.
  • an identifier information sending module configured to receive the identifier information sent by the master node, where the identifier information includes a unique number for the behavior request
  • the identifier information is generated by the first trusted device based on the identifier generation request that is sent by the primary node to carry the behavior request, where the identifier generation request is sent by the primary node to receive the behavior sent by the client.
  • the verification request sending module is configured to send, to the second trusted device, an identifier verification request that carries the identifier information, where the identifier verification request is used to trigger the first
  • the second trusted device performs the legality verification on the unique number
  • the second execution result sending module is configured to receive the legality verification result returned by the second trusted device, and when the legality verification result is a legal result Executing the behavior request, generating a second execution result, and transmitting the second execution result to the client; the second execution If for triggering the client is generated based on the execution result of the second and the master node performs the behavior request and sends a first execution result of the determination of the consensus results.
  • a processing device for identifying information comprising: an identifier information generating module, configured to generate identifier information for the behavior request after receiving an identifier generation request of a carrying behavior request sent by a master node, and send the identifier information Up to the master node, the identifier information includes a unique number for the behavior request, and the identifier information verification module is configured to: after receiving the identifier verification request that is sent by the node and carrying the identifier information, The unique number in the validity verification is performed, the validity verification result is obtained, and the legality verification result is sent to the slave node, and the verification result includes a legal result or an illegal result.
  • the blockchain consensus method, apparatus, and system, and the identification information processing method and apparatus are provided by the master node, and the trusted device generates the identifier information, where the identifier information includes the behavior request currently sent by the client.
  • the unique number correspondsly, the slave device calls the trusted device corresponding thereto to perform legality verification on the unique number in the identification information. Since the unique numbers generated by the trusted device for each behavior request are different from each other, the primary node can be effectively prevented from configuring the same number for different behavior requests, so that the number of abnormal nodes in the consensus network does not exceed f.
  • the total number of nodes required to reach agreement is reduced from (3f+1) to (2f+1), which reduces network and hardware overhead and improves system stability and consensus efficiency.
  • the trusted device is integrated on each node in the consensus network, so that the master node cannot operate the sorting result arbitrarily (effectively preventing the master node from configuring the same number for different behavior requests), and this qualification can be solved in the case of ensuring the Byzantine general problem.
  • the number of nodes required In the case of a reduced consensus network, the number of nodes required.
  • 1 is an application environment diagram of a blockchain consensus method in an embodiment
  • FIG. 2 is a schematic flow chart of a blockchain consensus method in an embodiment
  • FIG. 3 is a schematic diagram of a data structure of identification information in an embodiment
  • FIG. 4 is a schematic flow chart of steps of performing authorization verification on a client in an embodiment
  • FIG. 5 is a timing diagram of a blockchain consensus method in an embodiment
  • FIG. 6 is a structural block diagram of a blockchain consensus system in an embodiment
  • FIG. 7 is a schematic flowchart of a blockchain consensus method corresponding to a master node in another embodiment
  • FIG. 8 is a structural block diagram of a blockchain consensus device corresponding to a master node in another embodiment
  • FIG. 9 is a schematic flow chart of a blockchain consensus method corresponding to a slave node in still another embodiment
  • FIG. 10 is a structural block diagram of a blockchain consensus device corresponding to a slave node in still another embodiment
  • FIG. 11 is a schematic flowchart of a method for processing identification information in an embodiment
  • FIG. 12 is a schematic flowchart of a processing apparatus for identifying information in an embodiment
  • Figure 13 is a block diagram showing the structure of a computer device in an embodiment.
  • FIG. 1 is an application environment diagram of a blockchain consensus method in an embodiment. As shown in FIG. 1, the method is applied to a distributed system 100, which may involve a user terminal 110, a server 120, a server 121, a server 123, a trusted device 130, a trusted device 131, and a trusted device 132.
  • FIG. 1 shows a case where f is 1, in which case, in order to enable the distributed system 100 to agree, the number of servers included in the distributed system 100 may be three, respectively, the server 120, the server 121, and Server 122.
  • each server (such as the server 120, the server 121, and the server 122) included in the distributed system 100 can be implemented by a separate server or a server cluster composed of a plurality of servers.
  • each server included in the distributed system 100 can be regarded as a node in the consensus network, and the consensus network can refer to a network architecture composed of nodes that need to be agreed upon. It can be understood that, in the process of performing consensus, the behavior request sent by the client is performed in a determined order on each node in the consensus network. For each node included in the consensus network, one of the nodes acts as the master node and is responsible for The behavior request sent by the client is sorted, and the remaining other nodes are used as slave nodes, and the behavior request can be performed according to the sorting result provided by the master node.
  • the server 120 may be a server corresponding to the master node, and the server 121 and the server 122 are respectively servers corresponding to the two slave nodes.
  • a client is installed on the user terminal 110, and the client can communicate with the server 120, the server 121, and the server 123 through the network, respectively, to assist the distributed system 100 to reach an agreement.
  • the user terminal 110 may be a desktop terminal or a mobile terminal, and the mobile terminal may specifically be at least one of a mobile phone, a tablet computer, a notebook computer, and a wearable device.
  • the trusted device in the distributed system 100 can be used in conjunction with the server, that is, the trusted device has a one-to-one correspondence with the server.
  • the trusted device 130 is used in conjunction with the server 120
  • the trusted device 131 is used in conjunction with the server 121
  • the trusted device 132 is used in conjunction with the server 122 .
  • Each of the trusted devices (such as the trusted device 130, the trusted device 131, and the trusted device 132) included in the distributed system 100 has the functions of generating identification information and verifying the validity of the identification information, and the identification information includes The unique number of the behavior request sent by the client, and the unique numbers generated by the trusted device for different behavior requests are different from each other.
  • the blockchain system generally involves a P2P network.
  • network faults or abnormal nodes may occur at any time. These factors may cause the distributed system to fail smoothly.
  • the blockchain consensus method provided by the embodiments of the present application can be applied to a license chain in a blockchain to solve the problem of consistency of books on nodes in a distributed asynchronous system.
  • each node participating in the license chain system is licensed, and the alliance chain is a common license chain.
  • the nodes in the license chain are in a secure environment, and the client can help solve the consistency problem of the distributed system.
  • the slave node performs the behavior request sent by the client according to the sorting result of the master node, and sends the execution result to the client, and then the client determines the consensus result based on the received execution result.
  • the slave node relies on the sort result provided by the master node. If the master node does evil, it will have a negative impact on the consensus process, and even lead to a failure to reach a consensus.
  • the master node invokes the trusted device corresponding thereto to generate the identifier information, where the identifier information includes a unique number for the behavior request currently sent by the client, and correspondingly,
  • the slave device calls the trusted device corresponding to the legality verification of the unique number in the identification information. Since the unique numbers generated by the trusted device for each behavior request are different from each other, the primary node can be effectively prevented from configuring the same number for different behavior requests, that is, the primary node cannot operate the sorting result arbitrarily, thereby reducing the space for the master node to do evil. .
  • a blockchain consensus method is provided. This embodiment is mainly described by using the method in the above-described distributed system 100 in FIG. 1 as an example.
  • the blockchain consensus method may specifically include the following steps:
  • the client sends, to the primary node, behavior information that carries the behavior request.
  • the client refers to an application installed on the user terminal.
  • a user may send behavior information to a server in a distributed system through a client, and the behavior information may carry an action request.
  • An action request may refer to an instruction for triggering a recipient to complete a predetermined task.
  • the behavior request may be a transaction request, for example, requesting completion of the task of transferring RMB 100 from account A to account B. It can be understood that, in other application scenarios, the behavior request may also be a storage request or a calculation request, etc., which is not specifically limited in this application.
  • the master node receives the behavior information, and sends an identifier generation request that carries the behavior request to the first trusted device.
  • the method may further include the following steps: when the predetermined election trigger condition is met, one node is elected as a master node from each node included in the consensus network, and correspondingly, the remaining nodes are Both act as slave nodes.
  • the master node may be determined based on the current view number, and each node in the consensus network usually has an identity number. In this case, the current view number is divided by the total number of nodes to obtain a remainder, and the identity number is equal to the remainder.
  • the node is determined to be the master node, and the total number of nodes is the total number of nodes of the consensus network.
  • a slave node can also be called a replica node.
  • the master node may directly invoke the first trusted device, that is, directly send the identifier generation request that carries the behavior request to the first trusted device.
  • the first trusted device refers to a trusted device corresponding to the master node, for example, a trusted device connected to a server corresponding to the master node by a USB (Universal Serial Bus) connection.
  • the identifier generation request may be used to trigger the first trusted device to generate identification information carrying a unique number for the behavior request, and send the identification information to the primary node.
  • the first trusted device generates identifier information according to the identifier generation request, and sends the identifier information to the master node, where the identifier information includes a unique number for the behavior request.
  • the behavior request sent by the client is performed in a determined order on each node in the consensus network (ie, the master node and each slave node), and the master node is responsible for implementing the client sending.
  • the ordering of the behavior request, the slave node can perform the behavior request according to the sorting result provided by the master node.
  • the unique number of the behavior request can refer to the unique execution sequence number corresponding to the behavior request.
  • the primary node may invoke the corresponding first trusted device to generate the behavior request corresponding identifier information, where the identifier information may include a unique number for the behavior request.
  • the primary node invokes the first trusted device to sort the behavior requests sent by the client, and the unique numbers generated by the first trusted device for each behavior request sent by the client are different from each other, that is, different. Behavior requests correspond to different unique numbers.
  • the step of the first trusted device generating the identification information for the behavior request may include the following steps: the first trusted device acquires the current first number; the first trusted device is based on the current first number and the first The predetermined adjustment value obtains the first updated number, and the first updated number is a unique number for the behavior request; the identification information for the behavior request is generated based on the unique number.
  • the first trusted device may include a counter, and the count value of the counter is sequentially incremented. Specifically, each time the primary node invokes its corresponding first trusted device, the counter of the first trusted device increases by one. Based on this, after receiving the identifier generation request sent by the master node, the first trusted device reads the current count value of the counter, and then increases the current count value by one to obtain the updated count value, and the updated count value is A unique number identifying the behavior request in the generation request, and then generating identification information for the behavior request based on the unique number. In addition, each time the first trusted device generates a unique number, it is encrypted with the first key stored locally to avoid tampering with other applications during transmission.
  • the master node receives the identifier information, and broadcasts the identifier information to each slave node.
  • the master node performs the behavior request, obtains a first execution result, and sends the first execution result to the client.
  • the consistency of the distributed system is solved by the client. Therefore, the master node performs the behavior request sent by the client, and after obtaining the first execution result, sends the first execution result to the client.
  • the first execution result may be used to trigger the client to determine the consensus result based on the first execution result and the second execution result sent by each slave node respectively after performing the behavior request.
  • the first execution result may include current balance information of the account A and the account B, that is, balance information for characterizing that the current balance of the account A is RMB400, and the current balance of the account B is RMB300.
  • the balance information may be a hashed binary array.
  • the slave node receives the identifier information, and sends an identifier verification request that carries the identifier information to the corresponding second trusted device.
  • each of the slave nodes corresponds to a second trusted device, for example, each of the slave nodes corresponds to a second trusted device through a USB interface.
  • the identifier verification request carrying the identifier information is sent to the second trusted device corresponding to the slave node.
  • the identifier verification request is used to trigger the second trusted device to verify the validity of the unique number in the identification information.
  • the second trusted device receives the identifier verification request, performs legality verification on the unique number in the received identifier information, obtains a validity verification result, and sends the validity verification result to the corresponding From the node.
  • the legality verification is performed on the unique number in the identifier information, and the validity verification result is obtained, and The validity verification result is sent to the slave node.
  • the legality verification result may include a legal result or an illegal result.
  • the step of authenticating the unique number in the identifier information received by the second trusted device may include the following steps: the second trusted device acquires the current second number; The letter device obtains a second updated number based on the current second number and the second predetermined adjustment value; and the second trusted device performs legality verification on the unique number in the identification information based on the second updated number.
  • the second trusted device may include a counter, and each time the secondary trusted device is invoked by the slave node, the counter value of the counter in the second trusted device is increased by 1, and therefore, the second trusted device After receiving the identity verification request sent by the slave node, reading the current counter value of the counter, increasing the current counter value by 1, obtaining the updated counter value, and determining whether the updated counter value and the unique number in the identifier verification request are The same, if the same, a legal result is generated, if not the same, an illegal result is generated.
  • the slave nodes respectively receive the validity verification result, and when the validity verification result is a legal result, execute the behavior request, and send the generated second execution result to the client.
  • the behavior request obtained based on the identifier information sent by the master node is executed, and a corresponding second execution result is generated. And sending the second execution result to the client, where the second execution result is used to trigger the client to determine the consensus result based on the second execution result and the first execution result sent by the primary node after performing the behavior request. Conversely, after receiving an illegal result, the execution of the behavior request is abandoned.
  • the client determines a consensus result based on the received first execution result and each of the second execution results.
  • the client determines the consensus result based on the first execution result sent by the received primary node and the second execution result respectively sent by each slave node.
  • the client may determine a consensus result based on the total number of identical execution results in the received first execution result and the second execution result, for example, the distributed system shown in FIG. 1, if the client receives The execution result sent by the server 120, the server 121, and the server 122 is the same, and the execution result sent by the server 120 and the server 121 is the same, and the total number of execution results in the execution result received by the client is 2.
  • the identification information may further include a key signed behavior request (Sign ⁇ behavior request ⁇ ), and execution.
  • Log and digital signature (Sign ⁇ Hash ⁇ execution log ⁇ ).
  • the action request signed by the key is obtained by the first trusted device encrypting the behavior request sent by the primary node based on the first key.
  • the execution log records related information about the operation performed by the first trusted device to generate the identifier information, for example, the current first number obtaining operation is performed, and the first update is obtained based on the current first number and the first predetermined adjustment value. Post-numbered operations, etc.
  • the digital signature is that the first trusted device first hashes the execution log, obtains the first hash information, and obtains the hash information based on the first key.
  • the execution log may be hashed, the second hash information is obtained, and the first key is matched.
  • the second key decrypts the digital signature, obtains the summary information before encryption, and compares the second hash information with the summary information before encryption. If the two are the same, the execution log has not been tampered with. Then, since the execution log records related information about the operation performed by the first trusted device to generate the identification information, it may be determined whether the first trusted device obtains the information based on the information recorded in the execution log that has been confirmed to have not been falsified.
  • the current first number has been updated (such as incrementing 1) to determine whether the unique number generated by the first trusted device is legal. If it is performed, it indicates that it is legal, and a legal result is generated.
  • the second trusted device may also decrypt the digitally signed behavior request based on the second key to obtain the behavior request before encryption, and after receiving the legal result from the node, the pre-encryption behavior request may be executed to generate the first Second, the result is executed, and the second execution result is sent to the client.
  • the identity verification request sent by each of the slave nodes to the corresponding second trusted device may carry an action request (hereinafter referred to as an original behavior request) in addition to the identifier information, and the second trusted device may be based on the second key.
  • an action request hereinafter referred to as an original behavior request
  • the second trusted device may be based on the second key. Decrypting the digitally signed behavior request in the identification information, obtaining the pre-encryption behavior request, and comparing the pre-encryption behavior request with the original behavior request to determine whether the behavior request has been tampered with.
  • the first key may be a private key in the key pair
  • the second key may be a public key in the key pair.
  • the first trusted device can distribute the public key in the key pair to the second trusted device in the system to ensure that the subsequent second trusted device can complete the decryption operation.
  • the first key may be a public key in the key pair
  • the second key may be a private key in the key pair.
  • the corresponding identifier information may be generated based on a method similar to the first trusted device. Subsequently, the second trusted device corresponding to each slave node sends the generated validity verification result and the identifier information together to the corresponding slave node, and each slave node performs its execution result and the identifier information generated by the second trusted device thereof.
  • the identifier information generated by the first trusted device corresponding to the master node is sent to the client, and the client can verify the validity of the execution result based on the identifier information generated by the second trusted device and the identifier information generated by the first trusted device. .
  • the first trusted device and the second trusted device substantially describe the trusted device, and the physical structure and the achievable functions of the two can be the same.
  • the attributes of the corresponding node are distinguished by "first" and "second”, for example, the trusted device corresponding to the primary node is named as the first trusted device, and the trusted device corresponding to the slave node is named.
  • the second trusted device For the second trusted device.
  • the trusted device when the node corresponding to the trusted device is the master node, the trusted device performs the step of the first trusted device, and the node corresponding to the trusted device When the slave is a slave, the trusted device performs the step of the second trusted device.
  • the trusted device can be a small embedded system integrated with a professional-grade encryption and decryption chip, which can support various cryptographic algorithms, such as cryptographic algorithms such as RSA-512, RSA-1024, and RSA-2048.
  • the trusted device can connect to the corresponding physical machine through the USB interface (such as the server corresponding to the master node and each slave node).
  • the corresponding driver and application library need to be installed on the physical machine, and the upper application service calls the functional interface provided by the trusted device through the application library.
  • the trusted hardware mainly provides two functional interfaces, one for generating identification information according to the behavior request (specifically, generating unique number and digital signature information, etc.), and the other for verifying the legality of the identification information.
  • the client may have a timeout monitoring function, that is, when the client sends the behavior information carrying the behavior request to the primary node, the timer is started. If the client does not receive the delivery confirmation message returned by the master node within the predetermined time period, meaning that the behavior request may be lost during the transmission, the client may resend the behavior message to the master node.
  • the client when the client does not have the function of timeout monitoring, the client may send the behavior information to the slave node in addition to the behavior information carrying the behavior request to the master node, so as to prevent the master information from being When the node is down, and the client does not have the timeout monitoring function, there may be a problem of loss of behavior request.
  • the master node invokes a trusted device corresponding thereto to generate identification information, where the identifier information includes a unique number for the behavior request currently sent by the client.
  • the slave device calls the trusted device corresponding thereto to perform legality verification on the unique number in the identification information. Since the unique numbers generated by the trusted device for each behavior request are different from each other, the primary node can be effectively prevented from configuring the same number for different behavior requests, so that the number of abnormal nodes in the consensus network does not exceed f.
  • the total number of nodes required to reach agreement is reduced from (3f+1) to (2f+1), which reduces network and hardware overhead and improves system stability and consensus efficiency.
  • step S202 the following steps may also be included:
  • the client sends an authorization request for carrying the behavior request and the identity information of the client to the target node.
  • the target node receives the authorization request, and when the authorization request meets a predetermined license authorization condition, generates authorization information for the authorization request, where the license authorization condition includes the identity information being legal identity information, And the behavior request is a valid behavior request.
  • the target node sends the authorization information to the client.
  • the behavior information further includes authorization information.
  • the step S204 may include the following steps: the master node receives the behavior information, and when the authorization information carried in the behavior information is valid authorization information, A trusted device sends an identity generation request that carries the behavior request.
  • the embodiment first verifies whether the identity of the client is legal and whether the behavior request currently sent by the client is valid, so as to improve the reliability of the consensus process.
  • the application of the alliance chain generally involves several organizations, each of which corresponds to several members, each member having a member certificate from the corresponding organization, and the member certificate is used to represent the membership. It can be understood that the behavior request sent by the client with the member certificate issued by any organization in the alliance chain is allowed to be agreed, and the behavior request sent by the client not having the member certificate is prohibited from being agreed, which can effectively Improve the security of the consensus network.
  • the identity information may be a member certificate. If the member certificate sent by the client matches any organization in the current alliance chain, the identity information of the client is determined to be legal identity information, and vice versa, if the client sends the member certificate. If it does not match any of the organizations in the current alliance chain, it is determined that the identity information of the client is illegal identity information.
  • the user can send a behavior request through the client based on actual needs, but the behavior request is not necessarily valid.
  • the behavior request is to complete the task of transferring RMB 100 from Account A to Account B.
  • the available balance of Account A is only RMB 50, obviously it is impossible to transfer RMB 100 to Account B from Account A.
  • the task, and thus the behavior request is an invalid behavior request.
  • the behavior request sent by the client may be simulated, and if the execution result is normal, the behavior request is determined to be a valid behavior request, and if the execution result is abnormal, the behavior request is determined to be an invalid behavior request.
  • any node if the node generates authorization information for an authorization request from the client, it means that the node recognizes the identity of the client corresponding to the authorization request and the behavior request currently sent by the client. .
  • the client identity and the behavior request currently sent by the client do not need to be recognized by all nodes involved in the consensus network, but only the specified partial nodes are required to be recognized.
  • a predetermined authorization verification policy is configured for the chain code when the chain code is installed, and the target verification node can determine the target node (such as some of the nodes specified above), and then the target can be targeted to the target.
  • the node sends an authorization request to obtain the authorization information returned by the target node. Further, in a specific example, when the obtained authorization information is valid authorization information, the client transmits the behavior information carrying the authorization information and the behavior request to the master node.
  • the target node determined based on the predetermined authorization verification policy includes a node corresponding to at least one of the server 120 and the server 121, that is, the client needs to obtain the server 120 and/or Or the authorization information returned by the server 121.
  • the client may send an authorization request to the server 120 and the server 121 respectively, and when subsequently receiving the authorization information returned by the server 120 and/or the server 121, the host node may send the corresponding authorization information and Behavioral information for behavioral requests.
  • each node in the consensus network can be subdivided into a verification node and a consensus node, that is, each server in the distributed system is configured with a process or a sub-server for implementing the function of the verification node, and configured.
  • a process or subserver that implements the functionality of a consensus node may perform the client identity and behavior request verification step (such as the above steps S402-S406), and the process or the sub-server for implementing the function of the consensus node may perform the present application.
  • Other steps in the blockchain consensus method provided by the embodiment other than the client identity and behavior request verification steps.
  • each server (such as the server 120, the server 121, and the server 122) included in the distributed system 100 includes two sub-servers, one for implementing verification.
  • the function of the node, and the other is used to implement the function of the consensus node.
  • each server included in the distributed system 100 includes a server, and at least two processes are deployed on the server, one process is used to implement the function of the verification node, and the other process is used to implement the consensus. The function of the node.
  • the client can encrypt the behavior request with its own private key to obtain an authorization request.
  • the verification node can decrypt the authorization request by using the public key corresponding to the private key, and if the decryption is successful, the identity of the client is legal, and further simulates the behavior request obtained by performing the decryption, thereby determining whether the behavior request is valid.
  • the behavior request if yes, generates authorization information for the authorization request and sends it to the client.
  • the master node after receiving the behavior information of the authorization information and the behavior request sent by the client, the master node determines whether the authorization information carried in the behavior information is valid authorization information, and if so, The identity generation request carrying the behavior request is sent to the first trusted device.
  • the valid authorization information may include authorization information of the target node. Taking the distributed system shown in FIG. 1 as an example, it is assumed that the target node determined based on the predetermined authorization verification policy includes at least any one of the server 120 and the server 121, and the server 120 and/or the server 121 returns. Authorization information is valid authorization information.
  • the master node may also send a violation prompt message to the client, where the violation prompt message may be used to indicate that the behavior information sent by the client does not have valid authorization information, and is used to prompt the client to re-issue the information. .
  • the blockchain consensus method may further include the following steps:
  • the client determines the same execution result as a consensus result, and the received execution result includes the first execution result and each of the foregoing As a result of the second execution, the total number of nodes is the total number of nodes of the consensus network in which the slave node is located.
  • the blockchain consensus method may further include the following steps:
  • the client generates a voting confirmation request when the total number of identical execution results in the received execution result is not equal to the total number of nodes, but exceeds the total number of the nodes, and the received execution result includes the first execution result.
  • the total number of nodes is a total number of nodes of the consensus network in which the slave node is located; the client sends the voting confirmation request to the master node and each slave node respectively; After receiving the voting confirmation request sent by the client, the master node returns a first confirmation result for the voting confirmation request to the client; each of the slave nodes receives the voting confirmation sent by the client. After the request, a second confirmation result for the voting confirmation request is respectively returned to the client; the client determines a consensus result based on the first confirmation result and each of the second confirmation results.
  • the client can generate a voting confirmation request based on all the same execution results it receives, and then send the voting confirmation request to the master node and each slave node.
  • the confirmation result received by the client includes the first confirmation result sent by the master node and the second confirmation result sent by each slave node.
  • the vote confirmation request can be used to ensure that the behavior request can still be executed in the correct order after the view switch occurs. After the view switch occurs, it is necessary to determine the sequence number (ie, unique number) that the behavior request executes in the old view, thereby ensuring that the behavior request can be executed in the same order in the new view.
  • the blockchain consensus method may further include the following steps:
  • the client broadcasts the behavior request to each of the slave nodes when the total number of identical execution results in the received execution result does not exceed half of the total number of nodes, and the received execution result includes the first execution result And each of the second execution results, the total number of nodes is a total number of nodes of the consensus network where the slave node is located; each of the slave nodes is in the cache after receiving the behavior request sent by the client Searching for an execution result corresponding to the behavior request; each of the slave nodes forwarding the behavior request to the master node when the execution result corresponding to the behavior request is not found; the master node receiving the slave node After the forwarded behavior request, returning the identification information for the behavior request to the slave node;
  • Each of the slave nodes broadcasts a replacement master node request to the non-self slave node when the identity information returned by the master node for the behavior request is not received within a predetermined duration.
  • the master node in the consensus network may be an abnormal node, causing the slave node not to receive the master node. Identification information.
  • the client can broadcast the behavior request to each slave node when the total number of identical execution results in the received execution result does not exceed half of the total number of nodes.
  • Each slave node searches the cache for the execution result corresponding to the behavior request, and each slave node forwards the behavior request to the master node when the execution result corresponding to the behavior request is not found, and starts a timer.
  • the master node After receiving the behavior request forwarded by the slave node, the master node returns the identifier information for the behavior request to the corresponding slave node.
  • the slave node For any slave node that forwards the behavior request to the master node, if the identity information returned by the master node for the behavior request is not received within the predetermined duration, the slave node determines that the master node is an abnormal node, and at this time, The slave node broadcasts a replacement master node request to other slave nodes other than itself. In addition, for any node in the consensus network, when the total number of replacement master node requests it receives exceeds half of the total number of nodes, the operation of replacing the master node is started.
  • the request to replace the primary node may be a view switching request, and the operation of replacing the primary node is to initiate a view switch to replace the primary node.
  • each slave node finds the execution result corresponding to the corresponding behavior request, indicating that the slave node has previously performed the behavior request, directly sending the second execution result corresponding to the behavior request stored in the cache to the The client does not need to forward the behavior request to the primary node.
  • the behavior request when the client broadcasts the behavior request to each slave node, the behavior request is also sent to the master node. Similarly, the master node searches the cache for the first execution result corresponding to the behavior request. When the first execution result corresponding to the behavior request is found, the first execution result corresponding to the behavior request stored in the cache is directly sent to the client. It can be understood that, when the primary node does not find the first execution result corresponding to the behavior request, skip to the step of sending the identifier generation request carrying the behavior request to the first trusted device, and continue to perform the subsequent steps. (Steps S206 to S216).
  • the blockchain consensus system, the blockchain consensus method and apparatus, and the identification information processing method and apparatus all correspond to the blockchain consensus method described above, that is, the following blockchain
  • the technical features involved in the consensus system, the blockchain consensus method and apparatus, the identification information processing method and the device are the same as those described in the corresponding technical features involved in the blockchain consensus method described above.
  • the descriptions of the blockchain consensus method are applicable to the following blockchain consensus system, blockchain consensus method and device, and identification information processing method and device. For the sake of brevity, the description is not repeated below.
  • the number of abnormal nodes in the consensus network does not exceed f (ie, the number of abnormal servers in the distributed system does not exceed f)
  • the number of slave nodes in the consensus network is at least 2f (respectively Slave 1 to slave 2f).
  • the number of the second trusted devices is also 2f (the second trusted device 1 to the second trusted device 2f respectively), and f is a natural number.
  • the primary node is the target node. Based on this, as shown in FIG. 5, the interaction between the client, the master node, each slave node, the first trusted device, and each second trusted device in the following embodiments is described in detail.
  • the client sends an authorization request for carrying the behavior request and the identity information of the client to the target node.
  • the target node receives the authorization request, and determines whether the authorization request satisfies a predetermined license authorization condition, where the license authorization condition includes the identity information being legal identity information, and the behavior request is a valid behavior request;
  • the target node generates authorization information for the authorization request when determining that the authorization request satisfies the predetermined license authorization condition;
  • the target node sends the authorization information to the client.
  • the client sends, to the primary node, behavior information that carries the behavior request and the authorization information.
  • the master node receives the behavior information, and determines whether the authorization information carried in the behavior information is valid authorization information.
  • the master node sends an identifier generation request that carries the behavior request to the first trusted device when determining that the authorization information is valid authorization information;
  • the first trusted device generates identifier information according to the identifier generation request, and sends the identifier information to the master node, where the identifier information includes a unique number for the behavior request.
  • the master node receives the identifier information, and broadcasts the identifier information to each slave node.
  • the master node performs the behavior request, and obtains a first execution result.
  • the master node sends the first execution result to the client.
  • the slave node receives the identifier information, and sends an identifier verification request that carries the identifier information to the corresponding second trusted device.
  • the second trusted device receives the identifier verification request, and performs legality verification on the unique number in the received identifier information.
  • Each of the second trusted devices returns a legal result to each of the slave nodes when verifying that the unique number in the identifier information is legal.
  • Each of the slave nodes of S515 respectively receives the validity verification result, and when the legality verification result is a legal result, the behavior request is executed;
  • each of the slave nodes sends a second execution result generated by each of the slave nodes to the client;
  • the client determines a consensus result based on the received first execution result and each of the second execution results.
  • the situation in which the client determines the consensus result based on the received first execution result and the second execution result may be classified into the following three cases (not shown), as follows:
  • the client determines the same execution result as a consensus result when the total number of identical execution results in the received execution result is equal to the total number of nodes, and the received execution result includes the first execution result and each According to the second execution result, the total number of nodes is the total number of nodes of the consensus network where the slave node is located.
  • the client generates a voting confirmation request when the total number of identical execution results in the received execution result is not equal to the total number of nodes, but exceeds half of the total number of the nodes, and the received execution result includes the first Execution result and each of the second execution results, the total number of nodes is a total number of nodes of the consensus network where the slave node is located; the client sends the voting confirmation request to the master node and each slave node respectively; After receiving the voting confirmation request sent by the client, the master node returns a first confirmation result for the voting confirmation request to the client; each of the slave nodes receives the sending of the client After the voting confirmation request, the second confirmation result for the voting confirmation request is respectively returned to the client; the client determines the consensus result based on the first confirmation result and each of the second confirmation results.
  • the client requests the behavior request to broadcast each of the slave nodes when the total number of identical execution results in the received execution result does not exceed half of the total number of nodes, and the received execution result includes the first Execution result and each of the second execution results, the total number of nodes is a total number of nodes of the consensus network where the slave node is located; after receiving the behavior request sent by the client, each of the slave nodes is Querying, in the cache, an execution result corresponding to the behavior request; each of the slave nodes forwarding the behavior request to the master node when the execution result corresponding to the behavior request is not found; the master node receiving the After the action request forwarded by the node, the identifier information for the behavior request is returned to the slave node; each of the slave nodes does not receive the identifier information for the behavior request returned by the master node within a predetermined duration
  • the broadcast master node request is broadcast to the non-self slave node.
  • the blockchain consensus system 600 includes a client 602, a master node 604, and a A trusted device 606, a slave node 608, and a second trusted device 610.
  • the purpose of the components is as follows: the client 602 is used by the client to send behavior information carrying the behavior request to the master node 604; the master node 604 is configured to receive the behavior information by the master node, to the first The trusted device 606 sends an identifier generation request that carries the behavior request; the first trusted device 606 is configured to generate identifier information based on the identifier generation request, and send the identifier information to the master node 604.
  • the identification information includes a unique number for the behavior request; the primary node 604 is configured to receive the identification information, and broadcast the identification information to each of the slave nodes 608; the master node 604 is configured to execute the behavior request Obtaining a first execution result, and sending the first execution result to the client 602.
  • Each of the slave nodes 608 is configured to receive the identifier information, and send the bearer to the corresponding second trusted device 610.
  • An identifier verification request for the identifier information; each of the second trusted devices 610 is configured to receive the identifier verification request, and perform legal processing on the unique number in the received identifier information.
  • each of the slave nodes 608 is configured to respectively receive the legality verification result, and the validity verification result is legal
  • the client 602 is configured to receive the first execution result and each of the second execution results based on the received Determine consensus results.
  • the master node 604 invokes a trusted device corresponding thereto to generate identification information, which includes a unique number for the behavior request currently sent by the client 602.
  • the trusted device corresponding to the node 608 is called to verify the validity of the unique number in the identification information. Since the unique numbers generated by the trusted device for each behavior request are different from each other, the primary node 604 can be effectively prevented from configuring the same number for different behavior requests, so that the number of abnormal nodes in the consensus network can be no more than f.
  • the network and hardware overhead is reduced, and the stability and consensus efficiency of the system are improved.
  • a target node is specified in the primary node 604 and each of the secondary nodes 608.
  • the client 602 and the target node may have the following purpose: the client 602 is configured to send, by the client, an authorization request for carrying the behavior request and the identity information of the client to the target node; Receiving the authorization request, and when the authorization request satisfies a predetermined license authorization condition, generating authorization information for the authorization request, the license authorization condition includes the identity information being legal identity information, and the behavior Requesting is a valid behavior request; the target node is configured to send the authorization information to the client 602; the behavior information further includes authorization information, and based on this, the master node 604 receives the behavior information, When the authorization information carried in the behavior information is the valid authorization information, the first trusted device 606 sends an identifier generation request that carries the behavior request.
  • the client 602 determines the same execution result as a consensus result when the total number of identical execution results in the received execution result is equal to the total number of nodes, and the received execution result includes the first An execution result and each of the second execution results, the total number of nodes being the total number of nodes of the consensus network in which the slave node 608 is located.
  • the client 602, the master node 604, and each of the slave nodes 608 may also have the purpose of using the total number of identical execution results of the client 602 in the received execution results. Not counting the total number of nodes, but exceeding half of the total number of nodes, generating a voting confirmation request, the received execution result including the first execution result and each of the second execution results, the total number of nodes being the slave
  • the client 602 is configured to send the vote confirmation request to the master node 604 and the slave nodes 608, respectively;
  • the master node 604 is configured to receive the client After the voting confirmation request sent by the terminal 602, the first confirmation result for the voting confirmation request is returned to the client 602;
  • each of the slave nodes 608 is configured to receive the voting confirmation request sent by the client 602 after receiving the voting confirmation request Returning, to the client 602, a second confirmation result for the voting confirmation request, respectively;
  • the client 602 is configured to determine,
  • the client 602, the master node 604, and each of the slave nodes 608 may also have the purpose of using the total number of identical execution results of the client 602 in the received execution results.
  • the number of nodes is not more than half, the behavior request is broadcasted to each of the slave nodes 608, and the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is the The total number of nodes of the consensus network from which node 608 is located;
  • Each of the slave nodes 608 is configured to search, in the cache, the execution result corresponding to the behavior request after receiving the behavior request sent by the client 602.
  • Each of the slave nodes 608 is configured to forward the behavior request to the master node 604 when the execution result corresponding to the behavior request is not found;
  • the master node 604 is configured to, after receiving the behavior request forwarded by the slave node 608, return the identifier information for the behavior request to the slave node 608;
  • Each of the slave nodes 608 is configured to broadcast a request to replace the master node 604 to the non-slave node 608 when the identity information for the behavior request returned by the master node 604 is not received within a predetermined duration.
  • a blockchain consensus method is also provided. As shown in FIG. 7, the present embodiment is mainly described by using the method as a server corresponding to the primary node, such as the server 120 in FIG. 1 above.
  • the blockchain consensus method may specifically include the following steps:
  • S706 Receive the identifier information returned by the first trusted device according to the identifier generation request, broadcast the identifier information to each slave node, and trigger each of the slave nodes to send to the corresponding second trusted device respectively. And triggering, by the second trusted device, an identifier verification request for authenticating the unique number, and triggering each of the slave nodes to perform a legality result when the corresponding second trusted device returns a legal result, and executing The behavior request, and sending the generated second execution result to the client;
  • step S702 the following steps may also be included:
  • the license authorization condition includes the identity information being legal identity information, and the behavior request is a valid behavior request; the behavior information further includes authorization information; based on this, the step S704 may include The following steps:
  • the identifier generation request that carries the behavior request is sent to the first trusted device.
  • the method may further include the following steps:
  • the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is the slave node. a total number of nodes of the consensus network, the first confirmation result is used to trigger the client to return based on the first confirmation result, and each of the slave nodes receives the voting confirmation request sent by the client
  • the second confirmation result determines the consensus result.
  • the method may further include the following steps:
  • the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is a total number of nodes of the consensus network in which the slave node is located.
  • the blockchain consensus device 800 can include:
  • the behavior information receiving module 802 is configured to receive behavior information of the carrying behavior request sent by the client;
  • the generating request sending module 804 is configured to send, to the first trusted device, an identifier generating request that carries the behavior request, where the identifier generating request is used to trigger the first trusted device to generate the identifier information, where the identifier information includes The unique number of the behavior request;
  • the identifier information broadcast module 806 is configured to receive the identifier information returned by the first trusted device according to the identifier generation request, broadcast the identifier information to each slave node, and trigger each of the slave nodes to correspond to a second
  • the trusted device sends an identifier verification request for triggering the second trusted device to verify the validity of the unique number, and triggers each of the slave nodes to receive the validity verification result returned by the corresponding second trusted device.
  • the behavior request is executed, and the generated second execution result is sent to the client;
  • a first behavior request execution module 808, configured to execute the behavior request, obtain a first execution result, and send the first execution result to the client; the first execution result and each of the second execution The result is used to trigger the client to determine a consensus result.
  • the blockchain consensus device 800 may further include:
  • a first authorization information sending module configured to receive an authorization request of the carrying behavior request sent by the client and the identity information of the client, and generate a request for the authorization request when the authorization request satisfies a predetermined license authorization condition
  • Authorizing the information the authorization information is sent to the client, the license authorization condition includes the identity information being legal identity information, and the behavior request is a valid behavior request; the behavior information further includes authorization information;
  • the generation request sending module 804 can be further configured to: when the authorization information carried in the behavior information is valid authorization information, send an identifier generation request that carries the behavior request to the first trusted device.
  • the blockchain consensus device 800 may further include:
  • a first confirmation result returning module configured to receive a voting confirmation request sent by the client, and return a first confirmation result for the voting confirmation request to the client, where the voting confirmation request is received by the client
  • the received execution result includes the first execution result and each of the second execution results
  • the total number of nodes is the slave node.
  • a total number of nodes of the consensus network where the first confirmation result is used to trigger the client to receive a voting confirmation request sent by the client based on the first confirmation result and each of the slave nodes
  • the second confirmation result returned determines the consensus result.
  • the blockchain consensus device 800 may further include:
  • An identifier information returning module configured to receive an action request forwarded by the slave node, and return, to the slave node, identifier information for the behavior request, where the behavior request is that the slave node receives the client
  • the sent behavior request is forwarded when the execution result corresponding to the behavior request is not found in the cache, and the behavior request is performed by the client when the total number of execution results in the received execution result does not exceed half of the total number of nodes Sending to the slave node, the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is a total number of nodes of the consensus network where the slave node is located.
  • a blockchain consensus method is also provided. As shown in FIG. 9, the present embodiment is mainly applied to the server corresponding to the node as an example, such as the server 121 or the server 122 in FIG. 1 described above.
  • the blockchain consensus method may specifically include the following steps:
  • S902 Receive identification information sent by the primary node, where the identifier information includes a unique number for the behavior request, and the identifier information is generated by the first trusted device based on the identifier generation request that is sent by the primary node and that carries the behavior request.
  • the identifier generation request is sent by the primary node to the first trusted device when receiving the behavior information that is sent by the client and carrying the behavior request;
  • S904 Send an identifier verification request that carries the identifier information to the second trusted device, where the identifier verification request is used to trigger the second trusted device to perform legality verification on the unique number.
  • step S902 the following steps may also be included:
  • said license authorization condition comprises said identity information being legal identity information, and said behavior request is a valid behavior request; said behavior information further comprising authorization information, based on which said identity generation request is
  • the master node sends the behavior information that carries the authorization information and the behavior request sent by the client, and determines that the authorization information is valid authorization information, and sends the information to the first trusted device.
  • the method may further include the following steps:
  • the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is the slave node. a total number of nodes of the consensus network, the second confirmation result being used to trigger the client to return based on the second confirmation result and the voting confirmation result sent by the client by the primary node
  • the first confirmation result determines the consensus result.
  • the method may further include the following steps:
  • the replacement primary node request is broadcast to the non-owned slave node.
  • another embodiment further provides a blockchain consensus device (applied to a server corresponding to a slave node).
  • the blockchain consensus device 1000 can include:
  • the identifier information receiving module 1002 is configured to receive the identifier information sent by the master node, where the identifier information includes a unique number for the behavior request, and the identifier information is that the first trusted device sends the behavior based on the primary node And the identifier generation request is generated by the primary node to the first trusted device when receiving the behavior information that is sent by the client and carrying the behavior request;
  • the verification request sending module 1004 is configured to send, to the second trusted device, an identifier verification request that carries the identifier information, where the identifier verification request is used to trigger the second trusted device to perform legality verification on the unique number.
  • the execution result sending module 1006 is configured to receive a validity verification result returned by the second trusted device, and when the legality verification result is a legal result, execute the behavior request, generate a second execution result, and Sending the second execution result to the client;
  • the second execution result is used to trigger the client to determine a consensus result based on the second execution result and a first execution result sent by the primary node after performing the behavior request.
  • the blockchain consensus device 1000 may further include:
  • a second authorization information sending module configured to receive an authorization request of the carrying behavior request sent by the client and the identity information of the client, and generate authorization information for the authorization request when the authorization request satisfies a predetermined permission authorization condition Sending the authorization information to the client, the license authorization condition includes the identity information being legal identity information, and the behavior request is a valid behavior request; the behavior information further includes authorization information, based on the And the identifier generation request is sent by the primary node to the first trusted device when receiving the behavior information of the carrying authorization information and the behavior request sent by the client, and determining that the authorization information is valid authorization information.
  • the device sends.
  • the blockchain consensus device 1000 may further include:
  • a second confirmation result returning module configured to receive a voting confirmation request sent by the client, and return a second confirmation result for the voting confirmation request to the client, where the voting confirmation request is that the client is receiving
  • the received execution result includes the first execution result and each of the second execution results, and the total number of nodes is the slave node.
  • a total number of nodes of the consensus network wherein the second confirmation result is used to trigger the client to return based on the second confirmation result and when the primary node receives the voting confirmation result sent by the client
  • the first confirmation result determines the consensus result.
  • the blockchain consensus device 1000 may further include:
  • a second behavior request forwarding module configured to receive a behavior request sent by the client, and search for a second execution result for the behavior request in a cache, and when the second execution result is not found, the received The behavior request is forwarded to the primary node, and when the identification information returned by the primary node carrying the unique number for the behavior request is not received within a predetermined duration, the replacement primary node request is broadcast to the non-self-slave node.
  • a method of processing identification information is also provided.
  • the present embodiment is mainly applied to the foregoing trusted devices (the trusted device 130, the trusted device 131, and the trusted device 132) in FIG. 1 as an example, and the processing of the identifier information is performed.
  • the method may specifically include the following steps:
  • S1102 After receiving the identifier generation request of the bearer behavior request sent by the master node, generate identifier information for the behavior request, and send the identifier information to the master node, where the identifier information includes The unique number of the request;
  • S1104 After receiving the identifier verification request that is sent by the node and carrying the identifier information, perform validity verification on the unique number in the identifier information, obtain a validity verification result, and send the validity verification result to the The slave node, the verification result includes a legal result or an illegal result.
  • the method for processing the identifier information after receiving the identifier generation request of the bearer behavior request sent by the master node, generates identifier information for the behavior request, and sends the identifier information to the master node, where the identifier information includes a unique number for the behavior request.
  • the identity verification request carrying the identification information sent by the node after receiving the identity verification request carrying the identification information sent by the node, the validity verification of the unique number in the identification information is performed, and the verification result is sent to the slave node, and the verification result includes a legal result or an illegal result.
  • the primary node can be effectively prevented from configuring the same number for different behavior requests, so that the number of abnormal nodes in the consensus network does not exceed f,
  • the total number of nodes required for consistency is reduced from (3f+1) to (2f+1), reducing network and hardware overhead.
  • the step of generating the identification information for the behavior request may include the following steps:
  • step of performing legality verification on the unique number in the identification information may include the following steps:
  • the identification information further includes an action request carrying the digital signature information, an execution log, and summary information carrying the digital signature information.
  • the step of generating the identification information for the behavior request further includes:
  • the step of generating the identification information for the behavior request based on the unique number may include the following steps: based on the unique number, the behavior request carrying the digital signature information, the execution log, and the carrying The digest information of the digital signature information generates identification information for the behavior request.
  • the step of performing legality verification on the unique number in the identifier information may further include:
  • the step of performing legality verification on the unique number in the identification information based on the second updated number may include: based on the second updated number, the original summary information, and the second hash
  • the information carries out legality verification on the unique number in the identification information.
  • an embodiment further provides a processing device for identifying information.
  • the processing device 1200 for identifying information may include:
  • the identifier information generating module 1202 is configured to: after receiving the identifier generation request of the bearer behavior request sent by the master node, generate identifier information for the behavior request, and send the identifier information to the master node, where the identifier The information includes a unique number for the behavior request;
  • the identifier information verification module 1204 is configured to perform legality verification on the unique number in the identifier information after receiving the identifier verification request that is sent by the node and carrying the identifier information, and obtain a legality verification result, and the The validity verification result is sent to the slave node, and the verification result includes a legal result or an illegal result.
  • the identifier information generating module 1202 may include: a first number obtaining unit, configured to acquire a current first number; and a unique number obtaining unit, configured to adjust, according to the current first number and the first predetermined adjustment The value is obtained as a first updated number, and the first updated number is used as a unique number for the behavior request; the identification information generating unit is configured to generate identification information for the behavior request based on the unique number;
  • the identifier information verification module 1204 may include: a second number obtaining unit, configured to acquire a current second number; and an updated number obtaining module, configured to obtain the first number based on the current second number and the second predetermined adjustment value The second update number is used; the legality verification module is configured to perform legality verification on the unique number in the identification information based on the second updated number.
  • the identifier information further includes an action request carrying the digital signature information, an execution log, and summary information carrying the digital signature information;
  • the identifier information generating module 1202 may further include: a first key obtaining unit, configured to acquire a locally stored first key; and an encryption request obtaining unit, configured to use the first key pair
  • the action request sent by the master node is encrypted to obtain the behavior request carrying the digital signature information
  • the execution log obtaining unit is configured to obtain an execution log
  • the first hash information obtaining unit is configured to perform hash processing on the execution log
  • the encryption digest obtaining unit configured to encrypt the first hash information based on the first key, to obtain the digest information carrying the digital signature information.
  • the identifier information generating module 1202 may further include: an identifier information generating subunit, configured to perform, according to the unique number, the behavior request carrying the digital signature information, the execution log, and the carrying the digital signature information
  • the summary information generates identification information for the behavior request.
  • the identifier information verification module 1204 may further include: a second key obtaining unit, configured to acquire a locally stored second key that matches the first key; and an original digest obtaining unit, configured to The second key decrypts the summary information carrying the digital signature information to obtain the original summary information, and the second hash information obtaining unit is configured to perform hash processing on the execution log to obtain the second hash. Greek information.
  • the identification information verification unit may include: an identification information verification subunit, configured to perform, on the basis of the second updated number, the original summary information, and the second hash information, a unique number in the identification information. Legality verification.
  • the devices in the embodiments described above may all be deployed in a computer device, one embodiment of which is shown in FIG.
  • FIG. 13 A schematic structural diagram of a computer device in which the device in this embodiment is deployed.
  • the computer device in this embodiment includes a processor, a power supply module, a communication module, and a memory connected through a system bus.
  • the memory comprises a non-volatile storage medium and an internal memory.
  • the non-volatile storage medium of the computer device stores an operating system, a database, and a computer program of a data processing device for real-time communication.
  • the processor When the computer program is executed by the processor, the processor can be configured to implement the block in the above embodiment. Chain consensus method or method of processing identification information.
  • the internal memory may also store a computer program.
  • the processor When the computer program is executed by the processor, the processor may implement the blockchain consensus method or the processing method of the identification information in the foregoing embodiment.
  • FIG. 13 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device to which the solution of the present application is applied, and a specific computer.
  • the device may include more or fewer components than shown in the figures, or some components may be combined, or have different component arrangements.
  • a computer apparatus comprising a memory and a processor, the memory storing a computer program, the computer program being executed by the processor, causing the processor to perform the present application
  • a blockchain consensus method or a method for processing identification information provided by an embodiment A blockchain consensus method or a method for processing identification information provided by an embodiment.
  • a computer readable storage medium storing a computer program, the computer program being executed by a processor, causing the processor to execute a blockchain provided by any of the embodiments of the present application Consensus method or method of handling identification information.

Abstract

本申请涉及一种区块链共识方法,客户端向主节点发送携带行为请求的行为信息;主节点接收行为信息,向第一可信设备发送携带行为请求的标识生成请求;第一可信设备生成携带针对行为请求的唯一编号的标识信息,将标识信息发送至主节点;主节点将标识信息广播给各从节点,并执行行为请求,将生成的执行结果发送至客户端;各从节点接收到标识信息后,向相应第二可信设备发送携带标识信息的标识验证请求;各第二可信设备对标识信息中的唯一编号进行合法性验证;各从节点接收到相应的第二可信设备返回的合法结果后,执行行为请求,并将生成的执行结果发送至客户端;客户端基于接收到的执行结果确定共识结果。本申请提供的方案能减少网络及硬件的开销。

Description

区块链共识方法、装置和系统、标识信息处理方法和装置 技术领域
本申请涉及计算机技术领域,特别是涉及一种区块链共识方法、装置和系统、及标识信息处理方法和装置。
背景技术
随着网络技术的发展,分布式系统逐渐成为主流的系统架构。在分布式系统中,若干个节点协作配合,共同完成预定任务,如存储任务和计算任务等。
分布式系统的工作过程中,各节点常需要就某数据或决议达成一致,然而,异常节点(如故障节点和恶意节点)或网络故障等因素均可能破坏各节点的一致性。以区块链应用为例,其关键问题就是要解决分布式系统下各节点账本的一致性,原因在于区块链网络涉及P2P(Peer to Peer,对等网络)的拓扑结构,网络中随时可能存在节点或者网络故障,甚至拜占庭节点(恶意节点)。基于此,需要引入共识(Consensus)机制解决分布式系统的一致性问题。
传统方法中,主要基于拜占庭容错算法实现共识。然而,传统拜占庭容错算法中,假设异常节点的数目不超过f,则该分布式系统达成一致需要至少(3f+1)个节点。并且,从节点均须按照主节点的排序结果执行客户端发送的行为请求,为此各节点需要就执行顺序进行多轮投票。以区块链应用为例,基于状态机复制技术,进行每笔交易的过程中均会修改节点的状态,为保证区块链系统中的各正常节点的状态一致,交易在所有节点上都必须按照相同的顺序执行,为此各节点需要就交易的执行顺序进行多轮投票(投票是指节点之间相互广播消息)。因此,传统方法存在网络及硬件开销大,并发性不高、吞吐量低和共识时间长等问题,影响系统的整体性能。
发明内容
基于此,有必要针对传统方法中网络及硬件开销大的问题,提供一种区块链共识方法和装置、标识信息处理方法和装置。
一种区块链共识方法,包括:客户端向主节点发送携带行为请求的行为信息;所述主节点接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求;所述第一可信设备基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;所述主节点接收所述标识信息,将所述标识信息广播给各从节点;所述主节点执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;各所述从节点接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求;各所述第二可信设备接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点;各所述从节点分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;所述客户端基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
以应用于主节点对应的服务器为例,一种区块链共识方法,包括:接收客户端发送的携带行为请求的行为信息;向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
以应用于从节点对应的服务器为例,一种区块链共识方法,包括:接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述标识信息为第一可信设备基于所述 主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后发送的第一执行结果确定共识结果。
一种标识信息的处理方法,包括:当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
一种区块链共识系统,包括客户端、主节点、从节点、第一可信设备和第二可信设备;所述客户端用于向主节点发送携带行为请求的行为信息;所述主节点用于接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求;所述第一可信设备用于基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;所述主节点用于接收所述标识信息,将所述标识信息广播给各从节点;所述主节点用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;各所述从节点用于接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求;各所述第二可信设备用于接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点;各所述从节点用于分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;所述客户端用于基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
以应用于主节点对应的服务器为例,一种区块链共识装置,包括:行为信息接收模块,用于接收客户端发送的携带行为请求的行为信息;证书请求发送模块,用于向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;标识信息广播模块,用于接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;第一执行结果发送模块,用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
以应用于从节点对应的服务器为例,一种区块链共识装置,包括:标识信息发送模块,用于接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述标识信息为第一可信设备基于所述主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;验证请求发送模块,用于向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;第二执行结果发送模块,用于接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后生成并发送的第一执行结果确定共识结果。
一种标识信息的处理装置,包括:标识信息生成模块,用于当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;标识信息验证模块,用于当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性 验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
以上本发明实施例所述区块链共识方法、装置和系统、标识信息处理方法和装置,主节点调用与之对应的可信设备生成标识信息,该标识信息包括针对客户端当前发送的行为请求的唯一编号。相应地,从节点调用与之对应的可信设备对标识信息中的唯一编号进行合法性验证。由于可信设备针对各个行为请求生成的唯一编号均是互不相同,因而能够有效防止主节点为不同的行为请求配置相同的编号,从而能够在共识网络的异常节点的个数不超过f个时,将达成一致所需的节点总个数从(3f+1)个减至(2f+1)个,减少了网络及硬件的开销,提升了系统的稳定性和共识效率。
并且,还可以通过对客户端的身份以及客户端提交的行为请求提前进行验证,以此排除大部分客户端作恶的可能,提高作恶的成本。此外,在共识网络中的各节点上集成可信设备,使得主节点无法随意操作排序结果(有效防止主节点为不同的行为请求配置相同的编号),这一限定条件可以在保证拜占庭将军问题解决的情况下,减少共识网络中所需节点的数量。
附图说明
图1为一个实施例中区块链共识方法的应用环境图;
图2为一个实施例中区块链共识方法的流程示意图;
图3为一个实施例中标识信息的数据结构示意图;
图4为一个实施例中对客户端进行授权验证的步骤的流程示意图;
图5为一个实施例中区块链共识方法的时序图;
图6为一个实施例中区块链共识系统的结构框图;
图7为另一个实施例中主节点对应的区块链共识方法的流程示意图;
图8为另一个实施例中主节点对应的区块链共识装置的结构框图;
图9为又一个实施例中从节点对应的区块链共识方法的流程示意图;
图10为又一个实施例中从节点对应的区块链共识装置的结构框图;
图11为一个实施例中标识信息的处理方法的流程示意图;
图12为一个实施例中标识信息的处理装置的流程示意图;
图13为一个实施例中计算机设备的结构框图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的,不是旨在于限制本申请。本文所使用的术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。
图1为一个实施例中区块链共识方法的应用环境图。如图1所示,该方法应用于分布式系统100,该分布式系统100可涉及用户终端110、服务器120、服务器121、服务器123、可信设备130、可信设备131和可信设备132。
其中,假设分布式系统100中的异常服务器(故障服务器和恶意服务器)的数目不超过f,则该分布式系统100达成一致需要的服务器的数目至少为(2f+1),f为自然数。图1示出了f为1的情况,在此情况下,为使该分布式系统100能够达成一致,该分布式系统100中包含的服务器的数目可以为三,分别为服务器120、服务器121和服务器122。此外,分布式系统100中包含的各服务器(如服务器120、服务器121以及服务器122)均可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
此外,分布式系统100包含的各服务器可视为共识网络中的节点,共识网络可以指需要达成一致的各个节点所组成的网络架构。可以理解的是,在进行共识的过程中,客户端发送的行 为请求在共识网络中的各个节点上均按照确定的顺序执行,对于共识网络中包含的各个节点,其中一个节点作为主节点,负责对客户端发送的行为请求进行排序,剩余的其它节点则作为从节点,可按照该主节点提供的排序结果执行行为请求。以图1示出的分布式系统100为例,在一次共识过程中,服务器120可以为主节点对应的服务器,服务器121以及服务器122分别为两个从节点对应的服务器。
用户终端110上安装有客户端,该客户端可分别通过网络与服务器120、服务器121和服务器123进行通信,以协助分布式系统100达成一致。用户终端110可以是台式终端或移动终端,其中,移动终端具体可以是手机、平板电脑、笔记本电脑、以及穿戴式设备等中的至少一种。
分布式系统100中的可信设备可以与服务器配套使用,即可信设备与服务器一一对应。如图1所示,可信设备130与服务器120配套使用、可信设备131与服务器121配套使用、并且可信设备132与服务器122配套使用。分布式系统100中包含的各可信设备(如可信设备130、可信设备131和可信设备132)均具备生成标识信息以及对标识信息的合法性进行验证等功能,标识信息中包括针对客户端发送的行为请求的唯一编号,并且,可信设备针对不同的行为请求生成的唯一编号均是互不相同的。
需要说明的是,在实际应用中,区块链系统一般涉及P2P网络,在工作过程中,随时可能出现网络故障或异常节点(故障节点和恶意节点),这些因素均可能导致分布式系统无法顺利达成一致。本申请各实施例提供的区块链共识方法可应用于区块链中的许可链,以解决分布式异步系统下各节点上的账本的一致性的问题。对于许可链而言,参与到许可链系统中的各个节点均是经过许可的,联盟链则是一种常见的许可链。
此外,多数情况下,许可链中的节点处于安全环境中,可由客户端协助解决分布式系统的一致性问题。具体地,从节点按照主节点的排序结果执行客户端发送的行为请求,并向客户端发送执行结果,进而由客户端基于接收到的执行结果确定共识结果。然而,在此情况下,从节点依赖主节点提供的排序结果,若主节点作恶,则会给共识过程带来负面影响,甚至导致无法顺利达成一致。
基于此,本申请各实施例提供的区块链共识方法中,主节点调用与之对应的可信设备生成标识信息,该标识信息包括针对客户端当前发送的行为请求的唯一编号,相应地,从节点调用与之对应的可信设备对标识信息中的唯一编号进行合法性验证。由于可信设备针对各个行为请求生成的唯一编号均是互不相同,能够有效地防止主节点为不同的行为请求配置相同的编号,即使得主节点无法随意操作排序结果,减少了主节点作恶的空间。
如图2所示,在一个实施例中,提供了一种区块链共识方法。本实施例主要以该方法应用于上述图1中的分布式系统100为例进行说明。该区块链共识方法具体可以包括如下步骤:
S202,客户端向主节点发送携带行为请求的行为信息。
其中,客户端是指安装于用户终端上的应用程序。在实际应用中,用户可以通过客户端向分布式系统中的服务器发送行为信息,该行为信息中可以携带行为请求。
行为请求可以指用于触发接收方完成预定任务的指令。以应用场景是区块链系统为例,行为请求可以为交易请求,例如,请求完成由账号A向账号B转账人民币100元的任务。可以理解的是,在其他应用场景中,行为请求还可以为存储请求或计算请求等,本申请不作具体限定。
S204,所述主节点接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求。
在一个实施例中,所述步骤S204之前,还可以包括如下步骤:满足预定的选举触发条件时,从共识网络包含的各节点中,选举一个节点作为主节点,相应地,剩余的其它节点则均作为从节点。具体地,可基于当前视图编号确定主节点,共识网络中各节点通常都具有一个身份编号,在此情况下,用当前视图编号除以节点总数,得到余数,将其身份编号与该余数相等的节点确定为主节点,节点总数为共识网络的节点总数目。此外,应用于区块链时,从节点也可称之为副本节点。
在本实施例中,主节点接收到客户端发送的行为信息后,可以直接调用第一可信设备,即 直接向第一可信设备发送携带该行为请求的标识生成请求。
其中,第一可信设备是指该主节点对应的可信设备,例如以USB(Universal Serial Bus,通用串行总线)连接方式与该主节点对应的服务器连接的可信设备。标识生成请求可用于触发该第一可信设备生成携带针对行为请求的唯一编号的标识信息,并将该标识信息发送至该主节点。
S206,所述第一可信设备基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号。
需要说明的是,在进行共识的过程中,客户端发送的行为请求在共识网络中的各个节点(即主节点及各从节点)上均按照确定的顺序执行,主节点负责实现客户端发送的行为请求的排序,从节点则可按照该主节点提供的排序结果执行行为请求。可以理解的是,行为请求的唯一编号可以指该行为请求对应的唯一执行序号。
在本实施例中,对于客户端发送的任一行为请求,主节点均会调用其对应的第一可信设备生成该行为请求对应标识信息,该标识信息中可包括针对该行为请求的唯一编号。可见,主节点调用第一可信设备对客户端发送的行为请求进行排序,并且,第一可信设备生成的针对客户端发送的各个行为请求的唯一编号均是互不相同的,即不同的行为请求对应不同的唯一编号。
在一个具体示例中,第一可信设备生成针对行为请求的标识信息的步骤,可以包括如下步骤:第一可信设备获取当前第一编号;第一可信设备基于当前第一编号和第一预定调整值获得第一更新后编号,第一更新后编号即为针对行为请求的唯一编号;基于唯一编号生成针对行为请求的标识信息。
以下结合一个实例补充说明,第一可信设备可包括计数器,计数器的计数值依次递增。具体地,主节点每调用一次其对应的第一可信设备,该第一可信设备中的计数器的计数值就增加1。基于此,第一可信设备接收到主节点发送的标识生成请求后,读取计数器的当前计数值,再将该当前计数值增加1,获得更新后计数值,该更新后计数值即为针对标识生成请求中的行为请求的唯一编号,再基于该唯一编号生成针对该行为请求的标识信息。此外,第一可信设备每生成一个唯一编号,则采用本地存储的第一密钥对其进行加密,以避免在传输过程中被其他应用程序篡改。
S208,所述主节点接收所述标识信息,将所述标识信息广播给各从节点。
S210,所述主节点执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端。
在本实施例中,由客户端协助解决分布式系统的一致性问题。因此,主节点执行客户端发送的行为请求,获得第一执行结果后,将该第一执行结果发送至客户端。其中,第一执行结果可用于触发客户端基于该第一执行结果、以及各从节点分别执行行为请求后发送的第二执行结果确定共识结果。以行为请求为请求完成由账号A向账号B转账人民币100元的任务为例,假设转账之前,账号A的余额为人民币500元,账号B的余额为人民币200元,则执行该行为请求后,第一执行结果可以包括账号A和账号B的当前余额信息,即用于表征账号A的当前余额为人民币400元,账号B的当前余额为人民币300元的余额信息。需要说明的是,具体实施时,余额信息可以为经哈希处理过的二进制数组。
S212,各所述从节点接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求。
在本实施例中,各个从节点均一一对应一个第二可信设备,例如各个从节点对应的服务器上均通过USB接口连接一个第二可信设备。对于任一从节点而言,在接收到标识信息后,向该从节点对应的第二可信设备发送携带该标识信息的标识验证请求。标识验证请求用于触发第二可信设备对标识信息中的唯一编号进行合法性验证。
S214,各所述第二可信设备接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点。
对于任一第二可信设备而言,接收到与之对应的从节点发送的携带标识信息的标识验证请求后,对该标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至该从节点。可以理解的是,合法性验证结果可包括合法结果或非法结果。
在一个具体示例中,第二可信设备对其接收到的所述标识信息中的唯一编号进行合法性验证的步骤,可以包括如下步骤:第二可信设备获取当前第二编号;第二可信设备基于所述当前第二编号和第二预定调整值获得第二更新后编号;第二可信设备基于所述第二更新后编号对所述标识信息中的唯一编号进行合法性验证。
以下结合一个实例补充说明,第二可信设备可包括计数器,从节点每调用一次第二可信设备,该第二可信设备中的计数器的计数值就增加1,因此,第二可信设备接收到从节点发送的标识验证请求后,读取计数器的当前计数值,再将该当前计数值增加1,获得更新后计数值,并判断该更新后计数值与标识验证请求中的唯一编号是否相同,若相同,则生成合法结果,若不相同,则生成非法结果。
S216,各所述从节点分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端。
对于任一从节点而言,接收到与之对应的第二可信设备返回的合法性验证结果为合法结果时,执行基于主节点发送的标识信息获得的行为请求,生成相应的第二执行结果,并将该第二执行结果发送至客户端,该第二执行结果用于触发客户端基于该第二执行结果、以及主节点执行行为请求后发送的第一执行结果确定共识结果。相反地,接收到非法结果后,放弃执行该行为请求。
S218,所述客户端基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
在本实施例中,客户端基于接收到的主节点发送的第一执行结果以及各从节点分别发送的第二执行结果确定共识结果。在一个具体示例中,客户端可基于接收到的第一执行结果和第二执行结果中相同的执行结果的总数目确定共识结果,例如,图1示出的分布式系统,若客户端接收到的执行结果包括服务器120、服务器121以及服务器122发送的执行结果,且服务器120和服务器121发送的执行结果是相同的,则客户端接收到的执行结果中相同执行结果的总数目为2。
需要说明的是,在其他可选的实施例中,如图3所示,标识信息中除唯一编号(Counter)外,还可以包括经密钥签名的行为请求(Sign{行为请求})、执行日志以及数字签名(Sign{Hash{执行日志}})。其中,经密钥签名的行为请求是第一可信设备基于第一密钥对主节点发送的行为请求进行加密获得。执行日志中记载了第一可信设备生成标识信息所执行的操作的相关信息,例如执行了当前第一编号的获取操作,并执行了基于当前第一编号和第一预定调整值获得第一更新后编号的操作等。数字签名是第一可信设备先对该执行日志进行哈希处理,获得第一哈希信息,再基于第一密钥对该哈希信息进行加密获得。
相应地,当第二可信设备接收到从节点发送的携带标识信息的标识验证请求后,可对执行日志进行哈希处理,获得第二哈希信息,并利用与第一密钥匹配的第二密钥对数字签名进行解密,获得加密前的摘要信息,再将第二哈希信息与加密前的摘要信息进行比对,若两者相同,说明执行日志未被篡改过。随后,由于执行日志中记载了第一可信设备生成标识信息所执行的操作的相关信息,则可以基于已经确认未被篡改过的执行日志中记载的信息判断第一可信设备是否对其获取的当前第一编号进行过更新操作(如增加1),以此来判断第一可信设备生成的唯一编号是否合法,若进行过,说明合法,则生成合法结果。第二可信设备还可以基于第二密钥对经数字签名的行为请求进行解密,获得加密前的行为请求,当从节点接收到合法结果后,则可以执行该加密前的行为请求,生成第二执行结果,并将该第二执行结果发送至客户端。
此外,各从节点向各自对应的第二可信设备发送的标识验证请求中除标识信息外,还可以携带行为请求(以下称原始行为请求),进而第二可信设备可基于第二密钥对标识信息中的经数字签名的行为请求进行解密,获得加密前的行为请求,并将该加密前的行为请求与上述原始行为请求进行比对,从而判断行为请求是否被篡改过。
需要说明的是,第一密钥可为密钥对中的私钥,相应地,第二密钥可为密钥对中的公钥。并且,在实际应用中,初期进行系统部署时,第一可信设备即可向系统中的第二可信设备分发密钥对中的公钥,以保证后续第二可信设备可以完成解密操作。在其他可选实施例中,第一密钥可为密钥对中的公钥,相应地,第二密钥可为密钥对中的私钥。
此外,各从节点对应的第二可信设备对唯一编号进行合法性验证后,可基于与第一可信设 备类似的方法,生成对应的标识信息。后续,各从节点对应的第二可信设备将其生成的合法性验证结果以及标识信息一同发送至对应的从节点,各从节点将其执行结果、其第二可信设备生成的标识信息和主节点对应的第一可信设备生成的标识信息一并发送客户端,客户端可以基于该第二可信设备生成的标识信息和该第一可信设备生成的标识信息验证执行结果的有效性。
还需要说明的是,在实际应用中,第一可信设备和第二可信设备实质上描述的均是可信设备,两者的物理结构及可实现的功能均可以是相同的。在本申请中,仅仅是以“第一”和“第二”来区分其对应的节点的属性,如主节点对应的可信设备命名为第一可信设备,从节点对应的可信设备命名为第二可信设备。但是,可以理解的是,对于任一可信设备,当该可信设备对应的节点为主节点时,该可信设备则执行上述第一可信设备的步骤,当该可信设备对应的节点为从节点时,该可信设备则执行上述第二可信设备的步骤。
此外,可信设备可以为集成有专业级加解密芯片的小型嵌入式系统,该加解密芯片可以支持各种密码算法,例如RSA-512、RSA-1024以及RSA-2048等密码算法。另外,可信设备可通过USB接口连接与之对应的物理机器(如主节点和各从节点对应的服务器)。相应地,该物理机器上需要安装相应的驱动程序及应用库,上层的应用服务通过该应用库调用可信设备提供的功能接口。可信硬件主要提供两个功能接口,一个用于根据行为请求生成标识信息(具体可生成唯一编号和数字签名信息等),另一个用于验证该标识信息的合法性。
还需要说明的是,客户端可具备超时监测的功能,即客户端向主节点发送携带行为请求的行为信息时,启动计时器。若在预定时长内,客户端未接收到主节点返回的送达确认消息,意味着行为请求可能在传输过程中丢失,则客户端可以重新向主节点发送行为消息。
在其他可选的实施例中,当客户端不具备超时监测的功能时,客户端除向主节点发送携带行为请求的行为信息外,还可以向各从节点发送该行为信息,以防止在主节点出现宕机,且客户端不具备超时监测功能的情况下,可能存在的行为请求丢失的问题。
上述区块链共识方法,主节点调用与之对应的可信设备生成标识信息,该标识信息包括针对客户端当前发送的行为请求的唯一编号。相应地,从节点调用与之对应的可信设备对标识信息中的唯一编号进行合法性验证。由于可信设备针对各个行为请求生成的唯一编号均是互不相同,因而能够有效防止主节点为不同的行为请求配置相同的编号,从而能够在共识网络的异常节点的个数不超过f个时,将达成一致所需的节点总个数从(3f+1)个减至(2f+1)个,减少了网络及硬件的开销,提升了系统的稳定性和共识效率。
为进一步对本申请的方案进行更详细的说明,下文对本申请的一些优选实施例进行具体描述或举例说明。
如图4所示,在一个实施例中,在步骤S202之前,还可以包括如下步骤:
S402,客户端向目标节点发送携带行为请求和所述客户端的身份信息的授权请求。
S404,所述目标节点接收所述授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,所述许可授权条件包括所述身份信息为合法身份信息、以及所述行为请求为有效行为请求。
S406,所述目标节点将所述授权信息发送至所述客户端。
所述行为信息还包括授权信息;基于此,所述步骤S204,可以包括如下步骤:所述主节点接收所述行为信息,在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求。
需要说明的是,在本实施例中,由客户端协助解决分布式系统的一致性问题。在此情况下,若客户端作恶,则会给共识过程带来负面影响,甚至导致无法顺利达成一致。基于此,本实施例在步骤S202之前,先验证客户端的身份是否合法以及客户端当前发送的行为请求是否有效,以提高共识过程的可靠性。
以应用于联盟链为例,联盟链一般涉及若干个组织,各个组织均对应若干个成员,各成员均具有来自于对应组织的成员证书,该成员证书用于表征成员身份。可以理解的是,允许对具有联盟链中的任一组织发放的成员证书的客户端发送的行为请求进行共识,而禁止对不具备该成员证书的客户端发送的行为请求进行共识,能够有效地提高共识网络的安全性。
基于此,身份信息可以为成员证书,若客户端发送的成员证书与当前联盟链中的任一组织相匹配,则判定该客户端的身份信息为合法身份信息,反之,若客户端发送的成员证书与当前联盟链中的任一组织均不相匹配,则判定该客户端的身份信息为非法身份信息。
此外,用户可基于实际需求通过客户端发送行为请求,但该行为请求不一定有效。例如,行为请求为请求完成由账号A向账号B转账人民币100元的任务,但转账之前,账号A的可用余额仅为人民币50元,显然无法完成由账号A向账号B转账人民币100元这一任务,因而该行为请求为无效行为请求。
基于此,可模拟执行客户端发送的行为请求,若执行结果正常,则判定该行为请求为有效行为请求,反之,若执行结果异常,则判定该行为请求为无效行为请求。
需要说明的是,对于任一节点而言,若该节点生成针对来自于客户端的授权请求的授权信息,则意味着该节点认可该授权请求对应的客户端的身份以及该客户端当前发送的行为请求。
此外,在实际应用中,多数情况下,客户端身份以及该客户端当前发送的行为请求并不需要共识网络涉及的所有节点均认可,而仅需要指定的部分节点认可。基于此,对于客户端而言,在安装链代码时会为该链代码配置预定的授权验证策略,基于该授权验证策略可以确定目标节点(如上述指定的部分节点),后续则可以向该目标节点发送授权请求,以获取该目标节点返回的授权信息。此外,在一个具体示例中,当获得的授权信息为有效授权信息时,客户端才将携带授权信息和行为请求的行为信息发送至主节点。
以图1示出的分布式系统为例,假设基于预定的授权验证策略所确定的目标节点包括服务器120和服务器121中的至少任意一台服务器对应的节点,即客户端需要获得服务器120和/或服务器121返回的授权信息。基于此,在一个具体示例中,客户端可分别向服务器120和服务器121发送授权请求,后续接收到服务器120和/或服务器121返回的授权信息时,即可向主节点发送携带相应授权信息和行为请求的行为信息。
此外,基于功能划分,可将共识网络中的各个节点均细分为验证节点和共识节点,即在分布式系统中的各服务器配置有用于实现验证节点的功能的进程或子服务器,以及配置用于实现共识节点的功能的进程或子服务器。其中,用于实现验证节点的功能的进程或子服务器可执行客户端身份及行为请求验证步骤(如上述步骤S402~S406),用于实现共识节点的功能的进程或子服务器可执行本申请各实施例提供的区块链共识方法中除客户端身份及行为请求验证步骤之外的其它步骤。
以图1示出的分布式系统100为例,在一个具体示例中,分布式系统100中包含的各服务器(如服务器120、服务器121和服务器122)均包括两台子服务器,一个用于实现验证节点的功能,另一个用于实现共识节点的功能。在另一个具体示例中,分布式系统100中包含的各服务器均包括一台服务器,该台服务器上部署有至少两个进程,一个进程用于实现验证节点的功能,另一个进程用于实现共识节点的功能。
在一个具体示例中,客户端可利用自己的私钥对行为请求进行加密,获得授权请求。相应地,验证节点可通过与该私钥对应的公钥对授权请求进行解密,解密成功,则说明该客户端的身份合法,则进一步模拟执行解密获得的行为请求,从而判断该行为请求是否为有效行为请求,若是,则生成针对该授权请求的授权信息,并发送至客户端。
还需要说明的是,在本实施例中,主节点在接收到客户端发送的携带授权信息和行为请求的行为信息后,先判断该行为信息中携带的授权信息是否为有效授权信息,若是,才向第一可信设备发送携带所述行为请求的标识生成请求。具体地,有效授权信息可包括目标节点的授权信息。以图1示出的分布式系统为例,假设基于预定的授权验证策略所确定的目标节点包括服务器120和服务器121中的至少任意一台对应的节点,则服务器120和/或服务器121返回的授权信息即为有效授权信息。
此外,可以理解的是,若判断该行为信息中携带的授权信息不为有效授权信息(即为无效授权信息),则放弃向第一可信设备发送携带所述行为请求的标识生成请求。在一个具体示例中,主节点还可以向客户端发送用于违规提示消息,该违规提示消息可用于表征该客户端发送的行为信息不具备有效授权信息,以及用于提示客户端重发行为信息。
在一个实施例中,所述区块链共识方法,还可以包括如下步骤:
所述客户端在接收到的执行结果中相同执行结果的总数目等于节点总数时,将该相同执行结果确定为共识结果,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目。
需要说明的是,当客户端接收到的执行结果中的相同执行结果的总数目等于节点总数时,则说明相应的共识网络中不存在网络故障和异常节点,因此可直接将该相同执行结果作为共识结果。以生活实例进行类比,即在一次投票过程中,所有投票者选中的投票选项都是相同的,即该投票选项全票通过,则可将该投票选项作为最终的投票结果。
在一个实施例中,所述区块链共识方法,还可以包括如下步骤:
所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时,生成投票确认请求,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目;所述客户端分别向主节点以及各从节点发送所述投票确认请求;所述主节点在接收到所述客户端发送的投票确认请求后,向所述客户端返回针对所述投票确认请求的第一确认结果;各所述从节点在接收到所述客户端发送的投票确认请求后,分别向所述客户端返回针对所述投票确认请求的第二确认结果;所述客户端基于所述第一确认结果和各所述第二确认结果确定共识结果。
可以理解的是,当客户端接收到的执行结果中的相同执行结果的总数目不等于节点总数时,则说明共识网络中存在网络故障或异常节点。但是,当客户端接收到的执行结果中的相同执行结果的总数目超过节点总数的一半时,说明共识网络中的正常节点的总数目超过了半数。在此情况下,仍有可能达成一致。
基于此,客户端可以基于其接收到的所有相同执行结果生成投票确认请求,再向主节点和各从节点发送该投票确认请求,当客户端接收到的确认结果的总数目超过节点总数的一半时,即可将先前接收到的相同执行结果作为共识结果,可以理解的是,客户端接收到的确认结果包括主节点发送的第一确认结果和各从节点发送的第二确认结果。
此外,需要说明的是,投票确认请求可用于保证行为请求在发生视图切换后依旧能够按照正确的排序执行。在发生视图切换后,需要确定行为请求在旧视图中执行的序号(即唯一编号),由此保证在新视图中,该行为请求能够按照相同的排序执行。
在一个实施例中,所述区块链共识方法,还可以包括如下步骤:
所述客户端在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时,将所述行为请求广播各所述从节点,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目;各所述从节点在接收到所述客户端发送的行为请求后,在缓存中查找该行为请求对应的执行结果;各所述从节点在未查找到该行为请求对应的执行结果时,将所述行为请求转发至所述主节点;所述主节点在接收到所述从节点转发的行为请求后,向所述从节点返回针对所述行为请求的标识信息;
各所述从节点在预定时长内未接收到所述主节点返回的针对所述行为请求的标识信息时,向非己从节点广播更换主节点请求。
需要说明的是,当客户端接收到的执行结果中相同执行结果的总数目未超过节点总数一半时,则说明共识网络中的主节点可能为异常节点,导致从节点未接收到主节点发送的标识信息。
基于此,在本实施例中,客户端可以在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时,将行为请求广播至各从节点。各从节点在缓存中查找该行为请求对应的执行结果,各从节点在未查找到该行为请求对应的执行结果时,将行为请求转发至主节点,并启动计时器。相应地,主节点在接收到从节点转发的行为请求后,向相应从节点返回针对行为请求的标识信息。对于任一向主节点转发了行为请求的从节点而言,若在预定时长内未接收到主节点返回的针对行为请求的标识信息,该从节点则认定该主节点为异常节点,此时,该从节点向除自己以外的其它从节点广播更换主节点请求。此外,对于共识网络中的任一节点而言,当其接收到的更换主节点请求的总数目超过节点总数的一半时,开始执行更换主节点的操作。
其中,更换主节点请求可以为视图切换请求,开始执行更换主节点的操作指的则是启动视图切换,以更换主节点。
可以理解的是,各从节点查找到相应行为请求对应的执行结果时,说明该从节点之前执行 过该行为请求,则直接将缓存中存储的该行为请求对应的第二执行结果发送至所述客户端,而无需将该行为请求转发至主节点。
在一个实施例中,客户端在向各从节点广播行为请求时,还将该行为请求也发送至主节点,类似地,该主节点在缓存中查找与该行为请求对应的第一执行结果,当查找到该行为请求对应的第一执行结果时,直接将缓存中存储的该行为请求对应的第一执行结果发送至所述客户端。可以理解的是,当该主节点未查找到该行为请求对应的第一执行结果时,跳转至向第一可信设备发送携带所述行为请求的标识生成请求的步骤,并继续执行后续步骤(步骤S206~S216)。
需要说明的是,以下各实施例提供的区块链共识系统、区块链共识方法与装置、标识信息处理方法与装置均与上文所述的区块链共识方法对应,即以下区块链共识系统、区块链共识方法与装置、标识信息处理方法与装置涉及的各技术特征与上文所述的区块链共识方法涉及的相应技术特征所描述的具体内容均是相同的。并且,上文对区块链共识方法的描述内容均适用于以下区块链共识系统、区块链共识方法与装置、标识信息处理方法与装置,出于简洁考虑,以下不再重复描述。
在一个实施例中,假定共识网络中的异常节点的数目不超过f(即分布式系统中的异常服务器的数目不超过f),则该共识网络中的从节点的数目至少为2f(分别为从节点1~从节点2f)。相应地,第二可信设备的数目也为2f(分别为第二可信设备1~第二可信设备2f),f为自然数。此外,还假定主节点为目标节点。基于此,如图5所示,以下对该实施例中客户端、主节点、各从节点、第一可信设备以及各第二可信设备之间的交互情况进行详细描述。
S501,客户端向目标节点发送携带行为请求和所述客户端的身份信息的授权请求;
S502,所述目标节点接收所述授权请求,判断所述授权请求是否满足预定许可授权条件,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;
S503,所述目标节点在判定所述授权请求满足所述预定许可授权条件时,生成针对所述授权请求的授权信息;
S504,所述目标节点将所述授权信息发送至所述客户端;
S505,所述客户端向主节点发送携带行为请求和授权信息的行为信息;
S506,所述主节点接收所述行为信息,判断所述行为信息中携带的授权信息是否为有效授权信息;
S507,所述主节点在判定所述授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求;
S508,所述第一可信设备基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
S509,所述主节点接收所述标识信息,将所述标识信息广播给各从节点;
S510,所述主节点执行所述行为请求,获得第一执行结果;
S511,所述主节点将所述第一执行结果发送至所述客户端;
S512,各所述从节点接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求;
S513,各所述第二可信设备接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证;
S514,各所述第二可信设备在验证所述标识信息中的唯一编号合法时,向各所述从节点返回合法结果;
S515各所述从节点分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求;
S516,各所述从节点将其各自生成的第二执行结果发送至所述客户端;
S517,所述客户端基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
其中,所述客户端基于接收到的所述第一执行结果和所述第二执行结果确定共识结果的情况可以分为以下三种情况(未图示),具体如下:
1)所述客户端在接收到的执行结果中相同执行结果的总数目等于节点总数时,将该相同执行结果确定为共识结果,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结 果,所述节点总数为所述从节点所处的共识网络的节点的总数目。
2)所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时,生成投票确认请求,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目;所述客户端分别向主节点以及各从节点发送所述投票确认请求;所述主节点在接收到所述客户端发送的投票确认请求后,向所述客户端返回针对所述投票确认请求的第一确认结果;各所述从节点在接收到所述客户端发送的投票确认请求后,分别向所述客户端返回针对所述投票确认请求的第二确认结果;所述客户端基于所述第一确认结果和各所述第二确认结果确定共识结果。
3)所述客户端在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时,将所述行为请求广播各所述从节点,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目;各所述从节点在接收到所述客户端发送的行为请求后,在缓存中查找该行为请求对应的执行结果;各所述从节点在未查找到该行为请求对应的执行结果时,将所述行为请求转发至所述主节点;所述主节点在接收到所述从节点转发的行为请求后,向所述从节点返回针对所述行为请求的标识信息;各所述从节点在预定时长内未接收到所述主节点返回的针对所述行为请求的标识信息时,向非己从节点广播更换主节点请求。
基于与上述区块链共识方法相同的思想,一个实施例中还提供一种区块链共识系统,如图6所示,所述区块链共识系统600包括客户端602、主节点604、第一可信设备606、从节点608和第二可信设备610。且这些组成部分的用途具体如下:所述客户端602用于客户端向主节点604发送携带行为请求的行为信息;所述主节点604用于所述主节点接收所述行为信息,向第一可信设备606发送携带所述行为请求的标识生成请求;所述第一可信设备606用于基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点604,所述标识信息包括针对所述行为请求的唯一编号;所述主节点604用于接收所述标识信息,将所述标识信息广播给各从节点608;所述主节点604用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端602;各所述从节点608用于接收所述标识信息,向各自对应的第二可信设备610发送携带所述标识信息的标识验证请求;各所述第二可信设备610用于接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点608;各所述从节点608用于分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端602;所述客户端602用于基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
上述区块链共识系统600,主节点604调用与之对应的可信设备生成标识信息,该标识信息包括针对客户端602当前发送的行为请求的唯一编号。相应地,从节点608调用与之对应的可信设备对标识信息中的唯一编号进行合法性验证。由于可信设备针对各个行为请求生成的唯一编号均是互不相同,因而能够有效防止主节点604为不同的行为请求配置相同的编号,从而能够在共识网络的异常节点的个数不超过f个时,将达成一致所需的节点总个数从(3f+1)个减至(2f+1)个,减少了网络及硬件的开销,提升了系统的稳定性和共识效率。
在一个实施例中,在所述主节点604和各所述从节点608中指定目标节点。基于此,所述客户端602及所述目标节点可具有如下用途:所述客户端602用于客户端向目标节点发送携带行为请求和所述客户端的身份信息的授权请求;所述目标节点用于接收所述授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;所述目标节点用于将所述授权信息发送至所述客户端602;所述行为信息还包括授权信息,基于此,所述主节点604接收所述行为信息,在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备606发送携带所述行为请求的标识生成请求。
在一个实施例中,所述客户端602在接收到的执行结果中相同执行结果的总数目等于节点总数时,将该相同执行结果确定为共识结果,所述接收到的执行结果包括所述第一执行结果和 各所述第二执行结果,所述节点总数为所述从节点608所处的共识网络的节点的总数目。
在一个实施例中,所述客户端602、所述主节点604及各所述从节点608还可具有如下用途:所述客户端602用于在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时,生成投票确认请求,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点608所处的共识网络的节点的总数目;所述客户端602用于分别向主节点604以及各从节点608发送所述投票确认请求;所述主节点604用于在接收到所述客户端602发送的投票确认请求后,向所述客户端602返回针对所述投票确认请求的第一确认结果;各所述从节点608用于在接收到所述客户端602发送的投票确认请求后,分别向所述客户端602返回针对所述投票确认请求的第二确认结果;所述客户端602用于基于所述第一确认结果和各所述第二确认结果确定共识结果。
在一个实施例中,所述客户端602、所述主节点604及各所述从节点608还可具有如下用途:所述客户端602用于在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时,将所述行为请求广播各所述从节点608,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点608所处的共识网络的节点的总数目;
各所述从节点608用于在接收到所述客户端602发送的行为请求后,在缓存中查找该行为请求对应的执行结果;
各所述从节点608用于在未查找到该行为请求对应的执行结果时,将所述行为请求转发至所述主节点604;
所述主节点604用于在接收到所述从节点608转发的行为请求后,向所述从节点608返回针对所述行为请求的标识信息;
各所述从节点608用于在预定时长内未接收到所述主节点604返回的针对所述行为请求的标识信息时,向非己从节点608广播更换主节点604请求。
基于与上述区块链共识方法相同的思想,在另一个实施例中,还提供一种区块链共识方法。如图7所示,本实施例主要以该方法应用于主节点对应的服务器为例进行说明,如上述图1中的服务器120。该区块链共识方法具体可以包括如下步骤:
S702,接收客户端发送的携带行为请求的行为信息;
S704,向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;
S706,接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
S708,执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
在一个实施例中,在所述步骤S702之前,还可以包括如下步骤:
接收所述客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;所述行为信息还包括授权信息;基于此,所述步骤S704可以包括如下步骤:
在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求。
在一个实施例中,所述方法还可以包括如下步骤:
接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第一确认结果,所述投票确认请求由所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第一 确认结果用于触发所述客户端基于所述第一确认结果、以及各所述从节点接收到所述客户端发送的投票确认请求时返回的第二确认结果确定共识结果。
在一个实施例中,所述方法还可以包括如下步骤:
接收所述从节点转发的行为请求,向所述从节点返回针对所述行为请求的标识信息,其中,所述行为请求为所述从节点在接收到所述客户端发送的行为请求、且在缓存中未查找到该行为请求对应的执行结果时转发,所述行为请求由所述客户端在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时向所述从节点发送,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目。
基于与上述区块链共识方法相同的思想,另一个实施例中还提供一种区块链共识装置(应用于主节点对应的服务器)。如图8所示,所述区块链共识装置800可以包括:
行为信息接收模块802,用于接收客户端发送的携带行为请求的行为信息;
生成请求发送模块804,用于向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;
标识信息广播模块806,用于接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
第一行为请求执行模块808,用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
在一个实施例中,所述区块链共识装置800还可以包括:
第一授权信息发送模块,用于接收所述客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;所述行为信息还包括授权信息;基于此,生成请求发送模块804还可以用于:在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求。
在一个实施例中,所述区块链共识装置800还可以包括:
第一确认结果返回模块,用于接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第一确认结果,所述投票确认请求由所述客户端在接收到的执行结果中相同执行结果的总数目超过节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第一确认结果用于触发所述客户端基于所述第一确认结果、以及各所述从节点接收到所述客户端发送的投票确认请求时返回的第二确认结果确定共识结果。
在一个实施例中,所述区块链共识装置800还可以包括:
标识信息返回模块,用于接收所述从节点转发的行为请求,向所述从节点返回针对所述行为请求的标识信息,其中,所述行为请求为所述从节点在接收到所述客户端发送的行为请求、且在缓存中未查找到该行为请求对应的执行结果时转发,所述行为请求由所述客户端在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时向所述从节点发送,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目。
基于与上述区块链共识方法相同的思想,在又一个实施例中,还提供一种区块链共识方法。如图9所示,本实施例主要以该方法应用于从节点对应的服务器为例进行说明,如上述图1中的服务器121或服务器122。该区块链共识方法具体可以包括如下步骤:
S902,接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述 标识信息为第一可信设备基于所述主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;
S904,向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;
S906,接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后发送的第一执行结果确定共识结果。
在一个实施例中,在所述步骤S902之前,还可以包括如下步骤:
接收客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;所述行为信息还包括授权信息,基于此,所述标识生成请求由所述主节点在接收到所述客户端发送的携带授权信息和所述行为请求的行为信息,且判定所述授权信息为有效授权信息时向所述第一可信设备发送。
在一个实施例中,所述方法还可以包括如下步骤:
接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第二确认结果,所述投票确认请求是所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第二确认结果用于触发所述客户端基于所述第二确认结果、以及所述主节点接收到所述客户端发送的投票确认结果时返回的第一确认结果确定共识结果。
在一个实施例中,所述方法还可以包括如下步骤:
接收所述客户端发送的行为请求,在缓存中查找针对所述行为请求的第二执行结果,当未查找到所述第二执行结果时,将接收到的行为请求转发至所述主节点,并在预定时长内未接收到所述主节点返回的携带针对所述行为请求的唯一编号的标识信息时,向非己从节点广播更换主节点请求。
基于与上述区块链共识方法相同的思想,又一个实施例中还提供一种区块链共识装置(应用于从节点对应的服务器)。如图10所示,所述区块链共识装置1000可以包括:
标识信息接收模块1002,用于接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述标识信息为第一可信设备基于所述主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;
验证请求发送模块1004,用于向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;
执行结果发送模块1006,用于接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;
所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后发送的第一执行结果确定共识结果。
在一个实施例中,所述区块链共识装置1000,还可以包括:
第二授权信息发送模块,用于接收客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;所述行为信息还包括授权信息,基于此,所述标识生成请求由所述主节点在接收到所述客户端发送的携带授权信息和所述行为请求的行为信息,且判定所述授权信息为有效授权信息时向所述第一可信设备发送。
在一个实施例中,所述区块链共识装置1000,还可以包括:
第二确认结果返回模块,用于接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第二确认结果,所述投票确认请求是所述客户端在接收到的执行结果中相同执行结果的总数目超过节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第二确认结果用于触发所述客户端基于所述第二确认结果、以及所述主节点接收到所述客户端发送的投票确认结果时返回的第一确认结果确定共识结果。
在一个实施例中,所述区块链共识装置1000,还可以包括:
第二行为请求转发模块,用于接收所述客户端发送的行为请求,在缓存中查找针对所述行为请求的第二执行结果,当未查找到所述第二执行结果时,将接收到的行为请求转发至所述主节点,并在预定时长内未接收到所述主节点返回的携带针对所述行为请求的唯一编号的标识信息时,向非己从节点广播更换主节点请求。
基于与上述区块链共识方法相同的思想,在又一个实施例中,还提供一种标识信息的处理方法。如图11所示,本实施例主要以该方法应用于上述图1中的各可信设备(可信设备130、可信设备131和可信设备132)为例进行说明,该标识信息的处理方法具体可以包括如下步骤:
S1102,当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
S1104,当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
上述标识信息的处理方法,当接收到主节点发送的携带行为请求的标识生成请求后,生成针对行为请求的标识信息,并将标识信息发送至主节点,标识信息包括针对行为请求的唯一编号。相应地,当接收到从节点发送的携带标识信息的标识验证请求后,对标识信息中的唯一编号进行合法性验证,并将验证结果发送至从节点,验证结果包括合法结果或非法结果。由于针对各个行为请求生成的唯一编号均是互不相同,因而能够有效防止主节点为不同的行为请求配置相同的编号,从而能够在共识网络的异常节点的个数不超过f个时,将达成一致所需的节点总个数从(3f+1)个减至(2f+1)个,减少了网络及硬件的开销。
在一个实施例中,所述生成针对所述行为请求的标识信息的步骤,可以包括如下步骤:
获取当前第一编号;基于所述当前第一编号和第一预定调整值获得第一更新后编号,并将所述第一更新后编号作为针对所述行为请求的唯一编号;基于所述唯一编号生成针对所述行为请求的标识信息。
另外,所述对所述标识信息中的唯一编号进行合法性验证的步骤,可以包括如下步骤:
获取当前第二编号;基于所述当前第二编号和第二预定调整值获得第二更新后编号;基于所述第二更新后编号对所述标识信息中的唯一编号进行合法性验证。
在一个实施例中,所述标识信息还包括携带数字签名信息的行为请求、执行日志以及携带所述数字签名信息的摘要信息。
基于此,所述生成针对所述行为请求的标识信息的步骤,还包括:
获取本地存储的第一密钥;基于所述第一密钥对所述主节点发送的行为请求进行加密,获得所述携带数字签名信息的行为请求;获取执行日志;对所述执行日志进行哈希处理,获得第一哈希信息;基于所述第一密钥对所述第一哈希信息进行加密,获得所述携带所述数字签名信息的摘要信息。
并且,所述基于所述唯一编号生成针对所述行为请求的标识信息的步骤,可以包括如下步骤:基于所述唯一编号、所述携带数字签名信息的行为请求、所述执行日志以及所述携带所述数字签名信息的摘要信息生成针对所述行为请求的标识信息。
另外,所述对所述标识信息中的唯一编号进行合法性验证的步骤,还可以包括:
获取本地存储的与所述第一密钥相匹配的第二密钥;基于所述第二密钥对所述携带所述数 字签名信息的摘要信息进行解密,获得原始摘要信息;对所述执行日志进行哈希处理,获得第二哈希信息。
所述基于所述第二更新后编号对所述标识信息中的唯一编号进行合法性验证的步骤,可以包括:基于所述第二更新后编号、所述原始摘要信息以及所述第二哈希信息对所述标识信息中的唯一编号进行合法性验证。
基于与上述标识信息的处理方法相同的思想,一个实施例中还提供一种标识信息的处理装置。如图12所示,所述标识信息的处理装置1200可以包括:
标识信息生成模块1202,用于当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
标识信息验证模块1204,用于当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
在一个实施例中,所述标识信息生成模块1202,可以包括:第一编号获取单元,用于获取当前第一编号;唯一编号获取单元,用于基于所述当前第一编号和第一预定调整值获得第一更新后编号,并将所述第一更新后编号作为针对所述行为请求的唯一编号;标识信息生成单元,用于基于所述唯一编号生成针对所述行为请求的标识信息;
另外,所述标识信息验证模块1204,可以包括:第二编号获取单元,用于获取当前第二编号;更新后编号获取模块,用于基于所述当前第二编号和第二预定调整值获得第二更新后编号;合法性验证模块,用于基于所述第二更新后编号对所述标识信息中的唯一编号进行合法性验证。
在一个实施例中,所述标识信息还包括携带数字签名信息的行为请求、执行日志以及携带所述数字签名信息的摘要信息;
基于此,所述标识信息生成模块1202,还可以包括:第一密钥获取单元,用于获取本地存储的第一密钥;加密请求获取单元,用于基于所述第一密钥对所述主节点发送的行为请求进行加密,获得所述携带数字签名信息的行为请求;执行日志获取单元,用于获取执行日志;第一哈希信息获取单元,用于对所述执行日志进行哈希处理,获得第一哈希信息;加密摘要获取单元,用于基于所述第一密钥对所述第一哈希信息进行加密,获得所述携带所述数字签名信息的摘要信息。
并且,所述标识信息生成模块1202,可以包括:标识信息生成子单元,用于基于所述唯一编号、所述携带数字签名信息的行为请求、所述执行日志以及所述携带所述数字签名信息的摘要信息生成针对所述行为请求的标识信息。
另外,所述标识信息验证模块1204,还可以包括:第二密钥获取单元,用于获取本地存储的与所述第一密钥相匹配的第二密钥;原始摘要获取单元,用于基于所述第二密钥对所述携带所述数字签名信息的摘要信息进行解密,获得原始摘要信息;第二哈希信息获取单元,用于对所述执行日志进行哈希处理,获得第二哈希信息。
所述标识信息验证单元,可以包括:标识信息验证子单元,用于基于所述第二更新后编号、所述原始摘要信息以及所述第二哈希信息对所述标识信息中的唯一编号进行合法性验证。
应该理解的是,虽然图2、5、7、9、10的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,这些附图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
如上所述的实施例中的装置(如区块链共识装置800、区块链共识装置1000和标识信息的处理装置1200),均可以部署于计算机设备中,图13中示出了一个实施例中部署了该实施例中的装置的计算机设备的结构示意图。如图13所示,该实施例中的计算机设备包括通过系统总线连接的处理器、供电模块、通信模块和存储器。其中,存储器包括非易失性存储介质和 内存储器。该计算机设备的非易失性存储介质存储有操作系统、数据库以及实时通信的数据处理装置的计算机程序,该计算机程序被处理器执行时,可使得处理器相应地实现上述实施例中的区块链共识方法或标识信息的处理方法。该内存储器中也可储存有计算机程序,该计算机程序被处理器执行时,可使得处理器相应地实现上述实施例中的区块链共识方法或标识信息的处理方法。
本领域技术人员可以理解的是,图13中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
据此,在一个实施例中还提供一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述计算机程序被所述处理器执行时,使得所述处理器执行本申请任一实施例提供的区块链共识方法或标识信息的处理方法。
本领域普通技术人员可以理解的是实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一非易失性计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。
据此,在一个实施例中还提供一种计算机可读存储介质,存储有计算机程序,所述计算机程序被处理器执行时,使得所述处理器执行本申请任一实施例提供的区块链共识方法或标识信息的处理方法。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本申请专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

Claims (13)

  1. 一种区块链共识方法,其特征在于,包括:
    客户端向主节点发送携带行为请求的行为信息;
    所述主节点接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求;
    所述第一可信设备基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
    所述主节点接收所述标识信息,将所述标识信息广播给各从节点;
    所述主节点执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;
    各所述从节点接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求;
    各所述第二可信设备接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点;
    各所述从节点分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
    所述客户端基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
  2. 根据权利要求1所述的方法,其特征在于:
    在所述客户端向主节点发送携带行为请求的行为信息的步骤之前,还包括:
    客户端向目标节点发送携带行为请求和所述客户端的身份信息的授权请求;
    所述目标节点接收所述授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;
    所述目标节点将所述授权信息发送至所述客户端;
    所述行为信息还包括授权信息,且所述主节点接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求的步骤,包括:
    所述主节点接收所述行为信息,在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求。
  3. 一种区块链共识方法,其特征在于,包括:
    接收客户端发送的携带行为请求的行为信息;
    向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;
    接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
    执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;
    所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
  4. 根据权利要求3所述的方法,其特征在于:
    在所述接收客户端发送的携带行为请求的行为信息的步骤之前,还包括:
    接收所述客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;
    所述行为信息还包括授权信息,且所述向第一可信设备发送携带所述行为请求的标识生成请求的步骤,包括:
    在所述行为信息中携带的授权信息为有效授权信息时,向第一可信设备发送携带所述行为请求的标识生成请求。
  5. 根据权利要求3或4所述的方法,其特征在于,所述方法还包括下述两项中的至少一项:
    接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第一确认结果,所述投票确认请求由所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第一确认结果用于触发所述客户端基于所述第一确认结果、以及各所述从节点接收到所述客户端发送的投票确认请求时返回的第二确认结果确定共识结果;
    接收所述从节点转发的行为请求,向所述从节点返回针对所述行为请求的标识信息,其中,所述行为请求为所述从节点在接收到所述客户端发送的行为请求、且在缓存中未查找到该行为请求对应的执行结果时转发,所述行为请求由所述客户端在接收到的执行结果中相同执行结果的总数目未超过节点总数一半时向所述从节点发送,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目。
  6. 一种区块链共识方法,其特征在于,包括:
    接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述标识信息为第一可信设备基于所述主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;
    向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;
    接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;
    所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后发送的第一执行结果确定共识结果。
  7. 根据权利要求6所述的方法,其特征在于:
    在所述接收主节点发送的标识信息的步骤之前,还包括:
    接收客户端发送的携带行为请求和所述客户端的身份信息的授权请求,并在所述授权请求满足预定许可授权条件时,生成针对所述授权请求的授权信息,将所述授权信息发送至所述客户端,所述许可授权条件包括所述身份信息为合法的身份信息、以及所述行为请求为有效行为请求;
    所述行为信息还包括授权信息,所述标识生成请求由所述主节点在接收到所述客户端发送的携带授权信息和所述行为请求的行为信息,且判定所述授权信息为有效授权信息时向所述第一可信设备发送。
  8. 根据权利要求6或7所述的方法,其特征在于,所述方法还包括下述两项中的至少一项:
    接收所述客户端发送的投票确认请求,向所述客户端返回针对所述投票确认请求的第二确认结果,所述投票确认请求是所述客户端在接收到的执行结果中相同执行结果的总数目不等于节点总数,但超过所述节点总数一半时生成,所述接收到的执行结果包括所述第一执行结果和各所述第二执行结果,所述节点总数为所述从节点所处的共识网络的节点的总数目,所述第二确认结果用于触发所述客户端基于所述第二确认结果、以及所述主节点接收到所述客户端发送的投票确认结果时返回的第一确认结果确定共识结果;
    接收所述客户端发送的行为请求,在缓存中查找针对所述行为请求的第二执行结果,当未查找到所述第二执行结果时,将接收到的行为请求转发至所述主节点,并在预定时长内未接收到所述主节点返回的携带针对所述行为请求的唯一编号的标识信息时,向非己从节点广播更换主节点请求。
  9. 一种标识信息的处理方法,其特征在于,包括:
    当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
    当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
  10. 一种区块链共识系统,其特征在于,包括客户端、主节点、从节点、第一可信设备和第二可信设备;
    所述客户端用于向主节点发送携带行为请求的行为信息;
    所述主节点用于接收所述行为信息,向第一可信设备发送携带所述行为请求的标识生成请求;
    所述第一可信设备用于基于所述标识生成请求生成标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
    所述主节点用于接收所述标识信息,将所述标识信息广播给各从节点;
    所述主节点用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;
    各所述从节点用于接收所述标识信息,向各自对应的第二可信设备发送携带所述标识信息的标识验证请求;
    各所述第二可信设备用于接收所述标识验证请求,对接收到的所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将该合法性验证结果发送至对应的从节点;
    各所述从节点用于分别接收所述合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
    所述客户端用于基于接收到的所述第一执行结果和各所述第二执行结果确定共识结果。
  11. 一种区块链共识装置,其特征在于,包括:
    行为信息接收模块,用于接收客户端发送的携带行为请求的行为信息;
    标识请求发送模块,用于向第一可信设备发送携带所述行为请求的标识生成请求,所述标识生成请求用于触发该第一可信设备生成标识信息,所述标识信息包括针对所述行为请求的唯一编号;
    标识信息广播模块,用于接收所述第一可信设备根据所述标识生成请求返回的标识信息,将所述标识信息广播至各从节点,触发各所述从节点分别向对应的第二可信设备发送用于触发该第二可信设备对所述唯一编号进行合法性验证的标识验证请求,并触发各所述从节点在接收到相应的第二可信设备返回的合法性验证结果为合法结果时,执行所述行为请求,并将生成的第二执行结果发送至所述客户端;
    第一执行结果发送模块,用于执行所述行为请求,获得第一执行结果,并将所述第一执行结果发送至所述客户端;
    所述第一执行结果和各所述第二执行结果用于触发所述客户端确定共识结果。
  12. 一种区块链共识装置,其特征在于,包括:
    标识信息发送模块,用于接收主节点发送的标识信息,所述标识信息包括针对行为请求的唯一编号,且所述标识信息为第一可信设备基于所述主节点发送的携带所述行为请求的标识生成请求生成,所述标识生成请求由所述主节点在接收到所述客户端发送的携带所述行为请求的行为信息时向所述第一可信设备发送;
    验证请求发送模块,用于向第二可信设备发送携带所述标识信息的标识验证请求,所述标识验证请求用于触发所述第二可信设备对所述唯一编号进行合法性验证;
    第二执行结果发送模块,用于接收所述第二可信设备返回的合法性验证结果,并在所述合法性验证结果为合法结果时,执行所述行为请求,生成第二执行结果,并将所述第二执行结果发送至所述客户端;
    所述第二执行结果用于触发所述客户端基于所述第二执行结果和所述主节点执行所述行为请求后生成并发送的第一执行结果确定共识结果。
  13. 一种标识信息的处理装置,其特征在于,包括:
    标识信息生成模块,用于当接收到主节点发送的携带行为请求的标识生成请求后,生成针对所述行为请求的标识信息,并将所述标识信息发送至所述主节点,所述标识信息包括针对所述行为请求的唯一编号;
    标识信息验证模块,用于当接收到从节点发送的携带所述标识信息的标识验证请求后,对所述标识信息中的唯一编号进行合法性验证,获得合法性验证结果,并将所述合法性验证结果发送至所述从节点,所述验证结果包括合法结果或非法结果。
PCT/CN2018/109167 2017-12-21 2018-09-30 区块链共识方法、装置和系统、标识信息处理方法和装置 WO2019119929A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711397099.3 2017-12-21
CN201711397099.3A CN108111604B (zh) 2017-12-21 2017-12-21 区块链共识方法、装置和系统、标识信息处理方法和装置

Publications (1)

Publication Number Publication Date
WO2019119929A1 true WO2019119929A1 (zh) 2019-06-27

Family

ID=62212231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/109167 WO2019119929A1 (zh) 2017-12-21 2018-09-30 区块链共识方法、装置和系统、标识信息处理方法和装置

Country Status (2)

Country Link
CN (1) CN108111604B (zh)
WO (1) WO2019119929A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111506589A (zh) * 2020-04-13 2020-08-07 西安电子科技大学 基于联盟链的区块链数据服务系统、访问方法及存储介质
CN113031626A (zh) * 2020-05-15 2021-06-25 东风柳州汽车有限公司 基于自动驾驶的安全认证方法、装置、设备及存储介质
CN113283923A (zh) * 2020-02-20 2021-08-20 北京沃东天骏信息技术有限公司 一种基于区块链的资源处理方法和装置
WO2021184879A1 (zh) * 2020-03-16 2021-09-23 支付宝(杭州)信息技术有限公司 在区块链共识处理时进行处理消息同步的方法及装置
CN114745131A (zh) * 2022-04-06 2022-07-12 广东钜联信息科技有限公司 一种区块链的pbft改进共识算法
CN115334038A (zh) * 2022-08-20 2022-11-11 信通院(江西)科技创新研究院有限公司 一种基于区块链的appid申请管理方法和系统

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108111604B (zh) * 2017-12-21 2020-08-14 广州广电运通金融电子股份有限公司 区块链共识方法、装置和系统、标识信息处理方法和装置
CN110730959A (zh) * 2018-04-21 2020-01-24 因特比有限公司 用于执行由区块链请求的动作的方法和系统
CN108768618B (zh) * 2018-06-07 2021-05-11 广东工业大学 一种基于区块链的ip软核授权方法、装置及介质
CN109033376B (zh) * 2018-07-27 2022-09-27 深圳市汇尊区块链技术有限公司 一种去中心化的应用平台
CN113379425A (zh) * 2018-08-01 2021-09-10 北京洛必达科技有限公司 一种互联网区块链大数据处理系统的处理方法
CN109218079B (zh) * 2018-08-16 2021-09-10 北京京东尚科信息技术有限公司 一种区块链网络、部署方法及存储介质
CN109474682B (zh) * 2018-11-12 2022-03-11 杭州秘猿科技有限公司 一种区块链网络传输方法、装置及电子设备
CN109872159B (zh) * 2019-01-07 2021-04-06 必可嘉(武汉)科技有限公司 一种区块链共识方法及架构
CN110061856A (zh) * 2019-03-07 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的通信方法、装置及电子设备
CN110221938A (zh) * 2019-05-06 2019-09-10 深圳壹账通智能科技有限公司 电子装置、区块链共识的方法及存储介质
CN110198233B (zh) * 2019-05-09 2021-11-19 中国人民解放军国防科技大学 基于可信执行环境和有向无环图的区块链共识方法及系统
CN111752762A (zh) * 2019-06-03 2020-10-09 高田 一种区块链大数据安全处理方法
CN110633142B (zh) * 2019-07-30 2022-04-15 魏松杰 区块链的共识方法、管理节点、电子设备以及存储介质
CN110611666B (zh) * 2019-08-30 2021-03-05 视联动力信息技术股份有限公司 一种视联网信息的处理方法及装置
CN110602096B (zh) * 2019-09-12 2021-07-13 腾讯科技(深圳)有限公司 区块链网络中的数据处理方法、装置、存储介质和设备
CN111163084B (zh) * 2019-12-27 2021-11-09 清创网御(合肥)科技有限公司 一种基于动态选举和共识机制的安全存储方法
CN113206817B (zh) * 2020-02-03 2022-07-12 中移物联网有限公司 一种设备连接确认方法和区块链网络
CN113301002B (zh) * 2020-04-24 2023-05-09 阿里巴巴集团控股有限公司 一种信息处理方法、装置、电子设备以及存储介质
CN111724258A (zh) * 2020-05-28 2020-09-29 天津大学 基于环形拓扑、依赖图及多版本控制的联盟链交易并发方案的实现方法
CN112118305B (zh) * 2020-09-11 2023-04-21 北京易安睿龙科技有限公司 一种减少区块链共识系统中无效请求的方法
CN111932426B (zh) 2020-09-15 2021-01-26 支付宝(杭州)信息技术有限公司 一种基于可信硬件的身份管理方法、装置及设备
CN112865959B (zh) * 2020-12-30 2022-05-31 杭州趣链科技有限公司 分布式节点设备的共识方法、节点设备及分布式网络
CN113076376B (zh) * 2021-03-29 2024-02-06 湖北央中巨石信息技术有限公司 基于区块链的多方异步抽样共识方法及系统及装置及介质
CN113923093B (zh) * 2021-10-29 2024-02-06 博雅正链(北京)科技有限公司 一种基于可信执行环境的新型拜占庭容错共识方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358135A1 (en) * 2015-06-05 2016-12-08 DiQi, Inc. Digital currency management method and digital currency node apparatus
CN107196900A (zh) * 2017-03-24 2017-09-22 阿里巴巴集团控股有限公司 一种共识校验的方法及装置
CN108111604A (zh) * 2017-12-21 2018-06-01 广州广电运通金融电子股份有限公司 区块链共识方法、装置和系统、标识信息处理方法和装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105701372B (zh) * 2015-12-18 2019-04-09 布比(北京)网络技术有限公司 一种区块链身份构建及验证方法
KR101637868B1 (ko) * 2016-02-22 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
CN107040585B (zh) * 2017-02-22 2020-06-19 创新先进技术有限公司 一种业务校验的方法及装置
CN111327703B (zh) * 2017-03-28 2022-05-31 创新先进技术有限公司 一种基于区块链的共识方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358135A1 (en) * 2015-06-05 2016-12-08 DiQi, Inc. Digital currency management method and digital currency node apparatus
CN107196900A (zh) * 2017-03-24 2017-09-22 阿里巴巴集团控股有限公司 一种共识校验的方法及装置
CN108111604A (zh) * 2017-12-21 2018-06-01 广州广电运通金融电子股份有限公司 区块链共识方法、装置和系统、标识信息处理方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LI, QILEI: "Core Technology of Blockchain: Byzantine Consensus Algorithm-PBFT", JIANSHU.COM, 22 August 2016 (2016-08-22), XP055620607, Retrieved from the Internet <URL:https://www.jianshu.com/p/fb5edf031afd> *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113283923A (zh) * 2020-02-20 2021-08-20 北京沃东天骏信息技术有限公司 一种基于区块链的资源处理方法和装置
WO2021184879A1 (zh) * 2020-03-16 2021-09-23 支付宝(杭州)信息技术有限公司 在区块链共识处理时进行处理消息同步的方法及装置
CN111506589A (zh) * 2020-04-13 2020-08-07 西安电子科技大学 基于联盟链的区块链数据服务系统、访问方法及存储介质
CN111506589B (zh) * 2020-04-13 2023-06-23 西安电子科技大学 基于联盟链的区块链数据服务系统、访问方法及存储介质
CN113031626A (zh) * 2020-05-15 2021-06-25 东风柳州汽车有限公司 基于自动驾驶的安全认证方法、装置、设备及存储介质
CN114745131A (zh) * 2022-04-06 2022-07-12 广东钜联信息科技有限公司 一种区块链的pbft改进共识算法
CN115334038A (zh) * 2022-08-20 2022-11-11 信通院(江西)科技创新研究院有限公司 一种基于区块链的appid申请管理方法和系统
CN115334038B (zh) * 2022-08-20 2024-03-26 信通院(江西)科技创新研究院有限公司 一种基于区块链的appid申请管理方法和系统

Also Published As

Publication number Publication date
CN108111604A (zh) 2018-06-01
CN108111604B (zh) 2020-08-14

Similar Documents

Publication Publication Date Title
WO2019119929A1 (zh) 区块链共识方法、装置和系统、标识信息处理方法和装置
CN110351133B (zh) 用于区块链系统中的主节点切换处理的方法及装置
TWI705690B (zh) 分布式網路中進行主節點變更的系統
TWI734426B (zh) 使用可信執行環境檢索區塊鏈網路的公開資料
TWI707245B (zh) 使用高可用性的可信執行環境檢索區塊鏈網路的存取資料
JP6811339B2 (ja) 高可用な高信頼実行環境を使用したブロックチェーンネットワークのためのパブリックデータの読み出し
TWI725655B (zh) 用於在可信執行環境中執行子邏輯代碼的程式執行和資料證明的方法、設備和系統
JP6547079B1 (ja) 登録・認可方法、装置及びシステム
EP3628087B1 (en) Field-programmable gate array based trusted execution environment for use in a blockchain network
US9634831B2 (en) Role-based distributed key management
US20200389310A1 (en) Method and system for byzantine fault-tolerance replicating of data
US9455992B2 (en) Trusted hardware component for distributed systems
TW202036419A (zh) 區塊鏈網路中的資料隔離
CN111797159A (zh) 数据库中的信息管理和访问控制
CN111064569B (zh) 可信计算集群的集群密钥获取方法及装置
CN111212139A (zh) 对信任节点信息进行更新的方法及装置
TW202101261A (zh) 基於儲存空間互換的改進的防重放設備
CN111786812A (zh) 节点管理方法、装置、计算机设备和存储介质
CN112865959B (zh) 分布式节点设备的共识方法、节点设备及分布式网络
CN110620776B (zh) 一种数据转移信息传输方法及其装置
CN111211876B (zh) 发送针对数据请求的应答消息的方法及装置、区块链系统
CN111162970B (zh) 在区块链系统中测试去中心化应用服务器的方法及装置
WO2024045552A1 (zh) 一种数据处理方法及相关设备
CN117785557A (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: 18891541

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: 18891541

Country of ref document: EP

Kind code of ref document: A1