An on-chain automatic interaction probe ponzi contract identification method, system, terminal device and medium based on a large language model

Abstract

The application discloses a big language model-based on-chain automatic interaction probe ponzi contract identification method and system, terminal equipment and medium, and relates to the technical field of blockchain contract security identification. The method comprises the following steps: obtaining the source code of a contract to be identified and preprocessing the contract to obtain contract preprocessing data; based on the source code and the contract preprocessing data, a probe plan is generated through a preset constraint experiment planner; the probe plan is deployed in a test blockchain environment and executed to generate a probe execution track; and the probe execution track is subjected to ponzi contract feature identification to obtain an identification result. The application structurally analyzes relevant information generated in the real execution process of the smart contract, extracts key evidence reflecting the ponzi feature, realizes reproducible and interpretable judgment on whether the smart contract has the ponzi behavior, and breaks through the limitations of traditional static analysis and passive transaction analysis.

Description

Technical Field

[0001] This invention relates to the field of blockchain contract security identification technology, and in particular to a method, system, terminal device and medium for identifying Ponzi contracts based on a large language model and an on-chain automatic interactive probe. Background Technology

[0002] With the rapid development of blockchain technology, smart contracts are widely used in decentralized applications such as digital asset management. However, their immutable nature makes the security of their internal economic models crucial. Ponzi schemes often transfer profits through hidden fund allocation logic, with no explicit malicious behavior at the code level, posing a challenge to automated detection.

[0003] Existing Ponzi contract identification technologies are mainly divided into two categories: one is the static analysis method based on contract code, which can detect Ponzi schemes without executing the contract, but it relies solely on the potential capabilities of the code and is difficult to reflect real fund flows, making it easy to be obfuscated and evaded by the code; the other is the analysis method based on historical transaction data, which identifies risks through real transaction patterns, but it relies on rich transaction data, cannot adapt to newly deployed or less interactive contracts, and the interpretability of the analysis conclusions is weak.

[0004] Therefore, there is an urgent need for a method that does not require historical transaction data, can actively trigger contract fund flow logic, and can achieve reproducible and explainable identification, in order to fill the gap in existing technologies. Summary of the Invention

[0005] The technical problem this invention aims to solve is that, in the field of blockchain smart contract security identification, existing Ponzi contract identification methods rely on the potential capabilities of the code or on historical transaction data, failing to achieve efficient and interpretable Ponzi contract identification. Therefore, an effective solution is urgently needed to address the aforementioned technical problems.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a method for identifying Ponzi contracts using an on-chain automatic interactive probe based on a large language model, the method comprising: Obtain the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description. Based on the source code and the contract preprocessing data, a probe plan is generated through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model; The probe plan is deployed in a test blockchain environment, and the probe plan is executed to generate a probe execution trajectory; The probe's execution trajectory is subjected to Ponzi contract feature identification, and the Ponzi contract identification result of the contract to be identified is obtained through analysis.

[0007] In one implementation, the preset constraints of the experiment planner include cue word constraints and structured pattern constraints. The step of generating a probe plan through the experiment planner based on the source code and the contract preprocessing data includes: The planning objectives, participating roles, observation content, and interface call requirements of the probe plan are determined and integrated to obtain prompt word constraints, which are used to semantically constrain the planning behavior of the experiment planner. The structure of the probe plan's contract deployment configuration, participating role definition, observation content definition, and probe plan steps is determined and integrated to obtain a structured pattern constraint. The structured pattern constraint is used to impose a structured format constraint on the output content of the experiment planner. Based on the source code and the contract preprocessing data, and using the prompt word constraints and the structured pattern constraints as constraints of the large language model, the probe plan is generated by the experiment planner.

[0008] In one implementation, after generating the probe plan using the experiment planner based on the source code and the contract preprocessing data, the method further includes: Based on the source code and the contract preprocessing data, the probe plan is executable by a plan validator to obtain the probe plan verification result, wherein the plan validator is a rule-based, non-reasoning programmatic module. If the probe plan verification result is invalid or unexecutable, then based on the source code, the contract preprocessing data, and the error information in the probe plan verification result, and with the preset repair prompt word constraint as the constraint condition, the probe plan is locally adjusted by the experiment planner to obtain the repaired probe plan.

[0009] In one implementation, the contract preprocessing data includes an application binary interface and bytecode, and the deployment of the probe program in a test blockchain environment includes: Obtain remote procedure call information for the test blockchain environment, and encapsulate the remote procedure call information, the probe plan, the application binary interface, and the bytecode into a unified structured execution payload; Map the participating roles in the probe program to on-chain accounts in the test blockchain environment; The deployment transaction of the contract to be identified is completed based on the bytecode, the contract address is obtained, and an interactive contract instance is constructed.

[0010] In one implementation, the step of executing the probe plan to generate a probe execution trajectory includes: Each step in the probe plan is converted into an executable on-chain action; In the interactive contract instance, all on-chain actions are executed sequentially according to the steps of the probe plan, and observation information of each on-chain action is collected and recorded before and after its execution. The observation information of all actions on the chain is summarized into a structured probe execution trajectory.

[0011] In one implementation, the step of performing Ponzi contract feature identification on the probe execution trajectory and analyzing it to obtain the Ponzi contract identification result of the contract to be identified includes: Based on the probe's execution trajectory, the financial data of the contract to be identified is analyzed, wherein the financial data includes a sequence of fund flow events, statistical results of role income, and role fund dependency relationships; The financial data is subjected to Ponzi contract feature identification to determine whether a Ponzi funding dependence pattern exists, and the Ponzi contract identification results and the basis for the identification results are obtained.

[0012] In one implementation, analyzing the financial data of the contract to be identified based on the probe's execution trajectory includes: All transaction records in the probe execution trajectory are converted into standard fund flow events to obtain a fund flow event sequence; The financial behavior of each participating role in the financial flow event sequence is summarized, and the statistical results of the role's income are calculated. Based on the sequence of fund flow events and the statistical results of role income, the role fund dependency relationship between each role is summarized. The fund flow event sequence, the role income statistics, and the role fund dependency relationship are integrated into the financial data.

[0013] Secondly, embodiments of the present invention also provide an on-chain automatic interactive probe Ponzi contract identification system based on a large language model, the system comprising: The data preprocessing module is used to obtain the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description. The probe plan generation module is used to generate a probe plan based on the source code and the contract preprocessing data through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model. The probe plan execution module is used to deploy the probe plan in a test blockchain environment and execute the probe plan to generate a probe execution trajectory. The probe execution trajectory analysis module is used to identify Ponzi contract features on the probe execution trajectory and analyze the results to obtain the Ponzi contract identification results of the contract to be identified.

[0014] Thirdly, embodiments of the present invention also provide a terminal device, the terminal device including a memory, a processor, and an on-chain automatic interactive probe Ponzi contract identification program based on a large language model stored in the memory and executable on the processor. When the processor executes the on-chain automatic interactive probe Ponzi contract identification program based on a large language model, it implements the steps of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model as described in any of the above schemes.

[0015] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing an on-chain automatic interactive probe Ponzi contract identification program based on a large language model. When the on-chain automatic interactive probe Ponzi contract identification program based on a large language model is executed by a processor, it implements the steps of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model as described in any of the above schemes.

[0016] Beneficial Effects: This invention discloses a method, system, terminal device, and medium for identifying Ponzi contracts using on-chain automatic interactive probes based on a large language model, relating to the field of blockchain contract security identification technology. The method first obtains the source code of the contract to be identified and preprocesses it to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description. Subsequently, based on the source code and the contract preprocessing data, a probe plan is generated using an experiment planner, which is a pre-defined constrained large language model. Then, the probe plan is deployed in a test blockchain environment, and the probe plan is executed to generate a probe execution trajectory. Finally, Ponzi contract feature identification is performed on the probe execution trajectory, and the Ponzi contract identification result of the contract to be identified is obtained. This invention performs structured analysis on relevant information generated during the actual execution of smart contracts, extracts key evidence reflecting Ponzi characteristics, and achieves a reproducible and interpretable judgment on whether a smart contract exhibits Ponzi behavior, breaking through the limitations of traditional static analysis and passive transaction analysis. Attached Figure Description

[0017] Figure 1 The flowchart illustrates a specific implementation of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model, as provided in this embodiment of the invention.

[0018] Figure 2 This is a schematic diagram of the probe plan generation process for the on-chain automatic interactive probe Ponzi contract identification method based on a large language model provided in an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the automated on-chain interaction execution process of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model provided in an embodiment of the present invention.

[0020] Figure 4 This is a schematic diagram of the principle of the on-chain automatic interactive probe Ponzi contract identification device based on a large language model provided in this embodiment of the invention.

[0021] Figure 5 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0023] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0024] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0025] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0026] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0027] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] With the continuous development of blockchain technology, smart contracts, as a component of decentralized applications, have been widely used and popularized in fields such as digital asset management, cross-border payments, and decentralized finance. The characteristic of smart contracts lies in their ability to automatically execute operations such as fund allocation and business rule fulfillment according to preset code logic once deployed to a blockchain network, and they are difficult to modify or interfere with after deployment. This characteristic means that the security, rationality, and compliance of the economic model within a smart contract directly affect the financial security and legitimate rights of contract participants, thus imposing stringent requirements on risk identification and security verification of smart contracts.

[0029] In various smart contract-based application scenarios, a type of contract exhibiting Ponzi scheme characteristics frequently emerges, impacting the security and stability of the blockchain ecosystem. The operational logic of these contracts relies on subsequent participants' deposits to pay so-called returns to early participants, lacking any real value creation capability. More insidiously, these contracts typically employ meticulously designed fund allocation processes and multi-role interaction mechanisms to transfer profits and conceal risks. At the code level, they often lack explicit descriptions of malicious behavior or illegal operation instructions, relying solely on logical design to achieve Ponzi-like operation. This presents significant technical challenges for automated risk identification and compliance analysis of smart contracts.

[0030] To address the problem of identifying Ponzi contracts, two main technical approaches have emerged in the existing technological field. However, both have insurmountable limitations and cannot meet the comprehensive risk control requirements in practical applications. The first category is static analysis methods based on contract code. These methods focus on the source code of smart contracts, assessing risk through textual analysis without actually deploying or executing the contract. Early static analysis techniques primarily involved statistically analyzing the frequency of opcodes in the contract code, extracting feature vectors, and then using traditional machine learning models such as support vector machines and random forests for classification and identification to determine if the contract exhibited Ponzi scheme characteristics. Some solutions employed symbolic execution or constraint solving techniques to statically explore and analyze the reachability of potential fund flow paths within the contract code, attempting to discover abnormal fund flow patterns through logical deduction. In recent years, with the development of large language model technology, some existing technologies have begun to utilize large language models for semantic understanding and reasoning analysis of smart contract code. For example, this involves fine-tuning training on contract code samples from specific domains, or directly inputting contract code and prompts into the large language model, with the model outputting risk assessment results.

[0031] The advantage of this type of static analysis method lies in its efficiency and speed, requiring no contract deployment or execution, making it suitable for batch detection of large-scale contracts. However, its technical limitations are also significant: First, the analysis results are derived solely from the potential capabilities at the contract code level, failing to reflect the actual flow of funds and economic operation in the real-world on-chain interaction environment. Second, the implementation of Ponzi contracts is constantly evolving, and contract developers can circumvent the feature detection mechanism of static analysis models through code refactoring, logic obfuscation, and redundant code insertion. This results in insufficient robustness of static analysis methods when facing new or complex Ponzi contracts, leading to high false positive and false negative rates. Finally, static analysis methods struggle to deeply interpret the economic logic of contracts, and the analysis conclusions often lack causal interpretability, making them unreliable as a basis for compliance judgments.

[0032] The second category is analysis methods based on historical transaction data. These methods use real transaction records generated by contracts deployed on the blockchain network as their foundation. By mining information such as fund flow patterns and statistical characteristics contained in the transaction data, they can identify Ponzi schemes. Specifically, some technical solutions extract statistical features from blockchain transaction logs, such as contract balance changes, lifespan duration, number of inbound transactions, number of outbound transactions, and transaction frequency. They then use machine learning algorithms to build classification models to determine whether a contract is a Ponzi scheme. Other technical solutions organize transaction data into graph-structured data, such as heterogeneous transaction graphs, and use graph neural network models to learn the topological features and correlation patterns of contract transaction behavior, thereby achieving risk identification.

[0033] This type of analysis method based on historical transaction data can analyze the actual operational behavior of contracts and has a certain degree of accuracy in specific scenarios. However, this method also has technical shortcomings: First, the analysis process is essentially an inference of the correlation between past transaction results and lacks direct modeling and analysis of the causal mechanism of fund flows, resulting in weak interpretability of the analysis conclusions and difficulty in clearly defining the core causes of contract risks; Second, this type of method is highly dependent on the richness of historical transaction data and can only be applied to contracts that have been deployed and running for a long time and have generated a large number of transaction records. For newly deployed contracts or contracts with fewer interactions, due to the lack of sufficient transaction data, effective analysis cannot be carried out, making it difficult to meet the actual needs of early risk identification and warning for newly launched contracts; Third, this type of method is a passive analysis, which can only perform retrospective analysis of past transaction behavior and cannot actively trigger the potential fund flow logic of contracts, making it difficult to effectively uncover deeply hidden Ponzi scheme characteristics.

[0034] In summary, both existing mainstream technical approaches have significant limitations, and a comprehensive technical solution that can simultaneously combine contract code analysis and fund flow behavior verification has not yet been formed. From the perspective of practical application needs, on the one hand, it is necessary to move away from dependence on historical user transaction data, enabling analytical methods to be applicable to newly deployed contracts or contract scenarios with insufficient interaction data, achieving early risk identification in the initial stage of contract launch; on the other hand, it is necessary to overcome the limitations of purely static analysis, actively verifying and collecting evidence of the actual fund flow behavior of contracts in a controlled experimental environment, avoiding misjudgments caused by analysis based solely on the potential capabilities of the code; furthermore, it is necessary to address the insufficient interpretability of existing analytical methods, supporting risk assessment conclusions with clear evidence of fund flow, and providing a reliable basis for contract security audits.

[0035] Therefore, in the field of blockchain contract security identification technology, existing technologies cannot simultaneously meet the requirements of not relying on historical transaction data, actively triggering contract fund flow logic, and interpretable analysis conclusions. This leads to problems in the identification of Ponzi contracts, such as a lack of early warning, insufficient identification accuracy, and inadequate judgment criteria, making it difficult to effectively prevent the security risks posed by Ponzi contracts. A novel technical solution is urgently needed to address the shortcomings of existing technologies, fill the technological gap, and improve the security identification capabilities and risk control levels of blockchain smart contracts.

[0036] This embodiment provides a method for identifying Ponzi contracts using an on-chain automatic interactive probe based on a large language model, such as... Figure 1 As shown, the specific steps include the following: Step S100: Obtain the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description.

[0037] In this embodiment, the contract to be identified is a smart contract deployed on a blockchain network that can automatically execute fund allocation and business rules according to preset code logic. Specifically, it can be a Solidity language contract developed based on the Ethereum Virtual Machine (EVM) compatible standard, and its functions cover common application scenarios such as digital asset management and decentralized financial profit distribution. In this embodiment, the smart contract runs in the Ethereum Virtual Machine, but this invention is also applicable to other virtual machine environments compatible with smart contract execution.

[0038] Source code is the text of smart contract programs written in a high-level programming language compatible with the blockchain platform. Specifically, it can be contract source code conforming to the Solidity syntax specification, or it can be other publicly available smart contract development languages. Solidity's source code fully documents the contract's interface definitions, state variables, business logic, and fund transfer rules. A typical example is shown below: pragma solidity ^0.4.19; contract MyScheme { uint treeBalance; uint numInvestorsMinusOne; uint treeDepth; address[] myTree; function MyScheme() { treeBalance = 0; myTree.length = 6; myTree[0] = msg.sender; numInvestorsMinusOne = 0; } function getNumInvestors() constant returns (uint a) { a = numInvestorsMinusOne+1; } function() public payable { uint amount = msg.value; if (amount>=1000000000000000000) { numInvestorsMinusOne+=1; myTree[numInvestorsMinusOne]=msg.sender; amount-=1000000000000000000; treeBalance+=1000000000000000000; if (numInvestorsMinusOne<=2) { myTree[0].send(treeBalance); treeBalance=0; treeDepth=1; } } else if (numInvestorsMinusOne+1==myTree.length) {...} } } Preprocessing is the process of standardizing and converting the format of the contract source code. Specifically, it can be done by using a standard Solidity compiler to perform syntax verification and compilation optimization on the input source code, generating standardized data products required for the deployment and interaction of the corresponding contract.

[0039] Contract preprocessing data is a standardized compilation product used to support contract deployment, interface calls, and interactive execution. Specifically, it can include the Application Binary Interface (ABI) and contract bytecode.

[0040] The application binary interface is a standardized specification that describes the callable function interfaces, parameter types, and return value structures of smart contracts. It is used to implement function encoding and decoding during on-chain interactions. A typical example is as follows: {"abi":[{"constant":true,"inputs":[],"name":"getNumInvestors","outputs":[{"name":"a","type":"uint256"}],"payable":false,"stateMutability":"view","type":"fu nction"},{"inputs":[],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"payable":true,"stateMutability":"payable","type":"fallback"}]} Contract bytecode is a hexadecimal byte sequence generated by a compiler and executed directly in the Ethereum Virtual Machine. It fully carries all the business logic of the contract and is used for the deployment and operation of the contract in the blockchain environment.

[0041] In the specific implementation of this embodiment, the complete Solidity source code of the contract to be identified, input by the user, is first received. The source code undergoes formatting and syntax pre-validation, removing comments and irrelevant redundant information to ensure it meets the compiler's input requirements. Subsequently, a Solidity compiler matching the target blockchain version is invoked to compile the validated source code. Syntax validation is enabled during compilation; if syntax errors or compilation failures are found, the process is terminated, and the corresponding compilation error information is returned to the user, guiding them to correct the contract source code. After compilation, the ABI and bytecode are extracted from the compiled output and stored as contract preprocessing data. The contract source code and ABI will serve as input for the subsequent probe plan generation stage, while the bytecode will serve as input for the subsequent contract deployment stage, thus ensuring the consistency and controllability of data sources throughout the entire analysis process.

[0042] This embodiment uses standardized compilation preprocessing to provide a unified and compliant data foundation for subsequent full-process analysis, avoiding execution anomalies caused by differences in source code format or compilation.

[0043] Step S200: Based on the source code and the contract preprocessing data, generate a probe plan through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model.

[0044] In this embodiment, the experiment planner is a large language model with the ability to understand the semantics of contract code and can automatically generate on-chain interactive experiment schemes according to preset constraints. Specifically, it can be an open-source large language model or a closed-source commercial large language model that has been fine-tuned and trained with data from the smart contract field. Its function is to design interactive experiments that can trigger the contract fund flow logic based on the contract source code and ABI.

[0045] The probe program is a structured and executable experimental scheme used to guide the execution of on-chain interactive experiments. It fully defines the core contents such as contract deployment configuration, participating roles, interaction steps, and observation indicators, and can be directly parsed and run by the automated execution engine.

[0046] Preset constraints are a set of rules used to limit the semantic scope and structural format of the output content of a large language model. Specifically, they can include cue word constraints and structured pattern constraints to ensure that the generated probe plan not only meets the experimental objectives but also has strict executability.

[0047] like Figure 2 As shown in this embodiment, the probe plan generation process uses the contract source code and the preprocessed ABI as core inputs. After processing by a pre-defined constrained experiment planner, a standardized probe plan is output. Furthermore, plan verification and automatic repair mechanisms can be set to ensure the executability of the output results.

[0048] In the implementation process, the preprocessed contract source code and ABI data, along with preset constraint rules, are first input into the experiment planner. The experiment planner then performs a full semantic understanding of the contract source code, parsing the contract's business logic, callable interfaces, and core functions related to fund flow. It identifies key functionalities related to deposits, profit distribution, and withdrawals, and designs the overall framework for the interactive experiment based on this. Subsequently, guided by preset constraints, the experiment planner generates the full content of the probe plan, ensuring that the generated plan covers multi-participant role settings, a complete deposit, trigger, and withdrawal interaction process, and clearly defined observation metrics.

[0049] In this embodiment, the structured pattern constraints of the experiment planner are implemented through a predefined JSON Schema. JSON Schema is a specification language used to define JSON data structures, type constraints, and required fields. It can be used to limit the output format of structured data. This Schema clearly defines the overall structure, field types, and value constraints of the probe plan, as shown in Table 1.

[0050] Table 1:

[0051] This schema will serve as the target structure template for the content generated by the experiment planner. The model is required to strictly fill in the content according to the field definitions to ensure that the output probe plan has a unified structure that can be directly parsed by the subsequent execution engine.

[0052] This embodiment automatically generates probe plans using a constrained large language model, eliminating the need for manual test script writing and improving the automation and analysis efficiency of Ponzi contract identification.

[0053] In one implementation, the preset constraints of the experiment planner include prompt word constraints and structured pattern constraints. The step of generating a probe plan based on the source code and the contract preprocessing data specifically includes the following steps: Step S210: Determine the planning objectives, participating roles, observation content, and interface call requirements of the probe plan, and integrate them to obtain prompt word constraints. The prompt word constraints are used to semantically constrain the planning behavior of the experiment planner. Step S220: Determine the contract deployment configuration, participating role definition, observation content definition, and probe plan steps of the probe plan, and integrate them to obtain a structured pattern constraint. The structured pattern constraint is used to impose a structured format constraint on the output content of the experiment planner. Step S230: Based on the source code and the contract preprocessing data, and using the prompt word constraints and the structured pattern constraints as constraints of the large language model, the probe plan is generated through the experiment planner.

[0054] In this embodiment, prompt word constraints are a set of instructions used to semantically constrain the planning behavior of the experiment planner. Through explicit task rules, they limit the experimental design direction of the large language model and avoid generating irrelevant or non-executable content. Structured pattern constraints are structural templates used to constrain the output content of the experiment planner at the format level. Through predefined fields and hierarchical structures, they ensure that the content output by the model can be directly parsed and executed by the machine.

[0055] In this embodiment, a complete set of prompt constraints is first pre-constructed. This system consists of multiple sets of clearly directional instructions, which constrain the behavior of the experiment planner from different dimensions. The first part is the task objective constraint, which clarifies that the core output of the experiment planner is not to directly judge whether the contract is a Ponzi scheme, but to design a set of on-chain interactive experiments that can fully expose the contract's fund flow behavior. This guides the model to focus on experimental design rather than direct risk judgment, avoiding the model outputting unfounded subjective judgments. The second part is the experimental design constraint, which explicitly requires that the generated probe plan must set up multiple independent participant roles, and the experimental process must cover the key interactive behaviors of the entire lifecycle of smart contract fund flow, such as deposit, profit triggering, exit or monetization. This ensures that the designed experiment can fully trigger the core economic logic of the contract and avoid the omission of Ponzi scheme characteristics due to incomplete interaction processes. The third part outlines the observation requirements and constraints, explicitly requiring that the probe plan specify continuously monitored cash flow indicators and contract status indicators. These include changes in the overall contract balance, changes in the account balances of each participating role, and state variables related to the number of investors and profit distribution ratios within the contract. This ensures that sufficient evidence can be collected during subsequent execution, providing comprehensive data support for later analysis. The fourth part outlines interface and callability constraints, explicitly requiring that all interactive operations be designed based on actual function interfaces existing in the contract's ABI. The number and types of parameters in function calls must fully match the ABI definition, and operations involving fund transfers must comply with the payable attribute requirements of the contract functions. This semantically guarantees that the generated interactive steps have an executable basis.

[0056] Subsequently, a predefined, unified JSON Schema is used as a structured pattern constraint. This Schema is not used for post-generation validation, but rather serves as the target structural template for the content generated by the experiment planner, embedded in the prompts. The model is required to strictly adhere to the fields and structure defined in the Schema during generation, outputting the probe plan by filling in the template. This Schema provides a mandatory structural definition for the core components of the probe plan, specifically including five modules: contract deployment configuration, participant and monitoring address definition, observation indicator definition, experimental hypothesis, and experimental step sequence. Each step in the experimental step sequence must describe the interaction initiator role, interaction type, calling interface, parameter configuration, funding amount, and expected observation phenomena according to predefined fields, ensuring that each step has clear execution semantics. Through this structured pattern constraint, the model's generation space is strictly limited to a machine-parseable structural range, avoiding the generation of free text or unstructured descriptive content, thus guaranteeing the executability of the probe plan at the structural level.

[0057] Finally, the contract source code, ABI data, and the aforementioned completed prompt word constraints and structured schema constraints are input into the experiment planner. The experiment planner first performs semantic parsing on the contract source code, identifying the core business logic, callable functions, and key logic nodes related to fund flow. Then, guided by the prompt word constraints, it completes the overall design of the experiment plan, including setting participant roles, planning interaction processes, and defining observation indicators. At the same time, strictly following the format defined by the structured schema constraints, it organizes the designed experiment plan into a standardized probe plan and outputs it.

[0058] This embodiment employs a dual constraint mechanism—combining cue word constraints and structured pattern constraints—to explicitly position the large language model as an experiment planner. This allows it to focus on designing executable interactive experiments rather than directly assessing risks, ensuring that the probe plans output by the model both meet the experimental objectives of Ponzi scheme feature recognition and possess strict executability. Furthermore, this dual constraint mechanism enables controlled generation of the large language model, effectively preventing the model from generating illusory content and significantly improving the compliance and executability of the probe plans.

[0059] In one implementation, after generating the probe plan using the experiment planner based on the source code and the contract preprocessing data, the process further includes the following steps: Step S240: Based on the source code and the contract preprocessing data, the probe plan is executed by a plan validator to obtain the probe plan verification result, wherein the plan validator is a rule-based non-reasoning programmatic module; Step S250: If the probe plan verification result is invalid or unexecutable, then based on the source code, the contract preprocessing data, and the error information in the probe plan verification result, and with the preset repair prompt word constraint as the constraint condition, the probe plan is locally adjusted by the experiment planner to obtain the repaired probe plan.

[0060] In this embodiment, the plan validator is a programmatic verification module built based on preset rules. It does not rely on the reasoning ability of the large language model and can perform deterministic and automated verification of the executability of the probe plan, avoiding subsequent execution process failures due to errors in the content generated by the large language model.

[0061] In this embodiment, after the experiment planner outputs the probe plan, the probe plan, contract source code, and ABI data are input into the plan validator to initiate the executability verification process. The plan validator's verification process is divided into three levels. The first level is structural compliance verification, which verifies whether the overall structure of the probe plan conforms to the predefined JSON Schema convention, checks whether all required fields are complete and exist, and whether the data types of the fields meet the constraints. For array-type fields, it checks whether their element structure conforms to the specifications, ensuring that the probe plan can be parsed by the machine at the structural level. The second level is interface matching verification, which iterates through the sequence of experimental steps in the probe plan, checking whether the function name corresponding to each function call operation actually exists in the contract ABI, and whether the number and type of parameters of the function call completely match the definitions in the ABI. For operations involving fund transfer, it checks whether the corresponding function has the payable attribute, ensuring that all interactive operations have an executable basis at the interface level. The third level is semantic consistency verification, which checks whether the participating roles, address references, and parameter configurations defined in the probe plan are semantically consistent throughout the entire plan. For example, it checks whether the initiating role referenced in a step exists in the participant definition, and whether the observed metrics are actual state variables existing in the contract, ensuring that the plan content does not have semantic conflicts or reference errors. After completing the full-process verification, the plan validator outputs the probe plan verification results. If all verification items pass, the verification result is legal and executable; if there are any items that fail verification, the verification result is illegal and unexecutable, and clear error information is output simultaneously, including the error location, error type, error reason, and compliance requirements.

[0062] If the probe plan verification result is invalid or unexecutable, an automatic repair mechanism will be activated. The repair process is still completed by the experiment planner, but its input and generation space are strictly limited to avoid unnecessary modifications to the probe plan. The original probe plan, contract source code, ABI data, and explicit error messages output by the plan verifier are input into the experiment planner, along with specially designed repair prompt constraints. The repair prompt constraints require the model to follow three principles: First, only the necessary parts that caused the verification failure are modified, restricting any irrelevant changes to the valid steps that have passed verification, ensuring the integrity of the original experimental design of the probe plan; Second, the repaired probe plan still covers core interaction types such as deposit, trigger, and exit, restricting incomplete experimental processes due to repair, and ensuring the consistency of experimental objectives; Third, when the original interaction path is not feasible at the ABI level, the alternative interface or interaction method with the closest semantics and executable behavior in the ABI is selected first, restricting the arbitrary addition of interaction content unrelated to the experimental objectives. Guided by the above constraints, the experiment planner only makes local adjustments to the content corresponding to the error messages and outputs the repaired probe plan. After the probe plan is repaired, it can be re-entered into the plan validator for secondary verification until the verification result is legal and executable, ensuring that the probe plan that finally enters the execution phase is fully compliant.

[0063] like Figure 2 As shown, this embodiment employs a closed-loop mechanism of model generation, rule verification, and model constraint repair to ensure that the large language model always operates within a controlled range. Its responsibility is limited to the generation and repair of the probe plan, and it does not participate in verification or execution decisions, providing a reliable guarantee for the executability and reproducibility of the entire analysis process. Furthermore, the rule-based verification and constraint repair mechanism effectively solves the illusion problem of content generated by the large language model, ensuring the executability of the probe plan.

[0064] Step S300: Deploy the probe plan in the test blockchain environment and execute the probe plan to generate the probe execution trajectory.

[0065] In this embodiment, the test blockchain environment is a local isolated test environment used to simulate the operating mechanism of a real blockchain. Specifically, it can be a local Ethereum test node built on Anvil. Anvil is an open-source Ethereum local test node tool that can quickly build an isolated test environment that is fully compatible with the Ethereum mainnet. It has complete Ethereum Virtual Machine execution capabilities and supports full functions such as block time adjustment, account management, and transaction execution. It will not generate real on-chain transaction costs and will not have any impact on the mainnet environment.

[0066] The probe execution trajectory is a structured dataset that fully records the execution status, fund changes, and transaction results of the entire contract interaction experiment. It is the core data foundation for subsequent fund flow analysis and Ponzi scheme feature identification.

[0067] like Figure 3 As shown in this embodiment, the automated on-chain interaction execution process takes the probe plan, contract ABI and bytecode, and test environment RPC (Remote Procedure Call) information as input. After being processed by the automatic execution engine, it outputs a complete probe execution trajectory.

[0068] In the specific implementation process, the initialization of the test blockchain environment is completed first, the local Anvil test node is started, and a deterministic set of local accounts is generated. Subsequently, the automatic execution engine encapsulates the probe plan, contract ABI, bytecode, and remote procedure call (RPC) information of the local test node into a unified structured execution payload. This execution payload fully contains all the information required for an on-chain interaction experiment, enabling the execution engine to complete the entire process without additional external input.

[0069] After encapsulating the execution payload, a role mapping operation is performed first. The role symbols defined in the probe plan, such as the contract deployer owner and participants A, B, C, and D, are mapped one by one to deterministic on-chain accounts generated by the local test node. A unique on-chain address and corresponding private key are assigned to each role for subsequent transaction signing and sending. After role mapping is complete, based on the contract bytecode and the deployment configuration defined in the probe plan, a contract deployment transaction is sent to the local test node. After the node packages and confirms the transaction, the on-chain address of the deployed contract is extracted from the transaction receipt. Based on this address and the contract ABI, an interactive contract instance is constructed, completing the contract deployment in the test environment.

[0070] Subsequently, the execution engine executes the corresponding on-chain actions one by one according to the experimental step sequence defined in the probe plan. For each experimental step, the execution engine first parses the interaction type of the step. If it is a call type, the designated role account initiates a call transaction to the corresponding function of the deployed contract instance, carrying the corresponding call parameters and funds as defined in the step. If it is a transfer type, the designated role account initiates a direct transfer transaction to the contract address, triggering the contract's fallback or receive function logic. If it is an evm_increase_time type, the block time is adjusted through the interface provided by the local test node to meet the time-related triggering conditions such as time locks and reward cycles in the contract. The execution engine strictly follows the step sequence defined in the probe plan, without performing additional improvisation, ensuring that the execution results of the same probe plan are completely reproducible in the same environment.

[0071] Before and after each step, the execution engine collects and records complete observation information, including snapshots of the contract address and the balances of all monitored role accounts, snapshots of contract status indicators specified by the probe plan, and the execution results of the transactions, including whether the transactions were successful, the transaction hash, execution receipts, and error messages. All collected information is summarized into a structured probe execution trajectory according to the order of the execution steps, with a typical example shown below: {"probe_out":{"contract":{"address":"0xA51c1fc2f0D1a1b8494Ed1FE312d7C3a78Ed91C"},"addrs":{"owner":"0x39de5adF6F4ce6a8827279cffFb92266","A":"0x799797051812dc3A0107517c79087882794","B":"0x344CDdB6a900fa2b585dd299e03d12FA4293BC","C":"0x90F79b6E2c4f870365E785982E1f101E93b96","D":"0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65","contract":"0xA51c1fc2f0D1a1b8494Ed1FE312d7C3a78Ed91C"},"steps":[{"name":"A_invest_1eth","ok":true,"error":null,"txHash":"0x803ca9618a303bd3ffd655f1948f843d1d916ef9945eb214f97e7edd","balanceDiffWei":{"0x39de5adF6F4ce6a8827279cffFb92266":"1000000000000000000","0x799797051812dc3A0107517c79087882794":"-1000000000000000000","0x344CDdB6a900fa2b585dd299e03d12FA4293BC":"0","0x90F79b6E2c4f870365E785982E1f101E93b96":"0","0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65":"0","0xA51c1fc2f0D1a1b8494Ed1FE312d7C3a78Ed91C":"0"},"metrics":{"before":{"contract_balance_wei":"0","ts":1768290038,"getNumInvestors":"1"},"after":{"contract_balance_wei":"0","ts":1768290038,"getNumInvestors":"2"}}}]} This embodiment proactively triggers the contract fund flow logic in a local isolated environment to obtain full data of actual execution, eliminating the reliance on historical transaction data and enabling early identification of newly deployed contracts.

[0072] In one implementation, the contract preprocessing data includes an application binary interface and bytecode, and the deployment of the probe plan in a test blockchain environment specifically includes the following steps: Step S310: Obtain remote procedure call information of the test blockchain environment, and encapsulate the remote procedure call information, the probe plan, the application binary interface and bytecode into a unified structured execution payload; Step S320: Map the participating roles in the probe program to on-chain accounts in the test blockchain environment; Step S330: Based on the bytecode, complete the deployment transaction of the contract to be identified, obtain the contract address, and construct an interactive contract instance.

[0073] In this embodiment, the execution payload is a structured data packet encapsulating all the information required for the on-chain interaction experiment. It can be directly loaded and executed by the automatic execution engine without requiring additional external information input. The Remote Procedure Call (RPC) information is the connection configuration information used to enable data communication between the execution engine and the local test node. Specifically, it includes the node's RPC access address, port number, access credentials, etc., and is used by the execution engine to send transactions, query status, adjust block parameters, and perform other operations to the test node. An on-chain account is an account in the test blockchain environment with a unique address, capable of signing and sending transactions, and holding digital assets. Each account corresponds to a unique public and private key used for transaction signature verification, ensuring the legality and immutability of transactions.

[0074] This embodiment first obtains the Remote Procedure Call (RPC) information of the local test blockchain environment to verify the validity of the RPC connection and ensure that the execution engine can communicate normally with the local test node. Subsequently, the automatic execution engine encapsulates the verified RPC information, the validated probe plan, and the ABI and bytecode from the contract preprocessing data into a unified structured execution payload. This execution payload is organized in a standardized JSON format and consists of three modules: environment configuration, contract information, and probe plan. The environment configuration module stores the RPC connection information, the contract information module stores the contract ABI and bytecode, and the probe plan module stores the complete probe plan content. This unified encapsulation of all information required for an experiment ensures that the execution engine can complete the entire experiment execution process without any additional input after loading the execution payload.

[0075] Subsequently, the execution engine parses the probe plan in the execution payload, extracting all defined participating roles, including the contract deployer owner, participants A, B, C, and D, etc. Then, from the deterministic pre-generated account set provided by the local test node, it assigns a unique corresponding on-chain account to each participating role, establishing a one-to-one mapping between role symbols and on-chain addresses, and storing this mapping in the execution payload. Each assigned on-chain account is pre-allocated with sufficient test funds to meet the needs of deposit operations and related fee payments during the experiment. Furthermore, the generation and allocation of all accounts adopt deterministic rules to ensure that the mapping between roles and accounts remains completely consistent when the same probe plan is executed multiple times, guaranteeing the reproducibility of the experiment.

[0076] Subsequently, the execution engine constructs a contract deployment transaction based on the contract bytecode in the execution payload and the contract deployment configuration defined in the probe plan. The initiator of the deployment transaction is the on-chain account corresponding to the owner role defined in the probe plan. The transaction carries the contract bytecode and constructor parameters, and also carries the corresponding initial funds as defined in the deployment configuration. The execution engine signs the deployment transaction using the owner account's private key, and then sends the signed transaction to the local test node via the RPC interface. After verifying the transaction, the test node packages it into a new block, completing the contract deployment. The execution engine extracts the on-chain address of the deployed contract from the transaction receipt, and constructs an interactive contract instance based on the contract ABI. This contract instance can be directly used for subsequent function calls and interactive operations.

[0077] like Figure 3 As shown, this embodiment achieves automated deployment of the probe plan in the test environment through a standardized process of payload encapsulation, role mapping, and contract deployment, providing a standardized operational foundation for subsequent interactive execution. This standardized deployment process ensures consistency between contract deployment and environment configuration, providing a fundamental guarantee for the reproducibility of experimental results.

[0078] In one implementation, the step of executing the probe plan to generate the probe execution trajectory specifically includes the following steps: Step S340: Convert each step in the probe plan into an executable on-chain action; Step S350: In the interactive contract instance, execute all on-chain actions in the order of the probe plan, and collect and record the observation information of the on-chain actions before and after the execution of each on-chain action. Step S360: Summarize the observation information of all actions on the chain into a structured probe execution trajectory.

[0079] In this embodiment, on-chain actions are the executable transformations of experimental steps in the probe plan. They are deterministic operations that can be directly executed in the test blockchain environment. Each on-chain action corresponds to a unique experimental step and has clear execution semantics and operational rules. Observation information is the full amount of data used to record changes in the contract and account states during the experimental execution process, and it is the basic data unit for constructing the probe execution trajectory.

[0080] In this embodiment, the execution engine first iterates through and parses the sequence of experimental steps in the probe plan, converting each experimental step into a corresponding executable on-chain action. During the conversion process, the execution engine first reads the interaction type defined in the step and matches the corresponding execution logic according to the interaction type: for steps of the 'call' type, it is converted into a contract function call action, specifying the caller's account, target contract address, function name, parameter list, and amount of funds carried; for steps of the 'transfer' type, it is converted into a direct transfer action, specifying the transfer initiator's account, recipient's address, and transfer amount; for steps of the 'evm_increase_time' type, it is converted into a block time adjustment action, confirming the number of seconds to be advanced. Through this conversion process, the originally structured experimental steps are converted into deterministic operations that can be directly executed by local test nodes, ensuring that each step can be executed accurately.

[0081] Subsequently, the execution engine executes all transformed on-chain actions sequentially within the deployed contract instances, following the steps defined in the probe plan. During execution, the engine strictly adheres to the order of steps, only starting the next step after the previous one is completed. The order of steps cannot be adjusted, nor can any additional operations not defined in the probe plan be executed. Before each on-chain action, the execution engine first collects baseline state information, including the contract address and the fund balances of all monitoring role accounts, the current values ​​of all observation metrics defined in the probe plan, the current block height, and the block time. This baseline state information is then persistently stored. After completing the baseline state collection, the execution engine executes the corresponding on-chain action. If the action involves sending a transaction, it signs the transaction using the private key of the corresponding role account, sends it to the local test node, and waits for transaction packaging confirmation and receipt. If the action involves adjusting the block time, it calls the corresponding method of the node via the RPC interface to adjust the block time and waits for the new block to be generated. After the action is completed, the execution engine collects the status information after execution again, including a snapshot of the account and contract balance, the current value of the observed indicators, and the transaction execution results, including the transaction hash, execution status, related fee consumption, error information, etc., to complete the full information collection for a single step.

[0082] Subsequently, the execution engine summarizes and organizes the observation information collected before and after all steps according to the execution order, generating a structured probe execution trajectory. The probe execution trajectory is stored in a standardized format, with core content including contract deployment information, the mapping relationship between roles and on-chain accounts, and the execution record of all steps. Each step's execution record includes complete information such as step name, execution status, transaction hash, pre-execution baseline snapshot, post-execution status snapshot, balance difference data, indicator change data, and error information. This probe execution trajectory fully recreates the entire execution state of the interactive experiment. All data comes from the actual execution results of the local test node, without any subjective inferences, and can be directly used for subsequent fund flow analysis and Ponzi scheme feature identification.

[0083] like Figure 3 As shown, this embodiment achieves automated execution of the probe plan and full-process data recording through a standardized process of step transformation, sequential execution, and full snapshot collection, ensuring that the generated probe execution trajectory is complete, authentic, and reproducible. This embodiment, through strict sequential execution and full state snapshots, ensures that the execution trajectory fully reconstructs the actual fund flow behavior of the contract, providing a reliable data foundation for subsequent analysis.

[0084] Step S400: Perform Ponzi contract feature identification on the probe execution trajectory and analyze to obtain the Ponzi contract identification result of the contract to be identified.

[0085] In this embodiment, the identification of Ponzi contract features is based on the analysis of the real cash flow data in the probe execution trajectory, the analysis of the contract's profit distribution logic and capital dependence relationship, and the analysis process to determine whether the contract has Ponzi economic characteristics. Its core is to verify whether the contract has a core Ponzi operation mode in which the returns of early participants are supported by the deposits of subsequent participants.

[0086] The Ponzi contract identification result is a clear determination of whether a contract has Ponzi characteristics, as well as complete evidence of cash flow and analytical basis to support the conclusion, which can be directly used as a compliance reference for contract risk assessment.

[0087] In the specific implementation process, the full structured data of the probe execution trajectory is first acquired. The raw execution data is then parsed and standardized, and the transaction records executed step by step are uniformly converted into standardized fund flow event representations. Each fund flow event clearly records core information such as the interaction step number, participating roles, fund flow direction, fund amount, fund recipient, and transaction execution status, fully depicting the flow relationship of funds between participants and contracts. The typical results are shown in Table 2.

[0088] Table 2:

[0089] By standardizing and transforming cash flow events, the originally discrete execution trajectories are organized into clear and traceable cash flow sequences.

[0090] After completing the data collection of fund flow events, the fund flow data was aggregated and statistically analyzed from the perspective of participants. Based on the role information defined in the probe plan, the full fund behavior of each participating role in the entire interactive experiment was summarized, and the total investment amount, total recovery amount, and corresponding net profit of each role were calculated. This eliminated the randomness caused by single-step transactions and fully reflected the overall profit of roles with different participation orders throughout the entire experimental period. The typical statistical results are shown in Table 3. Table 3:

[0091] The aggregated statistical results in Table 3 visually present the differences in returns among different participating roles, providing a quantitative basis for the analysis of funding dependence.

[0092] Based on the above statistical analysis, we further reconstruct the capital dependence relationship among different participating roles, focusing on analyzing three core Ponzi scheme characteristics: The first is the source of early participants' profits, verifying whether their profits mainly come from the deposits of later participants; the second is the symmetry of profit distribution, verifying whether there is a significant asymmetry in profit distribution among roles with different participation orders, i.e., early participants can obtain profits, while later participants face principal losses; the third is the capital inflow situation of specific roles, verifying whether the contract creator or administrator address continuously receives risk-free capital inflows during multiple rounds of interaction.

[0093] By jointly analyzing the sequence of fund flow events and the statistical results of role-level returns, this study structurally verifies whether the contract exhibits a fund dependency pattern where subsequent deposits support earlier returns. If this pattern is verified, the contract is deemed to possess Ponzi scheme characteristics. Finally, the fund flow event sequence, role-level return statistical results, and fund dependency analysis conclusions are integrated into a complete structured analysis report. Based on actual execution data, the report provides an interpretable description of the contract's economic behavior, clearly stating whether the contract exhibits Ponzi scheme behavior, and providing complete fund flow evidence to support this conclusion.

[0094] This embodiment uses real execution data to identify Ponzi scheme features, and the judgment conclusion has complete interpretability and reproducibility, which greatly improves the reliability and persuasiveness of the identification results.

[0095] In one implementation, the step of identifying Ponzi contract features on the probe execution trajectory and analyzing the results to obtain the Ponzi contract identification result of the contract to be identified specifically includes the following steps: Step S410: Based on the probe execution trajectory, analyze the financial data of the contract to be identified, wherein the financial data includes a sequence of fund flow events, statistical results of role income, and role fund dependency relationships; Step S420: Perform Ponzi contract feature identification on the financial data, determine whether there is a Ponzi funding dependence pattern, and obtain the Ponzi contract identification result and the basis for the identification result of the contract to be identified.

[0096] In this embodiment, financial data is a quantitative dataset extracted from the probe execution trajectory, reflecting the contract's fund flow and profit distribution logic. It is the core analytical object for Ponzi scheme feature identification, specifically including three types of core data: fund flow event sequences, role profit statistics, and role fund dependency relationships. The Ponzi fund dependency model is the core economic characteristic of Ponzi contracts, specifically manifested in the contract's lack of real value creation capability. The profits of early participants come entirely or primarily from the funds deposited by later participants, and profit distribution is strongly correlated with the order of participation, exhibiting a clear characteristic of early entrants profiting and late entrants losing.

[0097] This embodiment first loads complete probe execution trajectory data, performs in-depth analysis and feature extraction on the raw execution data in the trajectory, and generates financial data for Ponzi scheme feature identification. First, it analyzes the step-by-step transaction records in the execution trajectory, extracting fund flow information for each interaction, generating a standardized fund flow event sequence, and fully recording the direction, amount, and time sequence of fund flow between different roles and contracts. Second, based on the fund flow event sequence, it performs aggregation statistics from the participant dimension, calculating the total investment, total recovery, and net profit for each participating role throughout the entire experimental period, generating role profit statistics, and quantitatively presenting the profit status of different participating roles. Finally, based on the fund flow event sequence and role profit statistics, it analyzes the correlation between the profits of different roles and fund inflows, reconstructs the fund dependency relationships between roles, clarifies the sources of profit for different roles, and generates role fund dependency data. Integrating these three types of data into complete financial data provides a comprehensive quantitative analysis foundation for subsequent Ponzi scheme feature identification.

[0098] Subsequently, the generated financial data was subjected to Ponzi scheme feature identification to verify whether the contract exhibited a Ponzi funding dependency pattern. First, based on role funding dependency data, the source of early participants' returns was verified. If there was a clear correlation between the returns of early participants and the deposits of later participants—that is, the deposits of later participants directly triggered the distribution of returns to early participants—then the contract was determined to possess core Ponzi funding dependency characteristics. Next, based on role return statistics, the symmetry of return distribution was verified. If roles with earlier participation orders received positive returns, while those with later participation orders generally suffered principal losses, and the return distribution showed a strong correlation with the participation order, then the contract was determined to possess a Ponzi scheme characteristic of asymmetrical return distribution. Simultaneously, based on the fund flow event sequence, it was verified whether the contract creator or a specific administrator role could continuously receive fund inflows throughout the entire interaction process without bearing the risk of principal loss. If such a risk-free return role existed, the contract was determined to exhibit typical Ponzi scheme management profit characteristics. The verification results of the above three types of characteristics are comprehensively judged. If the contract exhibits core characteristics of Ponzi scheme funding dependence, and is accompanied by asymmetrical profit distribution or risk-free profit for the manager, then the contract is determined to be a Ponzi scheme. Finally, a clear identification result is output, along with complete supporting evidence, including evidence of fund flow events, statistical data on role returns, and conclusions on funding dependence analysis, ensuring the identification result has complete interpretability.

[0099] This embodiment accurately identifies the Ponzi economic characteristics of contracts based on a comprehensive judgment of multi-dimensional financial data. The judgment conclusion is supported by sufficient evidence and is highly interpretable.

[0100] In one implementation, analyzing the financial data of the contract to be identified based on the probe's execution trajectory specifically includes the following steps: Step S411: Convert all transaction records in the probe execution trajectory into standard fund flow events to obtain a fund flow event sequence; Step S412: Summarize the financial behavior of each participating role in the financial flow event sequence and calculate the role's profit statistics; Step S413: Based on the fund flow event sequence and the role income statistics, summarize the role fund dependency relationship between each role; Step S414: Integrate the fund flow event sequence, the role income statistics, and the role fund dependency relationship into the financial data.

[0101] In this embodiment, a fund flow event is a standardized description of fund transfer behavior in a single on-chain interaction. It is the smallest data unit constituting a fund flow sequence and can clearly and unambiguously depict the direction and ownership of funds in a single interaction. Role profit statistics are a quantitative summary of the fund behavior of a single participating role throughout the entire interaction experiment cycle, intuitively reflecting the overall profit and loss situation of that role. Role fund dependency is a structured description of the correlation between profits and fund inflows among different participating roles, clearly revealing the underlying logic of contract profit distribution.

[0102] Specifically, the entire transaction record in the probe execution trajectory is first traversed, converting each discrete transaction record into a standardized fund flow event. During the conversion, core information such as the initiator, recipient, transfer amount, execution status, and execution time of the transaction is extracted. Combined with the semantics of the corresponding steps, the fund flow behavior is standardized and defined. For transactions where a user transfers funds to the contract, it is defined as a deposit event, clearly recording the depositing role, amount, and time. For transactions where the contract transfers funds to a user, it is defined as a profit distribution event, clearly recording the profit receiving role, distribution amount, and distribution trigger conditions. For direct fund flows between roles, it is defined as a peer-to-peer transfer event, clearly recording the transferring parties and the amount. Each fund flow event is assigned a unique event number, associated with the corresponding execution steps and transaction hash, ensuring traceability and verifiability. All converted fund flow events are arranged in chronological order of execution time to generate a complete fund flow event sequence, achieving a standardized characterization of the fund flow behavior throughout the contract's entire lifecycle.

[0103] Subsequently, based on the generated sequence of fund flow events, all fund flow events were aggregated and statistically analyzed using the participating roles as the dimension. For each participating role, all fund flow events were first traversed, and all events in which that role was the fund transferor were selected. The total investment amount for that role was calculated, including all fund outflows such as deposits into the contract and transaction fees. Then, all events in which that role was the fund receiver were selected, and the total recovery amount for that role was calculated, including all fund inflows such as profit distributions from the contract and principal returns. Finally, the net profit for that role was calculated by subtracting the total investment amount from the total recovery amount. The total investment, total recovery, and net profit results for all participating roles were summarized to generate standardized role profit statistics. These results can intuitively present the profit and loss differences of roles with different participation orders throughout the experiment, eliminating the randomness caused by single-step transactions and accurately reflecting the overall profit status of each role.

[0104] Subsequently, based on the sequence of fund flow events and the statistical results of role returns, the fund dependency relationships among various roles were analyzed and summarized. First, all return distribution events were located, clarifying the receiving role, the distribution amount, and the triggering conditions for each distribution, with a focus on whether the distribution was triggered by subsequent deposits from other roles. Then, a temporal correlation analysis was performed on return distribution events and deposit events to verify the source of funds for the distributions. If a return distribution to an early participant closely followed a subsequent deposit by a new participant, and the distribution amount and deposit amount showed a clear quantitative correlation, then the early participant's returns were determined to depend on deposits from subsequent participants. All return distribution events were analyzed one by one, summarizing all return-deposit relationships to generate a complete set of role fund dependency relationships. This clearly revealed the fund flow logic between different roles in the contract and verified whether the contract had a core operating model where subsequent deposits supported early returns.

[0105] Finally, the generated sequence of fund flow events, statistical results of role returns, and role fund dependencies are formatted and integrated to produce unified, standardized financial data. During the integration process, a correlation index is established between the three types of data, ensuring that the statistical results of role returns are traceable to the corresponding fund flow events, and that the role fund dependencies are traceable to the corresponding profit distribution events and deposit events, guaranteeing the full traceability and verifiability of the financial data. The integrated financial data will serve as the sole input for subsequent Ponzi scheme feature identification, ensuring that the identification process is entirely based on real, quantitative data and contains no subjective inferences.

[0106] This embodiment provides a comprehensive and traceable quantitative data foundation for Ponzi scheme feature identification through a standardized financial data extraction process, thereby improving the accuracy and reliability of the identification results.

[0107] The core technical concept of this invention is a smart contract economic behavior verification method based on a planning, execution, and analysis process. It automatically generates structured interaction probe plans through a large language model, completes contract interaction execution and fund flow evidence analysis in a controlled testing environment, and ultimately achieves interpretable identification of Ponzi contracts. Under the above core technical approach, various alternative solutions can be adopted for the specific implementation of each functional module. Such modifications and substitutions do not depart from the core technical concept of this invention and are all within the scope of protection of this invention.

[0108] In summary, this embodiment proposes a method for planning on-chain interaction experiments using a large language model under structural constraints. Unlike existing methods that directly utilize large language models for risk assessment or text classification, this method introduces the large language model as an interaction experiment planner. Guided by predefined structured constraints (Schema) and task instructions, it automatically generates a rigorously executable on-chain interaction probe plan, thereby enabling systematic exploration and analysis of smart contract behavior. Furthermore, this embodiment introduces a Ponzi contract analysis paradigm for automated on-chain interaction experiments, transforming Ponzi contract identification from traditional static analysis or historical behavior backtracking to experimental analysis based on real deployment and multi-participant interaction. By automatically executing the interaction plan in the local blockchain, it actively triggers the internal fund flow logic of the contract, obtaining reproducible on-chain execution evidence. In addition, this embodiment also analyzes and interprets the fund flow dependency relationships based on the multi-participant interaction results. By structuring the changes in fund flow generated during multi-role interactions, it analyzes the profit dependencies and distribution order among different participants, extracting key evidence reflecting Ponzi characteristics from the real execution results, achieving interpretable judgment of contract economic behavior, rather than simply relying on black-box model output.

[0109] like Figure 4 As shown in the figure, this embodiment of the invention provides an on-chain automatic interactive probe Ponzi contract identification system based on a large language model. The system includes: a data preprocessing module 10, a probe plan generation module 20, a probe plan execution module 30, and a probe execution trajectory analysis module 40.

[0110] Specifically, the data preprocessing module 10 is used to acquire the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data, wherein the contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description; the probe plan generation module 20 is used to generate a probe plan based on the source code and the contract preprocessing data through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model; the probe plan execution module 30 is used to deploy the probe plan in a test blockchain environment and execute the probe plan to generate a probe execution trajectory; the probe execution trajectory analysis module 40 is used to perform Ponzi contract feature identification on the probe execution trajectory and analyze it to obtain the Ponzi contract identification result of the contract to be identified.

[0111] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 5As shown, the terminal device includes a processor, memory, network interface, display screen, and temperature sensor connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a Ponzi contract identification method based on a large language model and on-chain automatic interactive probe. The display screen can be an LCD screen or an e-ink screen. The temperature sensor is pre-installed inside the terminal device to detect the operating temperature of the internal components.

[0112] Those skilled in the art will understand that Figure 5 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0113] In one embodiment, a terminal device is provided, including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs including instructions for performing operations as described in the embodiments of the methods above.

[0114] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0115] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

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

Claims

1. A method for identifying Ponzi contracts using on-chain automatic interactive probes based on a large language model, characterized in that, The method includes: Obtain the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description. Based on the source code and the contract preprocessing data, a probe plan is generated through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model; The probe plan is deployed in a test blockchain environment, and the probe plan is executed to generate a probe execution trajectory; The probe's execution trajectory is subjected to Ponzi contract feature identification, and the Ponzi contract identification result of the contract to be identified is obtained through analysis.

2. The method for identifying Ponzi contracts based on an on-chain automatic interactive probe according to claim 1, characterized in that, The preset constraints of the experiment planner include cue word constraints and structured pattern constraints. The generation of probe plans based on the source code and the preprocessed contract data by the experiment planner includes: The planning objectives, participating roles, observation content, and interface call requirements of the probe plan are determined and integrated to obtain prompt word constraints, which are used to semantically constrain the planning behavior of the experiment planner. The structure of the probe plan's contract deployment configuration, participating role definition, observation content definition, and probe plan steps is determined and integrated to obtain a structured pattern constraint. The structured pattern constraint is used to impose a structured format constraint on the output content of the experiment planner. Based on the source code and the contract preprocessing data, and using the prompt word constraints and the structured pattern constraints as constraints of the large language model, the probe plan is generated by the experiment planner.

3. The method for identifying Ponzi contracts based on a large language model on-chain automatic interactive probe according to claim 2, characterized in that, After generating the probe plan using the experiment planner based on the source code and the contract preprocessing data, the process further includes: Based on the source code and the contract preprocessing data, the probe plan is executable by a plan validator to obtain the probe plan verification result, wherein the plan validator is a rule-based, non-reasoning programmatic module. If the probe plan verification result is invalid or unexecutable, then based on the source code, the contract preprocessing data, and the error information in the probe plan verification result, and with the preset repair prompt word constraint as the constraint condition, the probe plan is locally adjusted by the experiment planner to obtain the repaired probe plan.

4. The method for identifying Ponzi contracts based on an on-chain automatic interactive probe according to claim 1, characterized in that, The contract preprocessing data includes the application binary interface and bytecode, and the deployment of the probe plan in a test blockchain environment includes: Obtain remote procedure call information for the test blockchain environment, and encapsulate the remote procedure call information, the probe plan, the application binary interface, and the bytecode into a unified structured execution payload; Map the participating roles in the probe program to on-chain accounts in the test blockchain environment; The deployment transaction of the contract to be identified is completed based on the bytecode, the contract address is obtained, and an interactive contract instance is constructed.

5. The method for identifying Ponzi contracts based on a large language model on-chain automatic interactive probe according to claim 4, characterized in that, The process of generating a probe execution trajectory by executing the probe plan includes: Each step in the probe plan is converted into an executable on-chain action; In the interactive contract instance, all on-chain actions are executed sequentially according to the steps of the probe plan, and observation information of each on-chain action is collected and recorded before and after its execution. The observation information of all actions on the chain is summarized into a structured probe execution trajectory.

6. The method for identifying Ponzi contracts based on an on-chain automatic interactive probe according to claim 1, characterized in that, The step of identifying Ponzi contract features on the probe execution trajectory and analyzing the results to obtain the Ponzi contract identification result of the contract to be identified includes: Based on the probe's execution trajectory, the financial data of the contract to be identified is analyzed, wherein the financial data includes a sequence of fund flow events, statistical results of role income, and role fund dependency relationships; The financial data is subjected to Ponzi contract feature identification to determine whether a Ponzi funding dependence pattern exists, and the Ponzi contract identification results and the basis for the identification results are obtained.

7. The method for identifying Ponzi contracts based on a large language model on-chain automatic interactive probe according to claim 6, characterized in that, The analysis of the financial data of the contract to be identified based on the probe's execution trajectory includes: All transaction records in the probe execution trajectory are converted into standard fund flow events to obtain a fund flow event sequence; The financial behavior of each participating role in the financial flow event sequence is summarized, and the statistical results of the role's income are calculated. Based on the sequence of fund flow events and the statistical results of role income, the role fund dependency relationship between each role is summarized. The fund flow event sequence, the role income statistics, and the role fund dependency relationship are integrated into the financial data.

8. A chain-based automatic interactive probe Ponzi contract identification system based on a large language model, characterized in that, The system includes: The data preprocessing module is used to obtain the source code of the contract to be identified and preprocess the source code to obtain contract preprocessing data. The contract to be identified is a blockchain smart contract, and the contract preprocessing data is used for contract deployment and contract interface description. The probe plan generation module is used to generate a probe plan based on the source code and the contract preprocessing data through an experiment planner, wherein the experiment planner is a pre-defined constrained large language model. The probe plan execution module is used to deploy the probe plan in a test blockchain environment and execute the probe plan to generate a probe execution trajectory. The probe execution trajectory analysis module is used to identify Ponzi contract features on the probe execution trajectory and analyze the results to obtain the Ponzi contract identification results of the contract to be identified.

9. A terminal device, characterized in that, The terminal device includes a memory, a processor, and an on-chain automatic interactive probe Ponzi contract identification program based on a large language model, which is stored in the memory and can run on the processor. When the processor executes the on-chain automatic interactive probe Ponzi contract identification program based on a large language model, it implements the steps of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an on-chain automatic interactive probe Ponzi contract identification program based on a large language model. When the on-chain automatic interactive probe Ponzi contract identification program based on a large language model is executed by a processor, it implements the steps of the on-chain automatic interactive probe Ponzi contract identification method based on a large language model as described in any one of claims 1-7.

Images