A smart contract operation compliance detection method and system

Abstract

The present application relates to the field of smart contract compliance detection, and relates to a smart contract operation compliance detection method and system, the method comprising: acquiring operation flow information of a smart contract; reconstructing the operation flow information of the smart contract to obtain a reconstructed BPMN process model; partitioning the reconstructed BPMN process model to obtain a partitioned BPMN process model, with one partition corresponding to one operation flow; mapping the partitioned BPMN process model into a visual Markov chain; and detecting the operation compliance of the smart contract based on the visual Markov chain to obtain a detection result. The present application solves the problem of traditional methods relying on subjective judgment and being difficult to quantify, and can accurately identify high-risk states to provide quantitative basis for supply chain financial smart contract operation risk control and improve system robustness and security.

Description

Technical Field

[0001] This invention relates to the field of smart contract compliance testing, and more specifically, to a method and system for testing the compliance of smart contract operations. Background Technology

[0002] With the development of blockchain technology, smart contracts have become an important tool for managing operational risks in supply chain finance, offering significant advantages such as automated execution. However, their practical application faces challenges. On the one hand, they heavily rely on external data sources; inaccurate or tampered data can lead to erroneous execution, as exemplified by the 2019 loss of millions of dollars by the DeFi platform Synthetix due to oracle data input errors. On the other hand, low consistency in offline operations and unpredictable factors such as logistics delays can cause payment inaccuracies. Traditional methods for verifying operational compliance rely on subjective judgment, lacking the ability to cope with the complexity and dynamic uncertainties of supply chain finance, and are mostly qualitative analyses, making it difficult to quantify frequent transactions and complex operations. The Probabilistic Model Validator (PRISM) is suitable for handling uncertainties in complex systems, but the problem of formalizing the business logic of supply chain finance smart contracts and inputting it into PRISM has not yet been fully solved. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for detecting the compliance of smart contract operations, so as to improve the above-mentioned problems.

[0004] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0005] On the one hand, embodiments of this application provide a method for detecting the compliance of smart contract operations, the method comprising:

[0006] Obtain information about the operation process of smart contracts;

[0007] The operation process information of the smart contract is reconstructed to obtain the reconstructed BPMN process model.

[0008] The reconstructed BPMN process model is partitioned to obtain a partitioned BPMN process model, with one partition corresponding to one operation process.

[0009] The partitioned BPMN process model is mapped as a visualized Markov chain;

[0010] The compliance of smart contract operations is detected based on the visualized Markov chain, and the detection results are obtained.

[0011] Secondly, embodiments of this application provide a smart contract operation compliance detection system, the system comprising:

[0012] The acquisition module is used to obtain information about the operation process of smart contracts;

[0013] The first processing module is used to reconstruct the operation process information of the smart contract to obtain the reconstructed BPMN process model.

[0014] The second processing module is used to partition the reconstructed BPMN process model to obtain a partitioned BPMN process model, with one partition corresponding to one operation process.

[0015] The third processing module is used to map the partitioned BPMN process model into a visualized Markov chain.

[0016] The fourth processing module is used to detect the compliance of smart contract operations based on the visualized Markov chain and obtain the detection results.

[0017] Thirdly, embodiments of this application provide a smart contract operation compliance detection device, the device including a memory and a processor. The memory is used to store a computer program; the processor is used to execute the computer program to implement the steps of the above-described smart contract operation compliance detection method.

[0018] Fourthly, embodiments of this application provide a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described smart contract operation compliance detection method.

[0019] The beneficial effects of this invention are as follows:

[0020] This invention simplifies complex business logic and facilitates review and verification by acquiring smart contract operation process information and reconstructing it into a BPMN model. Partitioning the reconstructed BPMN model reduces model complexity and improves verification efficiency. Mapping the partitioned model to a visual Markov chain, and combining the PRISM tool and PCTL language to set attribute specifications, allows for the quantification of operational risk transfer probabilities, enabling smart contract operation compliance detection. This invention solves the problems of traditional methods relying on subjective judgment and being difficult to quantify, accurately identifying high-risk states, providing a quantitative basis for risk management of smart contract operations in supply chain finance, and improving system robustness and security.

[0021] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the smart contract operation compliance detection method described in this embodiment of the invention.

[0024] Figure 2 This is a schematic diagram of the smart contract operation compliance detection system described in an embodiment of the present invention.

[0025] Figure 3 This is a schematic diagram of the smart contract operation compliance testing device described in an embodiment of the present invention.

[0026] Figure 4 A flowchart of the smart contract execution protocol.

[0027] Figure 5 A schematic diagram of BPMN modeling.

[0028] Figure 6 This is a schematic diagram of a Markov chain for visualization.

[0029] The diagram is labeled as follows: 800, Smart contract operation compliance testing equipment; 801, Processor; 802, Memory; 803, Multimedia component; 804, I / O interface; 805, Communication component. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0031] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] Example 1:

[0033] This embodiment provides a method for detecting the compliance of smart contract operations. See [link to relevant documentation]. Figure 1 The figure shows that the method includes steps S1, S2, S3, S4, and S5, which specifically include:

[0034] Step S1: Obtain the operation process information of the smart contract;

[0035] Step S2: Reconstruct the operation process information of the smart contract to obtain the reconstructed BPMN process model;

[0036] Step S2 further includes steps S21, S22, and S23, which specifically include:

[0037] Step S21: Obtain the preset BPMN elements;

[0038] In this step, the preset BPMN elements include N, A, E, V, D, M, G, and F, where N is a finite set of nodes; A is a task set; E represents events; V represents the set of variables and data structure definitions in the BPMN process; D represents a data set, D = {D1, D2}, where D1 represents the task's input dataset and D2 represents the task's output dataset; M represents the task's message association set; G represents the gateway set; and F represents the sequence stream set.

[0039] Step S22: Construct BPMN tuples based on the preset BPMN elements;

[0040] Understandably, a typical BPMN process is a tuple. .

[0041] Step S23: Reconstruct the operation flow of the smart contract using the BPMN tuple to obtain the reconstructed BPMN process model.

[0042] In this step, each operation of the smart contract can be represented as a set of tuples. In this context, C represents the contract conditions, referring to the preconditions or rules that trigger the execution of the smart contract, such as payment conditions or time limits. The contract will automatically execute when certain specific conditions are met (e.g., a payment reaching a certain amount, a specific time window, etc.). The triggering conditions and events of the contract are the core mechanism for the automatic execution of smart contracts. O represents the operations within the contract, indicating the operations that occur when the triggering conditions are met, such as payments, state updates, or asset transfers. X represents the state of the contract, indicating its current execution status or stage, which may include initial state, execution state, completion state, etc. R represents the assets or resources involved in the contract, including currency, tokens, goods, or data. By combining the smart contract tuple and the BPMN tuple, a mapping relationship from smart contracts to BPMNs can be established. The mapping relationship is as follows:

[0043] 1) Task Sets: In BPMN, tasks represent activities in a business process, while operations in smart contracts... It can be directly mapped to task A in the BPMN task set.

[0044] ;

[0045] 2) Event Set: Events in BPMN are divided into start events, intermediate events, and end events. The contract state X of a smart contract can be mapped to the start events, intermediate events, and end events of BPMN.

[0046] ;

[0047] In the above formula, , , These represent the start event, intermediate event, and end event of the BPMN, respectively.

[0048] 3) Variables and Data Structures: Smart contracts often contain variables that need to be judged and stored, such as state data during contract execution. This data can be mapped to a set of variables in a BPMN.

[0049] Smart contract variables ;

[0050] 4) Data set: The input and output data R in a smart contract can be mapped to the data set D of the BPMN, representing the assets created, used, or transferred in the short term within the smart contract, such as the flow of funds, tokens, or items. The input data and output data correspond to the input and output of the smart contract, respectively.

[0051] ;

[0052] 5) Task message association: Various tasks of a smart contract may involve communication and message passing, especially in complex on-chain contract systems. Messages can be represented by the message association set M of a BPMN.

[0053] Smart contract messages ;

[0054] 6) Gateway Set: The conditional statement C in a smart contract can be mapped to a gateway set G in a BPMN. These gateways are responsible for handling the logical branches in the contract.

[0055] ;

[0056] 7) Sequence Stream Set: The state transitions or dependencies between operations of a smart contract can be mapped to a sequence stream F in BPMN representing the connection relationships between tasks, events, or gateways.

[0057] Smart contract sequence stream ;

[0058] In this embodiment, the original operation process of smart contracts (such as fund payment and data verification) is transformed into a graphical BPMN process model through the structured mapping of BPMN tuples. This model clearly presents the process logic, branch conditions, and state transition relationships in a visual manner, laying the foundation for subsequent model partitioning, Markov chain mapping, and compliance testing, and solving the problems of vague process description and difficulty in quantification in traditional methods.

[0059] Step S3: Divide the reconstructed BPMN process model into partitions to obtain a partitioned BPMN process model, with one partition corresponding to one operation process.

[0060] Step S3 further includes steps S31, S32, S33, S34, and S35, which specifically include:

[0061] Step S31: Perform a validity check on the reconstructed BPMN process model and obtain the check results;

[0062] In this step, the structural validity of the BPMN model (such as the correctness of node connections and the integrity of the process) is verified to avoid subsequent partitioning failures due to logical errors in the model itself (such as isolated nodes or unclosed processes). This ensures that the model conforms to the semantics of the business process and provides a reliable foundation for subsequent gateway identification and partitioning.

[0063] Step S32: When the detection result is valid, the gateways in the reconstructed BPMN process model are identified to obtain the identification result, which includes branch gateways and convergence gateways.

[0064] In this step, we locate the decision points (branch gateways) and process merging points (merging gateways) in the process. These two types of gateways are the core elements controlling the branching logic of the process. By identifying the gateway type, we provide a key basis for subsequently dividing the process into partitions by gateway, ensuring that the partition boundaries conform to the natural logic of the process.

[0065] Step S33: Store the branch gateway and the convergence gateway in the first storage table and the second storage table, respectively;

[0066] Step S34: Determine whether the number of gateways in the first storage table matches the number of gateways in the second storage table, and obtain the determination result;

[0067] Step S35: Divide the BPMN process model into partitions based on the judgment results.

[0068] Step S35 further includes steps S351, S352, and S353, which specifically include:

[0069] Step S351: When the judgment result is that the number of gateways in the first storage table matches the number of gateways in the second storage table, it is determined to be a non-nested gateway;

[0070] Step S352: When the determination result is that the number of gateways in the first storage table and the number of gateways in the second storage table do not match, it is determined to be a nested gateway;

[0071] Step S353: Partition the BPMN process model according to the non-nested gateway and the nested gateway to obtain the partitioned BPMN process model.

[0072] In this embodiment, a double-ended queue is used to sequentially pop branch gateways from the first storage table and merge gateways from the second storage table to generate gateway pairs. If, after popping a pair of gateways, there are still remaining branch and merge gateways in the queue, the currently popped gateway pair is determined to be a nested gateway pair and stored in the nested gateway list. If there are no remaining branch and merge gateways, it is determined to be a non-nested gateway and stored in the non-nested gateway list. The specific partitioning rule is as follows: all elements from the start event to the first diverging gateway are assigned to the first partition; then, the elements from the end event to the last converging gateway are assigned to the last partition. If there is gateway nesting in the model, it needs to be divided into inner gateway pairs and outer gateway pairs. Inner gateway pairs contain gateways and related elements located inside other gateways, forming sub-layer partitions, usually represented by black boxes; outer gateway pairs consist of outer gateways and their parent elements, with inner gateway pairs as their sub-parts. If there is no gateway nesting in the model, the partitions are directly divided based on the gateway pairs. For models without gateway nesting relationships, partitioning is directly processed based on gateway pairs without further hierarchical division. All gateway pairs will be partitioned sequentially. This partitioning rule simplifies the management of complex BPMN models and enhances their clarity and operability, improving the efficiency of subsequent analysis and processing. It should be noted that in this embodiment, non-nested gateways are directly partitioned into independent partitions based on the gateway pair; nested gateways are split into sub-partitions according to their hierarchy, ensuring that the complex process model is decomposed into logically independent minimum operational units. Partitioning reduces model complexity and facilitates accurate quantification of the operational risk transfer probability of each process step when subsequently mapped to a Markov chain.

[0073] Step S4: Map the partitioned BPMN process model into a visualized Markov chain;

[0074] Step S4 further includes steps S41, S42, S43, and S44, which specifically include:

[0075] Step S41: Construct the initialized Markov chain framework;

[0076] In this step, the basic structure of a discrete-time Markov chain is established, defining the state space and initial states, providing a probabilistic model framework for the subsequent BPMN process after mapping and partitioning. This framework determines the state representation method of the Markov chain and the basic structure of the transition logic, ensuring that the subsequent quantification of risk transition probabilities has a standardized carrier.

[0077] Step S42: Construct an initial flowchart based on the partitioned BPMN process model;

[0078] Step S43: Obtain the operational risk probability transition matrix;

[0079] In this step, the operational risk probability transition matrix is ​​specifically as follows:

[0080] ;

[0081] In the above formula, This represents the probability transition matrix for operational risk. The transition matrix represents the probability of operational risk occurring when the system transitions from one state to another. The propagation matrix representing the impact of operational risks specifically represents the probability of risk propagating to other states after an operational risk occurs in state i. It should be noted that this is achieved by analyzing the historical execution logs of smart contracts and statistically analyzing the frequency of risk transfers caused by non-standard operations between different operational partitions, thus constructing a quantified operational risk probability transfer matrix. This matrix describes the probability of operational risk transferring from one partition to another and is a core parameter for Markov chains to achieve quantitative risk analysis, solving the problem that traditional methods struggle to quantify dynamic risks.

[0082] Step S44: Traverse the initialized flowchart and determine the operational risk transition probability between each partition based on the operational risk probability transition matrix to obtain the visualized Markov chain.

[0083] In this step, by traversing the initialization flowchart, the values ​​in the operational risk probability transition matrix are mapped to the state transition edges of each partition, generating a visualized Markov chain model. This step realizes the transformation from process structure to probabilistic model, making the operational risk transition of each partition computable, and providing data support for subsequent compliance testing using the PRISM tool.

[0084] Step S5: Based on the visualized Markov chain, the compliance of smart contract operations is detected, and the detection results are obtained.

[0085] Step S5 further includes steps S51, S52, and S53, which specifically include:

[0086] Step S51: Obtain preset smart contract status information;

[0087] In this step, the preset smart contract state information is shown in Table 1 below:

[0088] Table 1 Supply Chain Finance Smart Contract Status Information

[0089]

[0090] In the table above, ContractStep represents the process steps of a smart contract, and EndSCF represents the overall risk status variable of supply chain finance, which is used to monitor whether operational risks have occurred in the entire supply chain finance transaction process. It is 1 if yes and 0 if no.

[0091] Step S52: Construct a PRISM query statement based on the preset smart contract state information;

[0092] Based on the predefined definition of smart contract state information, examples of PRISM attribute queries related to supply chain finance platform transactions include:

[0093] Attribute 1: What is the probability that no supply chain finance operation risk occurs during the entire process of a certain financing transaction completed on a blockchain-based supply chain finance platform?

[0094] ;

[0095] In the above formula, This represents the current state of supply chain finance, indicating a specific process node in the execution of the smart contract. Indicates the state value; This represents the overall risk status variable of supply chain finance; This represents the core operator for probabilistic querying, where n represents the range of values ​​for the state of the supply chain finance smart contract.

[0096] Attribute 2: Smart contract progress to a certain state What is the probability that a non-standard operation will result in no supply chain finance operational risks occurring throughout the entire supply chain finance process?

[0097] ;

[0098] In the above formula, F represents the PCTL temporal operator. The variable representing the steps in the smart contract process is specifically the first... This query focuses on whether localized risks in the system will affect the completion of the overall process, and the probability that the system will remain risk-free even if risks occur in intermediate steps. It helps managers assess the system's resilience and protective capabilities, preventing localized risks from impacting the overall process.

[0099] Attribute 3: Smart contract progress steps What is the probability that the supply chain finance operation is not standardized and that supply chain finance operation risks have occurred throughout the entire process?

[0100] ;

[0101] The purpose of this query is to identify the path of risk propagation from localized operations, that is, the probability that a localized risk will eventually expose the entire system to risk. This helps managers understand how localized risks affect the overall process, providing them with a basis for improvement or control measures targeting specific steps.

[0102] By setting these attribute queries, managers can conduct multi-dimensional monitoring of the operational risks of the blockchain supply chain finance platform, understand the security of the overall process, the manifestation of local risks, and how local risks affect the overall process, thereby taking more refined risk management measures.

[0103] Step S53: Use the PRISM query statement to check the compliance of smart contract operations.

[0104] In this step, the PRISM query is applied to a visualized Markov chain model. Using the probabilistic model verification function of the PRISM tool, the probability value of the smart contract meeting compliance requirements in actual operation is calculated. This step can quantitatively assess whether the risk transfer path of each operational partition conforms to preset specifications, such as detecting "the probability that no operational risk occurs from the initial state to the payment stage," providing data support for the operational compliance of smart contracts and solving the problem that traditional methods cannot quantify dynamic risks.

[0105] Example 2:

[0106] This implementation uses a railway engineering factoring financing case to illustrate the specific implementation method. Railway engineering projects typically have long cycles, complex capital chains, and involve multiple parties and capital flows, thus possessing unique supply chain characteristics. The blockchain-based railway engineering factoring financing platform is a digital platform that utilizes blockchain technology to provide accounts receivable financing for contractors and suppliers in railway construction projects. Its core is the operation of a workload factoring product, an innovative factoring financing method based on blockchain technology. It primarily provides financial support to suppliers through the recording of workload data from real transaction contracts. In this model, commercial factoring companies provide financing services to suppliers based on transaction forms and data confirmed by the core enterprise, reducing suppliers' dependence on the core enterprise. Through the transparency, decentralization, and immutability of blockchain, the platform ensures the authenticity of workload and accounts receivable data, enabling SMEs in the supply chain to convert their workload information into credit and automate the factoring financing, fund disbursement, and repayment processes through smart contracts. The smart contract operation protocol process is as follows: Figure 4 As shown, S0-S12 are specifically represented as follows:

[0107] S0 enables blockchain account registration and identity authentication for various roles (construction party, owner, supervisor, factoring party). These roles register blockchain accounts using zero-knowledge proofs (ZKP) with tax identifiers, bank account numbers, etc. The system generates a link between identity authentication information and blockchain addresses, and manages this identity information through smart contracts.

[0108] S1 is the project payment settlement application. The contractor initiates the project payment settlement application through the platform's web service, submitting data on completed work, work verification and pricing reports, and quality certification materials. This data is stored via IPFS, hashed, and uploaded to the blockchain. The contractor generates an encrypted digest and automatically submits it to the owner.

[0109] S2 is for the supervisor's verification of work completed. The supervisor accesses and verifies the engineering documents submitted by the construction party through blockchain nodes, performs on-site quality confirmation and measurement of materials, and signs the verification report. The supervisor uploads the verification signature confirmation through a smart contract, and the system automatically generates a digital signature.

[0110] S3 is for the owner's review and invoice issuance. The owner reviews the progress report signed by the supervisor through a smart contract. After review and confirmation, the planning and finance department generates project payment settlement invoices and generates and distributes blockchain digital certificates to the contractor through the blockchain system, establishing a link between the contractor's identity and blockchain address.

[0111] S4 allows construction companies to submit financing requests to factoring companies. The construction company uploads its invoices to the blockchain and automatically issues a factoring financing request through the platform. The factoring company receives the financing request and views the invoice information via a smart contract.

[0112] S5 verifies the contractor's identity and the invoices for the factoring company. The factoring company verifies the contractor's identity and the authenticity of the invoices through on-chain smart contracts. The factoring company confirms authenticity through data such as the invoice hash value and the contractor's blockchain certificate, preventing double staking.

[0113] S6 provides factoring solutions to factoring companies. Factoring companies submit their solutions through the platform's on-chain bidding system. Smart contracts automatically select the best factoring solution, and the construction company receives and evaluates the solution through a smart contract.

[0114] S7 signs a factoring agreement for the factoring party. The factoring party generates a random number and, through a smart contract, generates a symmetric key, encrypts the factoring agreement and bank account information, and stores it on the blockchain. The factoring party then sends the signed encrypted factoring agreement to the construction party via a smart contract.

[0115] S8 verifies the factoring agreement for the construction party. The construction party verifies the factoring party's blockchain digital certificate on-chain and checks the content of the factoring agreement. After confirming that the factoring agreement is correct, the construction party signs the agreement, and the smart contract generates a transaction record and uploads it to the blockchain.

[0116] S9 is for bill registration and filing. The construction party registers bill information on-chain, using the hash value of the bill's MAC value as the key-value storage, and the smart contract automatically generates and records the transaction log.

[0117] S10 serves as the contractor's notification to the owner. The contractor notifies the owner through the platform that a factoring agreement has been signed. The smart contract automatically updates the bill status and notifies the owner of the agreement's signing via blockchain.

[0118] S11 facilitates payments for the factoring party. The factoring party confirms the bill registration information via a smart contract and pays the factoring amount to the contractor's bank account. The platform automatically records payment information and timing via blockchain.

[0119] S12 makes payment to the owner. Upon maturity of the bill, the owner checks the factoring status of the bill via a smart contract to confirm there is no double pledging. The owner then decrypts the factoring company's bank account via the smart contract and pays the bill amount; the system automatically records the payment transaction.

[0120] BPMN modeling is performed by combining the flowchart of the smart contract execution protocol, such as... Figure 5 As shown.

[0121] The completed BPMN process model is then divided into eight operational partitions in this embodiment:

[0122] 1) Identity Authentication (A1 Partition): The system generates the association between identity authentication information and blockchain address, and manages the identity information through smart contracts;

[0123] 2) Project payment settlement application (A2 partition): The contractor submits data on the completed work, work verification and pricing reports, and quality certification materials. The data is stored on IPFS and uploaded to the blockchain.

[0124] 3) Inspection and Valuation (A3 Zone): The supervisor verifies the work done on the project documents submitted by the contractor. The supervisor conducts on-site quality verification and measurement of materials, uploads the inspection report, and generates a digital signature.

[0125] 4) Invoice Verification and Issuance (A4 Section): The owner verifies the supervisor's progress report and generates project payment settlement invoices. The owner generates and distributes blockchain digital certificates to the contractors through blockchain technology, establishing a link between their identities and blockchain addresses.

[0126] 5) Financing Request Submission and Verification (A5 Partition): The contractor uploads the invoices to the blockchain and automatically submits a factoring financing request. The factor receives the financing request and verifies the contractor's identity and the authenticity of the invoices.

[0127] 6) Factoring Solution Provision and Agreement Signing (A6 Partition): The factoring party submits a solution through the on-chain bidding system, the construction party evaluates the factoring solution and selects the best solution; the factoring party and the construction party sign a factoring agreement.

[0128] 7) Bill Registration and Registration (A7 Partition): The construction party registers bill information and generates transaction records on the blockchain.

[0129] 8) Payment (A8 section): The factoring party pays the factoring amount to the contractor's bank account via smart contract. The owner makes the final payment when the bill matures, ensuring no double pledging.

[0130] This partitioning method allows for a more intuitive representation of the specific tasks and transitions of each role at different stages, facilitating the verification of operational compliance.

[0131] After completing the partitioning and obtaining the BPMN process model, it is converted into a visual Markov chain, specifically as follows: Figure 6 As shown, it should be noted that the visualized Markov chain can quantify the probability of operational risks occurring at different stages of the business process through state transition probabilities. The operational partitions of the BPMN-based railway engineering factoring financing smart contract correspond to its operational states. Combining the historical operation logs of this smart contract, the records of non-standard operational events under each step partition are analyzed. The possible non-standard operations under each state are as follows: A1 partition: data tampering or information leakage in the system; A2 partition: the construction party submits false engineering quantity data or forges the acceptance report; A3 partition: the supervisor violates the operating rules and fails to accept and price the work according to the actual situation; A4 partition: the project payment settlement invoice generated by the owner may be forged or tampered with; A5 partition: the factor fails to check whether the invoice has been pledged twice; A6 partition: the factoring agreement may have ambiguities or disputes; A7 partition: the invoice registration or registration information is incorrect; A8 partition: the factor or the owner delays payment.

[0132] After obtaining the visualized Markov chain, this embodiment performs the following attribute queries for states A2-A8 of the railway engineering factoring financing smart contract:

[0133] Attribute 1: What is the probability that the smart contract progresses to state y (y<8) and the operation is not standardized, but the railway engineering factoring financing smart contract ultimately does not experience operational risks?

[0134] ;

[0135] Attribute 2: What is the probability that the smart contract will encounter operational risks in the future, given that the operation is not standardized when it reaches state y (y<8) and the railway engineering factoring financing smart contract is ultimately in operation?

[0136] ;

[0137] To enable regulators to monitor platform processes, this invention employs a reverse reasoning method. By defining the overall system behavior (operational risk occurs / no operational risk occurs), it deduces the impact of each state on the system as a whole. This examines which non-standard operations in certain states are more likely to lead the system to an undesirable final state (operational risk occurs), and also identifies which states are most robust and less likely to produce adverse results. Therefore, this invention pre-sets 10%, 30%, 60%, and 90% as the system's operational risk levels, i.e., the probability of the system experiencing operational risk. Analysis of query results under different preset value groups examines the impact of the probability of non-standard operations in different states of the railway engineering factoring financing smart contract on the overall system. After PRISM calculation, the probability results of non-standard operations in each state when the system determines whether operational risk occurs or not are shown in Table 2.

[0138] Table 2 Comparison of the probability of non-standard operation in each state (A2-A8) under different risk levels (%)

[0139]

[0140] When the system eventually encounters operational risks The overall system risk level is high, and the probability of non-standard operations in each state is higher than in the low-risk state. Analysis of the relationship between states A2-A8 and the system's operational level reveals that the probability of standard operation increases most rapidly with risk in state A8, reaching 72.81% when the system's operational level is 90%, making it the state most prone to non-standard operations. In state A5, the probability of non-standard operation is 36.87% when the system risk is 90%, also a high-risk state. Therefore, states A8 and A5 require the most focused monitoring. When the system does not experience operational risks... Except for A8, other states have a higher probability of non-standard operation at low levels because system robustness prevents local risks from evolving into global risks. A6 is the most robust, with only 1.40% of its non-standard operations when the overall system operational risk probability is 5%, and only 1.98% even when it rises to 90%.

[0141] In smart contracts for factoring financing in railway engineering projects, A8 (payment) directly impacts the stability of the cash flow, with significant risks associated with delayed payments. If this affects project progress, the probability of irregular operations increases significantly when system risk is high, necessitating measures such as setting strict payment deadlines. A6 (factoring scheme and agreement signing) has less impact on cash flow and is relatively stable, but requires regular review of agreement terms. A5 (financing request submission and verification) is particularly critical in supply chain finance; double pledging increases risk, and automation of bill management should be strengthened to reduce human error.

[0142] PRISM, a probabilistic model checking tool, enhances the adaptability of blockchains and smart contracts in complex scenarios. While blockchains and smart contracts excel at automating business logic execution, their system reliability verification capabilities are weak. PRISM, through probabilistic model checking, can simulate and analyze system performance under high-risk events such as delayed payments, ensuring operational compliance. It also provides formal verification for high-reliability domains and, combined with operation logs, enables real-time verification of operational compliance. In practical applications, PRISM can monitor the compliance of various system states in real time, issuing alerts and providing feedback on the probability of deviations. For example, by setting payment deadlines and pledging time windows, when states like A8 and A5 are at high risk, it provides management with a basis for risk response, ensuring system stability.

[0143] Example 3:

[0144] like Figure 2 As shown, this embodiment provides a smart contract operation compliance detection system. The system includes an acquisition module 901, a first processing module 902, a second processing module 903, a third processing module 904, and a fourth processing module 905, specifically including:

[0145] Module 901 is used to obtain the operation process information of the smart contract;

[0146] The first processing module 902 is used to reconstruct the operation process information of the smart contract to obtain the reconstructed BPMN process model.

[0147] The second processing module 903 is used to partition the reconstructed BPMN process model to obtain a partitioned BPMN process model, with one partition corresponding to one operation process.

[0148] The third processing module 904 is used to map the partitioned BPMN process model into a visualized Markov chain.

[0149] The fourth processing module 905 is used to detect the compliance of smart contract operations based on the visualized Markov chain and obtain the detection results.

[0150] In one specific embodiment of this disclosure, the first processing module further includes a first acquisition unit, a first processing unit, and a second processing unit, specifically including:

[0151] The first acquisition unit is used to acquire preset BPMN elements;

[0152] The first processing unit is used to construct BPMN tuples based on the preset BPMN elements;

[0153] The second processing unit is used to reconstruct the operation flow of the smart contract using the BPMN tuple to obtain the reconstructed BPMN process model.

[0154] In one specific embodiment of this disclosure, the second processing module further includes a third processing unit, a fourth processing unit, a fifth processing unit, a judgment unit, and a sixth processing unit, specifically including:

[0155] The third processing unit is used to perform a validity check on the reconstructed BPMN process model and obtain the check result.

[0156] The fourth processing unit is used to identify the gateways in the reconstructed BPMN process model when the detection result is valid, and to obtain the identification result, which includes branch gateways and convergence gateways.

[0157] The fifth processing unit is used to store the branch gateway and the convergence gateway into the first storage table and the second storage table, respectively;

[0158] The judgment unit is used to determine whether the number of gateways in the first storage table matches the number of gateways in the second storage table, and obtain the judgment result;

[0159] The sixth processing unit is used to partition the BPMN process model according to the judgment result.

[0160] In one specific embodiment of this disclosure, the sixth processing unit further includes a first sub-judgment unit, a second sub-judgment unit, and a seventh processing unit, specifically including:

[0161] The first sub-judgment unit is used to determine a non-nested gateway when the judgment result is that the number of gateways in the first storage table matches the number of gateways in the second storage table.

[0162] The second sub-judgment unit is used to determine that a nested gateway is present when the judgment result is that the number of gateways in the first storage table and the number of gateways in the second storage table do not match.

[0163] The seventh processing unit is used to partition the BPMN process model according to the non-nested gateway and the nested gateway to obtain the partitioned BPMN process model.

[0164] In one specific embodiment of this disclosure, the third processing module further includes an eighth processing unit, a ninth processing unit, a second acquisition unit, and a tenth processing unit, specifically including:

[0165] The eighth processing unit is used to construct the initial Markov chain framework;

[0166] The ninth processing unit is used to construct the initialization flowchart based on the partitioned BPMN process model;

[0167] The second acquisition unit is used to acquire the operational risk probability transition matrix;

[0168] The tenth processing unit is used to traverse the initialized flowchart and determine the operational risk transition probability between each partition based on the operational risk probability transition matrix to obtain the visualized Markov chain.

[0169] In one specific embodiment of this disclosure, the fourth processing module further includes a third acquisition unit, an eleventh processing unit, and a twelfth processing unit, specifically comprising:

[0170] The third acquisition unit is used to acquire preset smart contract state information;

[0171] The eleventh processing unit is used to construct a PRISM query statement based on the preset smart contract state information;

[0172] The twelfth processing unit is used to detect the compliance of smart contract operations using the PRISM query statement.

[0173] It should be noted that the specific methods by which each module performs operations in the system described in the above embodiments have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0174] Example 4:

[0175] Corresponding to the above method embodiments, this embodiment also provides a smart contract operation compliance detection device. The smart contract operation compliance detection device described below and the smart contract operation compliance detection method described above can be referred to in correspondence.

[0176] Figure 3 This is a block diagram illustrating a smart contract operation compliance detection device 800 according to an exemplary embodiment. Figure 3 As shown, the smart contract operation compliance testing device 800 may include: a processor 801 and a memory 802. The smart contract operation compliance testing device 800 may also include one or more of the following: a multimedia component 803, an I / O interface 804, and a communication component 805.

[0177] The processor 801 controls the overall operation of the smart contract operation compliance detection device 800 to complete all or part of the steps in the aforementioned smart contract operation compliance detection method. The memory 802 stores various types of data to support the operation of the smart contract operation compliance detection device 800. This data may include, for example, instructions for any application or method operating on the smart contract operation compliance detection device 800, and application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 802 can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 803 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 802 or transmitted via the communication component 805. The audio component also includes at least one speaker for outputting audio signals. I / O interface 804 provides an interface between processor 801 and other interface modules, such as keyboards, mice, and buttons. These buttons can be virtual or physical. Communication component 805 is used for wired or wireless communication between the smart contract operation compliance detection device 800 and other devices. Wireless communication includes Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof. Therefore, the corresponding communication component 805 may include a Wi-Fi module, a Bluetooth module, and an NFC module.

[0178] In an exemplary embodiment, the smart contract operation compliance detection device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the aforementioned smart contract operation compliance detection method.

[0179] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps of the smart contract operation compliance detection method described above. For example, the computer-readable storage medium may be the memory 802 including the program instructions described above, which may be executed by the processor 801 of the smart contract operation compliance detection device 800 to complete the smart contract operation compliance detection method described above.

[0180] Example 5:

[0181] Corresponding to the above method embodiments, this embodiment also provides a readable storage medium. The readable storage medium described below can be referred to in conjunction with the smart contract operation compliance detection method described above.

[0182] A readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the smart contract operation compliance detection method of the above method embodiments.

[0183] Specifically, the readable storage medium can be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0184] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0185] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for detecting the compliance of smart contract operations, characterized in that, include: Obtain information about the operation process of smart contracts; The operation process information of the smart contract is reconstructed to obtain the reconstructed BPMN process model. The reconstructed BPMN process model is partitioned to obtain a partitioned BPMN process model, with one partition corresponding to one operation process. The partitioned BPMN process model is mapped as a visualized Markov chain; The compliance of smart contract operations is detected based on the visualized Markov chain, and the detection results are obtained. The reconstructed BPMN process model is partitioned, including: The reconstructed BPMN process model is subjected to a validity check, and the check results are obtained. When the detection result is valid, the gateways in the reconstructed BPMN process model are identified to obtain the identification result, which includes branch gateways and convergence gateways. The branch gateway and the convergence gateway are stored in the first storage table and the second storage table, respectively. Determine whether the number of gateways in the first storage table matches the number of gateways in the second storage table, and obtain the determination result; The BPMN process model is partitioned based on the judgment results.

2. The smart contract operation compliance detection method according to claim 1, characterized in that, The operation process information of the smart contract is reconstructed, including: Retrieve the preset BPMN elements; Construct BPMN tuples based on the preset BPMN elements; The operation process of the smart contract is reconstructed using the BPMN tuple to obtain the reconstructed BPMN process model.

3. The smart contract operation compliance detection method according to claim 1, characterized in that, Based on the judgment results, the BPMN process model is partitioned, including: When the determination result is that the number of gateways in the first storage table matches the number of gateways in the second storage table, it is determined to be a non-nested gateway. When the determination result is that the number of gateways in the first storage table does not match the number of gateways in the second storage table, it is determined to be a nested gateway; The BPMN process model is partitioned based on the non-nested gateway and the nested gateway to obtain the partitioned BPMN process model.

4. The smart contract operation compliance detection method according to claim 1, characterized in that, The partitioned BPMN process model is mapped to a visualized Markov chain, including: Construct an initial Markov chain framework; Build an initialization flowchart based on the partitioned BPMN process model; Obtain the operational risk probability transition matrix; The initial flowchart is traversed, and the operational risk transition probability between each partition is determined based on the operational risk probability transition matrix to obtain the visualized Markov chain.

5. A smart contract operation compliance detection system, characterized in that, include: The acquisition module is used to obtain information about the operation process of smart contracts; The first processing module is used to reconstruct the operation process information of the smart contract to obtain the reconstructed BPMN process model. The second processing module is used to partition the reconstructed BPMN process model to obtain a partitioned BPMN process model, with one partition corresponding to one operation process. The third processing module is used to map the partitioned BPMN process model into a visualized Markov chain. The fourth processing module is used to detect the compliance of smart contract operations based on the visualized Markov chain and obtain the detection results. The second processing module includes: The third processing unit is used to perform a validity check on the reconstructed BPMN process model and obtain the check result. The fourth processing unit is used to identify the gateways in the reconstructed BPMN process model when the detection result is valid, and to obtain the identification result, which includes branch gateways and convergence gateways. The fifth processing unit is used to store the branch gateway and the convergence gateway into the first storage table and the second storage table, respectively; The judgment unit is used to determine whether the number of gateways in the first storage table matches the number of gateways in the second storage table, and obtain the judgment result; The sixth processing unit is used to partition the BPMN process model according to the judgment result.

6. The smart contract operation compliance detection system according to claim 5, characterized in that, The first processing module includes: The first acquisition unit is used to acquire preset BPMN elements; The first processing unit is used to construct BPMN tuples based on the preset BPMN elements; The second processing unit is used to reconstruct the operation flow of the smart contract using the BPMN tuple to obtain the reconstructed BPMN process model.

7. The smart contract operation compliance detection system according to claim 5, characterized in that, The sixth processing unit includes: The first sub-judgment unit is used to determine a non-nested gateway when the judgment result is that the number of gateways in the first storage table matches the number of gateways in the second storage table. The second sub-judgment unit is used to determine that a nested gateway is present when the judgment result is that the number of gateways in the first storage table and the number of gateways in the second storage table do not match. The seventh processing unit is used to partition the BPMN process model according to the non-nested gateway and the nested gateway to obtain the partitioned BPMN process model.

8. The smart contract operation compliance detection system according to claim 5, characterized in that, The third processing module includes: The eighth processing unit is used to construct the initial Markov chain framework; The ninth processing unit is used to construct the initialization flowchart based on the partitioned BPMN process model; The second acquisition unit is used to acquire the operational risk probability transition matrix; The tenth processing unit is used to traverse the initialized flowchart and determine the operational risk transition probability between each partition based on the operational risk probability transition matrix to obtain the visualized Markov chain.

Images