A theorem proving based formal verification method for MedTiny language

Abstract

The application belongs to the field of formal verification, and proposes a MedTiny language formal verification method based on theorem proving. By designing a target language similar to the MedTiny structure in the theorem prover Isabelle, the verification of the MedTiny program is realized; by using the theorem proving technology, the verification result is strictly mathematically guaranteed; according to the preset Hall triple proof rule, the Hall triple is simplified, and the problem that the number of cycles cannot be verified is avoided; by converting the simplified Hall triple into the final value of the verification condition obtained by verification calculation, and judging whether the weakest precondition is contained in the precondition, the verification process is highly automated through the theorem prover, the demand for expert manpower is greatly reduced, and the verification efficiency and accuracy are significantly improved.

Description

Technical Field

[0001] This invention belongs to the field of formal verification, and in particular relates to a formal verification method for the MedTiny language based on theorem proof. Background Technology

[0002] The MedTiny language was first introduced at the 23rd International Conference on Software Quality, Reliability and Security in a paper titled "MedTiny: Enhanced Mediator Modeling Language for Scalable Parallel Algorithms". MedTiny is a component-based programming language that, compared to traditional programming languages, allows for flexible component-based modeling of concurrent systems and has already been applied in the field of smart contracts. Because MedTiny can be applied to many security-critical areas, there is a need for formal verification of it.

[0003] The paper that first proposed the MedTiny language introduced a model-checking-based method for formal verification of MedTiny programs. While highly automated, this method suffers from state explosion when dealing with variables like `int` and `float` that have large value ranges, making it unable to solve the problem within a reasonable timeframe. Furthermore, when encountering loop statements, the model-checking method typically only performs a finite number of expansions, failing to verify cases with unbounded loop iterations.

[0004] Theorem proving is a formal verification technique that can handle unbounded state spaces and has been widely used in program verification, operating system kernel verification, compiler verification, and other fields, effectively solving the state explosion problem in model checking methods. However, theorem proving methods typically have a low degree of automation and require a significant investment of expert human resources. Furthermore, while theorem proving methods exist for common programming languages ​​such as C and Java, there are currently no theorem proving methods for the MedTiny language. Summary of the Invention

[0005] To address the problems of existing model detection methods being prone to state explosion and unable to use theorem proofs for formal verification of the MedTiny language, while requiring significant expert manpower for formal verification using theorem proofs, resulting in low efficiency for formal verification of the MedTiny language, a theorem proof-based formal verification method for the MedTiny language is proposed, thus solving the aforementioned problems.

[0006] The technical solution of this invention is as follows:

[0007] A formal verification method for the MedTiny language based on theorem proof, comprising the following steps:

[0008] S1: Constructing an abstract syntax tree: Compile and analyze the MedTiny source code to be verified to obtain the abstract syntax tree corresponding to the MedTiny source code; the root node of the abstract syntax tree corresponds to the body of the MedTiny source code, i.e., the automaton, and the syntax tree nodes correspond to the transition branches in the MedTiny source code.

[0009] S2: Target Language Conversion: Generate initialization assignment statements for all program variables in the MedTiny source code; convert the code corresponding to the abstract syntax tree from MedTiny language to the target language according to the syntax of the preset target language to obtain the target language code;

[0010] S3: Construct Hall triples: Construct Hall triples using the preconditions, postconditions, and target language code provided by the demand side; simplify the Hall triples according to the preset Hall triple proof rules to obtain simplified Hall triples;

[0011] S4: Formal Verification: Calculate the weakest antecedents corresponding to different types of executed statements in the simplified Hall triplet using different types of weakest antecedent calculation functions; calculate the verification conditions corresponding to different types of executed statements in the simplified Hall triplet using different types of verification condition calculation functions; automatically determine whether the final value of the verification conditions is true and whether the weakest antecedent is implied in the antecedents by calling the SMT solver inside the theorem prover; if the final value of the verification conditions is true and the weakest antecedent is implied in the antecedents, then the formal verification is successful.

[0012] Preferably, the method for compiling and analyzing the MedTiny source code to be verified in step S1 is as follows:

[0013] A1: Lexical analysis of the MedTiny source code was performed based on the lexical definition file and finite automata theory to obtain the segmented code;

[0014] A2: The segmented code is subjected to syntactic analysis based on the lexical definition file and context-free grammar theory to obtain an abstract syntax tree; the lexical definition file and syntactic definition file are written according to the MedTiny design document.

[0015] Preferably, the transition branch is obtained by traversing the syntax tree nodes in the abstract syntax tree to obtain the transition branch corresponding to each syntax tree node; the transition branch includes: guard condition and specific execution statement; the types of the specific execution statement include: empty, assignment, sequential execution and branch statement.

[0016] Preferably, the method for target language conversion in step S2 is as follows:

[0017] S21: Generate the initialization assignment statements for all program variables in the MedTiny source code;

[0018] S22: The automaton is converted into loop code according to the syntax of the preset target language; each transition branch in the automaton is converted into a sequentially executed branch statement in the loop code according to the syntax of the preset target language; the target language code is formed by the initialization assignment statement and the loop code.

[0019] Preferably, the method for converting each transition branch into sequentially executed branch statements in the loop code according to the syntax of the preset target language is as follows:

[0020] B1: Convert the guard condition in the transition branch into the condition of the branch statement to be executed sequentially, according to the syntax of the preset target language.

[0021] B2: Based on the syntax of the preset target language, convert the specific execution statements in the transition branch into the statements executed when the condition in the sequential branch statement is "true".

[0022] Preferably, the method for constructing the Hall triplet in step S3 is as follows:

[0023] S31: Construct Hall triples using the preconditions, postconditions, and target language code provided by the demand side;

[0024] S32: The initialization assignment statements in the target language code are removed by using the Hall triplet proof rules corresponding to the preset sequential statements and assignment statements respectively, to obtain simplified target language code;

[0025] S33: Manually specify the invariant of the loop statement; eliminate the outer loop statement in the simplified target language code according to the invariant and the Hall triplet proof rule corresponding to the loop statement, and obtain the final target language code without loop statements;

[0026] S34: Replace the target language code in the Hall triple with the simplified target language code, and redetermine the preconditions and postconditions of the Hall triple based on the final target language code to obtain the simplified Hall triple.

[0027] Preferably, the Hall triplet proof rule is set according to Hall logic theory and the type of statement.

[0028] Preferably, the weakest antecedent calculation functions for the different types are:

[0029]

[0030] "pre SKIP Q = Q" |

[0031] "pre (Assign xa) Q = Q([a / x])" |

[0032] "pre (Seq C1 C2) Q = pre C1 (pre C2 Q)" |

[0033] "pre (IF b C1 C2) Q = if b then (pre C1 Q) else (pre C2 Q)"

[0034] Where fun is the function definition command; pre is the name of the function used to evaluate the weakest precondition; "This indicates that the weakest precondition calculation function takes two parameters of type com and assn as inputs and outputs one parameter of type assn; where indicates that the function pre provides specific rules for the weakest precondition calculation function; C1 and C2 both represent program statements; Q represents the postcondition; SKIP indicates that the execution statement type is empty; Assign indicates that the execution statement type is assignment; Seq indicates that the execution statement type is sequential execution; IF indicates that the execution statement type is branching statement.

[0035] Preferably, the different types of verification condition calculation functions are:

[0036]

[0037] "vc SKIP Q = True" |

[0038] "vc (Assign xa) Q = True" |

[0039] "vc (Seq C1 C2) Q = (vc C1 (pre C2 Q) ∧ vc C2 Q)" |

[0040] "vc (IF b C1 C2) Q = (vc C1 Q ∧ vc C2 Q)"

[0041] Where fun is the function definition command; vc is the name of the function used to verify the condition calculation; "This indicates that the input to the verification condition calculation function is two parameters of type com and assn, and the output is a parameter of type bool; where com represents a program statement, assn represents an assertion, and bool represents a boolean value.

[0042] Preferably, before proceeding to step S4, the reliability of the weakest antecedent calculation function and the verification condition calculation function needs to be verified in the theorem prover; when the reliability verification is passed, the weakest antecedent is calculated using the weakest antecedent calculation function and the verification condition is calculated using the verification condition calculation function in the theorem prover in step S4.

[0043] Beneficial effects:

[0044] This invention proposes a formal verification method for the MedTiny language based on theorem proof. It realizes the formal verification of the MedTiny language through theorem proof and can automatically complete the formal verification of the MedTiny language, thereby improving verification efficiency and accuracy. At the same time, it can effectively solve the problem of state explosion in model detection methods.

[0045] By compiling and analyzing the MedTiny source code, an abstract syntax tree is obtained, which can accurately determine the transition branches in the MedTiny source code. This accurate determination of the transition branches allows for the precise conversion of the MedTiny source code into target language code, avoiding discrepancies between the final functionalities of the target language code and the MedTiny language code. Furthermore, formal verification of the target language is achieved through theorem proofs, thereby enabling formal verification of the MedTiny language code and ultimately resolving the problem of not being able to formally verify the MedTiny language using theorem proofs.

[0046] Based on the MedTiny language, a target language with a similar structure to MedTiny was set up in the theorem prover, enabling formal verification of the MedTiny language using the theorem prover. Theorem proving techniques ensure the verification results have strict mathematical guarantees; the Hall triplet is simplified according to the pre-defined Hall triplet proof rules, avoiding the problem of not being able to verify cases with unbounded loop counts. By converting the verification of the simplified Hall triplet into verifying whether the final value of the calculated verification condition is true and determining whether the antecedent condition contains the weakest antecedent, the theorem prover automates the verification of whether the final value of the calculated verification condition is true and whether the antecedent condition contains the weakest antecedent. This achieves automation of most of the formal verification work using the theorem prover, requiring only a small amount of expert manpower for the entire verification process, while also offering high speed and accuracy. Attached Figure Description

[0047] Figure 1 This is a flowchart of a formal verification method in the MedTiny language based on theorem proof.

[0048] Figure 2This is an excerpt of smart contract code for a bank loan scenario described using MedTiny.

[0049] Figure 3 This is an excerpt of Isabelle target language code obtained by translating the smart contract code.

[0050] Figure 4 This is a code excerpt used for code verification.

[0051] Figure 5 Excerpt of verification code that does not use an automated proof strategy.

[0052] Figure 6 Verification code for using an automated verification strategy. Detailed Implementation

[0053] Example 1:

[0054] like Figure 1 As shown, a formal verification method for the MedTiny language based on theorem proof includes the following steps:

[0055] S1: Constructing an abstract syntax tree: Compile and analyze the MedTiny source code to be verified to obtain the abstract syntax tree corresponding to the MedTiny source code; the root node of the abstract syntax tree corresponds to the body of the MedTiny source code, i.e., the automaton, and the syntax tree nodes correspond to the transition branches in the MedTiny source code.

[0056] S2: Target Language Conversion: Generate initialization assignment statements for all program variables in the MedTiny source code; convert the code corresponding to the abstract syntax tree from MedTiny language to the target language according to the syntax of the preset target language to obtain the target language code;

[0057] S3: Construct Hall triples: Construct Hall triples using the preconditions, postconditions, and target language code provided by the demand side; simplify the Hall triples according to the preset Hall triple proof rules to obtain simplified Hall triples;

[0058] S4: Formal Verification: Calculate the weakest antecedents corresponding to different types of executed statements in the simplified Hall triplet using different types of weakest antecedent calculation functions; calculate the verification conditions corresponding to different types of executed statements in the simplified Hall triplet using different types of verification condition calculation functions; automatically determine whether the final value of the verification conditions is true and whether the weakest antecedent is implied in the antecedents by calling the SMT solver inside the theorem prover; if the final value of the verification conditions is true and the weakest antecedent is implied in the antecedents, then the formal verification is successful.

[0059] Example 2:

[0060] 1.1 Designing the Isabelle target language

[0061] Isabelle natively supports a functional language that focuses on simple computation rather than modifying variable values. MedTiny, on the other hand, is a component-based language built on top of traditional programming languages. It supports assignment, sequential operations, branching, and looping statements common in traditional programming languages, and allows direct modification of variable values. Due to the significant differences between the two, a target language needs to be defined using a language natively supported by Isabelle. This target language should support common statements in traditional programming languages ​​and the ability to modify variable values, thus being more similar to MedTiny and facilitating subsequent translation.

[0062] (a) To implement the "modify variable value" functionality in MedTiny within Isabelle, a mapping from variable name (vname, a string type in Isabelle) to value (val, see 1.1(b)) is defined in Isabelle. Modifying a variable value in MedTiny can be expressed as modifying the mapping in Isabelle:

[0063]

[0064] (b) Use the datatype command in Isabelle to define the possible values ​​(val), for example:

[0065] datatype val = Iv (io:int) | Sv (so:string) | Bv (bo:bool)

[0066] Integer, string, and boolean values ​​are defined.

[0067] (c) Use the `datatype` command in Isabelle to define possible expressions, for example:

[0068] datatype exp = Ic int | Plus exp exp | Minus exp exp

[0069] Integer expressions and addition and subtraction between them are defined.

[0070] (d) Use the datatype command in Isabelle to define common statements (empty, assignment, sequential execution, branching, and looping statements):

[0071] datatype com = SKIP | Assign vname exp| Seq com com| If exp com com|While exp com

[0072] 1.2 Design of Hall triplet proof rules

[0073] Then, in Isabelle, the proof rules upon which subsequent proofs depend are defined based on Hall logic.

[0074] (a) (Terminology Explanation) The central feature of Hall logic theory is the Hall triple. This triple describes how the execution of a piece of code changes the state of computation. A Hoare triple has the following form:

[0075]

[0076] Here, P and Q are assertions, and C is a program statement. P is called the "precondition" and Q is called the "postcondition." An assertion is a formula in predicate logic. Intuitively, this triple can be interpreted as: if P is true in the state before C is executed, then Q is also true after execution. This interpretation is also called "partial correctness." Another interpretation is: if P is true in the state before C is executed, then C must terminate, and Q is also true after execution. This interpretation additionally requires C to terminate and is called "complete correctness." Different interpretations can be chosen depending on the nature of the proof required. This invention supports the verification of both types of correctness simultaneously.

[0077] (b) For each type of statement in 1.1(d) (empty, assignment, sequential execution, branch, loop statement), define its corresponding Hall triple proof rule using Isabelle’s inductive command.

[0078] Specifically, the Hall triplet proof rules are set according to Hall logic theory and the type of statement. For example, for sequential execution statements, the proof rules in Isabelle are as follows:

[0079]

[0080]

[0081] 1.3 Design an automated proof strategy

[0082] Verifying the program solely based on the Hall triplet proof rule would consume a significant amount of expert manpower. Therefore, Isabelle implements automated proofs based on the Hall triplet obtained in section 1.2.

[0083] (a) Specifically, using the fun command in Isabelle, functions with the weakest preconditions can be computed based on different statement types defined by Hall logic theory, excluding loop statements.

[0084] For example, the functions for calculating the weakest precondition for different categories of executed statements are as follows:

[0085]

[0086] "pre SKIP Q = Q" |

[0087] "pre (Assign xa) Q = Q([a / x])" |

[0088] "pre (Seq C1 C2) Q = pre C1 (pre C2 Q)" |

[0089] "pre (IF b C1 C2) Q = if b then (pre C1 Q) else (pre C2 Q)"

[0090] Where fun is the function definition command; pre is the name of the function used to evaluate the weakest precondition; "This indicates that the weakest precondition calculation function takes two parameters of type com and assn as inputs and outputs one parameter of type assn; where indicates that the function pre provides specific rules for the weakest precondition calculation function; C1 and C2 both represent program statements; Q represents the postcondition; SKIP indicates that the execution statement type is empty; Assign indicates that the execution statement type is assignment; Seq indicates that the execution statement type is sequential execution; IF indicates that the execution statement type is branching statement.

[0091] Where (Assign xa) is an assignment statement, x represents the parameter, and a represents the specific value to be assigned to x;

[0092] (Seq C1 C2) represents program statements executed sequentially; (IF b C1 C2) represents program statements executed in a branch, where b is the condition.

[0093] In this context, C and its derivatives (such as C1, C2, C3, etc.) all represent "program statements", and P and Q both represent "assertions", where P refers to the preceding condition and Q refers to the following condition.

[0094] (b) Then, using the fun command, the function vc that can be used to calculate the verification condition is defined according to different statement types based on Hall logic theory. The statement types do not include loop statements.

[0095] For example, the functions for calculating the verification conditions for different categories of execution statements are as follows:

[0096]

[0097] "vc SKIP Q = True" |

[0098] "vc (Assign xa) Q = True" |

[0099] "vc (Seq C1 C2) Q = (vc C1 (pre C2 Q) ∧ vc C2 Q)" |

[0100] "vc (IF b C1 C2) Q = (vc C1 Q ∧ vc C2 Q)"

[0101] Here, ∧ represents "AND", and the final result is true only when both propositions on both sides of ∧ are true; com represents a program statement, assn represents an assertion, and bool represents a boolean value.

[0102] (c) Next, the reliability of the above-defined function is defined using the lemma command in Isabelle, and the reliability is proven.

[0103]

[0104] Even though the functions for calculating the weakest antecedent and the verification condition, as defined above, are based on Hall theory, it is still necessary to determine their correctness (i.e., reliability) by defining a reliability function in the theorem prover. Only after proving that the defined functions are correct (i.e., reliable) can they be used in the theorem prover Isabelle. Furthermore, when verifying the specific MedTiny source code later, the verification method in 1.3(d) can be used directly, without needing to re-verify the defined functions for calculating the weakest antecedent and the verification condition.

[0105] (d) According to 1.3(c), given the preceding and following conditions P and Q, to prove the correctness of a program C that does not contain loop statements (i.e., {P}C{Q}), it is only necessary to prove ① that vc CQ evaluates to true, and ② that P implies pre CQ.

[0106] The calculation of the weakest antecedent preCQ is only related to the program statement C and the postcondition Q, and is unrelated to the antecedent P. The weakest antecedent is itself an "assertion" (in layman's terms, an assertion is a logical expression), so determining whether P implies preCQ is equivalent to determining whether one logical expression implies another logical expression, without requiring a direct relationship between them.

[0107] (e) The function vc that verifies the condition is a pure function, so Isabelle can automatically calculate and simplify to obtain the value of vcCQ. Since P implies preCQ, which is a pure logical expression, the corresponding SMT solver can be called in the theorem prover Isabelle to complete the proof.

[0108] (f) Add the simplification operations and SMT solver call operations involved in 1.3(e) to Isabelle's auto strategy retrieval environment, which can then be automatically invoked via the by auto command.

[0109] 2. Translate the MedTiny program into the Isabelle target language code.

[0110] (a) A typical MedTiny program is essentially an automaton, with multiple transitions within it. Each transition consists of a guard condition and its corresponding execution statements. The execution statements within a transition include null, assignment, sequential execution, and branching statements.

[0111] (b) Based on the MedTiny design document, write the lexical definition file and the syntax definition file. (Note: This step only needs to be done once and is universal for all MedTiny code.)

[0112] The lexical definition file defines the basic elements in MedTiny code. For example, the following statement defines Boolean and integer values: BOOL: 'True'|'False';

[0113] DIGIT: [0-9] ;

[0114] INT: DIGIT+ ;

[0115] The syntax definition file defines the rules for constructing statements in MedTiny code. For example, the following statement defines a transition branch:

[0116] transition: 'state' '==' 'FlowState.' ID '->' '{' transContent '}';

[0117] (c) Given the MedTiny source code, perform lexical analysis on the code based on the lexical definition file and finite automata theory to obtain the segmented code. Then, based on the syntax definition file, perform syntax analysis on the segmented code based on context-free grammar theory to obtain an abstract syntax tree.

[0118] Specifically, after manually obtaining the lexical definition file and syntax definition file from the MedTiny design document, these files are then input into the Antlr4 tool. Antlr4 automatically performs lexical analysis on the input MedTiny source code using finite automata theory, based on the input lexical definition file. After lexical analysis, Antlr4 uses context-free grammar theory to perform syntactic analysis on the segmented results, based on the input syntax definition file, to obtain an abstract syntax tree. This automates the analysis of the MedTiny language, improving the speed and accuracy of constructing the abstract syntax tree.

[0119] (d) According to 2(a), the root node of the obtained abstract syntax tree is an automaton. Traverse the syntax tree nodes corresponding to all transition branches in the automaton to obtain the guard condition and the specific execution statement inside each transition branch.

[0120] Specifically, the purpose of constructing the abstract syntax tree corresponding to the MedTiny source code is to determine each transition branch in the MedTiny code. Compared to other methods, using the construction of an abstract syntax tree to determine the transition branches in the MedTiny source code can not only significantly improve processing efficiency, but also greatly enhance the accuracy of transition branch identification results.

[0121] (e) First, generate initialization assignment statements for all program variables. Then, according to the syntax of the Isabelle target language, translate the automaton into loop statements, where each transition branch is translated into a series of sequentially executed branch statements within the loop. Specifically, the guard condition of the transition branch is translated into the condition of the branch statement, and the specific execution statement within the transition branch is translated into the statement to be executed when the condition of the branch statement is "true".

[0122] 3. Express the properties to be verified using the Isabelle target language.

[0123] The preconditions P and Q for the properties to be verified are expressed using the Isabelle target language. For example, "the value of variable x is an integer 3" is expressed in the Isabelle target language as s''x'' = Iv 3.

[0124] In this invention, the preconditions P and Q, as well as the MedTiny program to be verified, are provided by the client based on specific verification requirements. Therefore, this invention verifies the MedTiny program based on the known preconditions P and Q and the MedTiny program.

[0125] Using Isabelle's definition command, define the target language code obtained in step 2 as the variable program. Then it is only necessary to prove the Hall triple {P}program{Q}.

[0126] Specifically, the Hall triples above are stated using the lemma command in Isabelle:

[0127]

[0128] 4. Prove the property in Isabelle.

[0129] (a) First, use the unfold command in Isabelle to expand the program in step 3 into specific code.

[0130] (b) As described in 2(e), the main body of the translated Isabelle target language code is a loop statement, preceded by several variable initialization assignment statements.

[0131] (c) When proving properties, first use the proof rules for sequential execution statements and assignment statements set in 1.2(b) to process a series of variable initialization assignment statements before the loop.

[0132] Specifically, after processing the series of variable initialization assignment statements before the loop by proving the rules, the program only includes the subsequent loop statements and no longer includes the preceding assignment statements.

[0133] (d) Manually determine the invariants in the loop statement, and then use the Hall triplet proof rule and invariants corresponding to the loop statement set in 1.2(b) to eliminate the outer loop of the program, and obtain the code inside the loop body that does not contain loop statements (consisting of empty, assignment, sequential execution, and branch statements).

[0134] Because the target language in the program has been simplified, the preconditions P and Q of the simplified program need to be changed accordingly.

[0135] (e) The code obtained in 4(d) meets the requirements of 1.3(d) (i.e., it does not contain loop statements). Therefore, according to 1.3(d), it is only necessary to prove that vc CQ evaluates to true and assert that P implies pre CQ. (Note: Here, C refers to the code obtained in 4(d) after eliminating loops and does not contain loop statements. P and Q still refer to the precondition and postcondition.)

[0136] (f) Finally, the by auto command in Isabelle (which has been set in 1.3(f)) is used to call the internal SMT solver to complete the automatic solution of the vc CQ evaluation problem and the P implied pre CQ problem, thus completing the proof.

[0137] Example 3:

[0138] like Figure 2 The image shows an excerpt of smart contract code for a bank loan scenario implemented using the MedTiny language.

[0139] Will Figure 2 Excerpt of loop code from the MedTiny language for a bank loan scenario, converted to the corresponding Isabelle target language. Figure 3 The main body of the loop code is a While loop statement, preceded by several variable initialization assignment statements. The state variable determines the current transition.

[0140] like Figure 4 The loop code shown verifies the conversion to the target language. The loop code proves that: if the applicant initially has m yuan, the bank initially has n yuan, and the applicant applies for a loan of k yuan, then when the loan application process ( Figure 3 After the program in the code ends, regardless of the application outcome, the total funds of the applicant and the bank will always be m+n yuan. This property ensures the correctness of the funds in the relevant smart contract. This property involves int type variables, and therefore cannot usually be characterized in common model detectors, but it has a direct correspondence in the theorem prover.

[0141] like Figure 5 As shown, when directly verifying the loop code, instead of using the automated proof strategy designed in 1.3... Figure 4 Verifying the properties in the code requires approximately 100 lines of verification code, resulting in high expert manpower costs.

[0142] like Figure 6 As shown, the automated proof strategy designed in section 1.3 is used to... Figure 4 Verifying the properties of the data requires only a dozen lines of code, resulting in low manpower costs.

[0143] It should be noted that the specific embodiments described above enable those skilled in the art to more fully understand the present invention, but do not limit the present invention in any way. Therefore, although the present invention has been described in detail with reference to the accompanying drawings and embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention. In short, all technical solutions and improvements that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the present invention patent.

Claims

1. A formal verification method for the MedTiny language based on theorem proof, characterized in that, S1: Constructing an abstract syntax tree: Compile and analyze the MedTiny source code to be verified to obtain the abstract syntax tree corresponding to the MedTiny source code; the root node of the abstract syntax tree corresponds to the body of the MedTiny source code, i.e., the automaton, and the syntax tree nodes correspond to the transition branches in the MedTiny source code. The transition branches are obtained by traversing the syntax tree nodes in the abstract syntax tree, and the transition branches corresponding to each syntax tree node are obtained. The transition branch includes: a guard condition and a specific execution statement; the types of the specific execution statement include: empty, assignment, sequential execution, and branch statement; S2: Target Language Conversion: Generate initialization assignment statements for all program variables in the MedTiny source code; convert the code corresponding to the abstract syntax tree from MedTiny language to the target language according to the syntax of the preset target language to obtain the target language code; S21: Generate the initialization assignment statements for all program variables in the MedTiny source code; S22: The automaton is converted into loop code according to the syntax of the preset target language; each transition branch in the automaton is converted into sequentially executed branch statements in the loop code according to the syntax of the preset target language; the target language code is formed by the initialization assignment statement and the loop code; The method for converting each transition branch into sequentially executed branch statements in the loop code according to the syntax of the preset target language is as follows: B1: Convert the guard condition in the transition branch into the condition of the branch statement to be executed sequentially, according to the syntax of the preset target language. B2: Based on the syntax of the preset target language, convert the specific execution statements in the transition branches into the statements executed when the condition is "true" in the sequentially executed branch statements; S3: Construct Hall triples: Construct Hall triples using the preconditions, postconditions, and target language code provided by the demand side; simplify the Hall triples according to the preset Hall triple proof rules to obtain simplified Hall triples; S31: Construct Hall triples using the preconditions, postconditions, and target language code provided by the demand side; S32: The initialization assignment statements in the target language code are removed by using the Hall triplet proof rules corresponding to the preset sequential statements and assignment statements respectively, to obtain simplified target language code; S33: Manually specify the invariant of the loop statement; eliminate the outer loop statement in the simplified target language code according to the invariant and the Hall triplet proof rule corresponding to the loop statement, and obtain the final target language code without loop statements; S34: Replace the target language code in the Hall triple with the simplified target language code, and redetermine the preconditions and postconditions of the Hall triple according to the final target language code to obtain the simplified Hall triple; S4: Formal Verification: Calculate the weakest antecedents corresponding to different types of executed statements in the simplified Hall triplet using different types of weakest antecedent calculation functions; calculate the verification conditions corresponding to different types of executed statements in the simplified Hall triplet using different types of verification condition calculation functions; automatically determine whether the final value of the verification conditions is true and whether the weakest antecedent is implied in the antecedents by calling the SMT solver inside the theorem prover; if the final value of the verification conditions is true and the weakest antecedent is implied in the antecedents, then the formal verification is successful.

2. A formal verification method for MedTiny language based on theorem proof as described in claim 1, characterized in that, The method for compiling and analyzing the MedTiny source code to be verified, as described in step S1, is as follows: A1: Lexical analysis of the MedTiny source code was performed based on the lexical definition file and finite automata theory to obtain the segmented code; A2: The segmented code is subjected to syntactic analysis based on the lexical definition file and context-free grammar theory to obtain an abstract syntax tree; the lexical definition file and syntactic definition file are written according to the MedTiny design document.

3. A formal verification method for MedTiny language based on theorem proof as described in claim 1, characterized in that, The Hall triplet proof rule is set according to Hall logic theory and the type of statement.

4. A formal verification method for MedTiny language based on theorem proof as described in claim 1, characterized in that, The weakest antecedent calculation functions for the different types mentioned are: "pre SKIP Q = Q" | "pre (Assign xa) Q = Q([a / x])" | "pre (Seq C1 C2) Q = pre C1 (pre C2 Q)" | "pre (IF b C1 C2) Q = if b then (pre C1 Q) else (pre C2 Q)" Where fun is the function definition command; pre is the name of the function used to evaluate the weakest precondition; "This indicates that the weakest precondition calculation function takes two parameters of type com and assn as inputs and outputs one parameter of type assn; where indicates that the function pre provides specific rules for the weakest precondition calculation function; C1 and C2 both represent program statements; Q represents the postcondition; SKIP indicates that the execution statement type is empty; Assign indicates that the execution statement type is assignment; Seq indicates that the execution statement type is sequential execution; IF indicates that the execution statement type is branching statement; x represents the parameter, a represents the specific value to be assigned to x; b is the judgment condition.

5. A formal verification method for MedTiny language based on theorem proof as described in claim 4, characterized in that, The different types of verification condition calculation functions are as follows: "vc SKIP Q = True" | "vc (Assign xa) Q = True" | "vc (Seq C1 C2) Q = (vc C1 (pre C2 Q) ∧ vc C2 Q)" | "vc (IF b C1 C2) Q = (vc C1 Q ∧ vc C2 Q)" Where fun is the function definition command; vc is the name of the function used to verify the condition calculation; "This indicates that the input to the verification condition calculation function is two parameters of type com and assn, and the output is a parameter of type bool; com represents a program statement, assn represents an assertion, and bool represents a boolean value; ∧ represents "AND".

6. A formal verification method for MedTiny language based on theorem proof as described in claim 1, characterized in that, Before proceeding to step S4, the reliability of the weakest antecedent calculation function and the verification condition calculation function must be verified in the theorem prover. When the reliability verification is passed, the weakest antecedent calculation function is used to calculate the weakest antecedent and the verification condition is calculated using the verification condition calculation function in the theorem prover in step S4.

Images