CN114816509A - Blockchain version compatibility verification method and device, electronic device - Google Patents

Abstract

The embodiments of this specification provide a blockchain version compatibility verification method and device, and an electronic device. The method is applied to the target node device in the blockchain; wherein, the blockchain supports software version upgrade; the method includes: acquiring a historical block to be verified, and extracting the historical block from the historical block reading the transaction to be verified; 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, Obtain a second transaction execution result; match the first transaction execution result with the second transaction execution result, and determine whether the first software version and the second software version are compatible based on the matching result .

Description

Blockchain version compatibility verification method and device, electronic device

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and apparatus for verifying version compatibility of a blockchain, and an electronic device.

Background technique

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Due to the characteristics of decentralization, openness and transparency of blockchain technology, each computing device can participate in database records, and data synchronization between computing devices can be performed quickly, blockchain technology has been widely used in many fields. to apply.

SUMMARY OF THE INVENTION

The embodiments of this specification provide a method and apparatus for improving information security, and an electronic device.

According to a first aspect of the embodiments of this specification, a method for verifying version compatibility of a blockchain is provided, and the method is applied to a target node device in the blockchain; wherein the blockchain supports software version upgrades ; the method includes:

Obtain the historical block to be verified, and read the transaction to be verified from the historical block;

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

The first transaction execution result is matched with the second transaction execution result, and based on the matching result, it is determined whether the first software version is compatible with the second software version.

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, Before obtaining the execution result of the second transaction, it also includes:

Obtain the historical state data corresponding to the historical block from the historical state database corresponding to the blockchain; wherein, the historical state data corresponding to the historical block is set to a read-only state;

The initial account state corresponding to the blockchain account associated with the transaction is read from the historical state data corresponding to the historical block.

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

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

Execute the transaction based on the first software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state and the updated account state based on the initial account state and the updated account state the first transaction receipt for the first software version;

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

Execute the transaction based on the second software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state based on the initial account state and the updated account state and a second transaction receipt for the second software version.

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

Before the matching of the first transaction execution result with the second transaction execution result, the method further includes:

The service port is called to locally store the generated first transaction receipt and the second transaction receipt.

Optionally, 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, include:

reading the first transaction receipt and the second transaction receipt recorded by the service port;

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

If the first transaction receipt matches the second transaction receipt, it is determined that the first software version is compatible with the second software version; otherwise, it is determined that the first software version is not compatible with the second software version .

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

Obtain the block number range corresponding to the historical block to be verified specified by the user;

The block number of the historical block to be verified is read from the block number interval, and the historical block corresponding to the block number is read from the block data of the blockchain maintained locally.

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

Optionally, the blockchain supports grayscale upgrade of software versions; the first software version includes the latest software version; the second software version includes software that supports some node devices in the blockchain. The version is the historical software version supported by some node devices before the grayscale upgrade is to the latest software version.

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

In response to the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, the historical block to be verified is obtained, and the transaction to be verified is read from the historical block.

Optionally, the method further includes:

If it is determined that the latest software version is compatible with the historical software version, send an upgrade instruction to the service platform corresponding to the blockchain, so as to trigger the service platform to transfer the software versions supported by the part of the node devices to the historical software The version is upgraded to the latest software version described.

Optionally, the service platform includes a Bass platform.

Optionally, the target node device includes a preset non-consensus node in the blockchain that does not participate in the consensus.

According to a second aspect of the embodiments of the present specification, a blockchain version compatibility verification device is provided, the device is applied to a target node device in the blockchain; wherein the blockchain supports software version upgrade ; the device includes:

an acquisition unit that acquires the historical block to be verified, and reads the transaction to be verified from the historical block;

an execution unit that executes the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and executes the transaction based on the second software version supported by the blockchain to obtain a second transaction Results of the;

A verification unit that 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 execution unit, it further includes:

The data acquisition subunit acquires the historical state data corresponding to the historical block from the historical state database corresponding to the blockchain; wherein, the historical state data corresponding to the historical block is set to a read-only state ; Read the initial account state corresponding to the blockchain account related to the transaction from the historical state data corresponding to the historical block.

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

The execution unit further includes:

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

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

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

Before the verification unit, it also includes:

The calling unit calls the service port to locally store the generated first transaction receipt and the second transaction receipt.

Optionally, the verification unit further includes:

a reading subunit, to read the first transaction receipt and the second transaction receipt recorded by the service port;

a matching subunit, which matches the read first transaction receipt and the second transaction receipt;

A determination subunit, if the first transaction receipt matches the second transaction receipt, determine that the first software version is compatible with the second software version; otherwise, determine that the first software version is compatible with the second software version Incompatible software version.

Optionally, the obtaining unit further includes: obtaining the block number interval corresponding to the historical block to be verified specified by the user, and reading the block number of the historical block to be verified from the block number interval, And read the historical block corresponding to the block number in the block data of the block chain maintained locally.

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

Optionally, the blockchain supports grayscale upgrade of software versions; the first software version includes the latest software version; the second software version includes software that supports some node devices in the blockchain. The version is the historical software version supported by some node devices before the grayscale upgrade is to the latest software version.

Optionally, before the obtaining unit, it further includes:

The response unit, in response to the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, obtains the historical block to be verified, and reads the historical block to be verified from the historical block. trade.

Optionally, the device further includes:

The processing unit, if it is determined that the latest software version is compatible with the historical software version, sends an upgrade instruction to the service platform corresponding to the blockchain, so as to trigger the service platform to update the software version supported by the part of the node device by the service platform. The historical software version is upgraded to the latest software version.

Optionally, the service platform includes a Bass platform.

Optionally, the target node device includes a preset non-consensus node in the blockchain that does not participate in the consensus.

According to a third aspect of the embodiments of the present specification, an electronic device is provided, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor is configured as any one of the above-mentioned blockchain version compatibility verification methods.

The embodiment of this specification provides a blockchain version compatibility verification scheme. The first software version and the second software version supported by the blockchain execute transactions in historical blocks respectively, and by comparing the transaction execution results of the two, to verify whether the first software version is compatible with the second software version.

Description of drawings

1 is a flowchart of a method for verifying version compatibility of a blockchain provided by an exemplary embodiment;

FIG. 2 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

FIG. 3 is a block diagram of a blockchain version compatibility verification device provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numerals in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification, as recited in the appended claims.

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

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can also be a combination of the above-mentioned types, such as private chain + alliance chain, alliance chain + public chain, etc.

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

The private chain is on the contrary, the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use by specific institutions.

The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; the node joins the network through authorization and forms a stakeholder alliance to jointly maintain the operation of the blockchain.

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

For the real data generated in the physical world, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain, and the node devices in the blockchain will perform consensus processing on the received transactions , and after reaching a consensus, the node device in the blockchain as the accounting node will package the transaction into the block and store the certificate persistently in the blockchain.

Generally, the accounting node of this round can package the received transaction to generate a candidate block, and send the generated candidate block or the block header of the candidate block to other node devices for consensus verification. If other node devices receive the candidate block or the block header of the candidate block and verify that there is no problem, the candidate block can be added to the end of the original blockchain as the latest block, thereby completing the blockchain. accounting process. In the process of verifying the new block or block header sent by the accounting node, other nodes can also execute the transactions contained in the block.

In the field of blockchain, an important concept is Account; accounts are usually divided into two categories: external accounts and contract accounts; external accounts are accounts directly controlled by users, also known as user accounts; and contract accounts It is an account (ie, a smart contract) that is created by the user through an external account and contains the contract code.

Of course, for some blockchains with account models (such as Ant blockchain), the account types supported by the blockchain can be further expanded, which is not particularly limited in this specification.

For an account in the blockchain, a structure is usually used to maintain the account state of the account. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes as well.

Generally, the structure of the account usually includes fields such as Balance, Nonce, Code and Storage. in:

The Balance field is used to maintain the current account balance of the account;

The Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can be processed only once, effectively avoiding replay attacks;

The Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the Codehash field.

The Storage field is used to maintain the storage content of the account (the default field value is empty); for a contract account, an independent storage space is usually allocated to store the storage content of the contract account; the independent storage space is usually Call it the account storage for this contract account. The storage content of the contract account is usually constructed as a data structure of the MPT (Merkle Patricia Trie) tree and stored in the above-mentioned independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree. The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field.

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

For most blockchain models, a Merkle tree; or, a data structure based on a Merkle tree, is usually used to store and maintain data. For example, MPT tree (a Merkle tree variant) is used as a data organization form to organize and manage important data such as account status and transaction information.

For the data that needs to be stored and maintained in the blockchain, three MPT trees are designed, which are MPT state tree, MPT transaction tree and MPT receipt tree. Among them, in addition to the above three MPT trees, there is actually a Storage tree constructed based on the storage content of the contract account.

MPT state tree is an MPT tree organized by the account state data of all accounts in the blockchain; MPT transaction tree is an MPT tree organized by transaction data in the blockchain; MPT receipt tree , is the MPT tree organized by the transaction receipt corresponding to each transaction generated after the transaction in the block is executed. The hash values of the root nodes of the MPT state tree, MPT transaction tree, and MPT receipt tree shown above will eventually be added to the block header of the corresponding block.

Among them, the MPT transaction tree and the MPT receipt tree correspond to blocks, that is, each block has its own MPT transaction tree and MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific block, but covers the account state data of all accounts in the blockchain.

The organized MPT transaction tree, MPT receipt tree and MPT state tree will eventually be stored in a Key-Value database (for example, LevelDB) that adopts a multi-level data storage structure.

The above-mentioned databases adopting a multi-level data storage structure usually adopt a multi-level data storage structure, which can be divided into n-level data storage; for example, the data storage of each level can be set as L0, L1, L2, L3.... L(n-1); For the data storage of all levels in the above database, the smaller the level number is, the higher the level is; for example, L0 stores the data of the latest blocks, and L1 stores the next new ones. block data, and so on.

Among them, the read and write performance of the storage medium corresponding to the data storage at all levels may also have performance differences; for example, the read and write performance of the storage medium corresponding to the data storage with a high level (that is, with a smaller level number) may be higher than that of the level. The read and write performance of the storage medium corresponding to low data storage. In practical applications, high-level data storage can use storage media with higher storage costs and better storage performance; while low-level data storage can use storage media with low unit cost and larger capacity.

In practical applications, as the block number of the blockchain increases (also called the block height), the data stored in the database will contain a lot of historical data; The older the data, the less important it is. Therefore, in order to reduce the overall storage cost, data of different block heights can usually be "differently treated"; for example, the data in the block with a smaller block number can be stored on a lower-cost storage medium; On the other hand, the data in the block with the larger block number is stored on the storage medium with higher cost.

It should be noted that each time the blockchain generates a newest block, after the transactions in the latest block are executed, the relevant accounts of these executed transactions in the blockchain (can be external accounts or contract accounts) account status, usually changes accordingly;

For example, when a "transfer transaction" in the block is executed, the balances of the sender's account and the transferer's account related to the "transfer transaction" (that is, the field value of the Balance field of these accounts) are usually also will change accordingly.

After the node device completes the execution of the transaction in the latest block generated by the blockchain, since the account status in the current blockchain has changed, the node device needs to use the current account status data of all accounts in the blockchain. Build the MPT state tree to maintain the latest state of all accounts in the blockchain.

That is, whenever a latest block is generated in the blockchain and the transaction in the latest block is executed, the account status in the blockchain changes, and the node device needs to be based on all the accounts in the blockchain. The latest account status data, rebuild an MPT status tree. In other words, each block in the blockchain has a corresponding MPT state tree; the MPT state tree maintains that after the transaction in the block is executed, all accounts in the blockchain are up-to-date. account status.

Take the MPT state tree organized by the account state data of the blockchain as an example to illustrate.

MPT tree is a more traditional and improved variant of Merkle tree, which combines the advantages of two tree structures of Merkle tree and Trie dictionary tree (also called prefix tree).

An MPT tree usually includes three kinds of data nodes, which are leaf nodes, extension nodes, and branch nodes.

Extended node, represented as a key-value pair of [key, value], where key is a special hexadecimal coded character, which represents the shared character prefix of the account address; wherein, the shared character prefix refers to the multi-area The address of the blockchain account has the same prefix of one or more characters; the value is the hash value (hash pointer) of other nodes, that is to say, it can be linked to other nodes through the hash pointer.

Branch node, including 17 elements, the first 16 elements correspond to the 16 possible hexadecimal characters in the key, and one character corresponds to a nibble (nibble), which respectively represent the shared character prefix of an account address (length is one character). Among them, if there is a [key, value] pair terminated at this 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 can be Null value.

A leaf node is a key-value pair expressed as [key, value], where key is also a special hexadecimal coded character, representing the character suffix of the account address; among them, the character suffix of the account address and the shared character of the account address The prefixes together form a complete account address; the character suffix refers to the suffix consisting of the last one or more characters except the shared character prefix of the account address; value is the status data of the account address corresponding to the leaf node (ie structure shown above).

Because on the MPT tree, the characters on the search path from the root node to a leaf node form a complete account address; therefore, for the branch node, it can be either the termination node of the above search path, or the above Intermediate nodes of the search path.

Assume that the account state data that needs to be organized into an MTP state tree is shown in Table 1 below:

Table 1

In Table 1, the account address is a string composed of several hexadecimal characters. The account state state is a structure composed of the above fields such as Balance, Nonce, Code, and Storage.

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

The prefix field is a prefix field shared by the extension node and the leaf node. Different field values of the prefix field can be used to represent different node types.

For example, the value of the prefix field is 0, indicating an extension node containing an even number of nibbles; as mentioned above, a nibble represents a nibble, which is composed of 4-bit binary, and a nibble can correspond to a character that constitutes an account address. The value of the prefix field is 1, which means that the extension node contains an odd number of nibble(s); the value of the prefix field is 2, which means that the leaf node contains an even number of nibbles; the value of the prefix field is 3, which means that it contains an odd number of nibbles. (s) leaf node.

For the branch node, since it is a prefix node of a parallel single nibble, the branch node does not have the above prefix field.

The Shared nibble field in the extension node corresponds to the key value of the key-value pair contained in the extension node, indicating the common character prefix between account addresses; for example, all account addresses in the above table have a common character prefix a7. The Next Node field is filled with the hash value (hash pointer) of the next node.

The hexadecimal character 0～f field in the branch node corresponds to the key value of the key-value pair contained in the branch node; if the branch node is an intermediate node on the search path of the account address in the MPT tree, then the branch node The Value field can be null. The hash value used to fill the next node in the 0~f field.

The Key-end in the leaf node corresponds to the key value of the key-value pair contained in the leaf node, and represents the last few characters of the account address (the character suffix of the account address). The key value of each node on the search path from the root node to the leaf node constitutes a complete account address. The Value field of the leaf node is filled with the account status data corresponding to the account address; for example, the structure composed of the fields such as Balance, Nonce, Code, and storage can be encoded, and then filled into the Value field of the leaf node.

Further, the nodes on the MPT state tree are finally stored in the database in the form of Key-Value key-value pairs;

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

That is, when the node on the MPT state tree is stored in the database, the hash value of the data content contained in the node can be calculated (that is, hash calculation is performed on the entire node), and the calculated hash value can be used as the key. The data content contained in the node is used as value to generate a Key-Value key-value pair; then, the generated Key-Value key-value pair is stored in the database.

Because the node on the MPT state tree is stored as the key with the hash value of the data content contained in the node, and the data content contained in the node is stored as the value; therefore, when you need to query the node on the MPT state tree, you can usually The hash value of the contained data content is used as a key for content addressing.

In practical applications, whether it is a public chain, a private chain or a consortium chain, it is possible to provide the function of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain. Smart contracts can be defined in the form of code.

After the smart contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address; the contract code (Code) and account storage (Storage) will be stored in the account storage of the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, smart contracts create virtual accounts on the blockchain that contain contract code and account storage.

As mentioned above, the Data field containing the transaction that creates the smart contract can store the bytecode of the smart contract. Bytecode consists of a series of bytes, each of which can identify an operation. Based on development efficiency, readability and other considerations, developers can choose a high-level language to write smart contract code instead of writing bytecode directly. For example, high-level languages such as Solidity, Serpent, LLL, etc. may be used. For smart contract code written in a high-level language, it can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.

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

In the existing blockchain technology, the software version of the blockchain needs to be upgraded. Every time the version of the blockchain is upgraded, a new version of the blockchain needs to be released to replace the old version of the blockchain.

Since each version upgrade of the blockchain directly replaces the old version with the new version, there is no transition period in between, and all users of the blockchain are directly affected after the replacement. If there is an incompatibility between the old and new versions of the blockchain, errors will occur in transactions processed using the new version of the blockchain.

Therefore, how to discover the compatibility between the new version and the old version of the blockchain in advance is called an urgent problem to be solved in the industry.

In view of the above problems, this specification proposes a blockchain version compatibility verification scheme. Through this solution, it is possible to pre-verify whether there is a compatibility problem between the old and new versions before the new version is officially used.

Please refer to FIG. 1 , which is a flowchart of a method for verifying version compatibility of a blockchain provided by an exemplary embodiment. The method is applied to the target node device in the blockchain; wherein, the blockchain supports software version upgrade. After receiving the latest software version of the blockchain, instead of upgrading the blockchain version immediately, you can perform the following steps:

Step 210: Obtain the historical block to be verified, and read the transaction to be verified from the historical block.

The target node device can first obtain the historical block to be verified, and read the transaction to be verified from the historical block.

Wherein, the historical block may be a preset historical block or a historical block designated by a user.

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

Taking the historical block specified by the user as an example, the obtaining of the historical block to be verified may include:

Obtain the block number range corresponding to the historical block to be verified specified by the user;

The block number of the historical block to be verified is read from the block number interval, and the historical block corresponding to the block number is read from the block data of the blockchain maintained locally.

Wherein, the locally maintained block data of the blockchain is the block data pre-copied to the target node device. In order to ensure that the target node device can correctly obtain the historical blocks, it is necessary to synchronize the latest block data in the blockchain to the local of the target node device.

In an exemplary embodiment, the target node device includes a preset non-consensus node in the blockchain that does not participate in the consensus.

Generally, nodes in a blockchain can be divided into consensus nodes and non-consensus nodes, and the non-consensus nodes refer to blockchain nodes that do not perform consensus. Among them, consensus nodes are generally used to process transactions that require consensus; non-consensus nodes can 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 the historical block, and this list of transactions does not require consensus, so non-consensus nodes that do not participate in consensus can be used as target node devices. In this way, normal transactions will not be affected by occupying the resources of consensus nodes.

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

Step 220: Execute the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and execute the transaction based on the second software version supported by the blockchain to obtain a second transaction Results of the;

Wherein, the first software version may include the latest software version; the second software version may include the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, the Historical software versions supported by some node devices.

After reading the transaction to be verified, the target node device can 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:

Obtain the historical state data corresponding to the historical block from the historical state database corresponding to the blockchain; wherein, the historical state data corresponding to the historical block is set to a read-only state;

The initial account state corresponding to the blockchain account associated with the transaction is read from the historical state data corresponding to the historical block.

In this example, the transaction to be verified is executed again to verify the compatibility of the blockchain software version, which is not a normal transaction execution. Therefore, the result of executing the transaction in either the first software version or the second software version should not be recorded in the In the status data; otherwise it will cause 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 execution result is allowed to be recorded in the status data, then account A will actually transfer money to account B, but in fact account A does not initiate the transfer, resulting in a major mistake. In this way, by setting the historical state data corresponding to the historical block to a read-only state, it is possible to avoid updating the state data of the historical transaction after executing the transaction in step 220 .

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

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

Execute the transaction based on the first software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state and the updated account state based on the initial account state and the updated account state the first transaction receipt for the first software version;

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

Execute the transaction based on the second software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state based on the initial account state and the updated account state and a second transaction receipt for the second software version.

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

Before the matching of the first transaction execution result with the second transaction execution result, the method further includes:

The service port is called to locally store the generated first transaction receipt and the second transaction receipt.

In this example, the service port may record the transaction execution result in the form of a transaction receipt. Specifically, the transaction receipt can be stored in the MPT receipt tree.

It is worth mentioning that it is assumed that the execution of the transaction based on the first software version supported by the blockchain is called the first execution of the transaction; and the execution of the transaction based on the second software version supported by the blockchain Called the second execution of the transaction.

Then, after executing the transaction for the first time and obtaining the first transaction receipt, it is necessary to rollback the transaction executed for the first time, so as to restore the updated account state after the first execution of the transaction to the initial account state. The purpose of this is not to affect the state of the world.

Since the same transaction is executed the first time and the second time, usually the blockchain will update the account state involved in the transaction after the transaction is executed. If the transaction executed the first time is not rolled back, then the initial account state of the same transaction will be different on the second execution, and the result must be different. Therefore, through rollback, the first execution of the transaction does not affect the world state, and thus will not affect the execution result of the second executed transaction.

For example, suppose a transaction is that user A transfers 10 yuan to user B, the account balance of user A in the world state is 100 yuan (initial account state), and the account balance of user B is 50 yuan (initial account state).

Then, after the first execution, user A's account balance in the world state will become 90 yuan (update account state), and user B's account balance will become 60 yuan (update account state).

If it is not rolled back, then in the second execution, 10 yuan is transferred from user A's account balance of 90 yuan to user B's account balance of 60 yuan. Instead of the initial transfer of 10 yuan from user A's account balance of 100 yuan to user B's account balance of 50 yuan.

Therefore, it is necessary to roll back the transaction executed for the first time, so that the world state is maintained at user A's account balance of 100 yuan and user B's account balance of 50 yuan. In this way, the second execution is the same as the first execution, which is to transfer 10 yuan from user A's account balance of 100 yuan to user B's account balance of 50 yuan.

It is worth mentioning that there may be differences in version logic between the first software version and the second software version. Thus, different transaction receipts are generated when the first software version and the second software version perform the same transaction.

Still using the previous example, a transaction is that user A transfers 10 yuan to user B, the account balance of user A in the world state is 100 yuan, and the account balance of user B is 50 yuan. Among them, the new version of the blockchain needs to charge a handling fee of 1 yuan; the old version of the blockchain needs to charge a handling fee of 2 yuan.

Then, after executing the transaction for the first time, the first transaction receipt obtained is that 10 yuan is withdrawn from the account balance of user A of 100 yuan and transferred to the account balance of user B of 50 yuan. In addition, an additional handling fee of 2 yuan is withdrawn from the account balance 100 of user A. That is, user A's account balance remains 88 yuan, and user B's account balance is 60 yuan.

After the second transaction is performed, the second transaction receipt obtained is that 10 yuan is withdrawn from the user A's account balance of 100 yuan and transferred to the user B's account balance of 50 yuan. In addition, an additional handling fee of 1 yuan is withdrawn from the account balance 100 of user A. That is, user A's account balance remains 89 yuan, and user B's account balance is 60 yuan.

It can be seen that when the same transaction is executed through the first software version and the second software version respectively, the transaction receipts will be different due to the logical differences of the versions.

To solve this problem, the first software version and the second software version may be configured with forward compatible configuration files, the configuration files including logic for differences in the first software version and the second software version. This makes up for differences between software versions.

Specifically, when executing the transaction for the first time, the target node device may replace the logic that is different between the first software version and the second software version with the same logic based on the preconfigured configuration file. In this way, the configuration file is used to make up for the compatibility differences between the old and new versions, so that the same transaction will not be different due to version logic after executing the same transaction.

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

After obtaining the first transaction execution result and the second transaction execution result, the target node device matches the first transaction execution result with the second transaction execution result, so as to determine the first transaction execution result based on the matching result. Whether a software version is compatible with the second software version.

In an exemplary embodiment, the step 230 may include:

reading the first transaction receipt and the second transaction receipt recorded by the service port;

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

If the first transaction receipt matches the second transaction receipt, it is determined that the first software version is compatible with the second software version; otherwise, it is determined that the first software version is not compatible with the second software version .

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

In practical applications, when matching the read first transaction receipt and the second transaction receipt, the first root hash of the transaction receipt tree where the first transaction receipt is located can be obtained, and the The second root hash of the transaction receipt tree where the second transaction receipt is located; if the first root hash and the second root hash are consistent, it is confirmed that the first transaction receipt and the second transaction receipt match.

As mentioned above, the transaction receipt is located on the transaction receipt tree, and the transaction receipt tree is a Merkle tree. For a Merkle tree, the root hash is calculated by all the data hashes in the tree. Any difference in the hash of any data in the tree will affect the final root hash.

Therefore, after the same transaction is executed by the first software version and the second software version respectively, there should be the same transaction receipt tree, and thus should have the same root hash. If the root hashes of the two are inconsistent, then it can be determined that there is a compatibility problem between the two.

In this way, it is faster to compare the root hash of the transaction receipt tree directly without looking up the transaction receipt for the executed transaction from the transaction receipt tree.

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

By executing different transaction types in the embodiment shown in FIG. 1 , it can be determined what type of transaction has compatibility problems when executing what version of the blockchain.

For example, when the account creation transaction is executed, the transaction receipt is the same, but when the transfer is executed, the transaction receipt is different; then it can be determined that there is a compatibility problem with the version logic of the transfer in the new version.

In addition, when there are multiple historical blocks, the transaction types in different blocks can also be different, so it can be verified whether there is a compatibility problem between the blockchain software versions under different transaction types.

In an exemplary embodiment, when there are multiple historical blocks, the target node device may execute transactions with the first software version and execute transactions with the second software version in parallel under multi-threading.

In this example, in order to obtain the verification result quickly, transactions of different blocks can be executed in parallel under multi-threading; since the executed blocks do not affect each other, and the execution result does not affect the world state. It is equivalent to the isolation of each block, so this multi-threaded parallel execution is feasible and improves the verification speed.

In an exemplary embodiment, the blockchain supports grayscale upgrade of software versions; the second software version includes grayscale upgrade of the software versions supported by some node devices in the blockchain to all versions. The historical software versions supported by some node devices before the latest software version.

Correspondingly, before the step 210, it may also include:

In response to the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, the historical block to be verified is obtained, and the transaction to be verified is read from the historical block.

In this example, the grayscale upgrade may refer to a smooth transition upgrade manner. In the grayscale upgrade process, A/B testing is used first, that is, some users continue to use the historical software version, and some users start to use the latest software version; if users have no objection to the latest software version, then gradually expand the latest software version. Using scope, slowly migrate all users to the latest software version.

The grayscale upgrade method can ensure the stable operation of the overall blockchain. Problems can be found and dealt with in time during the initial grayscale upgrade. Since the initial grayscale upgrade has fewer user groups, even if the problem occurs, the impact scope is limited.

In an exemplary embodiment, if it is determined that the latest software version is compatible with the historical software version, an upgrade instruction is sent to the service platform corresponding to the blockchain to trigger the service platform to update the part of the node devices. The supported software version is upgraded 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 Blockchain as a Service (BaaS, Blockchain as a Service). The BaaS platform can target client-side computing devices coupled to the BaaS platform by providing pre-written software for activities that take place on the blockchain, such as subscriptions and notifications, user authentication, database management, and remote updates. Simple and easy to use, one-click deployment, fast verification, flexible and customizable blockchain services, which can accelerate the development, testing, and launch of blockchain business applications, and help the implementation of blockchain business application scenarios in various industries.

Corresponding to the above method embodiments, this specification also provides an embodiment of a blockchain version compatibility verification device.

The embodiments of the blockchain version compatibility verification apparatus of this specification can be applied to electronic equipment. The apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, a device in a logical sense is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the electronic device where the device is located.

From the perspective of hardware, as shown in Figure 2, it is a hardware structure diagram of the electronic device where the blockchain version compatibility verification device of this specification is located, except for the processor, memory, network interface, and non-volatile hardware shown in Figure 2. In addition to the volatile memory, the electronic device in which the apparatus in the embodiment is located generally may also include other hardware according to the actual function of the electronic device, which will not be repeated here.

FIG. 3 is a block diagram of a block chain version compatibility verification apparatus shown in an exemplary embodiment of the present specification.

Please refer to FIG. 3 , the blockchain version compatibility verification device can be applied to the electronic equipment shown in the aforementioned FIG. 2 , and the device is applied to the target node device in the blockchain; wherein, the block The chain supports software version upgrades; the device includes:

The obtaining unit 310 obtains the historical block to be verified, and reads the transaction to be verified from the historical block;

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

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 execution unit 320, it further includes:

The data acquisition subunit acquires the historical state data corresponding to the historical block from the historical state database corresponding to the blockchain; wherein, the historical state data corresponding to the historical block is set to a read-only state ; Read the initial account state corresponding to the blockchain account related to the transaction from the historical state data corresponding to the historical block.

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

The execution unit 320 further includes:

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

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

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

Before the verification unit 330, it also includes:

The calling unit calls the service port to locally store the generated first transaction receipt and the second transaction receipt.

Optionally, the verification unit 330 further includes:

a reading subunit, to read the first transaction receipt and the second transaction receipt recorded by the service port;

a matching subunit, which matches the read first transaction receipt and the second transaction receipt;

A determination subunit, if the first transaction receipt matches the second transaction receipt, determine that the first software version is compatible with the second software version; otherwise, determine that the first software version is compatible with the second software version Incompatible software version.

Optionally, the obtaining unit 310 further includes: obtaining the block number interval corresponding to the historical block to be verified specified by the user, and reading the block number of the historical block to be verified from the block number interval , and read the historical block corresponding to the block number in the block data of the block chain maintained locally.

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

Optionally, the blockchain supports grayscale upgrade of software versions; the first software version includes the latest software version; the second software version includes software that supports some node devices in the blockchain. The version is the historical software version supported by some node devices before the grayscale upgrade is to the latest software version.

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

The response unit, in response to the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, obtains the historical block to be verified, and reads the historical block to be verified from the historical block. trade.

Optionally, the device further includes:

The processing unit, if it is determined that the latest software version is compatible with the historical software version, sends an upgrade instruction to the service platform corresponding to the blockchain, so as to trigger the service platform to change the software version supported by the part of the node device from the The historical software version is upgraded to the latest software version.

Optionally, the service platform includes a Bass platform.

Optionally, the target node device includes a preset non-consensus node in the blockchain that does not participate in the consensus.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control desktop, tablet, 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.

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

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Flash Memory or other memory technology, Compact Disc Read Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or which are inherent to such a process, method, article of manufacture, or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

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

It will be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the protection scope of one or more embodiments of this specification.

Claims (14)

1. A block chain version compatibility verification method, the method is applied to a target node device in the block chain; wherein, the block chain supports software version upgrade; the method comprises: Obtain the historical block to be verified, and read the transaction to be verified from the historical block; Execute the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and execute the transaction based on the second software version supported by the blockchain to obtain a second transaction execution result; The first transaction execution result is matched with the second transaction execution result, and based on the matching result, it is determined whether the first software version is compatible with the second software version. 2. The method according to claim 1, executing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and, based on the second software version supported by the blockchain Before the software version executes the transaction and obtains the execution result of the second transaction, it further includes: Obtain the historical state data corresponding to the historical block from the historical state database corresponding to the blockchain; wherein, the historical state data corresponding to the historical block is set to a read-only state; The initial account state corresponding to the blockchain account associated with the transaction is read from the historical state data corresponding to the historical block. 3. The method according to claim 2, wherein the transaction execution result comprises a transaction receipt generated after executing the transaction; performing the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; Execute the transaction based on the first software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state and the updated account state based on the initial account state and the updated account state the first transaction receipt for the first software version; The execution of the transaction based on the second software version supported by the blockchain to obtain a second transaction execution result includes: Execute the transaction based on the second software version supported by the blockchain, generate an updated account state corresponding to the initial account state, and generate the transaction corresponding to the initial account state based on the initial account state and the updated account state and a second transaction receipt for the second software version. 4. The method according to claim 3, wherein the target node device is equipped with a service port for recording transaction execution results; Before the matching of the first transaction execution result with the second transaction execution result, the method further includes: The service port is called to locally store the generated first transaction receipt and the second transaction receipt. 5. The method of claim 4, said matching said first transaction execution result with said second transaction execution result, and determining said first software version and said first software version based on said matching result. Whether the second software version is compatible, including: reading the first transaction receipt and the second transaction receipt recorded by the service port; matching the read first transaction receipt and the second transaction receipt; If the first transaction receipt matches the second transaction receipt, it is determined that the first software version is compatible with the second software version; otherwise, it is determined that the first software version is not compatible with the second software version . 6. The method according to claim 1, the acquisition of the historical block to be verified comprises: Obtain the block number range corresponding to the historical block to be verified specified by the user; The block number of the historical block to be verified is read from the block number interval, and the historical block corresponding to the block number is read from the block data of the blockchain maintained locally. 7 . The method according to claim 6 , wherein the locally maintained block data of the blockchain is the block data copied to the target node device in advance. 8 . 8. The method according to claim 1, wherein the blockchain supports grayscale upgrade of software versions; the first software version includes the latest software version; the second software version includes Before the software version supported by some node devices is grayscale upgraded to the latest software version, the historical software version supported by the part of the node devices. 9. The method according to claim 8, before the acquiring the historical block to be verified and reading the transaction to be verified from the historical block, further comprising: In response to the grayscale upgrade of the software version supported by some node devices in the blockchain to the latest software version, the historical block to be verified is obtained, and the transaction to be verified is read from the historical block. 10. The method of claim 9, further comprising: If it is determined that the latest software version is compatible with the historical software version, send an upgrade instruction to the service platform corresponding to the blockchain, so as to trigger the service platform to transfer the software versions supported by the part of the node devices to the historical software The version is upgraded to the latest software version described. 11. The method of claim 10, the service platform comprising a Bass platform. 12. The method according to claim 1, wherein the target node device comprises a preset non-consensus node in the blockchain that does not participate in consensus. 13. A blockchain version compatibility verification device, the device is applied to a target node device in the blockchain; wherein the blockchain supports software version upgrade; the device comprises: an acquisition unit that acquires the historical block to be verified, and reads the transaction to be verified from the historical block; an execution unit that executes the transaction based on the first software version supported by the blockchain to obtain a first transaction execution result; and executes the transaction based on the second software version supported by the blockchain to obtain a second transaction Results of the; A verification unit that 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. 14. An electronic device comprising: processor; memory for storing processor-executable instructions; Wherein, the processor implements the method of any one of claims 1-12 by executing the executable instructions.

Images