CN114047928A

CN114047928A - Intelligent contract formal verification method and system suitable for combined transaction

Info

Publication number: CN114047928A
Application number: CN202210029440.4A
Authority: CN
Inventors: 陈钟; 关志; 李青山; 董宇; 李悦; 崔冬琪; 陈子明
Original assignee: Boya Chain Beijing Technology Co ltd; Peking University
Current assignee: Boya Chain Beijing Technology Co ltd; Peking University
Priority date: 2022-01-12
Filing date: 2022-01-12
Publication date: 2022-02-15
Anticipated expiration: 2042-01-12
Also published as: CN114047928B

Abstract

The invention discloses an intelligent contract formal verification method suitable for combined transaction, wherein the combined transaction refers to the situation that a plurality of transactions are included in a scene or one transaction relates to a plurality of contracts; the method is characterized in that contract constraints are added based on a block chain Ethengfang intelligent contract source code, the contract constraints comprise cross functions and cross contract constraints in a combined transaction scene, the source code after the contract constraints are added is converted into corresponding types, sentences, expressions and constraints in an intermediate verification language, and then formal verification is automatically carried out on an intermediate verification language file through a verifier, so that the safety of the intelligent contract is guaranteed. By adopting the technical scheme of the invention, the verification of cross-function and cross-contract constraint functions can be supported, the contract function can be verified in a multi-transaction scene, the actual application requirements are met, and the intelligent contract safety is effectively ensured.

Description

Intelligent contract formal verification method and system suitable for combined transaction

Technical Field

The invention belongs to the technical field of block chain technology and intelligent contracts, relates to intelligent contract formal verification technology, and particularly relates to a solid intelligent contract formal verification method suitable for combined transaction, which is used for formally verifying a solid intelligent contract.

Background

The block chain is a novel technology which comprehensively uses computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like, and has the characteristics of decentralization, no tampering, openness and transparency and the like. The blockchain is essentially a distributed database, and a decentralized consensus mechanism is used to maintain a uniform distributed account book by participants in the blockchain without relying on a third-party management mechanism.

The intelligent contract is a section of code running on the blockchain, when the transactions of two parties on the blockchain asset meet the triggering condition, the program can automatically execute the contract content, and the characteristics of the blockchain guarantee that the whole processes of storage, reading and execution are transparent, traceable and not capable of being tampered. The Etherhouse intelligent contracts are written in a Solidity language and run in an Etherhouse Virtual Machine (EVM) after being compiled into byte codes. The contract deployer sends and saves the contract code to the blockchain by sending a transaction, and other users or contracts can interact with the contract code by calling the API.

Because of the non-tamper-ability of block chains, smart contract codes cannot be modified or upgraded once they are linked up, thus potentially resulting in significant losses that are not reversible if the code has fundamental problems. Such as The DAO event which occurred in 2016, an attacker steals an ethernet dollar value of 6000 million using a vulnerability present in The smart contract, causing significant losses. The intelligent contract security events which are frequently exploded enable more and more researchers from academic circles and industrial circles to pay attention to the security problem of the intelligent contract, and various algorithms and tools are used for conducting security audit on the contract before contract code deployment, so that possible threats and vulnerabilities are eliminated. However, the complexity of contract codes is increasing, and many application scenarios require interaction of different functions within one contract or interaction of multiple contracts to be able to be realized, i.e. a transaction scenario is combined. Because most of transactions are oriented to a combined transaction scene at present, more and more security attacks are also generated in the combined transaction scene, and therefore, the security and the functionality of the intelligent contract in the combined transaction scene are guaranteed to be very important.

The main method for verifying the functionality of the existing intelligent contracts is formal verification, namely, mathematical formulas, theorems and systems are used for verifying the correctness of a system. Formal verification typically translates programs into a verifiable formal language, which is then verified by rigorous mathematical reasoning and proof. Compared with other software testing methods, formal verification can prove that a system does not have certain defects or meet certain attributes, and the concept and the attributes of the intelligent contract can be comprehensively checked. The current scenarios supported by functional verification are divided into two categories: for a certain class of scenarios, e.g. for ERC20 or ERC 721; for a certain contract or a certain function. If the existing formal verification method is used for verifying the contracts under the combined transaction scene, false positives are easy to occur because the relations between the contracts or the functions cannot be verified. In addition, none of the existing functionality verification tools provide functionality for verifying third party contracts, nor provide for specification of third party contract attribute constraints.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention provides a method for formalized verification of a identity intelligent contract applicable to a combined transaction scene, wherein a user inserts functional semantics needing to be verified into the intelligent contract and finally checks whether the contract meets the functional semantics.

In the invention, the combined transaction scene means that the scene contains a plurality of transactions or one transaction relates to a plurality of contracts, and the combined transaction scene specifically comprises the following steps:

(1) the scenario includes multiple transactions: the sequence of transactions, manipulated by the contract caller, initiates calls in order to different functions of a contract. (2) The scenario involves a number of contracts: a transaction sequence written by a contract writer, one contract making calls to functions in another contract.

The technical scheme of the invention is as follows:

a solid intelligent contract formal verification method suitable for combined transaction adds contract constraints based on solid source codes of an EtherFang intelligent contract, comprises cross-function and cross-contract constraints in a combined transaction scene, converts the solid source codes after the contract constraints are added into corresponding types, sentences, expressions and constraints in an intermediate verification language (such as Boogie), and automatically performs formal verification on an intermediate verification language file through a verifier, and comprises the following steps:

1) adding contract constraints based on a solid source code of the Ether house intelligent contract, wherein the contract constraints are used for representing functional attributes which need to be met by the Ether house intelligent contract; the added contract constraints include: invariant constraints of the contract layer; pre-conditional constraints and post-conditional constraints of the function layer; a loop invariant constraint; the sum of the arrays or the mappings further comprises cross-function constraints and cross-contract constraints in the combined transaction scenario;

cross-function constraint, namely constraint on the function relationship in a multi-transaction scene; designing a constraint form of function precedence order and a constraint form of function mutual exclusion relation, and adding the constraint forms at the beginning of a contract;

the cross-contract constraint is a constraint under a plurality of contract scenes, and can comprise an invariant constraint of a contract layer, a pre/post conditional constraint of a function layer and a cross-function constraint; setting a writing form and a position of a cross-contract constraint, adding the cross-contract constraint into one contract, and constraining a function or a state variable of the contract; or adding cross-contract constraints to a plurality of contracts for making cross-contract constraints;

2) generating an abstract syntax tree AST from the Solidiy source code after the contract constraint is added, traversing the AST, converting types, sentences, expressions and contract constraints in the Solidiy syntax into corresponding types, sentences, expressions and constraints in the syntax of an intermediate verification language, and performing special conversion on cross-function constraints and cross-contract constraints; wherein the content of the first and second substances,

2a) for the conversion across function constraints, two additional processes are added to the converted intermediate language code; specifically, the method comprises the following steps:

2 aa) setting a precedence relationship between a function A and a function B, wherein the function A is a function executed firstly, and the function B is a function executed later; i.e. the precondition of function B contains the state variables modified by function a; then one new procedure after conversion only calls the function B, and the other procedure calls the function B according to the execution relation, namely calling A and then calling B; the constraint of the function B can be met only after the function A is called;

2 ab) setting a mutual exclusion relation between a function A and a function B, wherein the function A modifies a certain state variable, and the function B depends on the state before the state variable is modified; then one new procedure after conversion calls the functions A and B at the same time, and the other procedure only calls the function A or the function B;

2b) for the transformation of cross-contract constraints, namely adding a constraint condition to another contract in one contract, and then when a function of the other contract is called, whether the function meets the functional attribute of the constraint is checked; the realization mode is as follows: identifying and positioning another contract and a state variable and a function thereof, modifying a constraint expression, and inserting the constraint into a corresponding position of a called function of the other contract; the method specifically comprises the following steps:

locating a contract according to a contract name of another contract; according to the variable name or function name, positioning a specific variable or function, and replacing a cross contract variable or a cross contract function in the original constraint; after replacement, inserting the constraint into a corresponding position of a third-party contract, namely into the constraint of the called function; if the constraint is the constraint of the contract layer, the constraint is inserted into the constraint of the called function, so that the constraint is met when the function is entered and the function is exited; if the function layer is the pre/post constraint of the function layer, the function layer is directly inserted into the constraint of the called function, and the pre/post attribute is kept unchanged;

3) storing the converted intermediate verification language code with the constraint specification into a file;

4) formalizing the intermediate verification language code to generate a verification condition file;

5) inputting the verification condition file into the verifier; the verifier automatically carries out formal verification on the input file to obtain a verification result, analyzes the verification result into a readable result and returns the result to the user;

through the steps, intelligent contract formalized verification suitable for combined transaction is achieved.

In the intelligent contract formal verification method suitable for combined transaction, a scene comprises a transaction sequence in which a plurality of transactions are controlled by a contract caller, and different functions of one contract are initiated and called in sequence; a scenario involves multiple contracts being a sequence of transactions written by a contract writer, one contract initiating a call to a function in another contract.

In step 1), the constraint form of the sequence in the cross-function constraint is expressed as:

the constraint form of the mutual exclusion relationship in the cross-function constraint is expressed as:

the written form and position of a constraint in a cross-contract constraint are the same as those of the contract itself, and a state variable or function that calls another contract uses the form of '. prime, with the left of' prime being the contract name of the other contract and the right being the state variable name and function name in the other contract.

In the step 2), the conversion of contract constraint is divided into conversion of require, which is expressed in an alert statement mode and conversion of which is expressed in an annotation mode; the conversion method for representing the constraint in the mode of the require statement and the assert statement is specifically to directly convert the constraint into the assert statement, and the position is unchanged; the annotation mode represents the transformation method of the constraint, specifically, the constraint is placed after the procedure statement after the transformation, and the function body of the procedure is followed by the constraint. The conversion of the contract constraints is specifically:

if the statement is precondition, converting into a require statement; if the postcondition is the postcondition, converting into an ensure statement; if the constraint is invariant constraint of a contract layer, converting into two statements, namely, a require statement and an ensure statement, wherein the require statement enables the constraint to be met before the function is entered, and the ensure statement enables the constraint to be met when the function is exited; if the constraint is the invariant constraint of the loop body, the transformed statement is still an invariant statement, and is placed after the while () condition, and the constraint is followed by the loop body.

In step 2 aa), the verification that there is a precedence relationship in the cross-function constraint is specifically: extracting all modification statements related to state variables in the function A which is executed firstly, and putting the modification statements into the constraint of the converted procedure A, wherein the constraint form is postcondition; if the first procedure verification fails and the second procedure verification passes, it indicates that the postcondition of the function a executed first is consistent with the preconcondition of the function B executed later, that is, the constraint of the function B can be satisfied only after the function a is called, and the precedence relationship between the functions a and B is verified.

In step 2 ab), the verification of the mutual exclusion relationship across the function constraints is specifically: one newly added procedure after conversion calls the functions A and B at the same time, and the other procedure only calls the function A or the function B; simultaneously, extracting statements modified by the state variables in the function A and putting the statements into the constraint of the procedure A; and if the first procedure fails to pass the verification, the second procedure passes the verification, namely the post condition of the function A is inconsistent with the precondition condition of the function B, and the mutual exclusion relationship between the function A and the function B is verified.

In step 2 b), the contracts are located, specifically, an array is set when the contracts are converted into the intermediate language, each traversed contract is stored into the array, and then the array is searched according to the contract name of another contract in a traversing manner, and the contracts are located.

When the method is implemented specifically, the intermediate verification language adopts Boogie. The verifier adopts a verifier Z3.

And performing a formal verification process according to the intermediate language file.

After the Solidity source code is converted into the Boogie program, symbolic execution is carried out on the formalized program, and meanwhile, a theorem auxiliary prover (Z3) is used for automatically deducing a logic expression of the intermediate code based on Hall logic. The derived logical invariant result is automatically identified by theorem and is subjected to equivalence judgment with attribute constraint. If the program is judged to be equivalent, the verified program is shown to be in accordance with the expected verification attribute; if the decision is not equivalent, it indicates that the program does not conform to the desired verification properties. The return result of the invention is that the function in the contract is taken as the unit, if a plurality of contracts exist, the verification result of each function in the contract is returned in turn according to the input contract sequence. The verification result comprises two types of 'OK' and 'Error', if the verification is passed, the 'OK' is directly displayed after each function name; if the verification is not passed, displaying 'Error', reversely positioning a code line which is not in accordance with the specification in the identity source code by tracking the verification process, displaying a line number, and displaying which type of constraint in the invariant and pre/post condition is not met to cause the verification to be failed.

When the intelligent contract formal verification method is specifically implemented, a solid intelligent contract formal verification system suitable for combined transaction is realized based on the intelligent contract formal verification method suitable for combined transaction; the method comprises the following steps: contract constraint establishing module, intermediate language conversion module, formal verification module; wherein:

establishing a contract constraint module for adding contract constraints which need to be met by the intelligent contracts of the Etheng;

the intermediate language conversion module is used for converting the Ethernet intelligent contract (solid) source code with contract constraints into (Boogie) intermediate language;

the formal verification module is used for performing formal verification according to the intermediate language file.

Compared with the prior art, the invention has the positive improvement effects that:

the invention provides a general method and a tool for formalized verification of a solid intelligent contract, which not only supports common function verification, but also supports cross-function and cross-contract, can verify the contract function in a multi-transaction scene, meets the requirement of practical application, and effectively ensures the safety of the intelligent contract in all aspects.

Drawings

FIG. 1 is a block flow diagram of a method of formally validating an intelligent contract in accordance with the present invention.

Detailed Description

The invention will be further described by way of examples, without in any way limiting the scope of the invention, with reference to the accompanying drawings.

The invention provides a solid intelligent contract formal verification method suitable for combined transaction, which comprises the following steps:

(1) adding contract constraints based on a Solidity source code of the intelligent Ethernet house contract, wherein the contract constraints comprise cross functions and cross contract constraints in a combined transaction scene and are used for representing functional attributes required to be met by the intelligent Ethernet house contract;

(2) generating an Abstract Syntax Tree (AST) from the Solidiy source code after the contract constraint is added, traversing the AST, converting types, sentences, expressions, constraints and the like in the Solidiy syntax into corresponding types, sentences, expressions and constraints in the Boogie syntax, and performing special conversion on cross-function and cross-contract constraints;

(3) storing the converted Boogie codes with constraint specifications in a bpl file;

(4) formalized description is carried out on the Boogie program, and a verification condition is generated and input into a verifier Z3;

(5) the verifier automatically carries out formal verification on the input file to obtain a verification result, analyzes the verification result into a more readable result, and returns the result to the user.

Specifically how contract constraints are added and the kinds of functional attributes that may be added:

the function constraint statement comprises two major classes, wherein the first class is a require statement and an alert statement which are carried in source code and are placed in a function body, and the second class is in a comment form and is placed in front of a contract or the function body and begins with '///@'. In the present invention, the contract constraints of the annotation type include the following classes:

(1) invariant constraints of the contract layer.

And adding constraints on state variables in the contracts at the beginning of the contracts to ensure that the variables are kept unchanged in the contract execution process. The function of each public property in the contract inherits the constraint and is converted into a pre condition and a post condition of the function, namely the function needs to verify the invariance of the state variable before entering and after executing. The invariant constraint form of the contract layer is:

(2) pre-conditional constraints and post-conditional constraints for the function layer.

The pre condition is a condition to be satisfied when entering the function, and the post condition is a condition to be satisfied after the function is executed. The pre conditional constraint is of the form:

the post conditional constraint is of the form:

(3) loop invariant constraints.

And adding invariance constraint of the state variable in front of the loop body to ensure the invariance of the state variable in the whole loop execution process. The loop invariant constraint form is the same as the invariant constraint form of the contract layer.

(4) Constrained across functions. Namely the constraint on the functional relationship in the multi-transaction scene, is added at the beginning of the contract. The relationships between the functions include: the order of execution, and mutual exclusion relationship. The precedence order of the functions means that a certain function can be executed before another function is executed, otherwise the pre-condition constraint of another function cannot be met. The constraint form of the precedence order is:

the mutually exclusive relationship of the functions means that two functions cannot be called simultaneously, otherwise the pre-constraint of either function cannot be satisfied. The constraint form of the mutual exclusion relationship is:

(5) and (4) constraint across contracts. I.e., constraints under multiple contract scenarios.

The above constraint forms are all constraints on functions or state variables of the corresponding contracts, but in a cross-contract scenario, a plurality of contracts are included, and constraints of functions or state variables of other contracts need to be added to one of the contracts. Sometimes we need to call functions in the third party contract library, but do not know the functional correctness of these contracts, so constraints on these third party contracts can be added to this contract to verify that we want the functional attributes are satisfied. These constraints include the above-mentioned invariant constraints, pre/post conditional constraints, and cross-function constraints. The writing form and the position of the constraint are the same as those of the constraint of the contract itself, and the state variable or function calling another contract uses the form of '. The left side of the' is the contract name of other contracts, and the right side is the state variable name and the function name in other contracts, namely 'ContractName.Variable' or 'ContractName.function'.

(6) Array or sum of mappings. In addition to directly constraining the values of the state variables, the sum values of an array (array) or a map (mapping) may also be constrained. Because the increase and decrease operation of account balance is often involved in the intelligent contracts of the etherhouses, the balance check of accounts for transferring accounts is indispensable, and the most direct mode is to check whether the sum of the account balance of mutual transferring is kept unchanged. The invention provides a built-in function, namely, verifier _ sum _ type (), wherein type is a specific data type of an array or a mapping, and the sum value of the whole array or the mapping can be calculated, so that the verifier _ sum _ type () is actually the same as other common state variables, and can also be used as an invariant or put in a pre/post condition for constraint.

Further describing the process of converting the solid source code into Boogie intermediate language.

The conversion process is to compile the identity source code to generate an Abstract Syntax Tree (AST), each node of the AST from top to bottom represents a mutually contained type, the root node is a contact type, and the nodes are variable, function, expression and the like. Then traversing each node on the tree, and performing corresponding conversion according to the node type. For each contract name, function name, state variable and temporary variable appearing, id is added after the name in the conversion process, different variables or functions for distinguishing the duplicate names are converted into # id, the id is accumulated from 1 in the contract range, and if a plurality of contracts exist, the id is also accumulated among the plurality of contracts. The conversion includes the following categories:

(1) the type of data. The invention supports all basic data types of identity, including coolean, integer, address, array, mapping, etc. These basic data types are still of the same type after conversion. The invention provides three data modes for users to select, namely int, bv and mod modes. In the most basic int mode, integer is treated as a borderless arithmetic integer, so overflow holes are not detected. The bv mode is that each integer is stored in an array according to the bit form, and because each integer in the solid is 256 bits, the mode is not strong in expansibility and is not suitable for large numbers. The mod mode is that each mathematical operation has specific semantics, for example, addition operations including signed addition and unsigned addition, and the mode can check whether an overflow hole exists.

(2) A state variable. The state variable in the contract is converted into a global variable, and since one contract can create a plurality of instances, each instance has different addresses, the state variable is converted into a mapping type, a key is the address of each contract instance, the type is address, the value is a specific variable, and the type is the type of the variable.

(3) A function. Each function in the contract is converted to a procedure. The parameter in the procedure is added with an address type parameter __ this in addition to the original parameter of the function, representing the address of the contract. The original public and internal properties of the function are also applicable to the procedure. One function type in the identity is a modifier, i.e., a function modifier, which is used to change the behavior of a function and control the logic of the function. When the function is modified by the modifier, the constraint statement in the modifier needs to be added to the converted procedure, and the converted intermediate language code does not have the modifier function.

(4) Statements and expressions. Most of the Solidity statements can be directly converted into Boogie statements with the same semantics, such as variable declaration statements, assignment statements, conditional statements, loop statements while, function calls, return statements, and some ternary and binary expressions. In particular, the for loop statements and the dowhill loop statements are converted into while statements; the function call statement is converted to a call statement. For the return statement return, if the return is followed by an expression instead of a variable or constant, the expression is placed before the return and converted into an assignment statement, assigned to a new temporary variable, and then the return key is followed by the temporary variable. If there are nested call and assignment statements, they are also translated by means of the newly declared temporary variables.

(5) And (6) trading. The Solidiy language comprises a plurality of functions and variables which are specific to Etherns and are used for trading, and the variables and the functions need to be additionally processed during conversion. Each account in the ethernet house is associated with an address, and the balance in each account in the identity is represented by address. At the time of conversion, __ balance state variables of mapping type are added for each contract, and __ balance address records the balance change of the address. Meanwhile, the identity also indicates a message sender calling the function and transfer amount carried by calling the function by msg. When switching, the msg.sender parameter and the msg.value parameter are added to the parameter of each procedure. When one procedure calls another, its own address __ this is passed into the parameter as msg.

The function in identity sometimes has a payable attribute that indicates that the transfer is acceptable by calling the function, and the transfer amount is expressed in msg. In the conversion, the operation of updating balance of __ balanceis added in the procedure first, namely __ balance [ this ] is added with msg. The self-contained functions send and transfer in the identity realize the function of transferring between contracts. When converted to an intermediate language, send and transfer are directly converted to a modification to the global state variable __ balance, i.e., __ balance [ __ this ] is to decrease the transfer amount and __ balance [ recipient ] is to increase the transfer amount. Meanwhile, a require constraint is added before __ balances are modified, whether the balance in the contract account is larger than or equal to the transfer amount is judged, and if the balance in the account is insufficient, the transaction is directly rolled back.

(6) And (4) restraining. There are two ways in Solidity to represent constraints, one is a require, alert statement, and the other is a comment. The first constraint conversion (i.e. converting the constraint in the solid into the constraint of the intermediate language) is directly converted into the "assign" statement, and the location is not changed. In the second constraint conversion, the constraint conversion is placed behind the procedure statement, and the constraint is followed by the function body of the procedure. If the condition is precondition, the statement is converted into a require statement, and if the condition is postcondition, the statement is converted into an intensiure statement. If the constraint is invariant constraint of the contract layer, the constraint is converted into two sentences, namely, a require sentence and an ensure sentence, the require sentence ensures that the constraint is met before the function is entered, and the ensure sentence ensures that the constraint is met when the function is exported. If the constraint is the invariant constraint of the loop body, the transformed statement is still an invariant statement, and is placed after the while () condition, and the constraint is followed by the loop body.

If the constraint is cross-function constraint, two additional processes need to be added into the converted Boogie intermediate language code. The function a is assumed to have a precedence relationship with the function B, the function a is a function executed first, the function B is a function executed later, the function a modifies a certain state variable, and the function B depends on the modified state of the state variable, that is, the precondition of the function B contains the state variable. Then one new procedure after conversion only calls the function B, and the other procedure calls according to the correct execution relation, that is, calls the function B after calling the function a. In order to prove that the constraint of the function B can be met only after the function A is called, all modification statements related to state variables in the function A are extracted and put into the constraint of the converted procedure A, and the constraint is in the form of postcondition. If the first procedure is not verified, and the second procedure is verified, the postcondition of the function A is consistent with the precondition of the function B, and the precedence relationship between the function A and the function B is verified. Assuming that the function A and the function B have a mutual exclusion relationship, the function A modifies a certain state variable, and the function B depends on the state before the state variable is modified. Then one new procedure after conversion calls both functions a and B, and the other procedure calls only function a or function B. And extracting statements modified by the state variables in the function A and putting the statements modified by the state variables into the constraint of the procedure A. If the first procedure is not verified and the second procedure is verified, the situation that the post condition of the function A is inconsistent with the precondition of the function B is shown, and the mutual exclusion relationship between the function A and the function B is satisfied.

If the contract is a cross-contract constraint, namely a constraint condition for another contract is added in one contract, and then a function of the other contract is called, whether the function can meet the functional attribute of the constraint needs to be checked. This is accomplished by identifying another contract and its state variables and functions, modifying the constraint expression, and then inserting the constraint into the other contract at the corresponding location of the called function. The expression form of the cross-contract variable is "contictname. The controlname is the contract name of another contract, and the variable and function are its state variables and functions. The specific implementation mode is that an array is set when the contracts are converted into the intermediate language, each traversed contract is stored into the array, and then the array is searched according to the traversal of the ContractName. After the contract is positioned, the specific variable or function is positioned according to the variable name or the function name, and the variable or function replaces the ContractName.variable or the ContractName.function in the original constraint. After the replacement, the constraint is inserted into a corresponding position of the third-party contract, namely into the constraint of the called function. If the constraint is the constraint of the contract layer, the constraint is inserted into the constraint of the called function in the form of precondition and postcondition, and the constraint is ensured to be satisfied when the function is entered and the function is exited. If the function layer is the pre/post constraint, the function layer is directly inserted into the constraint of the called function, and the pre/post attribute is kept unchanged.

Further describing the process of formalizing a verification from an intermediate language document.

In specific implementation, the method is oriented to formal verification of the block chain intelligent contract, and an input file is a code file of 'star.sol' written in a solid language. The input parameters in the input code file comprise a verification mode 'int'/'bv'/'mod' besides a source code file name, the int mode is the most basic verification mode, and integer is taken as a borderless arithmetic integer, so that overflow holes cannot be detected by the int mode. The bv mode is that each integer is stored in an array in the form of bits. The mod mode is that each mathematical operation has specific semantics, and whether overflow holes exist can be checked.

Before a user inputs a ". about.sol" code file, custom attributes (contract constraints) need to be added into the Solidiy source code, except for the require and alert statements carried in the source code, the constraint attributes added by the user start with "// @ notice", and are followed by a constraint body. The functional constraints added by the user can be divided into three types according to the constraint expression forms, namely, the types of invariant constraint (invariant), pre-conditional constraint (precondition) and post-conditional constraint (postcondition), wherein for each type, different expression forms are represented as follows:

the Expression is an Expression that connects expressions on the left and right sides by an operator, and the expressions on the left and right sides can be variable or function calls. The function constraint can be divided into a contract layer constraint, a function layer constraint and a loop layer constraint according to the added position of the constraint, and the added positions are before the contract, before the function and before the loop body respectively. The method can be divided into a common scene and a combined transaction scene according to a constraint scene, wherein the combined transaction scene comprises a plurality of transaction scenes and a plurality of contract scenes. For a multi-transaction scenario, the transaction sequence is composed of the transaction initiator calling different functions of the same contract in sequence, and can be written as follows:

；

wherein

On behalf of the contract or contracts,

、

、

are respectively as

Different functions in the contract.

、

、

Having modifications or dependencies on the same state variable in a contract, e.g.

The value of the state variable x is modified from

To

To do so

The value of the required dependent state variable x is

Can account be transferred or some other operation, i.e.

Among them are statements that modify state variables, and

there is a constraint statement precondition for the state variable. Therefore, it says that

There is a precedence relationship between the f1 function and the f2 function in the contract. The constraint Expression in the scenario is of the type innovative, and the Expression is an Expression representing a functional relationship, such as

Is shown by

And

there is a function precedence order between them. The relationships between functions represented by the innovative type remain unchanged throughout the contract. For a multi-contract scenario, a transaction sequence where multiple contracts, written by a contract writer, call each other, may be written as:

;

wherein

、

、

On behalf of the different contracts, the contracts are different,

、

、

representing different functions in a contract, the sequence representing

Call out

，

And call up

。

And

contracts may be third party contract libraries whose functionality needs to be verified before the functions of the contracts are called, and for convenience, we add constraints to the called contracts. The constraint expression form in the scene comprises all forms, namely invariant, precondition and postcondition types, and the position of constraint addition also comprises all positions, namely before contract, before function and before loop body. The representation of the state variables and functions of the called contract takes the form'. An

Or

。

After adding constraints to the source contract, a complete input file ". sol" containing the constraints is obtained. Compiling the contract generates an abstract AST (syntax AST). Each node of the parse tree is a type that is mutually included, the root node is a contract type, and the child nodes are respectively a state variable type, a function type, an expression type, and the like. If the node type is a contract or function type and contains constraint information, then there will be a domain in the node that represents the constraint information. For the identity AST, each node of the tree needs to be traversed, corresponding conversion is carried out according to the node type, Boogie AST is generated, and Boogie intermediate codes are generated at the same time. For each contract name, function name, state variable and temporary variable appearing, id is added after the name in conversion, and different variables or functions for distinguishing the duplicate names are converted into # id. The converted code firstly defines an address type, namely an int type; and then __ balance global variables are added for simulating the accounts associated with each address in the ether house. The state variables in the source code are each converted to mapping type, which is the mapping of each address to a specific variable type. The functions in the source codes are all converted into the procedure, and the parameters in the procedure are added with this parameter, msg.sender parameter and msg.value parameter except the original parameters in the source code function. The procedure statement is followed by the constraint after the conversion, the constraint only has the form of requires and enseurs, the constraint contains position information, and the specific position is positioned when an error occurs in order to facilitate verification. And during constraint conversion of the contract layer, converting the constraint into a requires statement and an enseurs statement at the same time, and during constraint conversion of the function layer, converting the precondition into the requires statement and converting the postcondition into the enseurs statement.

When converting the constraint, the constraint type and the scene type need to be determined. If the type is invariant, the conversion is carried out into requires and esses statements at the same time, the precondition type is only converted into the requires statement, and the post condition is only converted into the esses statement. In the case of a contract-level constraint, the transformed data is added to the contract before each function. For different scenario types, it is necessary to identify whether it is a multi-transaction scenario or a multi-contract scenario. If the constraint includes a keyword such as "= = >" indicating a functional relationship, the multi-transaction scenario is determined, and if the constraint includes "C." (C is a contract name), the multi-contract scenario is determined. Two types of transaction scenarios are detailed below:

(1) in the case of a multi-transaction scenario, instead of simply converting the contract constraints into requires and esses statements before each function, 2 new procedures need to be added to the converted code. For example, if the constraint to be verified is "innovative funcA = = > funcB", the first procedure will call funcA and funcB simultaneously, while the second procedure will call funB only. And simultaneously, extracting statements modified by the state variables in funcA, converting the statements into events statements, and adding the events statements into postconditions of funA. Since funcB has constraint statements on state variables, funcB contains a precondition statement. When the funcA and the funcB are called simultaneously in the first procedure, the postconditions (sensues statements) of the funa and the preconconditions (reques statements) of the funB are consistent, and the verification is passed. And the second procedure only calls funcB, the precondition of the funcB cannot be satisfied, and the verification is not passed.

(2) In the case of a multi-contract scenario, the emphasis is on how to identify the functions and state variables of other contracts. For example in a contract

Middle call

To, for

Is constrained to a state variable

Then first find the constraint in the intermediate code

、

And

. When traversing different contracts of a ". sol" file, an array is declared and the traversed contracts are sequentially stored in the array. When the contract name of other contracts is identified in the present contract, the array is traversed to find the contract, i.e., the contract is identified

. Then all the procedures of the contract and the called function name are obtained

Comparing in sequence to determine

I.e. the position of the subsequent restraint placement. Then obtain

All state variables in the contract, the state variable name x in the contract is compared with the state variables in turn until the state variables are determined. The variable representation in the constraints in the identity source code is then converted to the identified variable, i.e., "x # id". For constraint types, no conversion is needed. Then put constraints into what we just found

Just before. To this end, a constraint on one contract is converted to a direct constraint on another contract. When verifying, if

In a contract

And the function passes the verification, and the function meets the function constraint which needs to be met.

In summary, the concrete examples and the detailed description of the identity conversion to Boogie are completed. The converted code will generate a ". bpl" file that is input into the Boogie validation tool, which will formally describe the intermediate code, formally validate it with the Z3 prover. And finally, analyzing the verification result into a readable result of the original identity contract, wherein the position information is recorded in the intermediate code, so that the position information is directly output when error information is output. The verification result comprises two types of OK and Error, each function of each contract is a line, the contract name and the function name are firstly output, and then the verification result is output. For example:

C1: funcA: OK

if the verification fails, the output information form is as follows:

C1: funcA: Error

--{position information}: Postcondition “postcondition expression” might not hold at end of function

the Position information is a source code Position that does not satisfy the constraint, and the postcondition expression is input constraint information, i.e., a Position where an error occurs and the constraint information are traced back, and output.

It is noted that the disclosed embodiments are intended to aid in further understanding of the invention, but those skilled in the art will appreciate that: various alternatives and modifications are possible without departing from the invention and scope of the appended claims. Therefore, the invention should not be limited to the embodiments disclosed, but the scope of the invention is defined by the appended claims.

Claims

1. An intelligent contract formal verification method suitable for combined transaction, wherein the combined transaction refers to the situation that a plurality of transactions are included in a scene or one transaction relates to a plurality of contracts; the method is characterized in that functional semantics needing to be verified are inserted into an intelligent contract, contract constraints are added based on an Ethengfang intelligent contract source code, the contract constraints comprise cross-function constraints and cross-contract constraints in a combined transaction scene, then the source code after the contract constraints are added is converted into corresponding types, sentences, expressions and constraints in an intermediate verification language, and the intermediate verification language file is automatically subjected to formal verification through a verifier; the method comprises the following steps:

1) adding contract constraints based on a solid source code of the Ether house intelligent contract, wherein the contract constraints are used for representing functional attributes which need to be met by the Ether house intelligent contract; the added contract constraints include: invariant constraints of the contract layer; pre-conditional constraints and post-conditional constraints of the function layer; a loop invariant constraint; the sum of the arrays or mappings; also include cross-function constraints and cross-contract constraints in the combined trading scenario;

the cross-function constraint is the constraint on the function relationship in a multi-transaction scene; designing a constraint form of function precedence order and a constraint form of function mutual exclusion relation, and adding the constraint forms at the beginning of a contract;

the method comprises the steps of containing a plurality of contracts under a cross-contract scene, wherein cross-contract constraints, namely constraints under the plurality of contract scenes, can comprise invariant constraints of a contract layer, pre/post conditional constraints of a function layer and cross-function constraints; adding function constraints or state variable constraints of other contracts in one of the contracts;

2a) for the conversion of cross-function constraint, two procedures are added in the converted intermediate language code; the method specifically comprises the following steps:

2. An intelligent contract formal verification method for combined transactions according to claim 1, wherein the scenario includes a transaction sequence in which multiple transactions are manipulated by a contract caller, calls being initiated in sequence to different functions of a contract; a scenario involves multiple contracts being a sequence of transactions written by a contract writer, one contract initiating a call to a function in another contract.

3. A smart contract formal verification method for combinatorial transactions as in claim 1 wherein in step 1) the constraint form of the precedence order in the cross-function constraint is expressed as:

the constraint form of the mutual exclusion relationship in the cross-function constraint is represented as:

the writing form and the position of the constraint in the cross-contract constraint are the same as those of the constraint itself, the state variable or the function calling another contract uses the form of '. The left side of the' is the contract name of the other contract, and the right side is the state variable name and the function name in the other contract.

4. An intelligent contract formal verification method applied to combined transactions according to claim 1, wherein in step 2), the transformation of contract constraints is divided into a transformation of require, an assertion statement mode representing constraints and a transformation of annotation mode representing constraints; the conversion method for representing the constraint in the mode of the require statement and the assert statement is specifically to directly convert the constraint into the assert statement, and the position is unchanged; the annotation mode represents the transformation method of the constraint, specifically, the constraint is placed after the procedure statement after the transformation, and the function body of the procedure is followed by the constraint.

5. An intelligent contract formal verification method for use with combined transactions according to claim 4 in which the conversion of contract constraints is specifically:

6. A method of intelligent contract formal verification for combined transactions according to claim 1, characterised in that in step 2 aa) the verification of precedence relationships across function constraints is specifically: extracting all modification statements related to state variables in the function A which is executed firstly, and putting the modification statements into the constraint of the converted procedure A, wherein the constraint form is postcondition; if the first procedure verification fails and the second procedure verification passes, it indicates that the postcondition of the function a executed first is consistent with the preconcondition of the function B executed later, that is, the constraint of the function B can be satisfied only after the function a is called, and the precedence relationship between the functions a and B is verified.

7. A smart contract formal verification method applicable to combinatorial transactions according to claim 1 wherein in step 2 ab) the verification of the mutually exclusive relationship across the function constraints is specifically: one newly added procedure after conversion calls the functions A and B at the same time, and the other procedure only calls the function A or the function B; simultaneously, extracting statements modified by the state variables in the function A and putting the statements into the constraint of the procedure A; and if the first procedure fails to pass the verification, the second procedure passes the verification, namely the post condition of the function A is inconsistent with the precondition condition of the function B, and the mutual exclusion relationship between the function A and the function B is verified.

8. An intelligent contract formal verification method for combined transactions according to claim 1, wherein in step 2 b), said locating a contract, in particular setting an array upon conversion to an intermediate language, storing each traversed contract in the array, and then traversing the array according to the contract name of another contract to locate a contract.

9. An intelligent contract formal verification method for use in combination transactions according to claim 1 in which said intermediate verification language is Boogie; the verifier adopts a verifier Z3.

10. An intelligent contract formal verification system suitable for combined transaction, based on the intelligent contract formal verification method suitable for combined transaction of claim 1; the method comprises the following steps: contract constraint establishing module, intermediate language conversion module, formal verification module; wherein:

the contract constraint establishing module is used for adding contract constraints which need to be met by the intelligent contracts of the Etheng;

the intermediate language conversion module is used for converting the Ethernet intelligent contract Solidity source code with contract constraint into Boogie intermediate language;

and the formal verification module is used for performing formal verification according to the intermediate language file.