CN112581140B

CN112581140B - Intelligent contract verification method and computer storage medium

Info

Publication number: CN112581140B
Application number: CN202011572924.0A
Authority: CN
Inventors: 不公告发明人
Original assignee: Xi'an Xinxin Information Technology Co ltd
Current assignee: Anhui Xinxin Science And Technology Innovation Information Technology Co ltd; Guangdong Shenxin Science and Technology Innovation Information Technology Co.,Ltd.
Priority date: 2020-12-24
Filing date: 2020-12-24
Publication date: 2022-07-29
Anticipated expiration: 2040-12-24
Also published as: CN112581140A

Abstract

The invention discloses an intelligent contract verification method and a computer storage medium, wherein the intelligent contract verification method comprises the following steps: step 1, obtaining a control flow graph according to an intelligent contract, wherein the control flow graph comprises a node marked with an initial mark and edges among a plurality of nodes, and when the node is a node containing assertion, the node is also marked with assertion, wherein the node comprises a non-cyclic node and a cyclic node; step 2, obtaining the invariant of each node according to the type of the node based on a preset sequence; and 3, obtaining a verification result according to the assertion implicit result of the invariant of the node. The verification method of the invention can verify the correctness of the intelligent contract. In addition, the verification method has wider application range to intelligent contracts.

Description

Intelligent contract verification method and computer storage medium

Technical Field

The invention belongs to the technical field of intelligent contracts, and particularly relates to an intelligent contract verification method and a computer storage medium.

Background

Blockchains are a rapidly developing field of research in recent years, and it was first proposed by Satoshi Nakamoto a concept in bitcoin blockchains, which is based on a variety of technologies, such as blockcipher chains, peer-to-peer communication, distributed systems, etc. The advent of bitcoin networks has made possible financial transactions between strangers without the involvement of third party authorities. Later, an ethernet platform was further developed, which is an open-source, intelligent contract-enabled, common blockchain platform. Since then, smart contracts have received much attention in many areas, such as financial institutions and supply chains.

A smart contract is a computerized transaction agreement that enforces the terms of the smart contract to meet the user's requirements, such as votes and transactions. An intelligent contract may be considered a computer program that can customize transaction execution logic on a blockchain, where the intelligent contract is written primarily in a well-behaved programming language, such as the solid (a contractual programming language) in an etherhouse. The non-modifiable nature of blockchains makes intelligent contracts unchangeable once deployed onto blockchains. Furthermore, some grammatical properties of the solid language are not as good as other computing and languages (e.g., javascript), e.g., storage properties of variables and the concept of fallback functions, even though some developers have experience with traditional programming languages, they are often in error. Therefore, since code writing is not robust, there are a large number of attacks, causing a huge economic loss. For example, The DAO attack results in a loss at that time equivalent to approximately $ 6000 million. Attackers find a hole in the splitDAO function and they can implicitly loop through the fallback function for a single transaction to remove the ethernet token repeatedly over and over again. It is therefore crucial to verify the correctness of smart contracts before they are deployed.

With the increasing attack on intelligent contracts, tools have been developed to analyze the correctness of intelligent contracts. For example, Luu et al developed a symbolic execution engine for a solid intelligent contract, named eyente (intelligent contract analysis tool), that systematically analyzed various functions in the intelligent contract to identify vulnerabilities. Nikolic et al developed a symbolic analyzer named MAIAN that can perform symbolic execution analysis during execution of a smart contract, analyzing smart contract bytecode to check for vulnerabilities such as "suicide", "volatile", and "greedy" in the smart contract. However, the focus of the above work is to test smart contracts, rather than to verify their correctness. For example, these symbolic execution engines typically set a limit on the number of loop iterations or function calls in order to cover those bounded program paths with generated test cases.

Currently, existing methods available for validating smart contracts include Securfy, Zeus, SOLC-verify, and VerX. The first three methods convert the Solidity program into the existing intermediate languages (i.e., Datalog, LLVM, and Boogie) and reuse the existing verification tools. This approach has two limitations. First, because authentication facilities are not designed for smart contracts, they can only play a limited role in certain specific attributes of the smart contract. Secondly, these methods are based on abstract interpretation, which often leads to false positives due to the fact that abstract methods and abstract domains are coarser. In particular, Securify cannot verify numerical attributes such as overflow; zeus false alarm is serious, and the SOLC-verify path coverage rate is not high. VerX applies deferred predicate abstraction (symbol-based execution and abstraction) to verify the correctness of intelligent contracts when transactions are executed. But VerX does not support the case of implicit loop callbacks caused by a fallback function and requires setting bounds for loop iterations in the function.

Therefore, it is an urgent problem to provide a method that can be applied to an intelligent contract and can accurately verify the intelligent contract.

Disclosure of Invention

In order to solve the above problems in the prior art, the present invention provides an intelligent contract verification method and a computer storage medium. The technical problem to be solved by the invention is realized by the following technical scheme:

an intelligent contract verification method comprising:

step 1, obtaining a control flow graph according to an intelligent contract, wherein the control flow graph comprises a node marked with an initial mark and edges among a plurality of nodes, and when the node is a node containing assertion, the node is also marked with assertion, wherein the node comprises a non-cyclic node and a cyclic node;

step 2, obtaining the invariants of each node according to the type of the node based on a preset sequence;

and 3, obtaining a verification result according to the assertion implicit result of the invariant of the node.

In one embodiment of the present invention, the step 1 comprises:

step 1.1, acquiring the intelligent contract;

step 1.2, compiling the source code of the intelligent contract into byte codes;

and step 1.3, obtaining the control flow graph according to the byte codes.

In one embodiment of the present invention, the step 2 comprises:

when the node is a non-cyclic node, obtaining the invariant of the non-cyclic node according to the strongest post condition;

and when the node is a loop node, obtaining the invariant of the loop node according to an iteration method.

In an embodiment of the present invention, obtaining the invariant of the acyclic node according to a strongest postcondition includes:

and obtaining the invariant of the current acyclic node according to the invariant of the parent node of the current acyclic node and the command of the parent node to the edge of the current acyclic node.

In an embodiment of the present invention, obtaining the invariant of the loop node according to an iterative method includes:

step 2.21, randomly generating a plurality of groups of first variable assigned value data, wherein the plurality of groups of first variable assigned value data form a first variable assignment set;

step 2.22, marking the first variable assigned value data to obtain second variable assigned value data based on the control flow graph;

step 2.23, obtaining candidate invariants according to a Linear Arbitrary algorithm based on the mark of the second variable assigned value data;

and 2.24, verifying the candidate invariant according to the father node of the loop node, if the verification is successful, the candidate invariant is the invariant of the loop node, if the verification is failed, adding a counter example of generated variable assignment to the first variable assignment set to obtain a second variable assignment set, and repeating the steps 2.22 to 2.24 until an invariant generation result of the loop node is obtained.

In one embodiment of the invention, said step 2.22 comprises:

step 2.221, the groups of first variable assignment data are sequentially input into the control flow graph, the loop node is executed to be terminated, and during execution, when the loop node is visited again, the first variable assignment reaching the loop node is also added into the first variable assignment set;

and 2.222, marking the first variable assigned value data according to preset conditions to obtain the second variable assigned value data, wherein the preset conditions comprise that the assertion is not violated during the execution, the assertion is violated during the execution and the assertion is proved during the execution.

In one embodiment of the invention, said step 2.24 comprises:

step 2.241, based on the strongest post condition, obtaining the verification invariant of the loop node according to the father node of the loop node;

step 2.242, judging whether the verification invariant of the loop node can push out the candidate invariant, if yes, the verification is successful, the candidate invariant is the invariant of the loop node, if not, the verification fails, adding a counter example of generated variable assignment to the first variable assignment set to obtain a second variable assignment set, and repeating the steps 2.22 to 2.24 until an invariant generation result of the loop node is obtained.

In an embodiment of the present invention, when the invariant generating result of the loop node is that the invariant of the loop node is not obtained, the invariant of the loop node is obtained according to the heuristic algorithm.

In one embodiment of the present invention, the step 3 comprises:

and checking whether the invariant of the node containing the assertion in the control flow graph implies the assertion or not, if so, successfully verifying the intelligent contract, and if not, failing to verify the intelligent contract.

An embodiment of the present invention also provides a computer storage medium having a computer program stored therein, which when executed by a processor implements the method steps of any of the above embodiments.

The invention has the beneficial effects that:

the verification method of the invention is different from the traditional method for testing the intelligent contract by fuzzing test and symbolic execution, and the verification method of the invention can verify whether the given intelligent contract with assertion is correct. The verification process of the invention is completed through the steps of intelligent contract formalization, invariable derivation of each node, intelligent contract verification and the like, so that the correctness of the intelligent contract can be verified. In addition, the verification method has wider application range to intelligent contracts.

The present invention will be described in further detail with reference to the accompanying drawings and examples.

Drawings

FIG. 1 is a flow chart of a method for verifying an intelligent contract according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of a contract including internal function calls provided by an embodiment of the present invention;

FIG. 3 is a schematic diagram of basic operation definitions in an intelligent contract provided by an embodiment of the invention;

FIG. 4 is a schematic diagram of an execution rule provided by an embodiment of the invention;

FIG. 5 is a schematic diagram of the strongest post-condition provided by an embodiment of the present invention;

FIG. 6 is a schematic diagram of an algorithm for invariant of acyclic nodes according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of an algorithm for invariant of a loop node according to an embodiment of the present invention;

FIG. 8 is a schematic diagram of an overview of a contract verification algorithm provided by an embodiment of the present invention;

fig. 9 is a schematic diagram of an sVerify engine according to an embodiment of the present invention;

fig. 10 is a schematic diagram of a computer device module according to an embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to specific examples, but the embodiments of the present invention are not limited thereto.

Example one

For testing and verifying intelligent contracts, there are currently mainly the following methods:

And (3) fuzzy testing: fuzz testing is a method of discovering software faults by constructing unexpected input data and monitoring abnormal results of target software during operation. When the intelligent contract is subjected to fuzzy test, a random engine is used for generating a large amount of random data to form executable transaction, the random engine dynamically adjusts the generated data by referring to the feedback of the test result, and therefore the intelligent contract state space as much as possible is explored. And analyzing the state of each transaction based on a finite state machine, and detecting whether an attack threat exists.

Symbol execution techniques: the core idea of symbolic execution is to execute a program using symbolic values instead of specific values. Any variable of indeterminate value during program analysis, including environmental variables and inputs, can be replaced with symbolic values. "execute" in symbolic execution refers to parsing instructions on the executable path of a program, updating the execution state of the program according to the semantics thereof, and is equivalent to interpretive execution. The general process of detecting intelligent contract vulnerabilities by symbolic execution is: firstly symbolizing variables of uncertain values in the intelligent contract according to needs, then interpreting instructions in an execution program one by one, updating an execution state in the interpretation and execution process, collecting path constraints, and performing fork (repeated etching) execution at branch nodes so as to finish the exploration of all executable paths in the program and find out security problems. The constraint solving technology can solve the path constraint collected in the symbolic execution, judge whether the path is accessible, and detect whether the value of the variable is in accordance with the program safety regulation or possibly in accordance with the condition of vulnerability existence at a specific program point.

Based on the abstract interpretation: and generating a vulnerability mode based on the rule and analyzing the correctness of the vulnerability mode.

And (3) detecting the model: the intelligent contracts are converted into different intermediate representations, and then analyzed by using the existing intermediate representation analysis tools. For example, the smart contract is converted into an F program, thereby reducing the contract verification problem to an F program verification problem. However, this method is currently deficient because it misses loops in the translation process. For example, the Zeus tool proposed by Kalra et al, can translate smart contracts into LLVM bytecodes and apply abstract interpretation techniques to interpret the correctness of the contracts. The SOLC-VERIFY can translate the intelligent contract into Boogie intermediate language and analyze the intelligent contract by utilizing a verification tool chain of a Boogie program. Translation is done at the source code level, which allows users to write annotations directly in the intelligent contract source code.

The theorem proves that: the formal semantics of the EVM are defined using a K framework, and the KEVM provides a basis for theorem proving the Etherhouse intelligent contracts. For example, the EVM may be defined using a K framework and then some security properties of the etherhouse intelligence contract may be demonstrated using a KEVM.

However, the above technique has the following disadvantages:

For the fuzzy testing method, test inputs are selectively generated by static and dynamic techniques to find key holes, but this is very prone to false negatives.

For symbolic execution techniques, it is often affected by path explosion. Thus, these methods may limit the search space, e.g., set a limit on the number of jumps or function calls. Thus, these methods are mainly used to test smart contracts, rather than to verify their correctness.

For formal verification methods based on abstract interpretation, the security is limited by the abstract interpretation (e.g., a fixed abstract domain). For example, with the intelligent contract verification tool Securify, numerical attributes such as overflow cannot be verified. The intelligent contract verification tool VerX introduces a delay predicate abstraction method based on symbolic execution and abstraction technology, and verifies the intelligent contract in the transaction execution process. However, VerX only supports contracts without external calls, which is equivalent to a fallback function that cannot be verified into intelligent contracts under certain circumstances, and clearly this restriction is not justified.

For formal verification methods based on model detection, some implicit cycles are missed in the conversion process due to the need to convert smart contracts into F programs (e.g., LLVM bytecode, bootie). Because the current intermediate language of translation is not designed for intelligent contracts, certain features of intelligent contracts cannot be well supported.

A method for validating an intelligent contract based on a theorem proving method. At present, the method is not fully automatic, needs manual intervention, needs to master some formal semantemes and related frameworks, and defines the target safety property by utilizing the professional knowledge, which has higher requirements on the personnel of the manual intervention.

Example one

Referring to fig. 1, fig. 1 is a schematic flowchart of an intelligent contract verification method according to an embodiment of the present invention. Based on the above reasons, an embodiment of the present invention provides an intelligent contract verification method, where the intelligent contract verification method includes:

step 1, obtaining a Control Flow Graph (CFG) according to an intelligent contract, wherein the Control Flow Graph comprises a node marked with an initial mark and edges among a plurality of nodes, and when the node is a node containing assertion, the node is also marked with assertion, and the node comprises a non-cyclic node and a cyclic node.

In this embodiment, The smart contract may be converted into a control flow graph, which may represent all paths that The smart contract traverses during execution, and therefore The control flow graph may include a node marked with an initial mark and edges between several nodes, wherein The nodes are The current state after The execution of The corresponding program, and The edges are The actions to be performed from one node to another, i.e. a set of commands to drive one node to another node, thereby forming an edge connecting two nodes, see, for example, fig. 2, The smart contract shown in fig. 2(a) is a simplified version of The DAO contract, which represents a function withdraw that allows The investor msg.sender to retrieve his investment and set The investor's balance to 0, and fig. 2(b) is a control flow graph corresponding to fig. 2(a), and in fig. 2(b), The node root and The node stop represent The entry and exit of The smart contract, respectively, the control flow graph also comprises a node n ₁ Node n ₂ Node n ₃ Node n ₄ Node n ₅ The edge includes an edge I ₅ Edge I ₆ Edge I ₇ Edge I ₇ ^* Edge I ₈ Edge I ₉ Edge I ₁₀ Wherein the edge I ₅ Corresponding to the 5 th command in FIG. 2(a), edge I ₆ Corresponding to the 6 th command in FIG. 2(a), and so on, in FIG. 2(b), node n ₅ Called assertion node, i.e. node n ₅ For a node containing an assertion, then the node n ₅ Marking with corresponding assertion this, area ═ oldq-amt, marking all nodes with an invariant, wherein the initial mark of the invariant is true, updating the initial mark to the corresponding invariant when obtaining the invariant, and in a control flow graph, generally speaking, the nodes are marked with the initial mark of the invariant, and the nodes are marked with the corresponding invariant after being marked with the initial mark of the invariantIncluding acyclic nodes and cyclic nodes, in which the cyclic node is the head node of the start of the cycle, e.g. node n in FIG. 2(b) ₄ And the other nodes are non-cyclic nodes. In addition, if the intelligent contract also comprises an implicit edge, the implicit edge is also introduced into the control flow graph and is used for capturing the control flow generated by function calling between the intelligent contracts. In fig. 2(b) there are two implicit edges linking node n4 to the root node and the stop node to node n4, indicated by dashed lines, which capture the call between contracts to the withdraw function.

For ease of understanding, The present embodiment illustrates FIG. 2, in which The intelligent contract shown in FIG. 2a is a simplified version of The DAO contract. The function withdraw allows the investor msg.sender to retrieve his investment and set the investor's balance to 0. Sender is here, however, a contract account, possibly under the control of an attacker. The fallback function in this malicious contract is elaborated to call The withdraw function in The DAO contract again. According to the mechanism of EVM, the fallback function is automatically invoked when some ethernet coins are sent into the smart contract (triggered by line 7 of fig. 2 a). This would allow an attacker to take an ethernet token that is not owned. In this case, the line 10 assertion of FIG. 2a (contract balance decreased by amt after line 9 of FIG. 2 a) will fail. This vulnerability is also referred to as a reentry vulnerability. To prevent this vulnerability, the contract toyDAO _ B in FIG. 2d introduces a variable lock to ensure that the transfer of line 10 of FIG. 2d can only be performed once. In addition, it should be noted that the variable lock can only be modified by the function withdraw. The statement in line 8 of fig. 2d requires the value of lock to be false and only if this condition is met will lock be updated to true and the amount of atm ethernet credits be sent to the investor msg. If the callback operation occurs again, the condition of line 8 will fail, preventing line 10 from executing again. Thus, the assertion of line 11 is always satisfied.

In a particular embodiment, step 1 may particularly comprise steps 1.1 to 1.3, wherein:

and 1.1, acquiring an intelligent contract.

And 1.2, compiling the source code of the intelligent contract into byte code.

And step 1.3, obtaining the control flow graph according to the byte codes.

In this embodiment, first, an intelligent contract to be converted is obtained, then a solid compiler is used to compile a source code of the intelligent contract into a byte code (/ byte code), and then the byte code is divided into basic blocks, wherein one basic block is an instruction sequence and has only one entry point and one exit point; execution of a basic block can only start at its entry point and control can only exit at its exit point, so if control enters a basic block, every instruction in the block will be executed. Therefore, the control position from one basic block to another basic block is a node, and finally, the nodes are connected, so that the control flow graph is obtained.

In this embodiment, in order to clearly understand the present solution, the present solution explains the basic operation definition of the intelligent contract, the function of the intelligent contract, the symbolic semantics, the node invariants, and the contract correctness:

Since each function in the smart contract may be invoked individually through a transaction, emphasis is placed on validating the smart contract from the function level. Based on this, the following is defined, which describes the instruction representation for the execution of an intelligent contract function:

define 3.1 (instruction). The basic operations in the smart contract are defined as follows.

Referring to FIG. 3, SSTORE (p, v) represents writing a location p with a value v to the blockchain world state, and SLOAD (p) represents reading a value p from the blockchain world state. x: ═ Exp represents the assignment of the value of expression Exp to variable x. The expression Exp may be a variable, a value, or an arithmetic operation on two expressions (e.g., addition, multiplication MUL, etc.). The branch command "if b" calculates a Boolean expression b, which may be a Boolean constant true or false. Boolean expressions also include comparison operators used with Boolean operators (NOT, AND, OR), such as ISZERO AND cmp (LT (less), GT (greater), EQ (equal)). "assert b" means that the Boolean expression b should be asserted. The commands "call f" and "return" represent a call and a return to the function f, respectively.

Define 3.2 (a function of the intelligent contract). The intelligent contract function is a tuple (N, root, E, I, A), where N is a set of nodes (representing control positions); root belongs to N and is an entrance node;

Is a set of edges marked with the commands defined in definition 3.1, Com is a command; n → P (expression) is a function that labels each node with an invariant; n → P is a function that marks each node with an assertion.

By the above definition, when a function of the intelligent contract C is given, the source code is first compiled into an Ethereum Virtual Machine (EVM) bytecode by a Solidity compiler and then the bytecode is disassembled. The function of the intelligent contract is defined as a control flow graph with marks through the mapping (referring to the ethernet yellow paper) of the byte codes and the instructions defined by the ethernet EVM. The node marker function I is defined as I (N) true and each N ∈ N. In addition, the definition of the node marking function a is that if the contract code position denoted by n has an "alert b" instruction, a (n) is b; otherwise a (n) true. For example, as shown in the CFG of the twidraw function of fig. 2(g), the invariant of the node n5 is I (n5) ═ z (locked ^ this. balance ═ oldq-amt), and the assertion is denoted as a (n5) ═ old-amt.

Define 3.3 (symbolic semantics). Let (N, root, E, I, A) be a function of a smart contract whose (symbolic) semantics are defined as the tagged transformation system (S, init, → S, I, A), where S is a set of symbolic states, each state S being a triplet (N, Γ, V), where N ∈ N, Γ is the function call stack, a container that records the function call state, i.e. stack, V is a symbolic valued function that maps program variables to expressions of symbolic variables, init ∈ S is the initial state,

Are translation relationships that comply with the semantic rules defined in fig. 4.

In fig. 4, the rule Store is used to determine how to update the value of a certain storage location, and after execution of a command, n is moved to the next node n ', and the location p in the storage V' is updated by the value of V. The rule Assignment updates the value of the x variable in V' according to the evaluation of expression Exp in value V (expressed by function eval). The execution rules in Sload and Assertion are similar. After the command is executed, n is moved to the next n' and the assignment and function call stack are not changed. The execution rules in Branch are similar except that variable assignments in V that do not satisfy condition b are excluded in the updated V' (denoted as function upd). The rule Invoke may capture the contract internal function call, move n to the root node of the called function n' if the balance bal in the current contract is positive, add the values of the function f and the local variable V Γ to the call stack Γ (f, V Γ) of the function. The rule Return pops up the top of the stack element and moves to the caller node with a new value by which the local variable value of the caller node is updated.

The path p of a function in an intelligent contract is<n0、c0、n1、c1、…、cn、nn+1>An alternating sequence of nodes and commands of the form where for all 0 ≦ i ≦ n, n0 ≦ root,

A trace (symbol) is a path in the symbol semantics and, by definition, each trace corresponds to a path in a contract. Thus, the trace tr is tr<s0，c0，s1，c1，…，cn，sn+1>An alternating state/command sequence of the form, where for all 0 ≦ i ≦ n, s0 ≦ init,

the last state of trace sn +1 is denoted by last (tr). The symbolic trace set of function F is represented by trace (F), which is a set of traces of its symbolic semantics, where each trace is a sequence whose header is the initial state, and the alternating "state/command/state" conforms to the conversion relationship.

Define 3.4 (node invariant). Given an intelligent contract function F ═ N (root, E, I, a), for all tr ∈ trace (F) s.t. N (last (tr)) N, last (tr) indicates that the state of the last node is sn, N (last (tr)) N, and indicates that the node corresponding to the last state of trace is N, this statement is to illustrate the relationship between the state and the node, and if and only if last (tr)) Φ, one is predicted to be invariant of node N (denoted by I (N)), this is true. Where s | ═ denotes that φ is satisfied by the variable assignments of s. In short, in the case where all paths leading to node n satisfy φ, φ is invariant at node n, i.e., its variable assignment satisfies φ when path v reaches n.

Define 3.5 (contract correctness). Given that each function Fi in the contract C alone is (Ni, rooti, Ei, Ii, Ai), Fi represents one function in the smart contract if

Then C is correct.

Thus, based on the constructed CFG and its semantics, the correctness of the contract can be verified by checking whether the invariant for any node can imply a relevant assertion. If so, the contract is correct.

And 2, obtaining the invariant of each node according to the type of the node based on a preset sequence.

In this embodiment, the preset sequence is an execution sequence of the intelligent contract, and in the control flow graph, because the nodes include the acyclic nodes and the cyclic nodes, there are two methods for deriving the node invariants for the acyclic nodes and the cyclic nodes. First, given a node n, the invariant can be inferred by computing the strongest postcondition of the invariant associated with nodes preceding node n. Second, if the node n is the head node of the loop (for/while statement or fallback function loop call), in this case, the invariant of the node needs to be obtained according to an iterative method.

In a specific embodiment, step 2 may specifically include: when the node is a non-cyclic node, obtaining the invariant of the non-cyclic node according to the strongest post condition; and when the node is a loop node, obtaining the invariant of the loop node according to an iteration method.

In this embodiment, when the node that needs to obtain the invariant at present is the non-cyclic node, obtaining the invariant of the non-cyclic node according to the strongest post condition includes: and obtaining the invariants of the current acyclic node according to the invariants of the father node of the current acyclic node and the commands of the father node to the edge of the current acyclic node.

That is, when the node that needs to obtain the invariants currently is an acyclic node, the invariants of the node may combine the invariants of the parent node of the node and commands corresponding to edges from the parent node to the node that needs to obtain the invariants currently, so as to obtain the invariants of the node that needs to obtain the invariants currently.

For the derivation invariant, given a node n, which is an acyclic node, then if and only if there is a transition from node m to node n, then m is the parent node of n. The invariants of node n are inferred based on the invariants of all parent nodes by computing a strongest postcondition. Before introducing the working principle of reasoning, we first define how to compute the strongest postconditions.

Define 3.6 (strongest postcondition). Given a command c ∈ Com and a precondition φ, the definition of the strongest postcondition sp (c, φ) please see FIG. 5, where FIG. 5 preconditions φ is SSTORE commanded (storage [ p ] ]→ v) coverage. Note this notation

If so, overwrite store [ p ]]A related predicate; otherwise, the postcondition is storage [ p ]]The connection to phi. The strongest post-condition for assignment is two cases. One is similar to the SSTORE command if it assigns a variable. The other is the concatenation of preconditions φ and assignments, which overwrite the variable x in Exp and φ. For the Branch and Assert commands, the strongest condition is the concatenation of φ and condition b. For the command SLOAD or return, the strongest post condition is φ. It may be noted that the strongest post-condition for command call f is φ, except that all constraints associated with global variable GV are removed. Note, symbol

Indicating that all storage variables in phi are eliminated. This is designed as a function call, f can potentially modify the value of the storage variable by calling other functions in the contract. The rules may be improved by contract-level invariant reasoning methods. The embodiment performs basic static analysis and can identify the variable of the storage type modified by each function in the contract. With this information, the present embodiment enhances the above rule: all constraints on the storage variables are removed except those modified only in the current function. This allows the CFG to capture all callback/callback operations for the current function. As an example shown in fig. 2(a), given the condition oldq this is balance, the command mt balance msg sensor ]The strongest post condition at row 6 is old, blue ^ amt, balance [ msg]。

Referring to fig. 6, fig. 6 is a schematic diagram of an algorithm of an invariant of an acyclic node according to an embodiment of the present invention. The algorithm in FIG. 6 details how the invariants of the nodes are updated based on the strongest postcondition, first setting the initial values of Ψ to false and Ψ to predicate, and calculating sp (c, I (m)) for each transition (m, c, n) (sp (c, I (m)) as the strongest postcondition for a logic statement, where (m, c, n) represents that node m has transitioned to node n after executing command c. Their disjunction (i.e., logical or) is a constraint that must be satisfied by the invariants at node n. This is because n can only be reached through one parent of n. Finally, on line 6 of FIG. 6, the invariant at node n is set to the connection of I (n) and Ψ, so that it can be progressively enhanced over time. Taking node n2 in fig. 2(b) as an example, the algorithm in fig. 6 can infer that the invariant of node n2 is old q is this which is equal to balance amt is balance msg sensor, which is enhanced by executing the command of row 6 of the algorithm in fig. 6 from node n1, where the invariant of node n1 is old q is this.

The algorithm in fig. 6 may be ineffective for looping, although it may infer the invariance of the non-looping nodes. That is, given a loop of the form < n0, c0, n1, c1, n2 …, nk, ck, n0>, the invariant for node n0 is based on self-recursive inference and may never terminate. Thus, the present embodiment distinguishes nodes that are the head nodes of certain loops (i.e., nodes that represent the beginning of loop statements or external function calls) and applies different methods to infer invariants of these nodes. The general idea is an iterative "guess and check" method for synthesizing loop invariants. This iterative approach includes three phases, namely data tagging, learning (or guessing), and verification.

Therefore, in this embodiment, when a node that needs to obtain an invariant at present is a loop node, obtaining the invariant of the loop node according to an iteration method includes:

and 2.21, randomly generating a plurality of groups of first variable assigned value data, wherein the plurality of groups of first variable assigned value data form a first variable assignment set.

Specifically, referring to fig. 7, fig. 7 is a schematic diagram of an invariant algorithm of a loop node according to an embodiment of the present invention, where F in fig. 7 is a CFG of a function, n is a head node of a loop, i.e., a loop node, Var is a variable set associated with the loop, each loop node corresponds to a variable set Var, and an assignment set (denoted as DS, i.e., a first variable assignment set) of variables in the variable set Var of the loop node n is initially generated by randomly sampling a plurality of sets of first variable assignment data on line 1. The size of the initial set of assignments DS is determined empirically, and in general, a set of rather large random samples often helps to efficiently learn the candidate invariants.

Therefore, in the embodiment, multiple groups of first variable assignment data (i.e., assignments of variables in the intelligent contract) can be randomly generated as required, and the assignments of all the variables can form the first variable assignment set.

And 2.22, marking the first variable assigned value data based on the control flow graph to obtain second variable assigned value data.

In a specific embodiment, step 2.22 may specifically include:

step 2.221, a plurality of groups of first variable assignment data are sequentially input into the control flow graph, the loop node is executed to be terminated, and in the execution period, when the loop node is accessed again, the first variable assignment reaching the loop node is also added into the first variable assignment set;

and 2.222, marking the first variable assigned value data according to preset conditions to obtain second variable assigned value data, wherein the preset conditions comprise that the assertion is not violated during the execution, the assertion is violated during the execution and the assertion is proved during the execution.

In particular, the program executes from loop node n to termination based on the initial input of the control flow graph and the specific first variable assignment data from the first set of variable assignments DS. During execution, the loop node n can be accessed again and the variable assignments upon reaching the loop node n are also added to the first set of variable assignments DS. Next, the present embodiment marks each first variable assignment data in the first variable assignment set DS as three types, i.e., "+" indicates positive, "-" indicates negative, and "e" indicates error. The flag is marked according to whether the first variable assigned data s0 satisfies i (n) (loop invariant for loop node n, which is currently unknown) and whether the assertion is eventually violated, starting with an initial value s0 and becoming s after zero or more iterations. In particular, it is labeled:

Mark "+": if s0 satisfies I (n), and the assertion is not violated during execution.

The mark "-": if s0 violates I (n), and the assertion is violated during execution.

The label "e": if s0 satisfies I (n), the assertion is violated during execution, i.e., the assertion is certified during execution.

The first variable-valued data valuation labeled with "+" must satisfy the (unknown) loop invariant; the first variable valued data valuation labeled with "-" cannot satisfy the loop invariant; an assignment marked with an "e" is a specific counter-example that proves an assertion. In this embodiment, the labeled first variable assigned data is the second variable assigned data.

Taking the example in fig. 2(d) as an example, assume that line 10 in fig. 2(d) randomly samples 2 values (2, 0, 20, 18), (5, 1, 30, 25) and assigns variables (amt, lock, oldq, this. After the execution of these variable assignments of

line

10, 1 more assignment is added to the first set of variable assignments DS: (2, 0, 20, 16). Thereafter, the assignment { (5, 1, 30, 25) } is marked with "+"; and { (2, 0, 20, 18), (2, 0, 20, 16) } is marked with "-".

And 2.23, obtaining candidate invariant according to a Linear Arbitrary algorithm based on the mark of the second variable assigned value data.

Specifically, after classifying the variable estimates, the present embodiment further checks whether any of the estimates are marked as "e" by the function checkce (ds). If so, the invariant generator function returns a "false proof" and an estimate as a counterexample, i.e., lines 4-6 in FIG. 7. Otherwise, the present embodiment calls the function lerrininv to start the learning phase (i.e. line 7 in fig. 7). This embodiment guesses the candidate invariants for the loop nodes in the form of a classifier that separates the value labeled "+" from the value labeled "-". Specifically, the present embodiment adopts a most effective and strongest classification technique based on support vector machine and decision tree classification, i.e. the Linear algorithm mentioned in the paper "a Data-drive CHC solution", which infers candidate invariants in any combination or separation form of Linear inequalities, i.e. the present embodiment distinguishes the second variable valued Data labeled as "+" from the second variable valued Data labeled as "-" by the Linear algorithm to infer the candidate invariants of the cyclic nodes.

And 2.24, verifying the candidate invariant according to the father node of the loop node, if the verification is successful, the candidate invariant is the invariant of the loop node, if the verification is failed, the counter example of the generated variable assignment is added to the first variable assignment set to obtain a second variable assignment set, and the steps 2.22 to 2.24 are repeated until the invariant generation result of the loop node is obtained.

In a specific embodiment, step 2.24 may specifically include:

step 2.241, based on the strongest post condition, obtaining the verification invariant of the cyclic node according to the father node of the cyclic node;

and 2.242, judging whether the verification invariant of the loop node can push out the candidate invariant, if so, the verification is successful, the candidate invariant is the invariant of the loop node, if not, the verification is failed, adding the counter example of the generated variable assignment to the first variable assignment set to obtain a second variable assignment set, and repeating the steps 2.22 to 2.24 until the invariant generation result of the loop node is obtained.

Specifically, the way of obtaining the invariant according to the acyclic node, that is, the invariant of the parent node is used, and the verification invariant of the cyclic node is derived based on the strongest post-condition. After the verification invariants of the loop nodes are obtained, it is necessary to judge whether the verification invariants of the loop nodes can push out candidate invariants, for example, if the verification invariants are x ═ 1 and x >0, then x >0 can be pushed out through x ═ 1, at this time, the verification is successful, the candidate invariants are the invariants of the loop nodes, if the verification invariants cannot be pushed out, the verification fails, a counter example of the generated variable assignment is added to the first variable assignment set, the first variable assignment set of the counter example is added as the second variable assignment set, then the candidate invariants are generated by using the second variable assignment set according to the modes from step 2.22 to step 2.24, then the verification is performed, if the verification is successful under the set conditions, the invariants of the loop nodes are obtained, if the verification is not successful under the set conditions, the invariants of the loop nodes cannot be obtained, the setting condition is, for example, a preset time unit, that is, a constant value of the cyclic node is generated in a certain time range according to the above-described method.

In the verification phase (i.e., lines 8-9 in FIG. 7), the function valid (φ, F, n) is called to check whether the learned candidate invariant φ is indeed an invariant (induction through each path in the loop). That is, the present embodiment attempts to label node n with candidate invariants and apply the algorithm in FIG. 6 to propagate it to each path starting with n and ending with the parent of n. For all parent nodes m, the invariants are generalized and onlyWhen the temperature is higher than the set temperature

In this embodiment, this is achieved by solving for the satisfaction of sp (I) (m), c) Λ neg (φ). If it is satisfiable for all parent nodes m, then φ is generalized, from which it can be determined to be invariant. Otherwise, a counter-example of the variable assignment form will be generated and added to the data set DS for the next round of generation of invariants.

In addition, when the invariant generation result of the loop node is that the invariant of the loop node is not obtained, obtaining the invariant of the loop node according to a heuristic algorithm (heuristic algorithm).

In particular, the loop invariants learned by this method of the present embodiment are attribute-guided. But the entire learning process may time out due to the excessive number of guessing and checking iterations. In the case that the algorithm in fig. 7 does not return invariants after a preset time unit, the present embodiment connects the assertion with the candidate invariants of the current candidate as candidate invariants for verification by using a simple heuristic algorithm. For example, in the toyDAO _ B contract shown in fig. 2(d), the candidate invariant generated by the algorithm in fig. 7 is lock ═ true. However, when it is verified, a timeout occurs, and then a heuristic algorithm is applied, and the candidate invariant is strengthened to lock ^ this.

In one embodiment, step 3 comprises: and checking whether the invariant of the node containing the assertion in the control flow graph implies the assertion or not, if so, successfully verifying the intelligent contract, and if not, failing to verify the intelligent contract.

Specifically, through the above description, the present embodiment can perform contract verification by the overall algorithm shown in the algorithm in fig. 8. Given an intelligent contract C with N functions, a control flow graph is first constructed for each function at action 1 in fig. 8. For each node n in each function F, the corresponding node invariant may be updated with line 8 and line 10 in fig. 8. Whenever an invariant is stable (i.e., reaches a fixed point), then it is checked whether its invariant is implicitly asserted for each node. If this implicit check fails at a certain node, the counter-example returned by the SMT solver is checked to see if it is the actual counter-example (performed symbolically). If so, the counterexample is returned as evidence to certify the pseudo-contract. Contract validation succeeds if all assertions are implied by invariants on the corresponding node.

For example, the function withdraw () in the contract shown in fig. 2(d) initially has the invariant of each node as true, and then incrementally enhances the node invariant by the method of the present embodiment. In this example, the invariants of all nodes except node n5 are updated by the algorithm of FIG. 6. Node n5 is the head node of the loop, i.e., node n5 is the loop node, whose invariant is updated by the algorithm in FIG. 7. Then, it is checked whether the invariants of each node imply their associated assertions. In this example, the only assertion is contained at node n 5. The invariant (locked) of the node n5 shown in fig. 2(g) implies its assertion (this). Thus, the algorithm concludes at line 21 in FIG. 8 that the contract validation was successful.

The method can be executed by a verification engine in a form named sVerify, and can directly support the verification of the intelligent contract written by the solid language. sVerify is based on the establishment of a loop invariant generation technique. Loop invariants are a set of properties that remain true within a loop body, each iteration, and are typically used to prove the correctness of a program or pseudo-code. Simply put, loop invariant refers to the property that is true at the beginning of the loop and at each iteration within the loop. That is, a correct loop body, loop invariance and loop termination conditions must be satisfied at the end of the loop.

Given an intelligent contract with assertions, sVerify will automatically construct a marked control flow graph for each function. Each node in the control flow graph is labeled as an invariant (initially true). Through reasonable reasoning rules, invariants related to nodes and contained in explicit or implicit circulation are subjected to active testing, machine learning and symbolic execution, and based on the characteristics of intelligent contracts, invariant learning is continuously enhanced before assertions implied by the invariants are verified or proved.

The overall workflow of sVerify is shown in fig. 9. It takes as input the source code of the intelligent contract (including the user-specified assertion) and outputs the verification result. sVerify first constructs a marked control flow graph where some nodes are marked with an assertion (if this node contains an assertion). The marked CFG is then taken as input to the verifier by means of (r) in fig. 9. The verifier iteratively infers an invariant for each node and then checks whether the invariant implies a relevant assertion for that node. If so, the contract is validated.

There are two methods for the derivation of the invariant. First, given a node n, the invariant is inferred by computing the strongest postcondition of the invariant associated with nodes preceding node n. Second, if node n is part of a loop (for/while statement or fallback function loop call), it is cumbersome to break the invariants in this case. In ② in FIG. 9, sVerify implements a built-in loop invariant generator to obtain loop invariant. The loop invariant generator consists of three parts, namely a label generator, a learning period and a checker. The label generator executes circular paths using specific variable assignments and marks these assignments as negative or positive examples. The learner infers candidate invariants from the labeled samples during the classification process. The checker checks whether the candidate invariant learned from the learner in (r) in fig. 9 satisfies the predicate attribute. If not, a counterexample is fed into the tag generator in the fifth in FIG. 9, and this new counterexample will also be added to the data sample set for marking. In addition, a new candidate invariant is also learned. This iterative process continues until the validation program successfully checks for a valid invariant. This valid invariant is then returned to the verifier for verification in sixth in fig. 9. In the data marking phase of the tag generator, if the data sample is marked as a false negative violating the assertion property, the verification process terminates immediately, which false negative will be returned to the user in the last step and report that the smart contract is incorrect.

The verification method of the invention is different from the traditional method for testing the intelligent contract by fuzzing test and symbolic execution, and the verification method of the invention can verify whether the given intelligent contract with assertion is correct. The verification process of the invention is completed through the steps of intelligent contract formalization, invariable derivation of each node, intelligent contract verification and the like, so that the correctness of the intelligent contract can be verified.

The invention applies the learning and derivation method of the circulation invariant to the intelligent contract formal verification for the first time, compared with some formal verification methods at present, the verification method of the invention has lower requirements on the specialization of personnel, and the verification can be carried out according to the verification method of the invention without mastering complex formal verification theory and related frameworks.

Through experimentation, the present invention presents advantages over prior formal verification methods (tools) in both respects:

the verification method can test the traditional known bugs (overflow and reentry), and compares an automatic intelligent contract formal verification engine Zeus based on abstract interpretation with a formal verification tool SOLC-VERIFY based on a model verification engine Boogie.

The verification method provided by the invention verifies the specific assertion in the contract, and compared with other tools, the result is more accurate.

Example two

The invention also provides a computer readable storage medium, in which a computer program is stored, and the computer program realizes the steps of the first embodiment and the second embodiment when being executed by a processor.

Generally, the computer readable storage medium can be disposed in a computer device, see fig. 10, which can include units or modules of a processor, a communication interface, a computer readable storage medium, and a communication bus, wherein the processor, the communication interface, and the memory are communicated with each other through the communication bus,

a computer-readable storage medium for storing a computer program;

a processor, configured to implement the following steps when executing a program stored on a computer-readable storage medium:

The communication bus mentioned in the above computer device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

The communication interface is used for communication between the electronic equipment and other equipment.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

The computer device may be: desktop computers, laptop computers, intelligent mobile terminals, servers, and the like. Without limitation, any electronic device that can implement the present invention is within the scope of the present invention.

For the computer device/storage medium embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment one and the embodiment two.

The computer equipment provided by the embodiment of the invention is used for calculating the size and the thickness of the opening of the steel mesh correspondingly and reasonably by detecting the deformation of the specific ball of the BGA, so that the welding is carried out according to the parameter, the proper soldering tin amount can be obtained at each ball of the BGA, the open welding caused by the deformation of the BGA is overcome to the maximum extent, and the reliability of the welding of each ball of the BGA is ensured.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean 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 invention. 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 described in this specification can be combined and combined by those skilled in the art.

While the present application has been described in connection with various embodiments, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed application, from a review of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the word "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, this application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module" or "system. Furthermore, the present application 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. A computer program stored/distributed on a suitable medium supplied together with or as part of other hardware, may also take other distributed forms, such as via the Internet or other wired or wireless telecommunication systems.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus and computer program products according to embodiments of the application. 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.

The foregoing is a more detailed description of the invention in connection with specific preferred embodiments and it is not intended that the invention be limited to these specific details. For those skilled in the art to which the invention pertains, several simple deductions or substitutions can be made without departing from the spirit of the invention, and all shall be considered as belonging to the protection scope of the invention.

Claims

1. An intelligent contract verification method, comprising:

Step 2, obtaining the invariant of each node according to the type of the node based on a preset sequence;

when the node is a loop node, obtaining invariant of the loop node according to an iteration method;

obtaining the invariant of the loop node according to an iteration method, comprising:

step 2.24, verifying the candidate invariant according to the father node of the loop node, if the verification is successful, the candidate invariant is the invariant of the loop node, if the verification is failed, adding a counter example of generated variable assignment to the first variable assignment set to obtain a second variable assignment set, and repeating the steps 2.22 to 2.24 until an invariant generation result of the loop node is obtained;

2. The intelligent contract verification method of claim 1, wherein step 1 comprises:

step 1.1, acquiring the intelligent contract;

and step 1.3, obtaining the control flow graph according to the byte codes.

3. The intelligent contract verification method of claim 1, wherein said step 2 comprises:

and when the node is a non-cyclic node, obtaining the invariant of the non-cyclic node according to the strongest post-condition.

4. The intelligent contract validation method of claim 3, wherein obtaining the invariant of the acyclic nodes according to a strongest post-condition comprises:

5. The intelligent contract validation method of claim 1, wherein said step 2.22 comprises:

6. The intelligent contract validation method of claim 1, wherein said step 2.24 comprises:

7. The intelligent contract verification method according to claim 1, wherein when the invariant of the loop node is not obtained as a result of the generation of the invariant of the loop node, the invariant of the loop node is obtained according to a heuristic algorithm.

8. The intelligent contract verification method of claim 1, wherein said step 3 comprises:

9. A computer storage medium, characterized in that a computer program is stored in the computer storage medium, which computer program, when being executed by a processor, carries out the method steps of any one of claims 1-8.