WO2022188831A1 - 一种基于区块链的区块共识方法以及相关设备 - Google Patents

一种基于区块链的区块共识方法以及相关设备 Download PDF

Info

Publication number
WO2022188831A1
WO2022188831A1 PCT/CN2022/080103 CN2022080103W WO2022188831A1 WO 2022188831 A1 WO2022188831 A1 WO 2022188831A1 CN 2022080103 W CN2022080103 W CN 2022080103W WO 2022188831 A1 WO2022188831 A1 WO 2022188831A1
Authority
WO
WIPO (PCT)
Prior art keywords
result
block
consensus
proposed
proposed block
Prior art date
Application number
PCT/CN2022/080103
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 WO2022188831A1 publication Critical patent/WO2022188831A1/zh
Priority to US18/071,271 priority Critical patent/US20230092484A1/en

Links

Images

Classifications

    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This application relates to the field of computer technology, and in particular, to block consensus based on blockchain.
  • tendermint a Byzantine fault-tolerant protocol
  • the tendermint consensus protocol before a proposed block enters the submission stage, it needs to go through two rounds of voting in the consensus network. Each round of voting needs to be approved by more than two-thirds of the consensus nodes in the consensus network to complete the block consensus. , enter the submission stage, and then the contract can be executed and the contract execution result can be obtained.
  • each consensus node needs to broadcast voting information in the consensus network during each round of voting. The network delay makes the consensus stage take a while, and the execution of the contract will also consume a lot of time. Therefore, the proposed block needs to complete the block consensus before executing the contract. The whole process takes a long time, resulting in low throughput of the blockchain.
  • the embodiments of the present application provide a blockchain-based block consensus method and related equipment, which can reduce the time-consuming of blockchain uploading and improve the throughput of the blockchain.
  • the embodiments of the present application provide a blockchain-based block consensus method, the method is executed by a computer device, and the method includes:
  • Execute the transaction data in the proposed block through the smart contract obtain the execution result of the target contract, and associate the block hash value of the proposed block with the execution result of the target contract and cache it in a temporary list; the temporary list includes blocks with a block height of M.
  • the target contract execution result mapped by the block hash value of the proposed block is obtained in the temporary list, and the proposed block and the target contract execution result are associated and stored in the blockchain.
  • One aspect of the embodiments of the present application provides a block chain-based block consensus device, the device is deployed on computer equipment, and the device includes:
  • the block verification module is used to obtain the proposed block whose block height is M and is generated in the Nth round, where both M and N are positive integers;
  • the contract execution module is used to execute the transaction data in the proposed block through the smart contract, obtain the execution result of the target contract, and associate the block hash value of the proposed block with the execution result of the target contract and cache it in a temporary list;
  • the temporary list includes The execution results of N contracts with a block height of M, and the execution results of N contracts include the execution results of the target contract;
  • the first consensus module is used to perform two rounds of consensus voting processing on the proposed block in parallel during the process of executing transaction data through the smart contract to obtain the first consensus result;
  • the first storage module is used to obtain the target contract execution result mapped by the block hash value of the proposed block in the temporary list if the first consensus result is the consensus pass result, and associate the proposed block with the target contract execution result stored in the blockchain.
  • An aspect of the embodiments of the present application provides a computer device, including: a processor and a memory;
  • the processor is connected to the memory, where the memory is used to store a computer program, and when the computer program is executed by the processor, the computer device executes the method provided by the embodiments of the present application.
  • One aspect of the embodiments of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program, where the computer program is adapted to be loaded and executed by a processor, so that a computer device having the processor executes the present application Methods provided by the examples.
  • embodiments of the present application provide a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the method provided by the embodiments of the present application.
  • the transaction data in the proposed block is executed through the smart contract, the execution result of the target contract is obtained, and the area of the proposed block is
  • the block hash value is associated with the execution result of the target contract and is cached in a temporary list; in the process of executing transaction data through the smart contract, two rounds of consensus voting are performed on the proposed block in parallel to obtain the first consensus result; if the first consensus result In order to pass the consensus result, the target contract execution result mapped by the block hash value of the proposed block is obtained in the temporary list, and the proposed block and the execution result of the target contract are associated and stored in the blockchain.
  • M and N are both positive integers.
  • the temporary list includes the execution results of N contracts with a block height of M, and the N contract execution results include the execution results of the target contract.
  • FIG. 1 is a schematic structural diagram of a blockchain node system provided by an embodiment of the present application
  • FIGS. 2a-2b are schematic diagrams of a block consensus scenario provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a blockchain-based block consensus method provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a scenario of block validity verification provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a scenario of contract execution provided by an embodiment of the present application.
  • 6a-6b are schematic diagrams of a consensus voting scenario provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a process of block consensus provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a contract execution result storage provided by an embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of a block consensus device provided by an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • FIG. 1 is a schematic structural diagram of a blockchain node system provided by an embodiment of the present application.
  • Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. , and can verify, store and update data at the same time.
  • the blockchain is essentially a decentralized database. Each node in the database stores an identical blockchain.
  • the blockchain network includes consensus nodes, which are responsible for the consensus of the entire blockchain network.
  • a block is a data packet that carries transaction data (that is, a transaction business) on the blockchain network. It is a data structure marked with a timestamp and the hash value of the previous block. Blocks are verified by the network's consensus mechanism and determine the transactions in the block.
  • a blockchain system may include a smart contract, and the smart contract may refer to a code that each node (including a consensus node) of the blockchain can understand and execute, and can execute arbitrary logic and obtain results.
  • the smart contract may refer to a code that each node (including a consensus node) of the blockchain can understand and execute, and can execute arbitrary logic and obtain results.
  • one or more smart contracts can be included in the blockchain, and these smart contracts can be distinguished by identification numbers (Identity document, ID) or names, and the transaction service request can carry the identification number or name of the smart contract, This specifies the smart contracts that the blockchain needs to run.
  • the blockchain node system shown in FIG. 1 may correspond to a blockchain network, and the blockchain network may include, but is not limited to, a blockchain network corresponding to a consortium chain.
  • the blockchain node system refers to a system for data sharing between blockchain nodes and blockchain nodes.
  • the blockchain node system may include multiple nodes, and multiple nodes may include, for example, node 10a, node 10b , node 10c, node 10d, ..., node 10n, where node 10a, node 10b, node 10c, node 10d..., node 10n can be collectively referred to as blockchain nodes.
  • each node can receive data sent by the outside world when it is working normally, and perform block chain processing based on the received data, and can also send data to the outside world.
  • there may be a data connection between each node there is a data connection between node 10a and node 10b, a data connection between node 10a and node 10c, and a data connection between node 10b and node 10c.
  • a data connection exists.
  • the blockchain network can realize the data connection between nodes based on the node identification.
  • each node in the blockchain network there is a corresponding node identification, and each of the above nodes can store other nodes that are connected to itself.
  • the node identifier of the node so that the acquired data or the generated block can be broadcast to other nodes according to the node identifiers of other nodes.
  • the node 10a can maintain a node identifier list as shown in Table 1.
  • the node identifier list Holds the node names and node IDs of other nodes:
  • the node identifier can be an Internet Protocol (IP) address between networks and any other information that can be used to identify a node in a blockchain network.
  • IP Internet Protocol
  • Table 1 only the IP address is used as an example for description.
  • node 10a may send information (eg, a block) to node 10b through node identification 117.116.189.145, and node 10b may determine through node identification 117.114.151.174 that the information was sent by node 10a.
  • connection mode does not limit the connection mode, and can be directly or indirectly connected through wired communication, or can be directly or indirectly connected through wireless communication, and can also be connected through other connection methods. No restrictions.
  • the block consensus method provided in the embodiments of the present application can be executed by computer equipment, and the computer equipment includes but is not limited to the above-mentioned consensus node (which may be a terminal or a server).
  • the above server may be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, Cloud servers for basic cloud computing services such as middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
  • the above-mentioned terminal may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto.
  • Consensus nodes in the blockchain node system participate in consensus, that is, consensus on blocks (including a batch of transactions), including generating proposed blocks and voting on proposed blocks; non-consensus nodes do not participate in consensus, but will help Propagating block and voting messages, synchronizing state with each other, etc.
  • one of the consensus nodes can act as a proposal node to generate a proposed block, and then send the proposed block to the blockchain node system according to the node identifiers of other consensus nodes in the blockchain node system. other consensus nodes in .
  • each consensus node After each consensus node receives the proposed block, it will verify the validity of the proposed block. If the proposed block is legal, the consensus node will execute the transaction data in the proposed block according to the smart contract, and obtain the execution result of the target contract. Then cache the execution result of the target contract; in the process of executing the transaction data through the smart contract, the consensus node will perform two rounds of consensus voting on the proposed block.
  • the consensus node If there is more than two-thirds consensus in the two rounds of consensus voting If the node votes in favor of the proposed block, the consensus is considered to be passed, and then the consensus node will add the proposed block and the execution result of the target contract to the blockchain it stores. It should be noted that the proposed node is also a consensus node, and two rounds of consensus voting processing are also required for the proposed block.
  • node 10a takes the proposed node as node 10a, node 10a generates a proposed block, and then node 10a broadcasts the proposed block to the remaining consensus nodes, that is, node 10b, node 10c and node 10d, and then consensus on the proposed block together Take an example to illustrate.
  • FIG. 2a-FIG. 2b are schematic diagrams of a block consensus scenario provided by an embodiment of the present application.
  • node 10a will monitor transactions of the entire blockchain network, then collect all transactions, and assemble and generate a proposal block 11 according to the transaction data corresponding to the collected transactions.
  • the node 10a will first broadcast the proposed block 11 to other consensus nodes in the consensus network, that is, the node 10b, the node 10c and the node 10d. All consensus nodes in the consensus network will conduct two rounds of consensus voting on the proposed block 11.
  • the process of the two rounds of consensus voting processing may be as follows: in the first round of consensus voting, each consensus node pre-votes on the proposed block 11 according to the legality of the proposed block 11, and obtains a pre-vote for the proposed block 11. Voting results, broadcast their pre-voting results to the remaining consensus nodes in the consensus network, and receive the pre-voting results for the proposed block 11 from the remaining consensus nodes; in the second round of consensus voting, each consensus node According to all the obtained pre-voting results, pre-commit the proposed block 11 (that is, perform consensus voting again based on the pre-voting results), obtain the pre-commit results for the proposed block 11, and broadcast its own pre-commit results to the consensus.
  • each pre-voting result may include a first approval result or a first disapproval result
  • the first approval result indicates that the consensus node determines that the proposed block 11 is legal
  • the first disapproval result indicates that the consensus node determines that the proposed block 11 is illegal .
  • each pre-submission result can include a second approval result or a second disapproval result
  • the second approval result means that among the pre-voting results obtained by the consensus nodes, more than two-thirds of the consensus nodes voted the first approval result
  • the second disapproval result means that among the pre-voting results obtained by the consensus nodes, more than one third of the consensus nodes voted for the first dissenting result.
  • the node 10b receives the proposed block 11 as an example for description. After the node 10b receives the proposed block 11, it will verify the validity of the proposed block 11, and obtain the validity verification result.
  • the validity verification is to verify whether the proposed block 11 is legal, such as whether it is generated by the proposed node 10a of the current round, whether the data structure and value in the proposed block 11 are reasonable, and so on.
  • the node 10b After the node 10b determines that the legality verification result of the proposed block 11 is a legal result, it will read the transaction data in the proposed block 11, and then execute the transaction data in the proposed block 11 through the smart contract to obtain the target contract execution result 12 , the target contract execution result 12 can only be written into the blockchain 14 together with the proposed block 11 after the consensus network reaches a consensus on the proposed block 11, so the node 10b will first store the target contract execution result 12 in the temporary list 13.
  • the temporary list 13 can also store contract execution results corresponding to other proposed blocks. Therefore, when writing the target contract execution result 12 into the temporary list, the target contract execution result 12 will also be the same as the block proposed for block 11.
  • the hash value is associated.
  • the target contract execution result 12 can be obtained through the block hash value of the proposed block 11, and then the proposed block 11 and the target contract execution result 12 are stored together to the blockchain 14. It should be noted that the consensus voting on the proposed block 11 and the execution of the transaction data in the proposed block 11 through the smart contract are performed simultaneously. After each consensus node in the consensus network receives the proposed block 11, it will perform the same operation as the node 10b, that is, the operation of contract execution and block consensus can be performed synchronously.
  • the specific process of contract execution and the block process of block consensus may refer to the description of the embodiment corresponding to FIG. 3 below.
  • FIG. 3 is a schematic flowchart of a blockchain-based block consensus method provided by an embodiment of the present application.
  • the method may be executed by a consensus node (for example, the node 10a, node 10b, node 10c, or node 10d corresponding to the above-mentioned FIG. 2a ), and the method is executed by a consensus node as an example for description below.
  • the blockchain-based block consensus method may at least include the following S101-S104:
  • the proposed block can also be called an alternative block or a block to be listed on the chain.
  • the proposed node monitors and collects all transactions of the entire network for a period of time, it assembles and generates transaction data containing each transaction. block.
  • the proposed node can be served by a consensus node in the consensus network, which is responsible for proposing candidate blocks and broadcasting them in the network.
  • the proposed block cannot be directly stored in the blockchain. It needs to be verified by the consensus network first. After the consensus is passed, it can be put on the chain and then connected to the previous block stored in the blockchain. Therefore, in simple terms, a blockchain is a chain of proposed blocks that are linked after consensus is passed.
  • the block height is the identifier of the block, which is used to measure the distance from a block to the first block in the blockchain. Through the block height, the position of a block on the chain can be accurately known. , which is equivalent to locating a coordinate for the block.
  • the block height of the first block is 0, the block height of the second block is 1... and so on, the block height of the fifth block is 4.
  • the proposed block is a new block to be added to the blockchain, and the corresponding block height is 5.
  • proposed blocks cannot be directly stored in the blockchain, and can only be added to the blockchain through block consensus.
  • the block consensus can be voting consensus, that is, after the proposed block in the consensus network generates the proposed block, the consensus node performs two rounds of consensus voting on the proposed block. For example, if the block consensus adopts the Tendermint consensus algorithm, then two-thirds or more of the consensus nodes in the two rounds of consensus voting have voted in favor of the proposed block, and it can be considered that the proposed block is in consensus. Passed; if there is one round of consensus voting and no two-thirds or more of the consensus nodes have voted in favor of the proposed block, it is considered that the consensus on the proposed block has not passed, and the proposed block Blocks cannot be stored on the blockchain.
  • the proposed block with a block height of 5 fails to reach consensus
  • a new consensus node will be elected in the consensus network to serve as the new proposal node, and then the new proposal node will generate a new proposal block, and the consensus network will Block consensus for new proposed blocks.
  • the block height of the new proposed block is still 5.
  • the proposed block that fails the consensus can be called the proposed block whose block height is 5 and is generated in the first round.
  • the proposed block is called the proposed block with block height 5 and generated in round 2. If the block height is 5 and the proposed block generated in the 2nd round still fails the consensus, the next proposed block is the block height 5 and the proposed block generated in the 3rd round.
  • the proposed nodes in each round are selected by the election algorithm (eg, by rotation), and are not necessarily fixed.
  • the consensus node after receiving the proposed block, the consensus node will verify the validity of the proposed block to obtain the validity verification result.
  • the validity verification may be the verification of the identity of the proposed node, or the verification of the content of the proposed block.
  • the consensus node performs legality verification on the proposed block to obtain the legality verification result, which may be to obtain transaction data in the proposed block, perform hash operation on the transaction data, and obtain the hash value to be verified;
  • the Merkle tree path in the proposed block performs hash operation on the hash value to be verified to obtain the root hash value of the tree to be verified; obtains the root hash value of the Merkle tree from the block header of the proposed block; if it is to be verified If the root hash value of the tree root is the same as the Merkle tree root hash value, the validity verification result of the proposed block is determined to be a legal result; if the root hash value of the tree to be verified is different from the Merkle tree root hash value, Then it is determined that the validity verification result of the proposed block is an illegal result.
  • the hash value also known as the information characteristic value or characteristic value
  • Merkle tree consists of a root node (root), a set of intermediate nodes and a set of leaf nodes (leaf).
  • the leaf node (leaf) contains the stored data or its hash value
  • the intermediate node is the hash value of the content of its two child nodes
  • the root node is also composed of the hash value of the content of its two child nodes. So Merkle tree is also called hash tree.
  • FIG. 4 is a schematic diagram of a block validity verification scenario provided by an embodiment of the present application.
  • the consensus node 40 (which can be any consensus node shown in FIG. 2 a ) receives the proposed block 41 , and the proposed block 41 includes a block header 411 (Header) and a block body 412 (Body ) in two parts.
  • the Merkle tree root hash value HX (1234) is stored in the block header 411.
  • the block header 411 can store basic data such as version number, timestamp and difficulty value, and can also store other relevant data.
  • the block body 412 stores a Merkle tree and transaction data 4121, wherein the transaction data 4121 includes transaction data Y1, transaction data Y2, transaction data Y3 and transaction data Y4. Among them, each transaction data corresponds to one transaction. In fact, a proposed block may contain transaction data corresponding to multiple transactions. As shown in FIG. 4 , the consensus node 40 first performs hash calculation on the transaction data Y1, transaction data Y2, transaction data Y3 and transaction data Y4, respectively, to obtain the to-be-verified hash value HY(1) and transaction data Y2 of the transaction data Y1.
  • the consensus node 40 compares the root hash value HY (1234) to be verified with the Merkle root hash value HX (1234) in the block header 411. If the two are the same, it can determine the legality of the proposed block 11.
  • the validity verification result is a legal result; otherwise, it is determined that the legality verification result of the proposed block 11 is an illegal result.
  • the consensus node performs legality verification on the proposed block to obtain the legality verification result, which may be to obtain transaction data in the proposed block; call the transaction verification function to verify the transaction data, and obtain the transaction verification result; If the transaction verification result is a valid result, the legality verification result of the proposed block is determined to be a legal result; if the transaction verification result is an invalid result, the legality verification result of the proposed block is determined to be an illegal result.
  • the transaction verification function is set according to the verification standard rules, such as the Check function.
  • the Check function you can verify whether the data structure syntax of the block is valid, whether the block size is within the length limit, whether the block timestamp is earlier than the verification time two hours in the future, and whether the signature data in the block is smaller than that of the signature operation. upper limit and so on. If the data format, size, signature, etc. of the block conform to the verification standard rules, the Check function can return 0, which is a valid transaction verification result. At this time, the consensus node will determine the legality verification result of the proposed block as a legal result. If calling The Check function returns other values, and the consensus node will determine that the validity verification result of the proposed block is an illegal result.
  • the consensus node performs legality verification on the proposed block to obtain the legality verification result, which can be obtained by obtaining the block hash value of the parent block of the proposed block in the blockchain as the target parent block.
  • Hash value obtain the hash value of the parent block from the block header of the proposed block as the hash value of the parent block to be verified; if the hash value of the parent block to be verified is the same as the hash value of the target parent block, then It is determined that the legality verification result of the proposed block is a legal result; if the hash value of the parent block to be verified is different from the hash value of the target parent block, the legality verification result of the proposed block is determined to be an illegal result.
  • the block hash value is also the identifier of the block.
  • the block hash value is calculated by the hash algorithm after splicing the three fields of the parent block hash value, block content, and block creation time.
  • the parent block is the previous block of a block in the blockchain.
  • the parent block of a block with a block height of 5 is a block with a block height of 4.
  • the consensus node performs legality verification on the proposed block to obtain the legality verification result, which may be to obtain the signature data associated with the proposed block; obtain the public key of the proposed node, verify the signature data through the public key, and obtain Signature verification result; if the signature verification result is successful, the validity verification result of the proposed block is determined to be a legal result; if the signature verification result is a signature verification failure, the legality verification result of the proposed block is determined to be an illegal result.
  • the signature data belonging to the successful signature verification is obtained by the proposal node signing the proposal block with the private key it owns.
  • the public key and the private key are commonly known as asymmetric encryption methods.
  • the public key is for everyone, that is to say, other consensus nodes can obtain the public key of the proposed node; the private key is private, and other consensus nodes can obtain the public key of the proposed node. Unable to obtain the private key of the proposed node.
  • the proposed node uses its own private key to process the proposed block. Since the private key is only owned by the proposed node, a file that cannot be generated by other nodes is generated, and a digital signature is formed. In a round of consensus, the consensus node can know who is the proposed node to generate the proposed block in this round, and obtain the public key of the proposed node, and then use the public key to decrypt the signature data, that is, to verify the signature.
  • the signature data is sent by the proposal node, and the proposal block associated with the signature data is the proposal block generated by the proposal node of this round of consensus, not the proposal block received from other nodes by mistake or other illegal block, it can be determined that the proposed block has passed the legality verification; otherwise, it can be determined that the proposed block has failed the legality verification.
  • S102 Execute the transaction data in the proposed block through a smart contract to obtain the execution result of the target contract, and associate and cache the block hash value of the proposed block with the execution result of the target contract in a temporary list.
  • the implementation method of S102 may be that if the legality verification result is a legal result, the transaction data in the proposed block is executed through the smart contract to obtain the target contract execution result.
  • the consensus node After the consensus node obtains the proposed block and verifies that the proposed block is legal, it will call the transaction execution function in the smart contract used to execute the transaction data, and then obtain the read data for the transaction data through the transaction execution function, and then pass the transaction execution function. Read the data and transaction data to execute the transaction execution function to get the execution result of the target contract. Then, the consensus node will obtain the block hash value of the proposed block, and associate the block hash value of the proposed block with the execution result of the target contract and cache it in a temporary list.
  • a smart contract is a computer protocol designed to disseminate, verify or execute a contract in an information-based manner.
  • a smart contract is a code that each node of the blockchain can understand and execute, and can execute arbitrary logic and get results.
  • smart contracts are managed and tested through transactions on the blockchain.
  • the transaction data corresponding to each transaction is equivalent to a Remote Procedure Call (RPC) request to the blockchain system.
  • RPC Remote Procedure Call
  • the blockchain is equivalent to an operating system that provides a running environment.
  • the blockchain can contain multiple contracts, which are distinguished by the contract account number (Identity, ID), identification number or name.
  • FIG. 5 is a schematic diagram of a contract execution scenario provided by an embodiment of the present application.
  • the consensus node 50 (which can be any consensus node shown in FIG. 2 a ) obtains the proposed block 51 , wherein the proposed block 51 can be the block to be consensus generated by the proposed node in the consensus network .
  • the block body of the proposed block 51 includes transaction data 511, and the transaction data 511 may include transaction 1, transaction 2, transaction 3, ..., transaction n, and the function name corresponding to each transaction.
  • the consensus node 50 can call the transaction execution function in the smart contract 52 for executing transaction data according to the function name. As shown in FIG.
  • the function that executes transaction 1 is transaction execution function 1
  • the function that executes transaction 2 is transaction execution function 2.
  • the function that executes transaction 3 is transaction execution function 3, ...
  • the function that executes transaction n is transaction execution function n.
  • functions including functions corresponding to function name 1, function name 2, function name 3, ..., function name n respectively
  • functions can be called under the same smart contract or under different smart contracts.
  • the function corresponding to function name 1 that is, transaction execution function 1
  • the function corresponding to function name 2 that is, transaction execution function 2
  • the function corresponding to function name 3 that is, transaction execution function 3
  • the function corresponding to the function name n is called in the smart contract V.
  • the consensus node 50 may acquire historical transaction data for the transaction data according to the transaction execution function, and determine the historical transaction data as read data.
  • the read data 1 of transaction 1 is obtained through transaction execution function 1
  • the read data 2 of transaction 2 is obtained through transaction execution function 2
  • the read data 3 of transaction 3 is obtained through transaction execution function 3, ..., Obtain the read data n of transaction n through transaction execution function n.
  • transaction 1 is that Party A transfers 10 yuan to Party B through its own account
  • transaction execution function 1 is the transfer execution function, which reads data 1, that is, the historical transaction data of transaction 1 is the remaining 20 yuan in Party A's account.
  • transaction 1 simply takes transaction 1 as an example to describe the relationship between transaction data, read data and transaction execution results. Therefore, according to transaction 2, read data 2 and transaction execution function 2, the transaction execution result 2 of transaction 2 can be obtained. According to Transaction 3, read data 3 and transaction execution function 3, the transaction execution result 3 of transaction 3 can be obtained, ..., according to transaction n, read data n and transaction execution function n, the transaction execution result n of transaction n can be obtained.
  • the consensus node will use transaction execution result 1, transaction execution result 2, transaction execution result 3, ..., transaction execution result n as the target contract execution result, and then establish an association relationship between the target contract execution result and the block hash value of the proposed block , which caches the association in a temporary list.
  • the temporary list may also contain contract execution results corresponding to other proposed blocks.
  • the proposed blocks generated in the first N rounds have multiple less-proposed blocks that have executed transaction data. How many contract execution results can be obtained. If the proposed blocks generated in the first N rounds have all executed transaction data, the temporary list includes the execution results of N contracts with a block height of M, and the N contract execution results include the execution results of the target contract.
  • the contract execution and the two rounds of consensus voting processing are executed in parallel, that is, when the consensus node starts to vote on the proposed block, the transaction data is simultaneously executed through the smart contract.
  • the consensus nodes pre-vote the proposed block according to the validity verification result of the proposed block, and obtain the pre-voting result; Pre-commit processing to get the first consensus result.
  • the consensus nodes pre-vote the proposed blocks according to the validity verification results of the proposed blocks, and obtain the pre-voting results.
  • the validity of the block the consensus node will determine the first pre-voting result as the first approval result for the proposed block; broadcast the first pre-voting result to multiple target consensus nodes; Second pre-voting results; according to the first pre-voting results and multiple second pre-voting results, determine the first number of affirmative votes and the first number of negative votes for the proposed block; if the first number of affirmative votes exceeds the first pre-voting threshold , it is determined that the pre-voting result is a successful pre-voting result; if the number of the first negative votes exceeds the second pre-voting threshold, the pre-voting result is determined to be a pre-voting failure result.
  • the first pre-voting threshold may be two-thirds of the total number of consensus nodes in the consensus network. For example, if the total number of consensus nodes is 30, the first pre-voting threshold may be 20; the second pre-voting threshold may be the consensus network. 1/3 of the total number of consensus nodes, for example, if the total number of consensus nodes is 30, the second pre-voting threshold can be 10.
  • the proposed block is pre-submitted according to the pre-voting result, and the first consensus result is obtained.
  • the first pre-commit result is determined as the second approval result for the proposed block; otherwise, the first pre-commit result is determined as the second objection result for the proposed block; then the consensus node will broadcast the first pre-commit result to up to target consensus nodes; at the same time, the consensus node will receive the second pre-commit results sent by multiple target consensus nodes respectively; according to the first pre-commit results and multiple second pre-commit results, determine the number of second approval votes for the proposed block and the second number of negative votes; if the number of second positive votes exceeds the first pre-submission threshold, the first consensus result is determined as the consensus result; if the number of second negative votes exceeds the second pre-submission threshold, the first consensus result is determined to be consensus Failed results.
  • the first pre-commit threshold may be two-thirds of the total number of consensus nodes in the consensus network. For example, if the total number of consensus nodes is 30, the first pre-commit threshold may be 20; the second pre-commit threshold may be the consensus network. 1/3 of the total number of consensus nodes, for example, if the total number of consensus nodes is 30, the second pre-commit threshold can be 10.
  • FIG. 6a-FIG. 6b are schematic diagrams of a consensus voting scenario provided by an embodiment of the present application.
  • the consensus node 60 (which may be the node 10a, node 10b, node 10c or node 10d shown in FIG. 2a)
  • the consensus node 60 after verifying that the proposed block is legal, the consensus node 60 performs a first check on the proposed block. Round of consensus voting, that is, pre-voting processing. Because the validity verification result of the proposed block is a legal result, the consensus node 60 determines the first pre-vote result for the proposed block as the first approval result, and then broadcasts the first approval result to other consensus nodes in the consensus network.
  • the proposal node After the proposal node generates the proposed block, it will be broadcast to all consensus nodes in the consensus network. Therefore, except for the consensus node 60, the remaining consensus nodes will execute the same proposal as the consensus node 60 after receiving the proposed block.
  • Blocks are processed by consensus. That is to say, the consensus node 61, the consensus node 62 and the consensus node 63 will also conduct the first round of consensus voting on the proposed block, and then broadcast their pre-voting results. For the consensus node 60, the consensus node 61, the consensus node 62 Or the pre-voting result of the consensus node 63 is the second pre-voting result. As shown in FIG.
  • the consensus node 60 will receive the first approval result of the consensus node 61, the first disapproval result of the consensus node 62 and the first approval result of the consensus node 63.
  • the first objection result may be because the consensus node 62 has not received the proposed block due to a network problem, or the consensus node 62 determines that the validity verification result of the proposed block is illegal, thereby determining the pre-voting result.
  • the consensus node 60 counts the first number of affirmative votes as 3 and the first number of negative votes as 1. Obviously, the first number of affirmative votes is greater than Two-thirds of the number of all consensus nodes in the consensus network, the consensus node 60 will determine that the pre-voting is successful.
  • the consensus node 60 determines that the pre-voting is successful, it will enter the second round of consensus voting, that is, pre-commit processing.
  • the pre-commit processing is actually carried out according to the pre-voting result of the consensus node.
  • the pre-voting result of the consensus node 60 is the successful result of the pre-voting.
  • the consensus node 60 will determine the first pre-commit result as the second approval result, and then broadcast it to the consensus. The rest of the consensus nodes in the network. Likewise, the consensus node 60 will receive the second pre-commit results of the remaining consensus nodes.
  • the second pre-submission result may be the second approval result or the second objection result. As shown in Fig.
  • the consensus node 61 may determine that the pre-voting result is a pre-voting failure due to network problems or broadcast transmission problems, so that the second pre-commit result is determined as the second objection result, but the consensus node 62, consensus node 63 and The consensus nodes 61 all determine that the pre-voting result is a successful pre-voting, so they are all second approval results.
  • the consensus node 60 can determine the second approval for the proposed block according to the first pre-commit result and the received second pre-commit result. The number of votes is 3 and the number of second negative votes is 1. Therefore, the consensus node 60 will determine that the proposed block has passed the consensus.
  • the consensus node 60 may receive the second pre-voting results of the remaining consensus nodes asynchronously.
  • the second pre-voting result sent from the consensus node 61 the same is true for the second pre-submission result. Therefore, during two rounds of consensus voting processing, the consensus nodes can continue to count the number of affirmative votes or negative votes according to the voting results that have been obtained. As long as the number of affirmative votes reaches two-thirds of the total number of consensus nodes, the The next action can be taken without waiting for the voting results of all consensus nodes to be received.
  • the consensus node can obtain the mapped target contract execution result in the temporary list according to the block hash value of the proposed block, and then associate the proposed block and the target contract execution result to the blockchain. middle.
  • the consensus node obtains the proposed block, and then verifies that the proposed block is legal, executes the contract in the proposed block and performs consensus voting on the proposed block at the same time, and executes the contract.
  • the contract execution result is cached in the temporary list. If the consensus result for the proposed block is the consensus result, the target contract execution result cached in the temporary list is obtained and stored in the blockchain together with the proposed block.
  • FIG. 7 is a schematic diagram of a block consensus process provided by the implementation of this application.
  • the Proposer node begins to monitor and collect all transactions in the entire network. After a period of time, a new block is assembled and broadcast to the entire network. This is the proposal block.
  • all the consensus (validator) nodes of the whole network receive the proposed block, they start to read all the transaction data in the proposed block and verify them one by one. If there is no problem, confirm that the proposed block is a valid block. , and then send out a Prevote Block, indicating that you agree with the proposed block and cast a positive vote.
  • the consensus node starts to execute the transaction data in the proposed block through the smart contract, that is, the Execute contract (Execute contract), and cache the obtained execution result of the target contract; if the consensus node does not receive the proposed block, or if the consensus node finds an illegal transaction in the proposed block, it confirms that the proposed block is an invalid block. Then, a Prevote Nil message is sent to express opposition to the proposed block and cast a negative vote.
  • these pre-vote messages will be broadcast to all consensus nodes, so each consensus node will not only send a pre-vote message, but also collect other people's pre-vote messages.
  • the consensus node finds that the number of consent votes in the collected pre-voting message exceeds 2/3 of the total number of consensus nodes (pre-vote exceeds 2/3 of the consent votes), it will issue a pre-commit block (Precommit Block) pre-commit information , this is the second stage of voting.
  • Precommit Block pre-commit information
  • each consensus node will not only send a pre-commit message, but also collect others' pre-commit messages.
  • the consensus node can write the proposed block and the cached target contract execution result into the local blockchain, append it to the end, that is, complete the commit (Commit), and at the same time increase the block height by one to get a new height (New Height), Entering the next round (round), the proposal node begins to propose new blocks corresponding to the new heights.
  • the consensus node will not write the proposed block and the cached target contract execution result into the local blockchain, and the submission fails.
  • the block height will not be Change, enter the next round (ie, a new round in Figure 7), and the proposal node begins to propose a new block corresponding to the block height.
  • a round includes 4 stages (steps): Propose, Execute contract, Prevote and Precommit. It is understandable that the Execute contract step is executed in parallel with the Prevote and Precommit steps.
  • the entire block consensus process consists of one or more rounds, plus two special stages: Commit and NewHeight, as follows:
  • the consensus node will still conduct two rounds of consensus voting on the proposed block to obtain a second consensus. Result: If the second consensus result is the consensus result, the proposed block that has been stored in the blockchain with a block height of M and the target contract execution result corresponding to the proposed block will be synchronized from the completed consensus node. Among them, the completed consensus node is the target consensus node that successfully stores the proposed block and the execution result of the target contract in the blockchain.
  • the consensus node in a round, does not receive the proposed block in time due to network problems and other problems, and the consensus node will naturally not wait all the time. Therefore, within the verification time threshold, the consensus node does not obtain the proposed block.
  • the block height is M and the proposed block is generated in the Nth round, a temporary empty block will be constructed, and then two rounds of consensus voting will be performed on the temporary empty block to obtain the third consensus result. If the third consensus result is the consensus result, and there is no transaction data in the empty block, the consensus node will synchronize the proposed block with block height M stored in the blockchain from the completed consensus node, and the proposed block The execution result of the target contract corresponding to the block.
  • the completed consensus node is the target consensus node that successfully stores the proposed block and the execution result of the target contract in the blockchain.
  • the execution of the contract is executed when it is detected that the proposed block is a valid block, that is, the execution of the contract can be carried out while broadcasting the pre-voting information and the pre-submission information.
  • the secondary broadcast time is equivalent, it is equivalent to saving the time of contract execution and greatly improving the performance of the blockchain.
  • FIG. 8 is a schematic diagram of a contract execution result storage provided by an embodiment of the present application.
  • the consensus node executes the contract in the proposed block that may not be submitted in advance, so the execution result cannot be directly saved in the database when executing the contract, but the temporary execution result needs to be cached, such as saving In a temporary list in memory, or in a temporary list stored in a temporary database, etc.
  • block H3/R1 refers to the proposed block with block height 3 and generated in the first round
  • block H3/R2 refers to the proposed block with block height 3 and generated in the second round block
  • block H3/R3 refers to the proposed block with block height 3 and generated in the third round.
  • the consensus node will first cache the contract execution result in the temporary list of the memory. It is understandable that the temporary list may store the contract execution results corresponding to multiple proposed blocks.
  • KV storage Key-Value storage
  • key is the number of the stored value
  • This temporary contract execution result can be saved with the block hash of the proposed block as the key (unique mark). Then, when the consensus node submits the proposed block, it only needs to find out the contract execution result corresponding to the block hash value of the submitted proposed block, and save it in the ledger.
  • the consensus node after submitting the final proposed block with block height M, the consensus node can delete the execution results of N contracts with block height M in the temporary list.
  • the consensus node can obtain the total number of execution results of all contracts in the temporary list, and if the total number is greater than or equal to the storage quantity threshold, delete all contract execution results in the temporary list.
  • all contract execution results include contract execution results corresponding to one or more block heights respectively.
  • the block hash value is used to identify the contract execution result corresponding to the proposed block. Even if there are multiple corresponding proposed blocks in the same block height, when the final proposed block is finally submitted, it is also possible to According to the block hash value of the final proposed block, the temporarily cached contract execution result is found, and there will be no storage confusion. At the same time, deleting the cached contract execution result after submitting the proposed block can release the memory and prompt the performance of the blockchain.
  • FIG. 9 is a schematic structural diagram of a block consensus apparatus provided by an embodiment of the present application.
  • the block consensus apparatus 1 may include: a block verification module 11 , a contract execution module 12 , a first consensus module 13 and a first storage module 14 .
  • the block verification module 11 is used to obtain the proposed block whose block height is M and is generated in the Nth round, where M and N are both positive integers;
  • the contract execution module 12 is used to execute the transaction data in the proposed block through the smart contract, obtain the execution result of the target contract, and associate and cache the block hash value of the proposed block with the execution result of the target contract in a temporary list;
  • the temporary list includes The execution results of N contracts with a block height of M, and the execution results of N contracts include the execution results of the target contract;
  • the first consensus module 13 is used to perform two rounds of consensus voting processing on the proposed block in parallel during the process of executing the transaction data through the smart contract to obtain the first consensus result;
  • the first storage module 14 is configured to obtain the target contract execution result mapped by the block hash value of the proposed block in the temporary list if the first consensus result is a consensus pass result, and store the proposed block and the target contract execution result The association is stored in the blockchain.
  • the specific function implementation of the block verification module 11 , the contract execution module 12 , the first consensus module 13 and the first storage module 14 may refer to S101 - S104 in the corresponding embodiment of FIG. 3 , which will not be repeated here.
  • the block verification module 11 is also used for:
  • the contract execution module 12 is used for:
  • the transaction data in the proposed block is executed through the smart contract to obtain the execution result of the target contract.
  • the temporary list stores the block hash value of the proposed block and the execution result of the target contract through key-value pairs, and the block hash value of the proposed block is the key in the key-value pair, and the execution result of the target contract is the value in the key-value pair.
  • the block verification module 11 may include: a hash operation unit 1111 , a root hash acquisition unit 1112 and a first verification unit 1113 .
  • the hash operation unit 1111 is used to obtain the transaction data in the proposed block, perform hash operation on the transaction data, and obtain the hash value to be verified;
  • the hash operation unit 1111 is further configured to perform hash operation on the hash value to be verified according to the Merkle tree path in the proposed block to obtain the root hash value of the tree to be verified;
  • the root hash obtaining unit 1112 is used to obtain the Merkle tree root hash value from the block header of the proposed block;
  • the first verification unit 1113 is used to determine that the validity verification result of the proposed block is a legal result if the hash value of the root of the tree to be verified is the same as the hash value of the root of the Merkle tree;
  • the first verification unit 1113 is further configured to determine that the validity verification result of the proposed block is an illegal result if the hash value of the root of the tree to be verified is different from the hash value of the root of the Merkle tree.
  • the root hash obtaining unit 1112 and the first verification unit 1113 please refer to the steps of performing legality verification on the proposed block to obtain the legality verification result in the corresponding embodiment of FIG. 3, No further description is given here.
  • the block verification module 11 may include: a transaction acquisition unit 1121 , a transaction verification unit 1122 and a second verification unit 1123 .
  • transaction acquisition unit 1121 used to acquire transaction data in the proposed block
  • the transaction verification unit 1122 is used to call the transaction verification function to verify the transaction data and obtain the transaction verification result;
  • the second verification unit 1123 is configured to determine that the legality verification result of the proposed block is a legal result if the transaction verification result is a valid result;
  • the second verification unit 1123 is further configured to determine that the validity verification result of the proposed block is an illegal result if the transaction verification result is an invalid result.
  • the specific function implementation of the transaction acquisition unit 1121, the transaction verification unit 1122 and the second verification unit 1123 can be referred to the steps in the corresponding embodiment of FIG. Repeat.
  • the block verification module 11 may include: a first hash acquisition unit 1131 , a second hash acquisition unit 1132 and a third verification unit 1133 .
  • the first hash obtaining unit 1131 is used to obtain the block hash value of the parent block of the proposed block in the blockchain as the target parent block hash value;
  • the second hash obtaining unit 1132 is further configured to obtain the parent block hash value from the block header of the proposed block as the parent block hash value to be verified;
  • the third verification unit 1133 is configured to determine that the validity verification result of the proposed block is a legal result if the hash value of the parent block to be verified is the same as the hash value of the target parent block;
  • the third verification unit 1133 is further configured to determine that the validity verification result of the proposed block is an illegal result if the hash value of the parent block to be verified is different from the hash value of the target parent block.
  • the block verification module 11 may include: a signature acquisition unit 1141 , a signature verification unit 1142 and a fourth verification unit 1143 .
  • Signature acquisition unit 1141 used to acquire signature data associated with the proposed block
  • the signature verification unit 1142 is used to obtain the public key of the proposed node, verify the signature data through the public key, and obtain the signature verification result;
  • the fourth verification unit 1143 is used to determine that the validity verification result of the proposed block is a legal result if the signature verification result is that the signature verification is successful; the signature data belonging to the successful signature verification is the private key pair owned by the proposal node through the verification.
  • the proposed block is obtained by signing; the proposed block associated with the signature data that is successfully verified is generated by the proposed node;
  • the fourth verification unit 1143 is further configured to determine that the validity verification result of the proposed block is an illegal result if the signature verification result is that the signature verification fails.
  • the specific function implementation manner of the signature acquisition unit 1141, the signature verification unit 1142 and the fourth verification unit 1143 can be referred to the steps in the corresponding embodiment of FIG. Repeat.
  • the contract execution module 12 may include: a first obtaining unit 121 , a second obtaining unit 122 , a result obtaining unit 123 and a cache unit 124 .
  • the first obtaining unit 121 is used for obtaining transaction data in the proposed block, and calling the transaction execution function in the smart contract for executing the transaction data;
  • the second obtaining unit 122 is configured to obtain the read data for the transaction data according to the transaction execution function
  • the result obtaining unit 123 is configured to execute the transaction execution function according to the read data and the transaction data, and obtain the target contract execution result of the transaction data;
  • the cache unit 124 is configured to cache the block hash value of the proposed block in association with the execution result of the target contract into a temporary list.
  • the specific function implementation manner of the first obtaining unit 121 , the second obtaining unit 122 , the result obtaining unit 123 and the caching unit 124 may refer to S102 in the corresponding embodiment of FIG. 3 , and details are not repeated here.
  • the first consensus module 13 may include: a pre-voting unit 131 and a pre-commit unit 132 .
  • the pre-voting unit 131 is configured to perform pre-voting processing on the proposed block according to the validity verification result of the proposed block in the first round of consensus voting, and obtain the pre-voting result;
  • the pre-submission unit 132 is configured to perform pre-submission processing on the proposed block according to the pre-voting result in the second round of consensus voting to obtain the first consensus result.
  • the specific function implementation manner of the pre-voting unit 131 and the pre-submission unit 132 may refer to S103 in the corresponding embodiment of FIG. 3 , which will not be repeated here.
  • the pre-voting unit 131 may include: a first determining sub-unit 1311 , a first broadcasting sub-unit 1312 , a first receiving sub-unit 1313 , a first counting sub-unit 1314 and a pre-voting processing sub-unit 1315 .
  • the first determination subunit 1311 is used to determine the first pre-voting result as the first approval result for the proposed block according to the legal result in the first round of consensus voting;
  • the first broadcasting subunit 1312 is used for broadcasting the first pre-voting result to multiple target consensus nodes;
  • the first receiving subunit 1313 is used to receive the second pre-voting results respectively sent by multiple target consensus nodes; there is a first approval result for the proposed block in the multiple second pre-voting results, or multiple second pre-voting results There is a first objection to the proposed block in the result;
  • the first statistical subunit 1314 is configured to determine the first number of affirmative votes and the first number of negative votes for the proposed block according to the first pre-voting result and a plurality of second pre-voting results;
  • the pre-voting processing subunit 1315 is used to determine that the pre-voting result is a successful pre-voting result if the number of the first affirmative votes exceeds the first pre-voting threshold;
  • the pre-voting processing subunit 1315 is further configured to determine that the pre-voting result is a pre-voting failure result if the number of the first negative votes exceeds the second pre-voting threshold.
  • the specific function implementation manner of the first determining subunit 1311, the first broadcasting subunit 1312, the first receiving subunit 1313, the first statistics subunit 1314 and the pre-voting processing subunit 1315 can be referred to in the corresponding embodiment of FIG. 6a. The specific description will not be repeated here.
  • the pre-submission unit 132 may include: a second determination sub-unit 1321 , a second broadcast sub-unit 1322 , a second receiving sub-unit 1323 , a second statistics sub-unit 1324 and a pre-submission processing sub-unit 1325 .
  • the second determination subunit 1321 is configured to determine the first pre-submission result as the second approval result for the proposed block if the pre-voting result is a successful pre-voting result;
  • the second determination subunit 1321 is further configured to determine the first pre-submission result as the second objection result for the proposed block if the pre-voting result is the pre-voting failure result;
  • the second broadcasting subunit 1322 is configured to broadcast the first pre-submission result to multiple target consensus nodes
  • the second receiving subunit 1323 is configured to receive the second pre-commit results respectively sent by the multiple target consensus nodes; there is a second approval result for the proposed block in the multiple second pre-commit results, or at least the second two pre-commit results. There is a second objection to the proposed block in the commit result;
  • the second statistics subunit 1324 is configured to determine the second number of positive votes and the second number of negative votes for the proposed block according to the first pre-submission result and a plurality of second pre-submission results;
  • the pre-submission processing subunit 1325 is configured to determine that the first consensus result is a consensus approval result if the number of the second affirmative votes exceeds the first pre-submission threshold;
  • the pre-submission processing subunit 1325 is further configured to determine that the first consensus result is a consensus failure result if the number of second negative votes exceeds the second pre-submission threshold.
  • the specific function implementation manner of the second determination subunit 1321, the second broadcast subunit 1322, the second reception subunit 1323, the second statistics subunit 1324 and the pre-submission processing subunit 1325 can be referred to in the corresponding embodiment of FIG. 6b. The specific description will not be repeated here.
  • the block consensus apparatus 1 may further include: a second consensus module 15 and a second storage module 16 .
  • the second consensus module 15 is configured to perform two rounds of consensus voting processing on the proposed block if the result of the legality verification of the proposed block is an illegal result to obtain a second consensus result;
  • the second storage module 16 is used for synchronizing the proposed block whose block height is M in the blockchain and the target corresponding to the proposed block from the completed consensus node if the second consensus result is the consensus result.
  • Contract execution result; the completed consensus node is the target consensus node that successfully stores the proposed block and the target contract execution result in the blockchain.
  • the specific function implementation manner of the second consensus module 15 and the second storage module 16 may refer to the specific description in the corresponding embodiment of FIG. 7 , which will not be repeated here.
  • the block verification module 11 may include: a successful acquisition unit 1151 .
  • the successful acquisition unit 1151 is configured to verify the validity of the proposed block if a proposed block whose block height is M and is generated in the Nth round is acquired within the verification time threshold.
  • the block consensus apparatus 1 may further include: a failure acquisition module 17 , a third consensus module 18 and a third storage module 19 .
  • the failure acquisition module 17 is used for constructing a temporary empty block if the proposed block whose block height is M and is generated in the Nth round is not acquired within the verification time threshold;
  • the third consensus module 18 is used to perform two rounds of consensus voting processing on temporary empty blocks to obtain a third consensus result
  • the third storage module 19 is configured to synchronize the proposed block whose block height is M in the blockchain and the target corresponding to the proposed block from the completed consensus node if the third consensus result is the consensus result.
  • Contract execution result; the completed consensus node is the target consensus node that successfully stores the proposed block and the target contract execution result in the blockchain.
  • the specific function implementation manner of the successful acquisition unit 1151 , the failure acquisition module 17 , the third consensus module 18 and the third storage module 19 may refer to the specific description in the corresponding embodiment of FIG. 7 , and will not be repeated here.
  • the block consensus apparatus 1 may further include: a first deletion module 110 and a second deletion module 111 .
  • the first deletion module 110 is used to delete the execution results of N contracts whose block height is M in the temporary list;
  • the second deletion module 111 is configured to obtain the total number of all contract execution results in the temporary list. If the total number is greater than or equal to the storage number threshold, delete all contract execution results in the temporary list; all contract execution results include one or more The contract execution results corresponding to the block heights.
  • the specific function implementation manner of the first deletion module 110 and the second deletion module 111 can be referred to the specific description in the corresponding embodiment of FIG. 8 , which will not be repeated here.
  • FIG. 10 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the block consensus apparatus 1 in the embodiment corresponding to FIG. 9 can be applied to the above-mentioned computer equipment 1000.
  • the above-mentioned computer equipment 1000 may include: a processor 1001, a network interface 1004 and a memory 1005.
  • the above-mentioned computer Device 1000 also includes a user interface 1003 , and at least one communication bus 1002 .
  • the communication bus 1002 is used to realize the connection and communication between these components.
  • the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may include a standard wired interface and a wireless interface (eg, a WI-FI interface).
  • the memory 1005 may be high-speed RAM memory or non-volatile memory, such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001 .
  • the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 1004 can provide a network communication function;
  • the user interface 1003 is mainly used to provide an input interface for the user; and
  • the processor 1001 can be used to call the device control application stored in the memory 1005 program to achieve:
  • Execute the transaction data in the proposed block through the smart contract obtain the execution result of the target contract, and associate the block hash value of the proposed block with the execution result of the target contract and cache it in a temporary list; the temporary list includes blocks with a block height of M.
  • the target contract execution result mapped by the block hash value of the proposed block is obtained in the temporary list, and the proposed block and the target contract execution result are associated and stored in the blockchain.
  • the computer device 1000 described in the embodiment of the present application can execute the description of the blockchain-based block consensus method in the embodiment corresponding to FIG.
  • the description of the blockchain-based block consensus device 1 will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer program executed by the aforementioned block consensus apparatus 1 is stored in the above-mentioned computer-readable storage medium.
  • the processor loads and executes the above-mentioned computer program, it can execute the description of the above-mentioned block consensus method in any of the foregoing embodiments, and thus will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the above-mentioned computer-readable storage medium may be the block consensus apparatus provided in any of the foregoing embodiments or an internal storage unit of the above-mentioned computer equipment, such as a hard disk or a memory of the computer equipment.
  • the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (smart media card, SMC), a secure digital (secure digital, SD) card equipped on the computer device, Flash card (flash card), etc.
  • the computer-readable storage medium may also include both an internal storage unit of the computer device and an external storage device.
  • the computer-readable storage medium is used to store the computer program and other programs and data required by the computer device.
  • the computer-readable storage medium can also be used to temporarily store data that has been or will be output.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种基于区块链的区块共识方法以及相关设备，该区块共识方法包括：获取提议区块(S101)，通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中(S102)；在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果(S103)；若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中(S104)。采用该方法，可以减少区块上链的耗时，提高区块链的吞吐量。

Description

一种基于区块链的区块共识方法以及相关设备
本申请要求于2021年03月12日提交中国专利局、申请号202110273266.3、申请名称为“一种基于区块链的区块共识方法以及相关设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及基于区块链的区块共识。
背景技术
随着网络技术的快速发展以及政府和企业对数据安全的重视，区块链得到了极大的重视和应用。当区块链中的节点将提议区块写入区块链之前，需要先通过共识网络中的共识节点分别对该提议区块进行验证，达成对该提议区块的共识。
相关技术通常采用tendermint(一种拜占庭容错类型的协议)共识协议来进行区块共识。在tendermint共识协议中，一个提议区块在进入提交阶段之前，需要通过共识网络中进行两轮投票，每轮投票都需要得到共识网络中三分之二以上的共识节点的认可，完成区块共识，进入提交阶段，然后才能执行合约，得到合约执行结果。其中，每轮投票时每个共识节点都需要在该共识网络中广播投票信息，网络延迟使得共识阶段需要消耗一段时间，而且合约的执行也会消耗不少时间。因此，提议区块需要完成区块共识再执行合约，整个过程花费时间较长，导致区块链的吞吐量低。
发明内容
本申请实施例提供一种基于区块链的区块共识方法以及相关设备，可以减少区块上链的耗时，提高区块链的吞吐量。
本申请实施例一方面提供了一种基于区块链的区块共识方法，该方法由计算机设备执行，该方法包括：
获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数；
通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，并将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中；临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果；
在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果；
若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中。
本申请实施例一方面提供了一种基于区块链的区块共识装置，该装置部署在计算机设备上，该装置包括：
区块验证模块，用于获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数；
合约执行模块，用于通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，并将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中；临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果；
第一共识模块，用于在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果；
第一存储模块，用于若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中。
本申请实施例一方面提供了一种计算机设备，包括：处理器和存储器；
处理器与存储器相连，其中，存储器用于存储计算机程序，计算机程序被处理器执行时，使得该计算机设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有该处理器的计算机设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的方法。
在本申请实施例中，获取到区块高度为M且在第N轮生成的提议区块后，通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中；在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果；若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中。其中，M和N均为正整数。其中，临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果。采用本申请实施例提供的方法，将合约的执行和区块的两轮共识投票并行处理，可以缩短提议区块通过共识后，与目标合约执行结果关联存储至区块链的时间，即提高了区块的上链效率，从而可以有效地提高区块链的吞吐量。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种区块链节点***的结构示意图；
图2a-图2b是本申请实施例提供的一种区块共识的场景示意图；
图3是本申请实施例提供的一种基于区块链的区块共识方法的流程示意图；
图4是本申请实施例提供的一种区块合法性验证的场景示意图；
图5是本申请实施例提供的一种合约执行的场景示意图；
图6a-图6b是本申请实施例提供的一种共识投票的场景示意图；
图7是本申请实施例提供的一种区块共识的过程示意图；
图8是本申请实施例提供的一种合约执行结果存储的示意图；
图9是本申请实施例提供的一种区块共识装置的结构示意图；
图10是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参见图1，图1是本申请实施例提供的一种区块链节点***的结构示意图。区块链是一种分布式数据存储、点对点传输、共识机制以及加密算法等计算机技术的新型应用模式，主要用于对数据按时间顺序进行整理，并加密成账本，使其不可被篡改和伪造，同时可进行数据的验证、存储和更新。区块链本质上是一个去中心化的数据库，该数据库中的每个节点均存储一条相同的区块链，区块链网络中包括共识节点，共识节点负责区块链全网的共识。
可以理解的是，区块(Block)是在区块链网络上承载交易数据(即交易业务)的数据包，是一种被标记上时间戳和之前一个区块的哈希值的数据结构，区块经过网络的共识机制验证并确定区块中的交易。
可以理解的是，区块链***中可以包括有智能合约，该智能合约可以是指一种区块链各节点(包括共识节点)可以理解并执行的代码，可以执行任意逻辑并得到结果。应当理解，区块链中可以包括一个或多个智能合约，这些智能合约可以通过标识号(Identity  document，ID)或名称来进行区分，而交易业务请求中可以携带智能合约的标识号或名称，以此指定区块链需要运行的智能合约。
如图1所示的区块链节点***可以对应于区块链网络，该区块链网络可以包括但不限于联盟链所对应的区块链网络。区块链节点***是指用于进行区块链节点与区块链节点之间数据共享的***，该区块链节点***中可以包括多个节点，多个节点例如可以包括节点10a、节点10b、节点10c、节点10d、…、节点10n，这里的节点10a、节点10b、节点10c、节点10d…、节点10n可以统称为区块链节点。其中，每个节点在进行正常工作时可以接收到外界发送的数据，并基于接收到的数据进行区块上链处理，也可以向外界发送数据。为了保证各个节点之间的数据互通，每个节点之间可以存在数据连接，例如节点10a和节点10b之间存在数据连接，节点10a和节点10c之间存在数据连接，节点10b和节点10c之间存在数据连接。
可以理解的是，节点之间可以通过上述数据连接进行数据或者区块传输。区块链网络可以基于节点标识实现节点之间的数据连接，对于区块链网络中的每个节点，均具有与其对应的节点标识，而且上述每个节点均可以存储与自身有相连关系的其他节点的节点标识，以便后续根据其他节点的节点标识，将获取到的数据或生成的区块广播至其他节点，例如节点10a中可以维护一个如表1所示的节点标识列表，该节点标识列表保存着其他节点的节点名称和节点标识：
表1
节点名称 节点标识
节点10a 117.114.151.174
节点10b 117.116.189.145
节点10c 117.114.151.183
节点10d 117.117.125.169
... ...
节点10n 117.116.189.125
其中，节点标识可为网络之间互联的协议(Internet Protocol，IP)地址以及其他任意一种能够用于标识区块链网络中节点的信息，表1中仅以IP地址为例进行说明。例如，节点10a可以通过节点标识117.116.189.145向节点10b发送信息(例如，区块)，且节点10b可以通过节点标识117.114.151.174确定该信息是由节点10a所发送的。
可以理解的是，上述的数据连接不限定连接方式，可以通过有线通信方式进行直接或间接地连接，也可以通过无线通信方式进行直接或间接地连接，还可以通过其他连接方式，本申请在此不做限制。
可以理解的是，本申请实施例所提供的区块共识方法可以由计算机设备执行，计算机设备包括但不限于上述共识节点(可以为终端或服务器)。上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。上述终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。
如图1所示，在区块链中，在将一个区块(即提议区块)进行上链之前，该区块必须经过区块链网络中的共识节点进行共识，在共识通过后才能将该区块添加到区块链上。可以理解的是，当区块链被用于政府或者商业机构的一些场景中时，并非区块链中的所有参与节点(即上述区块链节点***中的区块链节点)都有足够的资源和必要性成为区块链的共识节点。例如，在图1所示的区块链节点***中，可以将节点10a、节点10b、节点10c和节点10d作为该区块链节点***中的共识节点。区块链节点***中的共识节点参与共识，也就是对区块(包含一批交易)进行共识，包括生成提议区块，对提议区块进行投票；而非共识节点不参与共识，但会帮助传播区块和投票消息，以及相互同步状态等。
在一轮共识中，共识节点中的某一节点可以作为提议节点，生成提议区块，然后根据区块链节点***中其他共识节点的节点标识，将提议区块分别发送给区块链节点***中的其他共识节点。每个共识节点在接收到提议区块后，会验证该提议区块的合法性，如果该提议区块合法，共识节点会根据智能合约执行提议区块中的交易数据，得到目标合约执行结果，然后缓存该目标合约执行结果；在通过智能合约执行交易数据的过程中，共识节点会对该提议区块进行两轮共识投票处理，如果两轮共识投票处理中都有三分之二以上的共识节点对该提议区块投了赞成票，则认为共识通过，然后共识节点会将该提议区块和目标合约执行结果一起添加至其存储的区块链中。需要说明的是，提议节点也属于共识节点，也需要对提议区块进行两轮共识投票处理。
下述以提议节点为节点10a，节点10a生成提议区块，然后节点10a将该提议区块广播至其余共识节点，也就是节点10b、节点10c和节点10d，然后一起对该提议区块进行共识为例进行说明。
为便于理解，进一步地，请参见图2a-图2b，图2a-图2b是本申请实施例提供的一种区块共识的场景示意图。
如图2a所示，节点10a作为提议节点，会监听整个区块链网络的交易，然后收集所有的交易，根据收集到的交易对应的交易数据，组装生成一个提议区块11。提议区块11存储至区块链之前，需要先通过共识网络中的共识节点进行两轮共识投票处理，共识通过才能存储至区块链。因此，节点10a会先将该提议区块11广播至共识网络中的其他共识节点，也就是节点10b、节点10c和节点10d。共识网络中的所有共识节点，都会对该提议区块11进行两轮共识投票处理。其中，两轮共识投票处理的过程可以为：在第一轮共识投票中， 每个共识节点根据提议区块11的合法性对提议区块11进行预投票处理，得到针对提议区块11的预投票结果，并将自己的预投票结果广播至共识网络中的其余共识节点，同时从其余共识节点中接收针对该提议区块11的预投票结果；在第二轮共识投票中，每个共识节点根据所有获取到的预投票结果对提议区块11进行预提交处理(即基于预投票结果再次进行共识投票)，得到针对提议区块11的预提交结果，并将自己的预提交结果广播至共识网络中的其余共识节点，同时从其余共识节点中接收针对该提议区块11的预提交结果。其中，每个预投票结果可以包含第一赞成结果或第一反对结果，第一赞成结果表示该共识节点确定该提议区块11合法；第一反对结果表示该共识节点确定该提议区块11非法。其中，每个预提交结果可以包含第二赞成结果或第二反对结果，第二赞成结果表示共识节点获取到的预投票结果中，有三分之二以上的共识节点投票第一赞成结果，第二反对结果表示共识节点获取到的预投票结果中，有三分之一以上的共识节点投票第一反对结果。共识节点根据获取到的预提交结果，如果确定第二赞成结果的数量达到共识网络中共识节点数量的三分之二，则确定共识通过，否则，确定共识失败。
如图2b所示，以节点10b接收到提议区块11为例进行说明。节点10b在接收到提议区块11以后，会对该提议区块11进行合法性验证，得到合法性验证结果。其中，合法性验证是为了验证该提议区块11是否合法，比如是否由本轮的提议节点10a生成的，提议区块11中的数据结构、数值等是否合理等等。节点10b在确定提议区块11的合法性验证结果为合法结果后，会读取提议区块11中的交易数据，然后通过智能合约执行提议区块11中的交易数据，得到目标合约执行结果12，目标合约执行结果12只有在共识网络达成对提议区块11的共识以后，才能同提议区块11一起写入区块链14中，因此节点10b会先将目标合约执行结果12存入临时列表13中。临时列表13中还可以存有其他提议区块对应的合约执行结果，因此，在将目标合约执行结果12写入临时列表时，还会将该目标合约执行结果12同提议区块11的区块哈希值相关联，在提议区块11完成共识以后，可以通过该提议区块11的区块哈希值来获取目标合约执行结果12，然后将提议区块11和目标合约执行结果12共同存储至区块链14中。需要说明的是，对提议区块11进行共识投票和通过智能合约执行该提议区块11中的交易数据，两个过程是同时进行的。共识网络中的每个共识节点在接收到提议区块11后，都会执行与节点10b相同的操作，即可以同步进行合约执行和区块共识的操作。其中，合约执行的具体过程和区块共识的区块过程，可以参见下述图3所对应的实施例的描述。
请参见图3，图3是本申请实施例提供的一种基于区块链的区块共识方法的流程示意图。其中，该方法可以由共识节点(例如上述图2a所对应的节点10a、节点10b、节点10c或者节点10d)执行，下述以该方法由共识节点执行为例进行说明。如图3所示，该基于区块链的区块共识方法至少可以包括以下S101-S104：
S101，获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数。
可以理解的是提议区块也可以称之为备选区块或待上链区块，是提议节点在一段时间内监听并收集全网的所有交易以后，组装生成包含每个交易对应的交易数据的区块。其中， 提议节点可用由共识网络中的某一共识节点担任，负责提出备选区块并在网络中广播。提议区块不能直接存储至区块链中，需要先经过共识网络的共识验证，共识通过以后才能上链，然后连接到上一个存储进区块链中的区块。因此，简单来说，区块链是由一个个提议区块在共识通过后链接起来组成的一个链条。
区块高度是区块的标示符，用来丈量区块链中某一个区块到第一个区块之间的距离，通过区块高度可以准确地了解到某一区块在链上的位置，相当于给区块定位了一个坐标。假设区块链中有五个区块，则第一个区块的区块高度为0，第二个区块的区块高度为1……以此类推，第五个区块的区块高度为4。此时，提议区块作为准备添加至区块链中的新区块，对应的区块高度就为5。上述提到，提议区块不能直接存储至区块链中，只有在通过区块共识才可以添加至区块链。其中，区块共识可以是投票型共识，即共识网络中的提议节点生成提议区块后，共识节点针对该提议区块进行两轮共识投票的过程。比如说，区块共识采用的是Tendermint共识算法，那么在两轮共识投票中均有三分之二及以上的共识节点针对该提议区块投了赞成票，则可以认为针对该提议区块的共识通过；如果在两轮共识投票中存在其中一轮共识投票没有三分之二及以上的共识节点针对该提议区块投了赞成票，则认为针对该提议区块的共识不通过，则该提议区块无法存储至区块链中。假设区块高度为5的提议区块共识失败，此时共识网络中会选举出新的共识节点来担任新的提议节点，然后该新的提议节点会生成一个新的提议区块，共识网络会针对新的提议区块进行区块共识。可以理解的是，新的提议区块的区块高度依然为5，为了区分，可以将共识失败的提议区块称之为区块高度为5且在第1轮生成的提议区块，新的提议区块称之为区块高度为5且在第2轮生成的提议区块。如果区块高度为5且在第2轮生成的提议区块依然共识失败，则下一提议区块为区块高度为5且在第3轮生成的提议区块。需要说明的是，每一轮的提议节点是由选举算法选出(如轮流产生)，不一定是固定不变的。
在一种可能的实现方式中，共识节点在接收到提议区块后，会对其进行合法性验证得到合法性验证结果。其中，合法性验证可以是对提议节点身份的验证，可以是对提议区块内容的验证。
一个可行的实施例中，共识节点对提议区块做合法性验证得到合法性验证结果，可以是获取提议区块中的交易数据，对交易数据进行哈希运算，得到待验证哈希值；根据提议区块中的默克尔树路径对待验证哈希值进行哈希运算，得到待验证树根哈希值；从提议区块的区块头中获取默克尔树根哈希值；若待验证树根哈希值和默克尔树根哈希值相同，则确定提议区块的合法性验证结果为合法结果；若待验证树根哈希值和默克尔树根哈希值不相同，则确定提议区块的合法性验证结果为非法结果。其中，哈希(hash)值，也称作信息特征值或特征值，哈希值是通过哈希算法将任意长度的输入数据转换为密码并进行固定输出而生成的，不能通过解密哈希值来检索原始输入数据，它是一个单向的加密函数。其中，默克尔(Merkle)树由一个根节点(root)、一组中间节点和一组叶节点(leaf)组成。叶节点(leaf)包含存储数据或其哈希值，中间节点是它的两个孩子节点内容的哈希值，根节点也是由它的两个子节点内容的哈希值组成。所以Merkle树也称哈希树。
为便于理解，请一并参见图4，图4是本申请实施例提供的一种区块合法性验证的场景示意图。如图4所示，共识节点40(可以为上述图2a所示的任一共识节点)接收到提议区块41，提议区块41包含有包含区块头411(Header)和区块体412(Body)两部分。在区块头411中存有默克尔树根哈希值HX(1234)，当然，在实际应用时，区块头411中可以存储有版本号、时间戳和难度值等基本数据，还可以存储有其他相关数据。区块体412中存有默克尔树和交易数据4121，其中，交易数据4121中包含有交易数据Y1、交易数据Y2、交易数据Y3和交易数据Y4。其中，每个交易数据对应有一个交易，实际上一个提议区块中可能包含多个交易对应的交易数据。如图4所示，共识节点40首先对交易数据Y1、交易数据Y2、交易数据Y3和交易数据Y4分别进行哈希计算，得到交易数据Y1的待验证哈希值HY(1)、交易数据Y2的待验证哈希值HY(2)、交易数据Y3的待验证哈希值HY(3)，以及交易数据Y4的待验证哈希值HY(4)；然后共识节点会根据默克尔树路径，对这些待验证哈希值进行哈希运算，即对待验证哈希值HY(1)以及待验证哈希值HY(2)进行哈希运算，得到包括上述两个待验证哈希值的待验证叶哈希值HY(12)，对待验证哈希值HY(3)以及待验证哈希值HY(4)进行哈希运算，得到包括上述两个待验证哈希值的待验证叶哈希值HY(34)；最后对待验证叶哈希值HY(12)以及待验证叶哈希值HY(34)进行哈希运算，得到包括待验证叶哈希值HY(12)以及待验证叶哈希值HY(34)的待验证树根哈希值HY(1234)。然后共识节点40将待验证树根哈希值HY(1234)与区块头411中的默克尔树根哈希值HX(1234)进行对比，若两者相同，可以确定提议区块11的合法性验证结果为合法结果；否则确定提议区块11的合法性验证结果为非法结果。
一个可行的实施例中，共识节点对提议区块做合法性验证得到合法性验证结果，可以是获取提议区块中的交易数据；调用交易验证函数对交易数据进行验证，得到交易验证结果；若交易验证结果为有效结果，则确定提议区块的合法性验证结果为合法结果；若交易验证结果为无效结果，则确定提议区块的合法性验证结果为非法结果。其中，交易验证函数是根据校验标准规则来设定的，比如Check(检查)函数。通过Check函数，可以验证区块的数据结构语法是否有效，区块大小是否在长度限制范围内，区块时间戳是否早于验证时刻未来两个小时，区块中的签名数据是否小于签名操作的上限等等。如果区块的数据格式、大小、签名等符合校验标准规则，Check函数可以返回0，即有效的交易验证结果，此时共识节点会确定提议区块的合法性验证结果为合法结果，如果调用该Check函数返回其他值，共识节点会确定提议区块的合法性验证结果为非法结果。
一个可行的实施例中，共识节点对提议区块做合法性验证得到合法性验证结果，可以是在区块链中获取提议区块的父区块的区块哈希值，作为目标父区块哈希值；从提议区块的区块头中获取父区块哈希值，作为待验证父区块哈希值；若待验证父区块哈希值和目标父区块哈希值相同，则确定提议区块的合法性验证结果为合法结果；若待验证父区块哈希值和目标父区块哈希值不相同，则确定提议区块的合法性验证结果为非法结果。其中，区块哈希值也是区块的标示符，区块哈希值是由父区块哈希值、区块内容、区块创建时间三个字段拼接以后通过哈希算法计算得到的。其中，父区块就是区块链中某一区块的前一个区块，比如说，区块高度为5的区块的父区块就为区块高度为4的区块。
一个可行的实施例中，共识节点对提议区块做合法性验证得到合法性验证结果，可以是获取提议区块相关联的签名数据；获取提议节点的公钥，通过公钥验证签名数据，得到签名验证结果；若签名验证结果为验签成功，则确定提议区块的合法性验证结果为合法结果；若签名验证结果为验签失败，则确定提议区块的合法性验证结果为非法结果。其中，属于验签成功的签名数据，是由提议节点通过所拥有的私钥对提议区块进行签名得到的。其中，公钥是与私钥就是俗称的不对称加密方式，公钥是面向大家的，也就是说，别的共识节点可以获取到提议节点的公钥；私钥是私有的，别的共识节点无法获取提议节点的私钥。提议节点采用自己的私钥对提议区块加以处理，由于该私钥仅为提议节点所有，这样就产生了其他节点无法生成的文件，也就形成了数字签名。在一轮共识中，共识节点可以知道谁是本轮生成提议区块的提议节点，并获取提议节点的公钥，然后通过公钥来对签名数据进行解密，也就是验签，验签成功说明该签名数据是由提议节点发送的，与该签名数据相关联的提议区块是由本轮共识的提议节点生成的提议区块，不是误接收了别的节点传来的提议区块或者其他非法区块，则可以确定该提议区块合法性验证通过；否则确定提议区块合法性验证不通过。
需要说明的是，上述一个或多个可选实施例中提到的针对提议区块的合法性验证方法，可以在验证提议区块合法性的时候同时使用。
S102，通过智能合约执行所述提议区块中的交易数据，得到目标合约执行结果，将所述提议区块的区块哈希值与所述目标合约执行结果关联缓存至临时列表中。
当需要对提议区块进行合法性验证得到合法性验证结果时，S102的是实现方式可以是若合法性验证结果为合法结果，则通过智能合约执行提议区块中的交易数据，得到目标合约执行结果。
共识节点在获取到提议区块，并验证该提议区块合法以后，会调用用于执行交易数据的智能合约中的交易执行函数，然后通过交易执行函数获取针对交易数据的读取数据，再通过读取数据和交易数据执行交易执行函数，得到目标合约执行结果。然后，共识节点会获取提议区块的区块哈希值，将提议区块的区块哈希值和目标合约执行结果关联缓存至临时列表中。其中，智能合约是一种旨在以信息化方式传播、验证或执行合同的计算机协议。在区块链***当中，智能合约是一种区块链各节点可以理解并执行的代码，可以执行任意逻辑并得到结果。在实际应用中，智能合约通过区块链上的交易来管理与试用。每条交易对应的交易数据相当于对区块链***的一个远程过程调用(Remote Procedure Call，RPC)请求。如果说智能合约相当于可执行程序，区块链就相当于提供运行环境的操作***。区块链可以包含多个合约，以合约账号(Identity，ID)、标识号或名称来区分。
为便于理解，请一并参见图5，图5是本申请实施例提供的一种合约执行的场景示意图。如图5所示，共识节点50(可以为上述图2a所示的任一共识节点)获取了提议区块51，其中，提议区块51可以是共识网络中的提议节点生成的待共识区块。提议区块51的区块体中包含有交易数据511，交易数据511可以包含交易1、交易2、交易3、…、交易n， 以及每个交易对应的函数名称。共识节点50可以根据函数名称调用用于执行交易数据的智能合约52中的交易执行函数，如图5所示，执行交易1的函数为交易执行函数1，执行交易2的函数为交易执行函数2，执行交易3的函数为交易执行函数3，…，执行交易n的函数为交易执行函数n。可以理解的是，函数(包括函数名称1、函数名称2、函数名称3、…、函数名称n分别对应的函数)，可以在同一个智能合约下被调用，也可以在不同的智能合约下被调用，例如函数名称1对应的函数(即交易执行函数1)与函数名称2对应的函数(即交易执行函数2)在智能合约B中被调用，函数名称3对应的函数(即交易执行函数3)与函数名称n对应的函数(即交易执行函数n)在智能合约V中被调用。
然后，共识节点50可以根据交易执行函数获取针对交易数据的历史交易数据，将历史交易数据确定为读取数据。如图5所示，通过交易执行函数1获取交易1的读取数据1，通过交易执行函数2获取交易2的读取数据2，通过交易执行函数3获取交易3的读取数据3，…，通过交易执行函数n获取交易n的读取数据n。例如，交易1为甲方通过自己的账户向乙方转账10元，交易执行函数1为转移执行函数，读取数据1，也就是交易1的历史交易数据为甲方账户上剩余20元，针对交易1的交易执行结果1可以为20-10＝10元，即执行交易1后，甲方的账户上剩余10元。
上文简单以交易1为例叙述交易数据、读取数据以及交易执行结果之间的联系，故根据交易2、读取数据2以及交易执行函数2，可以得到交易2的交易执行结果2，根据交易3、读取数据3以及交易执行函数3，可以得到交易3的交易执行结果3，…，根据交易n、读取数据n以及交易执行函数n，可以得到交易n的交易执行结果n。共识节点会将交易执行结果1、交易执行结果2、交易执行结果3，…，交易执行结果n作为目标合约执行结果，然后将目标合约执行结果与提议区块的区块哈希值建立关联关系，将该关联关系缓存在临时列表中。
需要说明的是，在本申请实施例中，临时列表中还可以存有其他提议区块对应的合约执行结果，前N轮生成的提议区块有多个少提议区块执行了交易数据，就可以得到多少合约执行结果。若前N轮生成的提议区块都执行了交易数据，则临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果。
S103，在通过所述智能合约执行所述交易数据的过程中，并行对所述提议区块进行两轮共识投票处理，得到第一共识结果。
需要说明的是，合约执行和两轮共识投票处理是并行执行的，也就是说，在共识节点开始对提议区块进行共识投票时，就同时通过智能合约执行交易数据了。在第一轮共识投票中，共识节点根据提议区块的合法性验证结果对提议区块进行预投票处理，得到预投票结果；在第二轮共识投票中，根据预投票结果对提议区块进行预提交处理，得到第一共识结果。
在第一轮共识投票中，共识节点根据提议区块的合法性验证结果对提议区块进行预投票处理，得到预投票结果，可以是，在第一轮共识投票中，因为共识节点已经确定提议区 块的合法性，共识节点会将第一预投票结果确定为针对提议区块的第一赞成结果；将第一预投票结果广播至多个目标共识节点；接收多个目标共识节点分别发送的第二预投票结果；根据第一预投票结果和多个第二预投票结果，确定针对提议区块的第一赞成票数量和第一反对票数量；若第一赞成票数量超过第一预投票阈值，确定预投票结果为预投票成功结果；若第一反对票数量超过第二预投票阈值，确定预投票结果为预投票失败结果。其中，多个第二预投票结果中存在针对提议区块的第一赞成结果，或者多个第二预投票结果中存在针对提议区块的第一反对结果。其中，第一预投票阈值可以为共识网络中共识节点总数量的三分之二，比如，共识节点总数量为30，则第一预投票阈值可以为20；第二预投票阈值可以为共识网络中共识节点总数量的三分之一，比如，共识节点总数量为30，则第二预投票阈值可以为10。
在第二轮共识投票中，根据预投票结果对提议区块进行预提交处理，得到第一共识结果，可以是，若共识节点在第一轮共识投票中确定预投票结果为预投票成功结果，则将第一预提交结果确定为针对提议区块的第二赞成结果；否则将第一预提交结果确定为针对提议区块的第二反对结果；然后共识节点会将第一预提交结果广播至多个目标共识节点；同时共识节点会接收多个目标共识节点分别发送的第二预提交结果；根据第一预提交结果和多个第二预提交结果，确定针对提议区块的第二赞成票数量和第二反对票数量；若第二赞成票数量超过第一预提交阈值，确定第一共识结果为共识通过结果；若第二反对票数量超过第二预提交阈值，确定第一共识结果为共识不通过结果。其中，多个第二预提交结果中存在针对提议区块的第二赞成结果，或者多个第二预提交结果中存在针对提议区块的第二反对结果。其中，第一预提交阈值可以为共识网络中共识节点总数量的三分之二，比如，共识节点总数量为30，则第一预提交阈值可以为20；第二预提交阈值可以为共识网络中共识节点总数量的三分之一，比如，共识节点总数量为30，则第二预提交阈值可以为10。
为便于理解，请一并参见图6a-图6b，图6a-图6b是本申请实施例提供的一种共识投票的场景示意图。如图6a所示，共识节点60(可以为上述图2a所示的节点10a、节点10b、节点10c或者节点10d)，共识节点60在验证提议区块合法以后，对提议区块进行了第一轮共识投票，也就是预投票处理。因为提议区块的合法性验证结果为合法结果，共识节点60确定针对提议区块的第一预投票结果为第一赞成结果，然后将第一赞成结果广播给共识网络中的其他共识节点。可以理解的是，提议节点生成提议区块后会广播至共识网络中的所有共识节点，因此，除去共识节点60，其余共识节点在接收到提议区块后，会执行与共识节点60一样对提议区块进行共识处理。也就是说，共识节点61、共识节点62和共识节点63也会对提议区块进行第一轮共识投票，然后广播自己的预投票结果，对于共识节点60来说，共识节点61、共识节点62或者共识节点63的预投票结果为第二预投票结果。如图6a所示，共识节点60将接收到共识节点61的第一赞成结果，共识节点62的第一反对结果和共识节点63的第一赞成结果。其中，第一反对结果可能是因为共识节点62由于网络问题迟迟未接收到提议区块，或者共识节点62确定提议区块的合法性验证结果为非法，从而确定的预投票结果。然后，共识节点60根据第一预投票结果和接收到的其余共识节点 的第二预投票结果，统计出第一赞成票数量为3，第一反对票数量为1，明显第一赞成票数量大于共识网络中所有共识节点数量的三分之二，共识节点60会确定预投票成功。
如图6b所示，共识节点60确定预投票成功以后，会进入第二轮共识投票，也就是预提交处理。预提交处理实际是根据共识节点的预投票结果来进行的，共识节点60的预投票结果为预投票成功结果，共识节点60会将第一预提交结果确定为第二赞成结果，然后广播给共识网络中的其余共识节点。同样，共识节点60会接收其余共识节点的第二预提交结果。其中，第二预提交结果可以为第二赞成结果，或者第二反对结果。如图6b所示，共识节点61可能因为网络问题或者广播传输问题，确定预投票结果为预投票失败，从而将第二预提交结果确定为第二反对结果，但是共识节点62、共识节点63和共识节点61均确定预投票结果为预投票成功，因此都是第二赞成结果，共识节点60根据第一预提交结果和接收到的第二预提交结果，可以确定针对提议区块的第二赞成票数量为3，第二反对票数量为1，因此，共识节点60会确定该提议区块共识通过。
在一种可能的情况下，在上述两轮共识投票过程中，共识节点60在接收其余共识节点的第二预投票结果或者第二预提交结果时，由于共识节点60和其余共识节点的距离、网络速度等原因，共识节点60接收到其余共识节点的第二预投票结果可以是不同步的，比如说，共识节点60可以在接收到共识节点62的第二预投票结果的10s后，才接收到共识节点61传来的第二预投票结果；第二预提交结果同理。因此，在进行两轮共识投票处理时，共识节点可以持续根据已经获取到的投票结果，来统计赞成票或者反对票的数量，只要赞成票的数量达到共识节点总数量的三分之二，就可以进行下一步动作，无需等待接收到所有共识节点的投票结果。
S104，若所述第一共识结果为共识通过结果，则在所述临时列表中获取所述提议区块的区块哈希值所映射的目标合约执行结果，将所述提议区块和所述目标合约执行结果关联存储至区块链中。
当提议区块的共识通过后，共识节点可以根据提议区块的区块哈希值在临时列表中获取映射的目标合约执行结果，然后将提议区块和目标合约执行结果关联存储至区块链中。
通过本申请实施提供的方法，共识节点获取到提议区块，然后验证该提议区块为合法后，同时进行提议区块中的合约执行和提议区块的共识投票处理，将合约执行得到的目标合约执行结果缓存在临时列表中，如果针对该提议区块的共识结果为共识通过结果，就获取缓存在临时列表中的目标合约执行结果，同提议区块一起存储至区块链中。采用本申请实施例提供的方法，减少了整个区块上链处理的时间，大大提高了区块链的吞吐量。
请参见图7，图7是本申请实施提供的一种区块共识的过程示意图。如图7所示，提议(Proposer)节点开始监听并收集全网的所有交易，经过一段时间后，组装一个新块，并向全网广播，这个就是提议区块(proposal block)。全网所有共识(validator)节点收到这个提议区块后，开始读取这个提议区块里的所有交易数据，一一进行验证，如果没有问题，确认这个提议区块为有效块(valid block)，然后就发出一条预投票同意消息(Prevote Block)， 表示同意这个提议区块，投一个赞成票，与此同时，共识节点开始通过智能合约执行提议区块中的交易数据，即执行合约(Execute contract)，并将得到的目标合约执行结果缓存起来；如果共识节点没有收到该提议区块，或者共识节点发现提议区块里有非法交易，确认这个提议区块为无效块(invalid block)，则发出一条预投票反对消息(Prevote Nil)，表示反对这个提议区块，投一个反对票。
如图7所示，这些预投票消息会被广播到所有共识节点，所以每个共识节点既会发出一个预投票消息，又会收集别人的预投票消息。当共识节点发现收集到的预投票消息中同意投票数量超过共识节点总数量的2/3(预投票超过2/3的同意票)时，就发出一个预提交同意(Precommit Block)的预提交信息，这是第二阶段的投票了，同样的，每个共识节点既会发出一个预提交消息，又会收集别人的预提交消息。当一个共识节点收集到的预提交消息中同意票数超过共识节点总数量的2/3(预提交超过2/3的同意票)时，说明这个提议区块是得到了大多数共识节点同意的，然后共识节点可以把这个提议区块和缓存的目标合约执行结果写入本地的区块链，追加到末尾，即完成提交(Commit)，同时区块高度增一，得到新高度(New Height)，进入下一轮(round)，提议节点开始提议新高度对应的新区块。但是当一个共识节点收集到的预提交消息中同意票数不超过共识节点总数量的2/3，换言之，共识节点收集到的预提交消息中反对票数超过了共识节点总数量的1/3，说明这个提议区块是不能得到大多数共识节点同意，因此，共识节点不会把这个提议区块和缓存的目标合约执行结果写入本地的区块链，提交失败，此时，区块高度不会改变，进入下一round(即图7中新一轮)，提议节点开始提议该区块高度对应的新区块。
由上述可知，在区块链中的当前区块高度写入一个新的区块，需要经历一个或多个round。其中，一个round包括4个阶段(step)：Propose，Execute contract，Prevote和Precommit，可以理解的是，Execute contract步骤同Prevote和Precommit步骤是并行执行的。整个区块共识过程就是由一个或多个round，再加上两个特殊的阶段：Commit和NewHeight，如下所示：
NewHeight->{Propose->(Execute contract)/(Prevote->Precommit)}+->Commit->NewHeight->...
在一种可能的是实现方式中，若提议区块的合法性验证结果为非法结果，即提议区块为无效块，共识节点依然会对提议区块进行两轮共识投票处理，得到第二共识结果；若第二共识结果为共识通过结果，则从已完成共识节点中同步已存储至区块链中区块高度为M的提议区块，以及提议区块对应的目标合约执行结果。其中，已完成共识节点为成功将提议区块以及目标合约执行结果存储至区块链中的目标共识节点。
在一种可能的是实现方式中，在一个round中，共识节点由于网络等问题没有及时收到提议区块，共识节点自然不会一直等待下去，因此，在验证时间阈值内，共识节点未获取到区块高度为M且在第N轮生成的提议区块，会构建临时空区块，然后针对临时空区块进行两轮共识投票处理，得到第三共识结果。若第三共识结果为共识通过结果，空区块中 又没有交易数据，共识节点会从已完成共识节点中同步已存储至所述区块链中区块高度为M的提议区块，以及提议区块对应的目标合约执行结果。其中，已完成共识节点为成功将提议区块以及目标合约执行结果存储至区块链中的目标共识节点。
通过本申请实施例提供的方法，合约的执行在检测到提议区块为有效块时就执行，即在广播预投票信息和预提交信息的同时能进行合约的执行，当合约的执行与这两次广播时间相当时，相当于节省了合约执行的时间，大大提高了区块链的性能。
请参见图8，图8是本申请实施例提供的一种合约执行结果存储的示意图。在本申请实施例中，共识节点提前执行了可能最终无法提交的提议区块中的合约，因此执行合约时不能将执行结果直接保存到数据库中，而需要将临时的执行结果缓存起来，比如保存在存储器中的一个临时列表中，或者保存在临时数据库中的临时列表中，等等。如图8所示，区块H3/R1是指区块高度为3且在第1轮生成的提议区块，区块H3/R2是指区块高度为3且在第2轮生成的提议区块，区块H3/R3是指区块高度为3且在第3轮生成的提议区块。可能由于网络等问题，区块H3/R1和区块H3/R2的共识投票(例如预提交和预投票)失败了，都进入到了下一轮，尽管共识节点已经执行了区块H3/R1和区块H3/R2中的合约，但是并不会将对应的合约执行结果写入区块链中。如图8所示，在得到合约执行结果以后，共识节点会先将合约执行结果缓存至存储器的临时列表中，可以理解的是，临时列表中可能存储有多个提议区块对应的合约执行结果，因此可以采用[k,v]键值对(Key-Value存储，简称KV存储，键：就是存的值的编号，值：就是要存放的数据)来存储，即将合约执行结果作为值，关联上唯一的键值。可以用提议区块的区块哈希值(block hash)作为key(唯一标记)保存这个临时的合约执行结果。然后，在共识节点提交提议区块时，只需要找出决定提交的提议区块的区块哈希值对应的合约执行结果，将其保存到账本中。
在一种可能的是实现方式中，在提交完区块高度为M的最终提议区块后，共识节点可以将临时列表中区块高度为M的N个合约执行结果删除。
在一种可能的是实现方式中，共识节点可以获取临时列表中所有合约执行结果的总数量，若总数量大于或等于存储数量阈值，则删除临时列表中的所有合约执行结果。其中，所有合约执行结果包括一个或多个区块高度分别对应的合约执行结果。
通过本申请实施例提供的方法，采用区块哈希值来标识提议区块对应的合约执行结果，即使同一块高存在多个对应的提议区块，在最终提交最终提议区块时，也可以根据该最终提议区块的区块哈希值来找到临时缓存的合约执行结果，不会出现存储混乱。同时，在提交完提议区块后删除缓存的合约执行结果，可以释放内存，提示区块链的性能。
请参见图9，图9是本申请实施例提供的一种区块共识装置的结构示意图。该区块共识装置1可以包括：区块验证模块11、合约执行模块12、第一共识模块13以及第一存储模块14。
区块验证模块11，用于获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数；
合约执行模块12，用于通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中；临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果；
第一共识模块13，用于在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果；
第一存储模块14，用于若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中。
其中，区块验证模块11、合约执行模块12、第一共识模块13以及第一存储模块14的具体功能实现方式可以参见图3对应实施例中的S101-S104，这里不再进行赘述。
在一种可能的实现方式中，区块验证模块11还用于：
对所述提议区块进行合法性验证得到合法性验证结果；
合约执行模块12，用于：
若所述合法性验证结果为合法结果，则通过智能合约执行所述提议区块中的交易数据，得到所述目标合约执行结果。
在一种可能的实现方式中，所述临时列表是通过键值对来存储所述提议区块的区块哈希值与所述目标合约执行结果，所述提议区块的区块哈希值为所述键值对中的键，所述目标合约执行结果为所述键值对中的值。
请再参见图9，区块验证模块11可以包括：哈希运算单元1111、根哈希获取单元1112以及第一验证单元1113。
哈希运算单元1111，用于获取提议区块中的交易数据，对交易数据进行哈希运算，得到待验证哈希值；
哈希运算单元1111，还用于根据提议区块中的默克尔树路径对待验证哈希值进行哈希运算，得到待验证树根哈希值；
根哈希获取单元1112，用于从提议区块的区块头中获取默克尔树根哈希值；
第一验证单元1113，用于若待验证树根哈希值和默克尔树根哈希值相同，则确定提议区块的合法性验证结果为合法结果；
第一验证单元1113，还用于若待验证树根哈希值和默克尔树根哈希值不相同，则确定提议区块的合法性验证结果为非法结果。
其中，哈希运算单元1111、根哈希获取单元1112以及第一验证单元1113的具体功能实现方式可以参见图3对应实施例中的对提议区块进行合法性验证得到合法性验证结果的步骤，这里不再进行赘述。
请再参见图9，区块验证模块11可以包括：交易获取单元1121、交易验证单元1122以及第二验证单元1123。
交易获取单元1121，用于获取提议区块中的交易数据；
交易验证单元1122，用于调用交易验证函数对交易数据进行验证，得到交易验证结果；
第二验证单元1123，用于若交易验证结果为有效结果，则确定提议区块的合法性验证结果为合法结果；
第二验证单元1123，还用于若交易验证结果为无效结果，则确定提议区块的合法性验证结果为非法结果。
其中，交易获取单元1121、交易验证单元1122以及第二验证单元1123的具体功能实现方式可以参见图3对应实施例中的对提议区块进行合法性验证得到合法性验证结果的步骤，这里不再进行赘述。
请再参见图9，区块验证模块11可以包括：第一哈希获取单元1131、第二哈希获取单元1132以及第三验证单元1133。
第一哈希获取单元1131，用于在区块链中获取提议区块的父区块的区块哈希值，作为目标父区块哈希值；
第二哈希获取单元1132，还用于从提议区块的区块头中获取父区块哈希值，作为待验证父区块哈希值；
第三验证单元1133，用于若待验证父区块哈希值和目标父区块哈希值相同，则确定提议区块的合法性验证结果为合法结果；
第三验证单元1133，还用于若待验证父区块哈希值和目标父区块哈希值不相同，则确定提议区块的合法性验证结果为非法结果。
其中，第一哈希获取单元1131、第二哈希获取单元1132以及第三验证单元1133的具体功能实现方式可以参见图3对应实施例中的对提议区块进行合法性验证得到合法性验证结果的步骤，这里不再进行赘述。
请再参见图9，区块验证模块11可以包括：签名获取单元1141、签名验证单元1142以及第四验证单元1143。
签名获取单元1141，用于获取提议区块相关联的签名数据；
签名验证单元1142，用于获取提议节点的公钥，通过公钥验证签名数据，得到签名验证结果；
第四验证单元1143，用于若签名验证结果为验签成功，则确定提议区块的合法性验证结果为合法结果；属于验签成功的签名数据，是由提议节点通过所拥有的私钥对提议区块进行签名得到的；属于验签成功的签名数据相关联的提议区块是由提议节点生成的；
第四验证单元1143，还用于若签名验证结果为验签失败，则确定提议区块的合法性验证结果为非法结果。
其中，签名获取单元1141、签名验证单元1142以及第四验证单元1143的具体功能实现方式可以参见图3对应实施例中的对提议区块进行合法性验证得到合法性验证结果的步骤，这里不再进行赘述。
请再参见图9，合约执行模块12可以包括：第一获取单元121、第二获取单元122、结果获取单元123以及缓存单元124。
第一获取单元121，用于获取提议区块中的交易数据，调用用于执行交易数据的智能合约中的交易执行函数；
第二获取单元122，用于根据交易执行函数获取针对交易数据的读取数据；
结果获取单元123，用于根据读取数据以及交易数据执行交易执行函数，得到交易数据的目标合约执行结果；
缓存单元124，用于将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中。
其中，第一获取单元121、第二获取单元122、结果获取单元123以及缓存单元124的具体功能实现方式可以参见图3对应实施例中的S102，这里不再进行赘述。
请再参见图9，第一共识模块13可以包括：预投票单元131以及预提交单元132。
预投票单元131，用于在第一轮共识投票中，根据提议区块的合法性验证结果对提议区块进行预投票处理，得到预投票结果；
预提交单元132，用于在第二轮共识投票中，根据预投票结果对提议区块进行预提交处理，得到第一共识结果。
其中，预投票单元131以及预提交单元132的具体功能实现方式可以参见图3对应实施例中的S103，这里不再进行赘述。
请再参见图9，预投票单元131可以包括：第一确定子单元1311、第一广播子单元1312、第一接收子单元1313、第一统计子单元1314以及预投票处理子单元1315。
第一确定子单元1311，用于在第一轮共识投票中，根据合法结果将第一预投票结果确定为针对提议区块的第一赞成结果；
第一广播子单元1312，用于将第一预投票结果广播至多个目标共识节点；
第一接收子单元1313，用于接收多个目标共识节点分别发送的第二预投票结果；多个第二预投票结果中存在针对提议区块的第一赞成结果，或者多个第二预投票结果中存在针对提议区块的第一反对结果；
第一统计子单元1314，用于根据第一预投票结果和多个第二预投票结果，确定针对提议区块的第一赞成票数量和第一反对票数量；
预投票处理子单元1315，用于若第一赞成票数量超过第一预投票阈值，确定预投票结果为预投票成功结果；
预投票处理子单元1315，还用于若第一反对票数量超过第二预投票阈值，确定预投票结果为预投票失败结果。
其中，第一确定子单元1311、第一广播子单元1312、第一接收子单元1313、第一统计子单元1314以及预投票处理子单元1315的具体功能实现方式可以参见图6a对应实施例中的具体描述，这里不再进行赘述。
请再参见图9，预提交单元132可以包括：第二确定子单元1321、第二广播子单元1322、第二接收子单元1323、第二统计子单元1324以及预提交处理子单元1325。
第二确定子单元1321，用于若预投票结果为预投票成功结果，则将第一预提交结果确定为针对提议区块的第二赞成结果；
第二确定子单元1321，还用于若预投票结果为预投票失败结果，则将第一预提交结果确定为针对提议区块的第二反对结果；
第二广播子单元1322，用于将第一预提交结果广播至多个目标共识节点；
第二接收子单元1323，用于接收多个目标共识节点分别发送的第二预提交结果；多个第二预提交结果中存在针对提议区块的第二赞成结果，或者至少第二两个预提交结果中存在针对提议区块的第二反对结果；
第二统计子单元1324，用于根据第一预提交结果和多个第二预提交结果，确定针对提议区块的第二赞成票数量和第二反对票数量；
预提交处理子单元1325，用于若第二赞成票数量超过第一预提交阈值，确定第一共识结果为共识通过结果；
预提交处理子单元1325，还用于若第二反对票数量超过第二预提交阈值，确定第一共识结果为共识不通过结果。
其中，第二确定子单元1321、第二广播子单元1322、第二接收子单元1323、第二统计子单元1324以及预提交处理子单元1325的具体功能实现方式可以参见图6b对应实施例中的具体描述，这里不再进行赘述。
请再参见图9，该区块共识装置1还可以包括：第二共识模块15以及第二存储模块16。
第二共识模块15，用于若提议区块的合法性验证结果为非法结果，则对提议区块进行两轮共识投票处理，得到第二共识结果；
第二存储模块16，用于若第二共识结果为共识通过结果，则从已完成共识节点中同步已存储至区块链中区块高度为M的提议区块，以及提议区块对应的目标合约执行结果；已完成共识节点为成功将提议区块以及目标合约执行结果存储至区块链中的目标共识节点。
其中，第二共识模块15以及第二存储模块16的具体功能实现方式可以参见图7对应实施例中的具体描述，这里不再进行赘述。
请再参见图9，区块验证模块11可以包括：成功获取单元1151。
成功获取单元1151，用于若在验证时间阈值内，获取到区块高度为M且在第N轮生成的提议区块，则对提议区块进行合法性验证。
则，区块共识装置1还可以包括：失败获取模块17、第三共识模块18以及第三存储模块19。
失败获取模块17，用于若在验证时间阈值内，未获取到区块高度为M且在第N轮生成的提议区块，则构建临时空区块；
第三共识模块18，用于对临时空区块进行两轮共识投票处理，得到第三共识结果；
第三存储模块19，用于若第三共识结果为共识通过结果，则从已完成共识节点中同步已存储至区块链中区块高度为M的提议区块，以及提议区块对应的目标合约执行结果；已完成共识节点为成功将提议区块以及目标合约执行结果存储至区块链中的目标共识节点。
其中，成功获取单元1151、失败获取模块17、第三共识模块18以及第三存储模块19的具体功能实现方式可以参见图7对应实施例中的具体描述，这里不再进行赘述。
请再参见图9，该区块共识装置1还可以包括：第一删除模块110以及第二删除模块111。
第一删除模块110，用于将临时列表中区块高度为M的N个合约执行结果删除；
第二删除模块111，用于获取临时列表中所有合约执行结果的总数量，若总数量大于或等于存储数量阈值，则删除临时列表中的所有合约执行结果；所有合约执行结果包括一个或多个区块高度分别对应的合约执行结果。
其中，第一删除模块110以及第二删除模块111的具体功能实现方式可以参见图8对应实施例中的具体描述，这里不再进行赘述。
请参见图10，图10是本申请实施例提供的一种计算机设备的结构示意图。如图10所示，上述图9所对应实施例中的区块共识装置1可以应用于上述计算机设备1000，上述计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述计算机设备1000还包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图10所示，作为一种计算机可读存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及设备控制应用程序。
在图10所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：
获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数；
通过智能合约执行提议区块中的交易数据，得到目标合约执行结果，并将提议区块的区块哈希值与目标合约执行结果关联缓存至临时列表中；临时列表包括区块高度为M的N个合约执行结果，N个合约执行结果包括目标合约执行结果；
在通过智能合约执行交易数据的过程中，并行对提议区块进行两轮共识投票处理，得到第一共识结果；
若第一共识结果为共识通过结果，则在临时列表中获取提议区块的区块哈希值所映射的目标合约执行结果，将提议区块和目标合约执行结果关联存储至区块链中。
应当理解，本申请实施例中所描述的计算机设备1000可执行前文图3所对应实施例中对该基于区块链的区块共识方法的描述，也可执行前文图9所对应实施例中对该基于区块链的区块共识装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且上述计算机可读存储介质中存储有前文提及的区块共识装置1所执行的计算机程序，当上述处理器加载并执行上述计算机程序时，能够执行前文任一实施例对上述区块共识方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。
上述计算机可读存储介质可以是前述任一实施例提供的区块共识装置或者上述计算机设备的内部存储单元，例如计算机设备的硬盘或内存。该计算机可读存储介质也可以是该计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(smart media card，SMC)，安全数字(secure digital，SD)卡，闪存卡(flash card)等。进一步地，该计算机可读存储介质还可以既包括该计算机设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该计算机设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (18)

  1. 一种基于区块链的区块共识方法，所述方法由计算机设备执行，所述方法包括：
    获取区块高度为M且在第N轮生成的提议区块，对所述提议区块进行合法性验证M和N均为正整数；
    通过智能合约执行所述提议区块中的交易数据，得到目标合约执行结果，并将所述提议区块的区块哈希值与所述目标合约执行结果关联缓存至临时列表中；所述临时列表包括区块高度为M的N个合约执行结果，所述N个合约执行结果包括所述目标合约执行结果；
    在通过所述智能合约执行所述交易数据的过程中，并行对所述提议区块进行两轮共识投票处理，得到第一共识结果；
    若所述第一共识结果为共识通过结果，则在所述临时列表中获取所述提议区块的区块哈希值所映射的目标合约执行结果，将所述提议区块和所述目标合约执行结果关联存储至区块链中。
  2. 根据权利要求1所述的方法，所述方法还包括：
    对所述提议区块进行合法性验证得到合法性验证结果；
    所述通过智能合约执行所述提议区块中的交易数据，得到目标合约执行结果，包括：
    若所述合法性验证结果为合法结果，则通过智能合约执行所述提议区块中的交易数据，得到所述目标合约执行结果。
  3. 根据权利要求1所述的方法，所述临时列表是通过键值对来存储所述提议区块的区块哈希值与所述目标合约执行结果，所述提议区块的区块哈希值为所述键值对中的键，所述目标合约执行结果为所述键值对中的值。
  4. 根据权利要求2所述的方法，所述对所述提议区块进行合法性验证得到合法性验证结果，包括：
    获取所述提议区块中的交易数据，对所述交易数据进行哈希运算，得到待验证哈希值；
    根据所述提议区块中的默克尔树路径对所述待验证哈希值进行哈希运算，得到待验证树根哈希值；
    从所述提议区块的区块头中获取默克尔树根哈希值；
    若所述待验证树根哈希值和所述默克尔树根哈希值相同，则确定所述提议区块的合法性验证结果为合法结果；
    若所述待验证树根哈希值和所述默克尔树根哈希值不相同，则确定所述提议区块的合法性验证结果为非法结果。
  5. 根据权利要求2所述的方法，所述对所述提议区块进行合法性验证得到合法性验证结果，包括：
    获取所述提议区块中的交易数据；
    调用交易验证函数对所述交易数据进行验证，得到交易验证结果；
    若所述交易验证结果为有效结果，则确定所述提议区块的合法性验证结果为合法结果；
    若所述交易验证结果为无效结果，则确定所述提议区块的合法性验证结果为非法结果。
  6. 根据权利要求2所述的方法，所述对所述提议区块进行合法性验证得到合法性验证结果，包括：
    在区块链中获取所述提议区块的父区块的区块哈希值，作为目标父区块哈希值；
    从所述提议区块的区块头中获取父区块哈希值，作为待验证父区块哈希值；
    若所述待验证父区块哈希值和所述目标父区块哈希值相同，则确定所述提议区块的合法性验证结果为合法结果；
    若所述待验证父区块哈希值和所述目标父区块哈希值不相同，则确定所述提议区块的合法性验证结果为非法结果。
  7. 根据权利要求2所述的方法，所述对所述提议区块进行合法性验证得到合法性验证结果，包括：
    获取所述提议区块相关联的签名数据；
    获取提议节点的公钥，通过所述公钥验证所述签名数据，得到签名验证结果；
    若所述签名验证结果为验签成功，则确定所述提议区块的合法性验证结果为合法结果；属于验签成功的签名数据是由所述提议节点通过所拥有的私钥对所述提议区块进行签名得到的；所述属于验签成功的签名数据相关联的提议区块是由所述提议节点生成的；
    若所述签名验证结果为验签失败，则确定所述提议区块的合法性验证结果为非法结果。
  8. 根据权利要求1所述的方法，所述通过智能合约执行所述提议区块中的交易数据，得到目标合约执行结果，将所述提议区块的区块哈希值与所述目标合约执行结果关联缓存至临时列表中，包括：
    获取所述提议区块中的交易数据，调用用于执行所述交易数据的智能合约中的交易执行函数；
    根据所述交易执行函数获取针对所述交易数据的读取数据；
    根据所述读取数据以及所述交易数据执行所述交易执行函数，得到所述交易数据的目标合约执行结果；
    将所述提议区块的区块哈希值与所述目标合约执行结果关联缓存至临时列表中。
  9. 根据权利要求2所述的方法，所述对所述提议区块进行两轮共识投票处理，得到第一共识结果，包括：
    在第一轮共识投票中，根据所述提议区块的合法性验证结果对所述提议区块进行预投票处理，得到预投票结果；
    在第二轮共识投票中，根据所述预投票结果对所述提议区块进行预提交处理，得到第一共识结果。
  10. 根据权利要求9所述的方法，所述在第一轮共识投票中，根据所述提议区块的合法性验证结果对所述提议区块进行预投票处理，得到预投票结果，包括：
    在第一轮共识投票中，根据所述合法结果将第一预投票结果确定为针对所述提议区块的第一赞成结果；
    将所述第一预投票结果广播至多个目标共识节点；
    接收所述多个目标共识节点分别发送的第二预投票结果；多个第二预投票结果中存在针对所述提议区块的第一赞成结果，或者多个第二预投票结果中存在针对所述提议区块的第一反对结果；
    根据所述第一预投票结果和所述多个第二预投票结果，确定针对所述提议区块的第一赞成票数量和第一反对票数量；
    若所述第一赞成票数量超过第一预投票阈值，确定预投票结果为预投票成功结果；
    若所述第一反对票数量超过第二预投票阈值，确定预投票结果为预投票失败结果。
  11. 根据权利要求9所述的方法，所述在第二轮共识投票中，根据所述预投票结果对所述提议区块进行预提交处理，得到第一共识结果，包括：
    若所述预投票结果为预投票成功结果，则将第一预提交结果确定为针对所述提议区块的第二赞成结果；
    若所述预投票结果为预投票失败结果，则将第一预提交结果确定为针对所述提议区块的第二反对结果；
    将所述第一预提交结果广播至多个目标共识节点；
    接收所述多个目标共识节点分别发送的第二预提交结果；多个第二预提交结果中存在针对所述提议区块的第二赞成结果，或者多个第二预提交结果中存在针对所述提议区块的第二反对结果；
    根据所述第一预提交结果和所述多个第二预提交结果，确定针对所述提议区块的第二赞成票数量和第二反对票数量；
    若所述第二赞成票数量超过第一预提交阈值，确定第一共识结果为共识通过结果；
    若所述第二反对票数量超过第二预提交阈值，确定第一共识结果为共识不通过结果。
  12. 根据权利要求2所述的方法，所述方法还包括：
    若所述合法性验证结果为非法结果，则对所述提议区块进行两轮共识投票处理，得到第二共识结果；
    若所述第二共识结果为共识通过结果，则从已完成共识节点中同步已存储至所述区块链中区块高度为M的所述提议区块，以及所述提议区块对应的目标合约执行结果；所述已完成共识节点为成功将所述提议区块以及所述目标合约执行结果存储至区块链中的目标共识节点。
  13. 根据权利要求2所述的方法，所述对所述提议区块进行合法性验证得到合法性验证结果，包括：
    若在验证时间阈值内，获取到区块高度为M且在第N轮生成的提议区块，则对所述提议区块进行合法性验证；
    则所述方法还包括：
    若在验证时间阈值内，未获取到区块高度为M且在第N轮生成的提议区块，则构建临时空区块；
    对所述临时空区块进行两轮共识投票处理，得到第三共识结果；
    若所述第三共识结果为共识通过结果，则从已完成共识节点中同步已存储至所述区块链中区块高度为M的所述提议区块，以及所述提议区块对应的目标合约执行结果；所述已完成共识节点为成功将所述提议区块以及所述目标合约执行结果存储至区块链中的目标共识节点。
  14. 根据权利要求1所述的方法，在所述将所述提议区块和所述目标合约执行结果关联存储至区块链中的步骤之后，还包括：
    将所述临时列表中区块高度为M的N个合约执行结果删除；
    或者，
    获取所述临时列表中所有合约执行结果的总数量，若所述总数量大于或等于存储数量阈值，则删除所述临时列表中的所述所有合约执行结果；所述所有合约执行结果包括一个或多个区块高度分别对应的合约执行结果。
  15. 一种基于区块链的区块共识装置，所述装置部署在计算机设备上，所述装置包括：
    区块验证模块，用于获取区块高度为M且在第N轮生成的提议区块，M和N均为正整数；
    合约执行模块，用于通过智能合约执行所述提议区块中的交易数据，得到目标合约执行结果，并将所述提议区块的区块哈希值与所述目标合约执行结果关联缓存至临时列表中；所述临时列表包括区块高度为M的N个合约执行结果，所述N个合约执行结果包括所述目标合约执行结果；
    第一共识模块，用于在通过所述智能合约执行所述交易数据的过程中，并行对所述提议区块进行两轮共识投票处理，得到第一共识结果；
    第一存储模块，用于若所述第一共识结果为共识通过结果，则在所述临时列表中获取所述提议区块的区块哈希值所映射的目标合约执行结果，将所述提议区块和所述目标合约执行结果关联存储至区块链中。
  16. 一种计算机设备，包括：处理器、存储器以及网络接口；
    所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供网络通信功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行权利要求1-14任一项所述的方法。
  17. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，该计算机程序适于由处理器加载并执行权利要求1-14任一项所述的方法。
  18. 一种计算机程序产品，当所述计算机程序产品被执行时，用于执行权利要求1-14任一项所述的方法。
PCT/CN2022/080103 2021-03-12 2022-03-10 一种基于区块链的区块共识方法以及相关设备 WO2022188831A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/071,271 US20230092484A1 (en) 2021-03-12 2022-11-29 Block chain-based block consensus method and related device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110273266.3 2021-03-12
CN202110273266.3A CN112685796B (zh) 2021-03-12 2021-03-12 一种基于区块链的区块共识方法以及相关设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/071,271 Continuation US20230092484A1 (en) 2021-03-12 2022-11-29 Block chain-based block consensus method and related device

Publications (1)

Publication Number Publication Date
WO2022188831A1 true WO2022188831A1 (zh) 2022-09-15

Family

ID=75455632

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/080103 WO2022188831A1 (zh) 2021-03-12 2022-03-10 一种基于区块链的区块共识方法以及相关设备

Country Status (3)

Country Link
US (1) US20230092484A1 (zh)
CN (1) CN112685796B (zh)
WO (1) WO2022188831A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116055064A (zh) * 2023-03-17 2023-05-02 安徽中科晶格技术有限公司 区块链分片中多区块同时共识方法、***、介质及设备

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020258252A1 (zh) * 2019-06-28 2020-12-30 深圳市网心科技有限公司 一种区块链数据的共识方法及相关设备
CN112685796B (zh) * 2021-03-12 2021-06-18 腾讯科技（深圳）有限公司 一种基于区块链的区块共识方法以及相关设备
CN113179272B (zh) * 2021-04-28 2022-02-25 爱云保(上海)科技有限公司 基于智能合约的区块链跨链交互方法、装置和计算机可读存储介质
CN112887436B (zh) * 2021-04-28 2021-08-03 支付宝(杭州)信息技术有限公司 一种共识方法、共识节点和流水线方式的区块链***
CN113760999A (zh) * 2021-04-30 2021-12-07 支付宝(杭州)信息技术有限公司 区块链交易执行方法、区块链节点及控制装置
CN113408010B (zh) * 2021-07-14 2023-08-11 湖北央中巨石信息技术有限公司 基于区块链的异步共识方法及***及装置及介质
CN113342838B (zh) * 2021-08-06 2021-11-09 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN113783935B (zh) * 2021-08-12 2022-04-01 清华大学 一种拜占庭容错方法及装置
CN115859343A (zh) * 2021-09-24 2023-03-28 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置以及可读存储介质
CN113610531B (zh) * 2021-10-09 2021-12-14 支付宝(杭州)信息技术有限公司 一种共识方法、区块链***和共识节点
CN114153827B (zh) * 2021-10-11 2023-01-10 北京天德科技有限公司 一种基于区块链***的交易数据移除方法
CN114281888A (zh) * 2021-10-30 2022-04-05 ***股份有限公司 一种区块链共识方法、装置、设备及存储介质
CN114219650B (zh) * 2022-02-21 2022-05-20 浙江数秦科技有限公司 一种低交易延迟的区块链共识方法
CN114745131A (zh) * 2022-04-06 2022-07-12 广东钜联信息科技有限公司 一种区块链的pbft改进共识算法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN109447810A (zh) * 2018-11-29 2019-03-08 杭州秘猿科技有限公司 并行区块链共识方法、***、电子设备和计算机可读存储介质
CN110020859A (zh) * 2019-03-28 2019-07-16 杭州秘猿科技有限公司 一种并行执行的区块链共识方法、装置及电子设备
CN111199485A (zh) * 2020-01-02 2020-05-26 支付宝(杭州)信息技术有限公司 用于在区块链节点处进行交易数据处理的方法及装置
CN111526217A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链中的共识方法和***
CN111523901A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 基于拜占庭容错算法的区块链的共识方法、装置及***
CN112685796A (zh) * 2021-03-12 2021-04-20 腾讯科技（深圳）有限公司 一种基于区块链的区块共识方法以及相关设备

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN109447810A (zh) * 2018-11-29 2019-03-08 杭州秘猿科技有限公司 并行区块链共识方法、***、电子设备和计算机可读存储介质
CN110020859A (zh) * 2019-03-28 2019-07-16 杭州秘猿科技有限公司 一种并行执行的区块链共识方法、装置及电子设备
CN111199485A (zh) * 2020-01-02 2020-05-26 支付宝(杭州)信息技术有限公司 用于在区块链节点处进行交易数据处理的方法及装置
CN111526217A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链中的共识方法和***
CN111523901A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 基于拜占庭容错算法的区块链的共识方法、装置及***
CN112685796A (zh) * 2021-03-12 2021-04-20 腾讯科技（深圳）有限公司 一种基于区块链的区块共识方法以及相关设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116055064A (zh) * 2023-03-17 2023-05-02 安徽中科晶格技术有限公司 区块链分片中多区块同时共识方法、***、介质及设备

Also Published As

Publication number Publication date
CN112685796A (zh) 2021-04-20
CN112685796B (zh) 2021-06-18
US20230092484A1 (en) 2023-03-23

Similar Documents

Publication Publication Date Title
WO2022188831A1 (zh) 一种基于区块链的区块共识方法以及相关设备
WO2021244208A1 (zh) 区块链的提案消息处理方法、装置、设备以及存储介质
US11863624B2 (en) Fast propagation of recent transactions over a blockchain network
US20210256016A1 (en) Blockchain system and method
WO2023045620A1 (zh) 一种交易数据处理方法、装置、计算机设备以及存储介质
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
US20190156332A1 (en) Optimization of high volume transaction performance on a blockchain
WO2022121612A1 (zh) 区块链网络的信息处理方法、装置、设备及存储介质
WO2017071337A1 (zh) 管理数据库表数据的方法、装置及***
WO2023011022A1 (zh) 基于区块链的数据处理方法、设备及计算机可读存储介质
US20230370285A1 (en) Block-chain-based data processing method, computer device, computer-readable storage medium
US20230259938A1 (en) Blockchain-based data processing method and apparatus, device, readable storage medium and computer program product
US20230054245A1 (en) Distributed database
JP2014524204A (ja) キーバリューストレージに対するデータの保存および読み出しを行う方法およびシステム
WO2023040453A1 (zh) 一种交易信息处理方法及装置
Vizier et al. ComChain: A blockchain with Byzantine fault‐tolerant reconfiguration
WO2021233109A1 (zh) 基于区块链的消息处理方法、装置、设备以及存储介质
WO2022183518A1 (zh) 一种面向云计算的高性能区块链架构方法
US20230336368A1 (en) Block chain-based data processing method and related apparatus
WO2023168993A1 (zh) 基于区块链的数据处理方法、装置、设备、介质及产品
WO2023098327A1 (zh) 基于区块链的区块处理方法、装置、设备、存储介质及程序产品
WO2024066974A1 (zh) 基于区块链的数据处理方法、设备以及可读存储介质
WO2024007689A1 (zh) 共识网络的数据处理方法、装置、程序产品、设备和介质
US20240015037A1 (en) Data processing method and apparatus for consensus network, program product, device, and medium
US12034806B2 (en) Fast propagation of recent transactions over a blockchain network

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08.02.2024)