Intelligent contract conversion method and system for Event-B model

Abstract

The invention discloses an Event-B model intelligent contract conversion method and system, and the method comprises the steps: setting an input and output range of a conversion tool through employing an extended Bass normal form; on the basis of the defined input and output range, specific conversion rules are designed for each element in the Event-B model syntax subset; and a programming language is adopted to convert the Event-B model into a Solidity code, and formalized design and development of the smart contract are completed. According to the invention, online conversion between the formalized model and the smart contract is realized, and the security of the smart contract is effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain and software engineering technology, and in particular to an Event-B model smart contract conversion method and system. Background Art

[0002] In recent years, smart contracts have been widely used in decentralized finance, lending and other fields with the help of blockchain's decentralized, traceable, and tamper-proof features, carrying huge transaction volumes and real value. However, according to researchers' statistics, more than 34,000 smart contract programs in existing smart contracts have certain security issues and are at risk of being hacked. In order to improve the security of smart contracts and reduce vulnerabilities in smart contract programs, contract developers can usually use a variety of methods to detect smart contracts. Formal methods, as a software and hardware design method based on mathematical models, are suitable for the description, development and verification of software and hardware systems. They are an important method for international high-reliability software verification and can be used to detect smart contract vulnerabilities and ensure the security of smart contracts.

[0003] The patent "A method and system for designing and generating smart contract code based on a formal model" discloses a method for designing and generating smart contract code based on the Event-B model, which improves the security of smart contracts through formal methods. The patent "An EB2S system and method for using smart contract code design and generation" focuses on the conversion between the Event-B mathematical model and the Solidity smart contract program. The EB2S tool is designed and developed based on the model parsing function provided by the Rodin platform, and the conversion between the Event-B model and the Solidity program is realized. The EB2S tool in the above patent has the basic model conversion function, but there are still problems such as vague definition of grammar set, insufficient support for grammar function and high dependence on the platform. First, the grammar set of Event-B models supported by the EB2S tool for conversion is not clear enough, and it is impossible to determine whether the Event-B model meets the input requirements of the EB2S tool; second, the EB2S tool does not support Event-B model sets, functions and other structures, the combination and nesting rules between the grammar components are not clear, and the supported Event-B grammar functions are not extensive enough; third, the EB2S tool has a strong dependence on the Rodin platform and lacks cross-platform capabilities. Summary of the invention

[0004] The purpose of this section is to summarize some aspects of embodiments of the present invention and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the specification abstract and the invention title of this application to avoid blurring the purpose of this section, the specification abstract and the invention title, and such simplifications or omissions cannot be used to limit the scope of the present invention.

[0005] In view of the above existing problems, the present invention is proposed.

[0006] Therefore, the present invention provides an Event-B model smart contract conversion method and system to solve the problems of the existing methods such as vague grammar set definition, insufficient grammar function support and high dependence on the platform.

[0007] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0008] In a first aspect, the present invention provides an Event-B model smart contract conversion method, comprising:

[0009] Use the extended Backus-Naur Form to set the input and output range of the conversion tool;

[0010] Based on the defined input and output range, design specific transformation rules for each element in the Event-B model grammar subset;

[0011] Use programming language to convert Event-B model into Solidity code to complete the formal design and development of smart contracts.

[0012] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0013] The method of using the extended Backus-Naur form to set the input and output range of the conversion tool includes the following steps:

[0014] Select and apply the Extended Backus-Naur Form as the description language to describe the Event-B model input and Solidity contract output acceptable to the NEB2S tool;

[0015] The Event-B model syntax subset that the NEB2S tool supports conversion and the output Solidity contract syntax subset are defined in grammar form.

[0016] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0017] The method of defining the Event-B model grammar subset supported by the NEB2S tool for conversion in grammar form includes the following steps:

[0018] Define the Event-B model structure;

[0019] The Extended Backus-Naur Form is used to summarize the grammatical subsets of the Event-B model and Solidity smart contract, which are called Sub-EB and Sub-SD respectively;

[0020] Clarify the grammatical structure of the Sub-EB model framework;

[0021] Specifies the data declaration method for Constants, Sets, Variables, and Parameters in the Sub-EB syntax subset, supporting multiple data types;

[0022] Use Axioms, Invariants, and Guards to constrain declared data;

[0023] Clarify the supported data types, including integers, Booleans, collections, and functions, and describe in detail the support scope of each type;

[0024] Construct logical predicate statements, including logical connectives and multi-level nested structures;

[0025] Defines grammatical rules for integer expressions, Boolean expressions, and set expressions, allowing for numerical, logical, and set operations;

[0026] Describe the structure of initialization events and common events, and the guard conditions must be met before the action can be executed;

[0027] Defines two forms of assignment statements, including equal assignment and member assignment.

[0028] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0029] The defined Event-B model structure consists of two parts: Context and Machine.

[0030] The text Context includes constants, set constants, and axioms.

[0031] The Machine includes variables, invariants and events;

[0032] Events include initialization events and normal events.

[0033] The initialization event is executed once when the model starts running to complete the initial assignment of variables;

[0034] The common events include parameters, guard conditions and actions.

[0035] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0036] The specific conversion rules are designed for each element in the Event-B model grammar subset, including the following steps:

[0037] The Event model and the structure of the Solidity program are divided and matched;

[0038] The constants and set constants in the Event-B model correspond to the constants in the Solidity program;

[0039] The variables in the Event-B model correspond to the variables declared in the Solidity program;

[0040] The axioms and invariants in the Event-B model are converted into detection functions in the Solidity program;

[0041] The events and their internal parameters, guard conditions, and actions in the Event-B model are converted into functions, function parameters, conditional statements, and corresponding assignment statement blocks in the Solidity program.

[0042] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0043] The method of converting the Event-B model into Solidity code using a programming language includes the following steps:

[0044] Divide the project structure into multiple subdirectories, including entity directory, syntax directory, core directory, util directory and exception directory;

[0045] The entity directory includes the basic entity class of the Event-B model and its manager;

[0046] The syntax directory defines the classes of each grammatical component of the Event-B model, and the grammatical component classes reference each other to form a syntax tree;

[0047] The core directory includes three parts: startup class, lexical analysis class and grammatical semantic analysis class;

[0048] The util directory includes character input management classes and output management classes used by the storage project;

[0049] The exception is the exception class thrown by the project, including lexical exceptions, grammatical exceptions and semantic exceptions.

[0050] As a preferred solution of the Event-B model smart contract conversion method described in the present invention, wherein:

[0051] The lexical analysis class includes lexical analysis logic;

[0052] The lexical analysis logic includes the following steps:

[0053] After parsing starts, the next character is read backward continuously. If the character does not exist, parsing ends.

[0054] If the program gets a character, it performs type determination;

[0055] If the character starts with a letter, continue reading until a complete word is parsed;

[0056] If the word is determined to be a reserved word, continue parsing the next character after the word is queued;

[0057] If the word is judged to be an identifier, continue parsing the next character after the word is queued;

[0058] If the character starts with a number, continue reading until a complete number word is parsed, and then put the word into the queue to continue parsing;

[0059] If the character starts with a comment, this line is ignored and the comment information is backed up;

[0060] If it is a special character, determine the specific type, create a corresponding character word, and queue the word to continue parsing;

[0061] If it is an unknown word, the output parsing exception is generated.

[0062] In a second aspect, the present invention provides an Event-B model smart contract conversion system, comprising:

[0063] The grammar definition module is used to set the input and output range of the conversion tool using the extended Backus-Naur form;

[0064] The semantic transformation module is used to design specific transformation rules for each element in the Event-B model grammar subset based on the defined input and output ranges;

[0065] The code generation module is used to convert the Event-B model into Solidity code using a programming language to complete the formal design and development of smart contracts.

[0066] In a third aspect, the present invention provides a computing device, comprising:

[0067] Memory, used to store programs;

[0068] A processor is used to execute the computer executable instructions, which, when executed by the processor, implement the steps of the Event-B model smart contract conversion method.

[0069] In a fourth aspect, the present invention provides a computer-readable storage medium, comprising: when the program is executed by a processor, the steps of implementing the Event-B model smart contract conversion method are implemented.

[0070] Beneficial effects of the present invention: The present invention provides a reliable conversion path from a formal model to a smart contract program. Under the premise that the Event-B formal model is safe and reliable, the security of the smart contract program is guaranteed. The Sub-SD grammar subset defined by the NEB2S conversion rule is included in the Solidity grammar subset. The NEB2S tool ensures that the generated Solidity program can be compiled through grammar. The EBNF paradigm is used to describe the Event-B model input acceptable to the NEB2S tool. All Event-B models that conform to the paradigm description can be converted. The implemented NEB2S tool supports data types such as integers, Booleans, sets, and functions, and supports complex grammar functions such as nested processing of predicates and expressions. The NEB2S tool will generate a corresponding Event-B model syntax tree and a Solidity program syntax tree according to the model input, and display the corresponding relationship between the syntax tree nodes. The NEB2S tool is written in Java syntax, has strong cross-platform capabilities, realizes online conversion between formal models and smart contracts, and effectively improves the security of smart contracts. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor. Among them:

[0072] Figure 1 A basic flow chart of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0073] Figure 2 An Event-B model structure diagram of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0074] Figure 3 A Sub-EB model framework syntax structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0075] Figure 4 A Sub-EB data declaration syntax structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0076] Figure 5A Sub-EB axiom, invariant and guard condition syntax structure diagram of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0077] Figure 6 A syntax structure diagram of a Sub-EB identifier type definition of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0078] Figure 7 A grammatical structure diagram of a Sub-EB predicate statement of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0079] Figure 8 A Sub-EB relationship predicate syntax structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0080] Fig. 9 A Sub-EB expression syntax structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0081] Fig.10 A Sub-EB event syntax structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0082] Fig.11 A Sub-EB assignment statement syntax structure of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0083] Fig.12 A corresponding relationship diagram between an Event-B model and a Solidity program component of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0084] Fig.13 A Sub-EB model framework conversion diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0085] Fig.14 A conversion diagram of Sub-EB constant data of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0086] Fig.15 A conversion diagram of Sub-EB variable data of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0087] Fig.16A conversion diagram of Sub-EB axiom invariants of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0088] Fig.17 A conversion diagram of a Sub-EB predicate statement of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0089] Fig.18 A conversion diagram of a Sub-EB relationship predicate of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0090] Fig.19 A conversion diagram of a Sub-EB set expression of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0091] Fig. 20 A conversion diagram of a Sub-EB event of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0092] Fig.21 A conversion diagram of a Sub-EB assignment statement of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0093] Fig. 22 A NEB2S workflow diagram of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0094] Fig.23 A NEB2S project structure diagram of an Event-B model smart contract conversion method provided by an embodiment of the present invention;

[0095] Fig.24 An Event-B model lexical analysis flow chart of an Event-B model smart contract conversion method provided by one embodiment of the present invention;

[0096] Fig.25 An organizational structure diagram of NEB2S grammatical components of an Event-B model smart contract conversion method provided for one embodiment of the present invention. DETAILED DESCRIPTION

[0097] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the drawings of the specification. Obviously, the described embodiments are part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary persons in the art without creative work should fall within the scope of protection of the present invention.

[0098] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0099] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The term "in one embodiment" that appears in different places in this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive with other embodiments.

[0100] The present invention is described in detail with reference to schematic diagrams. When describing the embodiments of the present invention, for the sake of convenience, the cross-sectional diagrams showing the device structure will not be partially enlarged according to the general scale, and the schematic diagrams are only examples, which should not limit the scope of protection of the present invention. In addition, in actual production, the three-dimensional dimensions of length, width and depth should be included.

[0101] At the same time, in the description of the present invention, it should be noted that the directions or positional relationships indicated by the terms "upper, lower, inner and outer" are based on the directions or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as limiting the present invention. In addition, the terms "first, second or third" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0102] In the present invention, unless otherwise clearly specified and limited, the terms "install, connect, connect" should be understood in a broad sense, for example: it can be a fixed connection, a detachable connection or an integral connection; it can also be a mechanical connection, an electrical connection or a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0103] Example 1

[0104] Reference Figure 1-25 , as an embodiment of the present invention, provides an Event-B model smart contract conversion method, comprising:

[0105] S1: Use the extended Backus-Naur Form to set the input and output range of the conversion tool;

[0106] In the embodiment of the present application, the EBNF paradigm is used to describe the Event-B model input and Solidity contract output acceptable to the NEB2S tool, and the Event-B model syntax subset supported by the NEB2S tool for conversion and the output Solidity contract syntax subset are defined in grammatical form to clarify the input and output scope of the conversion tool.

[0107] In the embodiment of the present application, the Event-B grammar subset definition includes the following steps:

[0108] In the embodiment of the present application, Event-B is a formal modeling language based on predicate calculus and theorem proof, and its structure is as follows: Figure 2 As shown in the figure, it mainly consists of two parts: Context and Machine. The Context represents the static properties of the model, including constants, Sets, and Axioms; the Machine represents the dynamic behavior of the model, consisting of variables, invariants, and events.

[0109] In the embodiment of the present application, for the text Context of the model, the internal constants Constants and the set constants Sets can be used to define the constants needed by the model, and the constants will not change during the life cycle of the Event-B model. Axioms consist of a series of numbered predicates, mainly various constraints on constant attributes.

[0110] In the embodiment of the present application, for the machine of the model, there is a reference sees relationship between it and the text Context, and the machine can directly use the constants defined in the reference text Context. The machine can define variables of various types such as integer, Boolean, set and function. The values ​​of these variables represent the state of the model; the invariants are similar to axioms, which represent the constraints on the values ​​of the variables, thereby completing the restriction of the state of the Event-B model; the events include initialization events and normal events. The initialization event is executed once when the model starts running to complete the initial assignment of the variables, and then it will no longer be executed. Usually, the event mainly consists of three parts: parameters, guards, and actions. Parameters are the data to be used in the event, guards are a series of constraints on parameters and variables, and actions are a series of statements that change the values ​​of variables. Only when all guards are met will the event execute the action, change the value of the variable, and modify the state of the model.

[0111] In an embodiment of the present application, the EBNF paradigm is used to summarize a grammatical subset of the Event-B model and the Solidity contract (hereinafter referred to as the Event-B grammatical subset as Sub-EB and the Solidity grammatical subset as Sub-SD), where Sub-EB defines the model input acceptable to the NEB2S tool, and Sub-SD describes the Solidity smart contract format output by the NEB2S tool.

[0112] In the embodiment of the present application, the overall framework of the Event-B model has a clear structure and distinct levels. The Sub-EB model framework and the Event-B model framework system have a grammatical structure in the form of EBNF as follows: Figure 3 As shown, EventBModel is the start symbol of the grammar, Context and Machine represent the text and machine of the model respectively, ContextName and MachineName represent the file names of the model text and the model machine respectively. The Event-B model defined by the Sub-EB grammar subset includes two parts: Context and Machine. Context mainly defines the static properties of the model, including Constants, Sets and Axioms; Machine defines the dynamic behavior of the model, consisting of Variables, Invariants and Events. There is a "sees" relationship between Machine and Context, and the Constants and Sets variables defined in Context are used internally by Machine.

[0113] In the embodiment of the present application, Constants, Sets, Variables and Parameters in the Sub-EB syntax subset mainly complete the declaration of data. Constants and Sets complete the declaration and definition of constants, Variables completes the declaration and definition of variables, and Parameters completes the declaration and definition of parameters in Events. Its syntax structure is as follows: Figure 4 As shown. Constants data declaration requires the use of the 'constants' keyword, followed by the declaration of several constant identifiers ConsIdent, where the Sub-EB syntax subset requires that the declared identifiers be different. As for Sets, Variables, and Parameters data declarations, except for the keywords involved, the declaration rules are basically the same as Constants. Constants and parameters support three types of identifiers: Integer, Bool, and Set, and variables support four types of identifiers: Integer, Bool, Set, and Function.

[0114] In the embodiment of the present application, Axioms, Invariants and Guards are used in the Sub-EB grammar subset to constrain the declared data. The specific grammatical structure is as follows: Figure 5 As shown. The predicate statements contained in constraints such as Axioms, Invariants and Guards can be roughly divided into two categories: one is IdentTypeDefine, which is used to indicate the type of declared data; the other is Predicate, which is mainly used to explain the constraint relationship between declared data.

[0115] In the embodiment of the present application, the syntax structure of IdentTyepDefine is as follows: Figure 6 As shown, the data types supported by the Sub-EB grammar subset include integer Integer, Bool Bool, Set, and Function. Integer supports natural numbers, positive integers, and integers, Bool supports two values, TRUE and FALSE, and Set supports elements of the power set P(N) of natural number sets, that is, data of the Set type is a subset of the natural number set. As for the Function type, the Sub-EB grammar subset supports two types: partial function and full function from Set type data (a subset of the natural number set) to the natural number set.

[0116] In the embodiment of the present application, the grammatical structure of the predicate statement is as follows: Figure 7 As shown in the figure, Sub-EB supports logical AND, OR, NOT, implication and equivalent connection predicate symbols, and supports the use of brackets for multi-layer predicate nesting. Predicate is composed of BinaryPred containing logical implication and logical equivalence, BinaryPred is composed of AssociativePred containing logical OR and logical AND, AssociativePred is composed of UnaryPred containing logical NOT statement and PrimaryPred, and PrimaryPred is composed of relational predicate statement RelationalPred and predicate statement enclosed by brackets.

[0117] In the embodiment of the present application, the RelationalPred inside PrimaryPred is an atomic predicate in the Sub-EB grammar subset, that is, the predicate statement Predicate is essentially composed of a series of relational predicate statements RelationalPred. The relational predicate statement RelationalPred cannot contain other conjunctive predicates in structure, and its grammatical structure is as follows: Figure 8As shown. RelationalPred can be divided into three categories according to the data types supported by Sub-EB: IntegerRelPred, BoolRelPred and SetRelPred. IntegerRelPred mainly supports the size and equality comparison between integer value types, BoolRelPred only supports the equality comparison between Boolean types, and SetRelPred supports subset comparison and equality comparison between natural number sets.

[0118] In the embodiment of the present application, according to the data types supported by Sub-EB, expression statements can be divided into three categories: integer expression IntegerExp, Boolean expression BoolExp, and set expression SetExp. The grammatical structure is as follows: Fig. 9 As shown. IntegerExp supports addition, subtraction, multiplication and division operations between integers and nested expressions of brackets.

[0119] In the embodiment of the present application, the integer expression IntegerExp can be derived into a series of PrimaryIntExp through grammatical rules. The PrimaryIntExp statements can be divided into four categories: one is AddExp enclosed in parentheses, which indicates the nesting of integer expressions; the second is the call of function relationship, which obtains the target pixel value according to the function identifier FuncIdent and the original pixel value; the third is a single integer identifier IntegerIdent; and the fourth is a number Number. The above four parts and the integer operation symbol together constitute the complete integer expression IntegerExp.

[0120] In the embodiment of the present application, the Boolean expression BoolExp does not support related logical operations and numerical operations, and can only use the values ​​of TRUE, FALSE and other Boolean identifiers BoolIdent.

[0121] In the embodiment of the present application, the set type expression SetExp supports intersection, union, and difference operations between sets, where the set operations have the same priority. The set expression SetExp can also be derived into a series of PrimarySetExp through grammatical rules, and the PrimarySetExp statements can be divided into three categories: one is SetExp enclosed in brackets, indicating the nesting of set expressions; the second is a single set identifier SetIdent; the third is the initial set InitialSet. The above three parts and the intersection, union, and difference operation symbols together constitute the set expression SetExp.

[0122] In the embodiment of the present application, the grammatical structure of Events in the Sub-EB grammar subset is as follows: Fig.10As shown in the figure, the event Events includes initialization events and several events. The initialization event consists of a series of assignment statements, which are executed only once before the Event-B model runs to complete the variable initialization. Other events Event mainly consists of three parts: Parameters, Guards and Actions. Guards mainly include the type definition of Parameters and several constraints that must be met before the event is executed. Actions consists of several assignment statements that modify the variable values.

[0123] In the embodiment of the present application, the grammatical structure of the assignment statement Assignment is as follows: Fig.11 As shown, it includes two types: EqualToAssign assignment and MemberOfAssign assignment. EqualToAssign can be subdivided into four types: IntegerETAssign, BoolETAssign, SetETAssign, and FuncETAssign, which support assignment between sets and functions. As for MemberOfAssign assignment, its semantics is to randomly extract an element from the right set expression and assign this element to the left variable identifier.

[0124] S2: Based on the defined input and output range, design specific transformation rules for each element in the Event-B model grammar subset;

[0125] In the embodiment of the present application, for each grammatical statement in the Event model grammar subset, the patent designs corresponding conversion rules to convert it into the corresponding Solidity grammar statement. On the basis of ensuring the semantic consistency of each statement conversion, the NEB2S tool adds support for variable operations such as sets and functions, allowing complex combinations and nestings between the grammatical components of the Event-B model, supporting a wider range of Event-B grammar functions.

[0126] In the embodiment of the present application, in order to realize the conversion between the Event-B model and the Solidity program, the present patent divides and corresponds the structure of the Event model and the Solidity program. Fig.12 As shown, the constants and set constants in the Event-B model correspond to the constants in the Solidity program, the variables in the model correspond to the variables declared in the Solidity program, the axioms and invariants in the Event-B model are converted into detection functions in the contract, and the model events and their internal parameters, guard conditions, and actions are converted into functions, function parameters, conditional statements, and corresponding assignment statement blocks in the contract.

[0127] In the embodiment of the present application, the following formula is used to illustrate the syntax conversion rule, wherein the EBGrammar above the horizontal line of the formula is the Sub-EB syntax structure to be converted, and the SDGrammar below the horizontal line is the Solidity syntax structure generated by the conversion. The formula semantics is that the Sub-EB syntax structure EBGrammar to be converted is converted into the corresponding Solidity syntax structure SDGrammar through the conversion tool NEB2S.

[0128]

[0129] In the embodiment of the present application, the conversion of the Sub-EB overall framework is as follows Fig.13 As shown in the figure, the Context and Machine contents in the Event-B model will be converted to the same contract file. The original grammatical components in Context and Machine have corresponding items in the Solidity contract, ensuring the correspondence between the Sub-EB grammatical structure and the Solidity grammatical structure. The auxiliary operator AuxiliaryFunc is an automatically generated fixed code used to assist in the implementation of set and function related operations.

[0130] In the embodiment of the present application, Sub-EB constant declaration supports three types: Integer, Bool and Set. NEB2S Fig.14 As shown, they are converted into three types in Solidity: int / uint, bool, and uint[]. At the same time, the identifier is modified with the "constant" keyword, and the specific type is determined by the predicate constraints in the axiom.

[0131] In the embodiment of the present application, Sub-EB variable declaration supports four types: Integer, Bool, Set and Function. NEB2S Fig.15 As shown in the figure, it is converted into four types in Solidity: int / uint, bool, uint[] and mapping. The conversion of Integer, Bool and Set types is basically the same as the constant part. The conversion of Function variables uses mapping variables to store mapping relationships, sets the uint[] array to track the domain of the mapping relationship, and completes the access and update of variables through auxiliary operators.

[0132] In the embodiment of the present application, the conversion rules of the two constraints of Axioms and Invariants in Sub-EB are as follows: Fig.16As shown, NEB2S will generate a special check function to check all constraint relationships. The predicates in Axioms and Invariants mainly include IdentTypeDefine and Predicate. IdentTypeDefine is used as a type declaration for constants and variables, and the parsing has been completed in the data declaration part. The predicate statement Predicate is converted to generate SDPredicate as the input of the assert function to ensure that the Event-B state always meets the relevant constraints.

[0133] In the embodiment of the present application, the predicate statement Predicate is composed of a series of relational predicate statements RelationalPred combined by connecting predicates, so the predicate statement Predicate can be specifically divided into two parts: the conversion of connecting predicate statements and the conversion of relational predicate statements. The connecting predicate statement mainly uses connectives to combine various predicate statements, such as Fig.17 As shown, the focus is on the conversion of conjunctions such as and, or, and not.

[0134] In the embodiment of the present application, the conversion of the relational predicate statement RelationalPred is as follows: Fig.18 As shown in the figure, the IntegerRelPred relational predicate inside it is mainly for comparing the size between Integer type expressions, and the BoolRelPred relational predicate statement is for comparing the equality between Bool type expressions. The relational predicates used by the two have corresponding relationships in Solidity programs and can be directly converted into relational statements in Solidity programs. As for the SetRelPred relational predicate statement, its function is mainly to compare the relationships between sets and between elements and sets, and the pre-generated auxiliary operators are required for conversion.

[0135] In the embodiment of the present application, the Sub-EB grammar subset supports three types of integer expressions: IntegerExp, Boolean expressions: BoolExp, and set expressions: SetExp. The operations related to integer expressions and Boolean expressions have corresponding operations in the smart contract program, so they can be directly converted into corresponding expression statements in the smart contract. Set expressions support intersection, union, and difference operations between sets, so they need to be as follows: Fig.19 As shown, the corresponding auxiliary operator is used to complete the conversion of the statement.

[0136] In the embodiment of the present application, the events of the Sub-EB grammar subset include initialization events InitialEvent and general events Event. The initialization event only includes actions Actions, while the general event Event includes parameters Parameters, guard conditions Guards and actions Actions. The following mainly describes the conversion of general events. Fig. 20 As shown in the figure, all events will be converted into functions with public visibility and bool return values. Parameters, guards, and actions in Event will be converted into function parameters, nested conditional statements, and assignment statements in the function. The non-terminal symbol checkAxmsAndInvs indicates the check of axioms and invariants, that is, each event will check the constraint status of the model before the execution ends.

[0137] In the embodiment of the present application, the assignment statement Assignment of the Sub-EB grammar subset can be divided into two categories: equality assignment EqualToAssign and randomness MemberOfAssign. The conversion rules are as follows: Fig.21 As shown. The logic of the equality assignment statement is basically the same as that of the smart contract assignment statement and can be directly converted; while the random assignment requires the random selection of set elements for assignment. The corresponding auxiliary operator is required to obtain random elements during the specific conversion. The FunceTAssign assignment statement in the equality assignment statement is quite special. It includes two types: FuncInitAssign and FuncOverrideAssign. The difference between the two is whether to clear the mapping relationship of the original Function variable. The auxiliary operator SDFuncVarIdentClear automatically completes the clearing of the mapping relationship, and SDFuncVarIdentPut automatically completes the modification of the mapping relationship.

[0138] S3: Use programming language to convert Event-B model into Solidity code to complete the formal design and development of smart contracts.

[0139] In the embodiment of the present application, the Java programming language is used to develop the NEB2S tool to complete the lexical analysis, syntax analysis and corresponding semantic conversion of the Event-B model, and the tool supports cross-platform calls.

[0140] In the embodiment of the present application, the NEB2S tool function is mainly to convert the Event-B modeling language to the Solidity smart contract language. Its workflow is as follows: Fig. 22As shown in the figure, the conversion of a model requires steps such as lexical analysis, syntactic analysis, semantic conversion, exception handling and symbol table management. Lexical analysis completes the word parsing of the Event-B model and uses the parsed word sequence as the input of syntactic analysis. Syntactic analysis organizes the word sequence and constructs the model syntax tree and symbol table. Finally, the semantic conversion module completes the semantic conversion of the syntax tree statement nodes according to the model syntax tree and symbol table to generate the target smart contract code.

[0141] In the embodiment of the present application, the NEB2S tool is implemented in Java programming language to implement the analysis and conversion of Event-B model from the bottom layer. Fig.23 As shown in the figure, it mainly includes sub-directories such as entity, syntax, core, util and exception. The entity directory mainly includes Event-B model words, symbols, word types, symbol types and other basic entities and corresponding managers; the syntax directory includes various grammatical component classes of the Event-B model, and the grammatical component classes refer to each other to form a syntax tree; the core directory stores the core tool classes, including startup class, lexical analysis class and grammatical semantic analysis class; the util tool directory stores the character input management class and output management class used by the project; exception is the exception class thrown by the project, including lexical exception, grammatical exception and semantic exception.

[0142] In the embodiment of the present application, the NEB2S tool lexical analysis word parsing logic is as follows: Fig.24 As shown, after the parsing starts, the next character is read backward continuously. If the character does not exist, the parsing is completed. After the program gets a character, it will determine the type. If it is a letter, it will continue to read until a complete word is parsed. It will determine whether the word is a reserved word or an identifier, and then the word will be queued to continue parsing the next character; if it is a number, it will continue to read until a complete number word is parsed, and then the word will be queued to continue parsing; if it is a comment, the entire line after that will be ignored, and the comment information can also be backed up; if it is a special character, the specific type will be determined, and the corresponding character word will be created, and then the word will be queued to continue parsing; if it is an unknown word, an exception will be thrown.

[0143] In the embodiment of the present application, after the NEB2S tool completes the lexical analysis, the key of the Event-B model syntax tree is performed, and each grammatical component is organized in a combined form, and its organizational structure is as follows: Fig.25As shown in the figure, the solid box represents the grammatical subclass, the solid arrow represents the inclusion relationship, the number on the solid arrow represents the number of inclusions, and the dotted arrow represents the recursive reference. For the Event-B model that meets the grammatical requirements, after completing the lexical parsing, the NEB2S tool will parse it into a grammatical tree with the following structure based on the grammatical rules defined in the previous chapter through the recursive subroutine method, and generate a symbol table of the corresponding structure at the same time, and finally perform semantic conversion based on the grammatical tree and the symbol table.

[0144] In the embodiment of the present application, the semantic conversion work of the NEB2S tool is mainly carried out according to the grammar conversion rules defined in the previous chapters, that is, after completing the grammar analysis work to obtain the grammar tree and the multi-level symbol table, the grammar component nodes of the grammar tree are deeply traversed, and the statement conversion is performed according to the grammar conversion rules, and the conversion result is output to the corresponding document to complete the generation of the target smart contract code. For all grammar component classes, a trans2Solidity method is implemented internally. This method accepts a custom character output file object and a multi-level symbol table as input, and recursively calls the trans2Solidity method of the grammar component class it contains, and then splices the conversion statement according to the return information, and outputs it to the character output file object after the splicing is completed.

[0145] In the embodiment of the present application, the main design principles of the NEB2S tool of the present invention include three parts: Event-B grammar subset definition, Event-B grammar subset conversion, and compilation conversion tool implementation. The Event-B grammar subset definition part mainly completes the definition of the Event-B model grammar subset through the EBNF paradigm; the Event-B grammar subset conversion part defines the conversion rules based on the defined grammar subset to achieve a one-to-one correspondence between the Event-B model grammar components and the Solidity contract grammar components; the compilation conversion tool part explains the specific implementation process of the NEB2S tool.

[0146] In the embodiments of the present application, the present invention aims to realize the conversion of the Event-B formal model to the Solidity smart contract program, to assist in the formal design and development of the smart contract, and after completing the modeling and verification of the Event-B model, the corresponding Solidity smart contract program can be generated through the NEB2S tool to realize the online conversion of the formal model and the smart contract, thereby effectively improving the security of the smart contract.

[0147] This embodiment also provides an Event-B model smart contract conversion system, including:

[0148] The grammar definition module is used to set the input and output range of the conversion tool using the extended Backus-Naur form;

[0149] The semantic transformation module is used to design specific transformation rules for each element in the Event-B model grammar subset based on the defined input and output ranges;

[0150] The code generation module is used to convert the Event-B model into Solidity code using a programming language to complete the formal design and development of smart contracts.

[0151] Furthermore, it also includes:

[0152] Memory, used to store programs;

[0153] A processor is used to load the program to execute the Event-B model smart contract conversion method.

[0154] This embodiment also provides a computer-readable storage medium, which stores a program. When the program is executed by a processor, the Event-B model smart contract conversion method is implemented.

[0155] The storage medium proposed in this embodiment and the Event-B model smart contract conversion method proposed in the above embodiment belong to the same inventive concept. The technical details not described in detail in this embodiment can be referred to the above embodiment, and this embodiment has the same beneficial effects as the above embodiment.

[0156] Through the above description of the implementation methods, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ReadOnly, Memory, ROM), random access memory (RandomAccess Memory, RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform the methods of various embodiments of the present invention.

[0157] Example 2

[0158] This is an embodiment of the present invention, which provides an Event-B model smart contract conversion system, including a syntax definition module, a semantic conversion module and a code generation module;

[0159] In the embodiment of the present application, the grammar definition module includes using the extended Backus-Naur Form to set the input and output range of the conversion tool;

[0160] In the present application embodiment, the input and output grammar acceptable to the NEB2S tool is explicitly described using the extended Backus-Naur form (EBNF). The supported Event-B model grammar subset and the generated Solidity contract grammar subset are defined to ensure semantic consistency during the conversion process. The foundation is laid for the subsequent conversion rule design. By defining a limited Event-B grammar subset (Sub-EB) and a corresponding Solidity grammar subset (Sub-SD), it is ensured that the NEB2S tool can effectively convert the formalized Event-B model into an actual executable smart contract code. The text (Context) and machine (Machine) parts of the Event-B model are described, including the elements (such as constants, sets, axioms, variables, invariants, and events) contained in each of them, and the relationship between these elements, such as the "sees" relationship between the machine and the text, is clarified. The data declarations of constants, set constants, variables, and parameters are specified, which enables the NEB2S tool to recognize and correctly process these declarations and map them to the corresponding data types and declaration methods in Solidity. Restrictions on data usage are defined through Axioms, Invariants, and Guards, ensuring the logical consistency and correctness of the model's state. These constraints will be taken into account during the conversion process to ensure that the generated Solidity code conforms to the expected behavior. Explains how predicate statements and expressions are constructed, which is crucial to understanding the logical semantics of the Event-B model and is the basis for maintaining semantic consistency during the conversion process. Describes the composition of initialization events and other events, especially guard conditions and actions, which are the core of the model's dynamic behavior and determine the logic of state changes. This section is very important to ensure that the converted Solidity contract can accurately reflect the behavior of the original Event-B model. Clarifies the specific format of the assignment operation, which is necessary to translate state changes in the Event-B model into equivalent operations in the Solidity contract.

[0161] In the embodiment of the present application, the semantic conversion module includes designing specific conversion rules for each element in the Event-B model grammar subset based on the defined input and output ranges;

[0162] In the embodiment of the present application, the specific conversion rules include that the Context and Machine contents in the Event-B model will be integrated into the same Solidity contract file to ensure the one-to-one correspondence between the Sub-EB syntax structure and the Solidity syntax structure. Auxiliary operators (AuxiliaryFunc) are automatically generated fixed codes to assist in the implementation of set and function related operations. The integer, Boolean and set constants in Sub-EB are converted to int / uint, bool and uint[] types in Solidity, respectively, and modified with the constant keyword to ensure immutability. Variables support four types: integer, Boolean, set and function. The conversion method of the first three is similar to that of constants; variables of function type use mapping to store mapping relationships, and access updates are completed through auxiliary operators. These constraints are converted to check functions (check) in Solidity contracts to detect whether all constraint relationships are satisfied. Among them, predicate statements (Predicate) are converted to the input of assert functions to ensure state consistency. Use logical connectives (such as and, or, not) to combine various predicate statements and directly map to the corresponding logical operators in Solidity. Integer and Boolean type relational predicates can be directly converted to relational expressions in Solidity, while set type relational predicates need to be processed with the help of pre-generated auxiliary operators. Integer expressions (IntegerExp) and Boolean expressions (BoolExp) are directly converted to the corresponding expression statements in Solidity. Set expressions (SetExp) support intersection, union, and difference operations between sets, and auxiliary operators are required to complete the conversion. Initialization events (InitialEvent) contain a series of assignment statements used to set the initial state. Usually, events (Event) are converted into functions with public visibility and bool return values. Parameters, guard conditions and actions are converted into function parameters, nested conditional statements and assignment statements respectively. The check function (checkAxmsAndInvs) is called before and after each event to verify the model constraint status; equality assignment (EqualToAssign) is directly converted into assignment statements in Solidity. Function assignment (FuncETAssign) is divided into initialization (FuncInitAssign) and overwriting (FuncOverrideAssign), which involves the cleaning and modification of mapping relationships. Random assignment (MemberOfAssign) randomly selects elements from the collection for assignment, and auxiliary operators are required to obtain random elements.

[0163] In an embodiment of the present application, the code generation module includes converting the Event-B model into Solidity code using a programming language to complete the formal design and development of the smart contract.

[0164] In the embodiment of the present application, the workflow of NEB2S mainly includes lexical analysis, grammatical analysis, semantic conversion, exception handling and symbol table management; lexical analysis includes parsing the word sequence of the Event-B model, identifying and classifying characters, identifiers, numbers, comments and special characters, and constructing basic vocabulary units. Syntactic analysis includes organizing word sequences, constructing a syntax tree of the model, and generating a symbol table based on the results of lexical analysis. Semantic conversion includes deeply traversing each node of the syntax tree according to the defined syntax conversion rules, performing semantic conversion, and finally outputting the target smart contract code. Exception handling and symbol table management are included in the whole process. NEB2S will continuously monitor and handle various exceptions that may occur, and maintain and update the symbol table to support subsequent conversion operations. NEB2S is implemented in Java programming language, including entity directory, syntax directory, core directory, util directory and exception directory. The entity directory contains the basic entity classes of Event-B model and their managers, such as words, symbols, word types and symbol types. The syntax directory defines the classes of each grammatical component of the Event-B model. These classes reference each other to form a syntax tree. The core directory stores the core classes of the tool, including startup class, lexical analysis class and grammatical semantic analysis class. The util directory provides character input management and output management functions. The exception directory defines a variety of exception classes for handling errors in lexical, grammatical and semantic analysis.

[0165] In an embodiment of the present application, the lexical analysis and parsing logic includes reading character by character and determining the character type, identifying letters, numbers, comments, and special characters, and for letters and numbers, continuing to read until a complete word or number is formed, and determining whether it is a reserved word, identifier, or numeric value, ignoring comment lines, but optionally backing up comment information, and for unknown words, throwing an exception to indicate an error.

[0166] In the embodiment of the present application, the organizational structure of the grammatical components is represented by a solid box to represent a grammatical subclass, a solid arrow to represent an inclusion relationship, and a dotted arrow to represent a recursive reference. For the Event-B model that meets the grammatical requirements, NEB2S uses the recursive subroutine method to parse it into a grammatical tree and generate a corresponding symbol table to prepare for subsequent semantic conversion.

[0167] In the embodiment of the present application, semantic conversion is the core part of NEB2S. The specific steps include deeply traversing each node of the syntax tree after completing the syntax analysis, calling the trans2Solidity method in each syntax component class according to the syntax conversion rules defined in the previous chapter. The method accepts a custom character output file object and a multi-level symbol table as input, recursively calls the trans2Solidity method of the included syntax component class, splices the returned conversion statements, and finally outputs them to the character output file to complete the generation of the smart contract code.

[0168] Through the division of labor and collaboration among these three modules, the NEB2S tool can efficiently and accurately complete the conversion from formal modeling language to smart contract language, ensuring the security, reliability and consistency of the conversion process.

[0169] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. An Event-B model smart contract conversion method, characterized in that: include: Use the extended Backus-Naur Form to set the input and output range of the conversion tool; Based on the defined input and output range, design specific transformation rules for each element in the Event-B model grammar subset; Use programming language to convert Event-B model into Solidity code to complete the formal design and development of smart contracts.

2. The Event-B model smart contract conversion method according to claim 1, characterized in that: The method of using the extended Backus-Naur form to set the input and output range of the conversion tool includes the following steps: Select and apply the Extended Backus-Naur Form as the description language to describe the Event-B model input and Solidity contract output acceptable to the NEB2S tool; The Event-B model syntax subset that the NEB2S tool supports conversion and the output Solidity contract syntax subset are defined in grammar form.

3. The Event-B model smart contract conversion method according to claim 1 or 2, characterized in that: The method of defining the Event-B model grammar subset supported by the NEB2S tool for conversion in grammar form includes the following steps: Define the Event-B model structure; The Extended Backus-Naur Form is used to summarize the grammatical subsets of the Event-B model and Solidity smart contract, which are called Sub-EB and Sub-SD respectively; Clarify the grammatical structure of the Sub-EB model framework; Specifies the data declaration method for Constants, Sets, Variables, and Parameters in the Sub-EB syntax subset, supporting multiple data types; Use Axioms, Invariants, and Guards to constrain declared data; Clarify the supported data types, including integers, Booleans, collections, and functions, and describe in detail the support scope of each type; Construct logical predicate statements, including logical connectives and multi-level nested structures; Defines grammatical rules for integer expressions, Boolean expressions, and set expressions, allowing for numerical, logical, and set operations; Describe the structure of initialization events and common events, and the guard conditions must be met before the action can be executed; Defines two forms of assignment statements, including equal assignment and member assignment.

4. The Event-B model smart contract conversion method as claimed in claim 3, characterized in that: The defined Event-B model structure consists of two parts: Context and Machine. The text Context includes constants, set constants, and axioms. The Machine includes variables, invariants and events; Events include initialization events and normal events. The initialization event is executed once when the model starts running to complete the initial assignment of variables; The common events include parameters, guard conditions and actions.

5. The Event-B model smart contract conversion method according to claim 4, characterized in that: The specific conversion rules are designed for each element in the Event-B model grammar subset, including the following steps: The Event model and the structure of the Solidity program are divided and matched; The constants and set constants in the Event-B model correspond to the constants in the Solidity program; The variables in the Event-B model correspond to the variables declared in the Solidity program; The axioms and invariants in the Event-B model are converted into detection functions in the Solidity program; The events and their internal parameters, guard conditions, and actions in the Event-B model are converted into functions, function parameters, conditional statements, and corresponding assignment statement blocks in the Solidity program.

6. The Event-B model smart contract conversion method according to claim 5, characterized in that: The method of converting the Event-B model into Solidity code using a programming language includes the following steps: Divide the project structure into multiple subdirectories, including entity directory, syntax directory, core directory, util directory and exception directory; The entity directory includes the basic entity class of the Event-B model and its manager; The syntax directory defines the classes of each grammatical component of the Event-B model, and the grammatical component classes reference each other to form a syntax tree; The core directory includes three parts: startup class, lexical analysis class and grammatical semantic analysis class; The util directory includes character input management classes and output management classes used by the storage project; The exception is the exception class thrown by the project, including lexical exceptions, grammatical exceptions and semantic exceptions.

7. The Event-B model smart contract conversion method according to claim 6, characterized in that: The lexical analysis class includes lexical analysis logic; The lexical analysis logic includes the following steps: After parsing starts, the next character is read backward continuously. If the character does not exist, parsing ends. If the program gets a character, it performs type determination; If the character starts with a letter, continue reading until a complete word is parsed; If the word is determined to be a reserved word, continue parsing the next character after the word is queued; If the word is judged to be an identifier, continue parsing the next character after the word is queued; If the character starts with a number, continue reading until a complete number word is parsed, and then put the word into the queue to continue parsing; If the character starts with a comment, this line is ignored and the comment information is backed up; If it is a special character, determine the specific type, create a corresponding character word, and queue the word to continue parsing; If it is an unknown word, the output parsing exception is generated.

8. A system based on the Event-B model smart contract conversion method according to claim 1, characterized in that: The grammar definition module is used to set the input and output range of the conversion tool using the extended Backus-Naur form; The semantic transformation module is used to design specific transformation rules for each element in the Event-B model grammar subset based on the defined input and output ranges; The code generation module is used to convert the Event-B model into Solidity code using a programming language to complete the formal design and development of smart contracts.

9. A computing device, characterized in that include: Memory, used to store programs; A processor, used to load the program to execute the steps of the Event-B model smart contract conversion method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a program, characterized in that: When the program is executed by the processor, the steps of the Event-B model smart contract conversion method as described in any one of claims 1 to 7 are implemented.

Images