Method, device and equipment for multiple composite detection of smart contract and storage medium

Abstract

The present disclosure relates to a method, device, equipment and storage medium for multiple composite detection of smart contracts. The method comprises: obtaining a smart contract to be detected; using multiple detection tools to detect the smart contract to be detected respectively, and obtaining detection result files generated by each detection tool respectively; performing data integration processing on the multiple detection result files to obtain an initial vulnerability list; and verifying the initial vulnerability list using a large language model to obtain a target vulnerability list. The method provided by the present disclosure solves the technical problems of large bias of a single detection tool for different vulnerability types and low coverage of vulnerability detection by detecting the smart contract to be detected using multiple detection tools. The use of a large language model to verify the detection results output by the detection tools can further reduce the false positive rate and false negative rate of vulnerabilities and improve the security of smart contracts.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for multiple composite detection of smart contracts. Background Technology

[0002] With the rapid development of healthcare, the Internet of Things, and financial information, the application of blockchain technology in these fields is gradually gaining recognition. Smart contracts, as decentralized applications within the blockchain, can complete transparent, immutable, and traceable information transmission and monetary transactions without third-party verification. However, smart contracts currently also face challenges such as malicious attacks and code vulnerabilities.

[0003] In related technologies, to improve the security of smart contracts and discover potential code vulnerabilities, smart contract detection tools are typically used to perform code inspections. These tools contain multiple detectors, each focusing on specific vulnerability types. However, there are significant differences between different tools, exhibiting considerable bias towards different vulnerability types. Furthermore, these tools rely on expert-defined rules to detect code vulnerabilities. With the increasing number and complexity of smart contracts, problems such as high false positive and false negative rates arise, preventing developers from promptly identifying potential vulnerabilities in smart contracts and thus increasing security risks. Summary of the Invention

[0004] According to a first aspect of this disclosure, a multi-factor composite detection method for smart contracts is provided, comprising:

[0005] Obtain the smart contract to be tested;

[0006] The smart contract to be tested is tested using multiple testing tools, and the test result files generated by each testing tool are obtained.

[0007] The data from multiple detection result files are integrated and processed to obtain an initial vulnerability list;

[0008] The initial vulnerability list is verified using a large language model to obtain the target vulnerability list.

[0009] According to a second aspect of this disclosure, a multi-factor composite detection device for smart contracts is provided, comprising:

[0010] The data acquisition module is used to acquire the smart contracts to be tested;

[0011] The data processing module is used to use multiple detection tools to detect the smart contract to be detected, and to obtain the detection result file generated by each detection tool.

[0012] The data processing module is also used to integrate and process multiple detection result files to obtain an initial vulnerability list;

[0013] The data processing module is also used to verify the initial vulnerability list using a large language model to obtain the target vulnerability list.

[0014] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0015] Processor; and,

[0016] Memory for stored programs;

[0017] The program includes instructions that, when executed by the processor, cause the processor to perform the method according to an exemplary embodiment of the present disclosure.

[0018] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method according to exemplary embodiments of this disclosure.

[0019] The embodiments of this disclosure provide one or more technical solutions that, by acquiring a smart contract to be tested, employing multiple testing tools to test the smart contract separately, and obtaining testing result files generated by each testing tool, integrate and process the multiple testing result files to obtain an initial vulnerability list. A large language model is then used to verify the initial vulnerability list to obtain a target vulnerability list. The multi-factor composite testing method for smart contracts provided in this disclosure solves the technical problems of significant bias in a single testing tool for different vulnerability types and low vulnerability detection coverage of testing tools by using multiple testing tools to test the smart contract. Using a large language model to verify the testing results output by the testing tools can further reduce the false positive rate and false negative rate of vulnerabilities, thereby improving the security of smart contracts. Attached Figure Description

[0020] Further details, features, and advantages of this disclosure are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0021] Figure 1 This is an example of an exemplary multi-factor composite detection method for smart contracts provided in this disclosure.

[0022] Figure 2 A flowchart illustrating a multi-factor composite detection method for smart contracts provided in this disclosure;

[0023] Figure 3 This is an exemplary flowchart of a detection module provided in this disclosure;

[0024] Figure 4 Here is an exemplary flowchart of the verification module provided in this disclosure;

[0025] Figure 5 A flowchart illustrating the multi-factor composite detection method for smart contracts provided as an example in this disclosure;

[0026] Figure 6 A schematic block diagram of the functional modules of a multi-layer composite detection device for smart contracts provided as an example in this disclosure;

[0027] Figure 7 A schematic block diagram of a chip provided as an example of this disclosure;

[0028] Figure 8 This is a structural block diagram of an exemplary electronic device provided in this disclosure. Detailed Implementation

[0029] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0030] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0031] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to," and the term "based on" means "at least partially based on." The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; and the term "some embodiments" means "at least some embodiments." Definitions of other terms will be given in the description below. It should be noted that the concepts of "first," "second," etc., mentioned in this disclosure are used only to distinguish different devices, modules, or units and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0032] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0033] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0034] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0035] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device. It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of this disclosure; other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0036] Before introducing the embodiments of this disclosure, the relevant terms involved in the embodiments of this disclosure are first defined as follows:

[0037] Smart contracts: A smart contract is an automated contract or program that executes on a blockchain. It contains predefined rules and logic to automatically execute operations defined in the contract when specific conditions are met. Smart contracts are a key feature of blockchain technology, enabling programmable and immutable contract execution in a decentralized manner.

[0038] Retrieval Augmented Generation (RAG) is a natural language processing technique that combines information retrieval and generative models. This method aims to improve the performance of generative models on specific tasks by retrieving relevant information from large knowledge bases and integrating this information into the generative model.

[0039] With the rapid development of healthcare, the Internet of Things, and financial information, the application of blockchain technology in these fields is gradually gaining recognition. Smart contracts, as decentralized applications within the blockchain, can complete transparent, immutable, and traceable information transmission and monetary transactions without third-party verification. However, smart contracts currently also face challenges such as malicious attacks and code vulnerabilities.

[0040] In related technologies, smart contract detection tools are typically used to inspect smart contracts to improve their security and discover potential code vulnerabilities. However, these tools rely on expert-defined rules, leading to high false positive and false negative rates as the number and complexity of smart contracts increase. Furthermore, the inconsistent formats and poor readability of reports from different tools prevent developers from promptly identifying potential vulnerabilities in smart contracts, thus increasing security risks.

[0041] Therefore, in order to solve the above problems, this disclosure first provides a multi-factor composite detection method for smart contracts, for example, Figure 1 This is an overall framework diagram of a multi-factor composite detection method for smart contracts provided as an example in this disclosure. Figure 1 As shown, the multi-layered composite detection method 100 for smart contracts may include a detection module 110, a verification module 120, and a report generation module 130. First, multiple detection tools are integrated into the detection module 110. In the detection module 110, multiple detection tools are used sequentially to perform multiple rounds of detection on the smart contract to be tested, obtaining multiple detection result files. Data analysis and processing are performed on the multiple detection result files to obtain an initial vulnerability list. Subsequently, in the verification module 120, a large language model is used to verify the initial vulnerability list, obtaining a verified vulnerability list and corresponding modification suggestions. Finally, in the report generation module 130, a large language model is used to perform natural language processing on the vulnerability list and modification suggestions to improve their readability.

[0042] For example, Figure 2 This is a flowchart illustrating a multi-factor composite detection method for smart contracts provided as an example in this disclosure. Figure 2 As shown, a multi-factor composite detection method for smart contracts may include the following steps:

[0043] Step S210: Classify the detectors of multiple detection tools in the detection module.

[0044] For example, although each detection tool contains multiple detectors, the differences between different detection tools are significant, and they have a large bias towards different vulnerability types. Therefore, by pre-compiling multiple detection tools, such as Slither, Mythril, and Securify, into the detection module, the problem of large differences between different detection tools can be solved, and a wider range of vulnerability types can be covered during the detection process, improving the comprehensiveness of the detection of potential risks to smart contracts.

[0045] For example, the detection module also provides a detection tool insertion function to expand the detection tools within the module. This allows users to add new detection tools to the module, enabling them to select and integrate customized detection modules suitable for the smart contracts under test according to their specific needs. This better adapts to specific development environments and security requirements, addressing the ever-emerging vulnerabilities and threats in the smart contract field.

[0046] Since the detectors in the detection tool have different focuses and target different specific vulnerabilities, in order to facilitate subsequent analysis and comparison of the detection result files generated by different detection tools, we can first classify all detectors in all detection tools in the detection module.

[0047] For example, detectors can be categorized according to the types of vulnerabilities they focus on. The types of vulnerabilities the detectors focus on are matched with pre-determined vulnerability types to be classified. If a detector focuses on a specific type of vulnerability, it is assigned to the category corresponding to that vulnerability type.

[0048] In this embodiment, the vulnerability types can be divided into the following 14 categories: reentrancy attack, integer overflow, access control, abnormal operation, service denial, type mismatch, Ethernet freeze, short address attack, Ethernet loss, call stack overflow, Tx.origin usage vulnerability, timestamp dependency, block parameter dependency, and transaction order dependency. The above 14 types of vulnerabilities and their corresponding detectors are categorized and integrated to obtain a classification set a. Classification set a may include detector names and corresponding vulnerability type information. For example, the detectors corresponding to reentrancy attack vulnerabilities are A1, A2, and A3, and the reentrancy attack vulnerability number is 1; the detectors corresponding to integer overflow vulnerabilities are B1 and B2, and the integer overflow vulnerability number is 2… The detectors corresponding to transaction order dependency are N1, N2, N3, and N4, and the access control vulnerability number is 14; then classification set a can be represented as: {1, A1, A2, A3}, {2, B1, B2}… {14, N1, N2, N3, N4}.

[0049] In practical applications, the above 14 vulnerability types can be added or removed based on the smart contract to be tested, allowing users to customize a testing module suitable for the smart contract to be tested according to their needs.

[0050] Detectors that do not focus on the above 14 types of vulnerabilities can be categorized separately.

[0051] By integrating multiple detection tools into the detection module and providing an entry point for new detection tools, the complexity of subsequently expanding to new detection tools is reduced, the maintenance cost of the detection module is lowered, and the characteristics of each detection tool are preserved to the greatest extent, thereby expanding the coverage of vulnerability detection.

[0052] Based on this, classifying the multiple detectors in the detection module not only provides a clearer understanding of the vulnerability types each detector focuses on, offering users more accurate and detailed information, but also allows for a direct comparison of the performance and coverage of different detectors. By comparing the results of vulnerabilities within the same category, the strengths and weaknesses of each detector and its applicable scenarios can be better evaluated. Furthermore, the new detection tool expansion entry point enhances the system's scalability, enabling users to select and integrate customized detection modules suitable for the smart contracts under test according to their specific needs.

[0053] Step S220: Perform unified data processing on multiple detectors.

[0054] First, multiple detection tools in the detection module are used sequentially to detect the source code of the smart contract to be tested, obtaining a detection result file for each tool. The detection result file can include the name of the triggered detector, the vulnerability description, and the location of the vulnerability. To facilitate standardized data processing of the detection result files, the format can be standardized to JSON.

[0055] Then, based on the detection results file, the detectors that detected the vulnerabilities are obtained, and the data of these detectors is processed in a unified manner. For detectors that are categorized separately, the detector name, the type of vulnerability they target, the description of the vulnerability, and the modification suggestions can be saved to the initial vulnerability list. For detectors in category set a, the detector name, the type of vulnerability they target, the description of the vulnerability, and the modification suggestions can be saved to the detection results file of the corresponding vulnerability type according to the 14 vulnerability types mentioned above.

[0056] Different detectors employ different static analysis techniques and rule sets, resulting in varying advantages in vulnerability detection. Therefore, using multiple detection tools to examine the smart contract under test can improve detection accuracy and reduce false positives and false negatives through cross-validation and result synthesis.

[0057] For example, Figure 3 Here is an exemplary flowchart of a detection module provided in this disclosure, such as Figure 3 As shown, the detection module includes multiple detection tools, such as detection tool A, detection tool B, and detection tool C. Based on the detection result files output by each detection tool, unified data processing and optimization processing are performed sequentially to obtain an initial vulnerability list.

[0058] Step S230: Select the best among multiple detectors of the same vulnerability type to obtain an initial vulnerability list.

[0059] First, for the detectors in the classification set a, the confidence level of the detectors corresponding to the above 14 vulnerability types can be assigned.

[0060] Specifically, confidence levels can be assigned in the following ways:

[0061] ① Obtain detector accuracy from tool developers: The accuracy of the detectors can be obtained directly from the tool developers and used as the confidence level for the corresponding detector. This method relies on the developers' objective evaluation of their tool's performance, providing a confidence value for each detector based on their professional experience.

[0062] ② Obtain the accuracy of the corresponding detector by testing the dataset: Prepare a dataset of smart contracts with known vulnerabilities, use the detector to test the smart contracts in the dataset, and assign the accuracy obtained from the test to the confidence level of the corresponding detector.

[0063] ③ Dynamically adjust the confidence level of the detectors through machine learning: An objective function can be set, and the confidence level of each detector can be adjusted based on the output of the objective function. Specifically, for detectors that detect vulnerabilities, the confidence level is increased; for detectors that do not detect vulnerabilities, the confidence level is decreased to minimize the output value of the objective function, thereby improving the accuracy of the detection module.

[0064] Specifically, the objective function can be expressed by the following formula (1):

[0065] Z = 1 - [x1, x2, ... x n ]·[y1,y2,…,y n ] T (1)

[0066] Where Z is the output value of the objective function; x n For each detector, the trigger state is set as follows: a detector that detects a vulnerability has a trigger state of 1, and a detector that does not detect a vulnerability has a trigger state of -1; y n The confidence level for each detector; n is the number of detectors included in each vulnerability type.

[0067] During the confidence assignment process, to ensure the correct calculation of matrix dimensions, if a certain vulnerability type does not have a corresponding detector, its trigger status and confidence level are both set to 0 by default.

[0068] After obtaining the trigger status and confidence level of each detector, the best detectors for the same vulnerability type are selected.

[0069] For example, the preferred treatment can be expressed by the following formula (2):

[0070] Q = [x1, x2, ... xn ]·[y1,y2,…,y n ] T (2)

[0071] Where Q is the output value of the optimization process; x n For each detector, the trigger state is set as follows: a detector that detects a vulnerability has a trigger state of 1, and a detector that does not detect a vulnerability has a trigger state of -1; y n The confidence level for each detector; n is the number of detectors included in each vulnerability type.

[0072] The existence of a vulnerability is determined by the sign of the output value of formula (2) above. If the output value is positive, the vulnerability exists, and the detector name, the targeted vulnerability type, the description of the vulnerability, and the modification suggestions for that vulnerability type are saved to the initial vulnerability list. If the output value is negative, the vulnerability does not exist, and the detector name, the targeted vulnerability type, the description of the vulnerability, and the modification suggestions for that vulnerability type are not saved to the initial vulnerability list.

[0073] Each vulnerability type is processed sequentially to obtain an initial vulnerability list.

[0074] Taking the reentrancy attack vulnerability type as an example, assuming that the reentrancy attack vulnerability type contains three detectors, namely A1, A2 and A3, with trigger states of -1, 1 and 1 respectively, and confidence levels of 0.3, 0.3 and 0.4 respectively, then the optimal processing output value is [-1,1,1][0.3,0.3,0.4]=-0.3+0.3+0.4=0.4, which is positive, indicating that the smart contract to be detected has a reentrancy attack vulnerability.

[0075] Based on this, by employing different confidence level assignment methods, the professional experience of the tool developers, the accuracy of actual test data, and the dynamic adjustment of machine learning are comprehensively utilized to evaluate the confidence level of each detector from multiple perspectives. An optimal selection strategy is adopted, comprehensively considering the performance and confidence levels of multiple detectors for the same vulnerability type to output the most confident result, thereby improving the accuracy of vulnerability existence assessment.

[0076] Step S240: The initial vulnerability list is verified in the verification module to obtain the verified vulnerability list.

[0077] For example, Figure 4 Here is an exemplary flowchart of a verification module provided in this disclosure, such as Figure 4As shown, the initial vulnerability list and the source code of the smart contract to be tested are input into the large language model. The large language model retrieves relevant information from pre-set knowledge bases a and b using the RAG method, integrates and learns the retrieved information, generates an attack contract, and simulates an attack on the source code of the smart contract to be tested to obtain a verified vulnerability list and modification suggestions.

[0078] In the verification module, the initial vulnerability list is verified using a large language model. Specifically, this involves generating an attack contract using the RAG-assisted large language model, then simulating an attack on the smart contract to be verified using the large language model. Based on pre-defined attack criteria, the simulated attack results are obtained, and each vulnerability in the initial vulnerability list is verified one by one to obtain a verified vulnerability list. In this embodiment, the large language model can be gpt-3.5-turbo-0613.

[0079] To ensure the quality of the simulated attack, knowledge base a and knowledge base b can be maintained in advance.

[0080] Knowledge base 'a' can include source code of smart contracts containing the aforementioned 14 vulnerability types, as well as corresponding attack contract source code, with at least 10 smart contract source codes and corresponding attack contract source codes for each vulnerability type. Knowledge base 'a' is used to provide the large language model with the necessary information obtained through the RAG method during the attack generation process, thereby reducing the error in the large language model's generation of attack contracts.

[0081] Knowledge base b can include the criteria for determining the validity of attacks corresponding to the 14 vulnerability types mentioned above. Knowledge base b is used to assist the large language model in providing the criteria for determining the validity of attacks when virtually executing source code contracts and attack contracts.

[0082] Maintaining these two knowledge bases provides the necessary background knowledge and verification criteria for simulated attacks, which helps improve the quality of attack contract generation and reduce potentially misleading information.

[0083] For example, to facilitate the subsequent generation of attack contracts, the content in knowledge base a can be divided into blocks, and each data block can be converted into a corresponding vector embedding block.

[0084] In one alternative approach, data can be segmented according to vulnerability type, so that each data block is used to represent a specific vulnerability type, which helps large language models to perform retrieval.

[0085] In one alternative approach, processing can be done in blocks according to smart contracts. Consider dividing each smart contract into blocks, with each data block representing an independent smart contract. This helps large language models better understand the structure and vulnerabilities of each smart contract.

[0086] In one alternative approach, the data can be segmented according to attack scenarios. Since knowledge base 'a' contains attack contracts, it can be segmented according to each attack scenario within those contracts. After segmentation, each data block represents a specific attack context, which helps the large language model understand the relationship between attacks and vulnerabilities.

[0087] The segmentation rules can be combined or adjusted according to specific circumstances. Choosing an appropriate segmentation strategy can enable vector embedding blocks to better capture information in knowledge base a, providing more targeted input for large language models.

[0088] For example, after maintaining knowledge base a and knowledge base b, attack commands can be generated.

[0089] The attack instruction module can be: "'You are a smart contract vulnerability verification assistant performing a question-and-answer task. Refer to the [Context] I am about to give you and answer the questions shown in [Question]. If you don't know how to answer, just say: "I don't know."'"

[0090] Question: {Question Template}

[0091] Context: {Content in the knowledge base that is highly similar to the context of the question}

[0092] Question template: "Given this smart contract {vulnerability}, generate a corresponding vulnerability exploit contract. Smart contract source code: {smart contract source code}"

[0093] Here, {} represents content that needs to be replaced according to different scenarios. {vulnerability} enumerates the vulnerabilities that exist in the initial vulnerability list in different verification rounds. The content of {content in the knowledge base that is highly similar to the question context} can be matched with the question in the question template and knowledge base a by the retrieval component. The embedded vector blocks corresponding to the vulnerability type mentioned in the question module, the smart contract source code of the vulnerability, and the attack contract mentioned in the question module can be obtained from knowledge base a.

[0094] Then, the generated attack commands are input into the large language model to obtain the attack contract.

[0095] Then, a simulated attack is performed on the smart contract to be verified using a large language model.

[0096] Specifically, a large language model is used to simulate two accounts existing on the blockchain. The source code of the smart contract to be tested is deployed in account A, and the generated attack contract is deployed in account B, with the criteria for the attack to succeed set. Finally, based on the attack criteria, the output of the large language model is obtained to determine whether the attack was successful.

[0097] If the attack is successful, it means that the smart contract under test has the corresponding vulnerability, and the corresponding information in the initial vulnerability list is retained; if the attack is ineffective, it means that the smart contract under test does not have the corresponding vulnerability, and the corresponding information in the vulnerability list needs to be removed.

[0098] In this step, each vulnerability in the vulnerability list is iterated over, and a corresponding attack contract is generated sequentially to obtain the corresponding virtual attack result. After iterating over each vulnerability in the vulnerability list, a verified vulnerability list and modification suggestions are obtained.

[0099] For newly added detection tools, the following information needs to be added to ensure that the large language model can validate its output detection result files. The added information may include:

[0100] ①If the vulnerability type that the newly added detection tool's detector is interested in already exists in the classification set a, then add the detector's name and confidence level to the corresponding vulnerability type.

[0101] ② If the vulnerability type that the detector in the newly added detection tool is interested in does not exist in the classification set a, then add the vulnerability type to the classification set a, and add the name and confidence level of the detector to the corresponding vulnerability type.

[0102] ③ If the vulnerability type targeted by the detector in the newly added detection tool does not exist in category set a, then 10 smart contract source codes and 10 corresponding attack contracts with that vulnerability type need to be added to knowledge base a. The basis for the validity of attacks with that vulnerability type needs to be added to knowledge base b.

[0103] Step S250: In the report module, perform language optimization processing on the vulnerability list and modification suggestions to obtain the target detection report.

[0104] In the report generation module, a large language model is used to process the verified vulnerability list and remediation suggestions into natural language, resulting in a target detection report. This natural language processing improves the readability of the vulnerability list and remediation suggestions, helping non-specialist readers understand vulnerability information more easily, thereby improving the efficiency and accuracy of the vulnerability remediation process.

[0105] Based on the above embodiments, in order to facilitate user use, this disclosure also provides a human-computer interaction interface, which may include: a detection tool management module, a file upload module, and a report browsing module.

[0106] The detection tool management module is used to manage and update the multiple detection tools built into the detection module. It also provides a detection tool insertion function to expand the scope with new detection tools to meet evolving security needs.

[0107] The file upload module is used to upload the source code of smart contracts with different vulnerability types from knowledge base A, along with the corresponding attack contract source code. It is also used to upload the evidence supporting the attack for different vulnerability types from knowledge base B. Furthermore, it is used to upload the source code of smart contracts to be tested.

[0108] The report browsing module is used to display target detection reports, presenting a list of vulnerabilities and remediation suggestions.

[0109] The one or more technical solutions provided in the exemplary embodiments of this disclosure integrate multiple detection tools to achieve multi-round comprehensive detection of smart contracts, thereby improving the comprehensiveness and accuracy of vulnerability detection. By performing data analysis and processing on multiple detection result files to obtain an initial vulnerability list, it is helpful to comprehensively consider the outputs of different detectors and improve the robustness of vulnerability identification. In the verification module, a large language model is used for vulnerability verification, which enables a more comprehensive analysis and understanding of vulnerabilities and provides more accurate verification results. Finally, the vulnerability list and modification suggestions are simplified using the large language model, improving the readability of the vulnerability list and modification suggestions.

[0110] Therefore, the multi-factor composite detection method for smart contracts provided in the exemplary embodiments of this disclosure can solve the technical problems of insufficient vulnerability coverage of a single detection tool and low vulnerability detection accuracy of a large language model by combining multiple vulnerability detection tools and a large language model.

[0111] Based on the above embodiments, this disclosure also provides a multi-factor composite detection method for smart contracts. Figure 5 This is a flowchart illustrating an exemplary method for multiple composite detection of smart contracts provided in this disclosure, as shown below. Figure 5 As shown, the method may include the following steps:

[0112] Step S510: Obtain the smart contract to be tested.

[0113] In this embodiment, it is necessary to obtain the source code of the smart contract to be tested for subsequent multi-layered composite testing.

[0114] Step S520: Use multiple testing tools to test the smart contract to be tested, and obtain the test result file generated by each testing tool.

[0115] In this embodiment, although each detection tool contains multiple detectors, the differences between different detection tools are significant, and they exhibit considerable bias towards different vulnerability types. Therefore, multiple detection tools, such as Slither, Mythril, and Securify, can be pre-built in. This allows for coverage of a wider range of vulnerability types and improves the comprehensive detection of potential risks to smart contracts.

[0116] This embodiment also provides a detection tool insertion function to add new detection tools. Users can select and integrate multiple detection tools suitable for the smart contract to be detected according to their specific needs, thereby better adapting to specific development environments and security requirements, and addressing the new vulnerabilities and threats constantly emerging in the smart contract field.

[0117] Multiple detection tools are used sequentially to detect the smart contract under test, and the detection result file corresponding to each detection tool is obtained. The detection result file may include the name of the detector triggered by the detection tool, the vulnerability description, the vulnerability type, the location of the vulnerability, and the modification suggestions.

[0118] Step S530: Perform data integration processing on multiple detection result files to obtain an initial vulnerability list.

[0119] Because the detection result files generated by multiple detection tools have inconsistent formats, data integration processing is required to facilitate subsequent verification by large language models. This data integration processing can include unified data processing and optimization processing. Unified data processing is used to classify the detection result files according to vulnerability type, while optimization processing is used to determine the detection results based on the accuracy of the detectors for each vulnerability type.

[0120] Step S540: Verify the initial vulnerability list using a large language model to obtain the target vulnerability list.

[0121] In this embodiment, an initial vulnerability list and the smart contract to be tested are input into a large language model. The large language model retrieves relevant information from a pre-set database using a RAG (Rapid Argumentation and Analysis) method, integrates and learns the retrieved information, generates an attack contract, and simulates an attack on the smart contract to be tested. The simulated attack results are used to determine if a vulnerability exists, thus verifying the accuracy of the initial vulnerability list. For existing vulnerabilities, their relevant information in the initial vulnerability list is retained. For non-existent vulnerabilities, their relevant information in the initial vulnerability list is removed. Each vulnerability in the initial vulnerability list is verified sequentially to ultimately obtain the target vulnerability list.

[0122] Based on this, in the exemplary embodiments of this disclosure, the smart contract to be tested is obtained, and multiple testing tools are used to test the smart contract to be tested, obtaining a test result file generated by each testing tool. Data integration processing is performed on the multiple test result files to obtain an initial vulnerability list. A large language model is used to verify the initial vulnerability list to obtain a target vulnerability list. The multi-layer composite testing method for smart contracts provided in this disclosure solves the technical problems of significant bias of a single testing tool towards different vulnerability types and low vulnerability detection coverage of testing tools by using multiple testing tools to test the smart contract to be tested. Using a large language model to verify the test results output by the testing tools can further reduce the false positive rate and false negative rate of vulnerabilities, thereby improving the security of smart contracts.

[0123] Based on the above embodiments, in another embodiment provided in this disclosure, the detection tool includes multiple detectors, and step S520 may specifically include:

[0124] Obtain information from multiple detectors and the vulnerability types that each detector focuses on;

[0125] Multiple detectors are categorized and processed according to vulnerability type;

[0126] Multiple testing tools are used to test the smart contract to be tested, and the test result files generated by each testing tool are obtained.

[0127] Save multiple detection result files to the vulnerability type corresponding to the detector.

[0128] In this embodiment, since the multiple detectors in the detection tool have different focuses and target different specific vulnerabilities, in order to facilitate subsequent analysis and comparison of the detection result files generated by different detection tools, all detectors in all detection tools in the detection module can be classified first.

[0129] Specifically, it allows access to all detectors from multiple pre-built and newly expanded detection tools, along with the vulnerability types each detector focuses on. Detectors are then categorized according to vulnerability type, grouping those focusing on the same vulnerability type into the same category.

[0130] Multiple detection tools are used to test the smart contract under test, and each tool generates its own detection result file. The result file can include the name of the triggered detector, the vulnerability description, and the location of the vulnerability. To facilitate standardized data processing, the result files can be formatted as JSON. The result files are then categorized into the vulnerability types corresponding to the detectors used.

[0131] Therefore, different detectors employ different static analysis techniques and rule sets, resulting in varying advantages in vulnerability detection. Thus, using multiple detection tools to test the smart contract under test can improve accuracy and reduce false positives and false negatives through cross-validation and result synthesis.

[0132] Based on the above embodiments, in another embodiment provided in this disclosure, classifying multiple detectors according to vulnerability type may specifically include:

[0133] Multiple primary vulnerability types are preset;

[0134] If the vulnerability type that the detector is looking at matches the first vulnerability type, the corresponding detector will be classified into the corresponding first vulnerability type.

[0135] If the vulnerability type that the detector is targeting does not match the first vulnerability type, the corresponding detector will be classified into the second vulnerability type.

[0136] In this embodiment, multiple first vulnerability types can be preset based on common vulnerability types. In this embodiment, the first vulnerability types may include: reentrancy attack, integer overflow, access control, abnormal operation, service denial, type mismatch, Ethernet freeze, short address attack, Ethernet loss, call stack overflow, Tx.origin usage vulnerability, timestamp dependency, block parameter dependency, and transaction order dependency.

[0137] In practical applications, the first vulnerability type can be added or removed based on the smart contract to be tested, allowing users to customize the first vulnerability type applicable to the smart contract to be tested according to their needs.

[0138] The system matches the vulnerability types that the detector is interested in with the first vulnerability type. If the vulnerability type that the detector is interested in is in the first vulnerability type, the detector is classified into the corresponding vulnerability type. If the vulnerability type that the detector is interested in is not in the first vulnerability type, the detector is classified separately into the second vulnerability type. This process is repeated for each detector, and all detectors are classified accordingly.

[0139] Therefore, classifying multiple detectors not only provides a clearer understanding of the types of vulnerabilities each detector focuses on, offering users more accurate and detailed information, but also allows for a more intuitive comparison of the performance and coverage of different detectors. By comparing results for vulnerabilities within the same category, the strengths and weaknesses of each detector and their applicable scenarios can be better evaluated.

[0140] Based on the above embodiments, in another embodiment provided in this disclosure, step S530 may specifically include:

[0141] Obtain the trigger status and confidence information of each detector in the first vulnerability type; wherein, if the detector detects a vulnerability, the trigger status is assigned a positive value, and if the detector does not detect a vulnerability, the trigger status is assigned a negative value;

[0142] Based on the triggering state and confidence information, calculate the optimal processing output value corresponding to each first vulnerability type;

[0143] If the output value is positive, the detection result file of the corresponding first vulnerability type is saved to the initial vulnerability list.

[0144] Obtain the detection result file for the second vulnerability type and save the detection result file for the second vulnerability type to the initial vulnerability list.

[0145] In this embodiment, data integration processing may include unified data processing and optimization processing.

[0146] Specifically, unified data processing can include:

[0147] Based on the detection results file, obtain the detectors that detected the vulnerabilities. For detectors in the second vulnerability type, the detection results file can be saved to the initial vulnerability list. For detectors in the first vulnerability type, a selection process is required before the detection results file can be included in the initial vulnerability list.

[0148] Specifically, the optimal processing may include:

[0149] Obtain the trigger status and confidence level information for each detector in the first vulnerability type. The trigger status indicates whether the detector detected a vulnerability during the detection process. If the detector detected a vulnerability, the detection status can be assigned a value of 1; if the detector did not detect a vulnerability, the detection status can be assigned a value of -1. The confidence level information indicates the accuracy of the detector in vulnerability detection.

[0150] After obtaining the trigger status and confidence information corresponding to each detector, the optimal processing is performed on the detectors corresponding to each vulnerability type in the first vulnerability type, and the optimal processing output value is obtained.

[0151] For example, the optimal processing can be represented by the above formula (2). The existence of a vulnerability is determined by the sign of the output value of the optimal processing. If the output value is positive, the vulnerability exists, and the detection result file corresponding to that vulnerability type is saved to the initial vulnerability list. If the output value is negative, the vulnerability does not exist, and the detection result file corresponding to that vulnerability type is not saved to the initial vulnerability list.

[0152] Each vulnerability type is processed sequentially to obtain an initial vulnerability list.

[0153] Based on this, a unified data processing and optimization strategy is adopted, which comprehensively considers the performance and confidence of multiple detectors under the same vulnerability type, and outputs the most confident result, thereby improving the accuracy of vulnerability existence judgment.

[0154] Based on the above embodiments, in another embodiment provided in this disclosure, obtaining the confidence information of each detector in the first vulnerability type may specifically include:

[0155] Obtain the officially released detection accuracy rate, and / or the detection accuracy rate obtained through dataset testing as the initial confidence level information;

[0156] The initial confidence information is adjusted using an objective function to obtain the adjusted confidence information;

[0157] The adjustment of initial confidence information using an objective function includes:

[0158] For detectors with a positive trigger state, increase the corresponding initial confidence information; for detectors with a negative trigger state, decrease the corresponding initial confidence information.

[0159] The objective function includes:

[0160] Z = 1 - [x1, x2, ... x n ]·[y'1,y'2,…,y' n ] T

[0161] Where Z is the output value of the objective function; x n For each detector, the trigger state is 1 for detectors that detect vulnerabilities and -1 for detectors that do not detect vulnerabilities; y' n The initial confidence level information for each detector; n is the number of detectors corresponding to each of the first vulnerability types.

[0162] In this embodiment, obtaining the officially released detection accuracy rate may include: directly obtaining the detector's accuracy rate from the tool developer and using this accuracy rate as the initial confidence level information for the corresponding detector. This approach relies on the developer's objective evaluation of the tool's performance, providing a confidence level based on professional experience for each detector.

[0163] In this embodiment, the detection accuracy obtained through dataset testing may include: preparing a dataset of smart contracts with known vulnerabilities, using a detector to test the smart contracts in the dataset, and assigning the accuracy obtained from the test as the initial confidence information of the corresponding detector.

[0164] During the assignment of initial confidence information, to ensure the correct calculation of subsequent matrix dimensions, if a vulnerability type does not have a corresponding detector, its trigger status and initial confidence information are both set to 0 by default.

[0165] In this embodiment, after obtaining the initial confidence information, the initial confidence information corresponding to the detector can be dynamically adjusted through machine learning to obtain the adjusted confidence information.

[0166] Specifically, an objective function can be set, and the initial confidence information of each detector can be adjusted based on the output of the objective function. For detectors that detect vulnerabilities, the initial confidence information is increased; for detectors that do not detect vulnerabilities, the initial confidence information is decreased to minimize the output value of the objective function, thereby improving the accuracy of the adjusted confidence information.

[0167] For example, the objective function can be expressed by the following formula (3):

[0168] Z = 1 - [x1, x2, ... x n ]·[y'1,y'2,…,y' n ] T (3)

[0169] Where Z is the output value of the objective function; x n For each detector, the trigger state is 1 for detectors that detect vulnerabilities and -1 for detectors that do not detect vulnerabilities; y' n The initial confidence level information for each detector; n is the number of detectors corresponding to each of the first vulnerability types.

[0170] Based on this, by adopting different confidence information assignment methods, the professional experience of the tool developers, the accuracy of actual test data, and the dynamic adjustment of machine learning are comprehensively utilized to evaluate the confidence information of each detector more comprehensively and from multiple perspectives.

[0171] Based on the above embodiments, in another embodiment provided in this disclosure, step S540 may specifically include:

[0172] The large language model generates the attack contract corresponding to each vulnerability in the initial vulnerability list through a search-enhanced RAG generation method.

[0173] In the large language model, an attack contract is used to launch a simulated attack on the smart contract to be tested, and the simulated attack results are obtained.

[0174] If the simulated attack succeeds, retain the detection result file for the corresponding vulnerability in the initial vulnerability list;

[0175] If the simulated attack fails, remove the detection result file for the corresponding vulnerability from the initial vulnerability list;

[0176] Iterate through and verify each vulnerability in the initial vulnerability list to obtain the target vulnerability list.

[0177] In this embodiment, a knowledge base 'a' can be pre-set. Knowledge base 'a' maintains the source code of smart contracts and the corresponding attack contracts for each vulnerability type, with at least 10 smart contract source codes and at least 10 corresponding attack contract source codes for each vulnerability type. Knowledge base 'a' is used to provide the large language model with the corresponding information obtained using the RAG method during the attack generation process, thereby reducing the error in the large language model's generation of attack contracts.

[0178] To facilitate the subsequent generation of attack contracts, the content in knowledge base a can be divided into blocks, and each data block can be converted into a corresponding vector embedding block.

[0179] In one alternative approach, data can be segmented according to vulnerability type, so that each data block is used to represent a specific vulnerability type, which helps large language models to perform retrieval.

[0180] In one alternative approach, processing can be done in blocks according to smart contracts. Consider dividing each smart contract into blocks, with each data block representing an independent smart contract. This helps large language models better understand the structure and vulnerabilities of each smart contract.

[0181] In one alternative approach, the data can be segmented according to attack scenarios. Since knowledge base 'a' contains attack contracts, it can be segmented according to each attack scenario within those contracts. After segmentation, each data block represents a specific attack context, which helps the large language model understand the relationship between attacks and vulnerabilities.

[0182] The segmentation rules can be combined or adjusted according to specific circumstances. Choosing an appropriate segmentation strategy can enable vector embedding blocks to better capture information in knowledge base a, providing more targeted input for large language models.

[0183] For example, after maintaining the knowledge base 'a', you can start generating attack commands.

[0184] The attack instruction module can be: "'You are a smart contract vulnerability verification assistant performing a question-and-answer task. Refer to the [Context] I am about to give you and answer the questions shown in [Question]. If you don't know how to answer, just say: "I don't know."'"

[0185] Question: {Question Template}

[0186] Context: {Content in the knowledge base that is highly similar to the context of the question}

[0187] Question template: "Given this smart contract {vulnerability}, generate a corresponding vulnerability exploit contract. Smart contract source code: {smart contract source code}"

[0188] Here, {} represents content that needs to be replaced according to different scenarios. {vulnerability} enumerates the vulnerabilities that exist in the initial vulnerability list in different verification rounds. The content of {content in the knowledge base that is highly similar to the question context} can be matched with the question in the question template and knowledge base a by the retrieval component. The embedded vector blocks corresponding to the vulnerability type mentioned in the question module, the smart contract source code of the vulnerability, and the attack contract mentioned in the question module can be obtained from knowledge base a.

[0189] Then, the generated attack commands are input into the large language model. The large language model retrieves relevant information from a pre-set knowledge base 'a' using the RAG method, integrates and learns the retrieved information, generates an attack contract, and simulates an attack on the source code of the smart contract to be detected to obtain the simulated attack results. In this embodiment, the large language model can use gpt-3.5-turbo-0613.

[0190] If the attack succeeds, it means that the smart contract under test has the corresponding vulnerability, and the detection result file of the corresponding vulnerability in the initial vulnerability list is retained; if the attack fails, it means that the smart contract under test does not have the corresponding vulnerability, and the detection result file of the corresponding vulnerability in the initial vulnerability list needs to be removed.

[0191] The large language model is used to traverse and verify each vulnerability in the vulnerability list, generate the corresponding attack contract in turn, simulate attack on the smart contract to be tested, verify one by one, and obtain the verified vulnerability list.

[0192] Based on this, by maintaining the knowledge base 'a', necessary background knowledge and verification criteria can be provided for simulated attacks, which helps improve the quality of attack contract generation and reduce potentially misleading information. The segmentation rules can be combined or adjusted according to specific circumstances; selecting an appropriate segmentation strategy allows vector embedding blocks to better capture information from the knowledge base 'a', providing more targeted input for large language models.

[0193] Based on the above embodiments, in another embodiment provided in this disclosure, in the large language model, an attack contract is used to launch a simulated attack on the smart contract to be detected, and the simulated attack result is obtained, which may specifically include:

[0194] Obtain the basis for the attack that is valid for each vulnerability in the initial vulnerability list;

[0195] Create a first account and a second account in the large language model;

[0196] Deploy the smart contract to be tested in the first account, and sequentially deploy the attack contract corresponding to each vulnerability in the initial vulnerability list in the second account;

[0197] A simulated attack was launched from a second account against the first account, and the results of the simulated attack were obtained based on the evidence that the attack was successful.

[0198] In this embodiment, a knowledge base b can be pre-configured, maintaining the criteria for attack validity corresponding to each vulnerability type. Knowledge base b assists the large language model in providing the criteria for determining attack validity when virtually executing source code contracts and attack contracts. The criteria for attack validity corresponding to each vulnerability can be obtained from knowledge base b using the RAG method.

[0199] In this embodiment, a first account and a second account existing on the blockchain are created using a large language model. The source code of the smart contract to be detected is deployed in the first account, and the generated attack contract is deployed in the second account. The criteria for the attack to be established are also set.

[0200] A simulated attack is launched from the second account to the first account, and the simulated attack results of the large language model are obtained based on the criteria for the attack to determine whether the attack is valid.

[0201] Based on this, by maintaining knowledge base b, it can be used to assist the large language model in providing a basis for judging the validity of attacks when virtually executing source code contracts and attack contracts. Simulating attacks on the smart contract to be tested within the large language model leverages its broad coverage to encompass more source code content within the smart contract to be tested, thereby discovering vulnerabilities and reducing the false negative rate.

[0202] Based on the above embodiments, in another embodiment provided in this disclosure, traversing and verifying each vulnerability in the initial vulnerability list to obtain the target vulnerability list may specifically include:

[0203] Iterate through and verify each vulnerability in the initial vulnerability list to obtain the verified vulnerability list;

[0204] A large language model is used to perform natural language processing on the verified vulnerability list to obtain the target vulnerability list.

[0205] In this embodiment, a large language model is used to simulate attacks on each vulnerability in the initial vulnerability list sequentially, verifying them one by one to obtain a verified vulnerability list. The large language model can also generate modification suggestions for each vulnerability in the verified vulnerability list using a RAG (Rapid Application Group) approach. Furthermore, the large language model can be used to process the verified vulnerability list and modification suggestions into natural language to obtain the target vulnerability list.

[0206] In this step, natural language processing can improve the readability of the vulnerability list and remediation suggestions, helping non-specialist readers to understand vulnerability information more easily, thereby improving the efficiency and accuracy of the vulnerability remediation process.

[0207] The one or more technical solutions provided in the exemplary embodiments of this disclosure integrate multiple detection tools to achieve multi-round comprehensive detection of smart contracts, thereby improving the comprehensiveness and accuracy of vulnerability detection. By performing data analysis and processing on multiple detection result files to obtain an initial vulnerability list, it is helpful to comprehensively consider the outputs of different detectors and improve the robustness of vulnerability identification. In the verification module, a large language model is used for vulnerability verification, which enables a more comprehensive analysis and understanding of vulnerabilities and provides more accurate verification results. Finally, the vulnerability list and modification suggestions are simplified using the large language model, improving the readability of the vulnerability list and modification suggestions.

[0208] Therefore, the multi-factor composite detection method for smart contracts provided in the exemplary embodiments of this disclosure can solve the technical problems of insufficient vulnerability coverage of a single detection tool and low vulnerability detection accuracy of a large language model by combining multiple vulnerability detection tools and a large language model.

[0209] The foregoing primarily describes the solutions provided by the embodiments of this disclosure from a methodological perspective. It is understood that, in order to achieve the above-mentioned functions, the apparatus corresponding to the methods of the exemplary embodiments of this disclosure includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0210] This disclosure embodiment can divide the server into functional units according to the above method example. For example, it can divide each function into a separate functional module, or it can integrate two or more functions into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0211] In the case of dividing each functional module according to its respective functions, an exemplary embodiment of this disclosure provides a multi-component detection device for smart contracts. This multi-component detection device for smart contracts can be a server or a chip applied to a server. Figure 6 This is a schematic block diagram illustrating the functional modules of a multi-factor composite detection device for smart contracts, provided as an example of this disclosure. Figure 6 As shown, the smart contract's multi-factor composite detection device 600 includes:

[0212] Data acquisition module 610 is used to acquire the smart contract to be tested;

[0213] The data processing module 620 is used to use multiple detection tools to detect the smart contract to be detected, and obtain the detection result file generated by each detection tool.

[0214] The data processing module 620 is also used to perform data integration processing on multiple detection result files to obtain an initial vulnerability list;

[0215] The data processing module 620 is also used to verify the initial vulnerability list using a large language model to obtain the target vulnerability list.

[0216] In another embodiment provided in this disclosure, the detection tool includes multiple detectors; the data processing module 620 is further configured to acquire the multiple detectors and the vulnerability types that the multiple detectors are interested in respectively; classify the multiple detectors according to the vulnerability types; use the multiple detection tools to detect the smart contract to be detected respectively, and obtain the detection result file generated by each detection tool; and save the multiple detection result files to the vulnerability type corresponding to the detector respectively.

[0217] In another embodiment provided in this disclosure, the data processing module 620 is further configured to preset multiple first vulnerability types; when the vulnerability type of the detector is interested in matches the first vulnerability type, classify the corresponding detector into the corresponding first vulnerability type; when the vulnerability type of the detector is interested in does not match the first vulnerability type, classify the corresponding detector into the second vulnerability type.

[0218] In another embodiment provided in this disclosure, the data processing module 620 is further configured to acquire the trigger status and confidence information of each detector in the first vulnerability type; wherein, when the detector detects a vulnerability, the trigger status is assigned a positive value, and when the detector does not detect a vulnerability, the trigger status is assigned a negative value; based on the trigger status and the confidence information, the optimal processing output value corresponding to each of the first vulnerability types is calculated; when the optimal processing output value is positive, the detection result file of the corresponding first vulnerability type is saved to the initial vulnerability list; the detection result file of the second vulnerability type is acquired, and the detection result file of the second vulnerability type is saved to the initial vulnerability list.

[0219] In another embodiment provided in this disclosure, the data processing module 620 is further configured to obtain the officially released detection accuracy rate, and / or the detection accuracy rate obtained through dataset testing as initial confidence information; adjust the initial confidence information using an objective function to obtain the adjusted confidence information; wherein, adjusting the initial confidence information using an objective function includes: for detectors with a positive trigger state, increasing the corresponding initial confidence information, and for detectors with a negative trigger state, decreasing the corresponding initial confidence information;

[0220] The objective function includes:

[0221] Z = 1 - [x1, x2, ... x n ]·[y'1,y'2,…,y' n ] T

[0222] Where Z is the output value of the objective function; x n For each detector, the trigger state is 1 for detectors that detect vulnerabilities and -1 for detectors that do not detect vulnerabilities; y' n The initial confidence level information for each detector; n is the number of detectors corresponding to each of the first vulnerability types.

[0223] In another embodiment provided in this disclosure, the data processing module 620 is further configured to: generate an attack contract corresponding to each vulnerability in the initial vulnerability list using the large language model through a search-enhanced generation (RAG) method; launch a simulated attack on the smart contract to be detected using the attack contract in the large language model, and obtain the simulated attack result; retain the detection result file of the corresponding vulnerability in the initial vulnerability list if the simulated attack is successful; remove the detection result file of the corresponding vulnerability in the initial vulnerability list if the simulated attack is unsuccessful; and traverse and verify each vulnerability in the initial vulnerability list to obtain the target vulnerability list.

[0224] In another embodiment provided in this disclosure, the data processing module 620 is further configured to obtain the attack validity criteria corresponding to each vulnerability in the initial vulnerability list; create a first account and a second account in the large language model; deploy the smart contract to be detected in the first account, and sequentially deploy the attack contract corresponding to each vulnerability in the initial vulnerability list in the second account; launch a simulated attack on the first account through the second account, and obtain the simulated attack result based on the attack validity criteria.

[0225] In another embodiment provided in this disclosure, the data processing module 620 is further configured to traverse and verify each vulnerability in the initial vulnerability list to obtain a verified vulnerability list; and to perform natural language processing on the verified vulnerability list using a large language model to obtain the target vulnerability list.

[0226] Figure 7 This is a schematic block diagram of a chip provided as an example of this disclosure. Figure 7 As shown, the chip 700 includes one or more (including two) processors 701 and a communication interface 702. The communication interface 702 can support the server in performing the data transmission and reception steps in the above method, and the processor 701 can support the server in performing the data processing steps in the above method.

[0227] Optional, such as Figure 7 As shown, the chip 700 also includes a memory 703, which may include read-only memory and random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM).

[0228] In some implementations, such as Figure 7 As shown, processor 701 executes corresponding operations by calling operation instructions stored in memory (which may be stored in the operating system). Processor 701 controls the processing operations of any terminal device; processor can also be called a central processing unit (CPU). Memory 703 may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory 703 may also include NVRAM. For example, in applications, memory, communication interfaces, and other components are coupled together via a bus system, which may include, in addition to a data bus, a power bus, a control bus, and a status signal bus, etc. However, for clarity, in... Figure 7 The general designated all buses as Bus System 704.

[0229] The methods disclosed in the embodiments of this disclosure can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0230] Exemplary embodiments of this disclosure also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this disclosure.

[0231] Exemplary embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to embodiments of this disclosure.

[0232] Exemplary embodiments of this disclosure also provide a computer program product, including a computer program, wherein, when executed by a processor of a computer, the computer program is used to cause the computer to perform a method according to an embodiment of this disclosure.

[0233] Figure 8 This is a structural block diagram of an exemplary electronic device provided in this disclosure. (See reference...) Figure 8The present invention describes a structural block diagram of an electronic device 800 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0234] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0235] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, output unit 807, storage unit 808, and communication unit 809. Input unit 806 can be any type of device capable of inputting information to electronic device 800. Input unit 806 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 807 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 808 may include, but is not limited to, disks and optical discs. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0236] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (PU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above. The various methods described above can all be implemented as computer software programs, which are tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809.

[0237] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0238] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0239] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0240] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0241] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0242] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0243] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this disclosure are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a terminal, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0244] Although this disclosure has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this disclosure. Accordingly, this specification and drawings are merely exemplary illustrations of the disclosure as defined by the appended claims and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this disclosure. It is obvious that those skilled in the art can make various alterations and modifications to this disclosure without departing from its spirit and scope. Thus, this disclosure is also intended to include any such modifications and modifications that fall within the scope of the claims of this disclosure and their equivalents.

Claims

1. A multi-factor composite detection method for smart contracts, characterized in that, The method includes: Obtain the smart contract to be tested; The smart contract to be tested is tested using multiple testing tools, and the test result files generated by each testing tool are obtained. Data integration processing is performed on multiple detection result files to obtain an initial vulnerability list; The initial vulnerability list is verified using a large language model to obtain the target vulnerability list; The detection tool includes multiple detectors; the process of using multiple detection tools to detect the smart contract to be detected, and obtaining a detection result file generated by each detection tool, includes: Obtain multiple detectors and the vulnerability types that each detector focuses on; The multiple detectors are categorized according to their vulnerability types. The smart contract to be tested is tested using the multiple testing tools respectively, and the test result file generated by each testing tool is obtained; Each of the aforementioned detection result files is saved to the vulnerability type corresponding to the detector. The step of using a large language model to verify the initial vulnerability list and obtain the target vulnerability list includes: The large language model generates the attack contract corresponding to each vulnerability in the initial vulnerability list through a search-enhanced RAG generation method. In the large language model, the attack contract is used to launch a simulated attack on the smart contract to be detected, and the simulated attack results are obtained; If the simulated attack succeeds, retain the detection result file of the corresponding vulnerability in the initial vulnerability list; If the simulated attack fails, remove the detection result file for the corresponding vulnerability from the initial vulnerability list; By iterating through and verifying each vulnerability in the initial vulnerability list, the target vulnerability list is obtained.

2. The method according to claim 1, characterized in that, The classification of the multiple detectors according to vulnerability type includes: Multiple primary vulnerability types are preset; If the vulnerability type that the detector is looking at matches the first vulnerability type, the corresponding detector will be classified into the corresponding first vulnerability type. If the vulnerability type that the detector is looking at does not match the first vulnerability type, the corresponding detector will be classified into the second vulnerability type.

3. The method according to claim 2, characterized in that, The process of integrating and processing multiple detection result files to obtain an initial vulnerability list includes: Obtain the trigger status and confidence information of each detector in the first vulnerability type; wherein, if the detector detects a vulnerability, the trigger status is assigned a positive value, and if the detector does not detect a vulnerability, the trigger status is assigned a negative value. Based on the triggering state and the confidence information, calculate the optimal processing output value corresponding to each of the first vulnerability types; If the output value of the optimization process is positive, the detection result file of the corresponding first vulnerability type is saved to the initial vulnerability list; Obtain the detection result file for the second vulnerability type and save the detection result file for the second vulnerability type to the initial vulnerability list.

4. The method according to claim 3, characterized in that, The step of obtaining the confidence information of each detector in the first vulnerability type includes: Obtain the officially released detection accuracy rate, and / or the detection accuracy rate obtained through dataset testing as the initial confidence level information; The initial confidence information is adjusted using an objective function to obtain the adjusted confidence information; The step of adjusting the initial confidence information using an objective function includes: For detectors with a positive trigger state, increase the corresponding initial confidence information; for detectors with a negative trigger state, decrease the corresponding initial confidence information. The objective function includes: Z= 1－[ x 1 ,x 2 ,…x n ]·[ y’ 1 ,y’ 2 ,…,y’ n ] T in, Z Output the value of the objective function; x n For each detector, the trigger state is 1 if the detector detects a vulnerability, and -1 if the detector does not detect a vulnerability. y’ n Initial confidence information for each detector; n The number of detectors corresponding to each first vulnerability type.

5. The method according to claim 1, characterized in that, The process involves using the attack contract within the large language model to launch a simulated attack on the smart contract to be detected, and obtaining the simulated attack results, including: Obtain the basis for the attack to be valid for each vulnerability in the initial vulnerability list; Create a first account and a second account in the large language model; The smart contract to be detected is deployed in the first account, and the attack contract corresponding to each vulnerability in the initial vulnerability list is deployed sequentially in the second account; A simulated attack is launched from the second account against the first account, and the result of the simulated attack is obtained based on the criteria for the attack to succeed.

6. The method according to claim 1, characterized in that, The process of traversing and verifying each vulnerability in the initial vulnerability list to obtain the target vulnerability list includes: Iterate through and verify each vulnerability in the initial vulnerability list to obtain the verified vulnerability list; The verified vulnerability list is processed using a large language model to obtain the target vulnerability list.

7. A multi-factor composite detection device for smart contracts, characterized in that, include: The data acquisition module is used to acquire the smart contracts to be tested; A data processing module is used to perform detection on the smart contract to be tested using multiple detection tools, and obtain detection result files generated by each detection tool; wherein, the detection tools include multiple detectors; the step of using multiple detection tools to detect the smart contract to be tested and obtaining detection result files generated by each detection tool includes: acquiring multiple detectors and the vulnerability types that the multiple detectors focus on; classifying the multiple detectors according to vulnerability types; using the multiple detection tools to detect the smart contract to be tested and obtaining detection result files generated by each detection tool; and saving the multiple detection result files to the vulnerability type corresponding to each detector. The data processing module is also used to integrate and process multiple detection result files to obtain an initial vulnerability list; The data processing module is further configured to verify the initial vulnerability list using a large language model to obtain a target vulnerability list, including: the large language model generating an attack contract corresponding to each vulnerability in the initial vulnerability list through a search-enhanced generation (RAG) method; using the attack contract in the large language model to launch a simulated attack on the smart contract to be tested, and obtaining the simulated attack results; if the simulated attack succeeds, retaining the detection result file of the corresponding vulnerability in the initial vulnerability list; if the simulated attack fails, removing the detection result file of the corresponding vulnerability in the initial vulnerability list; and iterating through and verifying each vulnerability in the initial vulnerability list to obtain the target vulnerability list.

8. An electronic device, characterized in that, include: processor; as well as, Memory for stored programs; The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method according to any one of claims 1-6.

Images