WO2023040364A1 - 共识方法、装置及区块链系统 - Google Patents

共识方法、装置及区块链系统 Download PDF

Info

Publication number
WO2023040364A1
WO2023040364A1 PCT/CN2022/097230 CN2022097230W WO2023040364A1 WO 2023040364 A1 WO2023040364 A1 WO 2023040364A1 CN 2022097230 W CN2022097230 W CN 2022097230W WO 2023040364 A1 WO2023040364 A1 WO 2023040364A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
verification result
unverified
node
consensus
Prior art date
Application number
PCT/CN2022/097230
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 WO2023040364A1 publication Critical patent/WO2023040364A1/zh

Links

Images

Classifications

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

Definitions

  • the present disclosure relates to the technical field of blockchain, and in particular to a consensus method, device and blockchain system.
  • the Practical Byzantine Fault Tolerance (PBFT) algorithm can improve the correctness of the blockchain system (for example, avoid forks) when the number of malicious nodes in the system is less than one-third.
  • PBFT Practical Byzantine Fault Tolerance
  • every time a block is generated a round of consensus is usually required.
  • the consensus is that the block initiator generates the block and broadcasts it in the system, and other block verifiers verify the block to complete the consensus process.
  • the block initiator can also be called “primary node (primary)", and the rest of the block verifiers can be called “backup node (backup)”.
  • Embodiments of the present disclosure provide a consensus method, device and blockchain system for improving the consensus efficiency of block verification.
  • a consensus method comprising:
  • a transaction hash (hash) list in the block chain system so that the follower nodes in the block chain system receive the transaction hash list, and the transaction hash list includes at least one hash of an unverified transaction Hash value; searching for the at least one unverified transaction based on the transaction hash list, verifying the at least one unverified transaction to obtain a first verification result, and obtaining a first hash value based on the at least one unverified transaction, And saving the corresponding relationship between the first verification result and the first hash value;
  • the pre-preparation message includes the second verification result and the second hash value; if the found first verification result is the same as the second verification result, a preparation message is broadcast in the block chain system, and the preparation message is used for the master Nodes and follower nodes in the blockchain system perform consensus processing.
  • a consensus method is provided, which is applied to a first follower node in a blockchain system, and the blockchain system also includes a master node; the method includes:
  • the transaction hash list including at least one hash value of an unverified transaction
  • the pre-preparation message including a second verification result obtained by the master node from verifying the at least one unverified transaction and a second hash obtained based on the at least one unverified transaction value;
  • a preparation message is broadcast in the system, and the preparation message is used for consensus processing by the master node and at least one slave node in the blockchain system.
  • a consensus device includes a broadcast module and a verification module;
  • the broadcast module is used to broadcast the transaction hash list in the block chain system, so that the follower nodes in the block chain system receive the transaction hash list, and the transaction hash list includes at least one unverified A hash value of the transaction, searching for the at least one unverified transaction based on the transaction hash list, verifying the at least one unverified transaction to obtain a first verification result, and obtaining a first hash value based on the at least one unverified transaction Hash value, and save the corresponding relationship between the first verification result and the first hash value;
  • the first verification module is used to find the at least one unverified transaction based on the transaction hash list, verify the at least one unverified transaction to obtain a second verification result, and obtain a second hash based on the at least one unverified transaction value;
  • the broadcast module is also used to broadcast a pre-preparation message in the blockchain system, so that the follower node searches for the first verification result corresponding to the second hash value based on the correspondence, and the pre-preparation
  • the message includes the second verification result and the second hash value; if the found first verification result is the same as the second verification result, a preparation message is broadcast in the block chain system, and the preparation The message is used for consensus processing by the master node and the slave nodes in the blockchain system.
  • a consensus device which is applied to the first follower node in the blockchain system, and the blockchain system also includes a master node; the device includes a receiving module and a verification module and a verification result comparison module;
  • the receiving module is used to receive the transaction hash list broadcast by the master node, and the transaction hash list includes at least one hash value of an unverified transaction;
  • the second verification module is configured to search for the at least one unverified transaction based on the transaction hash list, verify the at least one unverified transaction to obtain a first verification result, and obtain a first hash based on the at least one unverified transaction Hash value, and save the corresponding relationship between the first verification result and the first hash value;
  • the receiving module is also used to receive the pre-preparation message broadcast by the master node, the pre-preparation message includes the second verification result obtained by the master node from verifying the at least one unverified transaction and based on the at least one unverified transaction The second hash value obtained by the transaction;
  • the verification result comparison module is configured to search for a first verification result corresponding to the second hash value in the pre-prepared message based on the correspondence, if the first verification result is the same as the second verification result, then in A preparation message is broadcast in the blockchain system, and the preparation message is used for consensus processing by the master node and each slave node in the blockchain system.
  • a blockchain system including a master node and a first follower node, where the first follower node is any follower node in the blockchain system;
  • the master node is used to broadcast a transaction hash list in the blockchain system, and the transaction hash list includes at least one hash value of an unverified transaction;
  • the first follower node is used to receive the transaction hash list, find the at least one unverified transaction based on the transaction hash list; verify the at least one unverified transaction to obtain a first verification result, based on the at least An unverified transaction obtains a first hash value, and saves the corresponding relationship between the first verification result and the first hash value;
  • the master node is also used to search for the at least one unverified transaction based on the transaction hash list, verify the at least one unverified transaction to obtain a second verification result; obtain a second hash based on the at least one unverified transaction value, and broadcast a pre-prepared message carrying the second verification result and the second hash value in the blockchain system;
  • the first follower node is further configured to receive the pre-preparation message, and search for a first verification result corresponding to the second hash value based on the correspondence, if the found first verification result is consistent with the second hash value If the verification results are the same, a preparation message is broadcast in the blockchain system, and the preparation message is used for consensus processing by the master node and at least one slave node in the blockchain system.
  • a computer-readable storage medium on which program codes are stored, and the program codes can be invoked and executed by a processor to implement any one of the above-mentioned embodiments of the present disclosure. consensus method.
  • the master node directly broadcasts a transaction hash list including the hash value of at least one unverified transaction in the blockchain system, so that the slave node and the master node can synchronously perform at least one unverified transaction
  • the follower node saves the first verification result obtained from the verification and the first hash value of at least one unverified transaction.
  • the master node broadcasts the obtained second verification result and the second hash value of at least one unverified transaction in the pre-preparation message, so that the follower node can find the first verification result based on the second hash value , and when the second verification result is the same as the found first verification result, broadcast a preparation message to enter the subsequent consensus stage and complete the consensus process.
  • the master node and the follower nodes can verify the unverified transactions that need to be uploaded to the chain in parallel in this round of consensus, which helps to speed up the consensus process and improve consensus efficiency.
  • FIG. 1 is a schematic diagram of the architecture of a blockchain system provided by an embodiment of the present disclosure
  • FIG. 2 is a schematic flow diagram of an embodiment of the consensus method of the present disclosure
  • FIG. 3 is a schematic flow diagram of another embodiment of the consensus method of the present disclosure.
  • FIG. 4 is a schematic flow chart of step S111 in the embodiment shown in FIG. 3;
  • FIG. 5 is a schematic flow diagram of another embodiment of the consensus method of the present disclosure.
  • FIG. 6 is a schematic diagram of the consensus process of the blockchain system provided by the embodiment of the present disclosure.
  • FIG. 7 is a sequence diagram of the consensus process of the blockchain system provided by an embodiment of the present disclosure.
  • FIG. 8 is a schematic structural diagram of an embodiment of the consensus device of the present disclosure.
  • FIG. 9 is a schematic structural diagram of an embodiment of the consensus device of the present disclosure.
  • FIG. 10 is a schematic diagram of a blockchain node framework provided by an embodiment of the present disclosure.
  • plural may refer to two or more than two, and “at least one” may refer to one, two or more than two.
  • the term "and/or" in the disclosure is only an association relationship describing associated objects, indicating that there may be three relationships, for example, A and/or B may indicate: A exists alone, A and B exist simultaneously, There are three cases of B alone.
  • the character "/" in the present disclosure generally indicates that the contextual objects are an "or" relationship.
  • Embodiments of the present disclosure may be applied to electronic devices such as terminal devices, computer systems, servers, etc., which may operate with numerous other general purpose or special purpose computing system environments or configurations.
  • Examples of well known terminal devices, computing systems, environments and/or configurations suitable for use with electronic devices such as terminal devices, computer systems, servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick client Computers, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, networked personal computers, minicomputer systems, mainframe computer systems, and distributed cloud computing technology environments including any of the foregoing, etc.
  • Electronic devices such as terminal devices, computer systems, servers, etc. may be described in the general context of computer system-executable instructions, such as program modules, being executed by the computer system.
  • program modules may include routines, programs, objects, components, logic, data structures, etc., that perform particular tasks or implement particular abstract data types.
  • the computer system/server can be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computing system storage media including storage devices.
  • FIG. 1 is a schematic diagram of the architecture of a blockchain system 10 provided by an embodiment of the present disclosure, which includes multiple blockchain nodes, such as blockchain nodes 100, blockchain nodes 101, blockchain nodes 102, and blockchain nodes.
  • Chain node 103 The number of blockchain nodes in the blockchain system 10 is 3f+1, where f represents the number of Byzantine nodes in the blockchain system 10, that is, the number of malicious or faulty nodes. In other words, there are at least 2f+1 non-Byzantine nodes in the blockchain system 10, and these nodes can perform consensus processing according to the consensus method provided by the embodiment of the present disclosure.
  • the follower nodes in the blockchain system 10 are all peer nodes, and they can communicate between each other.
  • the blockchain nodes mentioned in the embodiments of the present disclosure can be, for example, terminal devices (such as tablet computers, notebook computers, personal computers) or servers, and the servers here can be, for example, independent physical servers or A server cluster composed of multiple physical servers can also be a cloud server that provides basic cloud computing services such as cloud computing and big data. Embodiments of the present disclosure are not limited to this.
  • FIG. 2 is a schematic flowchart of a consensus method provided by an embodiment of the present disclosure, which can be applied to the blockchain system 10 shown in FIG. 1 .
  • the master node that is, the initiator of the blockchain
  • the remaining blockchain nodes serve as followers Nodes (i.e. block validators).
  • this embodiment will take blockchain node 100 as the master node, blockchain node 101, blockchain node 102 and blockchain node 103 as the example of the follower nodes, and the consensus method provided in this embodiment Introduce, specifically include the following steps.
  • the master node broadcasts a transaction hash list in the blockchain system, where the transaction hash list includes at least one hash value of an unverified transaction.
  • S120 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the broadcast module run by the processor.
  • the master node (such as the blockchain node 100 in Figure 1) can obtain the hash value of at least one transaction that needs to be packaged into the block from the local transaction pool, and form the transaction in S120 with the retrieved hash value list of hashes.
  • at least one transaction that needs to be packaged into the block refers to the transaction that needs to be uploaded to the chain in this round of consensus.
  • the master node can broadcast the transaction hash list to the blockchain In system 10, based on this, this embodiment refers to transactions that need to be packaged into blocks as "unverified transactions".
  • the transaction hash list may be carried in the unverified block (pre-block) message and broadcast.
  • the stage of broadcasting the pre-block message may be called the unverified block stage.
  • the consensus method provided by the embodiments of the present disclosure can be used in the pre-prepare phase, prepare phase and commit phase included in the Practical Byzantine Fault Tolerance (PBFT) consensus process. ) phase, add the unverified block phase.
  • PBFT Practical Byzantine Fault Tolerance
  • the unverified block message broadcast by the master node can be received by the follower nodes in the blockchain system 10 shown in FIG. 1 .
  • the master node broadcasts the transaction hash list in the blockchain system 10, which can make the slave nodes in the blockchain system 10 act as the first slave nodes to execute S140 described below.
  • the first follower node in the blockchain system receives the transaction hash list, searches for the at least one unverified transaction based on the transaction hash list, and verifies the at least one unverified transaction to obtain a first verification result, And, a first hash value is obtained based on the at least one unverified transaction, and a corresponding relationship between the first verification result and the first hash value is saved.
  • S140 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the second verification module run by the processor.
  • any follower node in the blockchain system 10 can be used as the first follower node, and when one follower node is regarded as the first follower node, the rest of the follower nodes can be regarded as the second follower node.
  • the blockchain node 101 shown in FIG. 1 is used as the first follower node
  • both the blockchain node 102 and the blockchain node 103 can be regarded as the second follower node.
  • the blockchain node 102 shown in FIG. 1 is used as the first follower node
  • both the blockchain node 101 and the blockchain node 103 can be regarded as the second follower node.
  • the first follower node After the first follower node receives the unverified block message, it can obtain a transaction hash list in the unverified block message, and any hash value in the transaction hash list corresponds to an unverified transaction.
  • the unverified transaction tx-1 corresponds to the hash value hs-1, which means that the hash calculation of tx-1 can get hs-1.
  • the first follower node can retrieve the unverified transaction corresponding to the hash value from the local transaction pool, so that the original of at least one unverified transaction that needs to be chained in this round of consensus can be obtained transaction data.
  • the first follower node can splice unverified transactions obtained into a transaction hash list, initiate verification of the transaction hash list locally, and determine the illegal transactions in the transaction hash list.
  • the illegal transactions here can be, for example, Overtime transactions, invalid transactions, etc.
  • due to performance problems of blockchain nodes there may be problems with the consistency of some transaction execution results, and these transactions can be called overtime transactions.
  • the transaction and the subsequent transactions of the source account of the transaction can be called invalid transactions.
  • the first follower node may generate verification result information of the illegal transaction, and then obtain a first verification result, the first verification result at least including the verification result information of the illegal transaction generated by the first follower node.
  • the first follower node can also perform hash calculation on at least one unverified transaction obtained this time to obtain the first hash value.
  • the first hash value may be the overall hash value of all unverified transactions retrieved by the first follower node.
  • the first follower node may locally save the corresponding relationship between the first hash value and the first verification result. For example, a key-value pair may be formed with the first hash value as the key and the first verification result as the value, and the key-value pair is saved locally.
  • the master node searches for the at least one unverified transaction based on the transaction hash list, verifies the at least one unverified transaction to obtain a second verification result; obtains a second hash value based on the at least one unverified transaction , and broadcast a pre-preparation message carrying the second verification result and the second hash value in the blockchain system.
  • S160 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the first module run by the processor.
  • S160 and S140 may be executed in parallel.
  • the master node enters the pre-preparation stage after broadcasting unverified block messages.
  • the master node in the pre-preparation stage, can retrieve the original transaction data of the corresponding unverified transaction from the local transaction pool according to any hash value in the transaction hash list, and verify the retrieved unverified transaction .
  • the specific process of verification can be similar to the verification process of the first follower node for unverified transactions.
  • the master node After the master node determines the illegal transaction from the obtained unverified transactions, it can generate the verification result information of the illegal transaction, and then obtain the second verification result, wherein the second verification result includes the illegal transaction generated by the master node. Transaction verification result information.
  • the master node can also perform hash calculations on the whole unverified transactions obtained to obtain the second hash value.
  • the master node can broadcast a pre-preparation message in the blockchain system 10, and the pre-preparation message includes the second verification result and the second hash value.
  • the pre-preparation message can be received by the follower nodes in the blockchain system 10. In other words, the master node broadcasts the pre-preparation message in the blockchain system 10, which can make any slave node in the blockchain system 10 act as the first slave node to execute S180 described below.
  • the first follower node receives the pre-preparation message, and searches for a first verification result corresponding to the second hash value in the pre-preparation message based on the correspondence, if the found first verification result If the result is the same as the second verification result in the pre-preparation message, then a preparation message is broadcast in the blockchain system, and the preparation message is used for at least one of the master node and the blockchain system
  • Follower nodes perform consensus processing.
  • S180 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the broadcast module run by the processor.
  • the unverified transactions finally acquired by the first slave node and the master node should be the same, and correspondingly, the first hash value and the second hash value should also be the same. Therefore, after receiving the pre-preparation message sent by the master node, the first follower node can search for the target key-value pair locally, and the target key-value pair is keyed by the second hash value in the pre-preparation message, or it can be understood as, The key of the target key-value pair (that is, the first hash value) is the same as the second hash value in the pre-prepared message.
  • the value in the target key-value pair (that is, the first verification result) may be taken out. Then, compare the first verification result taken from the target key-value pair with the second verification result in the pre-preparation message, that is, compare the verification of the transactions that need to be on-chain involved in this round of consensus between the master node and the first follower node Are the results consistent. If yes, it means that the verification is passed, the first follower node can broadcast a preparation message in the blockchain system 10, and other follower nodes can perform subsequent consensus processing based on the preparation message broadcast by the first follower node.
  • the pre-preparation message broadcast by the master node may also include an illegal transaction list, and the illegal transaction list may be a spliced list of illegal transactions in the at least one unverified transaction.
  • the first follower node if the first follower node cannot find the first verification result corresponding to the second hash value in the pre-prepared message based on the corresponding relationship, that is, the target key-value pair cannot be found, the first follower node The node can verify the illegal transaction list in the pre-prepared message to obtain the third verification result. If the third verification result is the same as the second verification result in the pre-preparation message, the first follower node may broadcast the preparation message in the blockchain system 10 .
  • the master node and at least one follower node in the blockchain system can verify the transactions in the block in parallel, and the master node passes the pre-preparation in the pre-preparation stage.
  • the message broadcasts the second verification result of the node to the follower node, and the follower node broadcasts the preparation message externally when the second verification result is the same as the first verification result of the node, and enters the preparation stage for subsequent consensus processing , which helps to improve the consistency of the verification results of the transactions in the block by the master node and the follower nodes on the basis of speeding up the consensus process and improving the consensus efficiency.
  • the broadcasting of the preparation message by the first follower node in the blockchain system can specifically be implemented through the following steps:
  • the first follower node After broadcasting the preparation message, the first follower node enters the preparation stage, waits for and collects the preparation message in the preparation stage; if the preparation message collected reaches the first predetermined number, then broadcasts a confirmation message in the block chain system 10, and enters Confirmation stage; waiting and collecting confirmation messages in the confirmation stage; if the collected confirmation messages reach the second predetermined number, then it is determined that the block chain system 10 reaches a consensus on the legal transaction in the at least one unverified transaction, and will be based on the legal
  • the block formed by the transaction is appended to the local blockchain (which can be understood as "placement").
  • the first predetermined number may be 2f
  • the second predetermined number may be 2f+1.
  • the preparation message collected by the first slave node may include the preparation message broadcast by the second slave node, and may also include the preparation message broadcast by the first slave node itself.
  • the confirmation message collected by the first slave node may include the confirmation message broadcast by the master node, the confirmation message broadcast by the second slave node, and the confirmation message broadcast by the first slave node itself.
  • the master node can also receive the preparation message broadcast by the follower nodes in the block chain system, and if the received preparation message reaches the first predetermined number, broadcast a confirmation message in the block chain system; receive If the confirmation messages broadcast by the follower nodes in the blockchain system reach a second predetermined number, blocks based on legal transactions in the at least one unverified transaction are appended to the local blockchain.
  • the master node may exclude illegal transactions from the at least one unverified transaction.
  • the master node after the master node broadcasts the pre-preparation message, it enters the pre-preparation stage, and waits for and collects the pre-preparation message broadcast by the first follower node in the pre-preparation stage.
  • the master node waits and collects confirmation messages in the confirmation phase, and if the collected confirmation messages reach the second predetermined number, then it is determined that the blockchain system 10 has reached a consensus on the legal transaction in the at least one unverified transaction, and the legal transaction is formed into The blocks of are appended to the local blockchain (i.e. "placed").
  • the confirmation message collected by the master node in the confirmation stage may include a confirmation message broadcast by at least one follower node in the blockchain system 10, and may also include a confirmation message broadcast by the master node itself.
  • the consensus method provided in this embodiment may further include steps S110, S111 and S200 shown in FIG. 3 .
  • the master node acquires the current network status of the blockchain system.
  • S110 may be executed by the processor calling a corresponding instruction stored in the memory, or may be executed by a broadcast module run by the processor.
  • the master node judges whether the current network state of the blockchain system meets the preset condition. If yes, the master node triggers the execution of S120. If not, the master node may execute S200.
  • S111 may be executed by the processor calling a corresponding instruction stored in the memory, or may be executed by a broadcast module run by the processor.
  • triggering execution of a certain step can be understood as jumping to this step.
  • the follower node can fish the at least one unverified transaction from the local transaction pool.
  • S110 may be implemented through the sub-steps shown in FIG. 4 .
  • the details are as follows.
  • S111-1 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the broadcast module run by the processor.
  • the master node determines that the current network state of the blockchain system meets the preset condition.
  • S111-2 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the broadcast module run by the processor.
  • the master node determines that the current network state of the blockchain system does not meet the preset condition.
  • S111-3 may be executed by the processor calling a corresponding instruction stored in the memory, or may be executed by the broadcast module run by the processor.
  • view replacement when the master node fails or the slave node suspects that the master node is in an abnormal state, view replacement will be triggered.
  • the master node can accumulate the total number of times of view replacement, for example, every time a view replacement occurs, the first count will be accumulated by 1.
  • the master node can also accumulate the number of view changes that occurred at the consensus block height. For example, under the current consensus block height, every time a view change occurs, the second count will be incremented by 1.
  • the master node when the master node needs to judge the current network status of the blockchain system 10, it obtains the current accumulated first number and second number, and calculates the ratio of the two. This ratio can represent the current network status of the blockchain system 10 . If the ratio of the second count to the first count does not exceed the first threshold, it means that the current network status of the blockchain system 10 is good, that is, the preset condition is met, and S120 can be executed.
  • S200 may be executed by the processor calling corresponding instructions stored in the memory, or may be executed by the broadcast module run by the processor.
  • the master node can clear the current accumulated first and second times, that is, restart the accumulation of the first and second times.
  • the consensus process can be performed according to the consensus process of the preset PBFT algorithm.
  • the preset PBFT algorithm here can be the PBFT algorithm in the related technology.
  • each round of consensus of the PBFT algorithm in the related technology can correspond to a view.
  • a view usually includes a master node and at least one follower node.
  • a round of consensus usually includes five stages: request, pre-prepare, prepare, commit, and reply.
  • a condition for checking the network status may be set, that is, when the condition is met, the master node executes S110 again.
  • the consensus method provided by this embodiment may further include steps S109 and S201 shown in FIG. 5 .
  • S109 may be executed by the processor calling a corresponding instruction stored in the memory, or may be executed by a broadcast module run by the processor.
  • the second threshold here is the network judgment threshold, which can be flexibly set according to needs, and can also be determined through statistical tests. This embodiment does not limit this.
  • S201 may be executed by the processor calling a corresponding instruction stored in the memory, or may be executed by a broadcast module run by the processor.
  • the consensus method may also include the following steps:
  • the first slave node cannot find the at least one unverified transaction based on the transaction hash list, request the unverified transaction from the master node or any second slave node.
  • this step may be executed by the processor calling a corresponding instruction stored in the memory, or executed by the second verification module run by the processor.
  • the first follower node When the first follower node cannot get the corresponding unverified transaction from the local transaction pool based on the hash value in the transaction hash list, it can send an acquisition request for the unverified transaction to the master node or the second follower node.
  • the get request can carry the hash value of the unverified transaction.
  • the master node or the second slave node can provide the original transaction data of the unverified transaction to the first slave node for subsequent verification by the first slave node.
  • the block chain node 100 in the block chain system 10 is the master node
  • the block chain node 101, the block chain node 102 and the block chain node 103 are follower nodes
  • the block chain node 103 is a Byzantine node.
  • the master node 100 judges whether the current consensus block height is a network status checkpoint: for example, the current consensus block height can be taken as the remainder of the preset network judgment threshold, and if the result is 0, it is determined that the current consensus block height is the network status checkpoint. State checkpoint; otherwise, it is determined that the current consensus block height is not a network state checkpoint.
  • the current consensus block height is not a network status checkpoint, then accumulate the number of view changes V1 from the current consensus block height to the next network checkpoint and the number of view changes V2 at the current consensus block height; and use the last time The result of the network status judgment.
  • the current consensus block height is the network status checkpoint, then obtain the current accumulated V1 and V2, and calculate V1/V2; judge whether V1/V2 exceeds the network status judgment threshold; if so, it means that the current network status is poor; if not, It means that the current network status is good. Clear the current accumulated V1 and V2 after obtaining the network status.
  • the consensus process corresponding to the consensus method of the embodiment of the present disclosure includes an unverified block stage, a pre-preparation stage, a preparation stage, and a confirmation stage, which may specifically include the following procedures.
  • FIG. 6 shows a schematic diagram of the consensus process of applying the consensus method provided by the embodiment of the present disclosure in the blockchain system 10.
  • FIG. 7 shows the blockchain node 100 as the master node Sequence diagram with the first follower node (for example, blockchain node 101 or blockchain node 102 or blockchain node 103). The following will be introduced in conjunction with FIG. 6 and FIG. 7 .
  • the first step is to generate an unverified block message:
  • the master node obtains the transaction hash list from the transaction pool, generates the original request block, and uses the unverified block message to broadcast the transaction hash list.
  • the transaction hash list includes the transaction hash value of at least one unverified transaction that needs to be packaged into the block in this round.
  • the second step is to verify the unverified blocks generated by the master node:
  • the master node After the master node broadcasts the unverified block message, according to the transaction hash value in the transaction hash list, it sequentially retrieves unverified transactions from the local transaction pool, and stitches the retrieved transactions into an unverified block transaction list, and Verify the transactions in the unverified block transaction list; after the verification is completed, remove the illegal transactions from the unverified block transaction list to obtain the pre-accurate transaction list; and generate the verification (validation) data of the illegal transaction list ( can be used as the second verification result in the above-mentioned embodiment); regenerate the pre-prepared message (which can serve as the second hash value in the above-mentioned embodiment), and this message carries an illegal transaction list, verification data and original unverified Hash value of block transaction list; broadcast pre-prepare message.
  • the master node enters the pre-preparation state and waits for the prepare message sent by the follower node.
  • the first follower node retrieves the corresponding unverified transaction from the local transaction pool according to each transaction hash value in the transaction hash list in the unverified block message , if it cannot be retrieved from the local transaction pool, you can request the unverified transaction corresponding to the transaction hash value from other nodes (such as the master node or the second follower node).
  • the first follower node can carry the transaction hash value corresponding to the unverified transaction that cannot be retrieved from the local transaction pool in the request and send it to the master node.
  • the master node can find the corresponding transaction hash value based on the transaction hash value.
  • the raw transaction data of the unverified transaction is sent to the first follower node.
  • the first follower node splices the unverified transaction sent by the master node into the unverified block transaction list, and verifies the unverified block transaction list.
  • the first follower node determines the illegal transaction from the unverified block transaction list, and generates the verification data of the illegal transaction list (which can serve as the first verification result in the above-mentioned embodiment).
  • the first verification result includes the verification result information of the slave node on the at least one unverified transaction
  • the second verification result includes the verification result information of the master node on the at least one unverified transaction. Verification result information of illegal transactions in unverified transactions.
  • the third step is to verify the pre-preparation block generated by the master node: after receiving the pre-preparation message sent by the master node, the first follower node searches the corresponding verification data from the local cache according to the hash value in the pre-preparation message .
  • the first follower node broadcasts a preparation message and collects the preparation messages of other nodes. If the first predetermined number of preparation messages are collected, it enters the preparation state, broadcasts a confirmation message and collects the confirmation messages broadcast by other nodes.
  • the master node and each follower node after collecting the second predetermined number of confirmation messages, write the block into the database (that is, put the data on the disk), and the current round of consensus ends.
  • Any consensus method provided by the embodiments of the present disclosure may be executed by any appropriate device with data processing capabilities, including but not limited to: terminal devices and servers.
  • any consensus method provided in the embodiments of the present disclosure may be executed by a processor, for example, the processor executes any consensus method mentioned in the embodiments of the present disclosure by calling corresponding instructions stored in a memory. I won't go into details below.
  • FIG. 8 is a schematic structural diagram of an embodiment of the disclosed device.
  • the device of this embodiment can be used to implement the above-mentioned method embodiments of the present disclosure.
  • the consensus device 800 may include a broadcast module 810 and a first verification module 820 .
  • the broadcast module 810 is used to broadcast the transaction hash list in the block chain system 10, so that the follower nodes in the block chain system 10 receive the transaction hash list, and the transaction hash list includes at least A hash value of an unverified transaction, searching for the at least one unverified transaction based on the transaction hash list, verifying the at least one unverified transaction to obtain a first verification result, and obtaining a first verification result based on the at least one unverified transaction the first hash value, and save the corresponding relationship between the first verification result and the first hash value.
  • the first verification module 820 is configured to search for the at least one unverified transaction based on the transaction hash list, verify the at least one unverified transaction to obtain a second verification result, and obtain a second verification result based on the at least one unverified transaction. hash value.
  • the broadcast module 810 is further configured to broadcast a pre-preparation message in the blockchain system 10, so that the follower node searches for the first verification result corresponding to the second hash value based on the correspondence, and the The pre-preparation message includes the second verification result and the second hash value; if the found first verification result is the same as the second verification result, the preparation message is broadcast in the block chain system, so The preparation message is used for consensus processing by the master node and the slave nodes in the blockchain system 10 .
  • the consensus device 800 may also include a network state judging module 830 .
  • the network state judging module 830 is used to obtain the current network state of the block chain system 10 before broadcasting the transaction hash list in the block chain system 10 of the broadcast module 810, and judge whether the current network state conforms to the preset condition; if so, trigger the broadcast module 810 to broadcast the transaction hash list in the block chain system 10.
  • the network state judging module 830 can judge whether the current network state of the blockchain system 10 meets the preset condition in the following manner:
  • the first number is the current total number of view replacement times of the blockchain system 10
  • the second number is the current consensus number of the blockchain system 10
  • the number of view changes that occur at the block height; if the ratio of the second number to the first number does not exceed the first threshold, it is determined that the current network state meets the preset condition, and the current accumulated first number is cleared. first and second times.
  • the consensus device 800 may also include a PBFT consensus module 840 .
  • the PBFT (Practical Byzantine) consensus module 840 is used to perform consensus processing according to the consensus process of the preset PBFT algorithm when the current network state of the blockchain system 10 does not meet the preset conditions, and clear the current accumulated No. first and second times.
  • the network state judging module 830 judges whether the current network state of the blockchain system 10 meets the conditions, it can also be used to:
  • the consensus device 800 may also include a consensus processing module 850 .
  • the consensus processing module 850 is used to: receive the preparation message broadcast by the follower node in the block chain system 10, if the received preparation message reaches the first predetermined number, broadcast a confirmation message in the block chain system 10; receive The confirmation message broadcast by the follower node in the block chain system 10, if the received confirmation message reaches the second predetermined number, the block based on the legal transaction in the at least one unverified transaction is appended to the local block chain .
  • FIG. 9 is a schematic structural diagram of an embodiment of the disclosed device.
  • the device of this embodiment can be used to implement the above-mentioned method embodiments of the present disclosure.
  • the consensus device 900 can be applied to the first follower node in the blockchain system. It can be understood that the first follower node is any follower node in the blockchain system 10.
  • the block The chain system 10 also includes master nodes.
  • the consensus device 900 may include a receiving module 910 , a second verification module 920 and a verification result comparison module 930 .
  • the receiving module 910 is configured to receive the transaction hash list broadcast by the master node, and the transaction hash list includes at least one hash value of an unverified transaction.
  • the second verification module 920 is configured to find the at least one unverified transaction based on the transaction hash list, verify the at least one unverified transaction to obtain a first verification result, and obtain the first verification result based on the at least one unverified transaction. hash value, and save the corresponding relationship between the first verification result and the first hash value.
  • the receiving module 910 is further configured to receive a pre-preparation message broadcast by the master node, where the pre-preparation message includes a second verification result obtained by the master node from verifying the at least one unverified transaction and based on the at least one unverified transaction The second hash value obtained by verifying the transaction.
  • the verification result comparison module 930 is configured to find a first verification result corresponding to the second hash value in the pre-prepared message based on the correspondence, if the first verification result is the same as the second verification result, then A preparation message is broadcast in the blockchain system, and the preparation message is used for consensus processing by the master node and at least one slave node in the blockchain system.
  • the blockchain system may also include a second follower node, which is a rechargeable node different from the first follower node.
  • the second verification module 920 can also be used for:
  • the pre-preparation message further includes an illegal transaction list, and the legal transaction list includes the illegal transactions in the at least one unverified transaction.
  • the verification result comparison module 930 can also be used for:
  • the preparation message is broadcast in the block chain system.
  • FIG. 10 is a schematic structural diagram of an embodiment of the disclosed device.
  • the device of this embodiment can be used to implement the above-mentioned method embodiments of the present disclosure.
  • a block chain node 100 is taken as an example to show a schematic diagram of a hardware architecture of a block chain node provided by an embodiment of the present disclosure.
  • the blockchain node 100 may include the aforementioned consensus devices 800 and 900 , a processor 110 and a computer-readable storage medium 120 .
  • Processor 110 and computer readable storage medium 120 may communicate via system bus 130 .
  • the software function modules included in the consensus devices 800 and 900 may be stored in the machine-readable storage medium 120 in the form of machine-executable instructions.
  • the processor 110 can realize the consensus method provided by the embodiments of the present disclosure by calling and reading the machine-executable instructions in the computer-readable storage medium 120 .
  • the architecture shown in FIG. 10 is only for illustration.
  • the blockchain node 100 provided by the embodiment of the present disclosure may also include more or fewer components than those shown in Figure 10, for example, may also include a communication unit, or have a matching value that is completely different from that shown in Figure 11. Examples are not limited to this.
  • the components shown in FIG. 10 may be realized by hardware, software or a combination thereof.
  • the processes described above with reference to the flowcharts can be implemented as computer software programs.
  • the embodiments of the present disclosure include a computer program product, which includes a computer program tangibly contained on a machine-readable medium, the computer program includes program code for executing the method shown in the flowchart, and the program code may include a corresponding Executing the instructions corresponding to the method steps provided by the embodiments of the present disclosure, for example, broadcasting the transaction hash list in the blockchain system, so that the follower nodes in the blockchain system receive the transaction hash list, the The transaction hash list includes a hash value of at least one unverified transaction; based on the transaction hash list, searching for the at least one unverified transaction, verifying the at least one unverified transaction to obtain a first verification result, and, based on the The at least one unverified transaction obtains a first hash value, and saves the corresponding relationship between the first verification result and the first hash value; based on the transaction hash list, finds
  • the methods and apparatus of the present disclosure may be implemented in many ways.
  • the methods and apparatuses of the present disclosure may be implemented by software, hardware, firmware or any combination of software, hardware, and firmware.
  • the above sequence of steps for the method is for illustration only, and the steps of the method of the present disclosure are not limited to the sequence specifically described above unless specifically stated otherwise.
  • the present disclosure can also be implemented as programs recorded in recording media, the programs including machine-readable instructions for realizing the method according to the present disclosure.
  • the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
  • the description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本公开实施例提供一种共识方法、装置及区块链系统。其中，主节点直接在系统中广播包括至少一个未验证交易的哈希值的交易哈希列表，以使随从节点和主节点同步对至少一个未验证交易进行验证，随从节点保存验证所得的第一验证结果以及至少一个未验证交易的第一哈希值。主节点则在完成验证后将所得的第二验证结果和至少一个未验证交易的第二哈希值携带在预准备消息中广播出去，以使随从节点基于第二哈希值查找第一验证结果，并在第二验证结果和查找到的第一验证结果相同时，广播准备消息，以进入后续的共识阶段，完成共识处理。如此，主节点和随从节点可以同步对本轮共识中需上链交易进行验证，有助于加快共识进程，提升共识效率。

Description

共识方法、装置及区块链系统
本公开要求在2021年09月16日提交中国专利局、申请号为CN 202111085505.9、发明名称为“共识方法、装置及区块链系统”的中国专利申请的优先权，其全部内容通过引用结合在本公开。
技术领域
本公开涉及区块链技术领域，尤其涉及一种共识方法、装置及区块链系统。
背景技术
实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法，可以在系统中作恶节点少于三分之一的情况下，提高区块链系统的正确性(例如，避免分叉)。在采用PBFT算法的区块链系统中，每产生一个区块，通常都需经历一轮共识。共识是由区块发起者生成区块，并在系统中广播，其他区块验证者对区块进行验证，以完成共识的流程。其中，区块发起者又可以称为“主节点(primary)”，其余区块验证者又可以称为“随从节点(backup)”。
发明内容
本公开实施例提供了一种共识方法、装置及区块链系统，用于提高区块验证的共识效率。
根据本公开实施例的一个方面，提供了一种共识方法，所述方法包括：
在所述区块链系统中广播交易哈希(hash)列表，使所述区块链系统中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
基于所述交易哈希列表查找所述至少一个未验证交易，并验证所述至少一个未验证交易得到第二验证结果，以及基于所述至少一个未验证交易得到第二哈希值；
在所述区块链系统中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点以及所述区块链系统中的随从节点进行共识处理。
根据本公开实施例的另一个方面，提供了一种共识方法，应用于区块链系统中的第一随从节点，所述区块链系统还包括主节点；所述方法包括：
接收所述主节点广播的交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
接收所述主节点广播的预准备消息，所述预准备消息包括所述主节点验证所述至少一 个未验证交易得到的第二验证结果以及基于所述至少一个未验证交易得到的第二哈希值；
基于所述对应关系查找与所述预准备消息中的第二哈希值对应的第一验证结果，若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点以及所述区块链系统中的至少一个随从节点进行共识处理。
根据本公开实施例的另一个方面，提供了一种共识装置，所述装置包括广播模块和验证模块；
其中，广播模块用于在所述区块链系统中广播交易哈希列表，使所述区块链系统中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值，基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
第一验证模块用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果，以及基于所述至少一个未验证交易得到第二哈希值；
所述广播模块还用于在所述区块链系统中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的随从节点进行共识处理。
根据本公开实施例的另一个方面，提供了一种共识装置，应用于区块链系统中的第一随从节点，所述区块链系统还包括主节点；所述装置包括接收模块、验证模块以及验证结果比较模块；
其中，接收模块用于接收所述主节点广播的交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
第二验证模块用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
所述接收模块还用于接收所述主节点广播的预准备消息，所述预准备消息包括所述主节点验证所述至少一个未验证交易得到的第二验证结果以及基于所述至少一个未验证交易得到的第二哈希值；
验证结果比较模块用于基于所述对应关系查找与所述预准备消息中的第二哈希值对应的第一验证结果，若所述第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的各随从节点进行共识处理。
根据本公开实施例的又一个方面，提供了一种区块链系统，包括主节点和第一随从节点，第一随从节点是所述区块链系统中的任意一个随从节点；
所述主节点用于在所述区块链系统中广播交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
所述第一随从节点用于接收所述交易哈希列表，基于所述交易哈希列表查找所述至少一个未验证交易；验证所述至少一个未验证交易得到第一验证结果，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
所述主节点还用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果；基于所述至少一个未验证交易得到第二哈希值，并在所述区块链系统中广播携带所述第二验证结果和所述第二哈希值的预准备消息；
所述第一随从节点还用于接收所述预准备消息，基于所述对应关系查找与所述第二哈希值对应的第一验证结果，若查找到的第一验证结果与所述第二验证结果相同，则在所述 区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的至少一个随从节点进行共识处理。
根据本公开实施例的再一个方面，提供了一种计算机可读存储介质，其上存储有程序代码，所述程序代码可被处理器调用执行以实现本公开上述实施例中任意一项提供的共识方法。
本公开实施例提供的方案中，主节点直接在区块链系统中广播包括至少一个未验证交易的哈希值的交易哈希列表，以使随从节点和主节点同步对至少一个未验证交易进行验证，随从节点保存验证所得的第一验证结果以及至少一个未验证交易的第一哈希值。主节点则在完成验证后将所得的第二验证结果和至少一个未验证交易的第二哈希值携带在预准备消息中广播出去，以使随从节点基于第二哈希值查找第一验证结果，并在第二验证结果和查找到的第一验证结果相同时，广播准备消息，以进入后续的共识阶段，完成共识处理。如此，主节点和随从节点可以并行地对本轮共识中需上链的未验证交易进行验证，有助于加快共识进程，提升共识效率。
下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。
附图说明
构成说明书的一部分的附图描述了本公开的实施例，并且连同描述一起用于解释本公开的原理。
参照附图，根据下面的详细描述，可以更加清楚地理解本公开。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图：
图1为本公开实施例提供的一种区块链系统的架构示意图；
图2为本公开的共识方法的一个实施例的流程示意图；
图3为本公开的共识方法的又一个实施例的流程示意图；
图4为图3所示的实施例中步骤S111的流程示意图；
图5为本公开的共识方法的又一个实施例的流程示意图；
图6为本公开实施例提供的区块链系统的共识过程示意图；
图7为本公开实施例提供的区块链系统的共识过程时序图；
图8为本公开的共识装置的一个实施例的结构示意图；
图9为本公开的共识装置的一个实施例的结构示意图；
图10为本公开实施例提供的一种区块链节点的框架示意图。
具体实施方式
现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。
还应理解，在本公开实施例中，“多个”可以指两个或两个以上，“至少一个”可以指一个、两个或两个以上。
本领域技术人员可以理解，本公开实施例中的“第一”、“第二”等术语仅用于区别不同步骤、设备或模块等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。
还应理解，对于本公开实施例中提及的任一部件、数据或结构，在没有明确限定或者在前后文给出相反启示的情况下，一般可以理解为一个或多个。
还应理解，本公开对各个实施例的描述着重强调各个实施例之间的不同之处，其相同或相似之处可以相互参考，为了简洁，不再一一赘述。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
另外，公开中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本公开中字符“/”，一般表示前后关联对象是一种“或”的关系。
本公开实施例可以应用于终端设备、计算机系统、服务器等电子设备，其可与众多其它通用或专用计算系统环境或配置一起操作。适于与终端设备、计算机系统、服务器等电子设备一起使用的众所周知的终端设备、计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统﹑大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。
终端设备、计算机系统、服务器等电子设备可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。
为了使本公开实施例中的技术方案及优点更加清楚明白，以下结合附图对本公开的示例性实施例进一步的说明，显然，所描述的实施例仅是本公开的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。
图1是本公开实施例提供的一种区块链系统10的架构示意图，其中包括多个区块链节点，例如区块链节点100、区块链节点101、区块链节点102以及区块链节点103。区块链系统10中的区块链节点的数量为3f+1，其中f表示的是区块链系统10中的拜占庭节点的数量，即恶意或故障节点的数量。换句话说，区块链系统10中至少存在2f+1个非拜占庭节点，这些节点可以按照本公开实施例提供的共识方法进行共识处理。区块链系统10中的随从节点均为对等节点，两两之间可以通信。可以理解，本公开实施例中提及的区块链节点，例如可以是终端设备(如，平板电脑、笔记本电脑、个人计算机)或服务器，这里的服务器例如可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群，还可以是提供云计算、大数据等基础云计算服务的云服务器。本公开实施例对此没有限制。
图2为本公开实施例提供的一种共识方法的流程示意图，可以应用于图1所示的区块链系统10。在一轮共识中，图1所示的区块链系统10中的多个区块链中的任意一个节点被选为主节点(即区块链发起者)，其余区块链节点则作为随从节点(即区块验证者)。为了便于理解，本实施例将以区块链节点100被选为主节点、区块链节点101、区块链节点102和区块链节点103作为随从节点为例，对本实施例提供的共识方法进行介绍，具体包括以下步骤。
S120，主节点在区块链系统中广播交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值。
在一个可选示例中，S120可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
实施过程中，主节点(如图1中的区块链节点100)可以从本地交易池捞取需要打包 进入区块的至少一个交易的哈希值，并将捞取的哈希值组成S120中的交易哈希列表。这里，需要打包进入区块的至少一个交易是指本轮共识需要上链的交易，主节点在对需要打包进入区块的至少一个交易进行验证之前，可以将交易哈希列表广播到区块链系统10中，基于此，本实施例将需要打包进入区块的交易称为“未验证交易”。
示例性地，本实施例中，交易哈希列表可以携带在未验证区块(pre-block)消息中广播出去，相应地，广播未验证区块消息的阶段可以称为未验证区块阶段。换句话说，本公开实施例提供的共识方法，可以在实用拜占庭容错算法(Practical Byzantine Fault Tolerance，PBFT)共识过程所包含的预准备(pre-prepare)阶段、准备(prepare)阶段和确认(commit)阶段的基础上，增加未验证区块阶段。具体参照下文相关介绍。
主节点广播的未验证区块消息可以被图1所示的区块链系统10中的随从节点接收到。换言之，主节点在区块链系统10中广播交易哈希列表，可以使得区块链系统10中的随从节点作为第一随从节点执行下文描述的S140。
S140，区块链系统中的第一随从节点接收所述交易哈希列表，基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系。
在一个可选示例中，S140可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的第二验证模块执行。
需要说明的是，本实施例中，不同的随从节点的处理流程可以是类似的。区块链系统10中的任意一个随从节点均可以作为第一随从节点，并且当一个随从节点被视为第一随从节点时，其余随从节点均可被视为第二随从节点。例如，当以图1所示的区块链节点101为第一随从节点时，区块链节点102和区块链节点103均可视为第二随从节点。又例如，当以图1所示的区块链节点102为第一随从节点时，区块链节点101和区块链节点103均可视为第二随从节点。
第一随从节点接收到未验证区块消息后，可以获得未验证区块消息中的交易哈希列表，交易哈希列表中的任一哈希值均对应一个未验证交易。举例来说，未验证交易tx-1与哈希值hs-1对应，表示对tx-1进行哈希计算，可以得到hs-1。
针对交易哈希列表中的至少一个哈希值，第一随从节点可以从本地交易池捞取该哈希值对应的未验证交易，如此可以得到本轮共识需要上链的至少一个未验证交易的原始交易数据。第一随从节点可以将捞取的未验证交易拼接成交易哈希列表，在本地对该交易哈希列表发起验证，确定出该交易哈希列表中的不合法交易，这里的不合法交易例如可以为超时交易、无效交易等。例如，由于区块链节点的性能问题，可能导致部分交易执行结果的一致性出现问题，这些交易可以称为超时交易。又例如，当一笔交易的余额不足时，可能导致该交易无法执行，则该交易以及该交易的源账户的后续交易都可以称为无效交易。
验证完成后，第一随从节点可以生成不合法交易的校验结果信息，进而得到第一验证结果，第一验证结果至少包括第一随从节点生成的所述不合法交易的校验结果信息。第一随从节点还可以对本次捞取的至少一个未验证交易进行哈希计算，得到第一哈希值。可以理解，第一哈希值可以是第一随从节点捞取的所有未验证交易整体的哈希值。然后，第一随从节点可以在本地保存第一哈希值和第一验证结果的对应关系。例如，可以以第一哈希值为键(key)、以第一验证结果为值(value)形成键值对，在本地保存该键值对。
S160，所述主节点基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果；基于所述至少一个未验证交易得到第二哈希值，并在所述区块链系统中广播携带所述第二验证结果和所述第二哈希值的预准备消息。
在一个可选示例中，S160可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的第一模块执行。
本实施例中，S160与S140可以是并行执行的。
实施过程中，主节点在广播未验证区块消息后，再进入预准备阶段。在本实施例中，主节点在预准备阶段可以根据交易哈希列表中的任一哈希值从本地交易池捞取对应的未验证交易的原始交易数据，并对所捞取的未验证交易进行验证。验证的具体流程可以与第一随从节点针对未验证交易的验证流程类似。
主节点从所捞取的未验证交易中确定出不合法交易后，可以生成该不合法交易的校验结果信息，进而得到第二验证结果，其中，第二验证结果包括主节点生成的该不合法交易的校验结果信息。主节点还可以对所捞取的未验证交易整体进行哈希计算，得到第二哈希值。然后，主节点可以在区块链系统10中广播预准备消息，所述预准备消息包括第二验证结果和第二哈希值。该预准备消息可以被区块链系统10中的随从节点接收到。换言之，主节点在区块链系统10中广播预准备消息，可以使得区块链系统10中的任一随从节点作为第一随从节点执行下文描述的S180。
S180，所述第一随从节点接收所述预准备消息，基于所述对应关系查找与所述预准备消息中的所述第二哈希值对应的第一验证结果，若查找到的第一验证结果与所述预准备消息中的第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的至少一个随从节点进行共识处理。
在一个可选示例中，S180可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
本实施例中，第一随从节点和主节点最终获取的未验证交易应当是相同的，对应地，第一哈希值和第二哈希值也应当是相同的。因此，第一随从节点在接收主节点发出的预准备消息后，可以从本地查找目标键值对，目标键值对以该预准备消息中的第二哈希值为键，或者可以理解成，目标键值对的键(即第一哈希值)与该预准备消息中的第二哈希值是相同的。
如果查找到目标键值对，则可以取出目标键值对中的值(即第一验证结果)。然后，将从目标键值对取出的第一验证结果与预准备消息中的第二验证结果进行比较，即比较主节点和第一随从节点对于本轮共识中涉及的需上链的交易的验证结果是否一致。如果是，则表示验证通过，第一随从节点可以在区块链系统10中广播准备消息，其他随从节点可以基于第一随从节点广播出的准备消息进行后续的共识处理。
可选地，主节点广播的预准备消息还可以包括不合法交易列表，该不合法交易列表可以是所述至少一个未验证交易中的不合法交易拼接而成的列表。
实施过程中，若第一随从节点基于所述对应关系，无法查找到与预准备消息中的第二哈希值对应的第一验证结果，即无法查找到所述目标键值对，第一随从节点可以对预准备消息中的不合法交易列表进行验证，得到第三验证结果。若第三验证结果和预准备消息中的第二验证结果相同，则第一随从节点可以在区块链系统10中广播准备消息。
通过图2所示的共识方法，每轮共识过程中，区块链系统中的主节点和至少一个随从节点可以并行地进行区块中交易的验证，并由主节点在预准备阶段通过预准备消息将本节点的第二验证结果广播给随从节点，随从节点在第二验证结果与本节点的第一验证结果相同的情况下，再对外广播准备消息，并进入准备阶段，以进行后续共识处理，有助于在加快共识进程、提升共识效率的基础上，提高主节点和随从节点各自对区块中交易的验证结果的一致性。
进一步地，在上述实施例的S180中，第一随从节点在所述区块链系统中广播准备消息具体可以通过以下步骤实现：
从所述至少一个未验证交易中剔除所述不合法交易，并针对所述至少一个未验证交易中的合法交易在区块链系统中广播所述准备消息。
在广播准备消息后，第一随从节点进入准备阶段，在准备阶段等待并收集准备消息； 若收集的准备消息达到第一预定数量，则在所述区块链系统10中广播确认消息，并进入确认阶段；在确认阶段等待并收集确认消息；若收集的确认消息达到第二预定数量，则确定区块链系统10针对所述至少一个未验证交易中的合法交易达成共识，将基于所述合法交易形成的区块追加到本地区块链(可以理解成“落盘”)。
本公开实施例中，第一预定数量可以是2f，第二预定数量可以是2f+1。需要说明的是，第一随从节点收集的准备消息可以包含第二随从节点广播的准备消息，此外，还可以包含第一随从节点自身广播出去的准备消息。类似地，第一随从节点收集的确认消息可以包含主节点广播的确认消息、第二随从节点广播的确认消息，还可以包含第一随从节点自身广播的确认消息。
本实施例中，主节点还可以接收所述区块链系统中的随从节点广播的准备消息，若所接收的准备消息达到第一预定数量，在所述区块链系统中广播确认消息；接收所述区块链系统中的随从节点广播的确认消息，若所接收的确认消息达到第二预定数量，将基于所述至少一个未验证交易中的合法交易的区块追加到本地区块链。作为示例，主节点可以从所述至少一个未验证交易中剔除不合法交易。并且，主节点在广播预准备消息后，进入预准备阶段，并在预准备阶段等待并收集第一随从节点广播的准备消息，若收集的准备消息达到第一预定数量，则针对所述至少一个未验证交易中的合法交易在区块链系统10中广播确认消息，从而进入确认阶段。主节点在确认阶段等待并收集确认消息，若收集的确认消息达到第二预定数量，则确定区块链系统10针对所述至少一个未验证交易中的合法交易达成共识，将所述合法交易形成的区块追加到本地区块链(即“落盘”)。
这里，主节点在确认阶段收集的确认消息可以包括至少一个随从节点在区块链系统10中广播的确认消息，还可以包括主节点自身广播的确认消息。
在一些可选的实施例中，在执行S120之前，本实施例提供的共识方法还可以包括图3所示步骤S110、S111以及S200。
S110，主节点获取区块链系统的当前网络状态。
在一个可选示例中，S110可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
S111，主节点判断区块链系统的当前网络状态是否符合预设条件。若是，则主节点触发执行所述S120。若否，则主节点可以执行S200。
在一个可选示例中，S111可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
本实施例中，“触发执行”某个步骤，可以理解成跳转至该步骤。
这样，如上所述，随从节点可以从本地交易池捞取所述至少一个未验证交易。
可选地，S110可以通过图4所示的子步骤实现。详细介绍如下。
S111-1，获取当前累计的第一次数和第二次数，所述第一次数是所述区块链系统当前的视图更换总次数，所述第二次数是所述区块链系统在当前共识区块高度发生的视图更换次数。
在一个可选示例中，S111-1可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
S111-2，若所述第二次数与所述第一次数的比值不超过第一阈值，则所述主节点确定所述区块链系统的当前网络状态符合所述预设条件。
在一个可选示例中，S111-2可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
S111-3，若所述第二次数与所述第一次数的比值超过第一阈值，则所述主节点确定所述区块链系统的当前网络状态不符合所述预设条件。
在一个可选示例中，S111-3可以由处理器调用存储器存储的相应指令执行，也可以由 被处理器运行的广播模块执行。
本实施例中，当主节点出现故障或者随从节点怀疑主节点处于异常状态时，会触发视图更换。主节点可以对视图更换的总次数进行累计，例如，每发生一次视图更换，则将第一次数累加1。主节点还可以针对任一共识区块高度，累计在该共识区块高度发生的视图更换次数。例如，在当前共识区块高度下，每发生一次视图更换，则将第二次数累加1。
实施过程中，主节点在需要判断区块链系统10的当前网络状态时，获取当前累计的第一次数和第二次数，计算两者的比值。该比值可以表征区块链系统10的当前网络状态。如果第二次数与第一次数的比值不超过第一阈值，则表示区块链系统10的当前网络状态良好，即符合预设条件，从而可以执行S120。
S200，清空当前累计的第一次数和第二次数。
在一个可选示例中，S200可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
在本实施例中，若所述区块链系统的当前网络状态不符合所述预设条件，则按照预设的实用拜占庭容错算法的共识流程进行共识处理，并清空所述当前累计的第一次数和第二次数。
如果第二次数与第一次数的比值超过第一阈值，表示区块链系统10的当前网络状态较差，即不符合预设条件。此时，主节点可以清空当前累计的第一次数和第二次数，即重新开始累计第一次数和第二次数。并且，可以按照预设的PBFT算法的共识流程进行共识处理，这里的预设的PBFT算法可以是相关技术中的PBFT算法，例如，相关技术中的PBFT算法的每轮共识可以对应一个视图，每个视图通常包括主节点和至少一个随从节点。一轮共识通常包括请求(request)、预准备(pre-prepare)、准备(prepare)、确认(commit)、响应(reply)这共5个阶段。
可选地，在本实施例中，可以设置进行网络状态检查的条件，即当满足该条件时，主节点再执行S110。基于此，在执行S110之前，本实施例提供的共识方法还可以包括图5所示的步骤S109和S201。
S109，确定当前共识区块高度，判断所述当前共识区块高度对第二阈值取余的结果是否为0。若是，则触发执行S110；如否，则执行S201和S111。
在一个可选示例中，S109可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
这里的第二阈值是网络判断阈值，可以根据需要灵活设置，也可以通过统计测试确定。本实施例对此没有限制。
S201，将上一次获取的所述区块链系统的网络状态，确定为所述区块链系统的当前网络状态。
在一个可选示例中，S201可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的广播模块执行。
通过上述设计，可以减少随从节点从其他随从节点处获取未验证交易的原始交易数据的情况，减少网络传输。
可选地，即便是在网络状态较好的情况下，即符合预设条件的情况下，还是可能出现主节点广播的交易哈希列表中哈希值所对应的未验证交易，在第一随从节点的本地交易池中不存在的情况。基于此，本实施例提供的共识方法还可以包括如下步骤：
若第一随从节点基于所述交易哈希列表无法查找到所述至少一个未验证交易，向所述主节点或者任意一个第二随从节点请求所述未验证交易。
在一个可选示例中，该步骤可以由处理器调用存储器存储的相应指令执行，也可以由被处理器运行的第二验证模块执行。
当第一随从节点基于交易哈希列表中的哈希值，从本地交易池无法捞取到对应的未验 证交易时，可以向主节点或者第二随从节点发送针对该未验证交易的获取请求，该获取请求可以携带该未验证交易的哈希值。这样，主节点或第二随从节点可以向第一随从节点提供该未验证交易的原始交易数据，以供第一随从节点进行后续验证。
在一个具体的示例中，区块链系统10中的区块链节点100是主节点，区块链节点101、区块链节点102和区块链节点103是随从节点，且区块链节点103是拜占庭节点。
主节点100判断当前共识区块高度是否是网络状态检查点：例如可以将当前共识区块高度对预设的网络判断阈值取余，若所得的结果为0，则确定当前共识区块高度是网络状态检查点；否则确定当前共识区块高度不是网络状态检查点。
若当前共识区块高度不是网络状态检查点，则累计当前共识区块高度到下一网络检查点之间的视图更换次数V1以及当前共识区块高度下发生的视图更换次数V2；并沿用上一次的网络状态判断结果。
若当前共识区块高度是网络状态检查点，则获取当前累计的V1和V2，计算V1/V2；判断V1/V2是否超过网络状态判断阈值；若是，则表示当前网络状态较差；若否，则表示当前网络状态良好。获取网络状态完成后清空当前累计的V1和V2。
本公开实施例的共识方法对应的共识过程包括未验证区块阶段、预准备阶段、准备阶段和确认阶段，具体可以包括以下流程。
请一并参照图6和图7，图6示出了在区块链系统10中应用本公开实施例提供的共识方法的共识过程示意图，图7示出了作为主节点的区块链节点100与第一随从节点(例如，区块链节点101或区块链节点102或区块链节点103)的时序图。下面结合图6和图7进行介绍。
第一步，生成未验证区块消息：
1、从区块验证者集合中选择一个主节点，作为示例，可以使用当前视图序号(view number)与区块链节点数量(backup number)做模运算，并将得到的结果作为区块验证者的索引，使用这个索引从区块验证者集合中选出的区块验证者即为本轮共识的主节点(primary)；
2、主节点从交易池获取交易哈希列表，生成原始请求区块，并使用未验证区块消息将交易哈希列表广播出去。其中，交易哈希列表包括本轮需要打包进区块的至少一个未验证交易的交易哈希值。
第二步，验证主节点生成的未验证区块：
1、主节点在广播未验证区块消息后，根据交易哈希列表中的交易哈希值，顺序从本地交易池捞取未验证交易，并将捞取的交易拼接成未验证区块交易列表，并对未验证区块交易列表中的交易进行验证；验证完成后，从未验证区块交易列表中剔除不合法交易，得到预准确交易列表；并生成不合法交易列表的校验(validation)数据(可以作为上述实施例中的第二验证结果)；重新生成预准备消息(可以充当上述实施例中的第二哈希值)，该消息携带有不合法交易列表、校验数据以及原始的未验证区块交易列表的哈希值；广播预准备消息。主节点进入预准备状态，等待随从节点发出的准备消息。
2、第一随从节点(backup)在收到未验证区块消息后，根据未验证区块消息中的交易哈希列表中的每个交易哈希值，从本地交易池捞取对应的未验证交易，若从本地交易池无法捞取到，可以从其他节点(如主节点或第二随从节点)请求该交易哈希值对应的未验证交易。
如图8所示，第一随从节点可以将无法从本地交易池捞取的未验证交易所对应的交易哈希值携带在请求中，发送给主节点，主节点可以基于该交易哈希值查找相应的未验证交易的原始交易数据，并发送给第一随从节点。第一随从节点再将主节点发送的未验证交易拼接到未验证区块交易列表中，并对未验证区块交易列表进行验证。
验证完成后，第一随从节点从未验证区块交易列表中确定出不合法交易，生成不合法 交易列表的校验数据(可以充当上述实施例中的第一验证结果)。以原始的未验证区块交易列表的哈希值(可以充当上述实施例中的第一哈希值)为键、以该校验数据为值形成键值对，并将键值对缓存在本地。
在本示例中，所述第一验证结果包括所述随从节点对所述至少一个未验证交易中不合法交易的校验结果信息，所述第二验证结果包括所述主节点对所述至少一个未验证交易中不合法交易的校验结果信息。
第三步，验证主节点生成的预准备区块：第一随从节点在收到主节点发送的预准备消息后，根据预准备消息中的哈希值，从本地缓存中查找对应的校验数据。
1、若从本地缓存找到对应的校验数据，则将找到的校验数据与预准备消息中携带的不合法交易列表的校验数据进行比对，若一致，则确定验证通过。
2、若从本地缓存中未找到对应的校验数据，则按照预准备消息中的交易列表进行验证，得到不合法交易列表校验数据，将其与预准备消息中的校验数据进行比对，若一致，则确定验证通过。
3、若验证通过，则第一随从节点广播准备消息并收集其它节点的准备消息，若收集到第一预定数量的准备消息，进入准备状态，广播确认消息并收集其它节点广播的确认消息。
第四步，主节点和每个随从节点，各自在收集第二预定数量的确认消息后，将区块写入数据库(即数据落盘)，本轮共识结束。
本公开实施例提供的任一种共识方法可以由任意适当的具有数据处理能力的设备执行，包括但不限于：终端设备和服务器等。或者，本公开实施例提供的任一种共识方法可以由处理器执行，如处理器通过调用存储器存储的相应指令来执行本公开实施例提及的任一种共识方法。下文不再赘述。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
请参照图8，图8为本公开装置一个实施例的结构示意图，该实施例的装置可用于实现本公开上述各方法实施例。如图8所示，共识装置800可以包括广播模块810和第一验证模块820。
其中，广播模块810用于在所述区块链系统10中广播交易哈希列表，使所述区块链系统10中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值，基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系。
第一验证模块820用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果，以及，基于所述至少一个未验证交易得到第二哈希值。
所述广播模块810还用于在所述区块链系统10中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统10中的随从节点进行共识处理。
可选地，共识装置800还可以包括网络状态判断模块830。
网络状态判断模块830用于在广播模块810所述区块链系统10中广播交易哈希列表之前，获取所述区块链系统10的当前网络状态，并判断所述当前网络状态是否符合预设 条件；若是，则触发所述广播模块810在所述区块链系统10中广播交易哈希列表。
可选地，网络状态判断模块830可以通过以下方式判断所述区块链系统10的当前网络状态是否符合预设条件：
获取当前累计的第一次数和第二次数，所述第一次数是所述区块链系统10当前的视图更换总次数，所述第二次数是所述区块链系统10在当前共识区块高度发生的视图更换次数；若所述第二次数与所述第一次数的比值不超过第一阈值，则确定所述当前网络状态符合所述预设条件，并清空当前累计的第一次数和第二次数。
可选地，共识装置800还可以包括PBFT共识模块840。
PBFT(实用拜占庭)共识模块840用于在区块链系统10的当前网络状态不符合所述预设条件的情况下，按照预设的PBFT算法的共识流程进行共识处理，并清空当前累计的第一次数和第二次数。
可选地，所述网络状态判断模块830在判断所述区块链系统10的当前网络状态是否符合条件之前，还可以用于：
确定当前共识区块高度；若所述当前共识区块高度对第二阈值取余得到结果为0，则触发执行所述判断所述区块链系统10的当前网络状态是否符合条件。
可选地，所述共识装置800还可以包括共识处理模块850。
共识处理模块850用于：接收所述区块链系统10中的随从节点广播的准备消息，若所接收的准备消息达到第一预定数量，在所述区块链系统10中广播确认消息；接收所述区块链系统10中的随从节点广播的确认消息，若所接收的确认消息达到第二预定数量，将基于所述至少一个未验证交易中的合法交易的区块追加到本地区块链。
关于上述功能模块的具体实现过程可以参照上文对于相关方法步骤的详细阐述，在此不再赘述。
请参照图9，图9为本公开装置一个实施例的结构示意图，该实施例的装置可用于实现本公开上述各方法实施例。如图10所示，该共识装置900可以应用于区块链系统中的第一随从节点，可以理解，第一随从节点是区块链系统10中的任意一个随从节点，除此以外，区块链系统10还包括主节点。
共识装置900可以包括接收模块910、第二验证模块920以及验证结果比较模块930。
接收模块910用于接收所述主节点广播的交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值。
第二验证模块920用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系。
所述接收模块910还用于接收所述主节点广播的预准备消息，所述预准备消息包括所述主节点验证所述至少一个未验证交易得到的第二验证结果以及基于所述至少一个未验证交易得到的第二哈希值。
验证结果比较模块930用于基于所述对应关系查找与所述预准备消息中的第二哈希值对应的第一验证结果，若所述第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的至少一个随从节点进行共识处理。
可选地，区块链系统中还可以包括第二随从节点，第二随从节点是与第一随从节点不同的随充节点。所述第二验证模块920还可以用于：
在基于所述交易哈希列表无法查找到至少一个未验证交易的情况下，向所述主节点或者任意一个第二随从节点请求所述未验证交易。
可选地，所述预准备消息还包括不合法交易列表，所述合法交易列表包括所述至少一个未验证交易中的不合法交易。对应地，所述验证结果比较模块930还可以用于：
在基于所述对应关系无法查找到与所述预准备消息中的第二哈希值对应的第一验证结果的情况下，验证所述不合法交易列表得到第三验证结果；若所述第三验证结果与所述预准备消息中的第二验证结果相同，则在区块链系统中广播准备消息。
关于上述功能模块的详细实现过程，具体可以参照上文对相应方法步骤的详细阐述，在此不再赘述。
请参照图10，图10为本公开装置一个实施例的结构示意图，该实施例的装置可用于实现本公开上述各方法实施例。如图10所示，其中以区块链节点100为例示出了本公开实施例提供的一种区块链节点的硬件架构示意图。区块链节点100可以包括上述的共识装置800和900、处理器110以及计算机可读存储介质120。
处理器110和计算机可读存储介质120可以通过系统总线130进行通信。共识装置800和900包括的软件功能模块可以以机器可执行指令的形式存储于机器可读存储介质120中。处理器110通过调用并读取计算机可读存储介质120中的机器可执行指令，可以实现本公开实施例提供的共识方法。
需要说明的是，图10所示的架构仅为示意。本公开实施例提供的区块链节点100还可以包括比图10所示更多或更少的组件，比如，还可以包括通信单元，或者具有与图11所示完全不同的匹配值，本实施例对此没有限制。此外，图10所示组件可以通过硬件、软件或其组合来实现。
需要说明的，如图10所示的架构仅为一种可选实现方式，在具体实践过程中，可根据实际需要对上述图10的部件数量和类型进行选择、删减、增加或替换；在不同功能部件设置上，也可采用分离设置或集成设置等实现方式，例如GPU和CPU可分离设置或者可将GPU集成在CPU上，通信部可分离设置，也可集成设置在CPU或GPU上，等等。这些可替换的实施方式均落入本公开公开的保护范围。
特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，计算机程序包含用于执行流程图所示的方法的程序代码，程序代码可包括对应执行本公开实施例提供的方法步骤对应的指令，例如，在所述区块链系统中广播交易哈希列表，使所述区块链系统中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；基于所述交易哈希列表，查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；基于所述交易哈希列表，查找所述至少一个未验证交易，并验证所述至少一个未验证交易得到第二验证结果，以及，基于所述至少一个未验证交易，得到第二哈希值；在所述区块链系统中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点以及所述区块链系统中的随从节点进行共识处理。
本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
可能以许多方式来实现本公开的方法和装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根 据本公开的方法的程序的记录介质。本公开的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本公开限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本公开的原理和实际应用，并且使本领域的普通技术人员能够理解本公开从而设计适于特定用途的带有各种修改的各种实施例。

Claims (22)

  1. 一种共识方法，其特征在于，所述方法包括：
    在所述区块链系统中广播交易哈希列表，使所述区块链系统中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；基于所述交易哈希列表，查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
    基于所述交易哈希列表查找所述至少一个未验证交易，并验证所述至少一个未验证交易得到第二验证结果，以及，基于所述至少一个未验证交易得到第二哈希值；
    在所述区块链系统中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；
    若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点以及所述区块链系统中的随从节点进行共识处理。
  2. 根据权利要求1所述的共识方法，其特征在于，在所述区块链系统中广播交易哈希列表之前，所述方法还包括：
    获取所述区块链系统的当前网络状态，并判断所述当前网络状态是否符合预设条件；若是，则触发执行所述在所述区块链系统中广播交易哈希列表的步骤。
  3. 根据权利要求2所述的共识方法，其特征在于，所述判断所述区块链系统的当前网络状态是否符合预设条件，包括：
    获取当前累计的第一次数和第二次数，所述第一次数是所述区块链系统当前的视图更换总次数，所述第二次数是所述区块链系统在当前共识区块高度发生的视图更换次数；
    若所述第二次数与所述第一次数的比值不超过第一阈值，则确定所述当前网络状态符合所述预设条件，并清空所述当前累计的第一次数和第二次数。
  4. 根据权利要求3所述的共识方法，其特征在于，所述方法还包括：
    若所述区块链系统的当前网络状态不符合所述预设条件，则按照预设的实用拜占庭容错算法的共识流程进行共识处理，并清空所述当前累计的第一次数和第二次数。
  5. 根据权利要求2-4中任意一项所述的共识方法，其特征在于，在所述判断所述区块链系统的当前网络状态是否符合条件之前，所述方法还包括：
    确定当前共识区块高度；
    若所述当前共识区块高度对第二阈值取余得到结果为0，则触发执行所述判断所述区块链系统的当前网络状态是否符合条件的步骤。
  6. 根据权利要求1-4中任意一项所述的共识方法，其特征在于，所述第一验证结果包括所述随从节点对所述至少一个未验证交易中不合法交易的校验结果信息，所述第二验证结果包括所述主节点对所述至少一个未验证交易中不合法交易的校验结果信息。
  7. 根据权利要求1-4中任意一项所述的共识方法，其特征在于，在所述区块链系统中广播准备消息之后，所述方法还包括：
    接收所述区块链系统中的随从节点广播的准备消息，若所接收的准备消息达到第一预定数量，在所述区块链系统中广播确认消息；
    接收所述区块链系统中的随从节点广播的确认消息，若所接收的确认消息达到第二预定数量，将基于所述至少一个未验证交易中的合法交易的区块追加到本地区块链。
  8. 一种共识方法，其特征在于，应用于区块链系统中的第一随从节点，所述区块链系统还包括主节点；所述方法包括：
    接收所述主节点广播的交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
    基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
    接收所述主节点广播的预准备消息，所述预准备消息包括所述主节点验证所述至少一个未验证交易得到的第二验证结果以及基于所述至少一个未验证交易得到的第二哈希值；基于所述对应关系查找与所述预准备消息中的第二哈希值对应的第一验证结果；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点以及所述区块链系统中的至少一个随从节点进行共识处理。
  9. 根据权利要求8所述的共识方法，其特征在于，所述区块链系统还包括第二随从节点，所述第二随从节点是与所述第一随从节点不同的随从节点；所述方法还包括：
    若所述第一随从节点基于所述交易哈希列表无法查找到所述至少一个未验证交易，向所述主节点或者任意一个所述第二随从节点请求所述至少一个未验证交易。
  10. 根据权利要求8或9所述的方法，其特征在于，所述预准备消息还包括不合法交易列表，所述不合法交易列表包括所述至少一个未验证交易中的不合法交易；所述方法还包括：
    若基于所述对应关系无法查找到与所述预准备消息中的第二哈希值对应的第一验证结果，则验证所述不合法交易列表得到第三验证结果；
    若所述第三验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息。
  11. 一种共识装置，其特征在于，所述装置包括：
    广播模块，用于在所述区块链系统中广播交易哈希列表，使所述区块链系统中的随从节点接收所述交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值，基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
    第一验证模块，用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果，以及，基于所述至少一个未验证交易得到第二哈希值；
    所述广播模块，还用于在所述区块链系统中广播预准备消息，使所述随从节点基于所述对应关系查找与所述第二哈希值对应的第一验证结果，所述预准备消息包括所述第二验证结果以及所述第二哈希值；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的随从节点进行共识处理。
  12. 一种共识装置，其特征在于，应用于区块链系统中的第一随从节点，所述区块链系统还包括主节点；所述装置包括：接收模块，用于接收所述主节点广播的交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
    第二验证模块，用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第一验证结果，以及，基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
    所述接收模块，还用于接收所述主节点广播的预准备消息，所述预准备消息包括所述主节点验证所述至少一个未验证交易得到的第二验证结果以及基于所述至少一个未验证交易得到的第二哈希值；
    验证结果比较模块，用于基于所述对应关系查找与所述预准备消息中的第二哈希值对应的第一验证结果，若所述第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的至少一个随从节点进行共识处理。
  13. 一种区块链系统，其特征在于，包括主节点和第一随从节点，第一随从节点是所述区块链系统中的任意一个随从节点；
    所述主节点，用于在所述区块链系统中广播交易哈希列表，所述交易哈希列表包括至少一个未验证交易的哈希值；
    所述第一随从节点，用于接收所述交易哈希列表，基于所述交易哈希列表查找所述至少一个未验证交易；验证所述至少一个未验证交易得到第一验证结果；基于所述至少一个未验证交易得到第一哈希值，并保存所述第一验证结果和所述第一哈希值的对应关系；
    所述主节点，还用于基于所述交易哈希列表查找所述至少一个未验证交易，验证所述至少一个未验证交易得到第二验证结果；基于所述至少一个未验证交易得到第二哈希值，并在所述区块链系统中广播携带所述第二验证结果和所述第二哈希值的预准备消息；
    所述第一随从节点，还用于接收所述预准备消息，基于所述对应关系查找与所述第二哈希值对应的第一验证结果；若查找到的第一验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息，所述准备消息用于供所述主节点和所述区块链系统中的至少一个随从节点进行共识处理。
  14. 根据权利要求13所述的系统，其特征在于，在所述区块链系统中广播交易哈希列表之前，所述主节点还用于判断所述区块链系统的当前网络状态是否符合预设条件，若是，则触发执行所述在所述区块链系统中广播交易哈希列表的步骤。
  15. 根据权利要求14所述的系统，其特征在于，所述主节点通过以下方式判断所述区块链系统的当前网络状态是否符合预设条件：
    获取当前累计的第一次数和第二次数，所述第一次数是所述区块链系统当前的视图更换总次数，所述第二次数是所述区块链系统在当前共识区块高度发生的视图更换次数；若所述第二次数与所述第一次数的比值不超过第一阈值，则所述主节点确定所述当前网络状态符合所述预设条件。
  16. 根据权利要求15所述的系统，其特征在于，所述主节点还用于在所述区块链系统的当前网络状态不符合所述预设条件的情况下，清空所述当前累计的第一次数和第二次数。
  17. 根据权利要求14-16中任意一项所述的系统，其特征在于，在所述判断所述区块链系统的当前网络状态是否符合预设条件之前，所述主节点还用于：
    确定当前共识区块高度，判断所述当前共识区块高度对第二阈值取余的结果是否为0；若是，则触发执行所述判断所述区块链系统的当前网络状态是否符合预设条件的步骤。
  18. 根据权利要求13-16中任意一项所述的系统，其特征在于，所述第一验证结果包括所述第一随从节点对所述至少一个未验证交易中不合法交易的校验结果信息；所述第二验证结果包括所述主节点对所述至少一个未验证交易中不合法交易的校验结果信息。
  19. 根据权利要求18所述的系统，其特征在于，所述第一随从节点在所述区块链系统中广播准备消息的方式为：从所述至少一个未验证交易中剔除所述不合法交易，并针对所述至少一个未验证交易中的合法交易在所述区块链系统中广播所述准备消息；
    所述第一随从节点，还用于在广播所述准备消息后，等待并收集准备消息，若收集的准备消息达到第一预定数量，则在所述区块链系统中广播确认消息；等待并收集确认消息，若收集的确认消息达到第二预定数量，则确定所述区块链系统对所述至少一个未验证交易中的合法交易形成的区块达成共识；
    所述主节点，还用于从所述至少一个未验证交易中剔除所述不合法交易；在广播所述预准备消息后，等待并收集准备消息，若收集的准备消息达到所述第一预定数量，则在所述区块链系统中广播确认消息；等待并收集确认消息，若收集的确认消息达到所述第二预定数量，则确定所述区块链系统对所述至少一个未验证交易中的合法交易形成的区块达成共识。
  20. 根据权利要求13-16中任意一项所述的系统，其特征在于，所述区块链系统还包括 与所述第一随从节点不同的第二随从节点；
    所述第一随从节点还用于：在基于所述交易哈希列表无法查找到所述至少一个未验证交易时，向所述主节点或者任意一个所述第二随从节点请求所述至少一个未验证交易。
  21. 根据权利要求13-16中任意一项所述的系统，其特征在于，所述预准备消息还包括不合法交易列表，所述不合法交易列表包括所述至少一个未验证交易中的不合法交易；所述第一随从节点还用于：
    基于所述对应关系无法查找到与所述第二哈希值对应的第一验证结果时，验证所述不合法交易列表得到第三验证结果；若所述第三验证结果与所述第二验证结果相同，则在所述区块链系统中广播准备消息。
  22. 一种计算机可读存储介质，其上存储有程序代码，其特征在于，所述程序代码可被处理器调用执行以实现权利要求1-10中任意一项所述的方法。
PCT/CN2022/097230 2021-09-16 2022-06-06 共识方法、装置及区块链系统 WO2023040364A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111085505.9 2021-09-16
CN202111085505.9A CN113541968B (zh) 2021-09-16 2021-09-16 共识方法、装置及区块链系统

Publications (1)

Publication Number Publication Date
WO2023040364A1 true WO2023040364A1 (zh) 2023-03-23

Family

ID=78092714

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/097230 WO2023040364A1 (zh) 2021-09-16 2022-06-06 共识方法、装置及区块链系统

Country Status (2)

Country Link
CN (1) CN113541968B (zh)
WO (1) WO2023040364A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113541968B (zh) * 2021-09-16 2021-11-26 中国信息通信研究院 共识方法、装置及区块链系统
CN113850600B (zh) * 2021-12-01 2022-04-26 深圳前海微众银行股份有限公司 基于区块链的交易共识方法、装置、设备及存储介质
CN114928650B (zh) * 2022-04-26 2023-06-30 成都质数斯达克科技有限公司 一种区块链数据共识方法、装置、设备及可读存储介质
CN115481446A (zh) * 2022-08-31 2022-12-16 北京大学 一种泛在环境下的数字对象访问事务存证方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107392608A (zh) * 2017-07-11 2017-11-24 北京博晨技术有限公司 基于区块链系统的数字资产交易方法及区块链系统
US20170344987A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees
CN109379397A (zh) * 2018-08-31 2019-02-22 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN111522822A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备
CN111555858A (zh) * 2020-03-20 2020-08-18 北京邮电大学 一种基于块链式存储的实用拜占庭容错共识方法
CN113541968A (zh) * 2021-09-16 2021-10-22 中国信息通信研究院 共识方法、装置及区块链系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2724181C1 (ru) * 2018-11-07 2020-06-22 Алибаба Груп Холдинг Лимитед Упрощение консенсуса в цепочках блоков по принципу практичной отказоустойчивости на основе византийского соглашения и синхронизации узлов
WO2019101241A2 (en) * 2019-03-18 2019-05-31 Alibaba Group Holding Limited System and method for ending view change protocol

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170344987A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees
CN107392608A (zh) * 2017-07-11 2017-11-24 北京博晨技术有限公司 基于区块链系统的数字资产交易方法及区块链系统
CN109379397A (zh) * 2018-08-31 2019-02-22 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN111555858A (zh) * 2020-03-20 2020-08-18 北京邮电大学 一种基于块链式存储的实用拜占庭容错共识方法
CN111522822A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备
CN113541968A (zh) * 2021-09-16 2021-10-22 中国信息通信研究院 共识方法、装置及区块链系统

Also Published As

Publication number Publication date
CN113541968A (zh) 2021-10-22
CN113541968B (zh) 2021-11-26

Similar Documents

Publication Publication Date Title
WO2023040364A1 (zh) 共识方法、装置及区块链系统
CN109831514B (zh) 平行链共识方法、数据异常处理方法、设备和存储介质
CN110730225A (zh) 基于区块链的物联网的数据处理方法、物联网及存储介质
CN110263035A (zh) 基于区块链的数据存储、查询方法及装置和电子设备
CN108805570A (zh) 数据处理方法、装置及存储介质
CN107480014B (zh) 一种高可用设备切换方法及装置
US7801997B2 (en) Asynchronous interconnect protocol for a clustered DBMS
US20200218823A1 (en) Method and system for a distributed computing system
CN108683668B (zh) 内容分发网络中的资源校验方法、装置、存储介质及设备
CN110708196B (zh) 数据处理方法及装置
CN113568981B (zh) 一种交易数据处理方法、装置、设备以及介质
CN105069152B (zh) 数据处理方法及装置
Ding et al. Centiman: elastic, high performance optimistic concurrency control by watermarking
US11728976B1 (en) Systems and methods for efficiently serving blockchain requests using an optimized cache
EP4198861A1 (en) Information processing method and apparatus for blockchain network, and device and storage medium
CN111245897B (zh) 数据处理方法、装置、系统、存储介质及处理器
CN113760976A (zh) 业务的处理方法、装置、设备及存储介质
CN114422331B (zh) 容灾切换方法、装置及系统
CN116760860A (zh) 基于云计算的集群日志收集方法及相关设备
CN112436962B (zh) 区块链共识网络动态扩展方法、电子设备、系统及介质
CN112579591A (zh) 数据校验方法、装置、电子设备及计算机可读存储介质
CN113254526A (zh) 区块链共识方法、装置及系统
WO2024066005A1 (zh) 重放区块链交易的方法及装置
CN113760519B (zh) 分布式事务处理方法、装置、系统和电子设备
Ren et al. Improving the performance of blockchain sharding protocols with collaborative transaction verification

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

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

Country of ref document: EP

Kind code of ref document: A1