A method for formalizing and verifying a smart contract security mode based on HCPN

Abstract

The application discloses an intelligent contract security mode formalization and verification method based on HCPN, converts the security mode of an intelligent contract into a BPMN model by using a submission display method, converts the BPMN model into a CPN model through preset mapping rules, analyzes the CPN model to generate a first state space report, converts the source code of the intelligent contract into an HCPN model, analyzes the HCPN model to generate a second state space report, respectively describes the first and second state space reports as a group of attributes, uses an ASK-CTL formula to express the group of attributes as an SML function, runs the SML function, and verifies whether the intelligent contract follows the security mode according to a running result. The application is convenient for investigating the security mode which is abused in an intelligent contract environment, and changes an original modeling mode through mapping rules into an automatic modeling process.

Description

Technical Field

[0001] This application belongs to the field of smart contract technology, and in particular relates to a formalization and verification method for smart contract security patterns based on HCPN. Background Technology

[0002] A smart contract is an automatically executable program that runs across a blockchain network. Since blockchain networks are theoretically secure, attackers can only exploit vulnerabilities to compromise smart contracts. The well-known THE DAO smart contract attack exploited a recursive call vulnerability, ultimately resulting in nearly $6 billion in losses. Since then, protecting smart contracts has become a crucial issue in the field, leading to the emergence and development of various analytical tools to detect vulnerabilities.

[0003] Weiqin Zou, David Lo, and others demonstrated through experiments that: 1. There is no powerful and effective method to guarantee the security of smart contract code; 2. Existing development tools are still very basic; 3. Programming languages ​​and virtual machines still have many limitations; 4. Performance issues are difficult to handle in resource-constrained operating environments; 5. Online resources (including advanced / updated documentation or community support) are still limited. In other words, using analysis tools to check for existing vulnerabilities in smart contracts is insufficient to guarantee their correctness and security. Due to the limitations of tools, it is necessary to ensure the correctness and reliability of smart contracts during the development phase through certain security patterns. Several international conferences have described a set of security patterns and best practices that developers can follow to improve the reliability of their code and avoid vulnerabilities in advance. For example, Wohrrer M and Zdun U collected data from different sources to answer their questions about common code patterns in robustness and what problems these patterns can solve. Then, they used grounded theory techniques to analyze the data they collected and proposed six security patterns based on robustness languages. They described the security patterns in detail and illustrated them with examples of robustness.

[0004] However, these patterns are already presented in textual descriptions and lack formal formulas, making it impossible to detect their implementation in the source code. Furthermore, the complexity of business logic and the characteristics of smart contracts make it more difficult for developers to follow specific instructions.

[0005] NejcZupan et al. and Wen Hu et al. introduced their security work, generating a secure smart contract by modeling and validating a model. Zhentian Liu, Jing Liu, Wang Duo, and Xudong He et al. used CPN modeling as a formal validation of smart contracts, but they did not provide formal or required properties, nor did they provide a security model. Summary of the Invention

[0006] The purpose of this application is to provide a formalization and verification method for smart contract security patterns based on HCPN, in order to address the shortcomings of current research by scholars.

[0007] To achieve the above objectives, the technical solution of this application is as follows:

[0008] A formalization and verification method for smart contract security schema based on HCPN, comprising:

[0009] The security model of the smart contract is converted into a BPMN model using the submission and presentation method. Through preset mapping rules, the BPMN model is converted into a CPN model, and the CPN model is analyzed to generate a first state space report.

[0010] Blindly test smart contracts, convert smart contract source code into HCPN model, analyze HCPN model to generate second state space report;

[0011] The first and second state space reports are described as a set of attributes, and the set of attributes is expressed as an SML function using the ASK-CTL formula. The SML function is run, and the smart contract is verified to conform to the security mode based on the running result.

[0012] Furthermore, the formalization and verification method for smart contract security patterns based on HCPN also includes:

[0013] ASK-CTL query is used to check whether there are no deadlock markers, no live nodes, and no loop termination markers.

[0014] Furthermore, the analysis of the CPN model generates a first state-space report, including:

[0015] A marker was added as an initial marker in the two libraries, start and req, at the main input location.

[0016] Furthermore, the analysis of the HCPN model generates a second state-space report, including:

[0017] Initial tags were added to the four main input locations: start, Breq, Rreq, and Rwithd.

[0018] This application proposes a formalization and verification method for smart contract security patterns based on HCPN. It describes the expected behavior of the Commit-Reveal pattern as an ASK-CTL / SML formula, and then uses the CPN tool to examine its implementation in a blind contract, which helps to discover errors and vulnerabilities in the code. In the future, this application will provide developers with more security patterns for analysis, facilitating their access and understanding, and enabling the investigation of security patterns abused in smart contract environments. It transforms the previously difficult process of modeling through mapping rules into an automated modeling process. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the formalization and verification method of the smart contract security model based on HCPN in this application;

[0020] Figure 2 This is a schematic diagram of the BPMN model in this application;

[0021] Figure 3 This is a schematic diagram of the state space report in an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the ASK-CTL / SML results of an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] In one embodiment, such as Figure 1 As shown, a formalization and verification method for smart contract security patterns based on HCPN is proposed, including:

[0025] Step S1: Convert the security mode of the smart contract into a BPMN model using the submission and presentation method. Convert the BPMN model into a CPN model using preset mapping rules. Analyze the CPN model to generate a first state space report.

[0026] Wohrer M. and Zdun U. defined the secure pattern rule as "applying a commitment scheme to ensure that value commits are bound and hidden until the end of the merge phase, after which the value is revealed and can be publicly verified to remain unchanged." An informal description of the secure pattern consists of three phases: in the first phase (Commit phase), an encrypted value and a salt are committed to the data to be committed; in the second phase (Reveal phase), the original data is revealed, i.e., the original data and salt are recommitted; finally, the initially committed data is matched against the original data until a match is found.

[0027] This application transforms the informal description of security models into a BPMN model (Business Process Modeling and Labelling), such as... Figure 2 As shown, the model uses two rectangles to represent the two phases of the security mode. Each phase has two activities, starting with clock judgment, determining whether it is in the commit phase or the display phase, and then verifying the consistency of the values ​​in the two phases.

[0028] Then, using the mapping rules mentioned by Decsupa C, Vatanawood W, and Meghzili S, Chaoui A, the BPMN model, which lacks formal semantics, is transformed into a CPN model, adding some concrete objects as a series of descriptions. The CPN model starts from the start position (whose color set: (INTxINTxSTRINGxINT) represents the submission time, display time, address, and contract account, respectively) and the req position (whose color set: (STRINGxINTxINT) represents the user's address, account, and request time, respectively).

[0029] For simulation purposes, this application represents the Commit phase using the commit transition and the hashV library. The Reveal phase is represented by the reveal transition, the actualV library, and the match transition. This application adds a time-out transition to represent invalid times (committed before the commit phase or after the reveal phase). Initial markers are added at the two libraries (start and req) at the main input locations. Then, a first state space report is generated based on the number of relevant nodes counted by the model.

[0030] In a specific embodiment, such as Figure 3 The diagram shows an example of a state-space report with 21 nodes (NODES) and 23 arcs (ARCS), indicating that the model is finite and bounded. The identical numbers in the Scc Graph fields signify no cycles. The last node, 21, is a dead marker, while unverified transitions are dead transitions (the model and other transitions are still alive), meaning the model terminated and executed in a finite manner. Therefore, the model is correct and safe, implying that transitions occur infinitely frequently in every infinite firing sequence.

[0031] Step S2: Blindly test the smart contract, convert the smart contract source code into an HCPN model, analyze the HCPN model to generate a second state space report.

[0032] This step involves modeling the smart contract in a real-world, blind-testing environment. For formal verification, a formal model is required; this embodiment uses Hierarchical Colorized Petri Nets (HCPNs) to represent the contract code. HCPNs are used to represent and isolate each function in the code, focusing on individual functions and local variables rather than other variables, providing multi-level details within the model.

[0033] Using a set of mapping rules, by extending the rules introduced by Dedova A and Petrucci L., Solidity contracts are converted into HCPN models. These rules are as follows:

[0034] 1) Read the contract code and understand its structure and flow.

[0035] 2) Divide the code content into: data types, global / local variables, state, functions, expression statements, and conditional statements.

[0036] 3) For top-level modeling: Place objects (circular nodes) represent major participants (e.g., Breq and Rreq), transition objects (squares) represent functions (e.g., constructor and bids), connections between places represent intermediate states, and color sets represent data types.

[0037] 4) For low-level modeling, function transitions are expanded. Each expression statement is represented by transitions and links through libraries, and directed arcs represent the inputs / outputs of transitions.

[0038] 5) Map the data types in the CPN ML language to the same type, and compensate for undefined types with equivalent types (e.g., an address type is defined as a string). Complex data types are defined as composites (tuples) with simple data types.

[0039] 6) The if statement and any other conditional statement are represented by a place and two transitions; these conditional representations are all protected by the transitions.

[0040] Based on the above rules, a blind auction contract model was built from the Solidity website (v0.8.7 documentation). In a blind auction contract scenario, bidders send the hash value of their bid during the bidding period. They then reveal the actual value of their bid during the disclosure period. Finally, the model verifies the bidding result by comparing the hash value with the actual value; this is the blind auction smart contract.

[0041] In a specific embodiment, a typical contract model comprises six functions represented by five place objects (bids, auctionEnd, withdraw, reveal, and placeBid within the reveal sub-module). `init` (basic transition) represents the constructor. Each sub-module is a sub-module representing function code. The model is initialized by adding tokens to places: the `start` place (representing the contract address and the time for each bid and reveal period), the `Breq` place (representing a bid request), the `Rreq` place (representing a reveal request), the `Rwithd` place (representing a withdraw request), and the `PendingR` place (storing bid data).

[0042] To simulate this model, this embodiment adds initial markers at the four locations (start, Breq, Rreq, and Rwithd) of the main input position. Then, a second state-space report is generated through model statistics.

[0043] It can be noted that in the generated state space report, the number of nodes and directed arcs in each SS field and SCC Graph field is the same, which means that there is no self-circularity (no infinitely occurring sequence). Therefore, it can be concluded that the model guarantees termination and living freedom.

[0044] Step S3: Describe the first and second state space reports as a set of attributes respectively, express the set of attributes as an SML function using the ASK-CTL formula, run the SML function, and verify whether the smart contract follows the security mode based on the running result.

[0045] This application uses an ASK-CTL / SML function to check whether the contract model works as expected. To verify whether the security model conflicts with the smart contract, the first state space report is first described as a set of attributes, i.e., places, and then these attributes are expressed as an SML function using an ASK-CTL formula. This SML function will be used in subsequent comparisons.

[0046] In one specific embodiment, the model after security mode conversion has five transitions to represent the final result, described in the correct order of the transitions in the attributes. The specific ASK-CTL formula is as follows:

[0047] OR(AU(NOT(OR(verified,nonverified)),

[0048] AND(AU(NOT(reveal),commit),

[0049] AU(NOT(match),AND(commit,reveal)))),timeout).

[0050] In another specific embodiment, for the second state space report, the same set of described attributes is written into the SML function using the ASK-CTL formula. The specific content of the SML function is as follows:

[0051] fun commit a=(Bind.useCaseSC_25HG_f'bids(1,{})=ArcToBE a);

[0052] fun reveal a=(Bind.useCaseSC_25HG_f'reveal(1,{})=ArcToBE a);

[0053] fun match a=(Bind.useCaseSC_25HG_f'reveal(1,{})=ArcToBE a);

[0054] fun verified a=(Bind.useCaseSC_25HG_f'auctionEnd(1,{})=ArcToBE a);

[0055] fun nonVerified a=(Bind.useCaseSC_25HG_f'withdraw(1,{})=ArcToBE a);

[0056] val A1=AF("commit step",commit);

[0057] val A2=AF("reveal step",reveal);

[0058] val A3=AF("match step",match);

[0059] val A4=AF("verified step",verified);

[0060] val A5=AF("nonVerified step",nonVerified);

[0061] val myASKCTLformula=MODAL(FORALL_UNTIL((OR(NOT(A4),NOT(A5))),(AND((FORALL_UNTIL(NOT(A2),A1)),(FORALL_UNTIL(NOT(A3),(AND(A1,A2))))))));

[0062] eval_node myASKCTLformula InitNode.

[0063] Finally, the results of the SML function are analyzed. (See [link to SML function output] for details.) Figure 4 The list of dead nodes (LIST OF DEADMARKINGS) is the linked list of dead nodes, and the number of dead node markers (NUMBER OF DEAD MARKINGS) is the number of dead node markers. If the number of dead node markers is the same, the results are considered identical.

[0064] By comparing the SML function execution results reported by the two state spaces, if the results are the same, the smart contract is considered to follow the described security mode, meaning that the security of the smart contract can be automatically determined by following this security mode. Otherwise, the security mode is considered to have failed and cannot be used for smart contract security verification.

[0065] In addition, in a specific embodiment, it also includes: using ASK-CTL query to query whether there are no deadlock markers, no live nodes, no loop termination markers, and other characteristics, for comparison and termination judgment of the two groups.

[0066] The details of the ASK-CTL query are as follows:

[0067] funstartn=(M ark·coin′sender1n=[(“0X00A”,30),

[0068] ("0X00A",30),("0X00A",30),("0X00B",30)]

[0069] andalsoM ark·coin′start1n=[(“0X00C”,0)]

[0070] andalsoM ark·coin′minter1n=[]

[0071] andalsoM ark·coin′receiver1n=[(“0X00S”,0)]

[0072] andalsoM ark·coin′caller1n=[(“0X00W”,40)]

[0073] andalsoM ark·coin′coinm1n=[]

[0074] andalsoM ark·coin′T x1n=[]

[0075] andalsoM ark·coin′error1n=[]);

[0076] fungoaln=(M ark·coin′sender1n=[]

[0077] andalsoM ark·coin′start1n=[]

[0078] andalsoM ark·coin′minter1n=[]

[0079] andalsoM ark·coin′receiver1n=[(“0X00B”,60)]

[0080] andalsoM ark·coin′caller1n=[(“0X00W”,10)]

[0081] andalsoM ark·coin′coinm1n=[]

[0082] andalsoM ark·coin'T x1n=[("0X00W","0X00S",30)]

[0083] andalsoM ark·coin′error1n=[]);

[0084] valmyASKCT Lformula=(INV(OR(NF("start",start),

[0085] EV(NF("goal",goal)))));

[0086] evalnodemyASKCT LformulaInitNode;

[0087] According to the query results, if the two sets of data are the same and there are no deadlock markers, no live nodes, and no self-loop termination markers, i.e. the loop terminates, then the smart contract follows the safety mode.

[0088] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A formalization and verification method for smart contract security patterns based on HCPN, characterized in that, The formalization and verification method for smart contract security patterns based on HCPN includes: The security model of the smart contract is converted into a BPMN model using the submission and presentation method. Through preset mapping rules, the BPMN model is converted into a CPN model, and the CPN model is analyzed to generate a first state space report. Blindly test smart contracts, convert smart contract source code into HCPN model, analyze HCPN model to generate second state space report; The first and second state space reports are described as a set of attributes, and the set of attributes is expressed as an SML function using the ASK-CTL formula. The SML function is run, and the smart contract is verified to follow the security mode based on the running result. The process of verifying whether the smart contract follows the security mode based on the execution results includes: Compare the SML function execution results reported by the two state spaces. If the results are the same, the smart contract is considered to follow the security mode. Otherwise, the security mode is considered to have failed and cannot be used for smart contract security verification.

2. The method for formalizing and verifying the security model of smart contracts based on HCPN according to claim 1, characterized in that, The formalization and verification method for smart contract security patterns based on HCPN also includes: ASK-CTL query is used to check whether there are no deadlock markers, no live nodes, and no loop termination markers.

3. The method for formalizing and verifying the security model of smart contracts based on HCPN according to claim 1, characterized in that, The analysis of the CPN model generates a first state-space report, including: A marker was added as an initial marker in the two libraries, start and req, at the main input location.

4. The method for formalizing and verifying the security model of smart contracts based on HCPN according to claim 1, characterized in that, The analysis of the HCPN model generates a second state-space report, including: Initial tags were added to the four main input locations: start, Breq, Rreq, and Rwithd.

Images