CN116842496A

CN116842496A - Language-independent intelligent contract verification method and device, electronic equipment and storage medium

Info

Publication number: CN116842496A
Application number: CN202310232397.6A
Authority: CN
Inventors: 李希萌; 施智平; 张倩颖; 王国辉; 关永
Original assignee: Capital Normal University
Current assignee: Capital Normal University
Priority date: 2023-03-06
Filing date: 2023-03-06
Publication date: 2023-10-03

Abstract

The embodiment of the disclosure discloses a language-independent intelligent contract verification method, a device, electronic equipment and a storage medium, wherein the method comprises the following steps: the method comprises the steps that semantic rules of a given intelligent contract programming language are formally expressed based on general semantic predicates of big-step operation semantics; describing the functional correctness of the function in the given intelligent contract as the corresponding relation between each initial pattern and the termination pattern set; describing the execution process of the key substructure in the form of the corresponding relation between each initial pattern and each termination pattern set for the key substructure in the given intelligent contract source code; describing the influence of external contract function call on the state of the blockchain in the form of the corresponding relation between each initial pattern and the termination pattern set; describing the influence of execution of the given intelligent contract after reentry on the state of the blockchain in the form of a corresponding relation between the initial pattern and the termination pattern set; an interactive proof is performed.

Description

Language-independent intelligent contract verification method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computer science and technology, and in particular, to a language independent intelligent contract verification method, device, electronic apparatus, and storage medium.

Background

Formalized verification is a technology for verifying the correctness and safety of a system based on a mathematical model of the system, and specifically comprises technical means such as theorem proving, model detection, abstract interpretation, equivalence test and the like. Through formal verification, the system can be proved to meet the functional correctness requirement under one type or all input. Formal verification can cover infinite number of different input data values and execution paths of a system, and one important method is to cover all possible execution paths of the system in the correctness and safety properties of the system by means of full-scale words or similar characteristics in mathematical logic, and prove that the system meets the target properties by means of logical reasoning. Other methods also include abstracting possible input data and execution paths of the system, thereby summarizing an infinite number of specific data values and execution paths into a finite number of categories, and then expressing verification targets and completing verification based on the categories.

The theorem proving method of formal verification is a verification method for proving the correctness and safety of the system based on logical reasoning, and is often used in combination with an theorem prover, and comprises an automatic theorem prover and an interactive theorem prover. When the target system or target property is complex, the certification process is often done in an interactive theorem prover. The interactive theorem prover allows the prover to be provided with a proof thread by a person during the proving process. In addition, the interactive theorem prover can check whether the proving process can be decomposed into simple steps conforming to mathematical axiom and basic logic rules, thereby maximally avoiding errors caused by omission of a verifier or bug in the implementation of the prover. Currently commonly used interactive theorem provers include Coq, isabelle, HOL, HOL Light, lean, etc.

Similar to formal verification, testing and simulation are also important means for confirming the functional correctness of the system. However, in testing and simulation, only the execution of the system under a limited number of input data values and execution paths can be observed, and under input data values and execution paths that are not covered, the system may still be in error. Compared with testing and simulation, formal verification provides a higher level of correctness and security guarantee for a target system. At the same time, however, formal verification techniques are more demanding on the mathematical, logical literacy of the user and may result in higher time costs. Nevertheless, formal verification has been recognized as one of the important means of providing correctness and security for various types of systems where operational errors can result in high costs.

Software programs are a class of typical target objects that can use formal verification techniques to provide security for their correctness. In order to formalize a software program, a model of the software program needs to be given by means of mathematical logic firstly, an important method is to give strict definition to the meaning of various grammar structures of a computer language used for writing the program, namely, the formal semantics of the program language are defined. One type of more widely used formal semantics is operation semantics (operational semantics), which focus on changes in program state caused by operations performed by program statements. In operational semantics, a "semantic pattern" (semantic configuration, also simply referred to as "pattern") is generally used to reflect the control state of a program (intuitively corresponding to where execution proceeds to the program) and the data state (including information such as the values of the respective variables).

The blockchain is a distributed data structure for maintaining data synchronization among nodes, maintaining multi-party consensus and preventing data tampering. Blockchains often store data in a series of block structures, concatenate the blocks into a chain structure, and maintain copies of the chain structure at each node of the network. After new data is generated, a data block assembled by a certain node is selected through a consensus algorithm, the data block is attached to the tail part of the blockchain, and the change of the blockchain structure is synchronized to the whole blockchain network.

In a blockchain system, a smart contract is a software program that describes the task logic of a multi-party transaction. Various important applications of the blockchain system, such as digital asset trading, supply chain management, product tracing, electronic copyright authentication, etc., can be realized by means of intelligent contracts. A typical smart contract may be expressed as a set of variables and a series of functions. A function in a smart contract may express that a particular operation is performed when a particular condition is met, the value of a variable in the contract (i.e., the contract state) is modified, a function in the present contract is called, an external contract is called, or a transfer is made to an external contract. Operations performed by the smart contract may trigger exceptions, causing the contract state to rollback.

As a software program, errors and vulnerabilities may be included in a smart contract-a typical class of problems is that the implementation of functions in a smart contract deviates from the intended function of the function due to the effects of a programmer's negligence or an attacker. In recent years, errors and vulnerabilities in smart contracts have resulted in loss of a large number of digital assets with catastrophic consequences. Formal verification techniques of smart contracts are highly valued and are being studied in recent years to ensure that smart contracts perform their intended functions correctly.

The formal verification of intelligent contracts is carried out by firstly establishing a mathematical model of the intelligent contracts, wherein the main means is to define formal semantics of an intelligent contract programming language and describe execution behaviors and results of various grammar structures of the intelligent contract programming language. In theorem-proving-based verification methods, it is often necessary to define a logical reasoning system (program logic) that is semantically reliable with respect to formalization. The meaning of "reliable" here is: for any given smart contract, if the logical inference system is used to infer that the smart contract should meet functional correctness requirements, then the correctness conditions expressed by the formal semantics of the smart contract language must be met. Program logic helps simplify the process of proving program correctness based on formalized semantics-as in the case of correctness proofing based directly on operational semantics, it is often necessary to complete proofing using induction methods for loop and recursive structures, while using program logic avoids the use of induction methods.

For each smart contract programming language, it is a difficult task to design the corresponding program logic and prove its reliability with respect to formalized semantics. In fact, even in the mainstream general-purpose programming language, only some of the sub-languages of the C language, java language, currently have reliable program logic. Smart contract programming languages are a wide variety (e.g., solidity, vyper, michelson, yul, move, etc.), and new languages are still being defined, designing the corresponding program logic for each language and proving its reliability is a difficult task.

To avoid the burden of designing the corresponding program logic for each specific language, one existing method is to translate different intelligent contract program languages into some intermediate language, and then complete intelligent contract verification by means of a verification system of the intermediate language. However, the correctness of translation into an intermediate language is difficult to be effectively guaranteed.

Language independent program verification techniques are another program verification technique that can be adapted to multiple program languages simultaneously. In language independent program attestation techniques, the semantics of the program language are defined in some generic form, after which verification is done on the target program using a verification process based on the generic semantic definition form. The language-independent program proving technology can simplify the process of directly proving the functional correctness of the program based on the semantics, can be suitable for a plurality of different program languages (only the formalized semantics of the target language can be given), and does not depend on the translation of different languages to the same intermediate language.

Heretofore, language-independent program certification techniques have been used only to accomplish formal verification of simple sequential programs. Smart contracts are software programs with distributed features-each smart contract Ctr can call other smart contracts on the blockchain, and called smart contracts can call Ctr before returning, so that execution of program code re-enters Ctr, which is called re-entry of called smart contracts into Ctr. The writer of the smart contract may not be able to know in advance which code execution will be triggered after an invocation of the external contract or after a transfer of the external contract (e.g., in an ethernet, transfer of the external contract will trigger execution of the code therein, including potential reentry of the current contract), but still hopes that the correct execution of the written contract will not be affected by the external contract. Thus, in the validation of a smart contract, a description may be made with respect to the unknown environment of a given smart contract (including essentially all potential external contracts that the contract calls) to support reasoning about the source code of the given smart contract. While using language-independent program attestation techniques, a formal description of the complete object program needs to be given-for smart contracts, the complete object program includes all external contracts in the authenticated smart contract and its unknown environment. How to solve the description problem of the unknown environment of the intelligent contract in the language-independent program proving technology, thereby truly realizing the intelligent contract verification which is simultaneously applicable to different program languages and has reliable form semantics, and being an important problem to be solved in the aspect of the block chain system form verification.

Disclosure of Invention

The embodiment of the disclosure provides a language-independent intelligent contract verification method, a device, electronic equipment and a computer-readable storage medium.

In a first aspect, an embodiment of the present disclosure provides a language independent smart contract verification method, including:

the method comprises the steps that semantic rules of a given intelligent contract programming language are formally expressed based on general semantic predicates of big-step operation semantics;

describing the functional correctness of the function in the given intelligent contract as the corresponding relation between each initial pattern and the termination pattern set of the given intelligent contract, wherein the description is called a formal specification of the functional correctness of the given intelligent contract;

describing the execution process of a key substructure in the given intelligent contract source code in the form of the corresponding relation between each initial pattern and the termination pattern set as verification auxiliary information of the key substructure in the given intelligent contract source code;

describing the influence of the external contract function call on the blockchain state in the form of the corresponding relation between each initial pattern and the termination pattern set as verification auxiliary information of the external contract function call in the given intelligent contract in the language-independent intelligent contract verification process;

Describing the influence of the execution of the given intelligent contract after reentry on the blockchain state in the form of the corresponding relation between the initial pattern and the ending pattern set of the given intelligent contract, and taking the influence as verification auxiliary information of the reentry execution of the given intelligent contract;

and performing interactive verification on the formal specification of the functional correctness of the given intelligent contract by using the formalized expressed semantic rules, verification auxiliary information of key substructures in the source code of the given intelligent contract, verification auxiliary information of external contract function calls in the given intelligent contract and verification auxiliary information of reentry execution of the given intelligent contract, if the verification process can be completed, determining that the realization of the function in the given intelligent contract can meet the functional correctness requirement specified by the interface of the given intelligent contract, and if the verification process cannot be completed, indicating that the given intelligent contract does not meet the functional correctness description.

In a second aspect, an embodiment of the present invention provides a language independent smart contract verification apparatus, including:

the expression module is configured to formally express the semantic rules of the given intelligent contract programming language based on the general semantic predicates of the big step operation semantics;

A first description module configured to describe functional correctness of functions in a given smart contract as a correspondence of each initial pattern of the given smart contract to a set of ending patterns, such description being referred to as formal specification of functional correctness of the given smart contract;

the second description module is configured to describe the execution process of the key substructure in the form of the corresponding relation between each initial pattern and the termination pattern set for the key substructure in the given intelligent contract source code, and the execution process is used as verification auxiliary information of the key substructure in the given intelligent contract source code;

the third description module is configured to describe the influence of external contract function calls on the blockchain state in the form of the corresponding relation between each initial pattern and the termination pattern set for the external contract function calls in the source code of the given intelligent contract, and the influence is used as verification auxiliary information of the external contract function calls in the given intelligent contract in the language-independent intelligent contract verification process;

a fourth description module, configured to describe an influence of execution of the given smart contract after reentry on a blockchain state in a form of correspondence between an initial pattern and a termination pattern set of the given smart contract, as verification auxiliary information of reentry execution of the given smart contract;

And the verification module is configured to interactively prove the formal specification of the functional correctness of the given intelligent contract by using the formalized expressed semantic rules, verification auxiliary information of key substructures in the source code of the given intelligent contract, verification auxiliary information of external contract function call in the given intelligent contract and verification auxiliary information of reentry execution of the given intelligent contract, and if the verification process can be completed, the realization of the function in the given intelligent contract can be determined to meet the functional correctness requirement specified by the interface of the given intelligent contract, and if the verification process cannot be completed, the given intelligent contract cannot meet the functional correctness description.

The functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above.

In one possible design, the structure of the above apparatus includes a memory for storing one or more computer instructions for supporting the above apparatus to perform the corresponding method, and a processor configured to execute the computer instructions stored in the memory. The apparatus may further comprise a communication interface for the apparatus to communicate with other devices or a communication network.

In a third aspect, an embodiment of the present disclosure provides an electronic device, including a memory, a processor, and a computer program stored on the memory, where the processor executes the computer program to implement the method of any one of the above aspects.

In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium storing computer instructions for use by any one of the above-described apparatuses, which when executed by a processor, are configured to implement the method of any one of the above-described aspects.

In a fifth aspect, embodiments of the present disclosure provide a computer program product comprising computer instructions for implementing the method of any one of the above aspects when executed by a processor.

The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects:

the traditional intelligent contract verification method based on the interactive theorem proving device can directly prove the functional correctness of the intelligent contract based on formal semantics of a specific intelligent contract programming language, namely reasoning about the characteristics of circulation, internal function call, external contract function call and the like in the contract by means of induction method; or building a logic reasoning system suitable for a specific intelligent contract programming language, wherein cross-language universality cannot be realized; or translate a given smart contract language into a unified intermediate language-there is no guarantee of accurate preservation of semantics in translation. In contrast, in the technical solution provided by the embodiments of the present disclosure, a reliable smart contract verification process is established based on a generic description form (generic semantic predicate) of the smart contract language form semantics. And after the semantics of a specific intelligent contract program language are given by using a general semantic description form, directly obtaining the verification process of the intelligent contract written by the language. The intelligent contract proving process of the scheme has cross-language universality, and the problem that the semantic equivalence of translation among different languages is difficult to guarantee is solved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

Other features, objects and advantages of the present disclosure will become more apparent from the following detailed description of non-limiting embodiments, taken in conjunction with the accompanying drawings. In the drawings:

FIG. 1 illustrates a flow diagram of a language independent smart contract validation method according to an embodiment of the present disclosure;

FIG. 2 illustrates a flow diagram of one implementation of an intelligent contract validation process, according to an embodiment of the present disclosure;

FIG. 3 illustrates an architecture diagram for building a smart contract validation system, according to an embodiment of the present disclosure;

FIG. 4 illustrates a block diagram of a language independent smart contract validation apparatus according to an embodiment of the disclosure;

fig. 5 is a schematic diagram of an electronic device suitable for use in implementing a language-independent smart contract validation method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement them. In addition, for the sake of clarity, portions irrelevant to description of the exemplary embodiments are omitted in the drawings.

In this disclosure, it should be understood that terms such as "comprises" or "comprising," etc., are intended to indicate the presence of features, numbers, steps, acts, components, portions, or combinations thereof disclosed in this specification, and are not intended to exclude the possibility that one or more other features, numbers, steps, acts, components, portions, or combinations thereof are present or added.

In addition, it should be noted that, without conflict, the embodiments of the present disclosure and features of the embodiments may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

The object of the present disclosure is to provide a solution that can directly perform functional correctness proof of a smart contract based on formal semantics (e.g., big-step operation semantics) of a smart contract program language, and that does not require the use of induction methods for complex control flow structures such as loops, recursive calls, external contract function calls, reentrants, etc. in the smart contract. "functional correctness" of interest in this disclosure refers to the fact that for each function in a smart contract, assuming that the contract state and actual parameters before the function call satisfy a certain condition (which may be referred to as a "pre-condition" in program verification), then after the function returns, the contract state and the function return value need to satisfy an expected condition (which may be referred to as a "post-condition" in program verification). Compared with the testing means, the formal verification means provided by the present disclosure can realize complete coverage of all input data and execution paths meeting certain conditions, but not coverage of a small number of data points and execution paths, of the intelligent contract function. The method and the system provided by the disclosure can solve the problem that the existing intelligent contract form verification technology cannot be simultaneously applied to a plurality of different intelligent contract programming languages, and help to reliably verify intelligent contracts written in corresponding languages.

FIG. 1 illustrates a flow diagram of a language-independent smart contract validation method according to an embodiment of the present disclosure. As shown in fig. 1, the language-independent smart contract verification method includes the steps of:

in step S101, formally expressing the semantics of a given intelligent contract programming language based on the universal semantic predicates of the big step operation semantics;

in step S102, describing the functional correctness of the function in the given smart contract as a correspondence between each initial pattern and a set of ending patterns of the given smart contract, such description being referred to as a formal specification of the functional correctness of the given smart contract;

in step S103, describing, for a key substructure in the source code of the given smart contract, an execution process of the key substructure in a form of a correspondence between each initial pattern and the termination pattern set, as verification auxiliary information of the key substructure in the source code of the given smart contract;

in step S104, describing, for an external contract function call in the source code of the given intelligent contract, an influence of the external contract function call on a blockchain state in a form of a correspondence between each initial pattern and a termination pattern set, as verification auxiliary information of the external contract function call in the given intelligent contract in a language-independent intelligent contract verification process;

In step S105, describing the influence of the execution of the given smart contract after reentry on the blockchain state in the form of the correspondence between the initial pattern and the final pattern set of the given smart contract, and using the influence as verification auxiliary information for reentry execution of the given smart contract;

in step S106, the formalized semantic rule, the verification auxiliary information of the key substructure in the source code of the given smart contract, the verification auxiliary information of the external contract function call in the given smart contract and the verification auxiliary information of the re-entry execution of the given smart contract are used to interactively prove the formal specification of the functional correctness of the given smart contract, if the verification process can be completed, it is determined that the implementation of the function in the given smart contract can meet the functional correctness requirement specified by the interface of the given smart contract, and if the verification process cannot be completed, it is indicated that the given smart contract does not meet the functional correctness description thereof.

FIG. 2 illustrates a flow diagram of one implementation of an intelligent contract validation process, according to an embodiment of the present disclosure. As shown in FIG. 2, the process takes as input general semantic predicates of big-step operation semantics, formal conventions of intelligent contract functional correctness, and verifies that the intelligent contract functions conform to the formal conventions. The reliability of the process (i.e., if a smart contract written in a certain language passes the verification of the process, the smart contract satisfies its functional correctness specification, and the terminating state generated by the execution of each function of the smart contract in any state satisfying the initial condition satisfies the user requirement) can provide a guarantee for different smart contract program languages only by proving once for a universal semantic predicate.

Based on the universal semantic predicates, the operational semantics of a particular smart contract programming language X may be defined, thereby materializing the semantic predicate-based smart contract verification process. After the definition of the operation semantics is completed, any intelligent contract written in the X language is given in a generic form a formal specification of its functional correctness-specifying all termination states that each function call is allowed to reach.

To complete verification of a given smart contract using a specialized language-independent program verification process, verification assistance information needs to be provided regarding key substructures in the smart contract such as loops, internal function calls, external contract function calls, contract reentry execution, and the like. During verification, it is relatively easy to obtain the source code of the function (i.e., the internal function) in the verified smart contract, but in many cases (e.g., the smart contract needs to respond to requests of any external contracts and send messages to those external contracts), it is difficult to obtain the source code of the external smart contract called by the verified smart contract.

In program logic oriented to a particular programming language, verification assistance information about loops may be expressed as loop invariants, verification assistance information about internal function calls may be expressed as function contracts (function contract), and verification assistance information about external contract function calls may be expressed as contract invariants (contract invariant). The loop invariance, i.e. a certain logical expression regarding the state of the program, satisfies: if the expression is established before a round of execution, the expression is established after the round of execution. The so-called contract invariance, i.e. some logical expression about the state of the smart contract, satisfies: if the expression is established before a call to the smart contract, the expression is also established after said call to the smart contract.

In language independent program verification, verification assistance information about various types of different grammar structures needs to be expressed in a unified form because the verification process lacks knowledge about specific program languages, program statements. In the present disclosure, verification assistance information regarding structures such as loops, internal function calls, external contract function calls, and the like is collectively expressed as a series of tuples (c, P), where c is an initial pattern (i.e., a semantic pattern reflecting an initial state of a program) including control states of the program corresponding to the structures such as loops, internal function calls, external contract function calls, and the like to be executed, and data states, and P is a set of termination patterns obtained after c is executed. The termination pattern includes control states and data states of the program. In some embodiments, the control state of the initial pattern or the termination pattern corresponds to a location where the program is executed, and may be expressed by a code to be executed in the program, and the data state includes data information such as a value of each variable in the program.

External contract function calls may trigger execution of unknown code, thus requiring verification assistance information regarding its execution effect to be provided without relying on specific external contract code. In the use of the existing language-independent program verification technology, no description about the unknown environment of the program exists to support the distributed program verification, so that a technical scheme for verifying intelligent contracts comprising external contract function calls and contract reentry based on the language-independent program verification technology does not exist yet.

FIG. 3 illustrates an architecture diagram for building an intelligent contract validation system, according to an embodiment of the present disclosure. As shown in FIG. 3, the verification system works on the computer system hardware and the operating system running thereon. The language independent program verification framework involved in the method is formalized in a high-level logic theorem proving device (such as Coq, isabelle and the like) running in an operating system so as to eliminate artificial errors in the reliability proving of the verification process and support the functional correctness proving of intelligent contracts based on the interactive theorem proving device. For each smart contract programming language, the operating semantics of the language are formalized in the form of semantic predicates in a verification framework that can be embodied as a version that can be used to verify the smart contract written in the language. For each intelligent contract which is written in the same language and needs to be verified, formalizing the termination pattern set allowed by the corresponding initial pattern of each function call of the contract, providing the needed verification auxiliary information, and using a specific verification framework to give out the proof that the intelligent contract meets the formalizing rules.

It should be noted that, in the following description, it is assumed that each smart contract exists in one account on the blockchain, and each account has a unique address. This is consistent with the case in blockchains such as ethernet, super ledger (Hyperledger Fabric) and the like. Despite the lack of account concepts in some blockchain platforms, in such platforms, smart contracts remain distributed, inter-callable on-chain program code, and the methods presented by the present disclosure remain applicable.

Embodiments of the present disclosure are described in detail below.

The step S101, that is, a step of formally expressing the semantic rule of the given intelligent contract programming language based on the universal semantic predicate of the big step operation semantic, further includes the following steps:

a) The programming language for a given smart contract determines the composition of its initial and final patterns of big-step operation semantics.

b) The general semantic predicates are materialized, definition of the materialized general semantic predicates is given according to situations, and each situation expresses a corresponding relation between an initial pattern and a termination pattern determined by program execution.

c) The definition of the embodied universal semantic predicates is formally expressed in an interactive theorem prover.

The large-step operation semantics of the program language are operation semantics, and the result of complete execution of the program statement is characterized. The large-step operation semantics of a smart contract programming language can be described by a series of rules that can be expressed for any language by means of the following generic semantic predicates:

wherein c, c ₁ ,......,c _n For the initial pattern, r ₁ ,......,r _n To terminate the pattern, (c) ₁ ,r ₁ )、......、(c _n ,r _n ) Is a precondition in the semantic rule, (c, r) is a conclusion in the semantic rule, To be about c ₁ ......c _n 、r ₁ ......r _n Additional conditions for c, r. The visual meaning of the semantic rules is: if from the initial pattern c ₁ Beginning execution reaches termination pattern r ₁ ,...a.from initial pattern c _n Beginning execution reaches termination pattern r _n And about c ₁ ……c _n 、r ₁ ……r _n The additional conditions of c, r are satisfied, then execution begins with initial pattern cThe line reaches the termination pattern r.

As one example, consider a smart contract programming language that supports inter-smart contract calls and into which callers can be reentered. Semantic patterns of the large-step operation semantics of the language are as follows<<S,ls> _ee ,gs> _ρ Where S is a program statement in a function of the smart contract, ls is a local state of the contract, the local state is a mapping from each local variable x to a current value x in the function, ee is an execution environment, and includes information such as an address of an account where the currently executed smart contract is located, an address of an account where a caller contract (i.e., the smart contract calling the currently executed smart contract) is located, and a digital currency amount transferred to the currently executed contract during calling, gs is a global state, includes information such as a balance of each account on a blockchain, a state of the smart contract in the account, and the like, ρ is a code mapping, and maps each smart contract account address to a data structure including information of a source code of the smart contract. Termination pattern as (ls ', gs') _cf Here, ls 'is the local state of the contract when execution of a certain transaction of the smart contract is completed, gs' is the corresponding global state, and cf indicates whether the execution state of the smart contract transaction is normal (no anomaly occurs).

The intelligent contract program language directly modifies the intelligent contract state, and the statement for realizing the functions of control flow skip and the like can be similar to the definition of the semantics of the traditional general program language. To illustrate how semantics of intelligent contract interactions are defined by means of semantic predicates, assume that there is a class of statements in the intelligent contract programming language, the shape is a.f (al) →xl', the visual meaning of which is: and calling a function f in the intelligent contract of an account A by taking the expression in the expression list al as an actual parameter, and storing a return value of the function f into a variable in a variable list xl', wherein the address of the account A is the value of the expression a. Executing a.f (al) →xl' in a given smart contract invokes a smart contract for account a may succeed or fail, and the semantic rules describing the success case may be expressed by means of a semantic predicate rule as:

the above semantic rules reflect that when a function call is performed, expression a for expressing the account address of the called smart contract is first evaluated to obtain the address of the account (denoted as A) of the called smart contract Next it is checked whether the length |al| of the list al of actual parameters passed by the function call is the same as the length |xl| of the form parameter list xl of the called function. If the check is passed and the program statement of the function f in the intelligent contract source code in the account A is S, the initial pattern is followedBegin execution of S, here->Mapping the ith local variable of function f (i.e. the ith element in xl) to the value z of the corresponding real parameter _i Other variables are mapped to 0. If statement S executes successfully (no exception occurs), the local state of the caller (specifically, a function in the intelligent contract of execution statement a.f (al) →xl') is updated to ∈>And takes the global state gs' in the termination pattern as the new global state of the caller. Where ls' is the local state reached after execution of statement S, and local state +.>Mapping the ith variable in list xl ' to the value of xl "ith variable in ls ', and still mapping the variable x not in xl ' to the value of x in ls, reflecting the return value based on the function f, modifying the value of the variable in the executing function to the caller contract.

The semantic rules can be formalized in a Coq interactive theorem prover

Above SCall ae f aes xs 'is a formal representation of function call a.f (al) →xl', size ae corresponds to |al| in the semantic rule math description, size zs corresponds to |zs| in the semantic rule math description, and avals ee ss corresponds to |zs| in the semantic rule math descriptionlstate_ini xs zs corresponds to +.f in the mathematical description of the semantic rules>lstate_upd_ret ls 'xs' ys corresponds to the mathematical description of the semantic rulesIn addition, ctr_cfg is used to construct an initial pattern of the intelligent contract programming language big-step operation semantics, and ctr_rcfg is used to construct a termination pattern of the intelligent contract programming language big-step operation semantics.

Semantic rules in the smart contract programming language describing that a contract fails to execute an external contract function call due to a failure of the called contract (e.g., throwing an exception) can be expressed by a semantic predicate rule as:

(<<a.f(al)→xl′,ls> _ee ,gs> _ρ ,(ls,gs) _ff )

the main difference between the above-mentioned rule and the rule describing the success of the execution of the external contract function call is that the execution of the program statement of the called function of the called smart contract is terminated in the form of (ls ', gs') _ff Where ff reflects that the called function itself did not execute successfully and returned normally to the current given smart contract.

The semantic rules described above may be formalized in a Coq interactive theorem prover as:

In the Coq interactive theorem prover, the universal semantic predicate rule is materialized using rules of blr_call_vacc, blr_call_fail_lnner, etc. On the basis, if the functional correctness of the intelligent contract is verified by relying on a language-independent program proving technology, the problem of how to describe the unknown codes and the execution effects thereof in the external contract still needs to be solved. This is because language independent program attestation techniques require the description and reasoning of all code that may be triggered to execute when the program being verified is running. In the verification of simple sequential programs, it is often not difficult to obtain complete program code and to provide the key substructures therein with verification assistance information required for the language-independent program certification process. In many cases of smart contract verification, it is difficult to obtain program code for all external contracts potentially interacting with the verified contract, although the external contract may have an impact on its state by reentering the current contract.

The step S102, namely, describing the functional correctness of the function in the given smart contract as the corresponding relationship between each initial pattern and the ending pattern set of the given smart contract, is a step of describing a formal specification called the functional correctness of the given smart contract, and further includes the following steps:

a) For a first function in a given smart contract source code, an initial pattern is described, the control states in the initial pattern reflect calls to the first function, the data states in the initial pattern include mappings of account addresses on a blockchain to smart contract states in an account when the function is called, and the smart contract states refer to mappings of variable names to variable values in a smart contract.

b) Describing a set of termination patterns for the first function in the step, expressing a defined range of termination patterns reached by execution of the given smart contract starting with the initial pattern of the step. The control state of each termination pattern in the set of termination patterns reflects whether the execution of the given smart contract completed successfully (i.e., no exception was triggered). The data state of each termination pattern in the set of termination patterns includes a mapping of an account address on a blockchain to an intelligent contract state in an account after the execution of the intelligent contract is completed.

c) Combining the initial pattern of the given smart contract obtained in step a) above and the set of termination patterns of the given smart contract obtained in step b) above into a binary group, said binary group being referred to as an assertion.

d) Repeating the steps a), b) and c) for each remaining function of the given smart contract to obtain a set of assertions, wherein the set is a formal specification of functional correctness of the given smart contract.

e) Formalized representation of the formal specification of the functional correctness of the given smart contract obtained in the above step is performed in an interactive theorem prover.

One transaction of the smart contract corresponds to execution of a function in the smart contract. To verify a smart contract using language-independent program verification techniques, the functional correctness requirements of the smart contract are expressed by means of formal conventions Φ: Φ contains a series of tuples (c, P), each such tuple being called an assertion that can indicate that the ending pattern resulting from execution of pattern c needs to fall within set P. When the same smart contract is implemented in different programming languages, there are differences in the form of presentation of the data states, control states, and termination patterns in the set P in pattern c, but the form specification Φ contains the same set of assertions in an intuitive sense.

Assertions (c, P) in the formal specification Φ may also express verification assistance information for the smart contract: the ending pattern that may be reached by the program execution started by the initial pattern c, where c contains loop structures in the smart contract, internal function calls, external contract function calls, constitutes the set P. The set P that can be expressed is not limited to a finite set, as the high-order logical theorem proving tool (e.g., coq, isabelle, HOL, etc.) supports descriptive representations of the set.

Using the smart contract programming language, a smart contract may be written that implements digital currency access functions. The code of the contract is given below and is used as an example to illustrate a method for specifying and validating intelligent contracts using language independent program validation techniques.

In one embodiment, a given smart contract includes a function for depositing an amount of digital currency into the contract that is automatically invoked when a user account transfers to the account of the given smart contract (similar to the receiver function in the solubility language in which an ethernet smart contract is written). The program statement of this function is as follows:

S _dpt :＝if lk＝0 then balance<caller()>:＝balance<caller()>+callvalue()else fail

the main function implemented by the statement described above is an increase in the balance of the caller (addressed to a caller ()) recording the transfer function in the given smart contract (since the caller has newly deposited a certain amount of digital money into the current contract). The variable balance maintains a balance in the given smart contract for the account on the blockchain where each smart contract is located. The expression callvalue () gives the amount that the account addressed to the caller () is transferring to the given smart contract this time. Lk in the above statement is a lock variable by which accounting of balance information is guaranteed to occur only when the transfer is not a reentry call.

If the given smart contract includes another function that allows the user to take out the digital currency previously stored in the contract, the program statement of the function is as follows:

the expression this () in the above statement gives the address of the account in which the given smart contract is located. The core task logic of this statement is to transfer the caller (the user account that is drawing digital money) the digital money for which the requested amount amountis (implemented by the caller (). Transfer (amount)) and to record the decrease in user balance in the given smart contract accordingly. Variables lk and S in the above statement _dpt The same as above.

The functional correctness of the given smart contract may be governed by the formal specification Φ ₀ :＝Φ _dpt ∪Φ _wd Expressed, wherein the account address of the account in which the given smart contract is assumed to be adr ₀ . At phi ₀ In the definition of phi _dpt Comprising a series of assertions describing the set of ending patterns reached by the given smart contract account after a transfer (deposit of digital money) from a certain initial pattern to the given smart contract, i.e. the two tuples (c, P) described hereinabove.

/>

Wherein the method comprises the steps of

At the technical level, the definition expresses from the initial pattern<<a.transfer(a′),ls> _ee ,gs> _ρ The ending pattern reached by any execution of the start falls on set P _ls,ee,gs Is a kind of medium. Intuitively, the main content of the definition expression is that if an account on the blockchain tries to transfer to a given smart contract under the local state ls and the global state gs (the target address is ) The state of the account of the given intelligent contract is not changed, the balance of the account of the transfer account recorded in the given intelligent contract is not changed (corresponding to unsuccessful transfer), or the balance of the account of the given intelligent contract and the balance recorded in the variable of the given intelligent contract are increased by an amount equal to the transfer amount, and the values of other state variables of the given intelligent contract are not changed.

At phi ₀ In the definition of phi _wd Contains a series of assertions that describe the set of termination patterns that a given smart contract account has reached after a certain amount of digital money has been drawn from the given smart contract under a certain initial pattern.

Wherein the method comprises the steps of

At the technical level, the definition expresses from the initial pattern<<a.withdraw([a1])→[],ls> _ee ,gs> _ρ The ending pattern reached by any execution of the start falls on set P _ls,ee,gs Is a kind of medium. Intuitively, the main contents of the definition expression are as follows: if an account on the blockchain attempts to withdraw a certain amount of digital money from the given smart contract under the local state ls and the global state gs, either the state of the account in which the given smart contract is located (including the built-in balance) is unchanged, the balance of the transfer account recorded in the contract is also unchanged (i.e., gs' (adr) ₀ )＝gs(adr ₀ ) Corresponding to the case of unsuccessful transfer operations), or the balance of the account in which the given smart contract is located and the balance recorded in the given smart contract variable are both reduced by an amount equal to the withdrawal limit, while the values of the other variables of the given smart contract are unchanged, i.e. bal' =bal-z, andwherein bal, bal 'are the balances of the account in which the given smart contract is located before and after the transfer operation, respectively, and sms' are a portion of the data state of the given smart contract before and after the transfer operation, respectively, in which the value of the balance variable in the given smart contract is recorded.

In Coq Interactive theorem prover, the form of the functional correctness of the intelligent contract, Φ ₀ Formally expressed as:

the above widthwart_resa1ls ee gs and deposite_resae' ls ee gs represent sets of termination patterns to which operations of withdrawing a certain amount of digital money from a given smart contract and depositing a certain amount of digital money into a given smart contract may be performed, respectively.

Step S103, namely, describing, for a key substructure in the source code of the given smart contract, an execution process of the key substructure in a form of a correspondence between each initial pattern and the termination pattern set, where the execution process is used as verification auxiliary information of the key substructure in the source code of the given smart contract, and includes the following steps:

a) And finding key substructures such as internal function calls (namely sentences for calling a certain function in the given intelligent contract source code) in the first function in the given intelligent contract source code, loops and the like.

b) For each key substructure in the above steps, an initial pattern is described. The control state in the initial pattern reflects that the key substructure is to be executed, and the data state in the initial pattern includes a mapping of account addresses on the blockchain to intelligent contract states in the accounts when the key substructure is to be executed.

c) For each key substructure in step a), a set of termination patterns is described, expressed starting from the initial pattern of the above step, the expected range of termination patterns that can be reached by the execution of the key substructure. The control state of each termination pattern in the set of termination patterns reflects whether execution of the critical substructure completed successfully (i.e., no triggering exception). The data state of each termination pattern in the set of termination patterns includes a mapping of an account address on a blockchain to an intelligent contract state in an account after the execution of the critical substructure is completed.

d) Combining the initial pattern of each critical substructure S obtained in step b) above and the final pattern of the critical substructure S obtained in step c) above into a set of tuples (i.e. one assertion) thus obtaining a series of assertions.

e) Repeating the steps a), b), c) and d) for each remaining function of the given smart contract to obtain a set of assertions (the set includes all assertions obtained in the step d), wherein the set of assertions is verification auxiliary information of the key substructure in the source code of the given smart contract.

f) The verification auxiliary information of the key substructures in the given intelligent contract source code obtained in the steps is formally expressed in an interactive theorem prover.

The method provided by the disclosure is used for verifying the intelligent contract, and verification auxiliary information can be given to key substructures such as circulation in the source code of the intelligent contract, internal function call of the intelligent contract and the like. The auxiliary information is presented in a form similar to the functional correctness specifications of a given smart contract, i.e., both are sets of assertions. For each assertion (c, P) that provides smart contract key substructure verification assistance information, the control state of the initial pattern c represents that a key substructure is to be executed, and the data state represents a mapping of account addresses on the blockchain to smart contract states in the account before the key substructure is executed. Furthermore, the set P consists of a termination pattern, which may be obtained by the initial pattern c starting to execute the key substructures.

Since the processing of the key sub-structures such as loops, internal function calls, etc. in language independent program verification is not a problem specific to intelligent contract verification, the provision of auxiliary information for intelligent contract key sub-structure verification is not described herein.

Step S104, namely describing the influence of the external contract function call on the blockchain state in the form of the correspondence between each initial pattern and the termination pattern set for the external contract function call in the source code of the given intelligent contract, wherein the external contract function call is used as verification auxiliary information of the external contract function call in the given intelligent contract in the language-independent intelligent contract verification process, and the step comprises the following steps:

a) Constructing a series of contract invariants for the given smart contract, each contract invariant should satisfy: if a certain function f in the source code of the given smart contract is called, the state of the given smart contract (mapping of variable to variable value) satisfies the contract invariance, and if the function f returns, the state of the given smart contract satisfies the contract invariance. All contract invariants I constructed by this step are set to constitute a set Il.

b) For a first function of the given smart contract, finding an external contract function call and a transfer operation to the external contract therein. An initial pattern is described for each external contract function call or transfer operation of an external contract. The control state of the initial pattern reflects that the external contract function call or the transfer operation of the external contract is to be performed. The data state of the initial pattern comprises mapping of the account address on the blockchain to the intelligent contract state in the account when the external contract function call or the transfer operation of the external contract starts to be executed.

c) For each initial pattern c described in step b), a set P of termination patterns is described, expressing the expected range of termination patterns reached by the initial pattern of the above steps, the external contract function call or the execution of the transfer operation to the external contract. In particular, each termination pattern r in P reflects: if the data state in c satisfies a contract invariance I in the set Il in the step a), the data state in r also satisfies I; in addition, the state of other intelligent contracts Ctr 'on the blockchain reflected by r may be any mapping from the variable name to the variable value of Ctr'.

e) Combining the initial pattern of each external contract function call or transfer to an external contract X obtained in step b) above and the ending pattern of X obtained in step c) above into a set of tuples (i.e., an assertion) thus obtaining a series of assertions for the first function of the smart contract.

d) Repeating the steps b), c) and d) for each remaining function of the given smart contract to obtain a set of assertions (the set of assertions including all assertions obtained in the step d), the set of assertions being the auxiliary information of the contract function call outside the given smart contract.

f) The auxiliary information of the external contract function call in the given intelligent contract source code obtained in the step is formalized in an interactive theorem proving device.

If the given smart contract includes an external contract function call, or a transfer operation to an external contract, a change in the external contract state may be initiated, and if the called contract is executed, the code may cause the given smart contract to be reentered, which may further initiate a change in the given smart contract state. A given smart contract reentry may be understood as a given smart contract invoking other smart contracts on the blockchain that were invoked to invoke the given smart before the return of the invoked other smart contract, such that execution of program code reenters the given smart contract.

The change in the state of a given smart contract may be defined by a series of contract invariants I constructed. The visual meaning of each contract invariance I is: if I is established on a certain parameter value l and a given smart contract state ss (mapping of variable names to variable values of smart contracts) when a given smart contract is re-entered, I is established on the same parameter value l and state ss' of the given smart contract when re-entry execution of the given smart contract is ended. Since the called smart contract can only change the state of a given smart contract by reentering the given smart contract, if I holds on the parameter value l and the state of the given smart contract when the external contract is called, I holds on the same parameter value l and the state of the given smart contract when the called contract returns.

For a given smart contract in the example, the following 2 contract invariants may be constructed, where ss.svs (lk) represents the value of the lock variable lk in the given smart contract state ss:

I ₁ (l,ss):＝ss.svs(lk)＝0

I ₂ (l,ss):＝ss.svs(lk)＝1∧l＝ss

based on contract invariance set il= { I ₁ ,I ₂ The following predicate set Φ may be employed _e The state changes that may be initiated by a transfer of an external contract given the smart contract in the examples are described.

Wherein the method comprises the steps of

The main contents of the expression of the protocol are as follows:

1. after the transfer operation of a given smart contract to an external contract is successfully returned (at which point the external contract may have reentered the given smart contract zero or more times), any state change of the external contract may occur, while the state change of the given smart contract remains unchanged for contracts in the collection Il;

2. after any contract other than the given smart contract executes a program statement S, the induced change in the state of the given smart contract maintains the contract invariance in Il-i.e., if the contract invariance I in Il holds on the state of the given smart contract in the initial pattern, I holds on the state of the given smart contract in the terminating pattern.

In general, phi _e Execution of any code in the reflected invoked contract maintains contract invariance with respect to the state of a given smart contract. In this way, a complete external contract function call (the transfer may be considered a special call) also remains contract invariant for a given smart contract state. In language independent program attestation techniques, any verification assistance information itself needs to be attested. Specifically, to phi _e Assertion set {<<S,ls>ee,gs> _ρ ,P _ls,I,l ) The |ee is not equal to the ads +.0 ∈I (i.e., shaped as +.a.) (L, gs (adr 0)) ∈L)<<S,ls> _ee ,gs> _ρ ,P _ls,I,l ) And an assertion set composed of two tuples in which the parameters satisfy the condition post-condition can be understood as<<S,ls> _ee ,gs> _ρ Corresponding to the initial pattern c, P _ls,I,l Corresponding to termination pattern set P), any statement S in the called contract needs to be discussed in a classified manner to account for Φ _e The assertion contained by itself is proved. In this section of evidence, if S contains a call or transfer to a given smart contract, then phi is required _i Representing that the given smart contract itself performs a certification of the completion of the sub-objective of the auxiliary information keeping it unchanged.

Step S105, namely, a step of describing an influence of the execution of the given smart contract after reentry on the blockchain state in a form of correspondence between the initial pattern and the ending pattern set of the given smart contract, as verification auxiliary information of the reentry execution of the given smart contract, includes the following steps:

a) For a first function in the given smart contract source code, an initial pattern c is described, the control states in the initial pattern reflecting calls to the function, the data states in the initial pattern including mappings of account addresses on the blockchain to smart contract states in the account when the function is called.

b) Describing a termination pattern set P for the initial pattern c in the above step, and expressing the expected range of termination patterns reached by the execution of the given intelligent contract starting from c. The control state of each termination pattern r in the set of termination patterns P reflects whether the execution of the given smart contract completed successfully (i.e., no exception was triggered). Each termination pattern r in the termination pattern set P reflects: if the data state in c satisfies a certain contract invariance I in the set Il in sub-step a of step S104, the data state in r also satisfies I; in addition, the state of other intelligent contracts Ctr 'on the blockchain reflected by r may be any mapping from the variable name to the variable value of Ctr'.

c) Combining the initial pattern of the given smart contract obtained in step a) above and the set of ending patterns of the given smart contract obtained in step b) above into a binary group (i.e. an assertion).

d) Repeating the steps a), b) and c) for each function of the given smart contract to obtain a set of assertions, wherein the set of assertions is verification auxiliary information of reentry execution of the given smart contract.

e) Formalized representation of the set of assertions obtained in step d) above is performed in an interactive theorem prover.

In the program code of a given smart contract, if an external contract function call or a transfer operation to an external contract is included, execution of the external contract code may be caused, so that reentry into the given smart contract may be caused. To accomplish the function reduction Φ using the methods set forth in the embodiments of the present disclosure ₀ All potential reentry's possible impact on a given smart contract state may also be described.

Wherein the method comprises the steps of

This definition expresses that, for contract invariance I in collection Il, if a given smart contract calls an external smart contract function, when the called contract reenters the given smart contract by calling function f, I is satisfied in the parameter value l and the data state of the given smart contract, and the real parameter list al transferred to f and the shape parameter list ((ρ (adr) ₀ ).fmp)(f)).xl ₁ The length is the same, then the termination pattern resulting from the completion of the execution of function f is in set P _ls,xl,I,l Is a kind of medium. The local state ls ' of the ending pattern in the set is the same as the local state ls of the initial pattern giving the same value to the variables outside all the lists xl (where xl is the list of variables used to receive the return value of the function when the function f is called) and reflects the state gs ' (adr) that the condition I finally arrives at the parameter value l and given smart contract if the execution of the function is not abnormal (i.e. cf ' is true) ₀ ) The above is satisfied. Furthermore, with respect to re-entry of a given smart contract initiated by a transfer to the given smart contract, the present definition expresses each condition I in the change maintenance set Il of the state of the given smart contract, i.e. the state of the given smart contract satisfies I, i.e. I (l, gs (adr) ₀ ) If the state of the given smart contract at the end of the re-entry execution satisfies I, i.e., I (l, gs' (adr) ₀ ) Is true.

Through the assertion set phi containing auxiliary information _e And phi is _i Can provide necessary auxiliary information for the effect generated by the execution of the called contract unknown code in the intelligent contract environment in the language-independent program proving process, so that the language-independent program proving technology can be truly used for intelligent contractsAnd the certification task similar to the distributed program, solving the problem that the intelligent contract verification technology is bound with the specific intelligent contract programming language.

Step S106, i.e. performing interactive proof on the formal specification of the functional correctness of the given smart contract by using the formalized semantic rule, the verification auxiliary information of the key substructure in the source code of the given smart contract, the verification auxiliary information of the external contract function call in the given smart contract, and the verification auxiliary information of the reentry execution of the given smart contract, if the verification process can be completed, determining that the implementation of the function in the given smart contract can meet the functional correctness requirement specified by the interface of the given smart contract, and if the verification process cannot be completed, indicating that the given smart contract does not meet the functional correctness description thereof, including the following steps:

a) For each corresponding relation between the initial pattern and the termination pattern set in the step, other termination patterns of the initial pattern c in other corresponding relations in the current corresponding relation and related termination patterns obtained based on the semantic rules are determined;

b) When the other termination patterns and the related termination patterns are in the termination pattern set in the current correspondence, the current correspondence is verified; and after all the corresponding relations are verified, the given intelligent contract is verified; otherwise, one of the corresponding relations is verified to be not passed, and the given intelligent contract is verified to be not passed.

In some embodiments, the other termination patterns of the initial pattern c and the associated termination patterns are determined as follows:

1) Judging whether the assertion set obtained in step 102, step 103, step 104, step 105 contains an assertion (c ', P '), wherein c ' =c. If yes, each termination pattern in the P' is one termination pattern corresponding to the c; if not, deducing a termination pattern r corresponding to c by using the semantics of the intelligent contract language defined in the step 1 according to the following method:

and setting the semantic reflection initial pattern c of the intelligent contract language to obtain a corresponding termination pattern based on a series of termination patterns corresponding to the initial patterns c1, … … and cn respectively. Then, for each initial pattern ci in c1, … …, cn, using the above step 1) to obtain a termination pattern corresponding to ci, and then based on the thus obtained termination patterns c1, … …, cn, respectively, pushing out a termination pattern r of c according to the semantics;

In this embodiment, for the assertion set Φ (which may be a formal specification of an intelligent contract, various verification auxiliary information, or a union of both), Φ may be verified by using verif (Φ), which is specifically defined as follows:

the specific meaning of the definition formula is: if assertions (c, P) are included in Φ, and r is a termination pattern corresponding to c, by virtue of the auxiliary information included in Φ (i.e., other assertions (c ', P ') in Φ, where the control state in c ' is about to perform some critical substructure, external contract invocation, or reentry of a given contract, and P ' includes a termination pattern that execution from c ' may reach), then r is in P. Wherein the expression of refer (phi, c, r) is based on verification auxiliary information in phi, and a termination pattern corresponding to the initial pattern c can be deduced to comprise r. The specific definition of this expression is as follows:

the specific meaning of the above definition formula is: if the precondition (c) ₁ ,r ₁ )、……、(c _k ,r _k ) Conclusions (c, r) can be drawn by applying certain semantic rules, whereas for each precondition (c) by means of the auxiliary information in Φ _i ,r _i ) Can push out r _i Is c _i A corresponding one of the termination patterns (expressed as res (Φ, c _i ,r _i ) By means of phiThe inclusion of auxiliary information may infer that r is a termination pattern corresponding to c. For different programming languages, the semantic predicate rule needs to be defined as different content, but the expression attestation process' refer and verif have the same form.

Intuitively, to prove that the assertion set Φ can be verified, namely verif (Φ), the conditions that can be met by each initial pattern of the program to reach the termination pattern must be deduced according to the requirement of refer, and all possible termination patterns are proved to fall within the range specified by Φ. If the phi gives a termination pattern set corresponding to a certain initial pattern or intermediate pattern involved in the process, the condition met by the corresponding termination pattern is directly obtained from the phi. Otherwise, appropriate semantic rules need to be applied to deduce the termination pattern actually generated by the execution of the initial pattern. By means of the auxiliary information in the formal specification, the potential problem that the process of deducing the execution result of the initial pattern completely depends on the semantic rules can not be terminated can be avoided.

For a given smart contract and its formal specification of functional correctness in the example, the given smart contract's functional specification Φ may be proved ₀ And an assertion set Φ containing auxiliary information _i 、Φ _e Can be verified, i.e. can prove:

verif(Φ ₀ ∪Φ _i ∪Φ _e )

the general idea of this proof is as follows. For phi ₀ Is asserted (i.e.. Phi _dpt Or phi is _wd Each assertion in (c), statement S defined in section 4.2 according to the refer pair _dpt Or S _wd Deriving from the execution of the external contract transfer statement caller (). Transfer (amount) encountered in execution, according to res, by Φ _e The auxiliary information (see 4.2) about the termination pattern that may be reached after the transfer operation is finished, directly gets the termination pattern of the transfer operation. For phi _i Deriving, also from the refer, a function call in a given smart contract or a termination pattern of a transfer to a given smart contract, by Φ, for transfer operations to an external contract encountered during the deriving _e Is provided with auxiliary information to obtain the possible termination of the transfer operationA pattern. For phi _e If the assertion comes from the composition Φ _e The 1 st set of (a) is that the assertion is as the following%<<a.transfer(a′),ls> _ee ,gs> _ρ ,P _ls,I,l ) Its initial pattern<<a.transfer(a′),ls> _ee ,gs> _ρ During the derivation process, the 2 nd set of forms are generated<<S,ls> _ee ,gs> _ρ Can be based on res by means of the initial pattern in set 2<<S,ls> _ee ,gs> _ρ The provided auxiliary information gives its corresponding termination pattern. For phi _e If the assertion comes from the composition Φ _e The 2 nd set of (a) is that the assertion is as the following%<<S,ls> _ee ,gs> _ρ ,P _ls,I,l ) Then the statement S is discussed in classification. For atomic sentences, the initial pattern can be directly obtained through semantic rules<<S,ls> _ee ,gs> _ρ The termination pattern reached by the execution of (a). For compound statements and target addresses not adr ₀ Contract function call by composition phi _e The auxiliary information contained in the 2 nd set of the (2 nd) is used for obtaining an initial pattern<<S,ls> _ee ,gs> _ρ A termination pattern that may be reached by execution of (a). Adr for target address ₀ Contract function call by Φ _i Directly giving an initial pattern to the information provided in (a)<<S,ls> _ee ,gs> _ρ A termination pattern that may be reached by execution of (a).

In the above proof and similar proof of functional correctness of smart contracts using the framework, although problems involving external contract function calls and reentry of a given smart contract may result in execution of functions of unknown repetition times, the proof work need not be performed using induction. This benefits from the fact that in the language independent program verification framework, one assertion (c, P) in the smart contractual convention can provide auxiliary information for verification on its own (i.e., verif ({ (c, P) }) is verified), and verification of that assertion itself can be accomplished based on the auxiliary information provided by other assertions. In addition, the refer reflecting the core verification process of the framework is expressed based on the universal semantic predicates, so that the method is unbound with a specific intelligent contract program language.

The method provided by the disclosure can ensure that for any assertion set phi, if verif (phi) can be proved, valid (phi) is established, which means that all assertions contained in phi are satisfied. In particular, if Φ is a formal specification of the functional correctness of a given smart contract, valid (Φ) indicates that the functional correctness requirements of the given smart contract are satisfied. The valid (Φ) is specifically defined herein as

The definition means that: for any initial pattern c and termination pattern set P, if the formal specification Φ of a given smart contract contains (c, P), and the deterministic execution of pattern c terminates at r, then r should be within the constraints of P. Wherein deriv (c, r) can be defined generalizely by means of semantic predicates as:

i.e. the execution of a program from an initial pattern c to a terminating pattern r can be regarded as being derived by means of some semantic rule, the preconditions used (c ₁ ,r ₁ )、……、(c _k ,r _k ) Itself should reflect pattern c ₁ 、……、c _k To r ₁ 、……、r _k Is executed by termination of (embodied as)。

Verif (Φ) as demonstrated above ₀ ∪Φ _i ∪Φ _e ) And the reliability of the language-independent verification process, valid (Φ) can be obtained ₀ ∪Φ _i ∪Φ _e ) According to the definition of valid, valid (phi) ₀ ) Indicating that the functional correctness requirements of a given smart contract are satisfied.

The proof of correctness of the smart contracts described in this section is only one example of an application of the methods presented in this disclosure. If other intelligent contracts written in the same programming language are to be verified, a formal specification phi of the functional correctness of the intelligent contract needs to be given for the intelligent contract ₀ And constructing a suitable contract invariance, i.e. phi _i And phi is _e The set Il in the definition. In addition, if there is a call (not transfer) to an external smart contract function in a given smart contract source code, then it is necessary to send a call to the external smart contract function at Φ _e An additional set is added to the definition of (1) that expresses successful external contract function calls to maintain contract invariance for a given smart contract state. To verify intelligent contracts in different programming languages, formal semantics of the language should first be described based on the semantic predicate rule. On the basis, for each intelligent contract written in the language, the specification phi can be defined as well ₀ And performing functional correctness verification of the intelligent contract on the basis of providing necessary verification auxiliary information.

The following are device embodiments of the present disclosure that may be used to perform method embodiments of the present disclosure.

Fig. 4 illustrates a block diagram of a language-independent smart contract validation apparatus that may be implemented as part or all of an electronic device via software, hardware, or a combination of both, in accordance with an embodiment of the disclosure. As shown in fig. 4, the language-independent smart contract verification apparatus includes:

an expression module 401 configured to formally express semantic rules of a given smart contract programming language based on generic semantic predicates of megastep operation semantics;

a first description module 402 configured to describe the functional correctness of the function in the given smart contract as a correspondence of each initial pattern of the given smart contract to a set of ending patterns, such description being referred to as a formal specification of the functional correctness of the given smart contract;

A second description module 403, configured to describe, for a key substructure in the given smart contract source code, an execution process of the key substructure in a form of a correspondence between each of the initial patterns and the termination pattern set, as verification auxiliary information of the key substructure in the given smart contract source code;

a third description module 404, configured to describe, for an external contract function call in the source code of the given smart contract, an effect of the external contract function call on a blockchain state in a form of a correspondence relationship between each initial pattern and a termination pattern set, as verification auxiliary information of the external contract function call in the given smart contract in a language-independent smart contract verification process;

a fourth description module 405, configured to describe, in a form of correspondence between the initial pattern and the final pattern set of the given smart contract, an effect of execution after the given smart contract is reentered on a blockchain state, as verification auxiliary information of the reentry execution of the given smart contract;

a verification module 406 configured to interactively prove the formal specification of the functional correctness of the given smart contract using the formalized semantic rules, verification assistance information of key substructures in the given smart contract source code, verification assistance information of external contract function calls in the given smart contract, and verification assistance information of reentry execution of the given smart contract, and if a verification process can be completed, determine that implementation of a function in the given smart contract can meet functional correctness requirements specified by an interface of the given smart contract, and if the verification process cannot be completed, indicate that the given smart contract does not meet its functional correctness description.

The language-independent intelligent contract verification device in this embodiment corresponds to the language-independent intelligent contract verification method in the foregoing, and specific details can be found in the description of the language-independent intelligent contract verification method in the foregoing, which is not repeated here.

As shown in fig. 5, the electronic apparatus 500 includes a Central Processing Unit (CPU) 501, which can execute various processes in the embodiments of the above-described method of the present disclosure according to a program stored in a Read Only Memory (ROM) 502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM503, various programs and data required for the operation of the electronic apparatus 500 are also stored. The CPU501, ROM502, and RAM503 are connected to each other through a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.

The following components are connected to the I/O interface 505: an input section 506 including a keyboard, a mouse, and the like; an output portion 507 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The drive 510 is also connected to the I/O interface 505 as needed. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as needed so that a computer program read therefrom is mounted into the storage section 508 as needed.

In particular, according to embodiments of the present disclosure, the methods in embodiments of the present disclosure described above with reference to may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program comprising program code for performing the methods of embodiments of the present disclosure. In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 509, and/or installed from the removable medium 511.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units or modules described in the embodiments of the present disclosure may be implemented by software, or may be implemented by hardware. The units or modules described may also be provided in a processor, the names of which in some cases do not constitute a limitation of the unit or module itself.

As another aspect, the present disclosure also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the apparatus described in the above embodiment; or may be a computer-readable storage medium, alone, that is not assembled into a device. The computer-readable storage medium stores one or more programs for use by one or more processors in performing the methods described in the present disclosure.

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention referred to in this disclosure is not limited to the specific combination of features described above, but encompasses other embodiments in which any combination of features described above or their equivalents is contemplated without departing from the inventive concepts described. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).

Claims

1. A language independent intelligent contract verification method, comprising:

2. The method of claim 1, wherein the general purpose semantic predicates based on big-step operation semantics formally express semantic rules for a given smart contract programming language, comprising:

determining the composition of an initial pattern and a termination pattern of big-step operation semantics of a programming language of a given intelligent contract;

the method comprises the steps of materializing general semantic predicates, and giving definition of the materialized general semantic predicates according to situations, wherein each situation expresses a corresponding relation between an initial pattern and a termination pattern determined by program execution;

The definition of the embodied universal semantic predicates is formally expressed in an interactive theorem prover.

3. The method of claim 1, wherein describing the functional correctness of the function in the given smart contract as a correspondence of each initial pattern of the given smart contract to a set of ending patterns, such description being referred to as a formal specification of the functional correctness of the given smart contract, comprises:

describing an initial pattern for a first function in a given smart contract source code; the initial pattern comprises a control state and a data state, the control state in the initial pattern reflects the call to the first function, the data state in the initial pattern comprises the mapping from the account address to the intelligent contract state in the account on the blockchain when the first function is called, and the intelligent contract state refers to the mapping from the variable name to the variable value in the intelligent contract;

describing a termination pattern set for the first function, expressing a defined range of termination patterns reached by the execution of the given smart contract starting from the initial pattern of the above steps; each termination pattern in the set of termination patterns includes a control state and a data state, the control state of the termination pattern reflecting whether the execution of the given smart contract was completed successfully; the data state of each termination pattern in the termination pattern set comprises a mapping of an account address on a blockchain to an intelligent contract state in an account after the execution of the intelligent contract is completed;

Combining the described initial pattern and termination pattern set of the given intelligent contract into a corresponding relation;

repeating the steps for each function of the given intelligent contract to obtain a set of corresponding relations, wherein the set is a formal specification of the functional correctness of the given intelligent contract;

formalized representation of the formal specification of the functional correctness of the given smart contract obtained in the above step is performed in an interactive theorem prover.

4. The method according to claim 1, wherein for a key substructure in the source code of the given smart contract, describing the execution of the key substructure in the form of correspondence between each of the initial patterns and the termination pattern set as verification assistance information for the key substructure in the source code of the given smart contract, comprising: finding a key substructure in a first function in the given smart contract source code;

describing an initial pattern including control states and data states for each of the key substructures; the control state in the initial pattern reflects that the key substructure is about to be executed, and the data state in the initial pattern comprises mapping of account addresses on a blockchain to intelligent contract states in accounts when the key substructure is about to be executed;

Describing a termination pattern set for each key substructure, and expressing the expected range of the termination pattern reached by the execution of the key substructure starting from the initial pattern of the above steps; each termination pattern in the termination pattern set comprises a control state and a data state, and the control state of the termination pattern reflects whether the execution of the key substructure is successfully completed; the data state of each termination pattern in the termination pattern set comprises mapping of an account address on a blockchain to an intelligent contract state in an account after the execution of the key substructure is completed;

combining the initial pattern of each key substructure and the final pattern set of the key substructure into a corresponding relationship;

repeating the steps for each function of the given intelligent contract to obtain a set of corresponding relations, wherein the set is verification auxiliary information of a key substructure in the source code of the given intelligent contract;

the verification auxiliary information of the key substructures in the given intelligent contract source code obtained in the steps is formally expressed in an interactive theorem prover.

5. The method of claim 1, wherein describing the effect of external contract function calls on blockchain status in terms of correspondence of each initial pattern to a set of termination patterns for external contract function calls in source code of the given smart contract as verification assistance information for external contract function calls in the given smart contract during language-independent smart contract verification includes:

Constructing a series of contract invariants for the given smart contract, each contract invariant should satisfy: if any objective function in the source code of the given intelligent contract is called, the state of the given intelligent contract meets the contract invariance, and when the objective function returns, the state of the given intelligent contract meets the contract invariance;

finding an external contract function call and a transfer operation to the external contract for a first function of the given smart contract; describing an initial pattern including a control state and a data state for each external contract function call or a transfer operation of an external contract; the control state of the initial pattern reflects the transfer operation of the external contract function call or the external contract to be executed; the data state of the initial pattern comprises mapping from the account address on the blockchain to the intelligent contract state in the account when the external contract function call or the transfer operation of the external contract starts to be executed;

describing a set of termination patterns for an initial pattern described for an external contract function call or a transfer operation of an external contract, expressing an expected range of termination patterns reached by execution of the external contract function call or the transfer operation of the external contract starting from the initial pattern;

Combining the initial pattern and the corresponding termination pattern set described for each external contract function call or transfer operation of the external contract into a corresponding relationship;

repeating the steps for each function of the given intelligent contract to obtain a set of corresponding relations, wherein the set is auxiliary information called by the contract function outside the given intelligent contract;

the auxiliary information of the external contract function call in the given intelligent contract source code obtained in the step is formalized in an interactive theorem proving device.

6. The method of claim 5, wherein describing the impact of execution of the given smart contract after reentry on blockchain status as authentication assistance information for reentry execution of the given smart contract in the form of correspondence of the initial pattern and the ending pattern set of the given smart contract comprises:

describing an initial pattern including control states and data states for a first function in the given smart contract source code, the control states in the initial pattern reflecting calls to the first function, the data states in the initial pattern including mappings of account addresses on a blockchain to smart contract states in an account when the first function is called;

Describing a termination pattern set for the initial pattern of the first function description, expressing an expected range of termination patterns reached by the execution of the given smart contract starting from the initial pattern; each termination pattern in the termination pattern set comprises a control state and a data state; the control state of the termination pattern reflects whether the execution of the given smart contract completed successfully; each termination pattern in the set of termination patterns reflects: if the data state in the initial schema satisfies one of a series of contract invariants constructed for the given smart contract, then the data state in the ending schema satisfies one of the series of contract invariants; in addition, the states of other intelligent contracts on the blockchain reflected by the termination pattern may be any mapping from variable names to variable values of other intelligent contracts;

combining the initial pattern and the termination pattern set described for the first function into a corresponding relation;

repeating the steps for each function of the given intelligent contract to obtain a set of corresponding relations, wherein the set is verification auxiliary information of reentry execution of the given intelligent contract;

7. The method of claim 1, wherein interactively proving formal protocols for functional correctness of the given smart contract using the formalized semantic rules, verification assistance information for key substructures in the given smart contract source code, verification assistance information for external contract function calls in the given smart contract, and verification assistance information for reentry execution of the given smart contract, determining that implementation of functions in the given smart contract can meet functional correctness requirements specified by interfaces of the given smart contract if a verification process can be completed, and indicating that the given smart contract does not meet its functional correctness description if a verification process cannot be completed, comprising:

for each corresponding relation between all initial patterns and the ending pattern set, other ending patterns of the initial patterns in other corresponding relations in the current corresponding relation and related ending patterns obtained based on the semantic rules are determined;

When the other termination patterns and the related termination patterns are in the termination pattern set in the current correspondence, the current correspondence is verified; and after all the corresponding relations are verified, the given intelligent contract is verified; otherwise, one of the corresponding relations is verified to be not passed, and the given intelligent contract is verified to be not passed.

8. A language independent intelligent contract verification device, comprising:

9. An electronic device comprising a memory and a processor; wherein,,

the memory is for storing one or more computer instructions, wherein the one or more computer instructions are executable by the processor to implement the method of any of claims 1-7.

10. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the method of any of claims 1-7.