CN114816509A

CN114816509A - Block chain version compatibility verification method and device and electronic equipment

Info

Publication number: CN114816509A
Application number: CN202210473975.0A
Authority: CN
Inventors: 林鹏; 邓福喜
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2022-07-29

Abstract

The embodiment of the specification provides a block chain version compatibility verification method and device and electronic equipment. The method is applied to a target node device in the block chain; wherein the blockchain supports software version upgrading; the method comprises the following steps: acquiring a history block to be verified, and reading a transaction to be verified from the history block; executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; executing the transaction based on a second software version supported by the blockchain to obtain a second transaction execution result; and matching the first transaction execution result with the second transaction execution result, and determining whether the first software version and the second software version are compatible based on the matching result.

Description

Block chain version compatibility verification method and device and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for verifying compatibility of blockchain versions, and an electronic device.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

The embodiment of the specification provides a method and a device for improving information security and electronic equipment.

According to a first aspect of embodiments of the present specification, there is provided a method for verifying compatibility of a blockchain version, the method being applied to a target node device in the blockchain; wherein the blockchain supports software version upgrading; the method comprises the following steps:

acquiring a history block to be verified, and reading a transaction to be verified from the history block;

executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; executing the transaction based on a second software version supported by the blockchain to obtain a second transaction execution result;

and matching the first transaction execution result with the second transaction execution result, and determining whether the first software version and the second software version are compatible based on the matching result.

Optionally, executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and executing the transaction based on the second software version supported by the blockchain, and before obtaining a second transaction execution result, the method further comprises the following steps:

acquiring historical state data corresponding to the historical blocks from a historical state database corresponding to the block chain; wherein the historical state data corresponding to the historical chunk is set to a read-only state;

reading an initial account status corresponding to a blockchain account associated with the transaction from historical status data corresponding to the historical blocks.

Optionally, the transaction execution result includes a transaction receipt generated after the transaction is executed;

executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result;

executing the transaction based on a first software version supported by the blockchain, generating an updated account status corresponding to the primary account status, and generating a first transaction receipt for the transaction corresponding to the first software version based on the primary account status and the updated account status;

the executing the transaction based on the second software version supported by the blockchain to obtain a second transaction execution result includes:

the transaction is executed based on a second software version supported by the blockchain, an updated account status corresponding to the primary account status is generated, and a second transaction receipt corresponding to the second software version is generated based on the primary account status and the updated account status.

Optionally, the target node device is equipped with a service port for recording a transaction execution result;

before the matching the first transaction execution result with the second transaction execution result, further comprising:

invoking the service port, and locally storing the generated first transaction receipt and the second transaction receipt.

Optionally, the matching the first transaction execution result and the second transaction execution result, and determining whether the first software version and the second software version are compatible based on the matching result includes:

reading the first transaction receipt and the second transaction receipt of the service port record;

matching the first and second transaction receipts that are read;

determining that the first software version is compatible with the second software version if the first transaction receipt matches the second transaction receipt; otherwise, determining that the first software version is incompatible with the second software version.

Optionally, the obtaining the history block to be verified includes:

acquiring a block number interval corresponding to a historical block to be verified, which is specified by a user;

and reading the block number of the historical block to be verified from the block number interval, and reading the historical block corresponding to the block number from the block data of the locally maintained block chain.

Optionally, the locally maintained block data of the block chain is block data that is copied to the target node device in advance.

Optionally, the block chain supports performing a gray scale upgrade of a software version; the first software version comprises a latest software version; the second software version comprises historical software versions supported by part of node devices in the block chain before the software versions supported by the part of node devices are upgraded to the latest software version in a gray scale mode.

Optionally, before the obtaining the history block to be verified and reading the transaction to be verified from the history block, the method further includes:

and responding to the gray scale upgrade of the software version supported by part of the node devices in the block chain to the latest software version, acquiring a history block to be verified, and reading a transaction to be verified from the history block.

Optionally, the method further includes:

and if the latest software version is determined to be compatible with the historical software version, sending an upgrading instruction to a service platform corresponding to the blockchain so as to trigger the service platform to upgrade the software version supported by the part of the node equipment from the historical software version to the latest software version.

Optionally, the service platform includes a Bass platform.

Optionally, the target node device includes a non-consensus node preset in the block chain and not participating in consensus.

According to a second aspect of embodiments of the present specification, there is provided a block chain version compatibility verification apparatus, which is applied to a target node device in the block chain; wherein the blockchain supports software version upgrading; the device comprises:

the acquisition unit is used for acquiring a history block to be verified and reading a transaction to be verified from the history block;

the execution unit executes the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; executing the transaction based on a second software version supported by the blockchain to obtain a second transaction execution result;

and the verification unit is used for matching the first transaction execution result with the second transaction execution result and determining whether the first software version and the second software version are compatible or not based on the matching result.

Optionally, before the execution unit, the method further includes:

the data acquisition subunit is used for acquiring historical state data corresponding to the historical blocks from a historical state database corresponding to the block chain; wherein the historical state data corresponding to the historical chunk is set to a read-only state; reading an initial account status corresponding to a blockchain account associated with the transaction from historical status data corresponding to the historical blocks.

the execution unit further includes:

a first execution subunit that executes the transaction based on a first software version supported by the blockchain, generates an updated account status corresponding to the primary account status, and generates a first transaction receipt for the transaction corresponding to the first software version based on the primary account status and the updated account status;

and the second execution subunit executes the transaction based on a second software version supported by the blockchain, generates an updated account state corresponding to the primary account state, and generates a second transaction receipt corresponding to the second software version based on the primary account state and the updated account state.

before the verification unit, the method further comprises:

and the calling unit is used for calling the service port and locally storing the generated first transaction receipt and the second transaction receipt.

Optionally, the verification unit further includes:

a read subunit reading the first transaction receipt and the second transaction receipt of the service port record;

a matching subunit for matching the first transaction receipt and the second transaction receipt;

a determining subunit that determines that the first software version is compatible with the second software version if the first transaction receipt matches the second transaction receipt; otherwise, determining that the first software version is incompatible with the second software version.

Optionally, the obtaining unit further includes: the method comprises the steps of obtaining a block number interval corresponding to a historical block to be verified, which is specified by a user, reading the block number of the historical block to be verified from the block number interval, and reading the historical block corresponding to the block number from block data of a locally maintained block chain.

Optionally, before the obtaining unit, the method further includes:

and the response unit is used for responding to the gray level upgrade of the software version supported by part of the node devices in the block chain to the latest software version, acquiring a history block to be verified, and reading a transaction to be verified from the history block.

Optionally, the apparatus further comprises:

and if the latest software version is determined to be compatible with the historical software version, sending an upgrading instruction to the service platform corresponding to the blockchain to trigger the service platform to upgrade the software version supported by the part of the node equipment from the historical software version to the latest software version.

Optionally, the service platform includes a Bass platform.

According to a third aspect of embodiments herein, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to perform any one of the above methods for blockchain version compatibility verification.

In an embodiment of the present specification, a blockchain version compatibility verification scheme is provided, where transactions in a history block are executed by a first software version and a second software version supported by a blockchain, respectively, and a result of the transaction execution is compared to verify whether the first software version and the second software version are compatible.

Drawings

FIG. 1 is a flowchart of a method for blockchain version compatibility verification according to an exemplary embodiment;

FIG. 2 is a schematic diagram of an electronic device according to an exemplary embodiment;

fig. 3 is a block diagram of a block chain version compatibility verification apparatus according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Block chains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.

Among them, the most decentralized is the public chain. Participants joining the public chain (also referred to as nodes in the blockchain) can read the data records on the chain, participate in transactions, compete for accounting rights for new blocks, and so on. Moreover, each node can freely join or leave the network and perform related operations.

Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.

A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.

Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.

The real data generated in the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then the real data is issued to the block chain, the node devices in the block chain perform consensus processing on the received transactions, after the consensus is achieved, the node devices serving as accounting nodes in the block chain pack the transactions into blocks, and persistent evidence storage is performed in the block chain.

In general, the accounting node of the current round may package the received transaction to generate a candidate block and send the generated candidate block or a block header of the candidate block to other node devices for consensus verification. If no problem is verified after the other node device receives the candidate block or the block header of the candidate block, the candidate block can be added to the end of the original block chain as the latest block, thereby completing the accounting process of the block chain. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

In the field of blockchain, an important concept is Account (Account); accounts are generally divided into two categories, external accounts and contract accounts; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract).

Of course, for some block chains of the account model (such as ant block chains), the account types supported by the block chains may be further expanded, and are not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

In general, the structure of an account usually includes fields such as Balance, Nonce, Code, and Storage. Wherein:

a Balance field for maintaining the current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;

a Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.

A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account. The storage content of the contract account is usually constructed into a data structure of an MPT (Merkle Patricia Trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.

Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.

For most blockchain models, Merkle trees are typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. For example, an MPT tree (a Merkle tree variety) is used as a data organization form for organizing and managing important data such as account status, transaction information, and the like.

For data needing to be stored and maintained in a block chain, three MPT trees are designed, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree. In addition to the three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.

An MPT state tree, which is an MPT tree organized by account state data of all accounts in a blockchain; an MPT transaction tree, which is an MPT tree organized by transaction (transaction) data in a blockchain; the MPT receipt tree is an MPT tree organized by transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are all added to the block header of the corresponding block.

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.

For the MPT transaction tree, the MPT receipt tree and the MPT state tree which are organized, the MPT transaction tree, the MPT receipt tree and the MPT state tree are finally stored in a Key-Value type database (such as a levelDB) which adopts a multi-level data storage structure.

The database adopting a multilevel data storage structure usually adopts a multilevel data storage structure and can be divided into n levels of data storage; for example, each level of data storage may be set to L0, L1, L2, L3.. L (n-1) in sequence; for each level of data storage in the database, the smaller the level number is, the higher the level is generally; for example, L0 stores the latest chunks of data, L1 stores the next-to-new chunks of data, and so on.

Wherein, the read-write performance of the storage medium corresponding to each level of data storage may also have performance difference in general; for example, the read/write performance of the storage medium corresponding to the data storage with a higher rank (i.e., with a smaller rank number) may be higher than the read/write performance of the storage medium corresponding to the data storage with a lower rank. In practical application, a storage medium with higher storage cost and better storage performance can be used for storing data with high level; and the storage medium with low unit cost and large capacity can be used for storing the data with low level.

In practical applications, as the block number of a block chain increases (also referred to as block height), the data stored in the database contains a lot of historical data; also, the longer the data in a block with a smaller block number is, the less important it is. Therefore, in order to reduce the overall storage cost, data of different block heights can be generally treated differently; for example, the data in the block with the smaller block number can be stored on a storage medium with lower cost; and the data in the block with larger block number is stored on the storage medium with higher cost.

It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;

for example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.

After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is completed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

The explanation is given by taking an MPT state tree organized by account state data of the blockchain as an example.

The MPT tree is a relatively traditional modified Merkle tree variety, and combines the advantages of two tree structures, namely a Merkle tree and a Trie dictionary tree (also called as a prefix tree).

Three data nodes, a leaf node (leaf node), an extension node (extension node), and a branch node (branch node), are typically included in the MPT tree.

The extended node is represented as a key-value pair of [ key, value ], wherein the key is a special hexadecimal code character and represents a shared character prefix of the account address; the shared character prefix refers to a prefix formed by one or more same characters of a plurality of block chain account addresses; value is the hash value (hash pointer) of the other node, i.e. it can be linked to the other node by a hash pointer.

The branch node comprises 17 elements, the first 16 elements correspond to 16 possible hexadecimal characters in the key, and one character corresponds to one nibble (half byte), and the shared character prefixes (the length of the prefixes is one character) of one account address are respectively represented. If a [ key, value ] pair terminates at the branch node, the branch node can act as a leaf node, and the last element represents the value of the leaf node; otherwise, the last element of the branch node may be null.

A leaf node, which is a key-value pair represented as [ key, value ], wherein key is also a special hexadecimal code character and represents a character suffix of the account address; the character suffix of the account address and the shared character prefix of the account address jointly form a complete account address; the character suffix refers to a suffix formed by the last one or more characters except the shared character prefix of the account address; value is the status data (i.e., the structure shown above) of the account address corresponding to that leaf node.

Because characters on a search path from a root node to a leaf node on the MPT tree form a complete account address; therefore, the branch node may be a termination node of the search path or an intermediate node of the search path.

Assume that account status data that needs to be organized into an MTP status tree is shown in table 1 below:

TABLE 1

In table 1, the account address is a character string composed of several 16-ary characters. The account status is a structure composed of fields such as Balance, Nonce, Code, and Storage.

The MPT state tree is finally organized according to the account state data in the table 1; the MPT state tree is composed of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which serves as a root node).

The prefix field is a prefix field that the extension node and the leaf node have in common. Different field values of the prefix field may be used to indicate different node types.

For example, the value of the prefix field is 0, which indicates that an extension node includes an even number of nibbles; as previously mentioned, a nibble represents a nibble, consisting of a 4-bit binary, and one nibble may correspond to one character that makes up an account address. The value of the prefix field is 1, and the prefix field represents an expansion node containing odd number of nibbles(s); the value of the prefix field is 2, which represents a leaf node containing an even number of nibbles; the value of the prefix field is 3, which indicates that the leaf node contains an odd number of nibbles(s).

And the branch node does not have the prefix field because the branch node is a prefix node of the parallel single neighbor.

A Shared neighbor field in the extension node, corresponding to a key value of a key-value pair contained in the extension node, represents a common character prefix between account addresses; for example, all account addresses in the table above have a common character prefix a 7. The Next Node field is filled with the hash value (hash pointer) of the Next Node.

The fields of the 16-system characters 0-f in the branch nodes correspond to the key values of the key value pairs contained in the branch nodes; if the branch node is an intermediate node of the account address on the search path on the MPT tree, the Value field of the branch node may be null. And the hash value used for filling the next node is in the fields 0-f.

The Key-end in a leaf node, corresponding to the Key value of the Key-value pair contained in that leaf node, represents the last few characters of the account address (the character suffix of the account address). The key values of the nodes on the search path from the root node to the leaf nodes form a complete account address. Filling account state data corresponding to the account address in a Value field of the leaf node; for example, a structure composed of fields such as Balance, Nonce, Code, and storage may be encoded and filled in the Value field of the leaf node.

Further, the node on the MPT state tree is finally stored in the database in a Key-Value Key Value pair mode;

when a node on the MPT state tree is stored in the database, a key in a key value pair of the node on the MPT state tree can be a hash value of data content contained in the node; value in the key Value pair of the node on the MPT state tree is the data content contained in the node.

That is, when a node in the MPT state tree is stored in the database, a hash Value of data content contained in the node may be calculated (that is, the whole node is subjected to hash calculation), the calculated hash Value is used as a Key, the data content contained in the node is used as a Value, and a Key-Value Key Value pair is generated; and then storing the generated Key-Value Key Value pair into a database.

Because the node in the MPT state tree takes the hash value of the data content contained in the node as Key and the data content contained in the node as value for storage; therefore, when a node on the MPT state tree needs to be queried, content addressing can be performed as a key based on the hash value of the data content contained in the node.

In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a Smart contract (Smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.

As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write the intelligent contract code instead of directly writing the byte code. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.

In the existing blockchain technology, there is a need for upgrading the software version of the blockchain. Each version upgrade of a blockchain requires a new version of blockchain to be released for replacing the old version of blockchain.

Because the version upgrading of the blockchain is to directly replace the old version with the new version every time, the transition period is not existed in the middle, and all users of the blockchain are directly affected after the replacement. If there is an incompatibility problem with the blockchains of the new and old versions, then transactions processed using the blockchains of the new version will be in error.

Therefore, how to discover the compatibility between the new version and the old version blockchains in advance is a problem to be solved urgently in the industry.

In order to solve the above problems, the present specification proposes a block chain version compatibility verification scheme. By the scheme, whether the new version and the old version have compatibility problems can be verified in advance before the new version is used formally.

Referring to fig. 1, fig. 1 is a flowchart illustrating a method for verifying compatibility of a blockchain version according to an exemplary embodiment. The method is applied to a target node device in the block chain; and the block chain supports software version upgrading. After receiving the latest software version of the blockchain, the following steps can be executed without immediately performing version upgrade of the blockchain:

step 210: and acquiring a history block to be verified, and reading the transaction to be verified from the history block.

The target node device may first obtain a history block to be verified and read the transaction to be verified from the history block.

The history block may be a preset history block or a history block designated by a user.

Taking a preset history block as an example, the latest history block can be read from the block data of the locally maintained block chain.

Taking the history block designated by the user as an example, the obtaining the history block to be verified may include:

And the block data of the locally maintained block chain is block data which is copied to the target node equipment in advance. In order to ensure that the target node device can correctly acquire the historical blocks, it is necessary to synchronize the latest block data in the block chain to the local of the target node device.

In an exemplary embodiment, the target node device includes a non-consensus node preset in the block chain and not participating in consensus.

Generally, nodes in a block chain can be divided into a consensus node and a non-consensus node, where the non-consensus node refers to a block chain node that does not perform consensus. Wherein, the consensus node is generally used for processing the transaction needing consensus; and non-consensus nodes may be used to process transactions that do not require consensus.

In this embodiment, the transactions executed by the first software version and the second software version are historical transactions in a historical block, and the transactions do not need to be identified together, so that the non-identified nodes which do not participate in the identification together can be used as target node equipment. Therefore, normal transaction cannot be influenced by occupying resources of the consensus node.

Similarly, in some embodiments, in order to not occupy the existing resources of the common node and the non-common node in the blockchain, a non-common node for verifying the compatibility of the software version may be further added to the blockchain.

Step 220: executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; executing the transaction based on a second software version supported by the blockchain to obtain a second transaction execution result;

wherein the first software version may comprise a latest software version; the second software version may include a historical software version supported by a part of node devices in the blockchain before the software version supported by the part of node devices is upgraded to the latest software version.

After reading the transaction to be verified, the target node device may execute the same transaction to be verified based on the latest software version and the historical software version, respectively.

In an exemplary embodiment, before the step 220, the method may further include:

In this example, the transaction to be verified is executed again to verify the compatibility of the blockchain software version, and the transaction is not executed normally, so the result of executing the transaction regardless of the first software version or the second software version should not be recorded in the status data; which would otherwise result in an exception to the status data. For example, assuming that the transaction to be verified is a transfer from account a to account B, if the outcome of the execution is allowed to be posted to the status data, account a would actually transfer to account B, but account a did not actually initiate a transfer, thereby causing a significant error. In this way, by setting the historical status data corresponding to the historical block to be read-only, updating the status data of the historical transaction after the transaction is executed in step 220 can be avoided.

In an exemplary embodiment, the transaction execution result includes a transaction receipt generated after execution of the transaction;

The target node equipment is provided with a service port for recording a transaction execution result;

invoking the service port and locally storing the generated first transaction receipt and the second transaction receipt.

In this example, the service portal may record the transaction execution results in the form of a transaction receipt. In particular, the transaction receipt may be stored in the MPT receipt tree.

It is worth mentioning that executing the transaction based on the first software version supported by the blockchain is assumed to be referred to as a first execution transaction; and executing the transaction based on the second software version supported by the blockchain is referred to as executing the transaction a second time.

Then, after the first transaction is executed and a first transaction receipt is obtained, it is also necessary to roll back (rolback) the first executed transaction, so as to restore the updated account status after the first executed transaction back to the original account status. This is done in order not to affect the world state.

Since the same transaction is performed for the first and second times, the blockchain typically updates the account status involved in the transaction after the transaction is performed. If the first executed transaction is not rolled back, then the initial account status of the same transaction will be different at the second execution and the results will necessarily be different. Therefore, by rolling back, the world state is not influenced when the transaction is executed for the first time, and the execution result of the transaction executed for the second time is not influenced.

For example, suppose a transaction is a transfer of 10 dollars from user a to user B, the account balance of user a in the world state is 100 dollars (primary account state), and the account balance of user B is 50 dollars (primary account state).

Then, after the first execution, the account balance of user a in the world state becomes 90 yuan (updated account state), and the account balance of user B becomes 60 yuan (updated account state).

If not, then at the second execution time, 10 is transferred from user A's account balance 90 to user B's account balance 60. Rather than the initial transfer of 10 from user a's account balance of 100 to user B's account balance of 50.

Thus, it is desirable to roll back the first executed transaction so that the world state is maintained with the account balance of user A being 100 dollars and the account balance of user B being 50 dollars. Thus, at the second execution, the 10-element is transferred from the account balance of 100-element for user A to the account balance of 50-element for user B, as in the first execution.

It is worth mentioning that the first software release and the second software release may differ in release logic. Thereby generating different transaction receipts when the first software version and the second software version perform the same transaction.

Still following the foregoing example, a transaction is a transfer of 10 dollars from user A to user B, with the account balance of user A being 100 dollars and the account balance of user B being 50 dollars in the world state. Wherein, the new version of the blockchain needs to charge 1-element handling fee; the old version of the blockchain requires a 2-tuple commission.

Then, after the first execution of the transaction, the first transaction receipt is obtained by taking 10 out of the account balance of user a of 100 dollars to transfer to user B of an account balance of 50 dollars. And, a 2-dollar commission is additionally extracted from the account balance 100 of user a. I.e., the account balance of user a is 88 dollars remaining, and the account balance of user B is 60 dollars.

After the transaction is executed for the second time, the second transaction receipt is obtained by extracting 10 yuan from the account balance of 100 yuan of the user A to transfer to the account balance of 50 yuan of the user B. And, a 1-dollar commission is additionally extracted from the account balance 100 of the user a. That is, the account balance of user a is 89 yuan remaining, and the account balance of user B is 60 yuan.

It can be seen that performing the same transaction with the first software version and the second software version, respectively, can result in different transaction receipts due to differences in version logic.

To address this issue, forward compatible configuration files may be configured for the first software release and the second software release that include logic for the differences in the first software release and the second software release. Differences between software versions can thus be compensated for.

Specifically, the target node device may replace the logic of the difference between the first software version and the second software version with the same logic based on the pre-configured configuration file when the transaction is performed for the first time. Therefore, the compatibility difference between the new version and the old version is made up through the configuration file, so that the difference caused by version logic reasons can be avoided after the same transaction is executed respectively.

Step 230: and matching the first transaction execution result with the second transaction execution result, and determining whether the first software version and the second software version are compatible based on the matching result.

After obtaining a first transaction execution result and a second transaction execution result, the target node device matches the first transaction execution result with the second transaction execution result, so that whether the first software version and the second software version are compatible can be determined based on the matching result.

In an exemplary embodiment, the step 230 may include:

matching the read first transaction receipt and the second transaction receipt;

In this example, the first transaction receipt and the second transaction receipt matching may mean that the first transaction receipt and the second transaction receipt are the same or consistent.

In the actual application, when the first transaction receipt and the second transaction receipt are matched, a first root hash of a transaction receipt tree of the first transaction receipt and a second root hash of a transaction receipt tree of the second transaction receipt can be obtained; confirming that the first transaction receipt and the second transaction receipt match if the first root hash and the second root hash match.

As previously mentioned, the transaction receipt is located on a transaction receipt tree, which is a Merkle tree. For the Merkle tree, the root hash is computed from all data hashes on the tree. Any difference in the hash of any one data on the tree will affect the final root hash.

Thus, after the same transaction is performed by the first software version and the second software version, respectively, it should have the same transaction receipt tree, i.e., it should have the same root hash. If the root hashes of the two are not consistent, then it can be determined that the compatibility problem exists between the two.

In this way, it is not necessary to find the transaction receipt for performing the transaction from the transaction receipt tree, but it is faster by directly comparing the root hash of the transaction receipt tree.

In practical applications, the types of transactions in the blockchain may include different types of account creation, contract creation, transfer, asset issuance, asset redemption, and the like. The execution of each transaction type requires support of the associated logic in the version.

By performing different transaction types with the embodiment shown in fig. 1, it can be determined what types of transactions have compatibility issues when performing what version blockchains.

For example, when a create account transaction is performed, the transaction receipts are the same, while when a transfer is performed, the transaction receipts are different; then it may be determined that there is a compatibility problem with the version logic for the transfer in the new version.

In addition, when a plurality of history blocks exist, transaction types in different blocks can be different, so that whether compatibility problems exist among software versions of the block chains under different transaction types can be verified.

In an exemplary embodiment, when there are multiple history blocks, the target node device may execute transactions in a first software version and in a second software version in parallel under multiple threads.

In this example, to get the verification result quickly, transactions of different blocks may be executed in parallel under multiple threads; the executed blocks do not influence each other, and the execution result does not influence the world state. The blocks are in an isolated state, so that the multithreading parallel execution has feasibility and improves the verification speed.

In an exemplary embodiment, the blockchain supports a software version grayscale upgrade; the second software version comprises historical software versions supported by part of node devices in the block chain before the software versions supported by the part of node devices are upgraded to the latest software version in a gray scale mode.

Accordingly, before the step 210, the method may further include:

In this example, the grayscale upgrade may refer to a smooth transition upgrade mode. In the gray scale upgrading process, A/B testing is adopted firstly, namely, a part of users continue to use the historical software version, and a part of users start to use the latest software version; if the user has no objection to the latest software version, the use range of the latest software version is gradually expanded, and all users are slowly migrated to the latest software version.

The stable operation of the whole block chain can be ensured by adopting a gray scale upgrading mode, the problem can be found and timely processed during the initial gray scale upgrading, and the influence range of the problem is limited even if the user group with the initial gray scale upgrading is few.

In an exemplary embodiment, if it is determined that the latest software version is compatible with the historical software version, an upgrade indication is sent to the service platform corresponding to the blockchain to trigger the service platform to upgrade the software version supported by the part of node devices from the historical software version to the latest software version.

The Service platform includes a BaaS platform (also referred to as a BaaS cloud) for providing a block chain as a Service (BaaS). The BaaS platform can provide a pre-programmed software mode for activities (such as subscription and notification, user verification, database management and remote update) occurring on the blockchain, and provides a simple and easy-to-use, one-key deployment, quick verification and flexible and customizable blockchain service for client-side computing equipment coupled with the BaaS platform, so that the application development, test and online of blockchain services can be accelerated, and landing of blockchain business application scenes of various industries can be facilitated.

Corresponding to the above method embodiments, the present specification further provides an embodiment of a device for verifying compatibility of a blockchain version.

The embodiments of the blockchain version compatibility verification apparatus of the present specification can be applied to electronic devices. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

From a hardware aspect, as shown in fig. 2, the block chain version compatibility verification apparatus in this specification is a hardware structure diagram of an electronic device where the block chain version compatibility verification apparatus is located, and except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 2, the electronic device where the apparatus is located in the embodiment may also include other hardware according to an actual function of the electronic device, which is not described again.

Fig. 3 is a block diagram of a blockchain version compatibility verification apparatus according to an exemplary embodiment of the present disclosure.

Referring to fig. 3, the apparatus for verifying compatibility of blockchain version may be applied to the electronic device shown in fig. 2, where the apparatus is applied to a target node device in the blockchain; wherein the blockchain supports software version upgrading; the device comprises:

the acquiring unit 310 acquires a history block to be verified, and reads a transaction to be verified from the history block;

the execution unit 320 executes the transaction based on the first software version supported by the blockchain, and obtains a first transaction execution result; executing the transaction based on a second software version supported by the blockchain to obtain a second transaction execution result;

the verification unit 330 matches the first transaction execution result with the second transaction execution result, and determines whether the first software version and the second software version are compatible based on the matching result.

Optionally, before the executing unit 320, the method further includes:

the execution unit 320 further includes:

before the verification unit 330, the method further includes:

Optionally, the verification unit 330 further includes:

Optionally, the obtaining unit 310 further includes: the method comprises the steps of obtaining a block number interval corresponding to a historical block to be verified, which is specified by a user, reading the block number of the historical block to be verified from the block number interval, and reading the historical block corresponding to the block number from block data of a locally maintained block chain.

Optionally, before the obtaining unit 310, the method further includes:

Optionally, the apparatus further comprises:

Optionally, the service platform includes a Bass platform.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, that may be used to store information that may be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A block chain version compatibility verification method is applied to a target node device in a block chain; wherein the blockchain supports software version upgrading; the method comprises the following steps:

2. The method of claim 1, executing the transaction at the first software release supported based on the blockchain, resulting in a first transaction execution result; and executing the transaction based on the second software version supported by the blockchain, and before obtaining a second transaction execution result, the method further comprises the following steps:

3. The method of claim 2, the transaction execution result comprising a transaction receipt generated after execution of the transaction;

4. The method of claim 3, the target node device hosting a service port for recording transaction execution results;

5. The method of claim 4, the matching the first transaction execution result with the second transaction execution result and determining whether the first software version and the second software version are compatible based on the matching result, comprising:

matching the first and second transaction receipts that are read;

6. The method of claim 1, the obtaining the history block to be verified, comprising:

7. The method of claim 6, wherein the locally maintained chunk data of the blockchain is chunk data that was previously copied to the target node device.

8. The method of claim 1, the blockchain supporting a software version grayscale upgrade; the first software version comprises a latest software version; the second software version comprises historical software versions supported by part of node devices in the block chain before the software versions supported by the part of node devices are upgraded to the latest software version in a gray scale mode.

9. The method of claim 8, further comprising, prior to said obtaining a history block to be verified and reading transactions to be verified from the history block:

10. The method of claim 9, further comprising:

11. The method of claim 10, the service platform comprising a Bass platform.

12. The method of claim 1, the target node device comprising a non-consensus node preset in the blockchain that does not participate in consensus.

13. A block chain version compatibility verification device is applied to a target node device in a block chain; wherein the blockchain supports software version upgrading; the device comprises:

14. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-12 by executing the executable instructions.