State data software version switching method, blockchain node and blockchain system

Abstract

A state data software version switching method in a blockchain, a blockchain node and a blockchain system, the blockchain comprising a first node and a plurality of second nodes, the first node comprising first state data of M blocks and second state data, the first state data being generated by a first version of state data software, the second state data being generated by a second version of state data software, each second node comprising second state data of the M blocks, the method being performed by the first node and comprising: sending the first state data of the M blocks to each second node; and sending software configuration information to each second node, the software configuration information comprising a version identifier of the first version of state data software to be enabled.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for switching state data software versions in a blockchain, a blockchain node, and 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 is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a solution for switching the state data software version in a blockchain, so as to improve the availability of the blockchain.

[0004] This specification provides a method for switching state data software versions in a blockchain, wherein the blockchain includes a first node and multiple second nodes, the first node includes first state data and second state data of M blocks, the first state data is generated using a first version of state data software, the second state data is generated using a second version of state data software, and each second node includes the second state data of the M blocks, the method being executed by the first node, including:

[0005] Send the first status data of the M blocks to each of the second nodes;

[0006] Software configuration information is sent to each of the second nodes. The software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

[0007] A second aspect of this specification provides a method for switching state data software versions in a blockchain. The blockchain includes a first node and multiple second nodes. The first node includes first state data and second state data for M blocks. The first state data is generated using a first version of state data software, and the second state data is generated using a second version of state data software. Each second node includes the second state data of the M blocks. The method is executed by the second nodes and includes:

[0008] Receive the first status data of the M blocks from the first node;

[0009] The software configuration information is received from the first node, and the software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

[0010] The configuration of the status data software is updated based on the version identifier of the first version.

[0011] A third aspect of this specification provides a first node in a blockchain, the first node including first state data and second state data of M blocks, the first state data being generated using a first version of state data software, and the second state data being generated using a second version of state data software. The blockchain also includes multiple second nodes, each second node including the second state data of the M blocks. The first node includes:

[0012] The first sending unit is used to send the first status data of the M blocks to each of the second nodes;

[0013] The second sending unit is used to send software configuration information to each of the second nodes. The software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

[0014] This specification provides a second node in a blockchain, the blockchain including a first node and multiple second nodes, the first node including first state data and second state data of M blocks, the first state data being generated by a first version of state data software, the second state data being generated by a second version of state data software, each second node including the second state data of the M blocks, and the second node comprising:

[0015] The receiving unit is configured to receive first status data of the M blocks from the first node; and to receive configuration information from the first node, wherein the software configuration information includes a version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

[0016] The update unit is used to update the configuration of the status data software according to the version identifier of the first version.

[0017] This specification provides a fifth aspect of a blockchain system, including a first node and multiple second nodes. The first node includes first state data and second state data for M blocks. The first state data is generated using a first version of state data software, and the second state data is generated using a second version of state data software. Each second node includes the second state data of the M blocks.

[0018] The first node is used to send the first status data of the M blocks to each of the second nodes; and to send software configuration information to each of the second nodes, wherein the software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled;

[0019] The second node is used to update the configuration of the status data software according to the version identifier of the first version.

[0020] 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 methods described in the first or second aspect.

[0021] The seventh aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first or second aspect.

[0022] In the solution provided in the embodiments of this specification, by storing state data of version A and state data of version B in a node of the blockchain at the same time, when a preset fork occurs in the state data of version B, the state data of version A is synchronized from that node to other nodes in the blockchain, and the other nodes are instructed to switch the state data software, so that the blockchain can continue to operate based on the state data software of version A, thereby improving the availability of the blockchain. Attached Figure Description

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

[0024] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0025] Figure 2 This is a schematic diagram of a blockchain data storage structure;

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

[0027] Figure 4 This is a schematic diagram of the state data stored in the blockchain in the embodiments of this specification;

[0028] Figure 5 This is a flowchart illustrating the method for block execution in the embodiments of this specification;

[0029] Figure 6 This is a flowchart illustrating the method for switching state data software versions in a blockchain, as described in the embodiments of this specification.

[0030] Figure 7 This is a schematic diagram of the state data stored in the blockchain node in the embodiments of this specification.

[0031] Figure 8 This is an architecture diagram of the first node in a blockchain according to an embodiment of this specification;

[0032] Figure 9 This is an architecture diagram of a second node in a blockchain according to an embodiment of this specification. Detailed Implementation

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

[0034] 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 transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

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

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

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

[0038] In scenarios where contracts are invoked, for example, Bob sends a transaction to 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.

[0039] Different blockchains can use different state data processing software to handle the state data corresponding to accounts, thus storing the state data in different data structures. Taking Ethereum as an example, accounts typically include two types:

[0040] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0041] Externally owned account: The user's account.

[0042] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as Nonce, Balance, Storage root, and CodeHash. Nonce and Balance exist in both external and contract accounts. CodeHash and Storage root attributes are generally only valid for contract accounts.

[0043] Nonce: A counter. For external accounts, this number can represent the number of transactions sent from the account address; for contract accounts, it can be the number of contracts created by the account.

[0044] Balance: Account balance.

[0045] Storage root: The hash of the root node of an MPT tree, which organizes the storage of state variables for contract accounts.

[0046] CodeHash: The hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since the smart contract is not included, the CodeHash field can generally be an empty string or a string of all zeros.

[0047] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0048] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs (kv) representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (such as the address of an Ethereum account or part of its hash value, hereinafter referred to as the account address), distributed across storage from the root node to the leaf nodes of the state trie. The "value" in the state trie is generated by encoding the information of the Ethereum account using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the value includes nonce and balance; for contract accounts, the value includes nonce, balance, codehash, and storageroot.

[0049] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states defined by state variables within the smart contract, which generate new values ​​when the smart contract executes. A smart contract usually refers to a contract defined in code within a blockchain environment that can automatically execute its terms. Once an event triggers a term in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a storage trie. The hash value of the storage trie's root node is stored in the aforementioned storage root, thus locking all the contract's states to this contract account through hashing. The storage trie is also an MPT tree structure, storing a key-value mapping from state addresses to state values. Information from the root node to the leaf node of the storage trie tree is arranged sequentially to store the address of a state, and the leaf node stores the state's value.

[0050] Figure 2 This is a schematic diagram of a blockchain data storage structure. For example... Figure 2As shown, each block's header includes several fields, such as the previous block hash (prev Hash in the diagram), a nonce number, a timestamp, a block number (Block Num), a state root hash (State_Root), a transaction root hash (Transaction_Root), and a receipt 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 hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set, respectively. The state set, transaction set, and receipt set are organized in a tree structure. Generally, they can be the same tree structure or different tree structures. For example, Ethereum uses the same MPT structure. In some tree structures like Ethereum, which include sets of smart contract states, there is a two-level MPT structure: the leaf nodes of the upper-level MPT structure include two types of external accounts and contract accounts; each contract account includes the lower-level MPT structure, and the leaf nodes of the lower-level structure include the values ​​of the state in the contract account.

[0051] Taking Ethereum as an example again, we can combine Figure 2As shown, `state_root` is the hash value of the root of the MPT tree composed of the states of all accounts in the current block. In other words, pointing to `state_root` is an MPT-style state trie. The root node of this MPT tree is generally an extension node or a branch node, and `state_root` typically stores the hash value of this root node. The root node can be connected to one or more extension nodes / branch nodes below it; these multiple levels of tree nodes can be collectively called internal nodes. A portion of the values ​​from each node from the root node to the leaf node in this MPT can be concatenated sequentially to form an account address as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a portion of the hash value of the account address (using a hash algorithm such as SHA3), and its stored value can be an RLP (Account) encoding of the account information. The account information consists of a four-tuple of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, external accounts typically only have the nonce and balance fields, while the storageRoot and codeHash fields default to storing empty strings or strings of all zeros. This means that external accounts do not store contracts or the state variables generated after contract execution. Contract accounts generally include Nonce, Balance, Storage root, and CodeHash. Nonce is the transaction counter for the contract account; Balance is the account balance; Storage root corresponds to another MPT, which links to contract-related state information; and CodeHash is the hash value of the contract code. Whether external or contract accounts, their account information is generally located in a single leaf node. The path from the root node's Extension Node / Branch Node to each account's Leaf Node may involve several branch nodes and extension nodes.

[0052] The state trie can be an MPT-style tree, typically a 16-ary tree, meaning each level can have a maximum of 16 child nodes. An Extension Node, used to store a common prefix, typically has one child node, which can be a Branch Node. A Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes.

[0053] For a contract account within the state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to the contract's execution state variables. This `storage_root` points to an MPT-form tree called the Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. The key represents the address of the state variable, and its value can be the result of processing the state variable's declaration position (counting from 0) according to certain rules, such as SHA3(state variable declaration position) or SHA3(contract name + state variable declaration position). The value stores the state variable's value (e.g., an RLP-encoded value). A portion of the data stored along the path from the root node through intermediate nodes to the leaf node forms the key, and the leaf node stores the value. As mentioned earlier, this Storage trie can also be an MPT-type tree, typically a 16-ary tree. This means that a Branch Node can have a maximum of 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. An Extension Node typically has one child node, which can be either a Branch Node or a Leaf Node.

[0054] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of nodes reach agreement on the proposed data. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated. That is, when 2f+1 out of N consensus nodes reach agreement, consensus is considered successful.

[0055] Figure 3 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 3As 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 2 As 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, update the world state based on the execution results of the multiple transactions, generate and store a block including the multiple transactions (e.g., block B1), 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 a block. 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.

[0056] In a scenario involving state data software upgrades, assume that version A is a widely used and stable state data software, such as the state data software with the MPT tree structure mentioned above. This means that version A is assumed to be bug-free. Version B, on the other hand, is a newly developed state data software, and it is assumed that version B is used in the blockchain. Because version B has not undergone long-term reliability verification, it may contain undiscovered software vulnerabilities (bugs). These bugs could potentially lead to forks or loss of state data in the blockchain. Specifically, a fork in state data refers to different nodes in the blockchain calculating different state data for the same block, resulting in different root hash values ​​for the same block. Since the calculation methods for the Merkle tree differ between version A and version B, the state data calculated by version A (hereinafter referred to as version A state data) is different from the state data calculated by version B (hereinafter referred to as version B state data). Therefore, when the state data (root hash value of the state data) of version B calculated by multiple nodes in the blockchain for a certain block forks, version B cannot be directly switched to version A in a single node.

[0057] To prevent significant system risks, this specification provides a scheme for switching the state data version of a node in a blockchain. By storing state data of version A and version B simultaneously in a node of the blockchain, when a preset fork occurs in the state data of version B, the state data of version A is synchronized from that node to other nodes in the blockchain, and the other nodes are instructed to switch the state data software, so that the blockchain can continue to operate based on the state data software of version A.

[0058] In the embodiments described in this specification, the blockchain can be started from the genesis block as follows: Figure 4 The storage status data is shown. For example... Figure 4As shown, taking a blockchain with four nodes (n1-n4) as an example, when executing a block, nodes n1-n4 reach a consensus on the state data of version B. After the consensus is passed, they store the state data of version B for that block and generate a block based on the root hash value in the state data of version B. One or more nodes (e.g., node n4) can be configured to generate state data of version A simultaneously with the generation of state data of version B, where the key-value pairs of accounts or state variables in the state data of version B are consistent with those in the state data of version A. Therefore, after consensus has been reached on the key-value pairs of accounts or state variables in version B at node n4, the key-value pairs of accounts or state variables in version A at node n4 can be considered correct. Since version A is a stable version, the state data of version A at node n4 can be considered correct state data.

[0059] In this case, the key-value pairs of the account or state variable in the state data of version A in node n4 are consistent with those in the state data of version B. However, the key-value pairs of each Merkle tree node in the state data of version A and version B may be different. For example, the Merkle tree root hash value in the state data of version A and version B may be different.

[0060] Figure 5 This is a flowchart of the method for executing blocks in the embodiments of this specification. Figure 5 Only nodes n4 and n1 are shown, which is understandable. Figure 4 Nodes n2 and n3 can perform the same process as node n1.

[0061] like Figure 5 As shown, in S501, the consensus among nodes in the blockchain regarding the state data of block B2 exhibits a pre-defined fork.

[0062] Assume that after executing block B1, each node in the blockchain stores the following in the blockchain: Figure 4The blockchain presents the state data and block header of block B1, and then proceeds to execute block B2, which is the next block after block B1. After executing the multiple transactions included in block B2, each node in the blockchain obtains the execution results of each transaction and calculates the root hash value of the state data for version B corresponding to block B2 based on these results. Then, each node in the blockchain can reach a consensus on the root hash value of its calculated version B state data to confirm whether there is a fork in the state data of version B generated by each node. Specifically, each node in the blockchain can generate the block header of block B2 based on its calculated root hash value of state data, transaction data, and receipt data. Then, each node in the blockchain can reach a consensus on the hash value of its generated block header to confirm whether the block headers generated by each node are consistent. If they are consistent, it can be confirmed that there is no fork in the state data of version B generated by each node. Otherwise, it can be determined whether the state data of version B generated by each node meets the preset fork conditions.

[0063] Each node in the blockchain (including node n1 and node n4) can... Figure 3 The consensus process shown achieves consensus on the root hash value of the state data.

[0064] In S503, a pre-defined fork occurs during the consensus process among the nodes in the blockchain.

[0065] In one implementation, the preset fork condition is that consensus on the root hash value of the state data has not been reached. Taking node n4 as an example, during the consensus process with other nodes, if node n4 does not receive consistent confirmation from the other 2f nodes during the preparation phase, or if node n4 does not receive consistent confirmation from the other 2f nodes during the commit phase, then node n4 can confirm that consensus has not been reached, thus determining that a preset fork condition has occurred in the consensus process.

[0066] In another implementation, the preset fork condition is that the root hash value of the state data of any other node is inconsistent with the root hash value of the state data calculated by the node itself. For example, if node n4 determines during the consensus process with other nodes that the root hash value of the state data of any other node is inconsistent with the root hash value of the state data calculated by the node itself, then a preset fork condition can be determined to have occurred in the consensus.

[0067] Node n1 can determine whether a pre-defined fork occurs in the consensus process in a similar way to node n4, which will not be elaborated here.

[0068] In S505, all nodes in the blockchain stop processing block B2.

[0069] Taking node n4 as an example, after node n4 determines that a preset fork has occurred during consensus, it indicates that there is a problem with the state data software of version B. Therefore, node n4 stops processing block B2. Specifically, node n4 will not store the block header generated based on the state data of version B of block B2, and can initiate the state data version switching scheme in the embodiments of this specification.

[0070] In one implementation, after node n4 determines that a preset fork has occurred in the consensus process, it can suspend the operation of the blockchain platform software and wait to restart the platform software after the blockchain is reconfigured.

[0071] After processing of block B2 is suspended in the blockchain, it can be done through... Figure 6 The method shown switches the state data software in the blockchain to a more stable version of the software.

[0072] Figure 6 This is a flowchart illustrating a method for switching state data software versions in a blockchain, as described in the embodiments of this specification. It can be understood that, although... Figure 6 Only nodes n4 and n1 are shown. Figure 4 Nodes n2 and n3 can be operated similarly to node n1 to switch the state data software version.

[0073] refer to Figure 6 In S601, node n4 sends the state data of version A of the existing blocks in the blockchain to other nodes, including node n1.

[0074] For example, if the latest block stored in the block database in node n4 has a block number of B1, then the existing blocks include all blocks from the genesis block of the blockchain to block B1.

[0075] For reference Figure 5 As shown in the method, after each node in the blockchain determines that a preset fork has occurred during the consensus process on the state data of block B2, the storage of the state data of block B2 is stopped. Therefore, node n4 can determine from the state database that the latest block is the block before block B2, and its block number is, for example, B1.

[0076] refer to Figure 4Node n4 stores the state data of version B and version A of each block from the genesis block to block B1. In one implementation, node n4 can send the state data of version A of each block from the genesis block to block B1 to other nodes. Taking node n1 as an example, after receiving the state data of version A of each block, node n1 stores the state data of version A of each block for subsequent software version switching. The state data of version A of each block includes the state values ​​of some accounts and state variables written in this block. The state values ​​of accounts and state variables in the state data of version A of each block that are not written in this block can reference the state values ​​of various accounts and state variables in previous blocks of this block.

[0077] In another implementation, node n4 can send the version B status data and version A status data of each block from the genesis block to block B1 to other nodes. Taking node n1 as an example, after receiving the version A status data and version B status data of each block, node n1 stores the version A status data and version B status data of each block for subsequent software version switching.

[0078] In S603, node n4 sends software configuration information to other nodes, including node n1.

[0079] Node n4 can generate software configuration information to send to other nodes, which is used to instruct other nodes to configure the state data software.

[0080] Specifically, the software configuration information includes the version of the status data software to be enabled. For example, the software configuration information may set the version to be enabled to "Version A" to instruct other nodes to switch their status data software to version A. Alternatively, the software configuration information may set the versions to be enabled to "Version A" and "Version B" to instruct other nodes to switch their status data software to versions A and B, respectively. Each node has pre-stored version A and version B status data software, and can switch to the corresponding version based on the software configuration information.

[0081] The software configuration information also includes the block number for software version switching (e.g., "B2"). Additionally, the software configuration information includes the version of the state data used for consensus. For example, the software configuration information might set the version of the state data used for consensus to "Version A".

[0082] In S605, node n4 can update its own status data software configuration in accordance with the software configuration information.

[0083] For example, if the software configuration information specifies the versions of the state data software to be enabled as "Version A" and "Version B", then node n4 does not need to update this configuration of the state data software. Corresponding to the software configuration information, node n4 sets the block number (e.g., "B2") used for software version switching and updates the version of the state data participating in consensus from "Version B" to "Version A".

[0084] In S607, node n1 updates the status data software configuration based on the software configuration information.

[0085] for Figure 4 The nodes n1-n3 are described below, with node n1 as an example. After receiving software configuration information from node n4, node n1 configures the state data software according to the software configuration information. Specifically, node n1 sets the version of the state data software to be enabled, the block number for software version switching, and the version of the state data participating in consensus, etc., according to the software configuration information.

[0086] After each node in the blockchain updates the configuration of its state data software, that is, after switching the state data software in the blockchain, each node can resume processing the state data of block B2. The following description uses node n1 as an example.

[0087] In S609, node n1 generates state data for version A of block B2.

[0088] After configuring the state data software according to the above software configuration information, node n1 can restart the process of generating state data for block B2. Node n1 reads the current state data software configuration, enables the locally stored version A state data software according to the configuration, and uses version A state data software to generate version A state data for block B2 based on the execution results of multiple transactions in block B2 and the locally stored version A state data of block B1.

[0089] When the state data software versions to be enabled in the state data software configuration are "Version A" and "Version B", since node n1 has already generated state data for version B of block B2, it is not necessary to generate state data for version B again for block B2. When node n1 generates state data for the next block after block B2 (e.g., block B3), it can use the state data software of version A to generate the state data of version A for block B3, and simultaneously use the state data software of version B to generate the state data of version B for block B3, according to the state data software configuration. By storing state data of version A and version B simultaneously on each node in the blockchain, it is helpful to use the newer state data software of version B to generate the state data of version B in the future.

[0090] In S611, each node in the blockchain generates the block header of block B2 based on the state data of version A of block B2.

[0091] Taking node n4 as an example, node n4 can include in the block header of block B2 the root hash value of the state data of version A of the generated block B2, the root hash values ​​of the transaction data of multiple transactions in block B2, and the root hash values ​​of the receipt data of multiple transactions in block B2, and... Figure 2 The other field values ​​of the block header included in the block header are used to generate the block header of block B2.

[0092] In S613, the nodes in the blockchain reach consensus on the block header of block B2.

[0093] Each node in the blockchain can calculate the hash value of the block header of block B2, and then each node can... Figure 3 The consensus method shown achieves consensus on the hash value of the block header of block B2. Since version A is a stable version, there will be no pre-set forks, and with all nodes being trusted, consensus on the block header of block B2 can be reached in the blockchain.

[0094] In S615, each node stores the block header of block B2 after reaching a consensus on the block header of block B2.

[0095] After all nodes in the blockchain reach a consensus on the block header of block B2, each node can store the block header of the generated block B2. As mentioned above, the root hash value of the state in the block header of block B2 is the root hash value of the state data of version A.

[0096] In addition, each node in the blockchain stores the state data of version A of the generated block B2 in its state database. Specifically, if the state data pattern in the software configuration information is version A + version B, then each node in the blockchain stores the state data of version A and version B of block B2 in its state database, respectively.

[0097] Figure 7 This is a schematic diagram illustrating the state data stored in the blockchain node in the embodiments of this specification. For example... Figure 7 As shown, each node in the blockchain stores state data for version A and state data for version B, respectively, to facilitate the switching of the blockchain's state data software between version A and version B. Figure 7In this context, due to a bug in the current software for version B's state data, the state data for version B in different nodes may be different. When the blockchain switches from version A to the updated version B again, the state data for version B can be selected from multiple nodes for subsequent calculations of the state data for version B of the new block.

[0098] exist Figure 5 In the method shown, when the operation of the blockchain platform software is suspended due to a consensus fork, the operation of the blockchain platform software is resumed after each node updates the configuration of the state data software. The blockchain nodes can provide the blockchain platform software with the transactions received during the suspension period so that the blockchain platform software can execute these transactions.

[0099] Figure 8 This is an architecture diagram of a first node in a blockchain according to an embodiment of this specification. The first node includes first state data and second state data of M blocks. The first state data is generated using a first version of state data software, and the second state data is generated using a second version of state data software. The blockchain also includes multiple second nodes, each including the second state data of the M blocks. The first node is used to execute... Figure 5 or Figure 6 The method shown includes:

[0100] The first sending unit 81 is used to send the first status data of the M blocks to each of the second nodes;

[0101] The second sending unit 82 is used to send software configuration information to each of the second nodes, wherein the software configuration information includes the version identifier of the first version of the status data software to be enabled.

[0102] Figure 9 This is an architecture diagram of a second node in a blockchain according to an embodiment of this specification. The blockchain includes a first node and multiple second nodes. The first node includes first state data and second state data of M blocks. The first state data is generated using a first version of state data software, and the second state data is generated using a second version of state data software. Each second node includes the second state data of the M blocks. The second nodes are used to execute... Figure 5 or Figure 6 The method shown includes:

[0103] The receiving unit 91 is configured to receive first status data of the M blocks from the first node; and to receive software configuration information from the first node, wherein the software configuration information includes a version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

[0104] The update unit 92 is used to update the configuration of the status data software according to the version identifier of the first version.

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

[0106] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 5 or Figure 6 The method shown.

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

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

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

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

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

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

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

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

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

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

[0117] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic 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.

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

[0119] 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 a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

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

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

Claims

1. A method for switching state data software versions in a blockchain, the blockchain including a first node and multiple second nodes, the first node including first state data and second state data of M blocks, the first state data being generated by a first version of state data software, the second state data being generated by a second version of state data software, for any block, the first state data generated based on the first version of state data software is different from the second state data generated based on the second version of state data software, each second node including the second state data of the M blocks, the method being executed by the first node, including: When a pre-defined fork occurs in the consensus on the second state data of any block, the first state data of the M blocks are sent to each of the second nodes; The preset fork condition indicates that the second state data root hash values ​​of any two nodes in the blockchain are inconsistent. Software configuration information is sent to each of the second nodes. The software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

2. The method according to claim 1, wherein the software configuration information further includes a version identifier of the second version, serving as a version identifier for the state data software to be maintained in use.

3. According to the method of claim 1 or 2, the software configuration information also includes the version identifier of the first version as the version identifier of the status data to be reached for consensus.

4. The method according to claim 3, wherein the software configuration information further includes an identifier of a first block, which serves as the block identifier of the block where the state data software version switching begins, and the first block is the block following the M blocks.

5. The method according to claim 4, wherein the first block is the block following the latest block among the M blocks, and the method further comprises: Execute the first block; Generate first state data and second state data for the first block based on the execution result of the first block; Achieve consensus with other nodes in the blockchain on the second state data of the first block; When it is determined during the consensus process that the second state data of the first block generated by each node in the blockchain has a preset fork, the processing of the first block is suspended. Sending the first state data of the M blocks to each of the second nodes includes: After suspending processing of the first block, the first state data of the M blocks are sent to each of the second nodes.

6. The method according to claim 5, further comprising: After suspending the processing of the first block, the configuration of the state data software is updated, including a version identifier of the first version, which serves as the version identifier of the state data to be reached for consensus. Based on the configuration of the updated state data software, the block header of the first block is generated based on the first state data of the first block; After determining that each of the second nodes has completed the update of the configuration of the state data software according to the software configuration information, consensus is reached with other nodes on the block header of the first block. If a consensus is reached on the block header of the first block, the block header of the first block is stored.

7. The method of claim 6, the aborting of processing of the first block comprising: Stop the operation of the platform software for the blockchain. The method further includes: after determining that each of the second nodes has completed the update of the configuration of the state data software according to the software configuration information, restarting the operation of the platform software, and providing the transactions received during the period when the platform software stopped running to the platform software as transactions to be executed.

8. The method of claim 1, wherein, The second state data of the M blocks are consensus-agreed. The first state data of the M blocks includes multiple state values ​​of multiple storage objects, and the second state data of the M blocks includes the multiple state values ​​of the multiple storage objects.

9. A method for switching state data software versions in a blockchain, the blockchain including a first node and multiple second nodes, the first node including first state data and second state data of M blocks, the first state data being generated by a first version of state data software, the second state data being generated by a second version of state data software, for any block, the first state data generated based on the first version of state data software is different from the second state data generated based on the second version of state data software, each second node including the second state data of the M blocks, the method being executed by the second nodes, including: When a pre-defined fork occurs in the consensus on the second state data of any block, the first state data of the M blocks is received from the first node; The preset fork condition indicates that the second state data root hash values ​​of any two nodes in the blockchain are inconsistent. Receive software configuration information from the first node, wherein the software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled; The configuration of the status data software is updated based on the version identifier of the first version.

10. The method according to claim 9, wherein the software configuration information further includes an identifier of a first block, serving as the block identifier of the block where the state data software version switching begins, the first block being the block following the M blocks, and the step of updating the state data software configuration according to the version identifier of the first version includes updating the state data software configuration according to the version identifier and the identifier of the first block. The method further comprises: Based on the configuration of the updated state data software, the first state data of the first block is generated using the first version of the state data software.

11. The method according to claim 10, wherein the first block is the next block after the latest block among the M blocks, the method further comprising: Execute the first block; Generate the second state data of the first block based on the execution result of the first block; Achieve consensus with other nodes in the blockchain on the second state data of the first block; When it is determined during the consensus process that the second state data of the first block generated by each node in the blockchain has a preset fork, the processing of the first block is suspended.

12. The method of claim 10, further comprising: Generate the block header of the first block based on the first state data of the first block; After confirming that all other nodes have completed updating the configuration of the state data software, consensus is reached with other nodes on the block header of the first block. If a consensus is reached on the block header of the first block, the block header of the first block is stored.

13. A first node in a blockchain, the first node including first state data and second state data of M blocks, the first state data being generated by a first version of state data software, the second state data being generated by a second version of state data software, wherein for any block, the first state data generated based on the first version of state data software is different from the second state data generated based on the second version of state data software, the blockchain further including multiple second nodes, each second node including the second state data of the M blocks, the first node including: The first sending unit is used to send the first state data of the M blocks to each of the second nodes when a preset fork occurs in the consensus on the second state data of any block; the preset fork indicates that the root hash values ​​of the second state data of any two nodes included in the blockchain are inconsistent. The second sending unit is used to send software configuration information to each of the second nodes. The software configuration information includes the version identifier of the first version, which serves as the version identifier of the status data software to be enabled.

14. A second node in a blockchain, the blockchain comprising a first node and a plurality of second nodes, the first node comprising first state data and second state data of M blocks, the first state data being generated using a first version of state data software, the second state data being generated using a second version of state data software, wherein for any block, the first state data generated based on the first version of state data software differs from the second state data generated based on the second version of state data software, each second node comprising the second state data of the M blocks, the second node comprising: A receiving unit is configured to receive the first state data of the M blocks from the first node when a preset fork occurs in the consensus on the second state data of any block; receive software configuration information from the first node, wherein the software configuration information includes the version identifier of the first version as the version identifier of the state data software to be enabled; the preset fork indicates that the root hash values ​​of the second state data of any two nodes included in the blockchain are inconsistent. The update unit is used to update the configuration of the status data software according to the version identifier of the first version.

15. A blockchain system comprising a first node and multiple second nodes, wherein the first node includes first state data and second state data of M blocks, the first state data being generated using a first version of state data software, and the second state data being generated using a second version of state data software, wherein for any block, the first state data generated based on the first version of the state data software differs from the second state data generated based on the second version of the state data software, and each second node includes the second state data of the M blocks. The first node is used to send the first state data of the M blocks to each of the second nodes when a preset fork occurs in the consensus on the second state data of any block; and to send software configuration information to each of the second nodes, wherein the software configuration information includes the version identifier of the first version as the version identifier of the state data software to be enabled; the preset fork indicates that the root hash values ​​of the second state data of any two nodes included in the blockchain are inconsistent. The second node is used to update the configuration of the status data software according to the version identifier of the first version.

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

Images