WO2024066011A1

WO2024066011A1 - Consensus node type conversion method and consensus node

Info

Publication number: WO2024066011A1
Application number: PCT/CN2022/135349
Authority: WO
Inventors: 卓海振
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-09-30
Filing date: 2022-11-30
Publication date: 2024-04-04
Also published as: CN115658808A

Abstract

A consensus node type conversion method and a consensus node, the consensus node types comprising a first type and a second type. A second-type consensus node comprises state data, the state data comprising a plurality of states. A first-type consensus node comprises verification data, the verification data being used for verifying the plurality of states. Node type information is stored in a blockchain system, the node type information being used for instructing a target consensus node to convert from the current first type to the second type. One specific embodiment of the method comprises: receiving from the second-type consensus node a first read set of a plurality of first transactions to be executed, the first read set comprising a first state that is read from the state data according to the plurality of first transactions; on the basis of the verification data, verifying the first read set, and after the verification succeeds, executing the plurality of first transactions on the basis of the first read set, and obtaining a first write set, the first write set comprising a second state for updating the state data; storing the second state; and according to the second state, updating the verification data.

Description

A consensus node type conversion method and consensus node

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 30, 2022, with application number 202211213653.9 and application name “A method for converting a consensus node type and a consensus node”, the entire contents of which are incorporated by reference in this application.

Technical Field

The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a consensus node type conversion method and a consensus node.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. In the blockchain system, the full node is generally used as the minimum facility to participate in the consensus. The full node needs to include the full amount of data to support the consensus function.

Summary of the invention

The purpose of the present invention is to provide a method for converting the type of consensus node. The blockchain system involved in the present invention includes a first type of consensus node and a second type of consensus node, wherein the second type of consensus node includes state data, the state data includes multiple states, and the first type of consensus node includes verification data, the verification data includes hash values of the multiple states. The present invention can realize the conversion of the first type of consensus node to the second type of consensus node.

In a first aspect, the present specification provides a method for converting the type of a consensus node, which is applied to a target consensus node in a blockchain system, wherein the types of consensus nodes in the blockchain system include a first type and a second type, the second type of consensus node includes state data, the state data includes multiple states, the first type of consensus node includes verification data, the verification data corresponds to the multiple states, the blockchain system stores node type information, and the node type information is used to indicate that the target consensus node is converted 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 according to the multiple first transactions; verifying the first read set based on the verification data, and after the verification passes, 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 according to the second state.

According to a second aspect of the present specification, there is provided a consensus node. The types of consensus nodes in a blockchain system include a first type and a second type. The consensus nodes of the second type include state data, and the state data include multiple states. The consensus nodes of the first type include verification data, and the verification data corresponds to the multiple states. The blockchain system stores node type information, and the node type information is used to indicate that a target consensus node is converted from a 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 consensus node of the second type, and the first read set includes a first state read according to the multiple first transactions; a verification unit, configured to verify the first read set based on the verification data, and after the verification is passed, execute the multiple first transactions based on the first read set to obtain a first write set, and the first write set includes 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 according to the second state.

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

A fourth aspect of the present specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described is implemented.

In the scheme of the embodiments of the present specification, when instructed to convert from the first type to the second type, the target consensus node verifies the first read set of multiple first transactions in the received consensus proposal, executes multiple first transactions based on the first read set, obtains a first write set including a second state, and stores the second state. Thus, the target consensus node can also include the state, thereby realizing the conversion from the first type to the second type, increasing the data storage capacity of the node, and improving the flexibility of the network.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

FIG1 shows a diagram of a blockchain architecture in one embodiment;

Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm;

FIG3 is a schematic diagram of the structure of blockchain data storage of consensus nodes in the related art;

FIG4 is a schematic diagram of the structure of an MPT tree;

FIG5 is a schematic diagram of a state hash value tree and a storage hash value tree in an LVP in an embodiment of this specification;

FIG6 is a schematic diagram of a state hash value tree in an embodiment of this specification;

FIG7 is a flow chart of a consensus method in a blockchain system based on FVP and LVP;

FIG8 is a flow chart of a method for converting a consensus node type in an embodiment of this specification;

FIG. 9 is a structural diagram of a consensus node in an embodiment of this specification.

Detailed ways

In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

FIG1 shows a diagram of a blockchain architecture in an embodiment. In the diagram of the blockchain architecture shown in FIG1 , a blockchain 100 includes N nodes, and FIG1 schematically shows nodes 1 to 8. The lines between the nodes schematically represent a P2P (Peer to Peer) connection, and the connection may be, for example, a TCP connection, etc., for transmitting data between nodes.

Transactions in the blockchain field can refer to task units executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount.

The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, so that each node in the blockchain can run the smart contract code in a distributed manner.

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

In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain 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 above-mentioned "0x6f8ae93...", that is, the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After consensus is reached on the transaction in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.

The consensus mechanism in the blockchain is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire 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 them, in various consensus algorithms, usually after a preset number of consensus nodes reach an agreement on the data to be treated as consensus (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful. Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes among N consensus nodes reach an agreement, the consensus can be determined to be successful. In related technologies, in order to realize the consensus function, the full amount of ledgers is stored on the consensus node, that is, the status of all blocks and all accounts is stored. Thus, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.

FIG2 is a schematic diagram of the consensus process in the PBFT consensus algorithm. As shown in FIG2, 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, node n1-node n4, wherein node n1 is, for example, a master node, and node n2-node n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated in node n1-node n4. Specifically, in the request stage, a user of the blockchain can send a request to node n1 through his user device, and the request is, for example, in the form of a blockchain transaction. In the preparation stage, after receiving multiple transactions from one or more user devices, node n1 can package the multiple transactions into a consensus proposal, and send the consensus proposal and the signature of node n1 on the consensus proposal to other consensus nodes (i.e., node n2-node n4) for generating blocks. The consensus proposal may include information such as the transaction body of the multiple transactions and the submission order of the multiple transactions. In the preparation stage, each slave node can sign the consensus proposal and send it to each other node. Assuming that node n4 is a malicious node, node n1, node n2, and node n3 can determine that the preparation phase is completed and can enter the submission phase after receiving the signatures of 2f=2 other consensus nodes on the consensus proposal. For example, as shown in Figure 2, after node n1 receives the signatures of node n2 and node n3, it verifies that the signatures of node n2 and node n3 are correct signatures on the consensus proposal, and then determines that the preparation phase is completed. After node n2 receives the signature of node n3 and the signature of node n1 in the preparatory phase and verifies them, it determines that the preparation phase is completed. In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to other consensus nodes. After receiving the signatures of 2f=2 other consensus nodes in the submission phase, each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after receiving and verifying the signatures of the submission phase of nodes n2 and n3, node n1 determines that the submission phase is completed, so that node n1 can execute the multiple transactions according to the consensus proposal, generate and store blocks (such as block N) including the multiple transactions, update the world state according to 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 submission phase is completed, nodes n2 and n3 execute the multiple transactions, update the world state according to the execution results 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. In other words, nodes n1-n4 can still achieve consensus on the consensus proposal successfully and complete the execution of the block in the presence of a malicious node.

FIG3 is a schematic diagram of the structure of the blockchain data storage of the consensus node in the related art. In the blockchain data storage shown in FIG3, the block header of each block includes several fields, such as the previous block hash previous_Hash (PrevHash in the figure), the random number Nonce (in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, the Nonce in the block header is not enabled), the timestamp Timestamp, the block number BlockNum, the state tree root hash State_Root, the transaction tree root hash Transaction_Root, the receipt tree root hash Receipt_Root, etc. Among them, the PrevHash in the block header of the next block (such as block N+1) points to the previous block (such as 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 next block on the blockchain is locked to the previous block through the block header. In particular, as mentioned above, state_root is the hash value of the root of the state trie consisting of the states of all accounts in the current block, such as the Merkle Patricia Tree (MPT Tree).

The MPT tree is a tree structure that combines the Merkle tree and the Patricia tree (a compressed prefix tree, a more space-saving Trie tree, a dictionary tree). The Merkle Tree algorithm calculates a hash value for each leaf node, and then connects two nodes to calculate the hash again until the top Merkle root. Ethereum uses an improved MPT tree, which is a 16-way tree structure.

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

The nodes in the state tree are connected by hashing. Specifically, a hash value can be generated based on the data in the child node of the parent node, and the generated hash value is stored in the parent node. Figure 4 is a schematic diagram of the structure of the MPT tree. Assume that the node marked "t2" in Figure 4 corresponds to the node t2 in the state tree in Figure 3, and the node marked "t4" corresponds to the leaf node t4 in the state tree in Figure 3. As shown in Figure 4, the states included in each leaf node in Figure 4 are respectively represented as state1, state2, state3, and state4, and each state is also the Value of each account. The characters in the left box of each node in Figure 4 are used to index the account, and the characters included in each node in the path between the leaf node and the root node are concatenated to form the account address corresponding to the leaf node. For example, each node between the leaf node where state1 is located and the root node includes the characters "f", "5" and "324", so that the account address corresponding to state1 can be obtained as "f5324".

In FIG4 , the child nodes of the node including “5” include leaf nodes. When calculating the hash (324, 74) included in the node, the following formula (1) can be used for calculation:

hash(324,74)＝hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)

That is, when calculating the hash value hash(324, hash(state1) of the leaf node t4 in FIG4, "324" in the node t4 and the hash value hash(state1) of state1 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 hash(74, hash(a, c)) of the non-leaf node in FIG4 (for example, the node including "74"), the data in the node is directly concatenated, and then the hash value of the concatenated data is calculated. It can be understood that the hash value of the node in the state tree is a hash value calculated based on all the data of the node, and the hash value included in the node that is not a leaf node and a non-root node in the state tree is a hash value obtained by concatenating the hash values of all its child nodes and hashing them.

In this way, the hash value included in each node between the leaf node and the root node can be calculated from bottom to top in the state tree, so that the calculated hash value of node t2 in Figure 3 can be concatenated with the hash value of node t3, and the concatenated data is hashed to generate the hash value of node t1. The hash value of node t1 is the state root of the state tree, which is recorded in the State_Root field of block N.

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

After the smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values when the smart contract is created and executed. As shown in Figure 3, the relevant states of the contract are stored in the storage trie, and Figure 3 schematically shows the storage trie of the contract corresponding to account B. The hash value of the root node st1 of the storage tree is stored in the above storage_root, so that all states of the contract are locked to the Value (i.e., account status) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure. Similar to the state tree shown in Figure 4, 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, so that the storage tree stores the key-value mapping from the variable name (also called the state address) to the state value. For example, referring to the storage tree in Figure 3, the leaf nodes st2 and st3 of the storage tree include the Value of variable a, the Value of variable b, etc. 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, and the variable name can similarly be composed of hexadecimal characters.

Among them, the calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of the node in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of the partial 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 that is not a leaf node and a non-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.

In general, the FVP node includes tree-like state data, the leaf nodes of which include the state of the 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, and the parent node in the state data includes a hash value calculated based on the data in its child nodes.

Still referring to Figure 3, after executing block N, the nodes in the blockchain reach a consensus on the next batch of transactions, and execute block N+1 after the consensus is passed, thereby generating state data corresponding to block N+1 similarly to the execution of block N, and the state data includes a state tree and storage trees corresponding to each contract. Among them, the data of the state data of block N+1 that is repeated with the state data of block N can refer to the data in block N without repeated storage. In this way, when each consensus node stores complete block data and state data, a large storage space is required.

The embodiment of this specification provides a light consensus node (Light Validating Peer, LVP), in which only part of the state data is saved, for example, the hash value data in the state tree and the storage tree is saved, but the Value (i.e., each state) of each account or variable in the state tree and the storage tree is not saved. At the same time, the blockchain also includes a full consensus node (Full Validating Peer, FVP) that is the same as the consensus node in the related art. FIG5 is a schematic diagram of the state hash value tree and the storage hash value tree in the LVP in the embodiment of this specification. As shown in FIG5, in the state hash value tree and the storage hash value tree in the LVP, compared with the state tree and the storage tree in the FVP in FIG3, the state in the leaf node in the state tree and the storage tree is replaced with the hash value of the state, for example, state1 in node t4 in the state tree is replaced with hash(state1) in node t4 in the state hash value tree, and state5 in node st2 in the storage tree is replaced with hash(state5) in node st2 in the storage hash value tree. FIG6 is a schematic diagram of the state hash value tree in FIG5. As shown in Figure 6, in the state hash value tree, the leaf node includes the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, the leaf node t4 in the state hash value tree includes the hash (state1) of "state1" in the leaf node t4 in the state tree. The hash values included in each node other than the leaf node and the root node in the state hash value tree can be generated using the same calculation method as in the state tree. For example, the hash (324, 74) in the node including "5" in Figure 6 can be calculated by the above formula (1). The storage hash value tree can also have a structure similar to the structure shown in Figure 6. In this way, the data included in the state hash value tree and the storage hash value tree other than the leaf node in Figure 5 is consistent with the corresponding nodes in the state tree and storage tree in Figure 3, so the root hash value of the node t1 in Figure 5 is consistent with the root hash value of the node t1 in Figure 3.

The state hash value tree and storage hash value tree shown in FIG5 and FIG6 can be used to verify the read set received from the FVP, so these data can be collectively referred to as verification data. It can be understood that the verification data is not limited to the structure shown in FIG5 or FIG6. For example, in order to verify the read set, the verification data may at least include the hash value of the state of each leaf node in the state tree and the storage tree. For the above-mentioned MPT tree variant, it is only necessary to delete the state in the leaf node in the MPT tree variant, that is, the hash value tree after the deletion can be used as the verification data in the LVP node. The following will use the state data and verification data shown in FIG3-6 as examples to describe the consensus and transaction execution scheme in the embodiments of this specification.

In a blockchain system based on FVP and LVP, through the consensus solution provided by the embodiments of this specification, only state verification data is saved in the light consensus node. 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 that it can participate in the consensus process, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.

FIG7 is a flow chart of a consensus method in an embodiment of the present specification. The method may be performed by a FVP (schematically shown as an FVP in FIG7 ) and one or more LVPs as a master node in a blockchain system, and FIG7 shows an LVP as an example. Among them, the blockchain system may include at least one FVP, and the at least one FVP may jointly determine an FVP as a master node, and nodes other than the master node in the blockchain system are slave nodes. The master node may initiate a consensus proposal to reach a consensus on the consensus proposal together with the slave nodes.

As shown in FIG. 7 , first, in step S701 , the FVP obtains read sets corresponding to multiple transactions.

Assuming that FVP1 in the blockchain system is the master node, FVP1 is used 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 a transaction that calls a contract, etc. After receiving a certain amount of transactions, FVP1 can select multiple transactions from the received transactions for consensus to generate a new block.

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

Specifically, FVP1 can obtain the read sets of multiple transactions, and then merge the read sets of each transaction, that is, select the key-value pairs of the variables read from the state data when each variable (including account and contract variables) is read for the first time from the read sets of multiple transactions, so as to obtain the read sets corresponding to multiple transactions. Assuming that one of the multiple transactions includes an update to the balance of account A (for example, reducing a preset amount), the transaction needs to first read the value of account A (that is, including Nonce and Balance) when it is executed, and then obtain the new value of account A according to the read value of account A. For example, according to the transaction, the Nonce value is added by 1, and the Balance value is reduced by a preset amount to obtain the updated Nonce value and Balance value of account A, which constitute the updated Value of account A. Therefore, the read set of the transaction includes the key-value pairs of account A read, and the write set of the transaction includes the key-value pairs of account A written. The read set of the multiple transactions includes the Key-Value pair of 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.

Assume that one of the multiple transactions includes an update operation on variable a in the contract corresponding to account B. Since writing to variable a will result in an update to Storage_root in account B, the transaction also includes a write operation on account B. In order to write to account B and variable a, the read set of the transaction needs to include the Key-Value pair of account B and the key-value pair of variable a. Assuming that the reading of account B and variable a by the transaction is the first reading from the state data, the read sets of multiple transactions also include 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 in the 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 the Nonce, Balance, CodeHash and Storage_root fields in the leaf node corresponding to account B. The key in the 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 sets of the multiple transactions, when writing to account B in the execution of the transaction, the updated Storage_root can be calculated according to the updated value of variable a and 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 updating the status data.

In one embodiment, FVP1 can perform static analysis on each transaction, analyze the transaction body of the transaction and the contract code of the contract called in the transaction, so as to determine the account and/or variable name, i.e., key, that each transaction needs to read when executing, and read the value corresponding to the key from the state data through the obtained key, so as to generate the read set corresponding to the multiple transactions. In another embodiment, FVP1 can pre-execute the multiple transactions, FVP1 can pre-execute the multiple transactions according to the preset arrangement order of the multiple transactions, or FVP1 can pre-execute the multiple transactions according to the order in which the transactions are received, and determine the arrangement order of the multiple transactions in the consensus proposal according to the pre-execution order of the transactions.

When FVP1 reads the value of an account or contract variable for the first time during the pre-execution of multiple transactions, it reads it from the state data and generates a read set of the multiple transactions based on the value of the account or contract variable read for the first time. At the same time, FVP1 caches the value of the account or contract variable read for the first time, and when the value of the account or contract variable read for the first time is updated during the pre-execution of the multiple transactions, the value of the account or contract variable is updated in the cache, and when the value of the account or contract variable is read again during the pre-execution of the multiple transactions, the value of the account or contract variable in the cache is read, wherein the value of the account or contract variable read again does not need to be written into the read set of the multiple transactions.

In step S703, the FVP sends a consensus proposal to the LVP, where the consensus proposal includes the read sets of the multiple transactions.

FVP1 can generate a consensus proposal for consensus on the order of arrangement of the multiple transactions. In one embodiment, the consensus proposal may include a transaction list of the multiple transactions, and the transaction list includes transaction bodies of multiple transactions arranged in sequence. In addition, the consensus proposal also includes the read sets of the multiple transactions obtained above. By including the read set in the consensus proposal, with reference to the consensus process shown in Figure 2, the read set can be verified in the PP stage, that is, it can be determined whether FVP1 is malicious in the PP stage. If it is determined that FVP1 is malicious in the PP stage, the consensus process can be terminated in advance, so that there is no need to carry out the subsequent preparation stage and submission stage, which saves computing resources and improves the system efficiency in the blockchain.

In another embodiment, the consensus proposal may include transaction identifiers of multiple transactions arranged in sequence (such as hash values of each transaction) and the above-mentioned read set. At the same time, FVP1 or other FVPs that receive transactions from user devices may broadcast the transaction bodies of the multiple transactions to other consensus nodes through broadcasting, thereby reducing the amount of data in the consensus proposal and saving the amount of calculation used for signing during the consensus process.

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

In one embodiment, the LVP stores the hash values of each state in the state tree and storage tree in FIG. 3, as well as the index data to the hash value (such as the account address or variable name) 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, 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 the state hash value to verify the Value of account A, that is, verify whether the Value of account A in the read set corresponds to the state hash value of account A stored locally. If so, it can be determined that the Value of account A in the read set is the correct state. In the case where the read set includes the Value of account B and the Value of variable a, the LVP can obtain the state hash value of account B and the state hash value of variable a from the verification data to verify the Value of account B and the Value of variable a in the read set, respectively.

In another embodiment, the state hash value tree and storage hash value tree as shown in FIG. 5 are stored in LVP 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 value tree and the storage hash value tree. For example, 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, and calculate the hash value of each node layer by layer based on the values of other leaf nodes in the state hash value tree (i.e., the state hash value) and hash1 until the root hash value of the state hash value tree (e.g., root1) is calculated, and it is determined whether root1 is consistent with the root hash value of the state hash value tree stored in LVP. If they are consistent, the Value of account A in the read set is considered to be correct. In the case where 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 value tree and the storage hash value tree.

In one embodiment, when verification data corresponding to the above-mentioned MPT tree variant is stored in the LVP, since the verification data similarly includes hash values of each state in the MPT tree variant, and each layer of nodes in the verification data is connected by hash, the read set can be similarly verified based on the verification data, which will not be repeated here.

In addition, the block headers of each block can also be stored in LVP. As shown in Figure 3, 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. The block header can be used to perform SPV verification on transaction, receipt and other data, and can be used to generate the block header of the next block.

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

LVP verifies the read set received from FVP based on the verification data stored locally. If the verification is successful, that is, the read set is verified to be the correct read set, so that LVP can subsequently perform node functions similar to FVP based on the read set, such as executing transactions, generating blocks, etc. After the verification is successful, LVP can complete the consensus process for multiple transactions, including completing the PP stage, P stage, and C stage as shown in Figure 2. If the verification fails, it can be determined that the master node may be malicious. 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.

In step S709 , the LVP executes multiple transactions according to the read set.

After the consensus proposal is successfully reached, LVP can execute multiple transactions in the consensus proposal based on the status in the read set. Specifically, when LVP needs to read the status of an account or variable in the process of executing a transaction, if it is the first read of the account or variable, the status of the account or variable can be found from the read set, and the transaction is executed based on the status of the account or variable. According to the write operation on the account or contract variable in the transaction, the write set of the transaction is obtained, and the write set includes the key-value pair of the account or the key-value pair of the contract account and the contract variable, which is used to update the status in the status data. After reading the status of the account or contract variable from the read set, LVP can cache the status, and when executing the write to the account or contract variable, update the status of the account or contract variable in the cache, so as to be used for the subsequent reading of the status of the account or contract variable in the process of executing the transaction. Since the status of the account or variable in the read set has been verified, that is, it is the current correct status of the account or variable, the execution result obtained by executing the transaction based on the status in the read set is consistent with the execution result obtained by FVP executing the transaction based on the status in the status data.

Specifically, assuming that one of the multiple transactions described above includes an update to 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, and updates V1 according to the transaction 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, 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 can be updated.

Assuming that as described above, one of the multiple transactions includes the writing of variable a of the contract corresponding to account B, LVP first reads the value of account B (assumed to be V3) and the value of variable a (assumed to be V4) from the read set of multiple transactions, processes V4 according to the transaction, obtains the updated value of variable a (assumed to be V5), calculates the hash value of V5, 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. Combined with the Nonce, Balance and CodeHash of account B in the read set of the transaction, the updated value of account B (assumed to be V6) is calculated, 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.

While LVP is executing multiple transactions according to the read set, if FVP1 has previously pre-executed multiple transactions, since, as mentioned above, the order in which FVP1 pre-executes the multiple transactions corresponds to the arrangement order of the multiple transactions in the consensus proposal, the reading, updating, and writing of the state by FVP1 when pre-executing multiple transactions are consistent with those when executing multiple transactions, so that the write set obtained by pre-executing multiple transactions can be used as the write set for executing the multiple transactions, and the receipts of the multiple transactions can be obtained based on the write set. If FVP1 has not previously pre-executed multiple transactions, the multiple transactions can be executed according to the read set or by reading the state from the state data in the arrangement order of the multiple transactions in the consensus proposal. In the above two methods, the write set and receipts of the multiple transactions obtained in FVP1 are consistent with the write set and receipts of the multiple transactions executed by LVP.

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

The consensus nodes can similarly reach consensus on the execution results of multiple transactions through the consensus process shown in FIG2. Specifically, after executing multiple transactions and obtaining the write sets and receipts of each transaction, each consensus node can calculate the state tree root hash value, transaction tree root hash value, and receipt tree root hash value corresponding to the multiple transactions according to the transaction bodies, write sets, and receipts of the multiple transactions. The block hash (i.e., the block header hash value of block B1) corresponding to the multiple transactions is calculated 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, as shown in PrevHash in FIG3). FVP1 can send a consensus proposal to other consensus nodes in the PP stage, and the consensus proposal includes the block hash of block B1. After receiving the consensus proposal, LVP can compare whether the block hash received from FVP1 is consistent with the block hash of block B1 calculated by itself. If they are consistent, the block hash is signed and sent to other consensus nodes. After completing the PP stage, P stage, and C stage in Figure 2, the consensus on the block hash is completed. After the consensus nodes complete the consensus on the block hash, it can be ensured that the execution results of multiple transactions by each consensus node are consistent, so that each node can update the storage according to the execution results of multiple transactions.

In step S713, LVP updates the verification data according to the write sets of multiple transactions.

Specifically, after obtaining the write sets of each transaction, LVP obtains the write sets corresponding to the multiple transactions (e.g., wset1) according to the write sets of each transaction, and the write set wset1 includes the key-value pairs of the accounts or the key-value pairs of the contract accounts and contract variables that will be used to update the state data according to the write operations of the multiple transactions. After successfully reaching a consensus on the execution results of multiple transactions, LVP can update the verification data in LVP based on the hash values of each state in wset1.

In one embodiment, the verification data in LVP includes the hash value of the state of each account and each contract variable. Assuming that the write set wset1 includes the key-value pair of account A to be written, 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 wset1, and write the hash value of the state corresponding to the key in wset1 to the storage location.

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, LVP first calculates the updated state hash value based on the updated value of variable a, and updates the state hash value of variable a in the verification data. Afterwards, LVP calculates the updated state hash value based on the updated value of account B, and updates the state hash value of account B in the verification data.

In another embodiment, the verification data in the LVP includes a state hash value tree and a storage hash value tree as shown in FIG5 , and the LVP may first update the state hash values in the leaf nodes corresponding to the multiple states in the write set in the state hash value tree and the storage hash value tree as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values included in the nodes at each level in the state hash value tree and the storage hash value tree may be updated upward until the hash values of the root nodes of the state hash value tree and the storage hash value tree are updated.

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.

While LVP is updating the storage, FVP1 is also updating the storage according to the execution results of multiple transactions. Specifically, FVP1 updates the state tree and storage tree shown in FIG3 according to the write sets of multiple transactions, and stores the block B1 corresponding to the multiple transactions, which includes a block header and a block body. The block body includes, for example, transaction bodies, receipts and other data of multiple transactions. After both LVP and FVP in the blockchain system update the storage according to the execution results of multiple transactions, the verification data in LVP still corresponds to the state data in FVP, so as to continue to reach consensus on the next batch of multiple transactions.

The solution of 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, so that it can participate in the consensus process, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.

In practice, the FVP and LVP in the blockchain system can be converted to improve the flexibility of the network. Specifically, the blockchain system stores node type information, which records the types of each consensus node in the blockchain system, such as FVP type or LVP type. When a node is deleted or added in the blockchain system, when the blockchain network is started, 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 indicating the consensus node to perform type conversion in the node type information.

The node type information can be recorded in the contract state of the smart contract in each FVP. In this way, the target LVP in the blockchain system can receive a read set including the node type information from the FVP in response to a transaction for updating the node type information, execute the transaction according to the read set, obtain the updated node type information, and learn that it needs to convert from the LVP type to the FVP type according to the updated node type information.

The node type information may be recorded in the configuration files of each consensus node (including FVP and LVP). In this way, the target LVP in the blockchain system can obtain updated node type information in response to the message for updating the node type information in the configuration file, and learn that it needs to be converted from LVP type to FVP type according to the updated node type information. At the same time, LVP also updates the node type information in the configuration file.

The node type information may be recorded in the block header of each block. In this way, the target LVP in the blockchain system can obtain updated node type information in response to the transaction for updating the node type information, learn that it needs to be converted from the LVP type to the FVP type according to the updated node type information, and store the updated node type information in the block header of the block corresponding to the transaction.

After the target LVP learns that it needs to be converted from the LVP type to the FVP type, it can execute the consensus node type conversion method shown in Figure 8 to convert itself from the LVP type to the FVP type. Figure 8 is a flow chart of 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 above, it can be seen that FVP can include state data, and the state data can include multiple states. LVP can include verification data, and the verification data can correspond to the above multiple states, and the verification data can be used to verify the above multiple states. As an example, the verification data may include the hash values of the above multiple states. It can be understood that the method shown in Figure 8 can be applied to the target consensus node (i.e., the target LVP).

As shown in FIG8 , first, in step S801 , a first read set of a plurality of first transactions to be executed is received from the FVP.

In the blockchain system, FVP can participate in the selection of the master node. Assuming that FVP2 in the blockchain system can be the master node, the target consensus node can receive the first read set of multiple first transactions to be executed from FVP2. The first read set may include the first state read according to the multiple first transactions. In one embodiment, the target consensus node can receive a consensus proposal from the master node, and the consensus proposal may include the first read set.

In one implementation, the consensus proposal may further include an arrangement order of multiple first transactions, and the first read set is generated by FVP2 pre-executing the multiple first transactions, and the pre-execution order of the multiple first transactions corresponds to the arrangement order.

In step S803, the first read set is verified based on the verification data, and after the verification passes, a plurality of first transactions are executed based on the first read set to obtain a first write set.

In one embodiment, after obtaining the first read set from the consensus proposal, the target consensus node may use the stored verification data to verify each first state in the first read set.

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

In one implementation, the verification data included in the target consensus node may include hash value data in a tree structure, and multiple leaf nodes of the hash value data include hash values of multiple states respectively. And, verifying the first read set based on the verification data may be specifically performed as follows: performing SPV verification on the first state in the first read set based on the hash value data.

For example, the target consensus node stores the state hash tree and the storage hash tree as verification data as shown in FIG5. 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 the storage hash tree.

After the verification is passed, in the first embodiment, 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. The first write set may include a second state for updating state data.

In the above-mentioned second implementation, the target consensus node may execute multiple first transactions based on part of the first state in the first read set (ie, the part of the state is not stored locally) and part of the first state stored locally to obtain a first write set.

In step S805, the second state is stored.

The target consensus node can store the second state in association with the verification data, that is, store the second state in the corresponding leaf node in the tree-like verification data, so that the index data corresponding to the leaf node included in the verification data in the target consensus node and the second state can form a Key-Value pair. For example, when the verification data includes a state hash value tree and a storage hash value tree, the second state can be stored in the corresponding leaf nodes in the state hash value tree and the storage hash value tree. Taking the state hash value tree and the storage hash value tree shown in Figure 5 as an example, for example, state1 is stored in the leaf node where hash(state1) is located, that is, node t4 of the state hash value tree. State5 is stored in the leaf node where hash(state5) is located, that is, node st2 of the storage hash value tree. In this way, the state in the state data can be completed in the target consensus node, so that it can be converted into FVP.

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

Specifically, the target consensus node can delete the state hash value in 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, the difference from updating the verification data in FIG7 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 updating method of the verification data, please refer to step S713 in FIG7, which will not be repeated here.

In one embodiment, the target consensus node may also generate blocks corresponding to the multiple first transactions according to the execution results of the multiple first transactions, and store the blocks.

In one embodiment, the above method may further include the following contents:

First, the target consensus node can send a data synchronization request to the FVP, which can be used to request at least part of the multiple states in the state data contained in the FVP. As shown in step S805, by participating in the transaction execution, the target consensus node can store part of the state, and for the remaining part of the state, the target consensus node can obtain it by requesting the FVP. This data synchronization request may not require consensus.

The target consensus node can then store the data that the FVP responds to in response to the data synchronization request.

In one embodiment, in response to satisfying a preset condition, the target consensus node sends a message to the blockchain system to modify the type of the target consensus node to FVP in the node type information. The above preset condition can be a condition set according to actual needs. For example, it can be pre-specified which states need to be stored. When the target consensus node stores the specified state, it can be considered that the preset condition is satisfied. Or when the target consensus node determines that a preset proportion of states are stored, it can be determined that the preset condition is satisfied.

In one embodiment, the contract state of the contract of the blockchain system may store node type information. At this time, the target consensus node sends a message to the blockchain system, which can be specifically performed as follows: Send a transaction to call the contract to the blockchain system to modify the type of the target consensus node to FVP in the contract state. Each consensus node in the blockchain system executes the transaction after receiving the consensus on the transaction, so that FVP updates the type of the target consensus node to FVP in the node type information in the contract state according to the transaction. LVP can execute the transaction according to the transaction and the read set in the consensus proposal, and update the hash value data corresponding to the node type information and the contract in the verification data according to the write set of the transaction. Assuming that the value of the contract account and the node type information corresponding to the contract have not been stored in the target consensus node, the target consensus node can 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 according to the write set of the transaction, 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.

In another embodiment, the node type information may be stored in the configuration file of the blockchain system. At this time, the target consensus node sends a message to the blockchain system, which may be specifically performed as follows: a configuration file update message is sent to the blockchain system to modify the type of the target consensus node to FVP in the configuration file.

Here, the configuration file update message can be in the form of a transaction, but there is no need to reach a consensus on the transaction. Since each node may receive the configuration file update message at different times, it can be agreed in the configuration file update message that they will be updated together in a certain block (for example, the 100th block), so that each consensus node (including FVP and LVP) can consistently update the node type information in the local configuration file when the 100th block is executed.

In another embodiment, the block header of the latest block of the blockchain system stores the node type information. At this time, the target consensus node sends a message to the blockchain system, which can be specifically performed as follows: a specific type of transaction is sent to the blockchain system to modify the type of the target consensus node to FVP in the block header corresponding to the specific type of transaction. Each consensus node in the blockchain system executes the specific type of transaction after receiving the consensus on the specific type of transaction, thereby updating the type of the target consensus node to FVP in the block header corresponding to the specific type of transaction.

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

When the target consensus node is selected as the master node, the target consensus node can receive the second transaction sent by the user from the user client or other FVP. For multiple second transactions to be executed, the target consensus node can determine whether the third state corresponding to the read operation in the above multiple second transactions is stored locally. If the third state is not stored locally, the third state is requested from other FVPs in the blockchain system. When the third state is received from other FVPs within the first preset time, the third state is verified according to the verification data. If the verification passes, the second read set of the above 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 for generating new blocks.

When the target consensus node fails to send the consensus proposal including the second read set to other consensus nodes within the second preset time, the blockchain system is triggered to switch the master node. Specifically, when other consensus nodes fail to receive the consensus proposal from the target consensus node within the preset time, the current master node may be considered as a malicious node, and thus an operation for switching the master node may be performed.

FIG9 is a structural diagram of a consensus node in an embodiment of the present specification. The types of consensus nodes in the blockchain system include a first type and a second type. The consensus node of the second type includes state data, and the state data includes multiple states. The consensus node of the first type includes verification data, and the verification data corresponds to the multiple states. The blockchain system stores node type information, and the node type information is used to indicate that the target consensus node is converted from the current first type to the second type. The target consensus node is used to execute the method shown in FIG8. The target consensus node includes: a receiving unit 901, configured to receive a first read set of multiple first transactions to be executed from the consensus node of the second type, and the first read set includes a first state read according to the multiple first transactions; a verification unit 902, configured to verify the first read set based on the verification data, and after the verification is passed, the multiple first transactions are executed based on the first read set to obtain a first write set, and the first write set includes 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.

In one embodiment, the target consensus node also 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 multiple states; 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.

In one implementation, the receiving unit 901 is further configured to: receive a consensus proposal from a consensus node of the second type, wherein the consensus proposal includes the first read set.

In one embodiment, the target consensus node also includes: a block storage unit (not shown in the figure), configured to generate blocks corresponding to the multiple first transactions according to the execution results of the multiple first transactions, and store the blocks.

In one embodiment, the target consensus node also includes: a message sending unit (not shown in the figure), configured to send a message to the blockchain system in response to meeting a preset condition, so as to modify the type of the target consensus node to the second type in the node type information.

In one embodiment, the node type information is stored in the contract state of the contract of the blockchain system, and the message sending unit is further configured to: send a transaction to call the contract to the blockchain system to modify the type of the target consensus node to the second type in the contract state.

In one embodiment, the node type information is stored in a configuration file of the blockchain system, 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.

In one embodiment, the node type information is stored in the block header of the latest block of the blockchain system, 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.

In one embodiment, 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 passes, 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.

In one embodiment, when the consensus proposal including the second read set is not sent to other consensus nodes within a second preset time, the blockchain system is triggered to perform a master node conversion.

In one implementation, the verification data includes hash value data in a tree structure, multiple leaf nodes of the hash value data respectively include hash values of the multiple states, and the verification unit 902 is further configured to: perform SPV verification on the first state based on the hash value data.

In one embodiment, the storage unit is further configured to obtain a first leaf node in the hash value data corresponding to the second state, and replace the state hash value in the first leaf node with the second state.

In one embodiment, the consensus proposal also includes an arrangement order of the multiple first transactions, the first read set is generated by pre-executing the multiple first transactions by the second type of consensus node, and the pre-execution order of the multiple first transactions corresponds to the arrangement order.

The embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 8 .

The embodiment of the present 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, the method shown in FIG. 8 is implemented.

In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing programs. The original code before compilation must also be written in a specific programming language, which is called Hardware Description Language (HDL). There is not only one kind of HDL, but many kinds, 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 ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that realizes the logic method flow.

The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer readable medium storing a computer readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, 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, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that in addition to implementing the controller in a purely computer readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the means for implementing various functions included therein may also be considered as a structure within the hardware component. Or even, the means for implementing various functions may be considered as both a software module for implementing the method and a structure within the hardware component.

The systems, devices, modules or units described in the above embodiments may be 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 exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, product or device including a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements inherent to such process, method, product or device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and/or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The present invention is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the embodiment of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram 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 device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

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

Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined in this article, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

A method for converting the type of a consensus node is applied to a target consensus node in a blockchain system, wherein the types of the consensus nodes in the blockchain system include a first type and a second type, the second type of consensus node includes state data, the state data includes multiple states, the first type of consensus node includes verification data, the verification data corresponds to the multiple states, the blockchain system stores node type information, the node type information is used to indicate that the target consensus node is converted from the current first type to the second type, and the method includes:

receiving, from a consensus node of the second type, a first read set of a plurality of first transactions to be executed, the first read set comprising a first state read according to the plurality of first transactions;

Verifying the first read set based on the verification data, and after the verification passes, executing the plurality of first transactions based on the first read set to obtain a first write set, wherein the first write set includes a second state for updating the state data;

storing the second state;

The verification data is updated according to the second state.
The method according to claim 1, wherein the method further comprises:

Sending 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 multiple states;

The data fed back by the second type of consensus node in response to the data synchronization request is stored.
The method of claim 1, wherein receiving a first read set of a plurality of first transactions to be executed from a consensus node of the second type comprises:

A consensus proposal is received from a consensus node of the second type, the consensus proposal including the first read set.
The method according to claim 1, wherein the method further comprises:

Generate blocks corresponding to the multiple first transactions according to the execution results of the multiple first transactions, and store the blocks.
The method according to claim 2, wherein the method further comprises:

In response to satisfying a preset condition, sending a message to the blockchain system to modify the type of the target consensus node to the second type in the node type information.
The method according to claim 5, wherein the node type information is stored in the contract state of the contract of the blockchain system, and the sending of the message to the blockchain system comprises:

A transaction for calling a contract is sent to the blockchain system to modify the type of the target consensus node to the second type in the contract state.
The method according to claim 5, wherein the node type information is stored in a configuration file of the blockchain system, and sending a message to the blockchain system comprises:

A configuration file update message is sent to the blockchain system to modify the type of the target consensus node to the second type in the configuration file.
The method according to claim 5, wherein the node type information is stored in a block header of the latest block of the blockchain system, and sending a message to the blockchain system comprises:

A transaction of a specific type is sent to the blockchain system, so as to modify the type of the target consensus node to the second type in a block header corresponding to the transaction of the specific type.
According to the method described in any one of claims 5 to 8, 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 passes, 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.
The method according to claim 9, wherein, when the consensus proposal including the second read set is not sent to other consensus nodes within a second preset time, the blockchain system is triggered to perform a master node conversion.
The method according to claim 1, wherein the verification data comprises hash value data in a tree structure, and a plurality of leaf nodes of the hash value data respectively comprise hash values of the plurality of states, and

The verifying the first read set based on the verification data includes:

Perform SPV verification on the first state based on the hash value data.
According to the method of claim 11, storing the second state includes: obtaining a first leaf node corresponding to the second state in the hash value data, and replacing the state hash value in the first leaf node with the second state.
According to the method of claim 3, the consensus proposal also includes an arrangement order of the multiple first transactions, the first read set is generated by pre-executing the multiple first transactions by the second type of consensus node, and the pre-execution order of the multiple first transactions corresponds to the arrangement order.
A consensus node, wherein the types of consensus nodes in a blockchain system include a first type and a second type, the second type of consensus node includes state data, the state data includes multiple states, the first type of consensus node includes verification data, the verification data corresponds to the multiple states, the blockchain system stores node type information, the node type information is used to indicate that a target consensus node is converted from the current first type to the second type, and the target consensus node includes:

a receiving unit configured to receive a first read set of a plurality of first transactions to be executed from a consensus node of the second type, wherein the first read set includes a first state read according to the plurality of first transactions;

a verification unit configured to verify the first read set based on the verification data, and after the verification passes, execute the plurality of first transactions based on the first read set to obtain a first write set, wherein the first write set includes a second state for updating the state data;

a storage unit configured to store the second state;

An updating unit is configured to update the verification data according to the second state.
A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in any one of claims 1 to 13.
A computing device comprises a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 13 is implemented.