Transaction processing methods, devices, and blockchain systems in blockchain systems

Abstract

This specification provides a transaction processing method, apparatus, and blockchain system in its embodiments. The consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes. FVP type consensus nodes store state data, which includes multiple states. LVP type consensus nodes store verification data, which corresponds to the multiple states. This method is applied to the consensus nodes in the blockchain system and includes: obtaining a first transaction, which is used to add a target node and includes the type of the target node; obtaining node information of the blockchain system, which includes the type of each consensus node in the blockchain system; and agreeing to the addition of the target node when the actual value of the FVP number after adding the target node in the blockchain system in the future, based on the node information, meets a preset minimum FVP number requirement. The FVP number is the number of FVP type consensus nodes in the blockchain system.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction processing method, apparatus and blockchain system in a blockchain system. Background Technology

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

[0003] The purpose of this invention is to provide a transaction processing method, apparatus and blockchain system in a blockchain system, which can classify consensus nodes in the blockchain system into FVP type consensus nodes and LVP type consensus nodes, thereby reducing the storage cost of the blockchain system and ensuring network activity.

[0004] This specification provides a transaction processing method in a blockchain system. The consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes. The FVP type consensus nodes store state data, which includes multiple states. The LVP type consensus nodes store verification data, which corresponds to the multiple states. The method is applied to the consensus nodes in the blockchain system and includes: obtaining a first transaction for adding a target node, and including the type of the target node; obtaining node information of the blockchain system, including the type of each consensus node in the blockchain system; and agreeing to the addition of the target node when the actual value of the FVP number after adding the target node in the future, based on the node information, meets a preset minimum FVP number requirement; wherein the FVP number is the number of FVP type consensus nodes in the blockchain system.

[0005] A second aspect of this specification provides a transaction processing method in a blockchain system. The consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes. The FVP type consensus nodes store state data, which includes multiple states. The LVP type consensus nodes store verification data, which corresponds to the multiple states. The method is applied to the consensus nodes in the blockchain system and includes: obtaining a first transaction for deleting a target node; obtaining node information of the blockchain system, which includes the type of each consensus node in the blockchain system; and agreeing to the target node's exit when the actual value of the FVP count determined based on the node information meets a preset minimum FVP count requirement. The FVP count is the number of FVP type consensus nodes in the blockchain system.

[0006] This specification provides a transaction processing apparatus in a blockchain system. The consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes. The FVP type consensus nodes store state data, which includes multiple states. The LVP type consensus nodes store verification data, which corresponds to the multiple states. The apparatus is applied to the consensus nodes in the blockchain system and includes: a transaction acquisition unit configured to acquire a first transaction for adding a target node, and including the type of the target node; a node information acquisition unit configured to acquire node information of the blockchain system, including the type of each consensus node in the blockchain system; and a processing unit configured to agree to the addition of the target node when the actual value of the FVP number after adding the target node in the blockchain system in the future, based on the node information, meets a preset minimum FVP number requirement; wherein the FVP number is the number of FVP type consensus nodes in the blockchain system.

[0007] This specification provides a transaction processing apparatus in a blockchain system, wherein the consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes. The FVP type consensus nodes store state data, which includes multiple states. The LVP type consensus nodes store verification data, which corresponds to the multiple states. The apparatus is applied to the consensus nodes in the blockchain system and includes: a transaction acquisition unit configured to acquire a first transaction for deleting a target node; a node information acquisition unit configured to acquire node information of the blockchain system, which includes the type of each consensus node in the blockchain system; and a processing unit configured to agree to the exit of the target node when the actual value of the FVP number determined based on the node information meets a preset minimum FVP number requirement; wherein the FVP number is the number of FVP type consensus nodes in the blockchain system.

[0008] The fifth aspect of this specification provides a blockchain system in which consensus nodes include full consensus nodes (FVP type) and light consensus nodes (LVP type). The FVP type consensus nodes store state data, which includes multiple states. The LVP type consensus nodes store verification data, which corresponds to the multiple states. The consensus nodes in the blockchain system are used to execute methods as described in either the first or second aspect.

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

[0010] A seventh aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in either the first or second aspect.

[0011] An eighth aspect of this specification provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the method described in either the first or second aspect.

[0012] The solutions provided in the embodiments described above in this specification can classify consensus nodes in a blockchain system into FVP-type consensus nodes and LVP-type consensus nodes, with only lightweight storage stored in LVP-type consensus nodes. In this solution, when a target node needs to be added or deleted from the blockchain system, the consensus nodes can perform network activity detection based on the minimum FVP requirement for the node addition or deletion scenario. This reduces the storage cost of the blockchain system while ensuring network activity. Attached Figure Description

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

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

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

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

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

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

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

[0020] Figure 7 This is a flowchart of the consensus method in the embodiments of this specification;

[0021] Figure 8 This is a flowchart of a consensus method in another embodiment of this specification;

[0022] Figure 9 This is a flowchart of the transaction processing method in the embodiments of this specification;

[0023] Figure 10 This is a schematic diagram of node information in a blockchain system;

[0024] Figure 11 This is a schematic diagram of the updated node information;

[0025] Figure 12 This is a flowchart of the transaction processing method in the embodiments of this specification;

[0026] Figure 13 This is a flowchart of the transaction processing method in the embodiments of this specification;

[0027] Figure 14 This is a schematic diagram of node information in a blockchain system;

[0028] Figure 15 This is a schematic diagram of the transaction processing device in the embodiments of this specification;

[0029] Figure 16 This is a schematic diagram of the transaction processing device in the embodiments of this specification. Detailed Implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0049] In summary, an FVP node includes tree-like state data. The leaf nodes of this state data include the state of an account or contract variable. Each node in the path from the root node to the leaf node in the state data includes the key of the state. The parent node in the state data includes a hash value calculated based on the data in its child nodes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0069] In addition, LVP can also store the block headers of each block, such as Figure 3As shown, the block header may include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree. The block header can be used to perform SPV verification on data such as transactions and receipts, and can also be used to generate the block header of the next block.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0087] Figure 8 This is a flowchart of a consensus method according to another embodiment of this specification. In this embodiment, LVP may include a consensus device, a storage device, and an execution device. The consensus device, storage device, and execution device may be separate units within a single computing device, or they may be multiple separate computing devices. The storage device stores verification data and block headers, among other data, from the LVP.

[0088] like Figure 8As shown, in step S801, FVP acquires the read sets corresponding to multiple transactions. This step can be referred to the description of step S701 above, and will not be repeated here.

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

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

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

[0092] In step S809, if the verification is successful, the storage device returns the successful verification result to the consensus device.

[0093] In step S811, the consensus device sends a transaction list and read set of multiple transactions to the execution device. The transaction list includes the transaction body of each of the multiple transactions and the order in which the multiple transactions are arranged.

[0094] In step S813, the execution device executes multiple transactions based on the read set.

[0095] The execution device can obtain the execution results of each transaction by executing each transaction according to the read set. The execution results include, for example, the write set and receipt of each transaction.

[0096] In step S815, the execution device returns the execution results of multiple transactions to the consensus device.

[0097] In step S817, the consensus device generates block hash values ​​corresponding to multiple transactions based on the execution results of multiple transactions. This step can be referred to the relevant description in the description of step S711 above, and will not be repeated here.

[0098] In step S819, the consensus nodes (including FVP and LVP) reach a consensus on the block hash value. That is, the consensus devices of each consensus node reach a consensus on the block hash value.

[0099] In step S821, if consensus on the block hash value is successful, the consensus device sends the generated block header and updated verification data to the storage device. The updated verification data may include, for example, […]. Figure 5 The state hash tree and the updated node values ​​in the storage hash tree are shown.

[0100] In step S823, the storage device stores the block header and updates the verification data.

[0101] This specification also provides transaction processing solutions in its embodiments. In blockchain systems based on FVP and LVP, the transaction processing solutions provided in these embodiments can reduce the storage costs of the blockchain system while ensuring network activity. It should be noted that a light consensus node in a blockchain system is a consensus node configured with LVP, and can be referred to as an LVP-type consensus node. A full consensus node in a blockchain system is a consensus node configured with FVP, and can be referred to as an FVP-type consensus node. For clarity in describing the transaction processing solutions, light consensus nodes will be referred to as LVP-type consensus nodes, and full consensus nodes will be referred to as FVP-type consensus nodes.

[0102] In this transaction processing scheme, consensus nodes in the blockchain system (such as FVP-type consensus nodes and LVP-type consensus nodes) can obtain transactions (which can be called the first transaction) used to add or delete target nodes, and process the first transaction.

[0103] Below, we will take the first transaction used to add a new target node as an example to introduce the transaction processing scheme in the embodiments of this specification.

[0104] Figure 9 This is a flowchart of the transaction processing method in the embodiments of this specification. The consensus nodes in the blockchain system include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. Specifically, the verification data may include the hash values ​​of each of the multiple states. This method can be executed by the consensus nodes in the blockchain system (such as FVP-type consensus nodes and LVP-type consensus nodes).

[0105] like Figure 9 As shown, firstly, in step S901, a first transaction is obtained. The first transaction is used to add a target node and includes the type of the target node.

[0106] Specifically, when a target node is to join the blockchain system as an FVP-type consensus node, the type of the target node included in the first transaction can be represented as "FVP" or other characters used to represent FVP (such as the number 1). When a target node is to join the blockchain system as an LVP-type consensus node, the type of the target node included in the first transaction can be represented as "LVP" or other characters used to represent LVP (such as the number 0). It should be understood that the embodiments in this specification do not specifically limit the representation of node types.

[0107] It should be noted that the first transaction may also include the identifier of the target node. The first transaction can be sent to the blockchain system by the blockchain system administrator or the owner of the target node via a user device. For example, the administrator or owner can send the first transaction to a specific FVP-type consensus node in the blockchain system via the user device. This specific FVP-type consensus node can be the master node in the blockchain system.

[0108] When a transaction processing method is executed by an LVP-type consensus node, that LVP-type consensus node can cache multiple transactions to be executed received from an FVP-type consensus node, and the first transaction can be included in these multiple transactions. Therefore, the LVP-type consensus node can obtain the first transaction from these multiple transactions.

[0109] In step S903, the node information of the blockchain system is obtained, including the type of each consensus node in the blockchain system.

[0110] The representation of FVP-type and LVP-type consensus nodes in the node information can be found in the previous explanations and will not be repeated here. Optionally, the node information may also include at least one of the following: node identifier, total number of consensus nodes, and actual value of the number of FVPs. The number of FVPs refers to the number of FVP-type consensus nodes in the blockchain system.

[0111] In practice, node information in a blockchain system can be stored in different locations.

[0112] In one implementation, FVP-type consensus nodes also store blocks, and LVP-type consensus nodes also store the block headers of those blocks; node information can be stored in the block headers. Based on this, both FVP and LVP-type consensus nodes can obtain node information from the block headers when executing transaction processing methods. For example, node information can be retrieved starting from the latest block header. It should be noted that when there is only one block in the blockchain system—the genesis block—node information can be stored in the genesis block header, and node information can be obtained from the genesis block header.

[0113] In another implementation, smart contracts can be deployed in the blockchain system, and node information can be stored in the contract state of the smart contract within an FVP-type consensus node. When a transaction processing method is executed by an FVP-type consensus node, the FVP-type consensus node can retrieve the node information from the contract state. When a transaction processing method is executed by an LVP-type consensus node, the specific execution process can be found in [reference needed]. Figure 12 The relevant descriptions in the corresponding embodiments.

[0114] In step S905, when the actual value of the number of FVPs after the addition of the target node in the blockchain system in the future is determined based on the node information to meet the preset minimum requirement for the number of FVPs, the target node is approved to join.

[0115] For example, the minimum requirement for the number of FVPs can include an expression representing the expected lower bound of the number of FVPs. In the case of a blockchain system using the PBFT consensus algorithm, this expression could be, for example, f+1, where f is the number of malicious nodes. Based on the previous introduction to the PBFT consensus algorithm, we know that the total number of consensus nodes N and the number of malicious nodes f in a blockchain system satisfy the following constraint: N≥3f+1. f can be calculated based on this constraint. Specifically, when N=3f+1, f=(N-1) / 3.

[0116] Therefore, based on node information and an expression representing the expected lower bound of the number of FVPs, the actual value and expected lower bound of the number of FVPs after adding target nodes to the blockchain system can be determined. Then, these two values ​​can be compared. When the actual value is greater than or equal to the expected lower bound, the target node can be approved for joining. When the actual value is less than the expected lower bound, the target node can be rejected for joining.

[0117] See Figure 10 This is a schematic diagram of node information in a blockchain system. For example... Figure 10 As shown, the node information indicates that the blockchain system includes 6 consensus nodes, namely VP0-VP5. Among them, VP0-VP2 are all of type FVP, and VP3-VP5 are all of type LVP. Based on this node information, it can be known that the current actual number of FVPs is 3, and the total number of consensus nodes is 6.

[0118] Assuming the blockchain system uses the PBFT consensus algorithm, the expression for the expected lower bound of the number of FVPs is f+1, and the type of target node included in the first transaction is LVP. Based on Figure 10The node information shown indicates that after the addition of a target node to the blockchain system, the total number of consensus nodes will be N = 7, and the actual number of FVPs will be Q2 = 3. Substituting the total number of consensus nodes N = 7 into the formula f = (N-1) / 3, we can calculate f = 2. Based on f = 2 and the expression f+1 used to characterize the expected lower limit of the number of FVPs, we can calculate the expected lower limit of the number of FVPs after the addition of a target node to the blockchain system, Q1 = 2 + 1 = 3. By comparing Q1 and Q2, we can determine that Q2 = Q1, which meets the preset minimum requirement for the number of FVPs, thus allowing the target node to join. Therefore, we can ensure that the actual number of FVPs after the addition of a target node to the blockchain system is greater than the number of malicious nodes f, thereby effectively guaranteeing the network activity of the blockchain system. For example, even if f malicious nodes all appear in the FVP type consensus nodes, we can ensure that at least one FVP type consensus node can operate normally, thus ensuring the normal operation of the blockchain system.

[0119] In one implementation, an LVP-type consensus node may include the consensus device described above. When the transaction processing method is executed by the LVP-type consensus node, the consensus device in the LVP-type consensus node can determine, based on node information, whether the actual value of the FVP number after the addition of a target node in the blockchain system in the future meets the preset minimum FVP number requirement, thereby obtaining the result of agreeing to or rejecting the target node's joining.

[0120] In one implementation, when obtaining node information of the blockchain system from the block header, updated node information, including information about the target node, can also be stored in the block header of the block to be generated. As an example, in... Figure 10 Based on the node information shown, the target node's information can be written below the VP5 information. The target node's information can be as follows: Figure 11 The diagram shows the target node's identifier "VP6" and type "LVP". Among them, Figure 11 This is a schematic diagram of the updated node information. The identifier "VP6" could, for example, be assigned to the target node by executing the first transaction.

[0121] In one implementation, where a smart contract is deployed in the blockchain system and node information is stored in the contract state of the smart contract within an FVP-type consensus node, when the transaction processing method is executed by the FVP-type consensus node, the FVP-type consensus node can also add the target node's information to the node information in the contract state based on the execution result of the first transaction.

[0122] In one implementation, when the transaction processing method is executed by an FVP-type consensus node, the FVP-type consensus node can also synchronize data with the target node upon receiving a data synchronization request from the target node. Specifically, the type of the target node can be used to determine which data needs to be synchronized to the target node, thereby performing data synchronization on the target node. In practice, after successfully joining the blockchain system, the target node can obtain data from FVP-type consensus nodes. For example, when the target node is an LVP-type consensus node, it can obtain data from FVP-type consensus nodes; when the target node is an FVP-type consensus node, it can obtain data from other FVP-type consensus nodes.

[0123] Figure 9 The corresponding implementation provides a transaction processing scheme that categorizes consensus nodes in a blockchain system into FVP-type consensus nodes and LVP-type consensus nodes, with LVP-type consensus nodes storing only lightweight storage. In this scheme, when a target node needs to be added to the blockchain system, the consensus nodes can perform network activity checks based on the minimum FVP requirement for the node addition scenario. This reduces the storage cost of the blockchain system while ensuring network activity.

[0124] In practice, when a smart contract is deployed in a blockchain system, and node information is stored in the contract state of that smart contract within an FVP-type consensus node, when the transaction processing method is executed by an LVP-type consensus node, that LVP-type consensus node can execute, for example... Figure 12 The process is shown below. Among them, Figure 12 This is a flowchart of the transaction processing method in the embodiments of this specification.

[0125] like Figure 12 As shown, firstly, in step S1201, the LVP-type consensus node obtains the first transaction, which is used to add a target node and includes the type of the target node.

[0126] An LVP-type consensus node can cache multiple transactions to be executed received from an FVP-type consensus node, and the first transaction can be included in these multiple transactions. Therefore, an LVP-type consensus node can obtain the first transaction from these multiple transactions.

[0127] In step S1203, the LVP-type consensus node obtains the node information of the blockchain system from the cached read set. The node information includes the type of each consensus node in the blockchain system.

[0128] This read set is received from an FVP-type consensus node and includes node information read from the contract state of the aforementioned smart contract within the FVP-type consensus node based on the first transaction. It should be noted that this read set may correspond to multiple transactions and may be included in the consensus proposal related to these multiple transactions received from the FVP-type consensus node.

[0129] In one implementation, before obtaining node information of the blockchain system from the read set, LVP-type consensus nodes can first verify the read set based on stored verification data. The specific verification process can be found in [reference needed]. Figure 7 The relevant descriptions in the corresponding embodiments will not be repeated here. Therefore, LVP-type consensus nodes can obtain node information from the read set if the read set passes verification.

[0130] In step S1205, when the LVP-type consensus node determines, based on the node information, that the actual number of FVPs after the addition of the target node in the blockchain system in the future meets the preset minimum FVP requirement, it agrees to the target node joining. This step can be referred to the description of step S905 above, and will not be repeated here.

[0131] In one implementation, LVP-type consensus nodes can also update the verification data based on the execution result of the first transaction. For details on the verification data update process, please refer to [link / reference needed]. Figure 7 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0132] The preceding text used the first transaction for adding a target node as an example to introduce the transaction processing scheme in the embodiments of this specification. Below, the text will use the first transaction for deleting a target node as an example to further introduce the transaction processing scheme in the embodiments of this specification.

[0133] See Figure 13 This is a flowchart of the transaction processing method in the embodiments of this specification. The consensus nodes in the blockchain system include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. Specifically, the verification data may include the hash values ​​of each of the multiple states. This method can be executed by the consensus nodes in the blockchain system (such as FVP-type consensus nodes and LVP-type consensus nodes).

[0134] like Figure 13 As shown, firstly, in step S1301, the first transaction is obtained, which is used to delete the target node.

[0135] The first transaction may include the identifier of the target node. Furthermore, the first transaction may also include the type of the target node. For details on how to obtain the first transaction, please refer to the relevant explanations above; they will not be repeated here.

[0136] In step S1303, the node information of the blockchain system is obtained, including the type of each consensus node in the blockchain system. This step can be referred to the description of step S903 above, and will not be repeated here.

[0137] In step S1305, when the actual value of the number of FVPs determined based on the node information meets the preset minimum requirement for the number of FVPs, the target node is allowed to exit.

[0138] The minimum requirement for the number of FVPs can, for example, include an expression representing the expected lower bound of the number of FVPs. In the case of a blockchain system using the PBFT consensus algorithm, this expression could be, for example, f+2.

[0139] Based on this, the actual value and expected lower bound of the FVP count can be determined using node information and an expression representing the expected lower bound of the FVP count. It should be understood that these actual and expected lower bounds represent the current actual and expected lower bounds of the FVP count, i.e., the actual and expected lower bounds of the FVP count before the target node is deleted from the blockchain system. Then, these actual and expected lower bounds can be compared. When the actual value is greater than or equal to the expected lower bound, the target node's exit can be approved.

[0140] See Figure 14 This is a schematic diagram of node information in a blockchain system. For example... Figure 14 As shown, the node information indicates that the blockchain system includes 7 consensus nodes, namely VP0-VP6. Among them, VP0-VP3 are all of type FVP, and VP4-VP6 are all of type LVP. Based on this node information, it can be known that the current actual number of FVPs is 4, and the total number of consensus nodes is 7.

[0141] Assuming the blockchain system uses the PBFT consensus algorithm, the expression for the expected lower bound of the number of FVPs is f+2, and the first transaction specifically deletes VP6. Based on this node information, the total number of consensus nodes is determined to be N=7, and the actual number of FVPs is Q2=4. Substituting the total number of consensus nodes N=7 into the formula f=(N-1) / 3, we can calculate f=2. Based on f=2 and the expression for the expected lower bound of the number of FVPs f+2, the expected lower bound of the number of FVPs can be calculated as Q1=2+2=4. By comparing Q1 and Q2, we can determine that Q2=Q1, which meets the preset minimum requirement for the number of FVPs, thus allowing the target node to exit. Therefore, it can be ensured that the actual number of FVPs after the target node exits the blockchain system in the future is greater than the number of malicious nodes f, thereby effectively guaranteeing the network activity of the blockchain system.

[0142] Figure 13 The corresponding implementation provides a transaction processing scheme that categorizes consensus nodes in a blockchain system into FVP-type consensus nodes and LVP-type consensus nodes, with LVP-type consensus nodes storing only lightweight storage. In this scheme, when a target node exits the blockchain system, the consensus nodes can perform network activity checks based on the minimum FVP requirement for node exit. This reduces the storage cost of the blockchain system while ensuring network activity.

[0143] Figure 15 This is a schematic diagram of the transaction processing device in the embodiments of this specification. The consensus nodes in the blockchain system include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. This device can be applied to consensus nodes (such as FVP-type and LVP-type consensus nodes) in a blockchain system.

[0144] like Figure 15 As shown in the embodiments of this specification, the transaction processing device 1500 includes: a transaction acquisition unit 1501, a node information acquisition unit 1502, and a processing unit 1503. The transaction acquisition unit 1501 is configured to acquire a first transaction, which is used to add a target node and includes the type of the target node; the node information acquisition unit 1502 is configured to acquire node information of the blockchain system, including the type of each consensus node in the blockchain system; the processing unit 1503 is configured to approve the addition of the target node when the actual value of the number of FVPs after adding the target node in the blockchain system in the future, based on the node information, meets a preset minimum requirement for the number of FVPs; the number of FVPs is the number of FVP-type consensus nodes in the blockchain system.

[0145] In some embodiments, the minimum requirement for the number of FVPs includes an expression representing the expected lower limit of the number of FVPs; and the processing unit 1503 may be further configured to: determine the actual value and the expected lower limit of the number of FVPs after the addition of a target node in the blockchain system in the future, based on node information and the expression; and agree to the addition of the target node when the actual value is greater than or equal to the expected lower limit.

[0146] In some embodiments, a smart contract is deployed in the blockchain system, and node information is stored in the contract state of the smart contract within the FVP-type consensus node; the first transaction invokes the smart contract, and when the above-mentioned device 1500 is applied to the FVP-type consensus node, the above-mentioned device 1500 may further include: a first storage unit (not shown in the figure), configured to add the target node information to the node information in the contract state based on the execution result of the first transaction.

[0147] In some embodiments, when the above-described device 1500 is applied to an LVP-type consensus node, the LVP-type consensus node caches a read set received from an FVP-type consensus node, the read set including node information read from the contract state according to the first transaction; and the node information acquisition unit 1502 may be further configured to: acquire node information from the read set.

[0148] In some embodiments, the above-described apparatus 1500 may further include: a verification unit (not shown in the figure) configured to verify the read set based on stored verification data; and a node information acquisition unit 1502 may be further configured to: acquire node information from the read set after the read set has passed verification.

[0149] In some embodiments, the above-described apparatus 1500 may further include: a verification data update unit (not shown in the figure), configured to update verification data based on the execution result of the first transaction.

[0150] In some embodiments, FVP-type consensus nodes also store blocks, and LVP-type consensus nodes also store the block header of the block, with node information stored in the block header; and the node information acquisition unit 1502 may be further configured to: acquire node information from the block header; the above-mentioned device 1500 may also include: a second storage unit (not shown in the figure), configured to store updated node information in the block header of the block to be generated, the updated node information including the information of the target node.

[0151] In some embodiments, when the above-described apparatus 1500 is applied to an FVP-type consensus node, the above-described apparatus 1500 may further include: a data synchronization unit (not shown in the figure), configured to synchronize data to the target node when a data synchronization request is received from the target node.

[0152] Figure 16 This is a schematic diagram of the transaction processing device in the embodiments of this specification. The consensus nodes in the blockchain system include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. This device can be applied to consensus nodes (such as FVP-type and LVP-type consensus nodes) in a blockchain system.

[0153] like Figure 16 As shown in the embodiments of this specification, the transaction processing device 1600 includes: a transaction acquisition unit 1601, a node information acquisition unit 1602, and a processing unit 1603. The transaction acquisition unit 1601 is configured to acquire a first transaction used to delete a target node; the node information acquisition unit 1602 is configured to acquire node information of the blockchain system, including the type of each consensus node in the blockchain system; the processing unit 1603 is configured to agree to the target node's exit when the actual value of the FVP number determined based on the node information meets a preset minimum FVP number requirement; the FVP number is the number of FVP type consensus nodes in the blockchain system.

[0154] exist Figure 15 , 16 For further explanation of each unit in the corresponding device embodiments, please refer to the relevant descriptions of the relevant method embodiments above, which will not be repeated here.

[0155] This specification also provides a blockchain system in which consensus nodes include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. The consensus nodes in the blockchain system are used to obtain a first transaction, which is used to add a target node and includes the type of the target node; obtain node information of the blockchain system, including the type of each consensus node in the blockchain system; and agree to the addition of the target node when the actual value of the FVP number after adding the target node in the future, based on the node information, meets a preset minimum FVP number requirement. The FVP number is the number of FVP-type consensus nodes in the blockchain system.

[0156] This specification also provides a blockchain system in which consensus nodes include FVP-type consensus nodes and LVP-type consensus nodes. FVP-type consensus nodes store state data, which includes multiple states. LVP-type consensus nodes store verification data, which corresponds to the multiple states. The consensus nodes in the blockchain system are used to obtain a first transaction, which deletes a target node; obtain node information of the blockchain system, including the type of each consensus node; and agree to the target node's exit when the actual value of the FVP count, determined based on the node information, meets a preset minimum FVP count requirement. The FVP count is the number of FVP-type consensus nodes in the blockchain system.

[0157] This specification also provides a computer-readable storage medium storing a computer program thereon, wherein when the computer program is executed in a computer, it causes the computer to perform the transaction processing method described in the above method embodiments.

[0158] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the transaction processing method described in the above method embodiments.

[0159] This specification also provides a computer program in its embodiments, wherein when the computer program is executed in a computer, it causes the computer to perform the transaction processing method described in the above method embodiments.

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

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

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

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

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

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

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

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

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

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

[0170] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

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

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

Claims

1. A transaction processing method in a blockchain system, wherein the consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes, wherein the FVP type consensus nodes store state data including multiple states, and the LVP type consensus nodes store verification data corresponding to the multiple states, used to verify read sets received from the FVP type consensus nodes, the method being applied to the consensus nodes in the blockchain system, comprising: Obtain the first transaction, which is used to add a target node and includes the type of the target node; The target node type includes any one of the following: FVP, LVP; Obtain the node information of the blockchain system, wherein the node information includes the type of each consensus node in the blockchain system; When the actual value of the number of FVPs after the target node is added to the blockchain system in the future meets the preset minimum requirement for the number of FVPs, the target node is approved to join; the number of FVPs is the number of FVP type consensus nodes in the blockchain system.

2. The method according to claim 1, wherein, The minimum requirement for the number of FVPs includes an expression for characterizing the expected lower limit value of the number of FVPs; as well as The method further includes: Based on the node information and the expression, determine the actual value and expected lower limit of the number of FVPs after the target node is added to the blockchain system in the future; The step of agreeing to the addition of the target node when the actual value of the FVP number after the target node is added to the blockchain system in the future, based on the node information, meets the preset minimum FVP number requirement, includes: When the actual value is greater than or equal to the expected lower limit, the target node is allowed to join.

3. The method according to claim 1, wherein, The blockchain system is equipped with smart contracts, and the node information is stored in the contract state of the smart contract within the FVP-type consensus node. The first transaction invokes the smart contract. When the method is executed by an FVP-type consensus node, the method further includes: Based on the execution result of the first transaction, the information of the target node is added to the node information in the contract state.

4. The method according to claim 3, wherein, When the method is executed by an LVP-type consensus node, the LVP-type consensus node caches a read set received from an FVP-type consensus node, the read set including the node information read from the contract state according to the first transaction; as well as The process of obtaining the node information of the blockchain system includes: Obtain the node information from the read set.

5. The method according to claim 4, wherein, The step of obtaining the node information from the read set includes: The read set is verified based on the verification data; After the read set is verified, the node information is obtained from the read set.

6. The method according to claim 5, further comprising: The verification data is updated based on the execution result of the first transaction.

7. The method according to claim 1, wherein, The FVP type consensus node also stores blocks, and the LVP type consensus node also stores the block header of the block, with the node information stored in the block header; as well as The process of obtaining the node information of the blockchain system includes: Obtain the node information from the block header; The method further includes storing updated node information in the block header of the block to be generated, wherein the updated node information includes information about the target node.

8. The method according to claim 3 or 7, wherein, When the method is executed by an FVP-type consensus node, the method further includes: Upon receiving a data synchronization request from the target node, synchronize data with the target node.

9. A transaction processing method in a blockchain system, wherein the consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes, wherein the FVP type consensus nodes store state data including multiple states, and the LVP type consensus nodes store verification data corresponding to the multiple states, used to verify read sets received from the FVP type consensus nodes, the method being applied to the consensus nodes in the blockchain system, comprising: Obtain the first transaction, which is used to delete the target node; The first transaction includes the type of the target node; The target node type includes any one of the following: FVP, LVP; Obtain the node information of the blockchain system, wherein the node information includes the type of each consensus node in the blockchain system; When the actual value of the number of FVPs determined based on the node information meets the preset minimum requirement for the number of FVPs, the target node is allowed to exit; the number of FVPs is the number of FVP type consensus nodes in the blockchain system.

10. A transaction processing apparatus in a blockchain system, wherein the consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes, the FVP type consensus nodes storing state data including multiple states, the LVP type consensus nodes storing verification data corresponding to the multiple states, used to verify read sets received from the FVP type consensus nodes, the apparatus being applied to the consensus nodes in the blockchain system, comprising: The transaction acquisition unit is configured to acquire a first transaction, which is used to add a target node and includes the type of the target node; The target node type includes any one of the following: FVP, LVP; The node information acquisition unit is configured to acquire node information of the blockchain system, the node information including the type of each consensus node in the blockchain system. The processing unit is configured to agree to the addition of the target node when the actual value of the number of FVPs after the target node is added to the blockchain system in the future, based on the node information, meets the preset minimum requirement for the number of FVPs; the number of FVPs is the number of FVP type consensus nodes in the blockchain system.

11. A transaction processing apparatus in a blockchain system, wherein the consensus nodes in the blockchain system include Full Validation (FVP) type consensus nodes and Light Validation (LVP) type consensus nodes, the FVP type consensus nodes storing state data including multiple states, the LVP type consensus nodes storing verification data corresponding to the multiple states, used to verify read sets received from the FVP type consensus nodes, the apparatus being applied to the consensus nodes in the blockchain system, comprising: The transaction acquisition unit is configured to acquire a first transaction, which is used to delete the target node; The first transaction includes the type of the target node; The target node type includes any one of the following: FVP, LVP; The node information acquisition unit is configured to acquire node information of the blockchain system, the node information including the type of each consensus node in the blockchain system. The processing unit is configured to allow the target node to exit when the actual value of the number of FVPs determined based on the node information meets the preset minimum requirement for the number of FVPs. The number of FVPs refers to the number of FVP-type consensus nodes in the blockchain system.

12. A blockchain system, wherein the consensus nodes in the blockchain system include full consensus nodes (FVP type) and light consensus nodes (LVP type), wherein the FVP type consensus nodes store state data, the state data including multiple states, and the LVP type consensus nodes store verification data, the verification data corresponding to the multiple states; the consensus nodes in the blockchain system are used to execute the method of any one of claims 1-9.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

14. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-9.

Images