A method for converting a consensus node type and a consensus node

Abstract

A method for converting a consensus node type and a consensus node, the type of the consensus node includes a first type and a second type, the consensus node of the second type contains state data, the state data includes a plurality of states, the consensus node of the first type contains verification data, the verification data is used for verifying the plurality of states, node type information is stored in a blockchain system, the node type information is used for indicating that a target consensus node is converted from the current first type to the second type, a specific embodiment of the method includes: receiving a first read set of a plurality of first transactions to be executed from a consensus node of the second type, the first read set includes a first state read from the state data according to the plurality of first transactions; verifying the first read set based on the verification data, after verification, executing the plurality of first transactions based on the first read set to obtain a first write set, the first write set includes a second state for updating the state data; storing the second state; updating the verification data according to the second state.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for converting consensus node types and a consensus node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. In a blockchain system, full nodes are generally used as the minimum requirement for participating in consensus; a full node needs to include all data to support the consensus function. Summary of the Invention

[0003] The purpose of this invention is to provide a method for converting consensus node types. The blockchain system involved in this invention includes a first type of consensus node and a second type of consensus node. The second type of consensus node includes state data, which includes multiple states. The first type of consensus node includes verification data, which includes the hash values ​​of the multiple states. This invention can realize the conversion of the first type of consensus node to the second type of consensus node.

[0004] This specification provides a consensus node type conversion method applied to a target consensus node in a blockchain system. The consensus node types in the blockchain system include a first type and a second type. The second type of consensus node contains state data, which includes multiple states. The first type of consensus node contains verification data, which corresponds to the multiple states. The blockchain system stores node type information, which is used to instruct the target consensus node to convert from the current first type to the second type. The method includes: receiving a first read set of multiple first transactions to be executed from the second type of consensus node, the first read set including a first state read based on the multiple first transactions; verifying the first read set based on the verification data; after successful verification, executing the multiple first transactions based on the first read set to obtain a first write set, the first write set including a second state for updating the state data; storing the second state; and updating the verification data based on the second state.

[0005] A second aspect of this specification provides a consensus node. The consensus node types in the blockchain system include a first type and a second type. The second type of consensus node contains state data, which includes multiple states. The first type of consensus node contains verification data, which corresponds to the multiple states. The blockchain system stores node type information, which is used to indicate a target consensus node's transition from the current first type to the second type. The target consensus node includes: a receiving unit configured to receive a first read set of multiple first transactions to be executed from the second type of consensus node, the first read set including a first state read based on the multiple first transactions; a verification unit configured to verify the first read set based on the verification data, and after successful verification, execute the multiple first transactions based on the first read set to obtain a first write set, the first write set including a second state for updating the state data; a storage unit configured to store the second state; and an update unit configured to update the verification data based on the second state.

[0006] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0007] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method.

[0008] In the embodiments of this specification, when instructed to switch from the first type to the second type, after the target consensus node verifies the first read set of multiple first transactions in the received consensus proposal, it executes multiple first transactions based on the first read set to obtain a first write set including the second state, and stores the second state. Thus, the target consensus node can also contain the state, realizing the switch from the first type to the second type, increasing the data storage capacity of the node, and improving the flexibility of the network. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A blockchain architecture diagram in one embodiment is shown;

[0011] Figure 2This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0012] Figure 3 This is a schematic diagram of the blockchain data storage structure of consensus nodes in related technologies;

[0013] Figure 4 This is a schematic diagram of the MPT tree structure;

[0014] Figure 5 This is a schematic diagram of the state hash tree and storage hash tree in the LVP of the embodiments of this specification;

[0015] Figure 6 This is a schematic diagram of the state hash value tree in the embodiments of this specification;

[0016] Figure 7 A flowchart illustrating consensus methods in blockchain systems based on FVP and LVP;

[0017] Figure 8 This is a flowchart of a consensus node type conversion method in an embodiment of this specification;

[0018] Figure 9 This is a structural diagram of a consensus node in one of the embodiments of this specification. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transmission between nodes.

[0021] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0022] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0023] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, 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, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0024] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0025] The consensus mechanism in blockchain is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of consensus nodes reach agreement on the data to be agreed upon. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated; that is, consensus is considered successful when 2f+1 out of N consensus nodes reach agreement. In related technologies, to achieve consensus, the entire ledger is stored on the consensus nodes, storing the state of all blocks and all accounts. 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.

[0026] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2 As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, 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 based on the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store block N. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0027] Figure 3 This is a schematic diagram of the blockchain data storage structure for consensus nodes in related technologies. Figure 3 In the blockchain data storage shown, each block's header includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled), a timestamp, a block number (BlockNum), a state tree root hash (State_Root), a transaction tree root hash (Transaction_Root), and a receipt tree root hash (Receipt_Root). The PrevHash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the block hash value of the previous block (i.e., the hash value of the block header). In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, state_root is the hash value of the root of the state trie, which consists of the states of all accounts in the current block. This state trie can be, for example, an MPT tree (Merkle Patricia Tree).

[0028] MPT trees are tree structures that combine Merkle trees and Patricia trees (compressed prefix trees, a more space-efficient trie tree). The Merkle tree algorithm calculates a hash value for each leaf node, then joins each node pairwise and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, which is, for example, a 16-ary tree structure.

[0029] The state tree contains key-value pairs representing the stored content for each account on the Ethereum network. The "key" in the state tree can be a 160-bit identifier (the address of the Ethereum account), and the characters in this address are distributed across nodes along the path from the root node to a leaf node of the state tree. (See reference) Figure 3 As shown, the leaf nodes of the MPT state tree (e.g., nodes t4 and t5) also include the values ​​for each account. Specifically, when the account is a user account (also known as an external account), for example... Figure 3 Account A in the context of the database has a Value that includes a Nonce and a Balance. When the account is a contractual account, for example... Figure 3 Account B in the context of the database has a Value that includes a Nonce, a Balance, a CodeHash, and a Storage_root hash. The Nonce represents the number of transactions sent from the account address for external accounts, and the number of contracts created by the account for contract accounts.

[0030] The nodes in the state tree are connected by hashes. Specifically, a hash value can be generated based on the data in the child nodes of the parent node, and the generated hash value is stored in the parent node. Figure 4 This is a schematic diagram of the MPT tree structure. Assume... Figure 4 The node labeled "t2" corresponds to Figure 3 In the state tree, node t2 corresponds to the node labeled "t4". Figure 3 The leaf node t4 in the state tree. For example... Figure 4 As shown, Figure 4 The states contained in each leaf node are represented as state1, state2, state3, and state4, respectively, and each state is also the value of each account. Figure 4The characters in the left-hand box of each node are used to index the account. The characters in each node along the path from the leaf node to the root node are concatenated to form the account address corresponding to that leaf node. For example, the nodes from the leaf node containing state1 to the root node include the characters "f", "5", and "324", so the account address corresponding to state1 is "f5324".

[0031] exist Figure 4 In the example, the child nodes of the node containing "5" include leaf nodes. When calculating the hash(324,74) contained in this node, it can be calculated using the following formula (1):

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

[0033] In other words, in calculation Figure 4 When calculating the hash value of leaf node t4 (hash(324, hash(state1)), the hash value of "324" in node t4 is concatenated with the hash value of state1 (hash(state1),) and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. Figure 4 When hashing a non-leaf node (e.g., a node containing "74") using hash(74, hash(a, c)), the data in that node is directly concatenated, and then the hash value is calculated from the concatenated data. It can be understood that the hash value of a node in the state tree is calculated based on all the data of that node. The hash value of a non-leaf node, and a non-root node, is obtained by concatenating the hash values ​​of all its child nodes and then taking the hash value.

[0034] This allows us to calculate the hash value included in each node between the leaf node and the root node in the state tree from bottom to top, thus ultimately allowing us to obtain the calculated hash value. Figure 3 The hash value of node t2 is concatenated with the hash value of node t3, and the hash of the concatenated data is then taken to generate the hash value of node t1. The hash value of node t1 is the state root of this state tree and is recorded in the State_Root field of block N.

[0035] In one variant of the MPT tree, branch nodes may be included. Each branch node can connect to multiple child nodes, and each branch node includes the hash value of the data in each of its connected child nodes. That is, each branch node includes multiple hash values ​​corresponding to multiple master nodes. Leaf nodes are connected after the branch nodes. This variant also includes extension nodes, which can be connected before or after the branch nodes. Each extension node has one child node and includes the hash values ​​of all the data in its connected child nodes. Similarly, in this MPT tree variant, the hash value of the root node can be recursively obtained based on the nodes at each level. The embodiments described in this specification are also applicable to this MPT tree variant.

[0036] Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has some state, which is defined by state variables within the smart contract and generates new values ​​during the creation and execution of the smart contract. For example... Figure 3 As shown, the contract's relevant state is stored in a storage trie. Figure 3 The diagram illustrates the storage tree of the contract corresponding to account B. The hash value of the root node st1 is stored in the aforementioned storage_root, thus locking all states of the contract to the Value (i.e., account state) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure, similar to... Figure 4 Similarly, in the state tree shown, each node on the path from the root node to a leaf node can include characters used to address variable names, and the leaf nodes store the values ​​of the variables, thus storing a key-value mapping from variable names (also called state addresses) to state values ​​in the tree. For example, see reference... Figure 3 The storage tree in the storage tree has leaf nodes st2 and st3, which include, for example, the value of variable a and the value of variable b. 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. This variable name can be similarly composed of hexadecimal characters.

[0037] The calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of nodes in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of a portion of the key included in the leaf node and the hash value of the state in the leaf node are concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. When calculating the hash value of a non-leaf node and a non-root node in the storage tree, the data in the node is directly concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of that node.

[0038] In summary, an FVP node includes tree-like state data. The leaf nodes of this state data include the state of an account or 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. The parent node in the state data includes a hash value calculated based on the data in its child nodes.

[0039] Still referencing Figure 3 In a blockchain, after executing block N, nodes reach a consensus on the next batch of transactions. Once consensus is reached, they execute block N+1, generating state data corresponding to block N+1, similar to the process of executing block N. This state data includes a state tree and storage trees for each contract. Data in block N+1 that overlaps with the state data of block N can reference data from block N without needing to be stored repeatedly. However, storing complete block and state data at each consensus node would require significant storage space.

[0040] This specification provides a Light Validating Peer (LVP) in its embodiments. The LVP only stores partial state data, such as hash value data in the state tree and storage tree, but does not store the value (i.e., each state) of each account or variable in the state tree and storage tree. At the same time, the blockchain also includes a Full Validating Peer (FVP) that is the same as the consensus node in related technologies. Figure 5 This is a schematic diagram of the state hash tree and storage hash tree in the LVP of the embodiments of this specification. Figure 5 As shown, in the state hash tree and storage hash tree of LVP, with Figure 3 Compared to the state tree and storage tree in FVP, the state in the leaf nodes of the state tree and storage tree is replaced with the hash value of that state. For example, state1 in node t4 of the state tree is replaced with hash(state1) in node t4 of the state hash tree, and state5 in node st2 of the storage tree is replaced with hash(state5) in node st2 of the storage hash tree. Figure 6 for Figure 5 A schematic diagram of the state hash tree in the image. (See diagram below.) Figure 6 As shown, in the state hash tree, the leaf nodes include the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, leaf node t4 in the state hash tree includes the hash(state1) of "state1" in leaf node t4 of the state tree. The hash values ​​included in each node in the state hash tree, except for the leaf nodes and the root node, can be generated using the same calculation method as in the state tree. For example, Figure 6The hash(324,74) of the node containing "5" can be calculated using the formula (1) above. The storage hash tree can also have... Figure 6 The structure shown is similar to the structure. In this way, Figure 5 The data contained in the state hash tree and the storage hash tree, excluding the leaf nodes, are related to... Figure 3 The corresponding nodes in the state tree and the storage tree are consistent, therefore Figure 5 The root hash value of node t1 in the data is... Figure 3 The root hash value of node t1 in the array is consistent.

[0041] Figure 5 and Figure 6 The state hash tree and storage hash tree shown can be used to verify reads received from the FVP; therefore, these data can be collectively referred to as verification data. It is understood that verification data is not limited to including, for example, […]. Figure 5 or Figure 6 The structure shown, for example, for verifying the read set, may include at least the hash values ​​of the states of the state tree and the leaf nodes of the storage tree in the verification data. For the MPT tree variant described above, simply deleting the states from the leaf nodes of the MPT tree variant allows the resulting hash value tree to be used as the verification data in the LVP node. The following will use... Figures 3-6 The status data and verification data shown are used as examples to describe the consensus and transaction execution schemes in the embodiments of this specification.

[0042] In blockchain systems based on FVP and LVP, the consensus scheme provided in the embodiments of this specification stores only state verification data in light consensus nodes. By including the read set in the consensus proposal, light consensus nodes can verify the read set based on the state verification data, thereby participating in the consensus process. This greatly saves the hardware and time costs of data storage and improves the performance and efficiency of the blockchain system.

[0043] Figure 7 This is a flowchart of the consensus method in the embodiments of this specification. This method can be implemented by an FVP (Fault-Version Virtualization Provider) acting as the master node in a blockchain system. Figure 7 (Illustrated by FVP) and one or more LVPs are executed. Figure 7 The diagram illustrates an LVP as an example. In this example, the blockchain system may include at least one FVP, which can collectively determine one FVP as the master node. Other nodes in the blockchain system besides the master node are slave nodes. The master node can initiate a consensus proposal to reach a consensus with the slave nodes on that proposal.

[0044] like Figure 7 As shown, firstly, in step S701, FVP obtains the read sets corresponding to multiple transactions.

[0045] Assuming FVP1 is the master node in the blockchain system, the following description uses FVP1 as an example. FVP1 can receive transactions sent by users from user clients or other FVPs. These transactions can be transfer transactions or transactions that invoke contracts, etc. After receiving a certain number of transactions, FVP1 can select several transactions from the received transactions for consensus to generate a new block.

[0046] After selecting multiple transactions, FVP1 obtains the corresponding read sets for those transactions. These read sets include the states of account and / or contract variables read from the state data based on the read operations included in the transactions. In other words, these read sets represent the states of account and / or contract variables that the transactions need to read from the state data when executed. The state data includes, for example, the states of the account and / or contract variables read from the state data. Figure 3 The state tree and storage tree are shown in the diagram.

[0047] Specifically, FVP1 can acquire read sets from multiple transactions and then merge these read sets. Specifically, it selects the key-value pairs of each variable (including account and contract variables) read from the state data during the initial read of each variable from the individual read sets of each transaction, thus obtaining the read sets corresponding to multiple transactions. Assuming one of the multiple transactions involves updating the balance of account A (e.g., reducing a preset amount), this transaction, when executed, first needs to read the value of account A (i.e., including Nonce and Balance). Then, based on the read value of account A, it obtains the new value of account A. For example, the transaction increments the Nonce value by 1 and reduces the Balance value by a preset amount, obtaining the updated Nonce and Balance values ​​of account A, which constitute the updated value of account A. Therefore, the read set of this transaction includes the read key-value pairs of account A, and the write set of this transaction includes the written key-value pairs of account A. The read set of these multiple transactions includes key-value pairs for account A read from the status data, where the key is the account address of account A and the value is the status of account A, which includes the Nonce value and Balance value in the leaf node corresponding to account A.

[0048] Suppose one of these multiple transactions includes an update operation on variable 'a' in the contract corresponding to account B. Since writing to variable 'a' will update the Storage_root in account B, this transaction also includes a write operation to account B. To write to account B and variable 'a', the read set of this transaction needs to include the key-value pair for account B and the key-value pair for variable 'a'. Assuming this transaction's read of account B and variable 'a' is the first read from the state data, the read set of multiple transactions will also include the key-value pair for account B and the key-value pair for variable 'a' read from the state data based on this transaction. Specifically, in the key-value pair for account B, the key is the account address of account B, and the value is the state of account B, which includes the values ​​of the Nonce, Balance, CodeHash, and Storage_root fields in the leaf node corresponding to account B. In the key-value pair for variable 'a', the key is the variable name of variable 'a', and the value is the state value of variable 'a'. Based on the read set of the multiple transactions, when writing to account B during the execution of the transaction, the updated Storage_root can be calculated based on the updated value of variable a, and then merged with the Nonce, Balance, and 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 use in updating state data.

[0049] In one implementation, FVP1 can perform static analysis on each transaction, analyzing the transaction body and the contract code of the contracts called within the transaction, thereby determining the account and / or variable names (keys) that each transaction needs to read during execution. Using the obtained keys, the value corresponding to the key is read from the state data, thus generating a read set corresponding to the multiple transactions. In another implementation, FVP1 can pre-execute the multiple transactions. FVP1 can pre-execute the multiple transactions according to a preset order, or FVP1 can pre-execute the multiple transactions according to the order in which they are received, and determine the order of the multiple transactions in the consensus proposal based on the pre-execution order of the transactions.

[0050] When FVP1 pre-executes multiple transactions, upon first reading the value of an account or contract variable, it reads it from the state data and generates a read set for the multiple transactions based on that initial read value. Simultaneously, FVP1 caches the initially read values ​​of these account or contract variables. When these values ​​are updated during the pre-execution of the multiple transactions, the cached values ​​are updated. When these values ​​are read again during the pre-execution of the multiple transactions, the cached values ​​are read instead. The values ​​of these re-read account or contract variables do not need to be written to the read set for the multiple transactions.

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

[0052] FVP1 can generate a consensus proposal for reaching a consensus on the order of the multiple transactions. In one implementation, the consensus proposal may include a transaction list of the multiple transactions, which includes the transaction bodies of the multiple transactions arranged in sequence. Additionally, the consensus proposal may include a read set of the multiple transactions obtained above. By including a read set in the consensus proposal, reference... Figure 2 The consensus process shown can verify the read set during the PP stage, that is, determine whether FVP1 is malicious during the PP stage. If FVP1 is determined to be malicious during the PP stage, the consensus process can be terminated early, thus eliminating the need for subsequent preparation and commit stages, saving computing resources and improving the system efficiency in the blockchain.

[0053] 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.

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

[0055] In one implementation, the LVP stores Figure 3The 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.

[0056] 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.

[0057] In one implementation, when the LVP stores verification data corresponding to the above-mentioned MPT tree variant, since the verification data similarly includes the hash values ​​of each state in the MPT tree variant, and the nodes of each layer in the verification data are connected by hashes, the read set can be similarly verified based on the verification data, which will not be elaborated further here.

[0058] In addition, LVP can also store the block headers of each block, such as Figure 3As shown, the block header may 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. The block header can be used to perform SPV verification on data such as transactions and receipts, and can also be used to generate the block header of the next block.

[0059] In step S707, the consensus nodes (including FVP and LVP) complete the consensus process for multiple transactions.

[0060] LVP verifies the read set received from FVP using verification data stored locally. If verification passes, meaning the read set is confirmed as correct, LVP can subsequently perform node functions similar to FVP based on this read set, such as executing transactions and generating blocks. After successful verification, LVP can complete the consensus process for multiple transactions, including completing tasks such as... Figure 2 The diagram illustrates the PP, P, and C phases. If verification fails, it indicates the master node may be malicious. LVP can then terminate the consensus process early and begin the process of replacing the master node, thereby improving the efficiency of the blockchain system.

[0061] In step S709, LVP executes multiple transactions based on the read set.

[0062] After successful consensus on a consensus proposal, LVP can execute multiple transactions from the proposal based on the state in the read set. Specifically, when LVP needs to read the state of an account or variable during transaction execution, if it is the first read of that account or variable, it can find the state of the account or variable in the read set and execute the transaction based on that state. Based on the write operations on the account or contract variable in the transaction, a write set for the transaction is obtained. This write set includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables, used to update the state in the state data. After reading the state of an account or contract variable from the read set, LVP can cache that state and update the state of that account or contract variable in the cache when performing a write operation, for subsequent reads of the state of that account or contract variable during transaction execution. Since the state of the account or variable in the read set has been verified as the correct current state of the account or variable, the execution result obtained by executing a transaction based on the state in the read set is consistent with the execution result obtained by FVP executing a transaction based on the state in the state data.

[0063] Specifically, assuming that one of the multiple transactions mentioned above includes updating the balance of account A, LVP first reads the value of account A from the read set of multiple transactions (assuming the read value is V1) and stores it in the cache. Based on the transaction, V1 is updated to obtain the updated value of account A (assuming the value is V2), where V2 includes the updated Nonce value and the updated Balance value. Thus, the updated key-value pair of account A can be written to the write set of the transaction, and the value of account A in the cache is updated.

[0064] As described above, if one of the multiple transactions includes writing to variable 'a' in the contract corresponding to account B, LVP first reads the value of account B (let's say V3) and the value of variable 'a' (let's say V4) from the read set of multiple transactions. Based on this transaction, it processes V4 to obtain the updated value of variable 'a' (let's say V5), calculates the hash value of V5, and substitutes it into... Figure 5 The storage hash tree in the data is used to calculate the hash value of the root node st1. The hash value of the root node st1 is used as the storage_root for the update of account B. Combined with the Nonce, Balance and CodeHash of account B in the read set of the transaction, the updated value of account B (let's assume it is V6) is calculated. Thus, 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.

[0065] 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.

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

[0067] Consensus nodes can similarly pass through Figure 2The 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.

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

[0069] Specifically, after obtaining the write sets of each transaction, LVP generates a corresponding write set (e.g., wset1) based on these write sets. This wset1 includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables used to update state data based on the write operations of the multiple transactions. After successful consensus on the execution results of the multiple transactions, LVP can update the verification data in LVP based on the hash values ​​of each state in wset1.

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

[0071] Assuming the write set wset1 contains key-value pairs for account B and variable a, the LVP first calculates the updated state hash based on the updated value of variable a and updates the state hash of variable a in the verification data. Then, the LVP calculates the updated state hash based on the updated value of account B and updates the state hash of account B in the verification data.

[0072] In another implementation, the verification data in LVP includes, for example: Figure 5 As shown in the state hash tree and storage hash tree, LVP can first update the state hash values ​​in the leaf nodes corresponding to multiple states in the write set, as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values ​​included in each level of nodes in the state hash tree and storage hash tree can be updated upwards until the hash value of the root node of the state hash tree and storage hash tree is updated.

[0073] In addition, after LVP reaches consensus on the block hash, it can store the block header of the generated block for SPV verification and for generating the next block.

[0074] While LVP updates the storage, FVP1 also updates the storage based on the execution results of multiple transactions. Specifically, FVP1 updates the storage based on the write sets of multiple transactions, such as... Figure 3 The diagram shows the state tree and storage tree, as well as block B1 storing the multiple transactions. This block includes a block header and a block body, which contains data such as the transaction bodies and receipts of the multiple transactions. After both LVP and FVP in the blockchain system update their storage based on the execution results of the multiple transactions, the verification data in LVP still corresponds to the state data in FVP, so as to continue consensus on the next batch of multiple transactions.

[0075] The scheme in the embodiments of this specification only stores lightweight storage in LVP. By including the read set in the consensus proposal, LVP can verify the read set based on the verification data, thereby participating in the consensus process. This greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.

[0076] In practice, FVP and LVP can be converted between each other in a blockchain system, thereby improving network flexibility. Specifically, the blockchain system stores node type information, which records the type of each consensus node in the blockchain system, such as FVP or LVP type. When a node is deleted or added in the blockchain system, when the blockchain network is launched, or when the updated FVP to LVP ratio is set in the blockchain system, the blockchain system updates the node type information to record information instructing the consensus node to perform a type conversion.

[0077] The node type information can be recorded in the contract state of the smart contract in each FVP. In this approach, the target LVP in the blockchain system can receive a read set containing node type information from the FVP in response to a transaction used to update the node type information, execute the transaction based on the read set, obtain the updated node type information, and determine from the updated node type information that it needs to change from the LVP type to the FVP type.

[0078] The node type information can be recorded in the configuration files of each consensus node (including FVP and LVP). In this approach, the target LVP in the blockchain system can receive updated node type information in response to a message used to update the node type information in its configuration file. Based on the updated node type information, it learns that it needs to change from LVP type to FVP type. At the same time, the LVP also updates the node type information in its configuration file.

[0079] The node type information can be recorded in the block header of each block. In this method, the target LVP in the blockchain system can respond to a transaction used to update the node type information to obtain the updated node type information, know that it needs to be converted from LVP type to FVP type based on the updated node type information, and store the updated node type information in the block header of the block corresponding to the transaction.

[0080] Once the target LVP learns that it needs to be converted from an LVP type to an FVP type, it can execute... Figure 8 The consensus node type conversion method shown is used to convert itself from LVP type to FVP type. Figure 8 This is a flowchart illustrating a consensus node type conversion method in an embodiment of this specification. In this embodiment, the first type of consensus node is LVP, and the second type of consensus node is FVP. As mentioned earlier, FVP can contain state data, which may include multiple states. LVP can contain verification data, which may correspond to the aforementioned multiple states and can be used to verify the aforementioned multiple states. As an example, verification data may include the hash values ​​of the aforementioned multiple states. It is understood that... Figure 8 The method shown can be applied to the target consensus node (i.e., the target LVP).

[0081] like Figure 8 As shown, firstly, in step S801, the first read set of multiple first transactions to be executed is received from FVP.

[0082] In a blockchain system, the First Transaction View (FVP) can participate in master node selection. Assuming FVP2 is the master node, the target consensus node can receive a first read set of multiple first transactions to be executed from FVP2. This first read set may include first states read based on the multiple first transactions. In one implementation, the target consensus node can receive a consensus proposal from the master node, which may include the first read set.

[0083] In one implementation, the consensus proposal may also include an order of arrangement of multiple first transactions, with the first read set generated by FVP2 pre-executing multiple first transactions, and the pre-executing order of the multiple first transactions corresponding to the order of arrangement.

[0084] In step S803, the first read set is verified based on the verification data. After the verification is successful, multiple first transactions are executed based on the first read set to obtain the first write set.

[0085] In one implementation, after obtaining the first read set from the consensus proposal, the target consensus node can use the stored verification data to verify each first state in the first read set.

[0086] In another implementation, the target consensus node has already stored some states through this method. The target consensus node can first determine one or more first states that are not stored locally in the first read set, and verify the one or more first states that are not stored based on the verification data.

[0087] In one implementation, the verification data contained in the target consensus node may include hash value data in a tree structure, where multiple leaf nodes of the hash value data each include the hash values ​​of multiple states. Furthermore, the verification of the first read set based on the verification data can be specifically performed as follows: SPV verification is performed on the first state in the first read set based on the hash value data.

[0088] For example, the target consensus node stores, as follows: Figure 5 The state hash tree and storage hash tree shown serve as verification data. After the target consensus node obtains the first read set from the consensus proposal, it can perform SPV verification on each first state in the first read set based on the state hash tree and storage hash tree.

[0089] After successful verification, in the first implementation described above, the target consensus node can execute multiple first transactions based on the first state in the first read set to obtain a first write set. This first write set may include a second state for updating state data.

[0090] In the second implementation described above, the target consensus node can execute multiple first transactions based on a portion of the first state in the first read set (i.e., the portion of the state is not stored locally) and a portion of the first state stored locally, to obtain the first write set.

[0091] In step S805, the second state is stored.

[0092] The target consensus node can store the second state in association with the verification data; that is, it stores the second state in the corresponding leaf node of the tree-like verification data. In this way, the index data corresponding to that leaf node in the verification data of the target consensus node can form a key-value pair with the second state. For example, when the verification data includes a state hash tree and a storage hash tree, the second state can be stored in the corresponding leaf nodes of the state hash tree and the storage hash tree. Figure 5 Taking the state hash tree and storage hash tree as an example, for instance, state1 is stored in the leaf node where hash(state1) is located, i.e., node t4 of the state hash tree. State5 is stored in the leaf node where hash(state5) is located, i.e., node st2 of the storage hash tree. In this way, the state data in the target consensus node can be completed, thus enabling conversion to FVP.

[0093] In step S807, the verification data is updated according to the second state.

[0094] Specifically, the target consensus node can delete the state hash value from the leaf node corresponding to the second state in the verification data, calculate the hash value of each second state, and update the verification data based on the hash value of each second state. Specifically, with... Figure 7 The difference between updating verification data and updating other methods is that the hash value of the second state will not be stored in the leaf node corresponding to the second state for conversion into state data. For other processing of the verification data update method, please refer to [link / reference]. Figure 7 Step S713 in the process will not be described again here.

[0095] In one implementation, the target consensus node can also generate blocks corresponding to the multiple first transactions based on the execution results of the multiple first transactions, and store the blocks.

[0096] In one embodiment, the above method may further include the following:

[0097] First, the target consensus node can send a data synchronization request to the FVP. This data synchronization request can be used to request at least a portion of the states from the state data contained in the FVP. As shown in step S805, by participating in transaction execution, the target consensus node can store a portion of the states. For the remaining states, the target consensus node can obtain them by requesting them from the FVP. This data synchronization request does not require consensus.

[0098] Then, the target consensus node can store the data that FVP responds to the data synchronization request.

[0099] In one implementation, in response to meeting a preset condition, the target consensus node sends a message to the blockchain system to modify its type to FVP in the node type information. The preset condition can be set according to actual needs; for example, it can be pre-defined which states need to be stored, and the preset condition can be considered met when the target consensus node stores the specified states. Alternatively, the preset condition can be determined to be met when the target consensus node has stored a preset proportion of states.

[0100] In one implementation, the contract state of a blockchain system can store node type information. When a target consensus node sends a message to the blockchain system, it can do so as follows: It sends a transaction to the blockchain system invoking the contract to modify the target consensus node's type to FVP in the contract state. Each consensus node in the blockchain system executes the transaction after receiving it and reaching consensus, thereby updating the target consensus node's type to FVP based on the node type information in the contract state. LVP can execute the transaction based on the transaction and the read set in the consensus proposal, and update the hash value data corresponding to the node type information and contract in the verification data based on the write set of the transaction. Assuming the target consensus node does not yet store the contract account's value and the contract's corresponding node type information, the target consensus node can, based on the write set of the transaction, replace the original state hash value with the updated value of the contract in the leaf node corresponding to the contract in the verification data, and replace the original state hash value with the updated node type information in the leaf node corresponding to the node type information (i.e., the contract variable) in the verification data.

[0101] In another implementation, the configuration file of the blockchain system can store node type information. In this case, the target consensus node can send a message to the blockchain system as follows: send a configuration file update message to the blockchain system to modify the type of the target consensus node to FVP in the configuration file.

[0102] Here, configuration file update messages can be in the form of transactions, but consensus is not required for these transactions. Since different nodes may receive the configuration file update messages at different times, it can be agreed in the configuration file update message to update together in a certain block (e.g., block 100). In this way, all consensus nodes (including FVP and LVP) can consistently update the node type information in their local configuration files when block 100 is completed.

[0103] In another implementation, the block header of the latest block in the blockchain system stores node type information. In this case, the target consensus node sends a message to the blockchain system, specifically as follows: it sends a specific type of transaction to the blockchain system to modify the target consensus node's type to FVP in the block header corresponding to that specific type of transaction. After receiving and reaching consensus on that specific type of transaction, each consensus node in the blockchain system executes the specific type of transaction, thereby updating the target consensus node's type to FVP in the block header corresponding to that specific type of transaction.

[0104] In practice, FVP can participate in the selection of master nodes. That is, when the node type information stored in the blockchain system indicates that the target consensus node is of type FVP, the target consensus node can participate in the selection of the master node.

[0105] When a target consensus node is selected as the master node, it can receive second transactions sent by users from user clients or other FVPs. For multiple second transactions to be executed, the target consensus node can determine whether it has stored the third state corresponding to the read operations in the aforementioned multiple second transactions locally. If it does not store the third state locally, it requests the third state from other FVPs in the blockchain system. When it receives the third state from other FVPs within a first preset time, it verifies the third state based on verification data. If the verification passes, it generates a second read set of the aforementioned multiple second transactions based on the third state, and sends the consensus proposal including the second read set to other consensus nodes in the blockchain system for generating a new block.

[0106] If the target consensus node fails to send a consensus proposal, including the second set of reads, to other consensus nodes within a second preset time, the blockchain system is triggered to perform a master node switch. Specifically, if other consensus nodes do not receive a consensus proposal from the target consensus node within the preset time, they can consider the current master node to be a malicious node, and thus can perform operations to switch the master node.

[0107] Figure 9This is a structural diagram of a consensus node in an embodiment of this specification. The consensus nodes in the blockchain system include a first type and a second type. The second type of consensus node contains state data, which includes multiple states. The first type of consensus node contains verification data, which corresponds to the multiple states. The blockchain system stores node type information, which is used to instruct a target consensus node to transition from the current first type to the second type. The target consensus node is used to execute... Figure 8 The method shown includes a target consensus node comprising: a receiving unit 901 configured to receive a first read set of a plurality of first transactions to be executed from a second type of consensus node, the first read set including a first state read according to the plurality of first transactions; a verification unit 902 configured to verify the first read set based on the verification data, and after successful verification, execute the plurality of first transactions based on the first read set to obtain a first write set, the first write set including a second state for updating the state data; a storage unit 903 configured to store the second state; and an update unit 904 configured to update the verification data according to the second state.

[0108] In one embodiment, the target consensus node further includes: a synchronization request sending unit (not shown in the figure), configured to send a data synchronization request to the second type of consensus node, wherein the data synchronization request is used to request at least some of the states among the plurality of states; and a request feedback storage unit (not shown in the figure), configured to store data fed back by the second type of consensus node in response to the data synchronization request.

[0109] In one implementation, the receiving unit 901 is further configured to receive a consensus proposal from a consensus node of the second type, the consensus proposal including the first read set.

[0110] In one implementation, the target consensus node further includes: a block storage unit (not shown in the figure), configured to generate blocks corresponding to the plurality of first transactions based on the execution results of the plurality of first transactions, and to store the blocks.

[0111] In one implementation, the target consensus node further includes: a message sending unit (not shown in the figure), configured to send a message to the blockchain system in response to a preset condition being met, for modifying the type of the target consensus node to the second type in the node type information.

[0112] In one implementation, the node type information is stored in the contract state of the blockchain system's contract, and the message sending unit is further configured to send a transaction to the blockchain system to invoke the contract, so as to modify the type of the target consensus node to the second type in the contract state.

[0113] In one implementation, the configuration file of the blockchain system stores the node type information, and the message sending unit is further configured to send a configuration file update message to the blockchain system to modify the type of the target consensus node to the second type in the configuration file.

[0114] In one implementation, the block header of the latest block of the blockchain system stores the node type information, and the message sending unit is further configured to send a specific type of transaction to the blockchain system to modify the type of the target consensus node to the second type in the block header corresponding to the specific type of transaction.

[0115] In one implementation, when the target consensus node is selected as the master node, for multiple second transactions to be executed, it is determined whether the third state corresponding to the read operation in the multiple second transactions is stored locally. If the third state is not stored locally, the third state is requested from other second-type consensus nodes in the blockchain system. When the third state is received from the other second-type consensus nodes within a first preset time, the third state is verified according to the verification data. If the verification is successful, a second read set of the multiple second transactions is generated according to the third state, and a consensus proposal including the second read set is sent to other consensus nodes in the blockchain system.

[0116] In one implementation, if a consensus proposal including the second set of reads is not sent to other consensus nodes within a second preset time, the blockchain system is triggered to perform a master node switch.

[0117] In one embodiment, the verification data includes tree-structured hash value data, wherein each leaf node of the hash value data includes the hash value of the respective states, and the verification unit 902 is further configured to perform SPV verification on the first state based on the hash value data.

[0118] In one embodiment, the storage unit is further configured to obtain the first leaf node in the hash value data that corresponds to the second state, and replace the state hash value in the first leaf node with the second state.

[0119] In one implementation, the consensus proposal further includes an order of arrangement of the plurality of first transactions, wherein the first read set is generated by pre-executing the plurality of first transactions by consensus nodes of the second type, and the pre-executing order of the plurality of first transactions corresponds to the order of arrangement.

[0120] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 8 The method shown.

[0121] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as described above. Figure 8 The method shown.

[0122] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0123] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0124] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0125] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0126] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0127] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0131] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0132] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0133] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0135] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0136] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for converting consensus node types, applied to a target consensus node in a blockchain system, wherein, The consensus nodes in the blockchain system include a first type and a second type. The second type of consensus node contains state data, which includes multiple states. The first type of consensus node contains verification data, which corresponds to the multiple states. The blockchain system stores node type information, which is used to instruct the target consensus node to transition from the current first type to the second type. The method includes: Receive a first read set of a plurality of first transactions to be executed from the consensus node of the second type, the first read set including a first state read according to the plurality of first transactions; The first read set is verified based on the verification data. After the verification is successful, the plurality of first transactions are executed based on the first read set to obtain a first write set. The first write set includes a second state for updating the state data. Store the second state; The verification data is updated based on the second state.

2. The method according to claim 1, wherein, The method further includes: Send a data synchronization request to the consensus node of the second type, wherein the data synchronization request is used to request at least some of the states among the plurality of states; Store the data returned by the second type of consensus node in response to the data synchronization request.

3. The method according to claim 1, wherein, The first read set of multiple first transactions to be executed received from the consensus node of the second type includes: Receive a consensus proposal from a consensus node of the second type, the consensus proposal including the first read set.

4. The method according to claim 1, wherein, The method further includes: Based on the execution results of the plurality of first transactions, a block corresponding to the plurality of first transactions is generated and the block is stored.

5. The method according to claim 2, wherein, The method further includes: In response to the fulfillment of preset conditions, a message is sent to the blockchain system to modify the type of the target consensus node in the node type information to the second type.

6. The method according to claim 5, wherein, The contract state of the blockchain system stores the node type information, and sending a message to the blockchain system includes: A transaction is sent to the blockchain system to invoke the contract, which is used to modify the type of the target consensus node to the second type in the contract state.

7. The method according to claim 5, wherein, The configuration file of the blockchain system stores the node type information, and sending messages to the blockchain system includes: Send a configuration file update message to the blockchain system to modify the type of the target consensus node to the second type in the configuration file.

8. The method according to claim 5, wherein, The block header of the latest block in the blockchain system stores the node type information, and sending a message to the blockchain system includes: Send a specific type of transaction to the blockchain system to modify the type of the target consensus node to the second type in the block header corresponding to the specific type of transaction.

9. The method according to any one of claims 5-8, wherein, When the target consensus node is selected as the master node, for multiple second transactions to be executed, it is determined whether the third state corresponding to the read operation in the multiple second transactions is stored locally. If the third state is not stored locally, the third state is requested from other second-type consensus nodes in the blockchain system. When the third state is received from the other second-type consensus nodes within a first preset time, the third state is verified according to the verification data. If the verification is successful, a second read set of the multiple second transactions is generated according to the third state, and the consensus proposal including the second read set is sent to other consensus nodes in the blockchain system.

10. The method according to claim 9, wherein, If a consensus proposal including the second set of reads is not sent to other consensus nodes within a second preset time, the blockchain system is triggered to perform a master node switch.

11. The method according to claim 1, wherein, The verification data includes tree-structured hash value data, where each leaf node of the hash value data includes the hash value of the respective state. The verification of the first read set based on the verification data includes: SPV verification is performed on the first state based on the hash value data.

12. The method of claim 11, wherein storing the second state comprises: Obtain the first leaf node corresponding to the second state from the hash value data, and replace the state hash value in the first leaf node with the second state.

13. The method according to claim 3, wherein, The consensus proposal also includes the order of the plurality of first transactions. The first read set is generated by the consensus nodes of the second type pre-executing the plurality of first transactions, and the pre-executing order of the plurality of first transactions corresponds to the order of the arrangement.

14. A consensus node, wherein the consensus node types in the blockchain system include a first type and a second type, the second type of consensus node contains state data, the state data including multiple states, the first type of consensus node contains verification data, the verification data corresponding to the multiple states, the blockchain system stores node type information, the node type information being used to indicate a target consensus node to transition from the current first type to the second type, the target consensus node comprising: The receiving unit is configured to receive a first read set of a plurality of first transactions to be executed from a consensus node of the second type, the first read set including a first state read according to the plurality of first transactions; The verification unit is configured to verify the first read set based on the verification data, and after the verification is successful, execute the plurality of first transactions based on the first read set to obtain a first write set. The first write set includes a second state for updating the state data. The storage unit is configured to store the second state; The update unit is configured to update the verification data according to the second state.

15. 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 any one of claims 1-13.

16. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-13.

Images