A blockchain version verification method and device

Abstract

A blockchain version verification method and apparatus are disclosed. The method includes: setting a target node, wherein the target node has a target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions; instructing the target node to execute multiple target transactions; receiving a first execution result of the multiple target transactions from the target node; obtaining a second execution result of the multiple target transactions from the blockchain; and determining whether the target version is available based on the first execution result and the second execution result.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a blockchain version verification method and apparatus. 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 blockchain version verification method and apparatus to verify the availability of a target version using real, executed transactions in the blockchain, thereby ensuring that the verified available target version is indeed available.

[0004] According to the first aspect, a blockchain version verification method is provided, including:

[0005] Set a target node, wherein the target node has the target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions;

[0006] Instruct the target node to execute the multiple target transactions;

[0007] Receive the first execution result of the plurality of target transactions from the target node;

[0008] Obtain a second execution result for the plurality of target transactions from the blockchain;

[0009] Based on the first execution result and the second execution result, determine whether the target version is available.

[0010] According to the second aspect, a blockchain version verification device is provided, comprising:

[0011] The configuration module is configured to set a target node, which has the target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions;

[0012] The instruction module is configured to instruct the target node to execute the multiple target transactions;

[0013] The first receiving module is configured to receive the first execution result of the plurality of target transactions from the target node;

[0014] The acquisition module is configured to acquire a second execution result for the plurality of target transactions from the blockchain;

[0015] The determination module is configured to determine whether the target version is available based on the first execution result and the second execution result.

[0016] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in any implementation of the first aspect.

[0017] According to a fourth aspect, a computing device is provided, including 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 described in any implementation of the first aspect.

[0018] According to the blockchain version verification method and apparatus provided in the embodiments of this specification, for a blockchain, a target node is set up with the target version of the blockchain (i.e., the upgraded version of the blockchain) installed, and its current state is the state of the blockchain before executing multiple target transactions. Then, the target node is instructed to execute the multiple target transactions, that is, to replay the multiple target transactions already executed by the blockchain, and obtain the corresponding first execution result. Subsequently, based on the first execution result and the second execution result of the multiple target transactions obtained from the blockchain, it is determined whether the target version is usable. This verifies the usability of the target version through actually executed transactions in the blockchain, ensuring that the verified usable target version is truly usable. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a blockchain architecture according to an embodiment of this specification;

[0021] Figure 2 This is a schematic diagram of an implementation framework of one embodiment of this specification;

[0022] Figure 3 This is a flowchart of a blockchain version verification method in one embodiment of this specification;

[0023] Figure 4 This is a schematic diagram of a blockchain version verification scenario in one embodiment of this specification;

[0024] Figure 5 This is a schematic diagram of the structure of a blockchain version verification device in one embodiment of this specification. Detailed Implementation

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

[0026] To further illustrate blockchain technology, Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100, for example, contains 6 nodes. The connections between nodes schematically represent P2P (Peer-to-Peer) connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can produce the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database. It can be understood that... Figure 1 Although the example shows a blockchain with 6 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0027] 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. In the case of a transaction calling a smart contract on the blockchain, the From field represents the account address initiating the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the parameters passed to that function, which is used to retrieve and execute the function's code from the blockchain during transaction execution.

[0028] Currently, when verifying blockchain node software after version upgrades (i.e., node software version upgrade verification), the verification test cases used are generally transaction data constructed for common business scenarios. This type of transaction data differs from the real transaction data generated in actual business scenarios, which may lead to a situation where the blockchain node software passes the upgrade verification, but the real transaction data in the blockchain is unavailable (i.e. cannot be executed normally).

[0029] In view of the above, the inventors propose a blockchain version verification method. Figure 1 A schematic diagram illustrating an implementation framework according to an embodiment disclosed in this specification is shown. Figure 2 As shown, this method can be executed by server 200. Specifically, a user can trigger an instruction (referred to as a setting instruction) to set a target node for blockchain 100 through the client corresponding to server 200. Blockchain 100 is a blockchain within the scope of server management. In response to the setting instruction, server 200 sets a target node 300 for blockchain 100. The target node 300 has the target version of blockchain 100 installed. This target version is the upgraded version selected by the user for blockchain 100, which needs to be verified for usability. The current state of the target node 300 is the state of blockchain 100 before executing multiple target transactions.

[0030] Server 200 instructs target node 300 to execute the multiple target transactions, that is, instructs target node 300 to replay the multiple target transactions already executed by blockchain 100, and receives the first execution result of the execution of the multiple target transactions from target node 300. The first execution result may include: the first block height and / or the first state of the block after target node 300 has executed the multiple target transactions. A second execution result is obtained from the blockchain for the multiple target transactions. This second execution result is a consensus result and may include: the second block height and / or the second state of blockchain 100 (i.e., the block height and / or state after blockchain 100 has completed the execution of the multiple target transactions).

[0031] Next, server 200 determines whether the target version is available based on the first and second execution results. Specifically, it determines whether the first block height is equal to the second block height, and / or whether the first state and the second state are consistent. If the first block height is equal to the second block height, and / or the first state and the second state are consistent, it means that the target node 300 with the target version of blockchain 100 has successfully executed all target transactions (transactions executed by blockchain 100 and agreed upon), and correspondingly, the target version is available. If the first block height is not equal to the second block height, that is, the first state and the second state are inconsistent, it means that the target node 300 with the target version of blockchain 100 cannot completely execute all target transactions successfully, that is, some target transactions cannot be executed successfully, and the target version is unavailable.

[0032] Subsequently, server 200 can feed back the result of determining whether the target version is available to the client, so that the user knows whether the target version is available.

[0033] In the above process, the availability of the target version can be verified through actual executed transactions (i.e., target transactions) in the blockchain, ensuring that the target version that is verified to be available is indeed available.

[0034] The blockchain version verification method provided in this specification will be described in detail below with reference to specific embodiments.

[0035] Figure 3 A flowchart of a blockchain version verification method according to one embodiment of this specification is shown. This method can be implemented by a server, which can be any device, equipment, platform, device cluster, etc., with computing and processing capabilities. The method includes the following steps S310-S350:

[0036] First, in step S310, server 200 sets up target node 300, that is, it sets up target node 300 for blockchain 100. Target node 300 has the target version of blockchain 100 installed; that is, the software version of blockchain 100 installed on target node 300 is the target version. The current state of target node 300 is the state of blockchain 100 before executing multiple target transactions. It can be understood that this target version is an upgraded version of blockchain 100 that needs to be verified for usability, and this target version can be any version of blockchain 100.

[0037] The multiple target transactions may include executed transactions in blockchain 100, as well as transactions that blockchain 100 will execute. These multiple target transactions may be multiple transactions stored in the same block (belonging to blockchain 100), or multiple transactions stored in multiple blocks.

[0038] The server 200 can correspond to several clients, providing various services to users through these clients, such as the blockchain version verification service provided in this specification. In one implementation, the server can be a BaaS (Blockchain as a Service) platform, meaning the functional module implementing the blockchain version verification can be embedded within this BaaS platform. This BaaS platform is an open blockchain platform that can provide many blockchain-related services. It embeds the blockchain framework into a cloud computing platform, leveraging the deployment and management advantages of cloud service infrastructure to provide developers with a convenient and high-performance blockchain ecosystem and supporting services, supporting developers' business expansion and operational support.

[0039] In another implementation, the server 200 can be a separately configured server providing blockchain version verification services. This server can be associated with a BaaS platform, and correspondingly, the server can invoke the BaaS platform to provide users with blockchain-related services. The following explanation uses the example of a server being a BaaS platform. In the case where the server is a separately configured server providing blockchain version verification services (hereinafter referred to as the verification service), the process of providing the blockchain version verification service can be found in the service process where the server is a BaaS platform.

[0040] Understandably, server 200 can manage multiple blockchains, with different blockchains corresponding to different business operations. The aforementioned blockchain 100 can be any blockchain within the server's management scope.

[0041] In one implementation, when a user needs to verify a specific version of the blockchain software, they can send a configuration command to the server via a client to configure the target node 300 for the blockchain 100. Correspondingly, the server 200 responds to the configuration command, such as... Figure 4 As shown, in step S41, target node 300 is set for blockchain 100.

[0042] In one embodiment, for security reasons related to blockchain 100, server 200 may create a new node as target node 300 for blockchain 100, which is different from the running consensus node of blockchain 100. Accordingly, in one embodiment, in step S310, specifically configured to create target node 300 for blockchain 100 based on the chain identifier of blockchain 100 and the version number of the target version carried by the first instruction.

[0043] Specifically, when server 200 sets target node 300 for blockchain 100, there are already executed transactions in blockchain 100. That is, when server 200 sets target node 300 for blockchain 100, the block height of blockchain 100 is not zero. For example, when server 200 sets target node 300 for blockchain 100, blockchain 100 already includes block 0 (i.e., the genesis block) and blocks B1-B100. At this time, the block height of blockchain 100 is 101.

[0044] Subsequently, in one scenario, while the target node 300 is executing a transaction, blockchain 100 can continue to generate new blocks. That is, other consensus nodes of blockchain 100 continue to execute new transactions while the target node 300 is executing a transaction. For example, while the target node 300 is executing a transaction, blockchain 100 generates at least one new block B101. Accordingly, in this implementation, the target node 300 is a new node created by server 200 for blockchain 100. The multiple target transactions can include executed transactions in blockchain 100 (i.e., transactions stored in blocks B1-B100) when server 200 sets the target node 300 for blockchain 100, and also include new transactions executed by other consensus nodes of blockchain 100 while the target node 300 is executing a transaction (e.g., at least transactions stored in block B101), i.e., the transactions to be executed as described above.

[0045] In another scenario, during the execution of a transaction by the target node 300, the blockchain 100 does not continue to generate new blocks. Accordingly, in this implementation, the target node 300 is a new node created by the server 200 for the blockchain 100. The multiple target transactions may include the executed transactions in the blockchain 100 when the server 200 sets the target node 300 for the blockchain 100 (i.e., transactions stored in blocks B1-B100).

[0046] In one implementation, when a user needs to verify a block version, they can first send a request to the server 200 via a client to retrieve the blockchain and its corresponding available versions. In response to this request, the server 200 sends back to the client the identifiers of the blockchains within its management scope and the version numbers of their respective available versions, or the identifiers of the blockchains the user has access to and the version numbers of their corresponding available versions. Then, based on the server's feedback, the user selects the target version of the blockchain 100 they need to verify via the client and triggers a first instruction carrying the chain identifier 'a' of blockchain 100 and the version number of the target version. The client sends this first instruction to the server 200. The server 200 receives the first instruction and, based on the chain identifier 'a' of blockchain 100 and the version number of the target version carried in the first instruction, creates a target node 300 for blockchain 100 and executes the subsequent blockchain version verification process.

[0047] In one scenario, server 200 can service its various functional modules. Server 200 can obtain the aforementioned acquisition instruction through its verification service (or replay service). Then, the verification service sends the acquisition instruction to server 200's BaaS service to obtain the identifier of the blockchain within the scope of server 200's management and the version number of each available version, or to obtain the identifier of the blockchain for which the user has operation permissions and the version number of each available version. This information is then fed back to the client for the user to select.

[0048] Subsequently, the user selects the target version of Blockchain 100 to be verified through the client and triggers the first instruction. The verification service then receives the first instruction from the client and forwards it to the BaaS service. The BaaS service then forwards the first instruction to the node service to create a target node 300 for Blockchain 100. After receiving information that the target node 300 has been successfully created, the verification service continues to execute the subsequent blockchain version verification process.

[0049] Understandably, in this embodiment, creating a new node, namely the target node 300, for blockchain 100 allows for the verification of the availability of the target version (i.e., the updated version) of blockchain 100 without affecting the normal operation of the consensus nodes of blockchain 100. After the target version is verified to be available, each consensus node of blockchain 100 can safely install the target version of blockchain 100. That is, the above embodiment can verify the availability of the target version (i.e., the updated version) of blockchain 100 while simultaneously protecting the consensus nodes of blockchain 100.

[0050] In one implementation, considering the security of blockchain 100, the target node 300 can be a non-consensus node. The target node 300 can obtain consensus-based transactions from blockchain 100, but it cannot write transactions to blockchain 100. In other words, the target node 300 has readable attributes corresponding to blockchain 100, which can guarantee the security of blockchain 100 to a certain extent.

[0051] In another embodiment, the target node 300 can be a consensus node of the blockchain 100 that has a target version of the blockchain installed. Accordingly, in step S310, it can be specifically configured to instruct the first consensus node of the blockchain 100 to stop running and roll back to the state before executing multiple target transactions, so as to obtain the target node 300. Here, the first consensus node is one of the consensus nodes of the blockchain 100.

[0052] In this implementation, when a user needs to upgrade blockchain 100, they can first send an upgrade command to server 200 through their client. This upgrade command carries the chain identifier of blockchain 100 to be upgraded and the version number of the target version. Correspondingly, server 200 can send an upgrade command to the first consensus node through its upgrade service. Based on the chain identifier of blockchain 100 and the version number of the target version, the first consensus node upgrades the software corresponding to blockchain 100 to the software corresponding to the target version of blockchain 100. Subsequently, the first consensus node reports the upgrade result back to server 200.

[0053] Afterwards, server 200 notifies the client of the upgrade result of the first consensus node. Based on the upgrade result, the user determines that the software corresponding to blockchain 100 in the first consensus node has been upgraded to the software corresponding to the target version, and can then instruct whether to verify the availability of the target version. If it is necessary to verify the availability of the target version, the user sends a second instruction (also known as a replay instruction) to server 200 through the client, instructing the first consensus node of blockchain 100 to roll back to the state before the execution of multiple target transactions.

[0054] In response to the second instruction, server 200 instructs the first consensus node of blockchain 100 to stop operating. Accordingly, after the first consensus node stops operating, it sends a feedback to server 200 regarding the stop operation result. Then, after confirming that the first consensus node has stopped operating, server 200 instructs the first consensus node to roll back to the state before executing the multiple target transactions.

[0055] Specifically, the process of instructing the first consensus node to roll back to the state before executing multiple target transactions can be that the server 200 sends a block deletion instruction to the first consensus node. The block deletion instruction carries the starting position of the block used to instruct the first consensus node to delete the corresponding block. The starting position of the block can be set by the user according to their needs.

[0056] Continuing with the above example, when server 200 sets target node 300 for blockchain 100, blockchain 100 includes block 0 and blocks B1-B100. Correspondingly, in one scenario, the chain corresponding to blockchain 100 stored by the first consensus node may also include block 0 and blocks B1-B100. In this case, the starting position of the block carried by the aforementioned block deletion instruction can be any block position from B1 to B98. In another scenario, the chain corresponding to blockchain 100 stored by the first consensus node includes block 0 and blocks B1-B98. In this case, the starting position of the aforementioned block can be any block position from B1 to B98.

[0057] Subsequently, the first consensus node responds to the block deletion command by deleting all blocks from the starting position of the block and subsequent blocks in the chain corresponding to blockchain 100 stored by it. Taking a chain corresponding to blockchain 100 stored by the first consensus node that includes block 0 and blocks B1-B100 as an example, if the starting position of the block is block B50, then blocks B50-B100 (and the transactions stored therein) in the chain corresponding to blockchain 100 stored by the first consensus node are deleted. Accordingly, the multiple target transactions include at least the transactions in blocks B50-B100 deleted by the first consensus node. For another example, if the starting position of the block is block B100, then block B100 (and the transactions stored therein) in the chain corresponding to blockchain 100 stored by it are deleted. Accordingly, the multiple target transactions include at least the transactions in block B100 deleted by the first consensus node. At this point, the first consensus node rolls back to the state before executing the multiple target transactions, thus obtaining target node 300.

[0058] If a new block is generated by blockchain 100 during the execution of a transaction by target node 300, assuming block B101 is generated as described above, then the multiple target transactions also include block B101.

[0059] In one implementation, server 200 can receive the second instruction through its verification service (also known as replay service). The verification service sends the second instruction to the server's node service to instruct the first consensus node of blockchain 100 to stop running. After determining that the first consensus node has stopped running, the verification service sends a block deletion instruction to the server's block deletion service to delete the starting position of the block and subsequent blocks in the chain corresponding to blockchain 100 in the first consensus node (and also delete the transactions stored in the corresponding blocks), thereby rolling back the first consensus node to the state before executing multiple target transactions.

[0060] In one embodiment, after the first consensus node of blockchain 100 stops running, and before the first consensus node rolls back to the state before executing multiple target transactions, server 200 receives and backs up the data from the first consensus node before the rollback. Backing up the data before the rollback of the first consensus node prevents data loss in the event of a rollback anomaly or the subsequent verification of the target version becoming unavailable (i.e., subsequent execution of the target transactions fails). The data before the rollback of the first consensus node may include all transactions corresponding to blockchain 100 stored by the first consensus node before the rollback, such as all transactions stored in block 0 and blocks B1-B100 of the chain corresponding to blockchain 100.

[0061] In another embodiment, while backing up the data of the first consensus node before rollback, server 200 can also back up the height of the (consensus-reached) blocks stored by the first consensus node before rollback. Continuing the example above, the chain corresponding to blockchain 100 stored by the first consensus node includes block 0 (i.e., the genesis block) and blocks B1-B100. Accordingly, the block height of the chain stored by the first consensus node before rollback is 101. Backing up the data and block height before rollback prevents data loss in the event of a rollback anomaly or the subsequent verification of the target version becoming unavailable (i.e., subsequent execution of the target transaction fails).

[0062] The above describes the method by which server 200 sets up target nodes. After server 200 sets up target node 300 for blockchain 100 based on the above method, in step S320, target node 300 is instructed to execute multiple target transactions.

[0063] In one implementation, such as Figure 4 As shown, in step S42, server 200 can send an instruction to target node 300 to instruct target node 300 to obtain multiple consensus-agreed target transactions from blockchain 100 and execute the multiple target transactions. In one implementation, if target node 300 is a new node created by server 200 for blockchain 100, the instruction to target node 300 to obtain multiple consensus-agreed target transactions from blockchain 100 can be to instruct the target node to obtain multiple target transactions from other consensus nodes in blockchain 100. In another implementation, if target node is one of the consensus nodes in blockchain 100 (i.e., the first consensus node), the instruction to target node 300 to obtain multiple consensus-agreed target transactions from blockchain 100 can be to obtain multiple target transactions from the location of backup data of the first consensus node, or from other consensus nodes in blockchain 100.

[0064] like Figure 4 As shown, after the target node 300 obtains the target transaction from the blockchain 100 in step S43, it executes the obtained target transaction in step S44.

[0065] In one implementation, when target node 300 is one of the consensus nodes of blockchain 100, the process by which the server instructs target node 300 to execute multiple target transactions can be to instruct target node 300 to start and execute multiple target transactions. In another implementation, when target node 300 is a new node created by server 200 for blockchain 100, after successful creation, target node 300 can be assumed to be in an active state. Correspondingly, the process by which server 200 instructs target node 300 to execute multiple target transactions can be to directly instruct target node 300 to execute multiple target transactions.

[0066] Subsequently, in step S330, the server receives the first execution results of multiple target transactions from the target node 300. This step corresponds to... Figure 4 Step S45. And, in step S340, a second execution result for multiple target transactions is obtained from blockchain 100. The second execution result is the consensus result. In one case, such as... Figure 4 As shown, step S340 can be specifically set as follows: S46 obtains the second execution result of multiple target transactions from other consensus nodes of blockchain 100.

[0067] Next, in step S350, the server determines whether the target version is available based on the first execution result and the second execution result. This step corresponds to... Figure 4 Step S47 in the process.

[0068] In one implementation, when server 200 sets up target node 300, blockchain 100 includes at least block A1 (the latest block when the target node is set up). The current state of target node 300 is the state before executing block A1. Assuming that no new blocks are generated in the blockchain, i.e., the multiple target transactions include multiple transactions in block A1 that have been executed in blockchain 100, in steps S330-S350, server 200 can specifically receive the first execution result of executing multiple transactions in block A1 (multiple target transactions) from target node 300, and obtain the second execution result of executing multiple transactions in block A1 from other consensus nodes of blockchain 100. The first execution result and the second execution result are compared, and the availability of the target version is determined based on the comparison result. Wherein, if the comparison result of the first execution result and the second execution result is the same, the target version is determined to be available; otherwise, if the comparison result of the first execution result and the second execution result is different, the target version is unavailable.

[0069] In another implementation, when the server sets up the target node, the blockchain 100 includes at least blocks A2 and A3 (block A2 is the block before block A3, and block A3 is the latest block when the server sets up the target node). The current state of the target node is the state before executing block A2. Assuming that the blockchain does not generate any new blocks, that is, when the multiple target transactions include multiple transactions in blocks A2 and A3 that have been executed in the blockchain 100, in steps S330-S350, specifically, during the execution of multiple target transactions by the target node 300, when a result acquisition period arrives, the server 200 can receive the execution result of block A2 (i.e., the execution result of multiple transactions in block A2) from the target node 300. Furthermore, the server 200 obtains the execution result of the consensus-agreed block A2 in the blockchain 100 from the blockchain 100. The server compares the execution result of block A2 executed by the target node 300 with the execution result of the consensus-agreed block A2 in the blockchain 100.

[0070] In one scenario, if server 200 determines that the comparison results are the same, when the next result retrieval period arrives, server 200 continues to receive the execution result of block A3 from target node 300, and obtains the execution result of consensus-agreed block A3 from blockchain 100. It then continues to compare the execution result of block A3 from target node 300 with the execution result of consensus-agreed block A3 from blockchain 100. If the comparison results are still the same, then the target version can be determined to be usable.

[0071] In another scenario, if the server determines that the execution result of block A2 by target node 300 is different from the execution result of consensus-based block A2 in blockchain 100, the server instructs target node 300 to stop executing the target transaction. Consequently, it can be determined that target node 300 cannot successfully execute some transactions in block A2, meaning that the target version of blockchain 100 installed by target node 300 is incompatible with some target transactions. Accordingly, it can be determined that the target version is unavailable.

[0072] In another implementation, when the server sets up the target node, blockchain 100 includes at least block A4 (block A4 is the latest block when the server sets up the target node), the current state of the target node is the state before executing block A4, and assuming that after the server sets up the target node, blockchain 100 generates a new block A5, that is, the multiple target transactions include the already executed block A4 in blockchain 100 and multiple transactions in block A5, then in steps S330-S350, specifically, after the server obtains the execution result of the target node 300 executing block A4, In addition to the execution result of blockchain 100 on block A4, and if it is determined that the two execution results are the same, the server also instructs the target node 300 to catch up with blockchain 100, that is, instructs the target node 300 to execute block 5, obtain the execution result of the target node 300 executing block 5, and obtain the execution result of block A5 from blockchain 100. Compare the execution result of the target node 300 executing block 5 with the execution result of block A5 obtained from blockchain 100. If the comparison result is the same, the target version is determined to be usable; otherwise, if the comparison result is different, the target version is determined to be unusable.

[0073] In one embodiment, the aforementioned first execution result may include: the first block height and / or first state of the block after the target node 300 executes multiple target transactions; and the second execution result includes: the second block height and / or second state of the blockchain 100. Accordingly, in step S350, it may be specifically set to determine whether the first block height is equal to the second block height, and / or to determine whether the first state and the second state are consistent.

[0074] If the server determines that the first block height is equal to the second block height, and / or determines that the first state is consistent with the second state, then it can determine that the target node 300 can successfully execute all target transactions. That is, the target node 300 catches up with blockchain 100, and the target version of blockchain 100 is compatible with all consensus-based transactions executed by blockchain 100. Accordingly, it can be determined that the target version is available.

[0075] Understandably, when the height of the first block equals the height of the second block, the corresponding first state and second state are consistent; conversely, when the height of the first block and the height of the second block are not equal, the corresponding first state and second state are inconsistent. Therefore, when server 200 determines that the height of the first block is not equal to the height of the second block, i.e., the first state and second state are inconsistent, it can be determined that target node 300 cannot successfully execute all target transactions. In other words, some target transactions cannot be successfully executed by target node 300, meaning the target version of blockchain 100 is incompatible with the consensus-driven portion of target transactions already executed by blockchain 100. Consequently, it can be determined that the target version is unusable.

[0076] Afterwards, server 200 can send the result of determining whether the target version is available to the corresponding client to notify the user whether the target version of blockchain 100 is available.

[0077] In one embodiment, when the target node 300 is a newly created node of the server 200 for the blockchain 100 (i.e., a non-consensus node of the blockchain 100), in order to ensure verification efficiency, a preset time period can be set in advance to limit the time consumed for version verification of the blockchain 100. Accordingly, in step S330, it can be specifically set to receive the first execution results of multiple target transactions within the preset time period from the target node 300.

[0078] In one implementation, the preset time period can be determined based on the block height of blockchain 100 and the transaction volume of executed transactions. Specifically, server 200 can pre-store multiple correspondences, including correspondences between the threshold of each time period and the block height threshold and transaction volume threshold of blockchain 100. Accordingly, server 200 can determine the aforementioned preset time period based on these correspondences and the block height and transaction volume of executed transactions of blockchain 100 when target node 300 is set on server 200.

[0079] In one scenario, if server 200 does not receive the first execution result of multiple target transactions from target node 300 within a preset time period, that is, target node 300 does not complete the consensus-based target transactions already executed by blockchain 100 within the preset time period, then server 200 can instruct target node 300 to stop executing transactions. Accordingly, server 200 will stop executing subsequent blockchain version verification processes, and thus can determine that the target version is unavailable.

[0080] In one implementation, when the target node 300 is one of the consensus nodes of blockchain 100, in order to better ensure the credibility of the determination that the target version is usable, after determining that the first block height is equal to the second block height and / or that the first state is consistent with the second state, the server 200 can continue to verify whether the target node 300 (i.e., the first consensus node) can participate in the consensus of blockchain 100. If the target node 300 can participate in the consensus of blockchain 100, then the target version is determined to be usable; if the target node 300 cannot participate in the consensus of blockchain 100, then the target version is determined to be unusable.

[0081] For example, if the server finds that the status of all consensus nodes in blockchain 100 is normal, and / or determines that the transactions of target node 300 are consistent with those of other consensus nodes in blockchain 100, then it can be determined that target node 300 can participate in the consensus for blockchain 100, and thus the target version can be determined to be available. The above example is only a way to verify whether a target node can participate in consensus; any other method that can verify whether a node in a blockchain can participate in consensus can also be applied to the embodiments of this specification.

[0082] In the above process, the availability of the target version can be verified through actually executed transactions (i.e., the target transaction) in the blockchain, ensuring that the verified available target version is indeed usable. Furthermore, the target version can be any version of the blockchain; correspondingly, the embodiments in this specification can verify the availability of any version of the blockchain, thus achieving verification of the availability of all versions of any blockchain.

[0083] Corresponding to the above method embodiments, this specification also provides a blockchain version verification device 500, the schematic block diagram of which is shown below. Figure 5 As shown, it includes:

[0084] The setting module 510 is configured to set a target node, wherein the target node has a target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions;

[0085] Instruction module 520 is configured to instruct the target node to execute the plurality of target transactions;

[0086] The first receiving module 530 is configured to receive the first execution result of the plurality of target transactions from the target node;

[0087] The acquisition module 540 is configured to acquire a second execution result of the plurality of target transactions from the blockchain;

[0088] The determination module 550 is configured to determine whether the target version is available based on the first execution result and the second execution result.

[0089] In one optional implementation, the first execution result includes: the first block height and / or first state of the block after the target node executes the plurality of target transactions; and the second execution result includes: the second block height and / or second state of the blockchain.

[0090] The determining module 550 is specifically configured to determine whether the height of the first block is equal to the height of the second block, and / or to determine whether the first state and the second state are consistent.

[0091] In one optional implementation, the instruction module 520 is specifically configured to instruct the target node to obtain the plurality of target transactions from other consensus nodes of the blockchain; and to instruct the target node to execute the plurality of target transactions.

[0092] In one optional implementation, the setting module 510 is specifically configured to create the target node for the blockchain based on the chain identifier of the blockchain carried by the first instruction and the version number of the target version.

[0093] In one alternative implementation, the target node is a non-consensus node.

[0094] In one optional implementation, the receiving module 530 is specifically configured to receive the first execution result of the plurality of target transactions within a preset time period from the target node.

[0095] In one alternative implementation, the preset time period is determined based on the block height of the blockchain and the transaction volume of executed transactions.

[0096] In one alternative implementation, the setting module 510 is specifically configured to instruct the first consensus node of the blockchain to stop running and roll back to the state before executing the plurality of target transactions, so as to obtain the target node.

[0097] In one alternative implementation, it further includes:

[0098] The second receiving module (not shown in the figure) is configured to receive data from the first consensus node before rollback and back up the data.

[0099] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform the blockchain version verification method.

[0100] According to another embodiment, a computing device is also provided, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the blockchain version verification method.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0115] 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 blockchain version verification method, comprising: Set a target node, wherein the target node has the target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions, the multiple target transactions including transactions already executed by the blockchain; wherein setting the target node includes: sending a block deletion instruction to the first consensus node of the blockchain to roll back the first consensus node to the state before executing multiple target transactions, so as to obtain the target node; Instruct the target node to execute the multiple target transactions; Receive the first execution result of the plurality of target transactions from the target node; Obtain a second execution result for the plurality of target transactions from the blockchain; Based on the first execution result and the second execution result, determine whether the target version is available.

2. The method as described in claim 1, wherein, The first execution result includes: the first block height and / or the first state of the block after the target node executes the plurality of target transactions; and the second execution result includes: the second block height and / or the second state of the blockchain. The determination that the target version is available includes: Determine whether the height of the first block is equal to the height of the second block, and / or determine whether the first state is consistent with the second state.

3. The method as described in claim 1, wherein, The instruction to the target node to execute the multiple target transactions includes: The target node is instructed to obtain the multiple target transactions from other consensus nodes of the blockchain; and the target node is instructed to execute the multiple target transactions.

4. The method according to any one of claims 1-3, wherein, Setting the target node includes: Based on the chain identifier of the blockchain and the version number of the target version carried by the first instruction, the target node is created for the blockchain.

5. The method of claim 4, wherein, The target node is a non-consensus node.

6. The method of claim 4, wherein, The first execution result of receiving the plurality of target transactions from the target node includes: Receive the first execution result of the multiple target transactions within a preset time period from the target node.

7. The method as described in claim 6, wherein the preset time period is determined based on the block height of the blockchain and the transaction volume of executed transactions.

8. The method as described in any one of claims 1-3, wherein, Setting the target node includes: The first consensus node of the blockchain is instructed to stop running and roll back to the state before the execution of the multiple target transactions to obtain the target node. In response to the block deletion instruction, the first consensus node deletes the blocks stored in the blockchain corresponding to the start position of the block and the blocks thereafter, so as to roll back to the state before the execution of the multiple target transactions. The block deletion instruction carries the start position of the block used to instruct the first consensus node to delete the corresponding block.

9. The method of claim 8, further comprising: Receive the data prior to rollback from the first consensus node and back up the data.

10. A blockchain version verification device, comprising: The setting module is configured to set a target node, wherein the target node has the target version of the blockchain installed, and the current state of the target node is the state of the blockchain before executing multiple target transactions, the multiple target transactions including transactions already executed by the blockchain; wherein, the setting module is specifically configured to send a block deletion instruction to the first consensus node of the blockchain to roll back the first consensus node to the state before executing multiple target transactions, so as to obtain the target node; The instruction module is configured to instruct the target node to execute the multiple target transactions; The first receiving module is configured to receive the first execution result of the plurality of target transactions from the target node; The acquisition module is configured to acquire a second execution result for the plurality of target transactions from the blockchain; The determination module is configured to determine whether the target version is available based on the first execution result and the second execution result.

11. 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.

12. 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