Blockchain network attack detection method based on semantic analysis

Abstract

This application provides a blockchain network attack detection method based on semantic analysis. It generates log-related control flow graphs and state transition rules through static analysis of smart contract source code, constructs structured log semantic sequences by jointly applying log parameters decoded using a binary interface, and executes the log-driven state machine sequence to verify constraints and detect attacks. This upgrades traditional log parsing from "parameter display" to "behavioral semantic reconstruction," solving the problem that existing technologies cannot recover state transition rules. Simultaneously, through data dependency pruning and formal rule generation, it considers both source code logic and runtime behavior, enabling early anomaly detection and precise attacker location for decentralized oracle network attacks, improving detection timeliness and proactive defense.

Description

Technical Field

[0001] This application relates to the field of blockchain information security, and in particular to a method for detecting blockchain network attacks based on semantic analysis. Background Technology

[0002] In the field of blockchain-based information security, it is necessary to monitor smart contract log data for network architecture. Specifically, smart contracts output logs through emit statements. These logs contain contract addresses, event topics, event data, timestamps, transaction hashes, etc. Logs naturally record runtime behavior, making them suitable for auditing, monitoring, and tracing. However, logs are encoded data that needs parsing, and "parameter values" alone do not equate to "behavioral semantics." Decentralized Oracle Networks (DONs) are used to provide off-chain data (such as weather data and stock prices) for smart contracts, enabling lending protocols, decentralized exchanges, and other applications to execute logic based on external data. DON is characterized by "real-time data dependence": data updates are frequent, and contracts are highly dependent on data accuracy. Once data becomes outdated, deviates from its intended purpose, is manipulated, or the aggregator malfunctions, it can lead to incorrect valuations and asset losses.

[0003] However, current information security monitoring methods have certain limitations. For example, mainstream blockchain explorers typically use the Application Binary Interface (ABI) to reverse engineer logs, decoding hexadecimal topics / data into "event name + parameter name + parameter value". This method is suitable for display, but it cannot recover "which states were updated internally within the contract when the event was triggered, which branch path was taken, and what the state transition conditions were." The two main directions of DON security detection include transaction analysis and program analysis. Transaction analysis uses transactions as the granularity, defining detection scripts / constraints (such as the relationship between collateral value and lending value) to verify and discover "unexpected price feeds / profitable paths" on the transaction sequence. However, because it uses transactions as the detection granularity and semantics / rules often require manual abstraction, its detection accuracy is limited. Program analysis, through static or symbolic execution, looks for improper DON usage and price manipulation paths, i.e., it detects price manipulation vulnerabilities starting from the source code of programs that utilize DON. Therefore, program analysis struggles to cover runtime factors such as market liquidity; transaction analysis struggles to cover the details of the contract's internal business logic.

[0004] Therefore, there is a need for a blockchain network attack detection method that can perform semantic analysis based on smart contract source code and its logs to improve the effectiveness and practicality of network attack monitoring. Summary of the Invention

[0005] The purpose of this application is to address at least one of the aforementioned technical deficiencies, particularly the lack of effectiveness and practicality in existing blockchain network attack monitoring.

[0006] Firstly, this application provides a method for detecting blockchain network attacks based on semantic analysis, the method comprising: Obtain the source code of the smart contracts and the original on-chain logs of the target network architecture; The target network architecture includes a decentralized oracle network; Semantic analysis is performed on the source code of the smart contract to generate a log-related control flow graph and determine the state transition rules corresponding to the log events; The target parameters are obtained by decoding the original log through the application binary interface, and a structured log semantic sequence is generated based on the target parameters and the state transition rules. The structured log semantic sequence is executed based on the log-driven state machine to determine network attack anomaly information.

[0007] As an optional implementation, the step of performing semantic analysis on the smart contract source code, generating a log-related control flow graph, and determining the state transition rules corresponding to log events includes: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

[0008] As an optional implementation, the step of performing semantic analysis on the smart contract source code, constructing an initial control flow graph, and locating log event-related variables includes: The source code of the smart contract is parsed using an intermediate representation; Identify the log event associated variables related to the event output statements and event parameters, and construct the initial control flow graph containing branch jump relationships; In the initial control flow graph, the read / write dependency chains of each log event associated variable and event parameter are determined.

[0009] As an optional implementation, the data dependency pruning includes: Based on the initial control flow graph, construct a temporary graph; Traverse each node in the temporary graph. If there is no data dependency reachable path from the current node to any of the log event association variables, then delete the node. Also, delete any residual nodes that are unreachable from the entry node.

[0010] As an optional implementation, the state transition rules can be generated in the following ways: Enumerate the feasible paths from the event trigger point to the state update point on the log-related control flow graph; Extract the assignment expressions and branch conditions of the corresponding state variables in each of the feasible paths; The state variables are mapped to configuration units in the preset form of the log-driven state machine.

[0011] As an optional implementation, the step of executing the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information includes: Based on the state transition process of the structured log semantic sequence, the preset state machine constraints are verified; When a state machine constraint violation is detected, a network attack exception message is output. The network attack anomaly information includes the abnormal path, abnormal state, trigger log location, and associated attacker address; Furthermore, based on the network attack anomaly information, alarm information and attack details are generated, and the risk control system and / or automated handling interface are triggered to execute the preset attack response process.

[0012] Secondly, this application provides a blockchain network attack detection device based on semantic analysis, comprising: The acquisition module is used to acquire the source code of smart contracts and raw on-chain logs of the target network architecture. The target network architecture includes a decentralized oracle network; The processing module is used to perform semantic analysis on the source code of the smart contract, generate log-related control flow graphs, and determine the state transition rules corresponding to log events. The processing module is further configured to decode the original log through the application binary interface to obtain the target parameters, and generate a structured log semantic sequence based on the target parameters and the state transition rules; The processing module is also used to execute the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information.

[0013] As an optional implementation, the processing module performs semantic analysis on the smart contract source code, generates a log-related control flow graph, and determines the specific method for the state transition rules corresponding to log events, including: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

[0014] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0015] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0016] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: Based on any of the above embodiments, this application takes smart contract source code and on-chain original logs as input, constructs an initial control flow graph through static analysis and locates log event-related variables, generates a control flow graph focusing on log semantics based on data dependency pruning, and then extracts branch paths to generate state transition rules. Simultaneously, it decodes log parameters through an application binary interface and binds them to a rule template to generate an executable structured log semantic sequence. This sequence is executed based on a log-driven state machine, verifying preset state machine constraints (such as price consistency, collateral ratio thresholds, etc.) in real time. When a constraint violation is detected, it automatically outputs the abnormal path, abnormal state, trigger log location, and associated attacker address, and links the risk control system to execute the handling process. This overcomes the limitation of traditional log parsing, which can only decode parameters, and achieves the reconstruction from "event description" to "state transition semantics," solving the shortcomings of transaction analysis in covering the internal logic of contracts and program analysis in integrating runtime factors. Through joint parsing of source code and logs, it captures real-time anomalies while preserving the accuracy of business rules, significantly improving the early warning capability for malicious data price feeding; combined with the attacker address location mechanism, it forms a closed-loop defense of detection, tracing, and handling, enhancing the security and reliability of decentralized oracle networks. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a semantic analysis-based blockchain network attack detection method provided in one embodiment of this application; Figure 2 A schematic diagram of a blockchain network attack detection system architecture based on semantic analysis provided for one embodiment of this application; Figure 3 This application provides a schematic diagram of a control flow graph and state transition rules in one embodiment. Figure 4 A pseudocode illustration of data dependency pruning provided for one embodiment of this application; Figure 5 This is a schematic diagram of the workflow of the joint parsing module provided in one embodiment of this application; Figure 6 This is a schematic diagram of the syntax and configuration of a log-driven state machine provided in one embodiment of this application; Figure 7 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] First, let's explain the key nouns and terms: 1. Smart Contracts: Software that runs on a blockchain and can automatically execute and enforce contract terms without third-party intervention. Smart contracts are created, run, and destroyed through transactions on the blockchain. They ensure the transparency, security, and reliability of contracts through the blockchain, providing an efficient, traceable, and verifiable way to handle various transactions.

[0021] 2. Smart Contract Logs: Event records output by the emit statement when a smart contract runs, including fields such as contract address, event topic, event data, timestamp, transaction hash, and gas.

[0022] 3. Application Binary Interface (ABI): This interface definition describes the signature and parameter encoding methods of contract functions / events, and is used to decode log topics / data.

[0023] 4. Decentralized Oracle Network (DON): A network system that provides off-chain data (such as prices, interest rates, and random numbers) for on-chain smart contracts. It is implemented by oracle nodes and a group of oracle-related smart contracts.

[0024] 5. Control Flow Graph (CFG): A directed graph that describes the basic blocks and branching relationships of a program.

[0025] 6. Data Dependency: The definition and usage relationships of program variables, taint propagation relationships, etc., used to determine which statements / branches will affect certain variables.

[0026] 7. Log-driven State Machine: A formal state machine model in which state transitions are driven solely by a log sequence; the log is the only input that triggers state changes.

[0027] 8. Log Semantics (Formal Semantics of Logs / Log Semantics): In this application, it refers to the formal description of "the state reflected by the log" and "the rules that cause state changes when the log is triggered (state transition rules)".

[0028] 9. State Machine Constraints: Invariants, preconditions, postconditions, threshold constraints, etc., given by business logic / security logic, used to detect anomalies / attacks and locate attackers.

[0029] First, let's analyze the role and risks of DON in on-chain business. DON is used to provide off-chain data (such as token prices) for smart contracts, enabling lending protocols, decentralized exchanges, etc., to execute logic based on external data. DON is characterized by "real-time data dependence": data updates are frequent, and contracts are highly dependent on data accuracy. Once the data expires, deviates, is manipulated, or the aggregator malfunctions, it may lead to incorrect valuations and asset losses. The structure and value of smart contract logs lie in the fact that smart contracts output logs through emit. The logs contain: contract address, event topics, event data, timestamps, transaction hashes, etc. The logs naturally record the runtime behavior trajectory, making them suitable for auditing, monitoring, and tracing. However, logs are encoded data that needs to be parsed, and "parameter values" alone do not equal "behavioral semantics."

[0030] Regarding smart contract log parsing and DON security testing, smart contract log parsing utilizes blockchain explorers. One feasible parsing method is ABI decoding. Specifically, current mainstream blockchain explorers typically use ABI to reverse-decode logs, decoding the hexadecimal topics / data into "event name + parameter name + parameter value". This method is suitable for display, but it cannot recover "which states were updated internally by the contract when the event was triggered, which branch path was followed, and what the state transition conditions were".

[0031] DON's two main security testing approaches include transaction analysis and program analysis: Transaction analysis identifies anomalous patterns in price changes within a transaction sequence, such as oracle manipulation and pinch trading attacks. One feasible implementation defines detection scripts / constraints (e.g., the relationship between collateral value and lending value) at the transaction granularity, verifying and discovering "unexpected price feeds / profitable paths" on the transaction sequence. Similar to this application, both use formal constraints / rules to detect DON-related risks; however, this implementation uses transactions as the detection granularity, and the semantics / rules often require manual abstraction. This application focuses on "log semantics + log-driven state machine," emphasizing the automatic extraction of state transition rules corresponding to logs from the source code, and achieving finer-grained, earlier detection and tracing at the log level.

[0032] Program analysis uses static or symbolic execution to identify paths to misuse of DON and price manipulation. One feasible implementation involves detecting price manipulation vulnerabilities by analyzing the source code of programs that exploit DON.

[0033] Similar to this application, both use program analysis methods to obtain partial intermediate results of the code for detection. However, this feasible program analysis scheme starts from the perspective of code vulnerabilities, rather than using "log semantics" as a bridge to uniformly characterize "source code control flow / data dependencies + runtime log sequence + formal verification".

[0034] In summary, both approaches have their limitations: program analysis struggles to cover runtime factors such as market liquidity; transaction analysis struggles to cover the details of the contract's internal business logic. This application combines the advantages of both methods, proposing a composite analysis approach.

[0035] In summary, the technical problems that this application is expected to solve include at least the following aspects: Existing log parsing methods can only "decode parameters" but cannot recover "state transition rules," resulting in the inability to reconstruct the semantics of contract execution using logs. Existing blockchain explorers / log parsing methods typically rely on the ABI to decode topics / data into event names and parameter values, but cannot know the control flow path, variable update relationships, and data dependencies corresponding to the event in the source code. Therefore, it is impossible to build a verifiable model of "how and why the state changes" from the logs.

[0036] For attacks triggered by malicious / abnormal data sources in DON (such as price oracles), existing methods relying solely on "transaction analysis" or "program analysis" struggle to detect them promptly and accurately. DON-related attacks often depend on both on-chain business logic (staking, lending, liquidation, exchange, etc.) and external runtime data (prices, liquidity, etc.) and their real-time changes. Existing methods, if only performing static program analysis, struggle to cover runtime triggers such as "market liquidity and real-time price deviations"; if only performing transaction-level analysis, they struggle to capture the details and early signs of "the business logic of the contract's internal state machine being compromised."

[0037] When a malicious data source / abnormal state is detected, how to further locate the "attack transaction and attacker address" from the logs for real-time handling is required: simply detecting anomalies is not enough for defense. It is necessary to further identify which addresses are profiting in the abnormal window and triggering key state transitions from the log-driven state changes, so as to implement blacklisting, preemptive hedging, and other measures.

[0038] This application aims to provide a method for automatically extracting "control flow and data dependency information corresponding to logs" from smart contract source code and generating "log state transition rules," making the logs not only readable but also executable and verifiable. Upon detecting anomalies, a technical solution can be used to further locate attack transactions and attacker addresses based on log semantics, facilitating rapid response.

[0039] Therefore, the technical concept of this application lies in taking smart contract source code and on-chain raw logs as input, constructing an initial control flow graph through static analysis and locating log event-related variables, generating a control flow graph focused on log semantics based on data dependency pruning, and then extracting branch paths to generate state transition rules. Simultaneously, by applying a binary interface to decode log parameters and binding them to rule templates, an executable structured log semantic sequence is generated. This sequence is executed based on a log-driven state machine, verifying preset state machine constraints (such as price consistency, collateral ratio thresholds, etc.) in real time. When a constraint violation is detected, the application automatically outputs the abnormal path, abnormal state, triggering log location, and associated attacker address, and links the risk control system to execute the handling process. This overcomes the limitation of traditional log parsing, which can only decode parameters, and achieves the reconstruction from "event description" to "state transition semantics," solving the shortcomings of transaction analysis in covering the internal logic of contracts and program analysis in integrating runtime factors. By jointly analyzing source code and logs, real-time anomalies can be captured while preserving the accuracy of business rules, significantly improving the early warning capability for malicious data price feeds; combined with attacker address location mechanisms, a closed-loop defense of detection, tracing, and handling is formed, enhancing the security and reliability of decentralized oracle networks.

[0040] The following describes in detail the method provided in this application based on corresponding implementation methods in some practical application scenarios. This application takes the source code of the DON-related smart contract and the original logs generated during its operation as input. Through static analysis and joint log parsing, it automatically constructs a formal semantic model of a "log-driven state machine" and executes state machine constraints on this model to detect: business logic violation paths caused by malicious / abnormal data price feeds (pre-attack signs or attacks in progress); and attacker addresses and related transactions that trigger anomalies and profit.

[0041] It should be noted that this application may involve some concepts related to "transaction", "business", "market", etc., but these concepts are intended to provide specific explanations of the blockchain network attack detection solution based on actual application scenarios.

[0042] In essence, the principle of this application lies in generating log-related control flow graphs and state transition rules through static analysis of smart contract source code. This is combined with log parameters decoded using a binary interface to construct a structured log semantic sequence. Finally, the execution sequence of the log-driven state machine is used to verify constraints and detect attacks. This upgrades traditional log parsing from "parameter display" to "behavioral semantic reconstruction," solving the problem that existing technologies cannot recover state transition rules. Simultaneously, through data dependency pruning and formal rule generation, it considers both source code logic and runtime behavior, enabling early anomaly detection and precise attacker location for decentralized oracle network attacks, thus improving detection timeliness and proactive defense.

[0043] Therefore, the underlying mechanism of this application is still based on data processing and data analysis based on the principles of blockchain technology, and this application should not be understood as an intellectual activity or business rule.

[0044] Figure 1 A flowchart illustrating a semantic analysis-based blockchain network attack detection method provided in one embodiment of this application, and, as... Figure 2 As shown, Figure 2 This is a schematic diagram of a blockchain network attack detection system architecture based on semantic analysis provided in one embodiment of this application. The following is in conjunction with... Figure 2 The provided business module architecture, for Figure 1 The method shown will be explained in detail.

[0045] This application provides a method for detecting blockchain network attacks based on semantic analysis, the method comprising: S101. Obtain the source code of the smart contract and the original on-chain logs of the target network architecture; The target network architecture includes a decentralized oracle network; This step is implemented through the data acquisition module, which obtains the source code, compilation artifacts (including ABI), and raw on-chain log data of the target DON smart contract (which can be pulled by block height, time window, and transaction hash). Before proceeding with subsequent data analysis and processing, the environment initialization module can be used to initialize the syntax of the log-driven state machine, the basic configuration unit (state storage structure), and the execution engine environment (e.g., formal execution / symbolic execution engine).

[0046] S102. Perform semantic analysis on the source code of the smart contract, generate a log-related control flow graph and determine the state transition rules corresponding to the log events; This step is implemented through a semantic mining module, which performs static analysis on the source code, constructs a control flow graph (CFG), prunes data dependencies based on log event parameters, extracts critical paths related to logs, and generates state transition rules for each type of log event. For further details, please refer to [link to relevant documentation]. Figure 3 , Figure 3 The diagram below illustrates the control flow graph and state transition rules provided in one embodiment of this application, showing the workflow of the semantic mining module. The original control flow graph includes nodes 1-6, but only nodes 1, 3, 5, and 6 are associated with the log. Therefore, the state transition rules can be determined based on the data association relationships between nodes 1, 3, 5, and 6, which will be described in detail below.

[0047] As an optional implementation, the step of performing semantic analysis on the smart contract source code, generating a log-related control flow graph, and determining the state transition rules corresponding to log events includes: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Furthermore, the step of performing semantic analysis on the smart contract source code, constructing an initial control flow graph, and locating log event-related variables includes: The source code of the smart contract is parsed using an intermediate representation; Identify the log event associated variables related to the event output statements and event parameters, and construct the initial control flow graph containing branch jump relationships; In the initial control flow graph, the read / write dependency chains of each log event associated variable and event parameter are determined.

[0048] By parsing the source code using intermediate representations, event output statements and associated variables are identified, an initial control flow graph containing branching relationships is constructed, and the read / write dependency chain between log event associated variables and event parameters is determined. This accurately associates log events with contract internal state variables, providing an accurate input basis for data dependency pruning and ensuring that subsequently generated log-related control flow graphs fully cover log semantic dependency paths.

[0049] Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Furthermore, the data-dependent pruning includes: Based on the initial control flow graph, construct a temporary graph; Traverse each node in the temporary graph. If there is no data dependency reachable path from the current node to any of the log event association variables, then delete the node. Also, delete any residual nodes that are unreachable from the entry node.

[0050] Please see Figure 4 , Figure 4 This is a pseudocode illustration of data dependency pruning provided in one embodiment of this application. For the data dependency pruning CFG part, the input is CFG and the log variable set LogV. The output is the pruned CFG (PrunedCFG). It can be described by the following process: Copy the original CFG to obtain a temporary graph; For each node n: If there is no data dependency reachable path from node n to any log variable v, then delete n; After deletion, if there are nodes unreachable from the entry point, delete them as well; The output is the PrunedCFG. The technical effect of this is: to remove "branch noise unrelated to logs" and retain only the minimal control flow skeleton related to the semantics of log events, which facilitates faster subsequent rule generation and verification.

[0051] By constructing a temporary graph and traversing nodes, nodes with no data dependency on reachable paths to log event-related variables are deleted, while residual nodes unreachable from the entry point are cleaned up. This pruning operation significantly compresses the control flow graph size, removes redundant branches, and retains critical paths directly related to log semantics, thereby reducing the complexity of rule generation and improving the effectiveness and executability of state transition rules.

[0052] Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

[0053] Furthermore, the state transition rules are generated in the following ways: Enumerate the feasible paths from the event trigger point to the state update point on the log-related control flow graph; Extract the assignment expressions and branch conditions of the corresponding state variables in each of the feasible paths; The state variables are mapped to configuration units in the preset form of the log-driven state machine.

[0054] On the log-related control flow graph, feasible paths from event trigger points to state update points are enumerated. Assignment expressions and branch conditions for state variables within these paths are extracted, and these state variables are mapped to preset configuration units of the log-driven state machine. By transforming abstract code logic into formal rules, the conversion from business states to executable semantics is achieved, providing standardized input for the generation of structured log semantic sequences and enhancing the adaptability and efficiency of state machine execution.

[0055] This implementation constructs an initial control flow graph and locates log event-related variables through semantic analysis of the smart contract source code. Based on these variables, data dependency pruning is performed to generate log-related control flow graphs, and then branch paths are extracted to generate state transition rules. By eliminating branch noise irrelevant to the logs through data dependency pruning, the core control flow skeleton is preserved, ensuring that the state transition rules accurately reflect the actual business logic of the log events, thereby improving the efficiency of rule generation and the targeting of subsequent detection.

[0056] S103. Obtain the target parameters by decoding the original log through the application binary interface, and generate a structured log semantic sequence based on the target parameters and the state transition rules; S104. Execute the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information.

[0057] Please see Figure 5 , Figure 5This is a schematic diagram of the workflow of the joint parsing module provided in one embodiment of this application. In fact, the overall execution flow of this application is based on the joint parsing module. This module uses ABI to decode the original log topics / data into event names and parameters; binds the parameters with the rule templates obtained by semantic mining to generate an executable "log semantic statement sequence" (structured log semantics).

[0058] As an optional implementation, the step of executing the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information includes: Based on the state transition process of the structured log semantic sequence, the preset state machine constraints are verified; When a state machine constraint violation is detected, a network attack exception message is output. The network attack anomaly information includes the abnormal path, abnormal state, trigger log location, and associated attacker address; Furthermore, based on the network attack anomaly information, alarm information and attack details are generated, and the risk control system and / or automated handling interface are triggered to execute the preset attack response process.

[0059] By executing structured log semantic sequences through a log-driven state machine, pre-defined state machine constraints are verified. When constraints are violated, the abnormal path, state, log location, and attacker address are output, simultaneously triggering the risk control system to execute the appropriate response. This closed-loop approach combines semantic analysis, rule execution, and attack localization, enabling not only early anomaly detection but also automated attack source tracing, improving the real-time nature and accuracy of security response.

[0060] In addition, the system provided in this application also includes a verification and detection module, which executes a structured log semantic sequence based on a log-driven state machine, checks preset state machine constraints during execution, and outputs abnormal paths, abnormal states, and trigger log locations; at the same time, it tracks the profit-making address based on the constraint script to locate the attacker.

[0061] In addition, there is an output and processing module, which outputs alarms (including time, block height, event type, violation constraints, and related addresses), generates a list of attacker addresses and a chain of evidence (log sequence fragments), and can be connected to blacklist / risk control systems or automated processing interfaces.

[0062] This enables closed-loop real-time monitoring of execution results and corresponding alarm processes, further enhancing the practicality of this application.

[0063] In summary, the workflow of this application can be summarized as follows: 1. Obtain source code and raw logs. Inputs include: smart contract source code (Solidity, etc.), raw logs (including topics / data fields, etc.), and optional block range and monitoring window.

[0064] 2. For example Figure 6 As shown, Figure 6 This is a schematic diagram of the syntax and configuration of a log-driven state machine provided in one embodiment of this application. The application obtains the ABI by compiling the source code; it is also initialized in a formal execution environment. Specific content may include syntax (e.g., BNF structures of non-terminal symbols such as Block, Statement, and Log); and configuration units (e.g., ...). <price> 、 <token>(Issuance of mapping structure); initial state (empty mapping or pre-defined constant). Business logic is transformed into automatically verifiable mathematical constraints through a formal model, enabling fine-grained anomaly detection.

[0065] 3. Static analysis of the source code, construction of the CFG and location of emit statements and event variables, generation of intermediate representations (IR) using static analysis tools, construction of the CFG; scanning of emit statements to determine the set of variables associated with each event.

[0066] 4. Perform data dependency analysis based on event variables, and prune the CFG to obtain log-related CFGs. Using the event variable set as the "slicing criterion", perform data dependency reachability analysis, prune CFG nodes / branches that are irrelevant to the events, and obtain the "log-related CFG".

[0067] 5. Extract feasible branches from the pruned CFG, generate configuration units and state transition rules (log semantics), enumerate feasible branches on the pruned CFG, and convert the variable updates and expressions of each branch node into formal semantics: model variables as configuration units; model expressions as rule constraints.

[0068] 6. Use ABI to decode the raw logs to obtain the event template and parameter values. Specifically, use ABI to decode the raw logs: topics[0] match the event signature; topics[1..] and data are decoded into parameters.

[0069] 7. Bind the parameter values ​​to the migration rule template, generate an executable structured log semantic sequence, bind the decoded parameters to the migration rule template of the corresponding event, and output an executable statement sequence in the form of exec(Action) as the input of the state machine.

[0070] 8. Execute state machine and verify constraints: detect malicious price feeds / anomalies; locate the attacker and output the results; execute state machine and verify constraints: if there are violations of lending and collateral constraints, price consistency constraints, balance conservation / abnormal profit constraints, etc., an alarm will be triggered; and the attacker's address and evidence log sequence will be output.

[0071] This implementation method acquires the smart contract source code and on-chain raw logs, performs semantic analysis on the source code to generate log-related control flow graphs and state transition rules, then decodes log parameters through a binary interface and binds them to the rules to generate a structured log semantic sequence. Finally, it uses the log-driven state machine execution sequence to determine network attack anomaly information. This elevates the raw log from "parameter decoding" to "behavioral semantic reconstruction," solving the problem that traditional methods cannot recover state transition rules. It enables verifiable tracking of contract runtime state changes, thereby capturing abnormal paths triggered by malicious data sources and improving the accuracy and timeliness of attack detection.

[0072] The key points of this application are as follows: First, a log semantic mining method that automatically generates "log events → state transition rules" from static analysis of source code: including at least CFG construction, data dependency pruning based on log variables, branch extraction, and rule generation.

[0073] Second, the joint parsing mechanism: binds the log parameters decoded by ABI with the migration rule template to generate an executable sequence of structured log semantic statements.

[0074] Third, the log-driven state machine model: uses log semantic statements as the only input to drive state changes, and saves key business states (price, balance / reserve, business parameters, etc.) through configuration units.

[0075] Fourth, a detection method based on state machine constraints: using business logic constraints / security constraints to discover violation paths caused by malicious / abnormal price feeding during log-driven execution.

[0076] Fifth, attacker location mechanism: Upon detecting anomalies, the mechanism tracks profit-making addresses and related transactions based on changes in log semantic state, thereby automating attacker identification and evidence output.

[0077] This results in improvements in log parsing capabilities and attack detection and localization capabilities. Specifically, on the one hand, this application elevates logs from "readable parameters" to "executable semantics": by restoring control flow and data dependencies through static analysis, it automatically generates state transition rules corresponding to the logs, enabling the system to reconstruct the smart contract's runtime state using log sequences and formally verify business logic constraints, thereby achieving interpretable detection and tracing of DON risks. On the other hand, this application uses logs as a unified carrier to connect source code semantics with runtime behavior: it can utilize source code to obtain precise state update rules and use logs to capture runtime anomalies, making it easier to identify abnormal features before the attack is truly completed and further locate the profiting address. The appendix research also demonstrates the ability to provide early warnings before actual events and identify more attacker addresses.

[0078] This application also provides a blockchain network attack detection device based on semantic analysis, comprising: The acquisition module is used to acquire the source code of smart contracts and raw on-chain logs of the target network architecture. The target network architecture includes a decentralized oracle network; The processing module is used to perform semantic analysis on the source code of the smart contract, generate log-related control flow graphs, and determine the state transition rules corresponding to log events. The processing module is further configured to decode the original log through the application binary interface to obtain the target parameters, and generate a structured log semantic sequence based on the target parameters and the state transition rules; The processing module is also used to execute the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information.

[0079] This implementation method acquires the smart contract source code and on-chain raw logs, performs semantic analysis on the source code to generate log-related control flow graphs and state transition rules, then decodes log parameters through a binary interface and binds them to the rules to generate a structured log semantic sequence. Finally, it uses the log-driven state machine execution sequence to determine network attack anomaly information. This elevates the raw log from "parameter decoding" to "behavioral semantic reconstruction," solving the problem that traditional methods cannot recover state transition rules. It enables verifiable tracking of contract runtime state changes, thereby capturing abnormal paths triggered by malicious data sources and improving the accuracy and timeliness of attack detection.

[0080] As an optional implementation, the processing module performs semantic analysis on the smart contract source code, generates a log-related control flow graph, and determines the specific method for the state transition rules corresponding to log events, including: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

[0081] This implementation constructs an initial control flow graph and locates log event-related variables through semantic analysis of the smart contract source code. Based on these variables, data dependency pruning is performed to generate log-related control flow graphs, and then branch paths are extracted to generate state transition rules. By eliminating branch noise irrelevant to the logs through data dependency pruning, the core control flow skeleton is preserved, ensuring that the state transition rules accurately reflect the actual business logic of the log events, thereby improving the efficiency of rule generation and the targeting of subsequent detection.

[0082] As an optional implementation, the processing module performs semantic analysis on the smart contract source code, constructs an initial control flow graph, and locates the specific methods for identifying log event-related variables, including: The source code of the smart contract is parsed using an intermediate representation; Identify the log event associated variables related to the event output statements and event parameters, and construct the initial control flow graph containing branch jump relationships; In the initial control flow graph, the read / write dependency chains of each log event associated variable and event parameter are determined.

[0083] This implementation uses intermediate representations to parse the source code, identify event output statements and associated variables, construct an initial control flow graph containing branching relationships, and determine the read / write dependency chain between log event associated variables and event parameters. This accurately associates log events with contract internal state variables, providing an accurate input basis for data dependency pruning and ensuring that the subsequently generated log-related control flow graph fully covers the log semantic dependency path.

[0084] As an optional implementation, the specific methods by which the processing module performs data dependency pruning include: Based on the initial control flow graph, construct a temporary graph; Traverse each node in the temporary graph. If there is no data dependency reachable path from the current node to any of the log event association variables, then delete the node. Also, delete any residual nodes that are unreachable from the entry node.

[0085] This implementation constructs a temporary graph and traverses the nodes, deleting nodes with no data dependency reachable from log event-related variables, while also cleaning up residual nodes that are unreachable from the entry point. This pruning operation significantly compresses the control flow graph size, removes redundant branches, and retains critical paths directly related to log semantics, thereby reducing the complexity of rule generation and improving the effectiveness and executability of state transition rules.

[0086] As an optional implementation, the specific method by which the processing module generates state transition rules includes: Enumerate the feasible paths from the event trigger point to the state update point on the log-related control flow graph; Extract the assignment expressions and branch conditions of the corresponding state variables in each of the feasible paths; The state variables are mapped to configuration units in the preset form of the log-driven state machine.

[0087] This implementation enumerates feasible paths from event trigger points to state update points on the log-related control flow graph, extracts assignment expressions and branch conditions for state variables in the paths, and maps the state variables to preset configuration units of the log-driven state machine. By converting abstract code logic into formal rules, it realizes the transformation of business states into executable semantics, provides standardized input for the generation of structured log semantic sequences, and enhances the adaptability and efficiency of state machine execution.

[0088] As an optional implementation, the processing module executes the structured log semantic sequence based on the log-driven state machine to determine the specific method of network attack anomaly information, including: Based on the state transition process of the structured log semantic sequence, the preset state machine constraints are verified; When a state machine constraint violation is detected, a network attack exception message is output. The network attack anomaly information includes the abnormal path, abnormal state, trigger log location, and associated attacker address; Furthermore, based on the network attack anomaly information, alarm information and attack details are generated, and the risk control system and / or automated handling interface are triggered to execute the preset attack response process.

[0089] This implementation uses a log-driven state machine to execute structured log semantic sequences, verify preset state machine constraints, and outputs the abnormal path, status, log location, and attacker address when constraints are violated. Simultaneously, it links with the risk control system to execute the handling process. This combines semantic analysis, rule execution, and attack localization in a closed loop, enabling not only early anomaly detection but also automated attack source tracing, improving the real-time nature and accuracy of security response.

[0090] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0091] Indicatively, such as Figure 7 As shown, Figure 7 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 7 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0092] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0093] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0094] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0095] Finally, it should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0096] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0097] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.< / token> < / price>

Claims

1. A blockchain network attack detection method based on semantic analysis, characterized in that, include: Obtain the source code of the smart contracts and the original on-chain logs of the target network architecture; The target network architecture includes a decentralized oracle network; Semantic analysis is performed on the source code of the smart contract to generate a log-related control flow graph and determine the state transition rules corresponding to the log events; The target parameters are obtained by decoding the original log through the application binary interface, and a structured log semantic sequence is generated based on the target parameters and the state transition rules. The structured log semantic sequence is executed based on the log-driven state machine to determine network attack anomaly information.

2. The method according to claim 1, characterized in that, The step of performing semantic analysis on the smart contract source code, generating a log-related control flow graph, and determining the state transition rules corresponding to log events includes: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

3. The method according to claim 2, characterized in that, The step of performing semantic analysis on the smart contract source code, constructing an initial control flow graph, and locating log event-related variables includes: The source code of the smart contract is parsed using an intermediate representation; Identify the log event associated variables related to the event output statements and event parameters, and construct the initial control flow graph containing branch jump relationships; In the initial control flow graph, the read / write dependency chains of each log event associated variable and event parameter are determined.

4. The method according to claim 3, characterized in that, The data dependency pruning includes: Based on the initial control flow graph, construct a temporary graph; Traverse each node in the temporary graph. If there is no data dependency reachable path from the current node to any of the log event association variables, then delete the node. Also, delete any residual nodes that are unreachable from the entry node.

5. The method according to claim 2, characterized in that, The state transition rules are generated in the following ways: Enumerate the feasible paths from the event trigger point to the state update point on the log-related control flow graph; Extract the assignment expressions and branch conditions of the corresponding state variables in each of the feasible paths; The state variables are mapped to configuration units in the preset form of the log-driven state machine.

6. The method according to any one of claims 1-5, characterized in that, The process of executing the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information includes: Based on the state transition process of the structured log semantic sequence, the preset state machine constraints are verified; When a state machine constraint violation is detected, a network attack exception message is output. The network attack anomaly information includes the abnormal path, abnormal state, trigger log location, and associated attacker address; Furthermore, based on the network attack anomaly information, alarm information and attack details are generated, and the risk control system and / or automated handling interface are triggered to execute the preset attack response process.

7. A blockchain network attack detection device based on semantic analysis, characterized in that, include: The acquisition module is used to acquire the source code of smart contracts and raw on-chain logs of the target network architecture. The target network architecture includes a decentralized oracle network; The processing module is used to perform semantic analysis on the source code of the smart contract, generate log-related control flow graphs, and determine the state transition rules corresponding to log events. The processing module is further configured to decode the original log through the application binary interface to obtain the target parameters, and generate a structured log semantic sequence based on the target parameters and the state transition rules; The processing module is also used to execute the structured log semantic sequence based on the log-driven state machine to determine network attack anomaly information.

8. The apparatus according to claim 7, characterized in that, The processing module performs semantic analysis on the smart contract source code, generates log-related control flow graphs, and determines the specific methods for state transition rules corresponding to log events, including: Semantic analysis was performed on the source code of the smart contract to construct an initial control flow graph and locate variables associated with log events; Data dependency pruning is performed based on log event association variables to generate log-related control flow graphs; Branch paths are extracted from the log-related control flow graph to generate state transition rules corresponding to log events.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-6.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-6.

Images