CN115454475A

CN115454475A - Method and device for detecting compatibility of contract upgrading

Info

Publication number: CN115454475A
Application number: CN202211117310.2A
Authority: CN
Inventors: 曹蓉
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-09-14
Filing date: 2022-09-14
Publication date: 2022-12-09
Also published as: WO2024055437A1

Abstract

One or more embodiments of the present specification provide a method and an apparatus for detecting compatibility of contract upgrading, and a client, which are applied to the field of block chaining. A method of detecting compatibility of a contract upgrade, comprising: generating abstract syntax trees of contracts before and after upgrading; analyzing the generated abstract syntax trees, and sequentially extracting basic information in node information of each abstract syntax tree; and comparing the basic information in the node information of the abstract syntax tree before and after upgrading to obtain a compatibility conclusion.

Description

Method and device for detecting compatibility of contract upgrading

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a method and a device for detecting compatibility of contract upgrading.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

Disclosure of Invention

The invention aims to provide a method and a device for detecting contract upgrading compatibility, which comprises the following steps:

a method of detecting compatibility of a contract upgrade, comprising:

generating abstract syntax trees of contracts before and after upgrading;

analyzing the generated abstract syntax tree, and sequentially extracting basic information in node information of each abstract syntax tree;

and comparing the basic information in the node information of the abstract syntax tree before and after upgrading to obtain a compatibility conclusion.

A contract upgrade compatibility detection apparatus comprising:

the abstract syntax tree generating unit is used for generating abstract syntax trees of contracts before and after upgrading;

the extraction unit is used for analyzing the generated abstract syntax trees and sequentially extracting basic information in the node information of each abstract syntax tree;

and the comparison unit is used for comparing the basic information in the node information of the abstract syntax tree before and after upgrading to obtain a compatibility conclusion.

A client, comprising:

a processor for processing the received data, wherein the processor is used for processing the received data,

a memory storing a program, wherein the above method is performed when the processor executes the program.

The updated contract writing method needs to meet certain specifications to enable compatibility before and after updating, namely, the state in the updated new contract needs to maintain the capability of reading the value of the same state in the old contract. When a user writes an upgraded contract, the specifications are often ignored, so that the upgraded contract has serious problems of data loss, confusion and the like. By the above example, a contract upgrade storage data compatibility detection scheme based on the type of policy and the like of the abstract syntax tree can be realized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a schematic diagram of deploying an intelligent contract in an embodiment;

FIG. 2 is a schematic diagram of invoking an intelligent contract in one embodiment;

FIG. 3 is a diagram of a block memory structure according to an embodiment;

FIG. 4 is a diagram of a block memory structure according to an embodiment;

FIG. 5 is a schematic diagram of an MPT tree in one embodiment;

FIG. 6 is a diagram illustrating the relationship of modules and CPUs, memory and disks involved in the transaction processing in one embodiment;

FIG. 7 is a schematic diagram of an EVM virtual machine module involved in transaction processing in one embodiment;

FIG. 8 is a schematic diagram of a slot structure in one embodiment;

FIG. 9 is a schematic diagram of a slot structure in one embodiment;

FIG. 10 is a flow diagram of a method of detecting compatibility of a contract upgrade in one embodiment;

FIG. 11 is a schematic diagram of a slot structure in one embodiment;

FIG. 12 is a schematic diagram of a slot structure in one embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of associations, such as private chain + federation chain, federation chain + public chain, and so on. The most decentralized of these is the public chain. Participants joining the public chain can read the data records on the chain, participate in transactions, compete for accounting rights for new blocks, etc. Furthermore, each participant (embodied as a node of the participant on the blockchain) can freely join and leave the network, and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. Briefly, a private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. The federation chain is a block chain between the public chain and the private chain, and can implement "partial decentralization". Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, in addition to supporting native assets on inter-account transfer blockchains, the functionality of intelligent contracts may be provided. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Intelligent contracts support users creating and invoking some complex logic in blockchain networks, which is the biggest challenge for programmable blockchains to distinguish from the original blockchain technology. At the heart of a programmable blockchain is a virtual machine (EVM), each blockchain node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking the intelligent contracts in the blockchain is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the blockchain network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0x6f8ae93 \8230" in fig. 1 represents the address of this contract, the data field of the transaction holds what may be a bytecode, and the to field of the transaction is an empty account. After the agreement is achieved between the nodes through the consensus mechanism, the contract is successfully created, and the subsequent user can call the contract.

After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code and the account storage are stored in the contract account. The behavior of an intelligent contract is controlled by contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, an intelligent contract causes a virtual account to be created on a blockchain that includes contract code and an account store (Storage).

As mentioned above, the data field containing the transaction that created the smart contract holds what may be the byte code of the smart contract. A bytecode consists of a series of bytes, each of which may 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. The intelligent contract code written by the high-level language is compiled by a compiler to generate byte code, and the byte code can be deployed on a block chain. The high-level languages supported by the blockchain are many, such as Solidity, serpent, LLL, and the like.

Taking the Solidity language as an example, the contract written by the method is similar to a Class (Class) in an object-oriented programming language, and various members including state variables, functions, function modifiers, events and the like can be declared in one contract. A state variable is a value stored in the account storage of an intelligent contract to preserve the state of the contract.

The following code example 1 is a simple intelligent contract written in the Solidity language:

code example 1.SimpleStorage code

In code example 1 above, line 2 declares the state variable storedData of the character type (string) and line 3 declares the event (event) which stores the initiator address and string s that called the contract. Lines 4-7 define a set function, with the reference being the string s. The operation performed by the set function includes setting an entry to the state variable storedData, producing an event whose contents include the initiator address and string s that called the contract.

As previously mentioned, the state variables will eventually be stored in the database. The events generated are generally of the form:

[topic1][topic2]...[topicn][data]

here, the first topic, i.e. topic1, is generally a default value, for example, an identifier of a receipt, and may be a hash value obtained after sequential concatenation of an event name, an event parameter type, and the like. Each topic 2-topicn exists or not, depending on whether an Indexed embellishment is added when defining a parameter, if so, the value of the parameter will be one topic in the receipt, and the topic without the Indexed embellishment is generally put into the data. In the example of code example 1 above, when an event is declared on line 3, both parameters address from and s, without Indexed embellishments, are typically placed in the data. The code of line 6, sets the data content [ msg.sender, s ] in the event by the stored () event. Thus, for the event of line 6 operation, overall the form is:

[ topoic 1: event identification ] [ data: msg.sender, s ]

Lines 8-10 define the get function. The operation of this function includes returning the value of the storedData of the query. returns (string) indicates the type of value returned, and the constant modifier identifies that the function cannot modify the value of the state variable in the contract.

In addition, as shown in fig. 2, after Bob sends a transaction containing the invoked smart contract information to the blockchain network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account from which the intelligent contract was initiated, and the to field is "0x6f8ae93 \8230," which represents the address of the intelligent contract being invoked, and the data field of the transaction holds the methods and parameters for invoking the intelligent contract. In addition, a value field may be included to indicate the value of the ethernet currency in the transaction. After invoking the smart contract, the value of storedData may change. Subsequently, a client can view the current value of storedData through a blockchain node (e.g., node 6 in FIG. 2).

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored in the blockchain, and therefore when the transaction is completed, transaction certificates which cannot be tampered and lost are stored in the blockchain.

As previously mentioned, storedData in the above example is a state variable that is stored in the account store of the smart contract. In various block chain networks that incorporate intelligent contracts, typically accounts can include two types:

contract account (contract account): storing the executed intelligent contract code and the value of the state in the intelligent contract code, wherein the intelligent contract code can be usually only activated by an external account call;

external account (Externally owned account): the user's account, such as an ethereal owner account.

The design of the external account and the contract account is actually a mapping of the account address to the account status. The status of an account typically includes fields such as Nonce, balance, storage root, codeHash, etc. Nonce, balance exist in both external and contract accounts. The CodeHash and Storage root attributes are generally only valid on contract accounts.

The nonces: a counter. For an external account, this number may represent the number of transactions sent from the account address; for a contract account, it may be the number of contracts that the account creates.

Balance: the number of ethercoins this address owns.

Storage root: a hash of a root node of an MPT tree that organizes the storage of state variables for the contract account.

CodeHash: a hash value of the intelligent contract code. For contract accounts, this is the hash value of the intelligent contract; for external accounts, the CodeHash field may typically be an empty string/all 0 string since no smart contract is included.

MPT is known as Merkle Patricia Tree, and is a Tree structure combining Merkle Tree and Patricia Tree (compressed prefix Tree, a more space-saving Trie Tree, dictionary Tree). The Merkle Tree algorithm calculates a Hash value for each transaction, and then calculates the Hash again by connecting two by two until the top-most Merkle root. Some blockchain networks employ an improved MPT tree, e.g., a structure of 16-way trees, also commonly referred to as MPT trees for short.

The data structure of the MPT tree includes a state tree (state trie). The state tree includes key-value pairs (also written as key-values, k-v or kv) of storage contents corresponding to each account in the block chain network. A "key" in the state tree may be a 160bits identifier (e.g., an address of a blockchain account or a portion of a hash value of an address, hereinafter collectively referred to as an account address) of the state tree, which account address is distributed in the store starting from the root node to the leaf nodes of the state tree. The "value" in the state tree is generated by encoding the information of the blockchain account using a Recursive-Length dictionary encoding (RLP) method. As previously mentioned, for external accounts, values include nonce and balance; for contract accounts, values include nonce, balance, codehash, and storageroot.

The contract account is used to store intelligent contract-related state. After the intelligent contract is deployed on the block chain, a corresponding contract account is generated. This contract account will typically have states that are defined by state variables in the intelligent contract and that generate new values when the intelligent contract executes. The intelligent contract generally refers to a contract defined in a block chain environment in the form of code that can automatically execute terms. The code may be executed automatically as soon as an event triggers a term in the contract (execution condition is met). In the blockchain, the relevant state of the contract is stored in the storage trie, and the hash value of the root node of the storage trie is stored in the storage root, so that all the states of the contract are locked under the contract account through the hash. A storage trie is also an MPT tree structure that stores a key-value mapping of state addresses to state values. After being sequentially arranged from a root node to a leaf node of the storage trie, part of information is used for storing the address of a state, and the leaf node stores the value of the state.

In some blockchain data stores such as that shown in fig. 3, the Block header of each Block includes fields such as the previous Block Hash previous _ Hash (Prev Hash in the figure), random number Nonce (this Nonce is not a random number in some blockchain systems or the Nonce in the Block header is not enabled in some blockchain systems), timestamp, block number Block Num, state Root Hash State _ Root, transaction Root Hash _ Root, receipt Root Hash record _ Root, etc. The Prev Hash in the header of the next block (e.g., block N + 1) points to the previous block (e.g., block N), which is the Hash value of the previous block. In this way, the block chain realizes the locking of the next block to the previous block through the block head. Wherein State _ Root, transaction _ Root, and Recepti _ Root lock the State set, the Transaction set, and the Receipt set, respectively. The set of states, transactions and receipts organize the states, transactions and receipts in a tree, respectively. In general, the tree structures may be the same or different. For example, in the above-described blockchain network using the MPT structure, the same MPT structure is used. In some tree structures that include a state set of a smart contract, an MPT structure includes two levels: leaf nodes of the MPT structure at the upper level comprise two types of external accounts and contract accounts; each contract account comprises the MPT structure of the next level, and the leaf nodes of the next level comprise the values of the states in the contract accounts.

Fig. 4 is a schematic diagram of a block chain data storage structure. As can be seen in connection with fig. 3, the state _ root is a hash value of the root of the MPT tree composed of the states of all accounts in the current block, i.e. a state tree state trie in the form of an MPT pointing to the state _ root. The root Node of the MPT tree is typically an Extension Node (Extension Node) or a Branch Node (Branch Node), and the state _ root stores a hash value of the root Node. The root Node may be connected to one or more layers of Extension nodes/Branch nodes below, and these multiple layers of tree nodes may be collectively referred to as intermediate nodes (Internal nodes). The account address can be formed by sequentially and serially connecting a part of values from the root node of the MPT to each node in the leaf nodes, and the account information stored in the leaf nodes is the value corresponding to the account address, so that a key-value key value pair is formed. This key may also be a part of sha3 (Address), that is, a part of a hash value of the Account Address (the hash algorithm adopts, for example, sha3 algorithm), and the value stored therein may be rlp (access), that is, an rlp code of the Account information. The account information is a quadruple formed by [ nonce, balance, storageRoot, codeHash ]. As previously mentioned, for external accounts, there are typically only two terms, nonces and balance, while the storageRoot, codeHash fields store the empty/all 0 strings by default. That is, the external account does not store the contract, nor the generated state variables after the contract execution. Contract accounts typically include Nonce, balance, storage root, codeHash. Wherein the Nonce is a transaction counter for the contract account; balance is the account Balance; the Storage root corresponds to another MPT and can be linked to the information of the contract-related state; the CodeHash is the hash value of the contract code. Whether an external account or a contract account, the account information is typically located in a single Leaf Node (Leaf Node). From the Extension Node/Branch Node of the root Node to the Leaf Node of each account, several Branch nodes and Extension nodes may be passed in the middle.

A state trie may be a tree of MPT form, typically a 16-way tree, i.e., there may be up to 16 child nodes per layer. For Extension nodes, for storing a common prefix, there are typically 1 child Node, which may be a Branch Node. For a Branch Node, there may be up to 16 child nodes, which may include Extension nodes and/or Leaf nodes.

Wherein, for one contract account in the state trie, its storage _ Root points to another tree, which is also in the form of MPT, in which data of state variables (state variables) involved in contract execution are stored. The tree in MPT form pointed by Storage _ Root is Storage Trie, i.e. the hash value of the Root node of Storage Trie. Typically, this Storage Trie tree stores key-value pairs as well. The key indicates the address of the state variable, and the value of the key may be the result of processing the position (value counted from 0) of the state variable declaration in the contract by a certain rule, such as sha3 (position of state variable declaration) or sha3 (position of contract name + state variable declaration). value is used to store the value of the state variable (e.g., an RLP-encoded value). A part of data stored on a path from the root node to the leaf node through the intermediate node are connected to form a key, and the leaf node stores value. As mentioned above, this Storage trie may also be a tree in the form of MPT, and typically a 16-way tree, i.e., for a Branch Node, there may be up to 16 child nodes, which may include extensions nodes and/or Leaf nodes. For Extension Node, there may be 1 child Node in general, and this child Node may be Branch Node or Leaf Node.

Such as Leaf Node Account P of state Trie in fig. 4, which is a contract Account whose Storage Root locks all states in the contract store. These states are organized as MPT trees, tree structures like the Storage trie to which the Storage Root is linked. In this linked Storage trie, taking a Leaf Node State Variable N as an example, for example, the value of stored data in the aforementioned contract code example, its key is sha3 (the declaration position of stored data, which will be described later in detail), and its value is s (for brevity, the coding format of value, such as RLP, is omitted here, and the description is omitted here for brevity. Wherein, the value of the key is distributed in the root Node to the Leaf Node (i.e. Leaf Node Variable N) of the storage Trie in sequence.

For another example, the Account C of the Leaf Node in the state Trie in fig. 4 is an external Account, and its key is sha3 (Address C), that is, a hash value of the Address of the Account C (the hash algorithm adopts, for example, the sha3 algorithm), and its stored value may be (Account), where the Account information Account is a binary group formed by [ nonce, balance ]. As described above, since Account C is an external Account, the Account information thereof is both nonce and balance (codehash and storage root are omitted here, and the following is similar). For example, if an external account has a nonce of 20 and a balance of 4550, then the Leaf Node State Variable C stores nonce =20 and balance =4550 in the Leaf Node. The address of Account C is key, and the value thereof is distributed in the root Node to the Leaf Node (i.e. Leaf Node Variable C) of the state Trie in sequence.

These states, including k-v for external accounts and k-v for contract accounts, are ultimately stored in a database. The storage in the database does not directly store the state of these accounts, i.e., the k-v of these accounts, but rather the k-v value of each tree node itself.

As shown in the example of fig. 5, in the MPT structure at the upper stage, for the leaf Node A1, a key of the leaf Node is formed by sequentially combining A7 of a shared neighbor in the root Node A8 (Extension Node), slot 1 of the intermediate Node A7 (Branch Node), and key-end 1335 in the leaf Node A1, that is, a711335, and Balance =45.0eth and nonce = n1 are stored in the leaf Node. For the leaf Node A2, the key of the leaf Node is formed by sequentially combining A7 of the shared Node in the root Node A8 (Extension Node), slot 7 of the middle Node A7 (Branch Node), d3 of the shared nodes in the Node A6 (Extension Node), slot 3 of the middle Node A5 (Branch Node), and 7 of the key-end in the leaf Node A2, namely, a77d337, and Balance =1.00wei and nonce = n2 is stored in the leaf Node. For the leaf Node A3, a key of the leaf Node is formed by sequentially combining A7 of a shared neighbor in a root Node A8 (Extension Node), a slot f of an intermediate Node A7 (Branch Node), and a 9365 of a key-end in the leaf Node A3, namely, A7f9365, and Balance =1.1eth and nonce = n3 are stored in the leaf Node. For the leaf Node A4, A7 of the shared nib in the root Node A8 (Extension Node), a slot 7 of the intermediate Node A7 (Branch Node), d3 of the shared nibbles in the Node A6 (Extension Node), a slot 9 of the intermediate Node A5 (Branch Node), and 7 of the key-end in the leaf Node A4 are sequentially combined to form a key of the leaf Node, i.e., a77d397, and Balance = 0.21eth, nonce = n4, codehash = c1, and storage root = s1 is stored in the leaf Node. s1 may be H (A10), the hash of the root node A10 of the next level tree. The leaf nodes of A1, A2 and A3 store information of the external account, and the leaf node of A4 stores information of the contract account. For a contract account, which contains the next-level MPT, a Storage Trie is formed for storing state variables in the contract account.

As shown in the example of fig. 5, in the MPT structure at the next stage, for a leaf Node a11, a key forming the leaf Node is sequentially combined by slot 3 in the root Node a10 (Branch Node) -35 b2e4 of key-end in the leaf Node a11, that is, 335b2e4, and "zhangsan _ a =20" is stored in the leaf Node, for example, it indicates that the share of a type digital asset defined in the contract to zhangsan is 20, that is, the balance of a type a asset of zhangsan is 20. For the leaf Node a12, the slot position 7 in the root Node a10 (Branch Node) -c 25988 of the key-end in the leaf Node a12 are sequentially combined to form the key of the leaf Node, that is, 7c25988, and "listra _ B =20" is stored in the leaf Node, for example, it indicates that the share of the B-type digital asset defined in the contract belonging to listra is 50, that is, the balance of the B-type asset of listra is 50. For the leaf Node a15, a key of the leaf Node, that is, fa6be33 is formed by sequentially combining a slot f in the root Node a10 (Branch Node), a of a shared neighbor in the intermediate Node a13 (Extension Node), a slot 6 of the intermediate Node a14 (Branch Node), and a key-end be33 in the leaf Node a15, and "stored data = s" is stored in the leaf Node. For the leaf Node a16, sequentially combining a slot f in the root Node a10 (Branch Node), a of a shared ribbon in the intermediate Node a13 (Extension Node), a slot 9 of the intermediate Node a14 (Branch Node), and a key-end 9365 in the leaf Node a16 to form a key of the leaf Node, that is, fa99365, and storing "wangwua _ a =35" in the leaf Node, for example, indicating that the share of the type a digital asset defined in the contract belonging to wangwuwu is 35, that is, the balance of the type a asset of wangwuwu is 35.

In the above-described Node configuration of the MPT tree, the tree Node type is represented by prefix, for example, 0 represents an Extension Node including an even number of shared nibbles (shared nibbles), 1 represents an Extension Node including an odd number of shared nibbles(s), 2 represents a Leaf Node including an even number of nibbles(s), and 3 represents a Leaf Node including an odd number of nibbles(s).

In the above node structure, the hash value of the whole content of the next tree node is filled in the corresponding position of the previous tree node. In the database, a key-value mapping of each tree node is actually stored, wherein the value includes the content stored in the tree node, and the corresponding key is a hash value of the whole content of the tree node. Thus, the actual stored tree nodes k-v in the database are as follows:

TABLE 1 actual stored Tree nodes k-v in database

In table 1 above, hash calculation is represented by H (). Thus, the hash value of the next tree node is anchored in the previous tree node. Through the layer hash, the root hash of the whole state trie tree is obtained, and the root hash is locked in the state root field of the block header.

In some blockchain systems, the code of the blockchain platform may include P2P (Peer-to-Peer) modules, consensus modules, execution modules, and storage modules. P2P is a way of building a computer network, and unlike a common web network, P2P is decentralized and decentralized. The P2P module may perform distributed propagation of data. For blockchain nodes, data may be propagated and received in a point-to-point manner by the P2P modules. Different participants can establish a distributed block chain network through the deployed nodes (nodes). The ledger constructed by using the chained block structure is stored on each node (or on most nodes, such as a common node) in the distributed blockchain network, which is also called decentralized (or multi-centralized) distributed ledger. Such a blockchain system needs to address the issue of consistency and correctness of the respective ledger data across multiple nodes that are decentralized (or multicentric). The same blockchain platform program is run on each node, and under the design of certain fault-tolerant requirements, all the loyalty nodes can be ensured to have the same transaction through the consensus module, so that the execution results of all the loyalty nodes for the same transaction are ensured to be consistent, and the transaction and the execution results are packaged to generate a block. The current mainstream consensus mechanisms include: proof of Work (POW), proof of stock (POS), proof of commission rights (DPOS), practical Byzantine Fault Tolerance (PBFT) algorithm, badger Byzantine Fault Tolerance (honeybadger bft) algorithm, and the like. In the consensus process, the consensus module may generally generate a timestamp of the block corresponding to the current transaction set. The execution module may execute transactions, including normal transfer transactions and transactions involving contracts, either before or after the consensus module completes the consensus. For the transaction related to the contract, the execution module may introduce a Virtual Machine, such as an Ethernet Virtual Machine (EVM), to execute the code of the intelligent contract, so as to shield the difference between the hardware configuration and the software environment of each node through the EVM, to ensure that the process and the result of executing the intelligent contract on each node are the same, and to avoid the execution of the intelligent contract from affecting the blockchain platform code, other programs, or the operating system on the host through the sandbox environment. For a situation of a federation chain, the nodes can determine transaction contents and transaction sequences in a transaction set through a consensus module, and then output a deterministic transaction set of consensus results to an execution module. The execution module generates an execution result by executing a general transfer transaction/a contract-related transaction, and transmits the execution result to the storage module. The storage module may be responsible for storing the execution results in a persistent storage medium local to the node.

A blockchain node shown in fig. 6 physically includes a CPU, a memory, a disk, and the like. The blockchain platform code executed by the blockchain node may include a P2P module, a consensus module, an execution module, and a storage module. The P2P module, the consensus module and the execution module generally need the participation of CPU and memory. The storage module may include a build tree module, a block header generation module, a WAL (Write Ahead Log) module, and a status database module. The tree building module is configured to build a tree (e.g., an MPT tree) based on a state k-v (e.g., an MPT tree) transmitted by the execution module, such as the aforementioned state trie and storage trie, so as to obtain k-v of a tree node, which generally requires participation of a CPU and a memory. The block header generation module is configured to generate a block header according to a root node of the tree constructed by the tree construction module and some other data (such as the hash of the previous block, the timestamp, the block number, and the like), and generally needs to participate in a CPU and a memory. Before the WAL module is used for writing the tree nodes k-v generated by the tree building module into the state database module, the tree nodes k-v generated by the tree building module are stored persistently to prevent data loss caused by power failure and the like in the process of writing the tree nodes k-v generated by the tree building module into the state database module, and data recovery is generally required when the situation occurs, namely, the participation of a CPU, a memory and a disk is required. The state database module is used for storing the tree nodes k-v constructed by the tree construction module in the table 1 on a persistent storage device; since the tree node data will eventually be written to a persistent storage medium (e.g., disk in the figure), the state database module typically requires disk involvement in addition to CPU, memory.

In terms of storage structure, the Merkle Tree structure, such as the SMT (Sparse Merkle Tree) of MPT and Libra described above, is located in the building Tree module in the form of the correspondence relationship in table 1 and is stored in the memory. The Merkle tree at the upper layer is a prefix tree (dictionary tree), so that the data can be organized, and a unique Merkle root can be obtained for the organized data. The leaf nodes may hold the state Value, and the root node implements a lexicographic index of the state key from the intermediate node to the leaf node. These tree nodes are encoded into Key and Value according to a certain rule, and finally stored in the lower database. Most databases adopt a NoSQL Key-Value DB (DataBase; key-Value DB is also abbreviated as KVDB) with an LSM (Log-Structured Merge-Tree) type structure, are located in a state DataBase module and are stored in a disk. Specifically, the database is, for example, levelDB, rocksDB by Libra. Both of these KVDBs are based on LSM storage engines.

As mentioned above, the transaction that created the smart contract is sent to the blockchain, and after consensus, the blockchain nodes can execute the transaction. A contract account (including, for example, the Identity of the account, the hash value Codehash of the contract, and the root StorageRoot of the contract store) corresponding to the intelligent contract appears on the time zone block chain, and has a specific address, and the contract code and the account store may be stored in the store (store) of the contract account, as shown in fig. 7. 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, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage). For contract deployment transactions or contract update transactions, the value of the Codehash will be generated or altered. Subsequently, the block link point may receive a transaction request that invokes the deployed smart contract, which may include the address of the invoked contract, the function in the invoked contract, and the parameters of the input. Generally, after the transaction request is identified, each node of the blockchain can independently execute the intelligent contract for the designated call.

On the left side of fig. 7 is an example of an intelligent contract written in solid and its compiled and executed process. The intelligent contract is compiled (build) by a compiler (compiler) to generate byte codes (bytecodes). The solc in the figure is a solidity command line compiler, and an intelligent contract written by solidity can be compiled by a command line tool solc with parameters, so that byte codes which can run in an EVM are generated. Through the process of deploying contracts in fig. 1 and fig. 2, intelligent contracts can be successfully created on the blockchain. After the contract is deployed, a contract account corresponding to the intelligent contract is generated on the block chain, and the contract account comprises, for example, a contract counter Nonce, a Balance of the account, a hash value Codehash of a contract bytecode, a root StorageRoot of the contract storage, and the like. The contract will have a specific address on the chain, i.e. the contract address.

This contract address is calculated, for example, by hashing the address of the external account on which the contract is to be deployed together with its counter nonce. Specifically, for example, sha3 (rlp. Encode ([ address _ sender, nonce ])) (rlp is a coding format as described above, and other coding formats can be used instead of, or even re-coded, in different block chains, so that rlp is omitted later). Where sha3 is a type of hash algorithm, such as the commonly used keccak256 algorithm. The rlp indicates an encoding format as described above, and the entry indicates that the content in the parentheses is rlp encoded. The [ address _ sender, nonce ] in the parenthesis indicates that the two fields address _ sender and its counter nonce of the external account deploying the contract are sequentially concatenated. For example, by using the keccak256 algorithm, a hash value with a length of 256bits can be obtained, and an address (for example, the first 20 bytes) of the deployed contract on the block chain can be obtained according to the hash value. 256bits is also 32bytes. The Balance of the account may be set to a default value of 0 or 0 upon completion of deployment. The hash value Codehash of the contract bytecode may be obtained by performing hash calculation on the contract bytecode by the block chain platform. The root storage root of the contract storage can be a default value or a hash value calculated according to the root node of the lower-layer storage Trie. This generally depends on whether an initialization operation, such as executing a constructor in a contract, will be performed in the deployed contract. If the constructor is included in the deployed contract, it typically includes the work of initializing some state variables that will eventually be stored in the underlying database, and this initialization work may be performed in the virtual machine. After initialization, as described above, the state variable may construct an MPT tree, so as to obtain a root node of the MPT tree, and further obtain a hash value of the root node. If the deployed contract does not contain a constructor, no specific function may be executed, but the blockchain platform assigns a default value to the StorageRoot, for example, a hash value of empty content.

After the contract is deployed, it may be subsequently invoked, as previously described. After Bob initiates a transaction to the blockchain network invoking an intelligent contract as shown in fig. 2, the contract executes, setting the state variable to the "hello" string. Similarly in fig. 2, alice initiates a transaction to invoke a contract, reading the value of the state variable through execution of the contract.

It was also mentioned previously that intelligent contracts typically define contracts in the form of code in a blockchain environment that are capable of automatically executing terms. The terms therein are generally related to the logic of the business level. Thus, the contract code as a whole embodies the business logic. As services evolve and change, the service logic may change, and the code of the contract may also need to be adjusted. In addition, the code of the contract may have a bug and needs to be repaired, or the language version upgrading of writing the contract also brings the upgrading requirement of the contract. In all of the above cases, it is often necessary to upgrade the deployed contracts.

One way to upgrade a contract is to deploy a new contract that may have a different address than the contract. Specifically, as described above, the contract address may be obtained by hash calculation based on the address of the external account where the contract is deployed and the counter nonce thereof, for example, sha3 ([ address _ sender, nonce ]). Contracts deployed by different contract deployers, contract addresses being different; even for the same contract deployer, the address of the newly deployed contract changes because the nonce changes as a transaction counter as it initiates a new transaction when upgrading the contract. Thus, the storage of the new contract is also different from the old contract, and the state variables in the contract storage of the new contract can only be set and read from the blocks where the new contract is deployed, but cannot access the state in the old contract.

In some federation chains, the upgrade of contracts requires safeguards:

first, the upgraded contract maintains the same contract address as the contract before the upgrade. Therefore, the same contract storage space as before upgrading can be kept after upgrading, the historical data can not be lost, and the user does not need to change the contract address input when calling the contract.

Second, there is also a need to ensure compatibility before and after an upgrade, i.e., the state in the new contract after the upgrade needs to maintain the ability to read the value of the same state in the old contract.

In the first point, the generation rule of the contract account address may be set to be independent of the nonce, and further, may be set to be independent of the deployer. For example, the address of a contract account may be determined by the name of the contract, such as sha3 ([ name _ contact ]). This ensures that the addresses on the blockchain are the same for all contracts of the same name. As mentioned previously, contract accounts typically include Nonce, balance, storage root, codeHash, where CodeHash is a hash value of the contract bytecode. The bytecode of the upgraded contract is different from the bytecode before upgrading, so the CodeHash in the contract account is changed after the contract is upgraded, that is, the CodeHash in the contract account is generally updated after the contract is upgraded.

The second point is essentially the same state variable, such as the state variable r, if the key after the contract is upgraded changes, the value of r is read from the block where the contract is upgraded, and the value of r before the contract is upgraded cannot be correctly read due to the change of the key.

For example, the following code example 2 is a code example of an old contract before upgrade:

code example 2.2.solidity code of demo1

In the demo1 code, 2 state variables ID, sex are declared on lines 3 to 4, respectively. Of these 2 state variables: ID is a unit256 type, which in the solid is 32 bytes; sex is of the boul type and is 1 byte. These 2 variables, if preceding the function, are typically stored as persisted state variables, i.e., in the underlying database.

In the demo1 code described above, the setID () function is defined at lines 6-8. Public following the setID () function serves as a modifier designating the setID () function as an interface function for inside/outside. There is a unit256 type parameter x in the setID () function. unit256 represents an unsigned integer of 256bits and is 32bytes in length. In the function body, the value of the parameter x is assigned to the ID, so that an interface provided for the outside is realized, and the parameter x input by a user is set as the value of the state variable ID. The getID () function is defined on lines 10-12. The view following the getID () function indicates that the function can only read state variables and cannot modify state variables.

In the demo1 code, setSex () function and getSex () function are defined in lines 14-16 and lines 18-20, respectively, and the meaning of the code is similar to that described above and is not described again.

In the demo1 code described above, lines 22-24 define a version () function, the return value of which is a uid 256 type. The operation in the function body is a return 1. The user may call the function, which returns the version of the current contract, where the version is 1.

As previously mentioned, the state variable that needs to be persisted is typically a paired key-value structure. Wherein key represents the address of the state variable, and value represents the value of the state variable. In the above-described demo1 code, 2 state variables ID, sex are declared at the head, each of which will have a key. It should be noted that the space occupied by these 2 state variables is fixed, namely 32bytes and 1 byte.

Each contract typically has its own storage space, which is virtual and can be a very large array, e.g., 2 ²⁵⁶ Array of elements numbered from 0 to 2 ²⁵⁶ -1. Each element may be of a certain length, for example 32bytes. Each element is referred to herein as a slot (slot), as shown in FIG. 8. ID. The values of the 2 state variables, sex, may be stored in the 2 slots, 0 and 1, for example. In addition, the total is 2 ²⁵⁶ Storage of slotsThe storage space is the total capacity of the virtual space, that is, the unused slot does not occupy the actual storage space of the underlying database.

As described above, the demo1 contract written in a high-level language such as solidity is compiled by a compiler to generate bytecode.

The execution of the contract may be specifically as shown in fig. 7. A transaction, such as one of the invoking contracts in fig. 2, is sent into the blockchain network and, after consensus, each node can execute the transaction. The to field of the transaction indicates the address of the invoked contract. Any one node can find the storage of the contract account according to the address of the contract, and further can read the Codehsh according to the storage of the contract account, so that the corresponding contract byte code can be found according to the Codehsh. The node may load the bytecode of the contract from storage into the virtual machine. Furthermore, the Interpreter (Interpreter) interprets the execution, for example, including parsing the bytecode of the called contract (Parse, such as parsing Push, add, SGET, SSTORE, pop, etc.), obtaining the operation code (OPcode) and the function, and storing the OPcode in the memory space (memory) of the virtual machine (alloc in the figure; corresponding to the release of the memory operation, such as Free in the figure, after the program execution is finished), and also obtaining the jump position (JumpCode) of the called function in the memory space. Generally, after calculating Gas consumed for executing a contract and sufficient Gas, the method jumps to a corresponding address of a Memory to acquire an OPcode of a called function and starts execution, and performs operations such as Data calculation and push/push Stack (Stack) on Data operated by the OPcode of the called function, thereby completing Data calculation. In this process, context information of some contracts (Context) may also be needed, such as block number, information of the initiator calling the contract, and the like, which can be obtained from the Context (Get operation). Finally, the generated state is saved in a database store (Storage) by calling a Storage interface. It should be noted that, during the process of creating a contract, execution of some functions in the contract may also occur, for example, a function of an initialization operation, and at this time, a code is also parsed, a jump instruction is generated, a Memory is stored, and a Stack is operated.

Through the above process, the virtual machine loads and executes the byte code of the contract, possibly producing status and/or read status, thereby requiring access to the underlying database. The virtual machine needs to conveniently access the underlying KV database. The KV database is accessed, and data access capability similar to a pointer can be adopted. For example, if a value corresponding to a key needs to be read from the KV database, the key of this data needs to be known before access.

As previously described with respect to fig. 5, 6 and corresponding text, for a write operation, the execution module (including the virtual machine therein) executes the contract to generate kv, and for a read operation, the execution module (including the virtual machine therein) executes the contract to generate k. This k is a key generated by the execution module or blockchain platform, referred to herein as a status key. This state key needs to be constructed on the MPT tree in the construction tree module, so as to obtain a series of tree nodes key from the MPT root node, the middle nodes, and the leaf nodes. If the operation is a read operation, the corresponding value can be searched in the state database module according to the tree node key. If a write operation is performed, a series of tree nodes key-value from MPT root node-intermediate node-leaf node are generated, and these tree nodes kv are written into the state database module in an append (appended) manner.

In the process of executing the contract bytecode by the virtual machine, the position of the same state variable needs to be fixed, so that the key generated by the contract execution is fixed. This fixing is typically fixed after the contract code has been determined. Therefore, the work of fixing the position of the state variable is usually decided in the compiling process of the compiler, and is not directly related to the virtual machine.

The process of compiler compilation may generally include the steps of lexical/syntactic analysis according to an abstract syntax tree, filling symbols according to a symbol table, semantic analysis, and code generation. In the process of lexical/syntactic analysis according to the abstract syntax tree, position information of the state variable of the contract can be generated. For example, the positions of the 2 state variables ID and sex in demo1 are 0 and 1, respectively, and may correspond to the following 2 positions in the slot:

0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

the top 2 slot locations are each 256bits, and are 32bytes, represented by a 16-ary (0 x). The 4 consecutive 16-ary numbers in each segment separated by a space after the upper 0x represent 2bytes, so there are 16 such segments.

Thus, in the contract bytecode compiled by the compiler, the 2 positions in the slot can be used to replace the identifiers of the 2 state variables, such as the ID and the sex replaced by the 2 256bits, respectively. Thus, when the data type is a fixed-size value, the compiling can pre-allocate a storage location for each data to be stored according to the field sorting order, which is equivalent to specifying a fixed-invariant data pointer in advance.

In the process of loading and executing the contract bytecode by the virtual machine, the ID is operated, that is, 0x000.. 00 (that is, the slot 0 is replaced by an ellipsis in the middle of more 0). Similarly, the operation on the sex is the operation on the slot location 0x000.. 01

For example, a transaction that calls a contract, calling the setID () function in the contract, and referring to the string "0001", the slot location of 0x000.. 01 is stored at 0001 during the execution of the transaction by the virtual machine. Specifically, it may be that the virtual machine pushes the slot of 0x000.. 01 of this 32bytes onto the stack, and then pushes the corresponding value onto the stack. And acquiring the OPcode of the called function from the memory in the process of explaining and executing, popping the value from the stack according to the first-in last-out or first-in last-out characteristics of the stack, popping the slot from the stack to form a slot-value pair, and then executing the current OPcode by the contract virtual machine, namely writing the value of the value into the storage of the slot position. In the above process, the stack generally has a length equal to 1 slot with 32bytes as a storage unit, and the corresponding value may be less than, equal to, or greater than 32bytes, and the value may occupy 1 unit or multiple units in the stack.

For example, a transaction that invokes a contract, which invokes the setSex () function in the contract, with the argument "1" (e.g., 1 for boy and 0 for girl), the virtual machine stores a1 in the slot 0x000.. 02 during the execution of the transaction.

The results of the two contract executions can be simply expressed as follows:

0x000...00：0001 (1)

0x000...01：1 (2)

the above may also be as shown in fig. 9. As for the 0x000.. 01 slot, which is a pool type, and only occupies 1byte, the pool value of 1 can be stored in the lower 8 bytes of the slot, as shown in the lower part of fig. 9.

After the virtual machine is executed, the virtual machine or the blockchain platform may convert slots in the 3 slot-value key value pairs (1) and (2) into state keys. Specifically, the state key may be obtained by splicing the contract address + slot position. For example, the demo1 contract has an address length of 20bytes, and is 0x3321dcaf8911d3842e14a7a415be2fb1a337f 43e. After the splice contract address + slot position is adopted,

(1) The status key of (a) is: 0x3321dcaf8911d3842e14a7a415be2fb1a337f43e 000000000000000000000000000000000000000000000000000000000000000000000000

(2) The status key of (1) is: 0x3321dcaf8911d3842e14a7a415be2fb1a337f43e 00000000000000000000000000000000000000000000000000000000000000000001

These generated state key-values, during the process of storing into the underlying database, as shown in fig. 6, can be transformed by the building tree module to the storage trie tree as shown in fig. 5. Then, the tree building module builds the value in the state key-value into a certain leaf node of the MPT tree according to the structure of the tree. It should be noted that, as described above, the state key is divided into several segments, and the segments are stored in the tree nodes sequentially according to the direction from the root of the storage trie tree to the leaf nodes. Which segment of the state key each tree node stores depends on the state key being a common prefix with other state keys on the tree. A series of hash value changes are caused from the leaf node to the root node through the intermediate nodes, and the tree building module builds kv of the tree nodes. Further, the tree building module sends the changed tree nodes kv to the state database module, and finally, the state database module stores the changed tree nodes kv into the state database shown in fig. 6.

In the above process, the slot of the read-write state variable is fixed in the compiling link, and is determined by the contract address and the slot position of the state variable as described above. The status key may be derived from a contract address and slot splice. Thus, the same slot is adopted for reading and writing the same state variable and corresponds to the fixed state key when the same contract is run.

As previously described, some blockchains perform contract upgrades, keeping the upgraded contracts the same contract address as the contracts before the upgrade. Nevertheless, it is still challenging to ensure compatibility before and after upgrading, i.e., the ability of the state in the new contract after upgrading to maintain the ability to read the value of the same state in the old contract.

For example, the following code example 3 is a code example of an upgraded new contract:

code example 3.2 solid code of demo2

The code of demo2 is inserted with a new state variable age in line 4 of demo2 with respect to demo 1. Thus, sex originally located at the 4 th line in demo1 is sequentially shifted backward in demo2, and becomes the 5 th line. In addition, new state variable related write and read functions, setAge () and getAge (), are added to demo2 in lines 15-17 and 19-21, respectively.

The new demo2 code will still be compiled by the compiler to bytecode. In the compiling process, similarly, the compiler generates slot positions for the 3 state variables ID, age, and sex in demo2, where the slot positions are:

0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0002

thus, in the contract bytecode compiled by the compiler, the 3 positions in the slot can be used to replace the identifiers of the 3 state variables, such as the above-mentioned 3 256bits to replace the ID, age, and sex, respectively. When the compiled contract bytecode is loaded into a virtual machine and executed, the operation on the ID is the operation on the slot position 0x000.. 00, the operation on the age is the operation on the slot position 0x000.. 01, and the operation on the sex is the operation on the slot position 0x000.. 02.

It can be seen that, for the sex of the 5 th line of the upgraded demo2 code, which is obviously the 4 th line of the demo1 code before upgrading, both are state variables with the same meaning. However, in the above upgrading mode, the operation on the slot position of 0x000.. 01 after upgrading is changed into the operation of age, which is obviously different from the operation on the slot position of 0x000.. 01 before upgrading. Then, if the operation of reading the age by the upgraded contract bytecode is performed, the value of the sex at the position before the upgrade is read, which causes confusion. On the other hand, the operation on the sex after the upgrade is changed to the operation on the slot position of 0x000.. 01. Then, if the operation of reading sex for the contract bytecode after upgrading is performed, only a default null value or 0 value can be read and the correct value cannot be read since there is no value at this position before.

As shown in fig. 10, a compatibility scheme for detecting contract upgrading according to the present application includes:

s110: and generating an abstract syntax tree of contracts before and after upgrading.

As mentioned above, the compiler compiling process may generally include the steps of lexical/syntactic analysis according to an abstract syntax tree, filling symbols according to a symbol table, semantic analysis, and code generation.

Here, the intelligent contract code before and after upgrading may be lexically/grammatically analyzed according to the abstract syntax tree to generate the abstract syntax tree of the contract before and after upgrading. Specifically, a solid compiler may be used, and an "- -ast-compact-json" command may be used to take contract source codes before and after the upgrade as input, so that abstract syntax tree json (JavaScript Object Notation) files of contracts before and after the upgrade may be generated respectively.

For example, the demo1 contract before upgrading is parsed with a lexical/syntactic analysis according to the abstract syntax tree, and the abstract syntax tree of the contract before upgrading is generated as follows:

abstract syntax Tree for code example 4.Demo1

Code example 4 above is an abstract syntax tree of the generated pre-upgrade demo1 contract and is annotated with//. Once. Wherein the storage location of row 11 is a calculation rule for slot. In the above abstract syntax tree, from line 3 below, the information of the contract state variables in the abstract syntax tree is described, and information related to one state variable is placed in one node. Regarding the two state variables ID and sex, there are actually two nodes, lines 5-19 are the first node regarding ID, and lines 20-34 are the second node regarding sex. Each node in turn contains several pieces of information. In general, information inside one node may be referred to as node information of an abstract syntax tree.

For example, the upgraded demo2 contract performs lexical/syntactic analysis according to the abstract syntax tree, and the abstract syntax tree of the contract before upgrading is generated as follows:

abstract syntax Tree for code example 5.demo2

Code example 5 above is an abstract syntax tree for the generated upgraded demo2 contract. Because a row of statement age variable is added between the original ID and the sex in the demo2 code, namely the 4 th row in demo2, the age node information of the 20 th to 34 th rows is inserted between the ID node information of the 5 th to 19 th rows and the sex node information of the 35 th to 50 th rows in the abstract syntax tree of demo 2.

S120: and analyzing the generated abstract syntax trees, and sequentially extracting basic information in the node information of each abstract syntax tree.

The code examples 4 and 5 are parsed, that is, the generated abstract syntax trees are parsed, and the basic information in the node information of each abstract syntax tree is extracted in sequence. The basic information herein may include at least a node order, and further include a state variable name and/or a type.

The following example is to extract abstract syntax tree node information containing node sequence, state variable name and state variable type of demo1 contract code before upgrading:

node information 1: ID { typeString: agent 256. }

Node information 2: sex { typeString: pool, say }

Similarly, abstract syntax tree node information including the node order, the state variable name and the state variable type of the upgraded demo2 contract code is extracted and obtained as follows:

node information 1: ID { typeString: agent 256. }

Node information 2: age { typeString: agent 256. }

Node information 3: sex { typeString: pool, say }

S130: and comparing the basic information in the node information of the abstract syntax tree before and after upgrading to obtain a compatibility conclusion.

For example, the basic information in the node information of the abstract syntax tree before and after the upgrade in S120 above can obtain the following comparison table:

base information in abstract syntax tree node information before upgrading	Basic information in upgraded abstract syntax tree node information
		Node information 1: ID { typeString: uint 256. }	Node information 1: ID { typeString: agent 256. }
Node information 2: sex { typeString: pool	Node information 2: age { typeString: agent 256. }
			Node information 3: sex { typeString: pool

TABLE 2 comparison of node information of abstract syntax trees before and after upgrading

In table 2, the node information of the abstract syntax tree before and after upgrading may be sequentially placed in the same row. Further, by line-by-line scanning and comparison, whether the left and right are the same can be judged. In other words, the basic information in the node information of the same node number in the abstract syntax tree before and after the upgrade is compared. Of course, it is preferable to compare the basic information in the node information of the same node number in the abstract syntax tree before and after the upgrade according to the node number order. In table 2 above, when the line of node information 2 is scanned, it can be compared that the names of the state variables are different, and thus, the conclusion of incompatibility can be obtained.

This is because, as described above, slots are generated according to node information in accordance with the slot generation rule. Further, the contract address and slot are spliced to generate a state key of the state variable. That is, the slots generated in the row of node information 2 are the same, e.g., all 0x000.. 01, and are not related to the variable name. Thus, the value generated by the same slot or state key according to the contract logic after the contract upgrade is another state variable different from the one before the upgrade, and is generally inconsistent. This is generally inconsistent because, if the state variable name is merely adjusted before and after an upgrade, no change in the contract logic relating to the state variable actually causes an incompatibility, but such a contract upgrade is less common. In most cases, there will be some change in contract logic after the state variable names are adjusted. Therefore, further, the determination may be made in conjunction with the type of the state variable. Incompatible conclusions can also be obtained if the comparison shows that the type of the state variable in the node information of the same row changes. Of course, if the name and the type of the state variable in the same row of node information are compared and changed, a stronger incompatible conclusion can be obtained.

In addition, basic information in node information of the abstract syntax tree before and after upgrading is compared, and if the sequence of the node where the state variable name after upgrading is located is different from that of the node of the abstract syntax tree where the same state variable name before upgrading is located, an incompatible conclusion can be obtained with a higher probability. This is because, in general, the same state variable name refers to the same state variable before and after the upgrade; then, if the sequence of the abstract syntax tree nodes where the same state variables are located before and after the upgrade is different, slots are generally different, and reading and writing of data may be confused.

In fact, by the comparison of S130, if the conclusion is not compatible, a conflicting slot, such as node order 2 in table 2 above, can also be obtained. In this way, the basic information/node information of the conflicting slot locations can be fed back to the developer, for example, by recording such as generating logs and alarms, or by notification such as screen prompt, mail, instant message, etc., so as to suggest the developer or the platform location incompatibility, and is particularly beneficial for the developer to make modifications.

There is also a case where the updated state variable is completely added with a new state variable after the original state variable, as compared with the state variable before the update, and a compatible conclusion can be obtained. For example, the following example code:

solidity code of code example 6.Demo2

As can be seen, the code of demo2' is a state variable, which is added with age after the original ID and sex, compared to demo 1. Thus, the abstract syntax tree for demo2' is as follows:

abstract syntax Tree for code example 7.Demo2

According to S120, abstract syntax tree node information including node sequence, state variable name and state variable type of the upgraded demo2' contract code is extracted and obtained, and the abstract syntax tree node information includes the following steps:

node information 1: ID { typeString: uint 256. }

Node information 2: sex { typeString: pool

Node information 3: age { typeString: agent 256. }

Thus, the basic information in the abstract syntax tree node information before and after upgrading can obtain the following comparison table:

base information in abstract syntax tree node information before upgrading	Basic information in upgraded abstract syntax tree node information
		Node information 1: ID { typeString: agent 256. }	Node information 1: ID { typeString: agent 256. }
Node information 2: sex { typeString: pool	Node information 2: sex { typeString: pool
			Node information 3: age { typeString: agent 256. }

TABLE 3 comparison of node information of abstract syntax trees before and after upgrade

As can be seen from table 3, the ID of the state variable before being upgraded and the total state variable name of the code after being upgraded of the sex, the type of the state variable, and the order of the nodes in the abstract syntax tree are not changed, so that the ID after being upgraded and the sex maintain the same slot as that before being upgraded, and are thus compatible. If the updated state variable is newly added after the state variable before updating, the slot generation rule will not affect the slot of the previous state variable, and the state key will not be affected, so that a compatible conclusion can be obtained. Obviously, this is easier to implement by comparing in the order of node numbering.

Note that the types of the state variables ID, age and sex in the above example are respectively uint256, uint256 and pool, wherein uint256 is 256bits, i.e. 32bytes, and the pool type is 1 byte. The type of these state variables determines the length of the data to be fixed, or fixed length. In addition, types of the uint, uint8, uint128, and the like are fixed in length. An array of a determined number of fixed length elements, also fixed in length, such as uint [2], comprises 2 elements, each element being of the uint type 32bytes, so that uint [2] is 64bytes in its entirety.

In addition to fixed-length data storage, the length of the data is not fixed, or the size of the data is unpredictable. In this case, the storage location cannot be directly determined during compilation in a fixed-length manner, but a different scheme is adopted. E.g., a dictionary (mapping) of an indefinite length data type. The storage layout of the dictionary is to store keys and the corresponding values thereof, and each Key corresponds to one storage. The corresponding storage location of a Key is Key 256 (slot), where ". Is the splice symbol,". The previous Key is the Key of a dictionary element, ". The next slot dictionary name is the slot location. For example, in the demo2 contract, if the ID, age, and six are followed by mapping (uint 256= > string) a, the number of elements in the dictionary is uncertain, and the lengths of key and value in the elements are also uncertain. After the demo2 contract is called several times, there may be2 elements of dictionary a, which are:

a["u1"]＝0x18；

a["u2"]＝0xac5b4fc54a5fa637d8c9853ada1430ea9203817e8a97df1f85f8e63a30f6713d7d3f68f79db22df669f5dbe17d43a16c720fe92edd5d87843ebf0b0b59；

then in this slot 0x000.. 06, the dictionary name a may be stored. The key of item 1 in dictionary a is u1 and value is ox 18. u1 may be keccak256 ("u 1".0x000.. 03), where a value may be stored in one or consecutive slots starting at this location (e.g., a value having a data length greater than 32 bytes). Similarly, the key of item 2 in dictionary a is u2, and value is a long 16-ary number. The storage location for u2 may be keccak256 ("u 2".0x000.. 03), where value may be stored in one or consecutive slots starting at this location (e.g., value has a data length greater than 32 bytes).

Take u1 with a value less than 32bytes, u12 with a value greater than 32bytes, less than 64bytes, as an example.

As shown in fig. 11, u1 has a value less than 32bytes, which can be stored in 1 slot, for example, at a value of keccak256 ("u 1",0x000.. 03), such as:

0x5b4ded6cc1629f138186f4b0795004adbed7ec13374d15ca04ec96f149132460

the value of u2, which has a length greater than 32bytes and less than 64bytes, can be stored in 2 consecutive slots, whose starting position is, for example, the value of keccak256 ("u 2",0x000.. 03), and then the positions of these two slots are:

0x90191b3f1d96c216c6a6637b9c8498bc25cc907afe246d611b3a8bf727bc081d

0x90191b3f1d96c216c6a6637b9c8498bc25cc907afe246d611b3a8bf727bc081e

the data of indefinite length may be judged to be compatible by performing the processes of S110 to S130. For example, the node information of the abstract syntax tree generated for the dictionary structure is:

code example 8 abstract syntax Tree of dictionary Structure

Then in performing S120, it is also necessary to traverse each slot in the indefinite length data structure, since the location of these slots may be the basis for the computation of the final state key. In particular, for the case of u2, which is a plurality of consecutive slots occupied by value, the starting position may be used as the basis for the calculation of the state key.

In addition, there are some composite structures. For example, a composite structure of a structure and a dictionary, the following solid code:

code example 9. Solid code of composite Structure

In the above code, a structure structDemo is declared at 7-10, which includes two elements, c _ of the fluid 256 type and d _ of the bytes type. Then, a dictionary, which is a mapping of the agent to the structure structDemo, is declared on line 11. The structure and dictionary part of the code, according to the abstract syntax tree generated in S110, includes:

code example 10 abstract syntax Tree for composite Structure

Lines 6-17 of the abstract syntax tree are the node information of agent 256 c _ in the structure StructDemo, lines 18-31 are the node information of bytes d _ in the structure StructDemo, and the bytes type is also 32bytes. It should be noted that both lines 10 and 23 are "stateVariable" indicating that neither c _ nor d _ are state variables, and therefore, are not stored in the underlying database.

Then in S120, the structure elements c _ and d _ of "stateVariable" false are not extracted, since c _ and d _ are not stored directly in the underlying database. But in the dictionary a, if "stateVariable" is true, the basic information in the node information of the abstract syntax tree is extracted, because the dictionary a is stored in the underlying database, and the structures c _ and d _ included in the elements are stored in the underlying database. That is, the structure is merely declared. In this way, in S120, the generated abstract syntax tree is analyzed, and for the state variable in the node information being true, the basic information in the node information of each abstract syntax tree is sequentially extracted.

In the case of a composite structure, for example, in the case where the value is a structure in the dictionary structure, the generated abstract syntax tree is parsed, and the basic information in the node information of each abstract syntax tree is sequentially and recursively extracted. This is because, although the attribute of "stateVariable" in the node information of the structure itself is false, it has its own slot and state key as a value in the dictionary. By extracting the basic information of the node information in a sequential and recursive manner, all the state variables which are actually stored in the bottom database can be expanded without omission. The recursive mode is that the nested structure definition is expanded, and the contained data structure is obtained from the expanded nested structure definition; if there are more layers of nesting, the contained data structure continues to be obtained in a recursive manner.

In this example, assume that 2 maps 2_ are initialized in the contract code, which are:

map2_"StructDemo"_uint:"StructDemo"_"c_" 0:StructDemo_c_

map2_"StructDemo"_uint:"StructDemo"_"d_" 0:StructDemo_d_

map2_"StructDemo"_uint:"StructDemo"_"c_" 1:StructDemo_c_

map2_"StructDemo"_uint:"StructDemo"_"d_" 1:StructDemo_d_

extracting abstract syntax tree node information of the obtained demo2' contract code, wherein the abstract syntax tree node information comprises a node sequence, a state variable name and a state variable type, and the abstract syntax tree node information comprises the following steps:

node information 1: ID { typeString: uint 256. }

Node information 2: age { typeString: agent 256. }

Node information 3: sex { typeString: pool

Node information 4: map2_ { typeString: mapping (U _ unt 256= > struct demo "_

Node information 5: map2_ StructDemo _0 c _ { typeString: uint 256. }

Node information 6: map2_ StructDemo _0

Node information 7: map2_ StructDemo _1

Node information 8: map2_ StructDemo _2

If another upgraded contract comprising the ID, the age, the sex and the map2_ exists, the abstract syntax tree node information of the contract code which is extracted and contains the node sequence, the state variable name and the state variable type is consistent with the above, compatibility is carried out, otherwise, incompatibility is carried out. The slot schematic of the above example is shown in fig. 12.

In another example, assuming map2_ is not initialized in the contract code, the node information of the abstract syntax tree of the contract code containing the node order, the state variable name and the state variable type is obtained as follows:

node information 1: ID { typeString: uint 256. }

Node information 2: age { typeString: agent 256. }

Node information 3: sex { typeString: pool, say }

Node information 4: map2_ { typeString: mapping (U _ unt 256= > struct demo "_

Then before and after contract upgrade, recursive comparison of nested struct structures is required when comparing node information 2. And if the node information 4 and the nested structure in the node information of the abstract syntax tree extracted before and after upgrading are consistent, the node information is compatible (assuming that the node information 1, the node information 2 and the node information 3 are consistent), otherwise, the node information is incompatible.

The updated contract writing method needs to meet certain specifications to enable compatibility before and after updating, namely, the state in the updated new contract needs to maintain the capability of reading the value of the same state in the old contract. When a user writes an upgraded contract, the user often ignores the specifications, so that the upgraded contract has serious problems of data loss, confusion and the like. By the above example, the schema for detecting compatibility of the storage data can be realized by upgrading the solidity contract based on the abstract syntax tree.

The following introduces a device for detecting compatibility of contract upgrade of the present application, including:

The extraction unit analyzes the generated abstract syntax trees, and sequentially extracts basic information in the node information of each abstract syntax tree for the condition variable in the node information is true.

And the abstract syntax tree generating unit carries out lexical/syntax analysis on the intelligent contract codes before and after upgrading according to the abstract syntax tree to generate the abstract syntax tree of the contracts before and after upgrading.

The basic information comprises the node sequence of the abstract syntax tree and further comprises a state variable name and/or a type.

And the comparison unit compares the basic information in the node information with the same node number in the abstract syntax tree before and after upgrading.

And the comparison unit compares the basic information in the node information with the same node number in the abstract syntax tree before and after upgrading according to the node number sequence.

In the comparison process of the comparison unit,

if the names of the state variables obtained by comparison are different, the state variables are incompatible; or the like, or, alternatively,

if the types of the state variables obtained by comparison are different, the state variables are incompatible; or the like, or, alternatively,

and if the state variable name and the state variable type are different, the state variable name and the state variable type are not compatible.

And the comparison unit compares the updated state variable with a new state variable added after the state variable before updating, and judges the updated state variable is compatible.

For the composite structure, the extraction unit analyzes the generated abstract syntax trees and sequentially and recursively extracts the basic information in the node information of each abstract syntax tree.

The detection device further comprises a feedback unit, wherein the comparison result of the comparison unit is incompatible, and the feedback unit feeds back the basic information/node information of the conflicted slot position.

An embodiment of a client of the present application is described below, including:

a memory storing a program, wherein when the processor executes the program, the method of any of the above embodiments is performed for the purpose of, for example, detecting compatibility of a contract upgrade.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development, but the original code before compiling is also written in a specific Programming Language, which is called Hardware Description Language (HDL), and the HDL is not only one kind but many kinds, such as abll (Advanced boot Expression Language), AHDL (alternate hard Description Language), traffic, CUPL (computer universal Programming Language), HDCal (Java hard Description Language), lava, lola, HDL, PALASM, software, rhydl (Hardware Description Language), and vhul-Language (vhyg-Language), which is currently used in the field. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium that stores computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be conceived to be both a software module implementing the method and a structure within a hardware component.

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. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. 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, the presence of additional identical or equivalent elements in processes, methods, articles, or apparatus that include the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device 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 tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can 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.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the system embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is intended to be illustrative of one or more embodiments of the disclosure, and is not intended to limit the scope of one or more embodiments of the disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A method of detecting compatibility of a contract upgrade, comprising:

generating abstract syntax trees of contracts before and after upgrading;

2. The method of claim 1, wherein parsing the generated abstract syntax trees to sequentially extract basic information in node information of each abstract syntax tree comprises:

and analyzing the generated abstract syntax trees, and sequentially extracting basic information in the node information of each abstract syntax tree for the state variable in the node information is true.

3. The method of claim 1, the generating an abstract syntax tree for contracts before and after upgrading, comprising:

and performing lexical/syntactic analysis on the intelligent contract codes before and after upgrading according to the abstract syntax tree to generate the abstract syntax tree of the contract before and after upgrading.

4. The method of claim 1, wherein the base information comprises an order of nodes of the abstract syntax tree, and further comprises a state variable name and/or a type.

5. The method of claim 1, wherein comparing the basic information in the node information of the abstract syntax trees before and after the upgrade comprises:

and comparing the basic information in the node information of the same node number in the abstract syntax tree before and after upgrading.

6. The method of claim 5, wherein the basic information in the node information of the same node number in the abstract syntax tree before and after the upgrade is compared in order of the node numbers.

7. The method according to claim 5 or 6,

if the names of the state variables obtained by comparison are different, the state variables are incompatible; or the like, or a combination thereof,

if the types of the state variables obtained by comparison are different, incompatibility is realized; or the like, or, alternatively,

and if the state variable name and the state variable type are different, the state variable name and the state variable type are incompatible.

8. The method of claim 5 or 6, wherein the upgraded state variables are judged to be compatible by adding new state variables after the state variables before upgrading.

9. The method of claim 1, wherein parsing the generated abstract syntax trees to sequentially extract basic information in node information of each abstract syntax tree comprises:

and for the composite structure, analyzing the generated abstract syntax trees, and sequentially and recursively extracting basic information in the node information of each abstract syntax tree.

10. The method of claim 1, further comprising feeding back base information/node information of the conflicting slot locations if incompatible.

11. A contract upgrade compatibility detection apparatus comprising:

12. The detection apparatus according to claim 11, wherein the extraction unit parses the generated abstract syntax trees, and sequentially extracts the basic information in the node information of each abstract syntax tree for which the state variable in the node information is true.

13. The detecting apparatus as claimed in claim 11, wherein the abstract syntax tree generating unit performs lexical/syntactic analysis on the intelligent contract code before and after upgrading according to the abstract syntax tree to generate the abstract syntax tree of the contract before and after upgrading.

14. The detection apparatus according to claim 11, wherein the basic information comprises a node order of the abstract syntax tree, and further comprises a state variable name and/or a type.

15. The detection apparatus according to claim 11, wherein the comparison unit compares the basic information in the node information of the same node number in the abstract syntax tree before and after the upgrade.

16. The detection apparatus according to claim 15, wherein the comparison unit compares the basic information in the node information of the same node number in the abstract syntax tree before and after the upgrade, in the order of the node numbers.

17. The detection device according to claim 15 or 16, a comparison unit

If the state variable names obtained by comparison are different, incompatibility is realized; or the like, or, alternatively,

18. The detection apparatus according to claim 15 or 16, wherein the comparison unit compares that the upgraded state variable is determined to be compatible by adding a new state variable after the state variable before upgrading.

19. The detecting device according to claim 11, wherein,

20. The detection apparatus according to claim 11, further comprising a feedback unit that feeds back basic information/node information of the slot locations of the collision for which the comparison result of the comparison unit is incompatible.

21. A client, comprising:

a memory storing a program, wherein the method of any of the above claims 1-10 is performed when the program is executed by the processor.