Intelligent legal contract construction execution method and system based on domain-specific language

Abstract

The invention discloses an intelligent legal contract construction execution method and system based on a domain-specific language, and belongs to the technical field of information. The method comprises the steps of performing formalized representation on legal provisions in a legal contract according to an SLL language, and generating an Event-B basic model of the intelligent legal contract; the Event-B basic model is converted into an executable Solidity code by means of a target language conversion mapping rule; after the Solidity code is verified, the Solidity code is published on the block chain, so that deployment of the intelligent legal contract is realized; and when the contract terms of the intelligent legal contract are triggered, automatically running the intelligent legal contract in the block chain, and storing a running result in the block chain in a set form. Through the method and the system for operating the method, the related problems of ambiguity, low efficiency and difficulty in understanding of the existing intelligent legal contract language expression are solved.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and more particularly to an intelligent legal contract construction and execution method and system based on a domain-specific language. Background Art

[0002] At present, as a computational trading protocol that can automatically execute contract terms, smart contracts have become the technical infrastructure for defining contractual relationships in digital social activities. The characteristics of smart contracts determine their great application potential in the fields of law, finance, and accounting.

[0003] However, due to many limiting factors such as the ambiguity of language, difficulty in cross-domain collaboration, non-reusability of models, and imperfect regulatory regulations, there are many difficulties in the legal application of smart contract technology, which greatly hinders the integration of blockchain smart contract technology and legal theory.

[0004] Therefore, how to provide an understandable, reusable, and verifiable intelligent legal contract construction and execution method and system is an urgent problem to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, the present invention provides an intelligent legal contract construction and execution method and system based on a domain-specific language, which is used to solve at least some of the technical problems in the background art.

[0006] To achieve the above object, the present invention adopts the following technical solutions:

[0007] The present invention first discloses an intelligent legal contract construction and execution method based on a domain-specific language, including the following steps:

[0008] 1) Formalize the legal provisions in the legal contract according to the SLL language to generate the Event-B basic model of the intelligent legal contract. The Event-B basic model includes a context and an abstract machine. The context is used to define the static scenarios and constants in the legal contract, and the abstract machine is used to define the state variables and initial values during the execution of the legal contract;

[0009] 2) Use the target language conversion mapping rules to convert the Event-B basic model into executable Solidity code;

[0010] 3) Verify the Solidity code and then publish it on the blockchain to achieve the deployment of the intelligent legal contract;

[0011] 4) After the contract terms of the intelligent legal contract are triggered, the intelligent legal contract is automatically executed in the blockchain, and the execution result is stored in the blockchain in a set form.

[0012] Preferably, in step 1), it further includes classifying the Event-B basic model according to different proof obligation rules, and the classification results specifically include:

[0013] INV model: The INV model is used to verify the transactions that remain unchanged in the intelligent legal contract, including the information of the contract parties and the asset attribute information;

[0014] FIS model: The FIS model is used to verify the possibility of non-deterministic actions in the intelligent legal contract, including the default conditions and the changes in the attributes of the contract ontology after the penalty measures are triggered;

[0015] SIM model: The SIM model is used to verify whether there are contradictions in the associated attributes when multiple events in the intelligent legal contract are executed simultaneously.

[0016] Preferably, in step 1), the provisions in the legal contract are formally represented according to the SLL language, specifically including extracting the legal ontology concepts in the legal text by using the ontology model based on the legal core;

[0017] Defining sets, constants, and axioms in the legal ontology concepts by using the SLL language;

[0018] Among them, the set includes: entities participating in legal acts, and the entities include Party A, Party B, assets, and intermediary institutions;

[0019] The constants include: entity constants participating in legal acts, and term constants of legal acts.

[0020] The axioms are used to define the data types and data relationships of each constant;

[0021] Converting the sets, constants, and axioms defined by the SLL language to the Event-B basic model by using the Backus BNF paradigm.

[0022] Preferably, the state variables in the execution process of the legal contract in step 1) include service terms, default terms, and termination terms,

[0023] The service default types defined in the service terms include that the service has not been delivered and the deposit has not been paid after the service is delivered;

[0024] The contract default types defined in the default terms include that the house has not been delivered and the time since the last payment is more than 30 days but not more than 60 days;

[0025] The types of contract termination defined in the termination clause include contract expiration, failure to deliver the house within the specified time, and overdue payment.

[0026] Preferably, in step 2), the target language conversion mapping rules specifically include:

[0027] Mapping the statement functions in the SLL language to equivalent Solidity code functions;

[0028] Mapping the context Context and abstract machine Machine defined in the SLL language to the hierarchical structure of Solidity code.

[0029] The present invention also discloses an intelligent legal contract construction and execution system based on a domain-specific language, including a basic model construction module, an executable code conversion module, an intelligent legal contract deployment module, and an intelligent legal contract operation module;

[0030] Among them, the basic model construction module is used to formally represent the legal provisions in the legal contract according to the SLL language, generate an Event-B basic model of the intelligent legal contract. The Event-B basic model includes a context Context and an abstract machine Machine. The context Context is used to define the static scenarios and constants in the legal contract, and the abstract machine Machine is used to define the state variables and initial values during the execution of the legal contract;

[0031] The executable code conversion module is used to convert the Event-B basic model into executable Solidity code by using the target language conversion mapping rules;

[0032] The intelligent legal contract deployment module is used to verify the Solidity code and then publish and deploy it on the blockchain;

[0033] The intelligent legal contract operation module is used to automatically run the intelligent legal contract in the blockchain when the contract terms of the intelligent legal contract are triggered, and store the operation results in the blockchain in a set form.

[0034] Preferably, the above system further includes a basic model classification module, and the basic model classification module is used to classify the Event-B basic model according to different proof obligation rules. The classification results specifically include:

[0035] INV model: The INV model is used to verify the transactions that remain unchanged in the intelligent legal contract, including the information of the contract parties and the asset attribute information;

[0036] FIS model: The FIS model is used to verify the possibility of non-deterministic actions in intelligent legal contracts, including default conditions and changes in the properties of the contract ontology after the triggering of penalty measures;

[0037] SIM model: The SIM model is used to verify whether contradictions in associated properties occur when multiple events are executed simultaneously in an intelligent legal contract.

[0038] Preferably, in the basic model construction module, the provisions in the legal contract are formally represented according to the SLL language. Specifically, it includes extracting legal ontology concepts in the legal text using an ontology model based on the legal core;

[0039] Defining sets, constants, and axioms in the legal ontology concepts using the SLL language;

[0040] Among them, the set includes: entities participating in legal acts, and the entities include Party A, Party B, assets, and intermediary institutions;

[0041] The constants include: entity constants participating in legal acts and term constants of legal acts;

[0042] The axioms are used to define the data types and data relationships of each constant;

[0043] Converting the sets, constants, and axioms defined by the SLL language to the Event-B basic model using the Backus BNF paradigm.

[0044] Preferably, in the basic model construction module, the abstract machine Machine is used to define the state variables during the execution of the legal contract, specifically including:

[0045] Service terms, default terms, and termination terms,

[0046] The service default types defined in the service terms include that the service has not been delivered and the deposit has not been paid after the service is delivered;

[0047] The contract default types defined in the default terms include that the house has not been delivered and the time since the last payment is more than 30 days but not more than 60 days;

[0048] The contract termination types defined in the termination terms include contract expiration, the house not being delivered within the specified time, and overdue payment.

[0049] Preferably, in the executable code conversion module, the target language conversion mapping rules for converting the Event-B basic model into executable Solidity code specifically include,

[0050] Map the statement functions in the SLL language to equivalent Solidity code functions;

[0051] Map the Context and Machine defined in the SLL language to the hierarchical structure of Solidity code

[0052] As can be seen from the above technical solutions, compared with the prior art, the present invention discloses a method and system for constructing and executing intelligent legal contracts based on a domain-specific language, which has the following beneficial effects:

[0053] The present invention discloses an ontology-based legal provision representation modeling, which solves the problems related to the ambiguity, inefficiency, and difficulty in understanding of the existing intelligent legal contract language expressions;

[0054] The present invention solves the problem of the lack of a conversion bridge between legal provisions in natural language and intelligent contracts based on programming languages; and completes the security detection of intelligent contract execution through a formal model detection tool. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained according to the provided drawings.

[0056] Figure 1 It is a schematic flowchart of the method provided by the embodiment of the present invention;

[0057] Figure 2 It is a schematic diagram of the steps of the intelligent legal contract development process provided by the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0058] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0059] Embodiment 1

[0060] The embodiment of the present invention discloses a method for constructing and executing an intelligent legal contract based on a domain-specific language, as Figure 1 、 Figure 2 shown, and generally includes the following steps:

[0061] 1) Formalize the legal provisions in a legal contract according to the SLL language to generate the Event-B basic model of an intelligent legal contract. The generated Event-B basic model includes a context and an abstract machine. Among them, the context is used to define the static scenarios and constants in the legal contract, and the abstract machine is used to define the state variables and initial values during the execution of the legal contract.

[0062] Formalize the legal provisions according to the SLL language to generate the Event-B basic model. First, extract the legal ontology concepts in the legal text using the ontology model based on the legal core; then define the sets, constants, and axioms in the legal contract using the SLL language.

[0063] Among them, the sets include: entities participating in legal acts, and the entities include Party A, Party B, assets, and intermediary agencies.

[0064] The constants include: entity constants participating in legal acts, and term constants of legal acts.

[0065] The axioms are used to define the data types and data relationships of each constant;

[0066] Then convert the sets, constants, and axioms defined by the SLL language to the Event-B basic model using the Backus-Naur form (BNF).

[0067] The state variables of the abstract machine include service terms, default terms, and termination terms.

[0068] The service default types defined in the service terms include the service not being delivered yet, and the deposit not being paid after the service is delivered;

[0069] The contract default types defined in the default terms include the house not being delivered yet, and the time from the last payment being more than 30 days but not more than 60 days;

[0070] The contract termination types defined in the termination terms include the contract expiration, the house not being delivered within the specified time, and the payment being overdue.

[0071] 2) Use the target language conversion mapping rules to convert the Event-B basic model into executable Solidity code.

[0072] In this step, the state variables during the execution of the legal contract defined by the abstract machine include specifically: service terms, default terms, and termination terms.

[0073] Among them, the types of service defaults defined in the service terms include that the service has not been delivered and the deposit has not been paid after the service is delivered; the types of contract defaults defined in the default terms include that the house has not been delivered and the time from the last payment exceeds 30 days but does not exceed 60 days; the types of contract terminations defined in the termination terms include contract expiration, the house not being delivered within the specified time, and overdue payment.

[0074] 3) After verifying the Solidity code, publish it on the blockchain to realize the deployment of the intelligent legal contract.

[0075] 4) When the contract terms of the intelligent legal contract are triggered, automatically run the intelligent legal contract in the blockchain and store the operation result in the blockchain in a set form.

[0076] As a preferred implementation manner, step 1) further includes classifying the Event-B basic model according to different proof obligation rules, specifically as follows:

[0077] INV model: The INV model is used to verify the transactions that remain unchanged in the intelligent legal contract, including the information of the contract parties and the information of the asset attributes;

[0078] FIS model: The FIS model is used to verify the possibility of non-deterministic actions in the intelligent legal contract, including the default conditions and the changes in the attributes of the contract ontology after the penalty measures are triggered;

[0079] SIM model: The SIM model is used to verify whether there are contradictions in the associated attributes when multiple events in the intelligent legal contract are executed simultaneously.

[0080] Embodiment 2

[0081] The embodiment of the present invention discloses an intelligent legal contract construction and execution system based on a domain-specific language, which is used to implement any one of the methods in Embodiment 1, including a basic model construction module, an executable code conversion module, an intelligent legal contract deployment module, and an intelligent legal contract operation module;

[0082] Among them, the basic model construction module is used to formally represent the legal provisions in the legal contract according to the SLL language, generate the Event-B basic model of the intelligent legal contract, and the Event-B basic model includes a context Context and an abstract machine Machine. The context Context is used to define the static scenarios and constants in the legal contract, and the abstract machine Machine is used to define the state variables and initial values in the execution process of the legal contract;

[0083] An executable code conversion module, configured to convert the Event-B basic model into executable Solidity code by using a target language conversion mapping rule;

[0084] An intelligent legal contract deployment module, configured to verify the Solidity code and then publish and deploy it on a blockchain;

[0085] An intelligent legal contract operation module, configured to automatically run the intelligent legal contract in the blockchain when the contract terms of the intelligent legal contract are triggered, and store the operation result in the blockchain in a set form.

[0086] Embodiment 3

[0087] The present invention provides a method for constructing and executing an intelligent legal contract based on a domain-specific language. The proposed method can be applied to scenarios related to the execution of legal contracts in various fields. In Embodiment 3, the execution method of the present invention is described with a house rental scenario. This embodiment applies the method for generating and verifying intelligent contracts based on a domain-specific language to a house rental contract, realizing cross-domain collaborative development, breaking through the boundary limitations of grammar semantics and legal elements, and achieving a formalized expression of legal provisions.

[0088] Entities involved in the house rental scenario include Party A, Party B, assets, and intermediary agencies, etc. The parties of Party A and Party B first reach an agreement on relevant matters of the contract and draw up a lease contract. For example, in the house rental scenario, generally the lessor provides the lease contract, and the lessee can put forward modification requirements. After the two parties reach an agreement, relevant legal workers will represent the contract as an intelligent contract template according to the grammar rules for the parties, asset details, and information related to data transactions, and use the automatic grammar detection function of the compiler to verify and determine the correctness of the grammar, and finally publish it to the blockchain network. Party A and Party B complete the transaction process through the lease contract. When a dispute occurs during the performance of the contract, the constructed intelligent contract will run penalty arbitration actions according to predefined event rules to handle the transaction dispute, and the arbitration result information can be stored in the blockchain network.

[0089] Specifically, first, legal ontology concepts in legal texts are extracted by using an ontology model based on the legal core. The ontology model based on the legal core is obtained by expanding and refining the Unified Foundational Ontology (UFO). Specific legal ontology concepts specifically include the following:

[0090] 1. Contract: A set of obligations and powers between two or more roles, which are allocated to each party during the execution of a transaction and involve two or more assets (each role is associated with at least one asset, and the relationship between the role and the asset is one-to-many).

[0091] 2. Assets: Tangible or intangible assets owned by a role, including various considerations involved in a contract. Other types of assets can also be used to maintain the proper execution of a contract. For example, in a real estate lease contract, the tenant may need to provide a deposit as security. This deposit, as an asset, ensures that the tenant complies with the contract terms.

[0092] 3. Legal Status: The legal status mainly describes the legal relationship between roles. The status serves as a precondition (antecedent) for triggering transactions and also accepts the execution results of transactions. It is the key primary key for maintaining the execution of a contract.

[0093] 4. Rights: The right of a role to establish, change, or terminate its legal status. It is instantiated by a trigger and must meet the corresponding preconditions (fed back by the legal status) to become effective.

[0094] 5. Obligations: When a legal status (antecedent) is established, the debtor has a legal obligation to the creditor for a certain legal status (consequence). In some cases, the termination time of the contract is inconsistent with the termination time of the obligation, and there is a situation where the remaining obligations still persist after the contract ends. For example, in a confidentiality agreement, even after the contract has terminated, both parties often still need to continue to fulfill their confidentiality obligations.

[0095] 6. Transactions: Things that happen at a certain point in time. The state of the contract divides events into two situations: before the state and after the state. For example, in the scenario of prepayment, its pre-state is "paid" and the post-state is "shipped".

[0096] 7. Roles: The role characteristics of a contract are the carriers of all rights and obligations and are the basic elements of the entire legal act.

[0097] 8. Parties: The legal representatives who own assets and assume roles in a contract.

[0098] Then, using a legal contract modeling language based on DSL (Domain-Specific Language): (1) Basic Types and Contract States Provisions: SLL (Smart Contract Language) is a high-level DSL (Domain-Specific Language) that uses object-oriented abstractions to implement smart contracts. Its design considerations include multiple intents: First, its design allows for the expression of the same type of elements in a standardized way. The SLL language analyzes and extracts the original concepts of legal contracts based on ontology and shows the relationships between ontologies. Second, it is described using a syntax similar to natural language, making it easy to write and read. Finally, the defined contract logic should conform to the signing intention of the contract, and the consistency of the logic is judged by formal verification methods in the follow-up.

[0099] The SLL language is developed in Xtext, which is a framework for developing programming languages and DSLs. When writing, the most basic types are specified to support the syntactic expressions of various ontology values, including integers, strings, booleans, dates, and time periods such as PERIOD. The basic types include Boolean, String, Integer, Real, DataTime, and Duration. The last two types represent the basic time concepts of absolute time and relative time. To further improve the readability and applicability of the DSL, we have specified that the PERIOD type is specially set according to the payment cycle of the contract, and is divided into "month", "three months", "six months", and "year". The ontology set consists of parties, assets, contract status, and data. The contract participants in Party interact with Active, and the parties in Party have interrelated rights and responsibilities according to their different roles. The interaction corresponds to the event Event, and the result of the event will affect the status of the contract. The possible states of the contract are the following four:

[0100] Restart: When Active reaches the active state, it usually means that the house lease contract has been signed or the abnormal situation has been handled, and the contract comes into force officially

[0101] Expire: When Active needs to perform relevant obligations, corresponding events will be triggered for execution. Breach: When an abnormal event occurs, it will trigger Active to refuse to perform the corresponding operation and terminate the validity period of the contract.

[0102] Continuous: When the contract status is modified, if the contract remains valid, it will be triggered

[0103] In the example of the present invention, the preconditions and postconditions precisely specify the context of the contract, such as trigger events, conditions, and objects. The trigger events describe the situations in which the terms must be considered, as well as internal and external events. Internal events can be controlled by both parties to the contract (for example, actions completed, terms fulfilled), while external events cannot be controlled by the parties themselves (for example, the time termination of the contract). The preconditions in the terms define the time and status constraints that must be met after the trigger event occurs, and set obligations for the parties (postconditions).

[0104] Rights and obligations are most relevant to smart contract code because they contain the operations expected to be executed, corresponding to the transactions in the smart contract. Due to their dynamics and ambiguity in natural language contracts, their components cannot be precisely defined. However, through research on contracts, some structural components can be listed separately: participants, actions, and the modality of actions. For example, setting "the buyer must pay" in a clause involves the participant the buyer, the action pay, and the modality of necessity. The corresponding components of ordinary rights and obligations can be extracted and further serve as triggering conditions, legal acts, and objects involved in the contract, etc.

[0105] Clause expressions clarify the context of the contract in a more detailed way, divided into three major parts: triggering conditions, legal acts, and objects involved. Triggering conditions clearly stipulate in which specific situations the contract clauses should be considered. Triggering conditions can be further divided into internal events and external events. Internal events are events that can be controlled or generated by the contract parties. For example, the parties complete a certain agreed-upon act or reach a certain stage. External events, on the other hand, are events beyond the control of the parties, such as market price fluctuations. Next, the clause conditions clarify the time frame that must be met and the status requirements that must be satisfied in order to maintain the relevant clauses after the execution of the legal act. Finally, the objects involved not only refer to the parties but also include the entities that receive a certain act or are subject to measures, which may be people, things, or objects.

[0106] (1) Logical expressions are used to connect the relationships between two or more conditional expression statements. SLL defines common logical expressions.

[0107] (2) Relational expressions are used to express the magnitude and equality relationships between multiple constants and variables. SLL defines common relational expressions, namely >, <, >=, <=,!=, ==.

[0108] (3) Operational expressions are used to express the operational relationships between multiple constants and variables. SLL defines common operational expressions, namely +, -, *, / , +=, -=, **.

[0109] (4) Parameter expressions are used to express the parameter types involved in an expression. It is divided into two types: constant types and variable types. The constant types involved are generally Int, Boolean, Float, Double, Date, String, etc., which are all defined in SLL. The variable types involved in SLL are mainly related to the participants in the contract and are consistent with the variables mentioned in the above structure. The types of variables include Party, Date, Clause, Money, etc.

[0110] (5) Temporal expressions are used to express temporal constraints. Common temporal constraints are used to express the time span of events and the order of event development. SLL defines "for" to define the time length of an event. For example, "EventA for num days" means that the duration of EventA is num days; "within" is used to express the maximum time span of an event, "before" and "after" are used to express the order of events, and "precondition" and "postcondition" are used to distinguish the temporal preconditions and postconditions, and then the order between actions is connected. Of course, in addition to using temporal expressions, time points can also be directly compared to constrain temporal expressions.

[0111] Through these expressions, various conditional expressions can be formed. There are two common conditional expressions, and their formats are as follows.

[0112] (1) within num days after|before event

[0113] (2) A >|<|>=|<=|=|!= B (A and B respectively represent arithmetic expressions).

[0114] The constraint meaning of the first expression is to execute the next thing within a few days before or after something happens. The second expression is a specific arithmetic logic trigger, generally before or after a certain time point. These two expressions can cover most of the preconditions.

[0115] S103. Syntax of clause expressions;

[0116] SLL uses clauses to connect syntactic elements, and clauses and actions are most relevant. Given the dynamic nature of natural language expressing future possible actions of a contract, its composition cannot be clearly defined. Therefore, the structural modules proposed in the model need to be filled according to the actual situation. Most clauses (at least) consist of three parts: participants, actions, and the modality of actions. So in SLL, we define these three types of actions as keywords, and do not need to define and describe these three types of methods separately. Just input the corresponding parameters, and the corresponding format is as follows, which simplifies the use of the methods:

[0117] (1) transfer(SomeBodyA,SomeBodyB,NumOfMoney).

[0118] It means that money is transferred from A's account to B's account.

[0119] (2) change(AttributeOfAsset, StatusA, StatusB).

[0120] Indicates that an attribute variable of an asset changes from state A to state B.

[0121] (3) startContract() | pauseContract() | endContract().

[0122] They respectively represent the start of a contract, the suspension of a contract, and the termination of a contract, and the contract status variable changes accordingly.

[0123] S104, Formal verification of intelligent legal contracts;

[0124] Security is crucial for intelligent legal contracts because they can automatically process transactions with asset value. These contracts may face security threats due to blockchain vulnerabilities or contract algorithm defects, resulting in economic losses to the trading parties. The present invention uses formal methods to ensure its security. These methods essentially describe and verify computer systems through mathematical logic, which helps to find potential errors in the system. Given the high risk of funds, the Event-B method is selected in this paper. It is a semi-automatic but effective theorem verification means. Syntax errors will show prompt messages in the XText compiler. To ensure the consistency of event expressions between legal contracts and intelligent legal contracts and eliminate the ambiguity of contract language, formal verification tools in model checking need to be used. According to the syntax rules defined in the SLL language, the house lease contract is converted into an Event-B model.

[0125] The Event-B method uses type set theory as the symbolic language and is based on propositional logic and predicate logic. The composition of an Event-B model consists of two parts: one is the context used to express the static part of the model, and the other is the abstract machine used to express the dynamic part.

[0126] Language conversion rule mapping;

[0127] In the SLL language, the compiler implements the rules for mapping intelligent contract modules to Event-B and enables the compiler to automatically generate a contract framework as well as some functions and fields. The specific logic is completed by the user's inspection and supplementation.

[0128] By specifying key domain-specific constructs in SLL through predefined types, we propose an SLL-Event-B rule mapping that allows the automatic generation of executable Event-B code within the compiler. The concepts included in this mapping (such as parties, assets, events, etc.) corresponding to the structure of Event-B, and the entire Solidity code hierarchy is assembled after being converted by these given types. Finally, a source program can be formed based on this process and compiled into a target program to run in the actual blockchain environment.

[0129] The clause function of SLL has an equivalent mapping in Event-B as a function, and both express the same event in their respective grammars. During the execution of the contract, the events in the SLL function reflect external events and enter the Event-B platform through interaction (transferring element information to function methods). Event-B supports the concepts of arrays and mappings (dictionaries). A mapping can be regarded as a hash table, and through virtual initialization, every possible key exists and is mapped to a value with all bytes being zero. In addition, the automatic conversion of Event-B also has the following advantages: it can model business processes for different contract transactions; intelligent contract templates can achieve various functions only by following the template and configuring parameters and states; it is simple and convenient to use and easy to expand; it can be completed without relying on any other specialized tools.

[0130] For the specific mapping method, the present invention designs a translation (Tr) function for the mapping from SLL to Event-B. This function can perform the model conversion of Event-B according to the SLL grammar, clearly describe the SLL logic while retaining the original semantics.

[0131] The corresponding relationships among SLL, Event-B, and the function are shown in the following table:

[0132] Table 1 Corresponding Relationship Table among SLL, Event-B, and the Function

[0133] SLL Event-B Function to convert to BNF normal form Type Set, axiom <![CDATA[Tr1]]> Attribute Variable, invariant <![CDATA[Tr2]]> Constructor Initialization <![CDATA[Tr3]]> Basic function Event, constant <![CDATA[Tr4]]>

[0134] Next, the structures of each conversion rule will be given in detail respectively to convert SLL code into Event-B.

[0135] (1) Tr1: The type declarations in the SLL code are converted into sets and axioms in the Context. If a data type such as unsigned integer is used in SLL, we create a set in Event-B to represent it. For example, for the house information defined in the Context of the lease contract, we define a "House" set to store it, and create a "house_XXX" invariant in the refinements of C0 and Cn to represent all house-related information.

[0136] As shown in the following code, a rule for mapping to a set is defined using Backus-Naur Form (BNF) for unsigned integers, and a rule for mapping to the Context of Event-B is defined for custom types (such as "House").

[0137] <DSL_model>::=<type_section>

[0138] <type_section>::="type"<type_definitions>

[0139] <type_definitions>::=<type_definition>|<type_definition><type_definitions>

[0140] <type_definition>::=<simple_type>|<custom_type>

[0141] <simple_type>::="unsigned integer""maps to"<eventb_set>

[0142] <custom_type>::= <name>"maps to"<eventb_context>

[0143] <eventb_set>::="set" <name>

[0144] <eventb_context> ::= "Context" <context_definitions>

[0145] <context_definitions> ::= <set_definition> <axiom_definition>

[0146] <set_definition> ::= "set" <name>

[0147] <axiom_definition> ::= "axiom" <name>"represents" <description>

[0148] <name>::= / *A legal identifier, such as "House"* /

[0149] <description>::= / *A statement describing invariants, such as "house_XXX represents information related to the house”* /

[0150] (2) Tr2: Attribute declaration conversion for variables and invariants in the Machine of Event-B. In the Context, sets may need to use DSL to describe specific attributes of the house, such as status, rent, house type, etc. These are abstract descriptions of house characteristics, etc. In this invention, Tr2 is used to map attributes to "variables" and "invariants" in Event-B. For example:

[0151] The attribute house_status, represented by the string type, is used to indicate that the house has an attribute named house_status, and its type is string. Possible values include "vacant", "rented", etc.

[0152] When we map it to the Event-B model, a corresponding variable will be created, and an invariant will be defined to constrain or describe the meaning and possible states of this variable. The mapping result is as follows:

[0153] variable house_status

[0154] invariant house_status_invariant: house_status ∈ {"vacant", "rented"}

[0155] The rules for syntax mapping are defined as follows:

[0156] <DSL_model> ::= <attribute_section>

[0157] <attribute_section> ::= "type" <attribute_definitions>

[0158] <attribute_definitions> ::= <attribute_definition> | <attribute_definition> <attribute_definitions>

[0159] <attribute_definition> ::= <name> ":" <type>"maps to"<eventb_attribute>

[0160] <type>::= / *Supported data types in DSL, such as "integer", "string", etc.* /

[0161] <eventb_attribute>::= "variable" <var_definition> "invariant" <invariant_definition>

[0162] <var_definition>::= <name>

[0163] <invariant_definition>::= <name>"represents" <description>

[0164] <name>::= / *A valid identifier* /

[0165] <description>::= / * A statement describing an invariant, such as "house_status_XXX represents the current status of the house * /

[0166] (3) Tr3, Tr4: The function declarations convert events, initializations, etc. in the abstract machine Machine in Event-B. Assume that in the DSL, there is the following function description: function rentHouse(tenant: string), which means there is a function named rentHouse and 'tenant' represents the tenant name. When we map this function to the Event-B model, we create a corresponding event. This event may have a guard to check whether the current status of the house allows renting, and an action to update the status of the house.

[0167] Here, the rent guard_ rent ensures that the house can only be rented when its status is "vacant". When the guard condition is met, the action actact_rent will be executed to update the status of the house to "rented".

[0168] Using the syntax mapping described by the BNF paradigm, we can intuitively convert the function definitions in the DSL into events in the Event-B model, thus realizing the conversion between the DSL description and the formal model. The Tr3, Tr4 mapping conversion rules are as follows:

[0169] <DSL_model> ::= <function_section>

[0170] <function_section> ::= "function" <function_definitions>

[0171] <function_definitions> ::= <function_definition>

[0172] | <function_definition> <function_definitions>

[0173] <function_definition> ::= <name> "(” <parameter>")”"maps to”<eventb_event>

[0174] <parameters> ：：＝ <parameter> | <parameter> "，” <parameters>

[0175] <parameter> ：：＝ <name> "：” <type>

[0176] <eventb_event> ::= "event" <event_definition> "guard" <guard_definition> "action" <action_definition>

[0177] <event_definition> ::= <name>

[0178] <guard_definition>::= <name>"represents” <description>

[0179] <action_definition>::= <name>"represents” <description>

[0180] <name>::= / *A valid identifier* /

[0181] <type>::= / *Supported data types in DSL, such as "integer", "string", etc.* /

[0182] <description>::= / * A statement describing a guard or action, for example, "guard_XXX represents the current status of the house is vacant" * /

[0183] Case Verification:

[0184] To verify the effectiveness of the SLL language, the present invention will take "housing lease" as an example, comprehensively apply the above-mentioned SLL grammar specifications, and demonstrate the convenience, ease of use, and readability of the SLL language in the compilation of legal contracts. The basic information of the contract includes the information of the lessor, the lessee, and the house. The contract terms are divided into three parts: contract service terms, non-termination default terms, and termination default terms. In this contract, there is a time prerequisite - assuming each month has 30 days.

[0185] (1) Definition of basic information: The code is as follows. The definition of basic information includes the lessor, the lessee, the house, and related dates, etc.

[0186] (2) Instantiation of basic information: The code is as follows. In this part, both parties can input information from the outside. The information input in this contract is most of the information defined in the basic information.

[0187] (3) Definition of service terms: There are three service terms in the housing lease contract, namely the down payment term, the delivery term, and the regular payment term. In the first payment term, the lessee needs to pay the rent and deposit to the lessor, and the payment time becomes now. In the delivery term, the lessor transfers the right to use the house to the lessee within 7 days after the deadline of the first payment. In the traditional payment method, when the time is exactly 30 days after the last payment, the lessee transfers the rent to the lessor, and the last payment time is changed to the current time.

[0188] (4) Definition of default terms: There are two default terms in the housing lease contract, namely the default term for house delivery and the default condition for rent delivery. In the default term for house delivery, the current time has passed the start of the lease period and has not exceeded 7 days, but the right to use the house is still in the hands of the lessor. The lessor needs to pay compensation to the lessee and deliver the house. The other is that the time since the last payment exceeds 30 days but does not exceed 60 days. The lessee needs to compensate the lessor and change the payment time to the last payment time plus 30 days.

[0189] (5) Definition of termination clauses: There are three types of termination clauses in a housing lease contract, namely, expiration termination clause, delivery termination clause, and payment termination clause. In the expiration termination clause, the current time has exceeded the end of the lease term, and the right to use the house is returned to the lessor, and the contract is terminated. In the delivery termination clause, the current time exceeds 7 days from the start time of the lease term, but the right to use the house is still in the hands of the lessor. The lessor refunds the full amount of rent and deposit to the lessee, and the contract is terminated. In the default termination clause, the prerequisite is that the current time is more than 60 days since the last payment. According to the contract agreement, the lessee needs to return the right to use the house to the lessor, and the contract is terminated.

[0190] Here we analyze the contracts in reality and write the contract specifications in the order of parties, subject matter, domain attributes, additional information, terms, signing of the contract, etc. that appear in housing leases.

[0191] Secondly, we sort out the relationship between entities and attributes in combination with the semantics in SLL. Here we use the Xtext compiler to execute our SLL statements, specifically including the preprocessing of elements, extracting the domain identifiers and independent attribute sets in advance; then converting the AST structure; then performing recursive operations on the specified type of entities in the AST, and screening relevant information from them. These information cover the domain identifiers and attributes determined in the preprocessing stage, as well as the nested entity elements related to these entities.

[0192] It can be seen from this that the SLL clauses have strong and concise expression capabilities for contract clauses, including service clauses, default clauses, and termination clauses.

[0193] To verify the logical correctness of the contract expressed by SLL, we establish an Event-B model in the Rodin software to formally analyze and verify the consistency between the SLL model and the real contract, and provide the specific steps for the refinement of this method.

[0194] The following is demonstrated based on a real housing lease contract.

[0195] Initial model:

[0196] I. Context:

[0197] To model the contract expressed by SLL, we first construct an initial model to simply describe the ontology and action execution process of the housing lease contract. The set of legal ontologies is represented in the context, and the event settings of default clauses and termination clauses are established in the abstract machine.

[0198] In the context "RentingContext2", some key global constants and sets in the housing lease contract are defined to form a static framework for the rental environment.

[0199] SETS: First, a set named "PARTIES" is defined, which represents all entities that may participate in a lease transaction.

[0200] CONSTANTS: Here, we declare some global constants, including:

[0201] landlord: Represents the lessor, i.e., the owner or manager of the house;

[0202] tenant: Represents the lessee, i.e., the individual or entity that rents the house;

[0203] house: Represents the house, which may be its quantity or identifier;

[0204] rent: Represents the rent, i.e., the amount regularly paid by the tenant;

[0205] deposit: Represents the deposit, which is the security provided by the tenant;

[0206] contract_start: Represents the start date of the lease contract;

[0207] contract_end: Represents the end date of the lease contract;

[0208] transfer_value: Represents the value when the house is transferred; It should be noted that deposit is marked as a symbolic constant.

[0209] AXIOMS: Here we define a series of axioms that determine the data types of each constant and specific relationships. For example, landlord and tenant should belong to the "PARTIES" set; house, rent, deposit, contract_start, contract_end, and transfer_value should all be natural numbers; and the contract start date contract_start should be less than or equal to the contract end date contract_end.

[0210] The sets, constants, and axioms defined above constitute the basic structure of the lease environment, providing constraints and a basis for subsequent behavioral models.

[0211] Machine:

[0212] 1. Terms of Service: According to the description of the terms of service, an initial model is provided, which is defined in a formal method based on Event - B. This model establishes a basic logical framework for our lease contract system and defines a set of important state variables and their initial values.

[0213] This model has four key state variables: deposit_paid, rent_paid, house_transferred, and last_payment_date.

[0214] deposit_paid is a boolean variable indicating whether the tenant has paid the deposit. If the deposit has been paid, its value is true; otherwise, its value is false. At system initialization, this value is defaulted to false, indicating that the tenant has not paid the deposit.

[0215] rent_paid is another boolean variable indicating whether the tenant has paid the rent. Similar to deposit_paid, its initial value is also set to false, indicating that no rent payment has been made.

[0216] house_transferred is the third boolean variable indicating whether the ownership of the house has been transferred to the tenant. When the house ownership is successfully transferred, this value is true; otherwise, this value is false. At system initialization, this value is also false, indicating that the house ownership has not been transferred.

[0217] last_payment_date is a natural number (N) representing the date of the last payment. At system initialization, it is set to 0, indicating that no payment has been made yet.

[0218] The definitions and initializations of these state variables provide the basis for subsequent development of more complex functions such as payment processing and house transfer. Additionally, this model also adopts some core concepts of the Event-B method, such as variables, events, and invariants, which enables the behavior of the system to be precisely defined and understood.

[0219] Breach terms: According to the description of the breach terms, create an initial Event-B model "BreachTerms". In this model, define and initialize the four relevant state variables: deposit_paid, rent_paid, house_transferred, and last_payment_date.

[0220] We define an INITIALISATION event that runs at the start of the model's life cycle and is responsible for setting the initial values of all state variables. In this event, we set the initial values of deposit_paid and house_transferred to FALSE, indicating that the deposit has not been paid and the house has not been transferred at the time of initialisation. At the same time, we set the initial values of rent_paid and last_payment_date to 0, indicating that no rent has been paid and no rent payment date has occurred at the time of initialisation.

[0221] Termination clause: According to the description of the termination clause, the variable deposit_paid represents whether the lessee has paid the deposit, and its value can be TRUE (paid) or FALSE (not paid). The variable rent_paid represents whether the lessee has paid the rent, and its value can be TRUE (paid) or FALSE (not paid). The variable house_transferred represents whether the right to use the house has been transferred to the lessee, and its value can be TRUE (transferred) or FALSE (not transferred). Finally, the variable last_payment_date represents the lessee's last payment date, and its value is a natural number.

[0222] Specific model:

[0223] The specific model is further refined and developed based on the initial model according to the actual situation. SETS, CONSTANTS, and AXIOMS carriers are introduced in the context of the model. The following is the process of refining three different parts of the contract according to the actual situation.

[0224] In the ServiceTerms event of the service terms, the defined ServiceTerms model references all key elements defined in RentingContext2. This model adds three state variables on the basis of the initial model: deposit_paid, service_transferred, and last_service_date. The types of these variables are boolean and natural number respectively, and are declared in the invariant part of the model.

[0225] Specifically, the variable deposit_paid represents whether the lessee has paid the deposit, and its value can be TRUE (paid) or FALSE (not paid). The variable service_transferred represents whether the service has been transferred to the lessee, and its value can be TRUE (transferred) or FALSE (not transferred). Finally, the variable last_service_date represents the lessee's last service receipt date, and its value is a natural number.

[0226] The initialization event in the model sets all state variables to their corresponding initial values. That is, the lessee has not paid the deposit at the start, the service has not been transferred to the lessee, and the last service reception date is 0.

[0227] In this model, we define two cases of service default: one is that the service has not been delivered, and the other is that the lessee has not paid the deposit after the service has been delivered. Each default case has corresponding conditions (grd) and actions (act) to be executed. This formal description method can ensure that the service terms in the contract can be correctly executed whenever a default occurs.

[0228] 2. In BreachTerms, the breach clause model of the housing lease contract is refined. This more in-depth model, named BreachTerms, uses the formal language of Event-B and introduces new operations on the basis of the initial model to depict the default scenarios.

[0229] The BreachTerms model inherits the context defined in RentingContext2 and further introduces four state variables: deposit_paid, rent_paid, house_transferred, and last_payment_date. The data types of these variables include boolean and natural numbers, and their value ranges are defined in the invariant part of the model.

[0230] In this model, we define two cases of default: one is that the house has not been delivered, and the other is that it is more than 30 days but not more than 60 days since the last payment. Both of these default cases are defined by their guards (grd), and when the conditions are met, the corresponding actions (act) will be executed. This formal method can ensure that all breach clauses can be correctly executed when a default occurs, ensuring the fairness and impartiality of the housing lease contract.

[0231] 3. In TerminationTerms, the model inherits the context defined in RentingContext2 and further introduces four state variables: deposit_paid, rent_paid, house_transferred, and last_payment_date. The data types of these variables include boolean and natural numbers, and their value ranges are defined in the invariant part of the model.

[0232] Specifically, deposit_paid indicates whether the rental deposit has been paid. Its value being TRUE means it has been paid, and FALSE means it has not been paid; rent_paid represents the amount of rent paid, and its value is a natural number; house_transferred indicates whether the house has been delivered to the lessee. Its value being TRUE means it has been delivered, and FALSE means it has not been delivered; finally, last_payment_date represents the date of the last payment, and its value is a natural number.

[0233] In this model, we define three situations for contract termination: one is the expiration of the contract, the second is that the house is not delivered within the specified time, and the third is overdue payment. These contract termination situations are all defined through their guards (grd). When the conditions of the guards are met, the corresponding actions (act) will be executed.

[0234] The model created through the Rodin platform generates a total of 3 proof obligations, and all proof obligations are automatically proven by the built-in prover of the platform. Among them, the Total label represents the total number of proof obligations generated, and the Auto label represents the number of proof obligations automatically proven by the Rodin platform.

[0235] In the embodiments of the present invention, Event-B is adopted as the method for logical consistency verification. First, Event-B supports establishing models through refinement steps from abstraction to concreteness, which can ensure that the DSL file accurately reflects the consistency of the actual requirements of legal contracts; second, Event-B is based on set theory and has powerful logical expression capabilities, and can perform calculations on the Rodin development platform. The Rodin platform integrates model detection and interactive theorem proving functions, greatly improving the effectiveness and reliability of formal verification and automatic generation of smart contracts. Specifically, the Event-B logic verification steps based on the model-driven are as follows:

[0236] 1. Stage of defining state variables: The model declaration under the Event-B framework needs to first clarify each state variable.

[0237] 2. Stage of defining events: Based on propositional logic and predicate logic, cover the preconditions, post-conditions, and specific behavioral manifestations of each event.

[0238] 3. Stage of constructing relationships between events: Utilize constraint conditions and dependencies between events to establish the execution order and triggering logic between different events. Write proof obligations according to the terms in the contract and predefine the relationships in the Machine.

[0239] 4. Stage of verifying system properties: Utilize the refinement process of the formal model to perform the next verification task.

[0240] If the verification passes, the code mapping of DSL-Solidity is further implemented. If the verification fails, it indicates that there may be logical inconsistencies and feedback is provided to the DSL programmers for file modification. In the definition phase and the phase of constructing event relationships, the present invention stipulates a transformation (Tr) function for the mapping between SLL and Event-B. This function can transform the Event-B model based on the SLL syntax, clearly interpret the SLL logic, and retain the original semantic information.

[0241] (1) Tr1: In the SLL code, type declarations are transformed into sets and rules in the Context. If data formats such as unsigned integers are used in SLL, we will construct a set in Event-B. For example, in the context of a lease contract, we define product information and store it by creating a "Product" set. During the refinement process from C0 (initial context) to Cn (refined context), we create a "product_XXX" invariant to represent all information related to the house. Here, based on the BNF paradigm of unsigned integers, we define the rules for mapping to sets and further clarify the rules for mapping to the Context in Event-B. The correspondence between the SLL content and the Context in Event-B is clearly defined.

[0242] (2) Tr2: Attribute declarations are transformed into variables and invariants of the Machine in Event-B. In the Context, basic specific attributes described by DSL may be required, such as status, currency, involved parties, etc., which are abstract descriptions of house characteristics. In this part, Tr2 is used to map the attributes to the "variables" and "invariants" of Event-B in the present invention.

[0243] For example, a product has a status attribute called product_status, whose type is a string. The possible values in the prop keyword include "vacant", "leased", etc. When mapping it to the Event-B model, the corresponding variable is created, and an invariant is defined to restrict or describe the meaning and possible states of this variable. The mapping result is as follows: The rules for syntax mapping are defined as follows:

[0244] <DSL_model>::=<attribute_section>

[0245] <attribute_section>::="Attributes"<attribute_definitions>

[0246] <attribute_definitions> ::= <attribute_definition> | <attribute_definition><attribute_definitions>

[0247] <attribute_definition> ::= <name> ":" <type>"mapped to"<eventb_attribute>

[0248] <type>::= / * Data types supported by DSL, such as "integer", "string", etc. * /

[0249] <eventb_attribute>::= "Variable" <var_definition> "Invariant" <invariant_definition>

[0250] <var_definition>::= <name>

[0251] <invariant_definition>::= <name>"represents" <description>

[0252] <name>::= / * Valid identifier * /

[0253] <description>::= / Statement describing invariant, e.g., "product_status_XXX represents the current status of the house" * /

[0254] (3) Tr3: Function declarations are converted into events, initializations, etc. of the abstract machine Machine in Event-B. Suppose in the DSL, we have the following function description:

[0255] event rentProductEvent

[0256] guard guard_rent: product_status = "Vacant"

[0257] action act_rent: product_status := "Rented"

[0258] Taking the lease contract as an example here, the purpose of rent guard_rent is to ensure that the product can only be rented when it is in the "vacant" state. Once the guard condition is met, the action of "act_rent" will be activated, resulting in the product status changing to the "rented" state.

[0259] Through the grammar mapping described using the extended BNF paradigm (i.e., EBNF), the function definitions in the DSL can be directly converted into events in the Event-B model, thus realizing the conversion between DSL descriptions and formal models. Through such a conversion, SLL can not only formally define all aspects of the smart contract but also ensure its logical and legal validity in practical applications.

[0260] After obtaining the domain-specific DSL verified by real-world logic, Solidity contracts are automatically generated through mapping. The SLL domain model definitions (such as roles, assets) are conceptually equivalent to the instantiation of structs in Solidity, and the event types in SLL are mapped to the corresponding conceptually equivalent counterparts in Solidity. The events included in SLL are mapped to functions in Solidity, and external information can enter Solidity through interaction (passing data to functions). Regarding the constraint conditions in clause construction, these are corresponding in the individual function modifiers added to the clause functions, including declarative checks that prevent improper execution in advance. The overall mapping relationship is shown in the table.

[0261] Table 2 Code mapping from SLL to Solidity

[0262] SLL construction Solidity construction Role Struct instance instantiation Asset Struct instance instantiation Event Function Clause constraint Function modifier

[0263] In the implementation of the Xtext architecture, Xtend is used to implement the logic for converting DSL constructs into Solidity code, and its template expressions and advanced control structures are utilized to write concise and readable code conversion logic. After the user writes the DSL file (with the suffix.sll), Xtext forms the basic structure of the language and uses the AST,

[0264] a meta-model in the form of Ecore. Once the SLL text input file is processed, the parser creates an in-memory instance of the meta-model, called the Abstract Syntax Tree (AST). Then, the generator written in Xtend traverses this AST to generate Solidity code that depends on static and dynamic support libraries. These libraries contain the implementation methods of operations in SLL types and the development environment of smart contracts, etc.

[0265] To comprehensively verify the practicality and flexibility of the SLL language, the present invention fully applies the previously defined SLL syntax specification and selects the "prepayment contract" as an experimental case. Since the prepayment contract has relatively high requirements for the execution of time and events, has strong logic, and the content of the contract is not likely to be greatly modified according to the actual situation, the prepayment contract is used as the experimental processing object here. The keywords of the prepayment contract are extracted and abstractly represented, and then the basic information definition, service term definition, and default term definition are carried out respectively, as follows:

[0266] Basic information definition: The basic elements of the prepayment contract, including the identities of the parties involved and relevant transaction details, are defined in the basic information model of SLL. This contract allows external input of basic information by the contract parties to ensure that all major details are captured according to the overview in the basic information section.

[0267] Service term definition: SLL carefully divides the service terms, including the initial payment, service delivery, and continuous payment obligations, thus establishing a clear contract framework. First is the definition of the service terms, and then the canonical form of rules is used to express the rights and obligations:

[0268] Expression of rights and obligations in rule specification

[0269] Default term definition: In response to possible failures in service delivery or payment, the default terms are clearly stated, and SLL provides a default management mechanism.

[0270] Termination term definition: The termination term in the contract is defined as specifying the conditions under which the contract may be terminated, thus highlighting the life cycle of the contract.

[0271] It can be seen that the SLL terms have a powerful and concise ability in expressing contract terms including service terms, default terms, and termination terms.

[0272] In the present specification, the various embodiments are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description in the method section.

[0273] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.< / description> < / name> < / description> < / name> < / name> < / type> < / type> < / name> < / description> < / type> < / name> < / description> < / name> < / description> < / name> < / name> < / type> < / name> < / parameter> < / parameters> < / parameter> < / parameter> < / parameters> < / parameter> < / name> < / description> < / name> < / description> < / name> < / name> < / type> < / type> < / name> < / description> < / name> < / description> < / name> < / name> < / name> < / name>

Claims

1. A method for constructing and executing a smart legal contract based on a domain-specific language, comprising the following steps: 1) Write a smart legal contract based on the contract logic, formalize the legal provisions in the legal contract based on the SLL language, and generate the Event-B basic model of the smart legal contract. The Event-B basic model includes a context Context and an abstract machine Machine. The context Context is used to define static scenes and constants in the legal contract, and the abstract machine Machine is used to define state variables and initial values ​​during the execution of the legal contract; 2) Convert the Event-B basic model into executable Solidity code using the target language conversion mapping rules; 3) After verifying the Solidity code, it is published on the blockchain to realize the deployment of smart legal contracts; 4) When the contract terms of the smart legal contract are triggered, the smart legal contract is automatically executed in the blockchain, and the execution results are stored in the blockchain in a set form.

2. The method for constructing and executing a smart legal contract based on a domain-specific language according to claim 1, characterized in that: Step 1) also includes classifying the Event-B basic model according to different proof burden rules, and the classification results specifically include: INV model: The INV model is used to verify the unchanged transactions in the smart legal contract, including the contract party information and asset attribute information; FIS model: The FIS model is used to verify the possibility of non-deterministic actions in smart legal contracts, including breach conditions and changes in the properties of the contract entity after the penalty measures are triggered; SIM model: The SIM model is used to verify whether the simultaneous execution of multiple events in a smart legal contract produces conflicts in related attributes.

3. The method for constructing and executing a smart legal contract based on a domain-specific language according to claim 1, characterized in that: In step 1), the clauses in the legal contract are formally represented according to the SLL language to generate the Event-B basic model of the smart legal contract, which includes: The legal ontology concepts in legal texts are extracted using the ontology model based on the legal core; Use SLL language to define sets, constants and axioms in legal ontology concepts; The set includes: entities involved in legal acts, including Party A, Party B, assets and intermediary institutions; The constants include: the entity constants involved in the legal act, and the duration constants of the legal act; The axioms are used to define the data types and data relationships of various constants; The Backus BNF is used to transform the sets, constants and axioms defined in the SLL language into the Event-B basic model.

4. The method for constructing and executing a smart legal contract based on a domain-specific language according to claim 1, characterized in that: The state variables in the execution process of the legal contract described in step 1) include service terms, breach of contract terms and termination terms; Types of service breaches defined in the said Terms of Service include failure to deliver services and failure to pay a deposit after services have been delivered; The types of contract default defined in the said default clause include the house not being delivered and the last payment being made more than 30 days but not more than 60 days; The types of contract termination defined in the termination clause include contract expiration, property not delivered within the specified time, and overdue payment.

5. The method for constructing and executing a smart legal contract based on a domain-specific language according to claim 1, characterized in that: The target language conversion mapping rules in step 2) specifically include: Map the sentence functions in the SLL language to the equivalent functions in Solidity code; Map the context Context and abstract machine Machine defined in the SLL language to the hierarchy of Solidity code.

6. A smart legal contract construction and execution system based on a domain-specific language, characterized in that: Including basic model building module, executable code conversion module, smart legal contract deployment module and smart legal contract operation module; The basic model building module is used to formally represent the legal provisions in the legal contract according to the SLL language, and generate the Event-B basic model of the smart legal contract. The Event-B basic model includes a context Context and an abstract machine Machine. The context Context is used to define static scenes and constants in the legal contract, and the abstract machine Machine is used to define state variables and initial values ​​during the execution of the legal contract. The executable code conversion module is used to convert the Event-B basic model into executable Solidity code by using the target language conversion mapping rule; The smart legal contract deployment module is used to publish and deploy the Solidity code on the blockchain after verification; The smart legal contract running module is used to automatically run the smart legal contract in the blockchain when the contract terms of the smart legal contract are triggered, and store the running results in the blockchain in a set form.

7. The domain-specific language-based intelligent legal contract construction and execution system according to claim 6, characterized in that: The system further includes a basic model classification module, which is used to classify the Event-B basic model according to different proof obligation rules, and the classification results specifically include: INV model: The INV model is used to verify the unchanged transactions in the smart legal contract, including the contract party information and asset attribute information; FIS model: The FIS model is used to verify the possibility of non-deterministic actions in smart legal contracts, including breach conditions and changes in the properties of the contract entity after the penalty measures are triggered; SIM model: The SIM model is used to verify whether the simultaneous execution of multiple events in a smart legal contract produces conflicts in related attributes.

8. The domain-specific language-based intelligent legal contract construction and execution system according to claim 6, characterized in that: In the basic model building module, the clauses in the legal contract are formally represented according to the SLL language, specifically including extracting the legal ontology concepts in the legal text using the ontology model based on the legal core; Use SLL language to define sets, constants and axioms in legal ontology concepts; The set includes: entities involved in legal acts, including Party A, Party B, assets and intermediary institutions; The constants include: the entity constants involved in the legal act, and the duration constants of the legal act; The axioms are used to define the data types and data relationships of various constants; The Backus BNF is used to transform the sets, constants and axioms defined in the SLL language into the Event-B basic model.

9. The domain-specific language-based intelligent legal contract construction and execution system according to claim 6, characterized in that: In the basic model building module, the abstract machine Machine is used to define the state variables in the execution process of the legal contract, specifically including: Terms of Service, Breach of Contract and Termination, Types of service breaches defined in the said Terms of Service include failure to deliver services and failure to pay a deposit after services have been delivered; The types of contract default defined in the said default clause include the house not being delivered and the last payment being made more than 30 days but not more than 60 days; The types of contract termination defined in the termination clause include contract expiration, property not delivered within the specified time, and overdue payment.

10. The domain-specific language-based intelligent legal contract construction and execution system according to claim 6, characterized in that: In the executable code conversion module, the target language conversion mapping rules for converting the Event-B basic model into executable Solidity code specifically include: Map the sentence functions in the SLL language to the equivalent functions in Solidity code; Map the context Context and abstract machine Machine defined in the SLL language to the hierarchy of Solidity code.

Images