Consensus method, consensus node and blockchain system in a blockchain system

Abstract

A consensus method, a consensus node and a blockchain system in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data, the second consensus node storing verification data, the verification data comprising a plurality of hash values of respective states, the method comprising: the first consensus node sending a consensus proposal to the second consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions; the second consensus node verifying the read set based on the verification data, and performing consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on a result of the verification.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the technical field of blockchains, and particularly relate to a consensus method in a blockchain system, a consensus node and a blockchain system. BACKGROUND

[0002] Blockchain is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. In a blockchain system, data blocks are combined in a chain-like data structure in a time sequence, and a distributed ledger is ensured to be unalterable and unforgeable by cryptography. Due to the characteristics of decentralization, information unalterability and autonomy, blockchain has received more and more attention and application. In a blockchain system, a full node is generally used as the minimum facility for participating in consensus, and the full node needs to include full data to support the consensus function. SUMMARY

[0003] The purpose of the present application is to provide a light consensus node and a consensus scheme in a blockchain system, which can greatly save storage resources in the blockchain system and provide system efficiency.

[0004] The first aspect of the present specification provides a consensus method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data, the state data comprising a plurality of states, the second consensus node storing verification data, the verification data corresponding to the plurality of states, the method comprising:

[0005] The first consensus node sends a consensus proposal to the second consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;

[0006] The second consensus node verifies the read set based on the verification data, and performs consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on the result of the verification.

[0007] The second aspect of the present specification provides a consensus method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data, the state data comprising a plurality of states, the second consensus node storing verification data, the verification data corresponding to the plurality of states, the method being performed by the second consensus node, comprising:

[0008] receiving a consensus proposal from the first consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;

[0009] verify the read set based on the verification data, and reach consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on a result of the verification.

[0010] A third aspect of the present specification provides a blockchain system, comprising a first consensus node and a second consensus node, the first consensus node storing state data, the state data comprising a plurality of states, the second consensus node storing verification data corresponding to the plurality of states,

[0011] The first consensus node is configured to send a consensus proposal to the second consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;

[0012] The second consensus node is configured to verify the read set based on the verification data, and reach consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on a result of the verification.

[0013] A fourth aspect of the present specification provides a consensus node in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data, the state data comprising a plurality of states, the second consensus node storing verification data corresponding to the plurality of states, the second consensus node comprising:

[0014] The receiving unit is configured to receive a consensus proposal from the first consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;

[0015] The verification unit is configured to verify the read set based on the verification data, and reach consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on a result of the verification.

[0016] A fifth aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer program causes the computer to execute the method of the second aspect.

[0017] A sixth aspect of the present specification provides a consensus node, comprising a memory and a processor, the memory storing executable code, and the processor executing the executable code to implement the method of the second aspect.

[0018] In the scheme of the embodiments of the present specification, only state verification data is saved in the light consensus node, and by including the read set in the consensus proposal, the light consensus node can verify the read set based on the state verification data, so as to participate in the consensus process, greatly saving the hardware cost and time cost of data storage, and improving the performance and efficiency of the blockchain system. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0020] Figure 1 A blockchain architecture diagram in an embodiment is shown;

[0021] Figure 2 A consensus process diagram in the PBFT consensus algorithm is shown;

[0022] Figure 3 A structure diagram of the blockchain data storage of the consensus node in the related art is shown;

[0023] Figure 4 A structure diagram of the MPT tree is shown;

[0024] Figure 5 A state hash value tree and a storage hash value tree in the LVP in the embodiments of the present specification are shown;

[0025] Figure 6 A state hash value tree in the embodiments of the present specification is shown;

[0026] Figure 7 A flowchart of the consensus method in the embodiments of the present specification is shown;

[0027] Figure 8 A flowchart of the consensus method in another embodiment of the present specification is shown;

[0028] Figure 9 A structure diagram of a light consensus node in a blockchain system in the embodiments of the present specification is shown. DETAILED DESCRIPTION

[0029] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described in the specification below in conjunction with the drawings in the specification embodiments. Obviously, the described embodiments are only part of the embodiments of the specification, not all. Based on the embodiments in the specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the specification.

[0030] Figure 1 A blockchain architecture diagram in an embodiment is shown. In Figure 1 In the shown blockchain architecture diagram, N nodes are included in the blockchain 100, Figure 1 Nodes 1-8 are schematically shown. The connection between the nodes schematically represents a P2P (Peer to Peer) connection, which can be, for example, a TCP connection, etc., for transmitting data between the nodes.

[0031] A transaction in the blockchain field can refer to a task unit executed in the blockchain and recorded in the blockchain. The transaction usually includes a sending field (From), a receiving field (To) and a data field (Data). Among them, in the case of a transfer transaction, the From field represents the account address that initiates the transaction (i.e. initiates the transfer task to another account), the To field represents the account address that receives the transaction (i.e. receives the transfer), and the Data field includes the transfer amount.

[0032] The blockchain can provide the function of a smart contract. The smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system. The smart contract can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the address of the smart contract, so that each node in the blockchain distributes the smart contract code.

[0033] In the scenario of deploying a contract, for example, Bob sends a transaction containing the information of creating a smart contract (i.e. deploying a contract) to the blockchain as shown in Figure 1 The data field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the to field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93…" of the contract is determined, each node adds the contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, stores the contract code, saves the hash value of the contract code in the state storage of the contract, and thus the contract creation is successful.

[0034] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain as shown in Figure 1 The from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), the to field is the address of the smart contract to be called (i.e., “0x6f8ae93…”) as described above, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and updating the state database based on the execution of the contract.

[0035] The consensus mechanism in the blockchain is a mechanism for the nodes in the blockchain to reach a consensus on the block information (or block data) in the whole network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among various consensus algorithms, the consensus is usually successful after a preset number of consensus nodes reach an agreement on the data to be consensus (i.e., consensus proposal). Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes among the N consensus nodes reach an agreement, the consensus is determined to be successful. In the related technology, in order to realize the consensus function, the full amount of the ledger is stored on the consensus node, that is, all blocks and the states of all accounts are stored. Thus, each node in the blockchain can produce the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.

[0036] Figure 2 A schematic diagram of the consensus process in the PBFT consensus algorithm is shown in FIG. 1. As shown in Figure 2As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four stages: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume that a blockchain includes four consensus nodes: nodes n1-n4, where node n1 is a primary node, for example, and nodes n2-n4 are secondary nodes, for example. According to the PBFT algorithm, f = 1 malicious node can be tolerated in nodes n1-n4. Specifically, in the Request stage, a user of the blockchain can send a request to node n1 through a user device of the user, where the request is in the form of a blockchain transaction, for example. In the Pre-Prepare stage, after receiving multiple transactions from one or more user devices, node n1 can package the multiple transactions into a consensus proposal, send the consensus proposal and a signature of the consensus proposal by node n1 to other consensus nodes (i.e., nodes n2-n4) for generating a block, where the consensus proposal can include transaction bodies of the multiple transactions and a commit order of the multiple transactions, and the like. In the Prepare stage, each secondary node can sign the consensus proposal and send it to other nodes. Assume that node n4 is a malicious node, and after receiving 2f = 2 signatures of the consensus proposal from other consensus nodes, respectively, node n1, node n2, and node n3 can determine that the Prepare stage is complete and can proceed to the Commit stage. For example, as shown in FIG. 3B, after receiving the signatures of node n2 and node n3, node n1 verifies that the signatures of node n2 and node n3 are both correct signatures of the consensus proposal, and then determines that the Prepare stage is complete. After receiving the signature of node n3 and the signature of node n1 in the Pre-Prepare stage and verifying that they are correct, node n2 determines that the Prepare stage is complete. Figure 2 In the Commit stage, each consensus node signs the consensus proposal for the Commit stage and sends it to other consensus nodes. After receiving 2f = 2 signatures of the Commit stage from other consensus nodes, each consensus node can determine that the Commit stage is complete and the consensus is successful. For example, after receiving the signatures of the Commit stage of node n2 and node n3 and verifying them, node n1 determines that the Commit stage is complete. Thus, node n1 can execute the multiple transactions according to the consensus proposal, generate and store a block (e.g., block N) including the multiple transactions, update the world state according to the execution result of the multiple transactions, and return the execution result of the multiple transactions to the user device. Similarly, after determining that the Commit stage is complete, node n2 and node n3 execute the multiple transactions, update the world state according to the execution result of the multiple transactions, and generate and store block N. Through the above process, the storage consistency of nodes n1, n2, and n3 is achieved. That is, nodes n1-n4 can still achieve consensus success on the consensus proposal and complete execution of the block in the presence of one malicious node.

[0037] Figure 3is a structural diagram of a blockchain data storage of a consensus node in the related art. In Figure 3 In the illustrated blockchain data storage, the block header of each block includes several fields, such as a previous block hash previous_Hash (Prev Hash in the figure), a nonce Nonce (this nonce is not a random number in some blockchain systems, or the nonce in the block header is not enabled in some blockchain systems), a timestamp Timestamp, a block number Block Num, a state tree root hash State_Root, a transaction tree root hash Transaction_Root, a receipt tree root hash Receipt_Root, and the like. Among them, the Prev Hash in the block header of the next block (such as block N+1) points to the previous block (such as block N), that is, the block hash value (that is, the hash value of the block header) of the previous block. In this way, the next block on the blockchain realizes the locking of the previous block through the block header. In particular, as described previously, the state_root is the hash value of the root of the state tree (state trie) composed of the states of all accounts in the current block, and the state tree is, for example, an MPT tree (Merkle Patricia Tree).

[0038] The MPT tree is a tree structure combining a Merkle Tree and a Patricia Tree (a more space-saving Trie tree, a dictionary tree). The Merkle Tree algorithm calculates a Hash value for each leaf node, then connects two by two to calculate the Hash again, until the topmost Merkle root. The improved MPT tree is used in Ethereum, and the MPT tree is, for example, a 16-ary tree structure.

[0039] The state tree contains key and value pairs of the storage content corresponding to each account in the Ethereum network. The "key" in the state tree can be a 160-bit identifier (address of the Ethereum account), and the characters contained in the account address are distributed in the nodes in the path from the root node to the leaf node of the state tree. Referring to Figure 3 As shown in the MPT state tree, the leaf nodes (such as node t4 and node t5) also include the values of each account. Among them, when the account is a user account (also known as an external account), for example Figure 3 the account A in Figure 3The Value of the account B in the account includes a counter (Nonce), a balance (Balance), a contract code hash (CodeHash), and a storage root hash (Storage_root). The counter represents the number of transactions sent from the account address for an external account, and the number of contracts created by the account for a contract account.

[0040] The nodes in the state tree are connected by hashing. Specifically, a hash value can be generated based on the data in the child nodes of a parent node, and the generated hash value is stored in the parent node. Figure 4 is a structural diagram of an MPT tree. It is assumed that Figure 4 The node labeled "t2" in Figure 3 The node labeled "t2" in Figure 3 The leaf node t4 in the state tree in Figure 4 As shown in Figure 4 The states included in each leaf node in Figure 4 The characters in the left box in each node in

[0041] In Figure 4 The child nodes of the node including "5" include leaf nodes, and when calculating the hash (324, 74) included in the node, the following formula (1) can be used for calculation:

[0042] hash (324, 74) = hash (hash (324, hash (state1)), hash (74, hash (a, c))) (1)

[0043] That is, when calculating the hash value hash (324, hash (state1)) of the leaf node t4 in Figure 4 The hash value hash (state1) of "324" and state1 in the node t4 is concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. In calculating the hash value hash (74, hash (a, c)) of the leaf node t4 in Figure 4The hash value of the node t1 in the state tree is obtained by concatenating the hash value of the node t2 and the hash value of the node t3 in the state tree, and taking the hash of the concatenated data, thereby generating the hash value of the node t1. The hash value of the node t1 is the state root of the state tree, which is recorded in the State_Root field of the block N.

[0044] Thus, the hash value included in each node between the leaf node and the root node in the state tree can be calculated from bottom to top, and finally the calculated hash value of the state root of the state tree can be recorded in the State_Root field of the block N. Figure 3 The hash value of the node t1 in the state tree is obtained by concatenating the hash value of the node t2 and the hash value of the node t3 in the state tree, and taking the hash of the concatenated data, thereby generating the hash value of the node t1. The hash value of the node t1 is the state root of the state tree, which is recorded in the State_Root field of the block N.

[0045] In a variant of the MPT tree, branch nodes can be included, which can connect multiple child nodes, and the branch node includes the hash value of the data in each child node connected by the branch node, that is, the branch node includes multiple hash values corresponding to multiple main nodes respectively, and the leaf node is connected after the branch node. The variant also includes an extension node, which can be connected before or after the branch node, and the extension node has one child node, and the extension node includes the hash value of all data in the child node connected by the extension node. In this variant of the MPT tree, the hash value of the root node can also be obtained recursively based on the nodes of each layer. The embodiment scheme of the present specification is also applicable to this variant of the MPT tree.

[0046] After the smart contract is deployed on the blockchain, a corresponding contract account is generated. The contract account generally has some states, which are defined by state variables in the smart contract and generate new values when the smart contract is created and executed. As shown in Figure 3 The related states of the contract are stored in a storage tree (storage trie), as shown in Figure 3 The storage tree of the contract corresponding to the account B is shown in FIG. 2. The hash value of the storage tree root node st1 is stored in the storage_root, thereby locking all states of the contract to the Value (i.e., the account state) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure, which is similar to the state tree shown in Figure 4 As shown in the state tree, each node in the path from the root node to the leaf node can include characters for addressing the variable name, and the leaf node stores the Value of the variable, thereby storing the key-value mapping of the variable name (which can also be referred to as the state address) to the state value. For example, referring to Figure 3The leaf nodes st2, st3 of the storage tree, for example, include the Value of variable a, the Value of variable b, and the like. Taking variable a as an example, the characters included in each node in the node path from the root node to the leaf node st2 in the storage tree constitute the variable name of variable a, which can also be composed of hexadecimal characters.

[0047] The calculation of the hash value of each node in the storage tree can refer to the method of calculating the hash value of a node in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash values of the part of the key included in the leaf node and the state in the leaf node are spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the leaf node. When calculating the hash value of a node other than a leaf node and a root node in the storage tree, the data in the node is directly spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the node.

[0048] In general, the FVP node includes tree-shaped state data, the leaf node of the state data includes the state of an account or a contract variable, each node in the path from the root node to the leaf node in the state data includes the key of the state, and the parent node in the state data includes a hash value calculated based on the data in its child nodes.

[0049] Still referring to Figure 3 After the node in the blockchain completes the execution of block N, it performs consensus on the next batch of transactions and executes block N+1 after the consensus passes, thereby generating state data corresponding to block N+1 similar to the execution of block N, which includes a state tree and a storage tree corresponding to each contract. The repeated data of the state data of block N+1 and the state data of block N can refer to the data in block N, and does not need to be stored repeatedly. In this way, in the case where each consensus node stores complete block data and state data, a large storage space needs to be occupied.

[0050] The embodiments of the present specification provide a light consensus node (Light Validating Peer, LVP), which only saves part of the state data, for example, saves the hash value data in the state tree and the storage tree, and does not save the Value (i.e., each state) of each account or variable in the state tree and the storage tree, while the blockchain also includes a full consensus node (Full Validating Peer, FVP) which is the same as the consensus node in the related art. Figure 5 A schematic diagram of the state hash value tree and the storage hash value tree in the LVP in the embodiments of the present specification is shown in FIG. 1. As shown in FIG. 1, the state hash value tree and the storage hash value tree in the LVP include a root node, a plurality of parent nodes, and a plurality of leaf nodes. Figure 5 As shown in FIG. 1, the state hash value tree and the storage hash value tree in the LVP include a root node, a plurality of parent nodes, and a plurality of leaf nodes. Figure 3In the state hash tree and the storage hash tree in the FVP, the state in the leaf node in the state tree and the storage tree is replaced by the hash value of the state, for example, state1 in node t4 in the state tree is replaced by hash(state1) in node t4 in the state hash tree, and state5 in node st2 in the storage tree is replaced by hash(state5) in node st2 in the storage hash tree. Figure 6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 5 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 6 For example, hash(324, 74) in the node including "5" in FIG. 6 can be calculated by the above formula (1). The storage hash tree can also have a structure similar to that shown in FIG. 7. In this way, Figure 6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 5 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 3 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 5 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 3 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses.

[0051] Figure 5 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 5 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figure 6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses. Figures 3-6 As shown in FIG. 6, the state hash tree in the FVP includes a root node, a plurality of nodes, and a plurality of leaf nodes. The root node in the state hash tree includes a root hash value of the state hash tree. The plurality of nodes in the state hash tree include a plurality of hash values. The plurality of leaf nodes in the state hash tree include a plurality of account addresses.

[0052] In the blockchain system based on the FVP and the LVP, by the consensus scheme provided by the embodiments of the present specification, only the state verification data is saved in the light consensus node, the read set is included in the consensus proposal, so that the light consensus node can verify the read set based on the state verification data, thereby participating in the consensus process, greatly saving the hardware cost and time cost of data storage, and improving the performance and efficiency of the blockchain system.

[0053] Figure 7 A flowchart of a consensus method in the embodiments of the present specification. The method can be executed by an FVP (as a master node) and one or more LVPs in a blockchain system. Figure 7 The FVP is schematically shown in FIG. 1. Figure 7 The FVP is schematically shown in FIG. 1.

[0054] As shown in FIG. 1, first, in step S701, the FVP obtains a read set corresponding to a plurality of transactions. Figure 7

[0055] It is assumed that FVP1 in the blockchain system is the master node, and FVP1 is taken as an example in the following description. FVP1 can receive transactions sent by users from user clients or other FVPs. The transaction can be a transfer transaction, or can be a transaction for calling a contract, etc. After receiving a certain amount of transactions, FVP1 can select a plurality of transactions from the received transactions for consensus, for generating a new block.

[0056] After selecting a plurality of transactions, FVP1 obtains a read set corresponding to the plurality of transactions. The read set includes the states of accounts and / or contract variables read from the state data according to the read operations included in the plurality of transactions, that is, the states of accounts and / or contract variables that need to be read from the state data when the plurality of transactions are executed, wherein the state data includes, for example, the state tree and the storage tree shown in FIG. 1. Figure 3

[0057] ​​Specifically, the FVP1 can obtain the read sets of the plurality of transactions respectively, and then can merge the read sets of the plurality of transactions respectively, that is, select the key-value pair of each variable (including account and contract variable) from the state data read when each variable is read for the first time, to obtain the read set corresponding to the plurality of transactions. Assuming that one of the plurality of transactions includes an update (for example, a decrease of a preset amount) to the balance of account A, the transaction needs to read the value of account A (that is, including Nonce and Balance) first when executed, and then obtain the new value of account A according to the read value of account A, for example, increase the Nonce value by 1 and decrease the Balance value by a preset amount according to the transaction, to obtain the updated Nonce value and Balance value of account A, which constitutes the updated value of account A. Therefore, the read set of the transaction includes the key-value pair of the read account A, and the write set of the transaction includes the key-value pair of the written account A. The read set of the plurality of transactions includes the Key-Value key-value pair of account A read from the state data, wherein the Key is the account address of account A, and the Value is the state of account A, which includes the Nonce value and the Balance value in the leaf node corresponding to account A.

[0058] Assuming that one of the plurality of transactions includes an update operation to variable a in the contract corresponding to account B, since the writing to variable a will cause the update to Storage_root in account B, the transaction also includes the write operation to account B. In order to write to account B and variable a, the read set of the transaction needs to include the Key-Value key-value pair of account B and the key-value pair of variable a. Assuming that the read of account B and variable a by the transaction is the first read from the state data, the read set of the plurality of transactions also includes the key-value pair of account B and the key-value pair of variable a read from the state data based on the transaction. Among them, the key of the Key-Value key-value pair of account B is the account address of account B, and the Value is the state of account B, which includes the values of Nonce, Balance, CodeHash and Storage_root in the leaf node corresponding to account B. The key of the Key-Value key-value pair of variable a is the variable name of variable a, and the Value is the state value of variable a. According to the read set of the plurality of transactions, when writing to account B in the transaction is executed, the updated Storage_root can be calculated according to the updated value of variable a, and combined with the Nonce, Balance, CodeHash of account B in the read set to obtain the updated value of account B. The updated value of variable a and the updated value of account B will be recorded in the write set of the transaction, for updating the state data.

[0059] In an embodiment, FVP1 can perform static analysis on each transaction, analyze the transaction body of each transaction and the contract code of the contract invoked in each transaction, and determine the account and / or variable name, i.e., key, that each transaction needs to read when executed, read the value corresponding to the key from the state data according to the obtained key, and generate the read set corresponding to the plurality of transactions. In another embodiment, FVP1 can pre-execute the plurality of transactions. FVP1 can pre-execute the plurality of transactions according to a preset arrangement order of the plurality of transactions, or FVP1 can pre-execute the plurality of transactions according to the receiving order of each transaction, and determine the arrangement order of the plurality of transactions in the consensus proposal according to the pre-execution order of each transaction.

[0060] When FVP1 pre-executes the plurality of transactions, when the value of an account or a contract variable is read for the first time, the value is read from the state data, and the read set of the plurality of transactions is generated according to the value of the account or the contract variable read for the first time. At the same time, FVP1 caches the value of the account or the contract variable read for the first time, updates the value of the account or the contract variable in the cache when the value of the account or the contract variable read for the first time is updated during the pre-execution of the plurality of transactions, and reads the value of the account or the contract variable in the cache when the value of the account or the contract variable is read again during the pre-execution of the plurality of transactions, wherein the value of the account or the contract variable read again does not need to be written into the read set of the plurality of transactions.

[0061] In step S703, FVP sends a consensus proposal to LVP, wherein the consensus proposal includes the read set of the plurality of transactions.

[0062] FVP1 can generate a consensus proposal for consensus on the arrangement order of the plurality of transactions. In an embodiment, the consensus proposal can include a transaction list of the plurality of transactions, wherein the transaction list includes the transaction bodies of the plurality of transactions arranged in order, and the consensus proposal further includes the read set of the plurality of transactions obtained as described above. By including the read set in the consensus proposal, the verification of the read set can be performed in the PP phase, i.e., it is determined whether FVP1 is malicious in the PP phase. If it is determined that FVP1 is malicious in the PP phase, the consensus process can be ended in advance, so that the subsequent preparation phase and submission phase are not needed, the computing resources are saved, and the system efficiency in the blockchain is improved. Figure 2

[0063] ​In another implementation, the consensus proposal may include transaction identifiers (such as hash values ​​of each transaction) of multiple transactions arranged in sequence and the aforementioned read set. Meanwhile, FVP1 or other FVPs that receive transactions from user equipment can broadcast the transaction bodies of multiple transactions to other consensus nodes, thereby reducing the data size of the consensus proposal and saving the computational load used for signing during the consensus process.

[0064] In step S705, LVP verifies whether the read set is correct based on the verification data.

[0065] In one implementation, the LVP stores Figure 3 The LVP uses the hash values ​​of each state in the state tree and storage tree, along with index data (such as account addresses or variable names) to those hash values, as verification data. After obtaining the read set from the consensus proposal, the LVP can use the hash values ​​of each state to verify each state in the read set. For example, if the read set includes the value of account A, the LVP can obtain the state hash value of account A from the verification data and use it to verify the value of account A. That is, it verifies whether the value of account A in the read set corresponds to the state hash value of account A stored locally. If they correspond, it can be determined that the value of account A in the read set is the correct state. If the read set includes the value of account B and the value of variable a, the LVP can obtain the state hash values ​​of account B and variable a from the verification data to verify the value of account B and the value of variable a in the read set respectively.

[0066] In another implementation, the LVP stores, for example... Figure 5 The state hash tree and storage hash tree shown serve as verification data. After obtaining the read set from the consensus proposal, LVP can perform Simplified Payment Verification (SPV) on each state in the read set based on the state hash tree and storage hash tree. For example, if the read set includes the value of account A, LVP can calculate the hash value (e.g., hash1) of the value of account A in the read set. Based on the values ​​of other leaf nodes in the state hash tree (i.e., state hash values) and hash1, it calculates the hash values ​​of each node layer by layer upwards until it calculates the root hash value (e.g., root1) of the state hash tree. It then determines whether root1 matches the root hash value of the state hash tree stored in LVP. If they match, the value of account A in the read set is considered correct. If the read set includes the value of account B and the value of variable a, LVP can similarly perform SPV verification on the value of account B and the value of variable a based on the state hash tree and storage hash tree.

[0067] In an implementation, when the verification data corresponding to the MPT tree variant is stored in the LVP, since the hash values of each state in the MPT tree variant are similarly included in the verification data, and each layer node in the verification data is connected by hashing, the read set can be similarly verified based on the verification data, which will not be described here.

[0068] In addition, the block header of each block can also be stored in the LVP, such as Figure 3 As shown in the above, the block header can include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree, and the block header can be used for spv verification of transaction, receipt and other data, and can be used to generate the block header of the next block.

[0069] In step S707, the consensus nodes (including the FVP and the LVP) complete the consensus process of the plurality of transactions.

[0070] The LVP verifies the read set received from the FVP based on the locally stored verification data, and in the case of passing the verification, that is, the read set is a correct read set, so that the LVP can perform similar node functions based on the read set in the subsequent FVP, such as performing transactions, generating blocks and other functions. After the LVP passes the verification, it can complete the consensus process of the plurality of transactions, including completing the PP phase, P phase and C phase as shown in Figure 2 If the verification fails, it can be determined that the master node has the possibility of cheating, and the LVP can end the consensus process as soon as possible and start the process of replacing the master node, thereby improving the efficiency of the blockchain system.

[0071] In step S709, the LVP executes the plurality of transactions according to the read set.

[0072] After the consensus success of the consensus proposal, the LVP can execute the plurality of transactions in the consensus proposal based on the states in the read set. Specifically, when the LVP needs to read the state of an account or a variable in the process of executing a transaction, if it is the first reading of the account or the variable, the state of the account or the variable can be found from the read set, the execution of the transaction is performed based on the state of the account or the variable, and the write set of the transaction is obtained according to the write operation on the account or the contract variable in the transaction, which includes the key-value pair of the account or the key-value pair of the contract account and the contract variable in the write set, for updating the state in the state data. After the LVP reads the state of the account or the contract variable from the read set, the state can be cached, and the state of the account or the contract variable is updated in the cache when writing to the account or the contract variable, for subsequent reading of the state of the account or the contract variable in the process of executing the transaction. Since the state of the account or the variable in the read set has been verified, that is, the current correct state of the account or the variable, therefore, the execution result of executing the transaction based on the state in the read set is consistent with the execution result of executing the transaction based on the state in the state data by the FVP.

[0073] Specifically, assuming that one of the plurality of transactions includes an update to the balance of account A as described above, the LVP first reads the value of account A from the read set of the plurality of transactions (assuming the read value is V1) and stores it in the cache, updates V1 according to the transaction, thereby obtaining the updated value of account A (assuming the value is V2), wherein V2 includes an updated Nonce value and an updated Balance value, so that the updated key-value pair of account A can be written in the write set of the transaction, and the value of account A in the cache is updated.

[0074] Assuming that one of the plurality of transactions includes a write to the variable a of the contract corresponding to account B as described above, the LVP first reads the value of account B (assuming V3) and the value of variable a (assuming V4) from the read set of the plurality of transactions, processes V4 according to the transaction to obtain the updated value of variable a (assuming V5), calculates the hash value of V5, and substitutes it into the storage hash value tree in Figure 5 , calculates the hash value of the root node st1, and uses the hash value of the root node st1 as the updated storage_root of account B, and combines the Nonce, Balance and CodeHash of account B in the read set of the transaction to calculate the updated value of account B (assuming V6), so that the updated key-value pair of account B and the updated key-value pair of variable a can be included in the write set of the transaction.

[0075] While LVP executes multiple transactions based on the read set, if FVP1 has previously pre-executed multiple transactions, as mentioned earlier, the order in which FVP1 pre-executes these transactions corresponds to the order of transactions in the consensus proposal. Therefore, FVP1's reading, updating, and writing of the state during pre-execution of multiple transactions are consistent with its execution of multiple transactions. Consequently, the write set obtained from pre-executing multiple transactions can be used as the write set for executing those transactions, and receipts for the multiple transactions can be obtained from this write set. If FVP1 has not previously pre-executed multiple transactions, it can execute those transactions according to the read set or by reading the state from the state data, following the order of transactions in the consensus proposal. In both methods, the write set and receipts for the multiple transactions obtained by FVP1 are consistent with the write set and receipts for LVP's execution of multiple transactions.

[0076] In step S711, consensus nodes (including FVP and LVP) reach a consensus on the execution results of multiple transactions.

[0077] Consensus nodes can similarly pass through Figure 2 The consensus process shown achieves consensus on the execution results of multiple transactions. Specifically, after executing multiple transactions and obtaining the write sets and receipts for each transaction, each consensus node calculates the state tree root hash value, transaction tree root hash value, and receipt tree root hash value corresponding to each transaction based on the transaction bodies, write sets, and receipts. Based on the state tree root hash value, transaction tree root hash value, receipt tree root hash value, and the block hash of the previous block (i.e., the block header hash value, such as...),... Figure 3 The Prev Hash (as shown in the diagram) calculates the block hash (i.e., the block header hash of block B1) of the block corresponding to these multiple transactions. FVP1 can send a consensus proposal to other consensus nodes during the PP phase, which includes the block hash of block B1. After receiving this consensus proposal, LVP compares the block hash received from FVP1 with its own calculated block hash of block B1. If they match, LVP signs the block hash and sends it to all other consensus nodes. This completes the process. Figure 2 After the PP, P, and C phases, consensus on the block hash is achieved. Once the consensus nodes have reached a consensus on the block hash, it ensures that the execution results of multiple transactions are consistent across all nodes, allowing each node to update its storage based on the execution results of multiple transactions.

[0078] In step S713, LVP updates the verification data based on the write set of multiple transactions.

[0079] Specifically, after obtaining the write set of each transaction, the LVP obtains a write set (e.g., wset1) corresponding to the plurality of transactions based on the write set of each transaction, the write set wset1 including key-value pairs of accounts or key-value pairs of contract accounts and contract variables for updating state data according to the write operations of the plurality of transactions. After the execution results of the plurality of transactions are successfully consensus, the LVP can update the verification data in the LVP based on the hash values of each state in the wset1.

[0080] In an embodiment, the verification data in the LVP includes the hash values of the states of each account and each contract variable. Assuming that the write set wset1 includes the key-value pair of account A to be written, the LVP can find the storage location of the value hash value corresponding to the key in the verification data based on the key of account A in the wset1, and write the hash value of the state corresponding to the key in the wset1 to the storage location.

[0081] Assuming that the write set wset1 includes the key-value pair of account B to be written and the key-value pair of variable a, the LVP first calculates the updated state hash value according to the updated value of variable a, and updates the state hash value of variable a in the verification data. Then, the LVP calculates the updated state hash value according to the updated value of account B, and updates the state hash value of account B in the verification data.

[0082] In another embodiment, the verification data in the LVP includes a state hash value tree and a storage hash value tree as shown in Figure 5 The LVP can first update the state hash values in the leaf nodes corresponding to the plurality of states in the write set in the state hash value tree and the storage hash value tree as described in the above embodiment. Then, based on the updated leaf nodes, the hash values included in each layer node in the state hash value tree and the storage hash value tree can be updated upwards until the hash values of the root nodes of the state hash value tree and the storage hash value tree are updated.

[0083] In addition, after the block hash is consensus, the LVP can store the block header of the generated block for SPV verification, and for the generation of the next block.

[0084] While the LVP updates the storage, the FVP1 also updates the storage according to the execution results of the plurality of transactions, specifically, the FVP1 updates the storage according to the write set of the plurality of transactions as shown in Figure 3The state tree and the storage tree are shown, and the block B1 corresponding to the plurality of transactions is stored, the block includes a block header and a block body, and the block body includes, for example, transaction bodies of the plurality of transactions, receipt data, and the like. After the LVP and the FVP in the blockchain system are updated according to the execution result of the plurality of transactions, the verification data in the LVP still corresponds to the state data in the FVP, so as to continue to reach consensus on the next batch of transactions.

[0085] According to the scheme of the embodiments of the present specification, only lightweight storage is saved in the LVP, and the read set is included in the consensus proposal, so that the LVP can verify the read set based on the verification data, thereby participating in the consensus process, greatly saving the hardware cost and time cost of data storage, and improving the performance and efficiency of the blockchain system.

[0086] Figure 8 A flowchart of a consensus method in another embodiment of the present specification is shown. In this embodiment, the LVP can include a consensus device, a storage device, and an execution device, which can be separate units in a single computing device, or can be multiple separate computing devices. The storage device stores verification data in the LVP and block headers and the like.

[0087] As shown in Figure 8 In step S801, the FVP obtains a read set corresponding to the plurality of transactions. This step can refer to the description of step S701 above, and will not be described here.

[0088] In step S803, the FVP sends a consensus proposal to the consensus device of the LVP, and the consensus proposal includes the read set.

[0089] In step S805, the consensus device sends the read set to the storage device.

[0090] In step S807, the storage device verifies whether the read set is correct based on the verification data. The verification process in this step can refer to the description of step S705 above, and will not be described here.

[0091] In step S809, in the case of passing the verification, the storage device returns the verification result of passing the verification to the consensus device.

[0092] In step S811, the consensus device sends a transaction list of the plurality of transactions and the read set to the execution device, and the transaction list includes transaction bodies of the plurality of transactions respectively and an arrangement order of the plurality of transactions.

[0093] In step S813, the execution device executes the plurality of transactions according to the read set.

[0094] The execution device can obtain an execution result of each transaction by executing each transaction according to the read set, which includes, for example, a write set and a receipt of each transaction.

[0095] At step S815, the execution device returns the execution result of the plurality of transactions to the consensus device.

[0096] At step S817, the consensus device generates a block hash value corresponding to the plurality of transactions according to the execution result of the plurality of transactions. This step can refer to the related description in the description of step S711 above, and will not be described here again.

[0097] At step S819, the consensus nodes (including FVP and LVP) perform consensus on the block hash value. That is, the consensus device of each consensus node performs consensus on the block hash value.

[0098] At step S821, in the case of successful consensus on the block hash value, the consensus device sends the generated block header and the updated verification data to the storage device. The updated verification data may, for example, include Figure 5 the updated node values in the state hash tree and the storage hash tree.

[0099] At step S823, the storage device stores the block header and the updated verification data.

[0100] Figure 9 A structure diagram of a light consensus node in a blockchain system according to an embodiment of the present specification, the blockchain system including a first consensus node and a second consensus node, the first consensus node storing state data, the state data including a plurality of states, the second consensus node storing verification data, the verification data corresponding to the plurality of states, the second consensus node being configured to perform a method as shown in Figure 7 or Figure 8 The method includes:

[0101] The receiving unit 91 is configured to receive a consensus proposal from the first consensus node, the consensus proposal including a read set of a plurality of transactions to be executed, the read set including a first state read according to the plurality of transactions.

[0102] The verification unit 92 is configured to verify the read set based on the verification data, and perform consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain based on the result of the verification.

[0103] The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer performs a method as shown in Figure 7 or Figure 8 The present specification also provides a computer

[0104] The embodiments of the present specification also provide a consensus node, comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method as shown in Figure 7 or Figure 8 The embodiments of the present specification also provide a consensus node, comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method as shown in

[0105] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) such as a field programmable gate array (FPGA) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a piece of PLD by the designer programming it by himself, without having to ask a chip manufacturer to design and manufacture a special integrated circuit chip. Moreover, instead of manually fabricating an integrated circuit chip, this programming is now mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing a program, and the original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there are many types of HDL, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit that implements the logical method flow can be easily obtained.

[0106] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code form, the controller can perfectly well be implemented to perform the same functions in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. by means of logical programming of the method steps. Such a controller can thus be considered a hardware component, and the means comprised therein for performing the various functions can also be considered structures within the hardware component. Alternatively, or even, the means for performing the various functions can be considered both software modules implementing the method and structures within the hardware component.

[0107] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not rule out that with the development of future computer technology, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0108] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical applications be performed concurrently, in parallel, or in a different order. The order of execution of the operations of various embodiments can be changed, and various other operations described, can be deleted or added. Additionally, those of ordinary skill in the art will recognize that the order of the operations of the methods can be changed, and that other operations can be added or replaced while still

[0109] For the sake of description, the above-described apparatuses are described as various modules to describe the various modules separately. Of course, when implementing one or more of the embodiments of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, and the modules implementing the same functions can be implemented by a combination of a plurality of sub-modules or sub-units, etc. The apparatus embodiment described above is merely illustrative, for example, the division of the units is merely a logical function division, and in actual implementation, there can be another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0110] The present application is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (system) and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a machine that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of one or more flows and / or blocks Figure 1 The apparatus that implements the functions specified in one or more flows and / or blocks.

[0111] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 Figure 1 of the block or blocks.

[0113] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0114] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0115] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage, or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0116] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, system or computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0117] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0118] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the use of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the specification. Illustrative representations of the above terms in the specification do not necessarily refer to the same embodiment or example. Moreover, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Furthermore, different embodiments or examples described in the specification can be combined and combined with features of different embodiments or examples, where such combinations do not contradict each other.

[0119] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. A consensus method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the method comprising: The first consensus node sends a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed, and the read set includes a first state read according to the multiple transactions. The second consensus node verifies the read set based on the verification data, and reaches a consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain system based on the verification result.

2. The method according to claim 1, wherein the consensus proposal further includes an order of arrangement of the plurality of transactions, the read set is generated by the first consensus node pre-executing the plurality of transactions, and the pre-execution order of the plurality of transactions corresponds to the order of arrangement.

3. The method according to claim 2, further comprising: If the consensus proposal is successfully reached, the second consensus node executes the multiple transactions according to the arrangement order and the read set to obtain a write set, which includes a second state for updating the state data; Update the verification data according to the write set.

4. The method according to claim 3, further comprising: The second consensus node, together with the first consensus node and other consensus nodes in the blockchain system, reaches a consensus on the write set; The step of updating the verification data according to the write set includes: when the second consensus node successfully reaches consensus on the write set, updating the verification data according to the write set.

5. The method according to claim 4, wherein the consensus between the second consensus node, the first consensus node, and other consensus nodes in the blockchain system on the write set includes: The second consensus node generates a block header corresponding to the multiple transactions based on the execution results of the multiple transactions, the execution results of the multiple transactions including the write set; Calculate the hash value of the block header; The consensus is reached with the first consensus node and other consensus nodes in the blockchain system regarding the block header hash value.

6. The method according to claim 5, further comprising: Store the block header.

7. The method according to claim 1 or 2, wherein the verification data includes the hash values ​​of each of the plurality of states.

8. The method according to claim 7, wherein the verification data comprises hash value data in a tree structure, wherein each leaf node of the hash value data comprises the hash value of the respective states, and the second consensus node verifies the read set based on the verification data, comprising: The second consensus node performs SPV verification on the first state based on the hash value data.

9. The method according to claim 3 or 4, wherein the second consensus node comprises a consensus device and a storage device, the storage device storing the verification data, and the second consensus node verifying the read set based on the verification data comprises: The consensus device sends the read set to the storage device, and the storage device verifies the read set based on the verification data and returns the verification result to the consensus device.

10. The method of claim 9, wherein the second consensus node further comprises an execution device, and the second consensus node executes the plurality of transactions according to the arrangement order and the read set, comprising: The execution device executes the plurality of transactions according to the arrangement order and the read set; The second consensus node updates the verification data according to the write set, including: the execution device sending the write set to the consensus device, and the consensus device instructing the storage device to update the verification data according to the write set.

11. A consensus method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the method being executed by the second consensus node, comprising: Receive a consensus proposal from the first consensus node, the consensus proposal including a read set of multiple transactions to be executed, the read set including a first state read according to the multiple transactions; The read set is verified based on the verification data, and consensus on the consensus proposal is reached with the first consensus node and other consensus nodes in the blockchain system based on the verification result.

12. A blockchain system, comprising a first consensus node and a second consensus node, wherein the first consensus node stores state data, the state data including multiple states, and the second consensus node stores verification data, the verification data corresponding to the multiple states. The first consensus node is used to send a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed, and the read set includes a first state read according to the multiple transactions. The second consensus node is used to verify the read set based on the verification data, and to reach a consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain system based on the verification result.

13. A consensus node in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the second consensus node comprising: A receiving unit is configured to receive a consensus proposal from the first consensus node, the consensus proposal including a read set of multiple transactions to be executed, the read set including a first state read according to the multiple transactions; The verification unit is used to verify the read set based on the verification data, and to reach a consensus on the consensus proposal with the first consensus node and other consensus nodes in the blockchain system based on the verification result.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of claim 11.

15. A consensus node, comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of claim 11.

Images