A method for detecting regulatory contract rule conflicts

Abstract

The application provides a kind of supervisory contract rule conflict detection method, it is related to blockchain technology field.The present application takes the supervisory contract code as input, the supervisory rules in supervisory contract are symbolized, and the supervisory rule conflict problem is converted into constraint solving problem using symbol analysis technology, theorem proving is carried out through SMT solver, and each type of conflict in supervisory rule is found, or it is proved that supervisory rule has no conflict.Specifically, it includes type analysis stage, supervisory rule symbolization stage and conflict detection stage.The present application can detect self-conflict, complete conflict, partial conflict and other rule conflict problems of supervisory contract in blockchain financial application, and provides effectiveness guarantee for realizing digitalization of supervisory rules.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method for detecting conflicts in regulatory contract rules. Background Technology

[0002] With its characteristics of multi-party sharing, immutability, transparency, and trustworthiness, blockchain technology is being increasingly widely applied in the financial sector, becoming an emerging financial information infrastructure. As a shared data record repository between regulators and regulated entities, blockchain provides a new paradigm for interaction between business logic and regulatory rules, and offers an effective way to digitize business logic and regulatory rules through smart contracts. On the one hand, financial institutions can implement flexible business logic by writing smart contracts; on the other hand, regulatory agencies can also use smart contracts to digitize regulatory rules, achieving real-time, transparent supervision of financial business contract transactions.

[0003] Regulatory contracts are smart contracts on the blockchain, primarily functioning to constrain ordinary business contracts according to digital regulatory rules. In practical applications, the frequent rule conflicts in the financial regulatory field pose new challenges to the digitization of regulatory rules. At the level of authority source, conflicts in financial regulatory rules mainly manifest as conflicts in the application of law, specifically conflicts between macro-level and industry-level regulations, and conflicts between "multi-track" regulations from different regulatory departments. Furthermore, programming errors during the drafting of regulatory contracts can also cause rule conflicts. Newly added regulatory contracts may not only have their own rule conflicts but may also conflict with other deployed regulatory contracts. Because regulatory rules are mandatory and prohibitive, regulatory contracts have a significant impact on the operation of business contracts after deployment. Rule conflicts in regulatory contracts not only increase the compliance costs for practitioners but also challenge the effectiveness of regulation. Therefore, conflict detection of regulatory rules before the deployment of regulatory contracts is of great significance. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method for detecting conflicts in regulatory contract rules. The method takes the regulatory contract code as input, symbolizes the regulatory rules within the contract, and uses symbolic analysis techniques to transform the regulatory rule conflict problem into a constraint-solving problem. It then uses an SMT solver to perform theorem proofs, identifying various types of conflicts in the regulatory rules or proving that the regulatory rules are conflict-free.

[0005] A method for detecting conflicts in regulatory contract rules, specifically including the following steps:

[0006] Step 1: Type Analysis Phase: Inferring the types of all variables in the regulatory contract;

[0007] The type analysis phase specifically involves taking the abstract syntax tree of the regulatory contract as input and generating a variable type table through variable type dependency analysis and variable type propagation analysis. Specifically, variable type dependency analysis constructs a variable type dependency graph by analyzing the regulatory contract code and adds type constraints to the variable type dependency graph based on known information.

[0008] Variable type dependency analysis traverses the abstract syntax tree of the regulatory contract code in a top-down manner, extracts all variables, and constructs a variable type dependency graph based on the constraints between variables. Nodes in the variable type dependency graph represent variables in the regulatory contract, and edges represent dependencies between the types of two variables. Variable type dependency analysis adds two types of constraints to the dependency graph using variable and operator information from the abstract syntax tree: type constraints and relational constraints. Type constraints constrain the attributes of nodes in the variable type dependency graph, i.e., the possible types of variables in the dependency graph. Relational constraints constrain the type relationships between two variables, specifically whether the types of two variables or elements within variables in the dependency graph are compatible, i.e., whether they are of the same type or can be automatically converted to the same type.

[0009] The variable type propagation analysis uses a dependency graph-based type propagation algorithm to infer the type of variables with undetermined types. The type propagation algorithm first constructs a variable type table to record the type of all variables. Then, starting from variables with determined types, it infers the type of the variable's neighboring nodes based on the type constraints and relational constraints in the variable type dependency graph, and propagates the type update until the variable type table no longer changes.

[0010] Step 2: Regulatory rule symbolization stage: Based on the variable types in the variable type table, symbolize the variables and statements respectively to generate symbolized regulatory rules;

[0011] The symbolization process first extracts the statement subtree of each regulatory rule from the regulatory contract abstract syntax tree, then traverses each subtree in a top-down manner, replacing all variables in the statement with symbols, and converting each statement into a logical expression based on the semantic information of operators and built-in functions.

[0012] Step 3: Conflict Detection Phase: Conflict detection is performed on the symbolic regulatory rules from Step 2.

[0013] In the conflict detection, regulatory rule conflicts are classified into three categories—self-conflict, partial conflict, and complete conflict—based on the regulatory rules involved in the regulatory conflict and the scope of the regulatory conflict's impact.

[0014] The self-conflict is defined as compliance with regulatory rules. Scope any state None of them meet the requirements of the regulatory rules. ,or or It is itself a contradiction, defined as follows:

[0015] (1);

[0016] In the formula, S represents all possible values ​​of all variables in the regulatory scope statement;

[0017] The complete conflict refers to the conflict between two regulatory rules. R is the set of regulatory rules involved in the detection. If there exists a state that simultaneously conforms to two regulatory rules, then R represents the state within the scope of the detection. However, any one Neither can simultaneously meet the requirements of two regulatory rules, as defined below:

[0018] (2);

[0019] If formula (3) holds true, then it proves that formula (2) must not hold true. In this case, it proves that the two regulatory rules are not completely conflicting.

[0020] (3);

[0021] The local conflict occurs when two regulatory rules have the same or similar regulatory scope, but some states only meet the requirements of one of the regulations, during verification. and Based on the relevant information, the following definitions are made:

[0022] (4);

[0023] For multiple regulatory rules The complete conflict of these regulatory rules is defined as follows:

[0024] (5);

[0025] If formula (6) holds, then it proves that formula (5) must not hold. In this case, it proves that these n regulatory rules are not completely conflicting, and it can ensure that any m of them are not completely conflicting.

[0026] (6);

[0027] Regarding local conflicts, if there are local conflicts among n regulatory rules, then there must be two regulatory rules that are in local conflict. That is, the existence of two regulatory rules in local conflict is a necessary condition for the existence of local conflicts among n regulatory rules.

[0028] Step 3.1: Self-collision detection;

[0029] Self-conflict detection requires the SMT solver to calculate whether each symbolic regulatory rule is satisfiable, i.e., to determine whether the regulatory rule is self-conflicting. The SMT solver has the following four calculation results:

[0030] (1) Sat: This result shows that all constraints can be satisfied at the same time. At this time, the SMT solver will give a solution that satisfies the constraints; it proves that the regulatory rules are not self-conflicting and can give a business contract transaction within the scope of regulation so that it meets all regulatory requirements.

[0031] (2) unsat: This result shows that the SMT solver can prove that all constraints cannot be satisfied at the same time, proving that for any business contract transaction within the regulatory scope, the regulatory requirements cannot be satisfied. According to formula (1), the regulatory rules are self-conflicting.

[0032] (3) unknown: This result indicates that the SMT solver cannot determine whether the constraints can be satisfied;

[0033] (4) timeout: Set the timeout when using the SMT solver. When the SMT solver runs for longer than the set timeout, it will return timeout.

[0034] Step 3.2: Complete collision detection;

[0035] Performing full conflict detection on a set of n regulatory rules presents three possible scenarios:

[0036] (1) These n regulatory rules are completely conflicting, which can be proven using formula (5);

[0037] (2) These n regulatory rules are not completely conflicting. The conflict detection method should be able to provide a solution to formula (6) and ensure that any subset of the set of incompletely conflicting regulatory rules is not completely conflicting.

[0038] (3) The regulatory scope of these n regulatory rules cannot be satisfied simultaneously, that is... At this point, it cannot be proven that the subsets of these n regulatory rule sets are completely conflicting, nor can it be proven that any subset of them is not completely conflicting. Therefore, conflict analysis needs to be performed on different subsets of the regulatory rule sets separately.

[0039] Step 3.3: Local conflict detection;

[0040] Since the existence of partial conflicts between two regulatory rules is a necessary condition for the existence of partial conflicts among n regulatory rules, it is only necessary to perform conflict detection on the pairwise combinations of regulatory rules.

[0041] The beneficial effects of adopting the above technical solution are as follows:

[0042] This invention provides a method for detecting regulatory contract rule conflicts, which can detect rule conflicts such as self-conflict, complete conflict, and partial conflict in regulatory contracts in blockchain financial applications, providing effective assurance for the digitalization of regulatory rules. Attached Figure Description

[0043] Figure 1 This is a flowchart of the regulatory rule conflict detection method of the present invention;

[0044] Figure 2 This is a diagram showing the type constraints and relationship constraints of the operands in this invention;

[0045] Figure 3 This is a diagram of the variable type propagation algorithm of the present invention;

[0046] Figure 4 This is a mapping diagram showing the relationship between the regulatory contract variable type and the Z3 symbol type in this invention;

[0047] Figure 5 This is a flowchart of the regulatory rule complete conflict detection process of the present invention;

[0048] Figure 6 This is a diagram of the algorithm for partitioning the regulatory rules subset according to the present invention.

[0049] Figure 7 An example diagram of a regulatory contract written in RegLang, provided for embodiments of the present invention;

[0050] Figure 8 Example diagram of regulatory contract variable type analysis provided for embodiments of the present invention;

[0051] Figure 9 An example diagram of symbolic representation of regulatory contract variables provided for embodiments of the present invention;

[0052] Figure 10 An example diagram illustrating the symbolic representation of regulatory contract rules provided for embodiments of the present invention. Detailed Implementation

[0053] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0054] A method for detecting conflicts in regulatory contract rules, such as Figure 1 As shown, the specific steps include:

[0055] Step 1: Type Analysis Phase: Infer the types of all variables in the regulatory contract in order to more accurately symbolize them;

[0056] The type analysis phase specifically involves using the abstract syntax tree of the regulatory contract as input to generate a variable type table through variable type dependency analysis and variable type propagation analysis. Variable type dependency analysis constructs a variable type dependency graph by analyzing the regulatory contract code and adds type constraints to the graph based on known information. The type propagation algorithm, based on the dependency graph, analyzes variables whose types were not determined in the first phase using these type constraints, thereby improving the accuracy of the variable type analysis.

[0057] Variable type dependency analysis employs a top-down approach, traversing the abstract syntax tree (AST) of the regulatory contract code to extract all variables. A variable type dependency graph is constructed based on the constraints between variables. Nodes in the graph represent variables within the regulatory contract, including knowledge-related, transaction-related, and contract-related variables. Transaction-related variables, used to read transaction data from business contracts, are represented in RegLang as follows: `tx.from`, `tx.to`, `tx.function`, `tx.args.var`, `tx.readset(addr).var`, and `tx.readset(addr).var`, corresponding to the sender, receiver, calling function, calling parameters, read set, and write set of the business contract transaction, respectively. Contract-related variables, used to read business contract data, are represented in RegLang as follows: `contract(addr).name`, `contract(addr).owner`, and `contract(addr).state.var`, corresponding to the name, owner, and ledger state of the business contract, respectively. Edges indicate a type dependency between two variables. Variable type dependency analysis utilizes the abstract syntax tree (AST). In a Tree (AST), variable and operator information is used to add two types of constraints to the dependency graph: type constraints and relational constraints. Figure 2 As shown. Type constraints are constraints on the node attributes in the variable type dependency graph, that is, the possible types of variables in the dependency graph; relation constraints are constraints on the type relationship between two variables, specifically whether the types of two variables or elements in the variable in the dependency graph are compatible, that is, whether they are the same type or can be automatically converted to the same type.

[0058] Variable type dependency analysis can generate a variable type dependency graph for regulatory contracts and infer the exact types of some variables. The variable type propagation analysis uses a type propagation algorithm based on the dependency graph to infer the types of variables with undetermined identities. The specific process is as follows: Figure 3As shown, the type propagation algorithm first constructs a variable type table to record the types of all variables (line 1). Then, starting with variables whose types are known (lines 2-4), it infers the types of neighboring nodes of the variable based on the type constraints and relational constraints in the variable type dependency graph, and propagates the type updates (lines 5-7) until the variable type table no longer changes (lines 8-9). The algorithm can narrow down the possible types of variables with unknown types based on known variable types and constraints, and thus infer their accurate types. Because the type propagation algorithm records the nodes visited in each round of updates, nodes will not be revisited if their types have not changed (line 5). Therefore, even if the variable type dependency graph is a cyclic graph, the algorithm can still terminate.

[0059] Step 2: Regulatory rule symbolization stage: Based on the variable types in the variable type table, symbolize the variables and statements respectively to generate symbolized regulatory rules;

[0060] The purpose of symbolizing regulatory rules is to convert the variables and statements in the regulatory contract into symbols and logic that can be processed by the SMT solver, so as to transform the regulatory rule conflict problem into a satisfiability problem and solve the constraints through the SMT solver. Z3 is an open-source SMT solver. The following section uses Z3's data structures and functions as targets to introduce the symbolization method for variables and statements in regulatory rules. After the type analysis phase, the regulatory rule conflict detection method can obtain all variables and their types in the regulatory contract. Next, all variables need to be symbolized according to their types. The mapping relationship between the regulatory contract variable types and Z3 symbol types is as follows: Figure 4 As shown.

[0061] The symbolization process first extracts the statement subtree of each regulatory rule from the regulatory contract abstract syntax tree, then traverses each subtree in a top-down manner, replacing all variables in the statement with symbols, and converting each statement into a logical expression based on the semantic information of operators and built-in functions.

[0062] Step 3: Conflict Detection Phase: Conflict detection is performed on the symbolic regulatory rules from Step 2.

[0063] In the conflict detection, regulatory rule conflicts are classified into three categories—self-conflict, partial conflict, and complete conflict—based on the regulatory rules involved in the regulatory conflict and the scope of the regulatory conflict's impact.

[0064] The self-conflict is defined as compliance with regulatory rules. Scope any state None of them meet the requirements of the regulatory rules. ,or or It is itself a contradiction, defined as follows:

[0065] (1);

[0066] In the formula, S represents all possible values ​​of all variables in the regulatory scope statement;

[0067] The complete conflict refers to the conflict between two regulatory rules. R is the set of regulatory rules involved in the detection. If there exists a state that simultaneously conforms to two regulatory rules, then R represents the state within the scope of the detection. However, any one Neither can simultaneously meet the requirements of two regulatory rules, as defined below:

[0068] (2);

[0069] If formula (3) holds true, then it proves that formula (2) must not hold true. In this case, it proves that the two regulatory rules are not completely conflicting.

[0070] (3);

[0071] The aforementioned partial conflict occurs when two regulatory rules have the same or similar regulatory scope, but certain states only meet the requirements of one of the rules. This is the most common rule conflict in the field of financial regulation. (In verification...) and Based on the relevant information, the following definitions are made:

[0072] (4);

[0073] For multiple regulatory rules The complete conflict of these regulatory rules is similar to the complete conflict of two rules (Formula (2)), and is defined as follows:

[0074] (5);

[0075] If formula (6) holds, then it proves that formula (5) must not hold. In this case, it proves that these n regulatory rules are not completely conflicting, and it can ensure that any m of them are not completely conflicting.

[0076] (6);

[0077] Regarding local conflicts, if there are local conflicts among n regulatory rules, then there must be two regulatory rules that are in local conflict. That is, the existence of two regulatory rules in local conflict is a necessary condition for the existence of local conflicts among n regulatory rules.

[0078] Based on the formal definition of regulatory rule conflicts, conflict detection for regulatory contracts can be specifically described as the following issues:

[0079] (1) If it can be proven that the regulatory requirements cannot be met for any business contract transaction within the scope of regulation, then the regulatory rule is self-conflicting (Formula (1)).

[0080] (2) If a business contract transaction and knowledge base setting can be found such that the regulatory scope and regulatory requirements of a set of regulatory rules can be met, then these regulatory rules are not completely conflicting with each other, and the regulatory rule conflict detection method should be able to provide such input (Formula (3) and Formula (6)).

[0081] (3) If (2) is not satisfied, the following test shall be performed: If a business contract transaction can be found to be within the scope of a set of regulatory rules at the same time, but no transaction can simultaneously meet the regulatory requirements of these regulatory rules, then these regulatory rules are in complete conflict (Formula (2) and Formula (5)).

[0082] (4) A method for calculating the correlation of the regulatory scope of two regulatory rules can be defined based on the semantic information of the regulatory scope or the variables involved. If the regulatory scope of two regulatory rules is related, and a business contract transaction and knowledge base setting can be found such that only one of the regulatory requirements of the two regulatory rules is satisfied, then the two regulatory rules are in partial conflict, and the regulatory rule conflict detection method should be able to provide such input. Since the partial conflict of two rules is a necessary condition for the partial conflict of multiple rules, it is not necessary to detect the partial conflict of multiple rules (Formula (4)).

[0083] Step 3.1: Self-collision detection;

[0084] Self-conflict detection requires the SMT solver to calculate whether each symbolic regulatory rule is satisfiable, i.e., to determine whether the regulatory rule is self-conflicting. The SMT solver has the following four calculation results:

[0085] (1) Sat. This result shows that all constraints can be satisfied simultaneously, and the SMT solver will give a solution that satisfies the constraints; it proves that the regulatory rules are not self-conflicting and can give a business contract transaction within the scope of regulation, so that it meets all regulatory requirements;

[0086] (2) unsat. This result shows that the SMT solver can prove that all constraints cannot be satisfied at the same time, proving that for any business contract transaction within the regulatory scope, the regulatory requirements cannot be satisfied. According to formula (1), the regulatory rules are self-conflicting.

[0087] (3) Unknown. This result indicates that the SMT solver cannot determine whether the constraint can be satisfied. This is usually because the constraint is nonlinear, for example... , where x is a symbol, and the SMT solver cannot complete the solution in a finite amount of time.

[0088] (4) timeout. Since the SMT solver may take a long time to solve complex constraints, a timeout is set when using the SMT solver. When the SMT solver runs for longer than the set timeout, it will return timeout.

[0089] Nonlinear calculations are less frequent in regulatory rules, and the complexity of constraints is relatively low. Therefore, "unknown" or "timeout" errors are rare, and accurate self-conflict detection results can be given for the vast majority of regulatory rules.

[0090] Step 3.2: Complete collision detection;

[0091] Performing full conflict detection on a set of n regulatory rules presents three possible scenarios:

[0092] (1) These n regulatory rules are completely conflicting, which can be proven using formula (5);

[0093] (2) These n regulatory rules are not completely conflicting. The conflict detection method should be able to provide a solution to formula (6) and ensure that any subset of the set of incompletely conflicting regulatory rules is not completely conflicting.

[0094] (3) The regulatory scope of these n regulatory rules cannot be satisfied simultaneously, that is... At this point, it cannot be proven that the subsets of these n regulatory rule sets are completely conflicting, nor can it be proven that any subset of them is not completely conflicting. Therefore, conflict analysis needs to be performed on different subsets of the regulatory rule sets separately.

[0095] Based on the above analysis, the process for performing complete conflict detection on regulatory rules in regulatory rule conflict detection methods is as follows: Figure 5 As shown. In the complete conflict detection of regulatory rules, whether the regulatory scope of the regulatory rules can be simultaneously satisfied is proven by proving the first clause of formula (5) through the SMT solver, and whether the regulatory rules are completely conflicting is proven by proving the second clause of formula (5) and formula (6) (these two formulas can be completed simultaneously during constraint solving). When the regulatory scope of all regulatory rules cannot be simultaneously satisfied, it is necessary to detect all subsets of the regulatory rule set, but since the number of subsets is This results in the algorithm's complexity being This approach is unacceptable in conflict detection; therefore, it is necessary to partition the regulatory rules into subsets to discover as many conflicts as possible within acceptable complexity. Specifically, the algorithm for partitioning the regulatory rules subsets is as follows: Figure 6 As shown, the algorithm uses a heuristic approach to divide regulatory rules into multiple subsets, ensuring that the regulatory scope of all rules in each subset can be simultaneously satisfied (line 4). After dividing the regulatory rules into subsets, the algorithm can detect whether the regulatory rules in each subset are completely conflicting, thus identifying regulatory rule conflicts.

[0096] Step 3.3: Local conflict detection;

[0097] Next, we consider performing local conflict detection on a set of n regulatory rules. According to the formal definition of regulatory rule conflict, since the existence of local conflict between two regulatory rules is a necessary condition for the existence of local conflict among n regulatory rules, we only need to perform conflict detection on pairwise combinations of regulatory rules.

[0098] In this embodiment, combined with Figure 7 The invention is illustrated by an example of a regulatory contract. Figure 7 This demonstrates a sample regulatory contract written in RegLang. The sample has a knowledge base called `crowdFunding`, which defines `blacklist` as the blacklist, `Max` as the maximum transfer amount, and `decUnits` as the precision. In the rules section, line 9 indicates the regulatory scope, meaning transactions calling the `Funding` function will be inspected. Line 10 is a mandatory rule, stating that the regulatory rules require transactions to use precision consistent with regulatory requirements. Line 11 is another mandatory rule, stating that the total transfer amount cannot exceed the maximum transfer amount required by the regulatory rules. Line 12 is a prohibitive rule, prohibiting donors from initiating fraudulent transfers to addresses they control, for anti-money laundering and other purposes. Line 13 is a prohibitive rule, stipulating that crowdfunding recipients cannot appear on the address blacklist, for combating terrorist financing and other purposes.

[0099] First of all Figure 7Type analysis is performed on the regulatory contract. The regulatory rule RegFunding involves eight different variables: the knowledge variables decUnits, Max, and blacklist from the knowledge base crowdFunding; the transaction-related variable tx.function; and the parameter variables from four tx.args. First, an abstract syntax tree (AST) of the regulatory contract is generated using the RegLang Parser, and a top-down variable type dependency analysis is performed. According to the definitions in the knowledge base, the types of the three knowledge variables involved in the regulatory rule are known: blacklist is a string array, and the other two are numeric. The transaction-related variable tx.function is of type string, a type that is consistent across all regulatory rules. Then, during the traversal of the abstract syntax tree, a variable type dependency graph is generated by adding type constraints and relational constraints to variables based on the operators and built-in functions in lines 10-14 of the regulatory contract, as shown below. Figure 8 The initial state is shown. Next, type propagation analysis will be performed based on the generated dependency graph. The algorithm will sequentially select variables with determined types and update the types of their neighboring nodes to satisfy type constraints and variable compatibility constraints. In the example, the algorithm will select the knowledge variable blacklist (step 1), then update the type of its neighboring node tx.args._receivers to String-Array according to the relation constraints (step 2), then update the type of tx.args._senders, the neighboring node of tx.args._receivers, to String-Array (step 3), and then select the knowledge variable decUnits and update the type of its neighboring node tx.args._decUnits to Number. The algorithm will terminate after determining the types of all variables. The symbol types corresponding to each variable in the regulatory rules are as follows: Figure 9 As shown.

[0100] Next Figure 7 Regulatory rules in regulatory contracts are symbolized. Arithmetic, comparison, and logical operators in regulatory rules can be directly mapped to their corresponding operators in Z3. Prohibitory statements in regulatory rules (starting with "prohibit") are mapped to negation operators. Membership operators and built-in functions are converted as follows:

[0101] (1) For membership operators of the form a in x, where x is an array and the length of the x array is set to len(x) during variable symbolization, a in x will be converted to .

[0102] (2) For the built-in function at_least(), which is of the form at_least(n, a in x), where a and x are arrays, and in variable symbolization, the lengths of the arrays a and x are set to len(a) and len(x) respectively. Then at_least(n, a in x) will be converted to: .

[0103] (3) For the built-in function at_most(), in the form at_most(n, a in x), where a and x are arrays, and in variable symbolization, the lengths of arrays a and x are set to len(a) and len(x) respectively. Then at_most(n, a in x) will be converted to at_least(n+1, a in x), where at_least(n, a in x) is as shown in (2).

[0104] (4) For the built-in function all_items(), which takes the form all_items(a in x), where a and x are arrays and the lengths of arrays a and x are set to len(a) and len(x) respectively during variable symbolization, all_items(a in x) will be converted to .

[0105] (5) For the built-in function any_item(), which is of the form any_item(a in x), where a and x are arrays, and in the variable symbolization, the lengths of arrays a and x are set to len(a) and len(x) respectively, then any_item(a in x) will be converted to .

[0106] (6) For the built-in function count(), in the form count(a, e1, ..., en), where n is a number and e1, ..., en are n logical expressions, count(a, e1, ..., en) will be converted to .

[0107] Figure 7 The expressions in lines 9-11 of the regulatory contract contain only comparison operators, which can be directly converted to the corresponding operators in Z3. The expressions in lines 12-13 contain the built-in function any_item(), which needs to be converted according to conversion rule (5). The symbolic result corresponding to each regulatory rule statement in the regulatory contract is as follows: Figure 10 As shown. Finally, simply input the symbolic regulatory rules into the SMT solver according to the type of conflict to be detected to determine whether a rule conflict exists.

[0108] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for detecting conflicts in regulatory contract rules, characterized in that, The method comprises the following steps: Step 1: type analysis phase: inferring the types of all variables in the regulatory contract; specifically, taking the abstract syntax tree of the regulatory contract as input, generating a variable type table through variable type dependency analysis and variable type propagation analysis; Step 2: regulatory rule symbolization phase: symbolizing variables and statements according to their types in the variable type table, and generating symbolized regulatory rules; Step 3: conflict detection phase: detecting conflicts in the symbolized regulatory rules in step 2; In the conflict detection, according to the regulatory rules involved in the regulatory conflict and the influence range of the regulatory conflict, the regulatory rule conflicts are divided into self-conflicts, local conflicts and complete conflicts; The self-conflict is defined as compliance with regulatory rules. Scope any state None of them meet the requirements of the regulatory rules. ,or or It is itself a contradiction, defined as follows: （1）； In the formula (3), S is all values of all variables in the regulatory range statement; The complete conflict is that for two regulatory rules R is the set of regulatory rules involved in the detection, if there exists a state that satisfies the regulatory range of both regulatory rules But any one Cannot meet the requirements of two regulatory rules at the same time, defined as follows: （2）； If formula (3) is established, it is proved that formula (2) is not established, and it is proved that the two regulatory rules are not complete conflicts: （3）； The local conflict is that two regulatory rules have the same or similar regulatory scope, but part of the state only meets one of the regulatory requirements, in the verification and On the basis of the related basis, the definition is as follows: （4）； For multiple regulatory rules The complete conflict of these regulatory rules is defined as follows: （5）； If formula (6) is established, it is proved that formula (5) is not established, and it is proved that the n regulatory rules are not complete conflicts, and any m of them are not complete conflicts; （6）； For local conflicts, if there are local conflicts in the n regulatory rules, there must be local conflicts between two of them, that is, the existence of local conflicts between two regulatory rules is a necessary condition for the existence of local conflicts in the n regulatory rules; The variable type dependency analysis in step 1 constructs a variable type dependency graph by analyzing the regulatory contract code, and adds type constraints of variables on the variable type dependency graph according to known information; the variable type dependency analysis traverses the abstract syntax tree of the regulatory contract code in a top-down manner, extracts all variables, and constructs a variable type dependency graph according to the constraint relationship between variables; the nodes in the variable type dependency graph represent the variables in the regulatory contract, and the edges represent the dependency relationship between the types of two variables; the variable type dependency analysis adds two types of constraints in the dependency graph through the variable and operator information in the abstract syntax tree, namely type constraint and relationship constraint; the type constraint is a constraint on the node attribute in the variable type dependency graph, that is, the possible type of the variable in the dependency graph; the relationship constraint is a constraint on the type relationship of two variables, specifically indicating whether the types of two variables or elements in the variable are compatible, that is, whether they are of the same type or can be converted to the same type through automatic type conversion; The variable type propagation analysis infers the types of variables with uncertain types through a type propagation algorithm based on the dependency graph; the type propagation algorithm first constructs a variable type table to record the types of all variables, and then starts from the variables with determined types, infers the types of the neighbor nodes of the variables according to the type constraints and relationship constraints in the variable type dependency graph, and propagates the type updates until the variable type table no longer changes; In step 2, the symbolization first extracts the statement sub-tree of each regulatory rule in the abstract syntax tree of the regulatory contract, and then traverses each sub-tree in a top-down manner, replaces all variables in the statement with symbols, and converts each statement into a logical expression according to the semantic information of the operator and the built-in function; The step 3 specifically comprises the following steps: Step 3.1: Self-conflict detection; Self-conflict detection needs to calculate whether each symbolic regulatory rule is satisfiable through an SMT solver, that is, to determine whether the regulatory rule is self-conflicting; the SMT solver has the following four calculation results: (1) sat: this result shows that all constraints can be satisfied at the same time, at this time the SMT solver will give a solution that satisfies the constraints; it is proved that the regulatory rule is not self-conflicting, and a business contract transaction within the regulatory scope can be given to satisfy all regulatory requirements; (2) unsat: this result shows that the SMT solver can prove that all constraints cannot be satisfied at the same time, proving that for any business contract transaction within the regulatory scope, the regulatory requirements cannot be met, according to formula (1), the regulatory rule is self-conflicting; (3) unknown: this result shows that the SMT solver cannot determine whether the constraints can be satisfied; (4) timeout: when using the SMT solver, a timeout time is set, and when the SMT solver runs beyond the set timeout time, it will return timeout; Step 3.2: Complete conflict detection; For a set of n regulatory rules, complete conflict detection is performed, and there are the following three cases: (1) the n regulatory rules are completely conflicting, and formula (5) is used for proof; (2) the n regulatory rules are not completely conflicting, and the conflict detection method should be able to give a solution of formula (6), and be able to ensure that any subset of the not completely conflicting regulatory rule set is not completely conflicting; (3) The regulatory scopes of the n regulatory rules cannot be satisfied simultaneously, that is At this time, neither can it be proved that the subset of the n regulatory rule set is completely conflicting, nor can it be proved that any subset is not completely conflicting, so different subsets of the regulatory rule set need to be analyzed for conflict. Step 3.3: Local conflict detection; Since the existence of local conflict between two regulatory rules is a necessary condition for the existence of local conflict in n regulatory rules, it is only necessary to perform conflict detection on the two-by-two combination of regulatory rules.

Images