Blockchain transaction anomaly detection method and device based on associated knowledge graph

Abstract

This invention provides a method and apparatus for detecting blockchain transaction anomalies based on a relational knowledge graph. The method includes: obtaining basic node feature information corresponding to a transaction request from a pre-stored relational knowledge graph; parsing the transaction path to obtain transaction path information and performing path verification; if the path verification result is successful, obtaining related transaction node information corresponding to the basic node feature information from the relational knowledge graph and performing correlation analysis; performing anomaly detection on the correlation analysis information and the transaction request to obtain anomaly detection results; if no anomalies are found, executing the exchange payment according to the transaction request and generating a transaction log for distributed storage. This method, through path verification, correlation analysis, and anomaly detection, can accurately detect and intercept abnormal high-risk transaction behaviors, significantly improving the security of the payment system and the traceability of transaction paths.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and network security technology, and in particular to a method and apparatus for detecting anomalies in blockchain transactions based on a relational knowledge graph, which is applicable to commercial settlement application scenarios. Background Technology

[0002] With the rapid development of blockchain technology and the widespread application of crypto assets, stablecoins have become an important medium in the digital payment system, widely used in cross-border payments, decentralized finance (DeFi), and various commercial settlement scenarios. Existing blockchain network architectures typically include various types of nodes such as full nodes, light nodes, consensus nodes, and archive nodes, working together to maintain the integrity of the ledger and the security of transactions. To ensure the security of the payment process, existing technologies usually collect and analyze on-chain transaction data in real time through monitoring nodes, using preset rules or basic models to verify transaction requests. These technical solutions mainly rely on independently analyzing the metadata of individual transactions (such as payer, payee, amount, timestamp, etc.) and combining it with the execution logs of smart contracts to confirm the legality of the transaction status, thereby completing basic anti-double-spending detection and compliance screening.

[0003] However, with existing technologies, facing increasingly complex cross-chain interactions, automatic multi-currency exchange, and high-frequency mixed transaction scenarios, relying solely on feature analysis of a single transaction dimension is insufficient to comprehensively identify hidden abnormal behaviors. Because compliance information and risk characteristics are scattered across different blockchain networks and heterogeneous ledgers, the lack of a unified, interconnected view makes it difficult for the system to efficiently trace the complete path of fund flows and accurately capture transaction risks or fraud patterns involving multi-party collaboration.

[0004] This results in low efficiency in anomaly detection during the payment process, affecting the overall security of the payment system. Summary of the Invention

[0005] This invention provides a blockchain transaction anomaly detection method and apparatus based on a relational knowledge graph, aiming to solve the problem of low payment security in existing payment systems.

[0006] In a first aspect, embodiments of the present invention provide a method for detecting blockchain transaction anomalies based on a relational knowledge graph. The method is applied to a detection server, which is connected to a blockchain network and acts as a monitoring node of the blockchain network. The method includes: If a transaction request initiated by a user within the blockchain network is received, the basic node feature information corresponding to the transaction request is obtained from the pre-stored related knowledge graph; Based on the basic node feature information, the transaction request is parsed to obtain the corresponding transaction path information; The transaction path information is validated according to the preset path validation rules to obtain the corresponding path validation result. If the path verification result is successful, the associated transaction node information corresponding to the basic node feature information is obtained from the associated knowledge graph according to the preset association judgment rules. Based on a pre-set correlation analysis model, correlation analysis is performed on the basic node feature information and the related transaction node information to obtain the corresponding correlation analysis information; The transaction request is subjected to anomaly detection based on the preset anomaly detection model and the correlation analysis information to obtain the corresponding anomaly detection results; If the anomaly detection result is no anomaly, the exchange payment is executed according to the transaction request, and the corresponding transaction log is generated and stored in a distributed manner.

[0007] Secondly, embodiments of the present invention also provide a blockchain transaction anomaly detection device based on a relational knowledge graph. The device is configured in a detection server, which is connected to a blockchain network and acts as a monitoring node of the blockchain network. The device is used to execute the blockchain transaction anomaly detection method based on a relational knowledge graph as described in the first aspect. The device includes: The basic node feature information acquisition unit is used to acquire basic node feature information corresponding to the transaction request from a pre-stored related knowledge graph if a transaction request initiated by a user in the blockchain network is received. The transaction path information acquisition unit is used to parse the transaction request based on the basic node feature information to obtain the corresponding transaction path information. The path verification result acquisition unit is used to perform path verification on the transaction path information according to the preset path verification rules and obtain the corresponding path verification result. The associated transaction node information acquisition unit is used to acquire associated transaction node information corresponding to the basic node feature information from the associated knowledge graph according to the preset association judgment rules if the path verification result is passed. The association analysis unit is used to perform association analysis on the basic node feature information and the related transaction node information according to the preset association analysis model to obtain the corresponding association analysis information. An anomaly detection result acquisition unit is used to perform anomaly detection on the transaction request based on a preset anomaly detection model and the correlation analysis information, and obtain the corresponding anomaly detection result; The transaction log storage unit is used to execute the exchange payment according to the transaction request and generate the corresponding transaction log for distributed storage if the anomaly detection result is no anomaly.

[0008] Thirdly, embodiments of the present invention also provide an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect above.

[0009] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can implement the method described in the first aspect.

[0010] This invention provides a method and apparatus for detecting blockchain transaction anomalies based on a relational knowledge graph. The method includes: obtaining basic node feature information corresponding to a transaction request from a pre-stored relational knowledge graph; parsing the transaction path to obtain transaction path information and performing path verification; if the path verification result is successful, obtaining related transaction node information corresponding to the basic node feature information from the relational knowledge graph and performing correlation analysis; performing anomaly detection on the correlation analysis information and the transaction request to obtain anomaly detection results; if no anomalies are found, executing the exchange payment according to the transaction request and generating a transaction log for distributed storage. This method, through path verification, correlation analysis, and anomaly detection, can accurately detect and intercept abnormal high-risk transaction behaviors, significantly improving the security of the payment system and the traceability of transaction paths. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating the blockchain transaction anomaly detection method based on a relational knowledge graph provided in this embodiment of the invention; Figure 2 A schematic block diagram of a blockchain transaction anomaly detection device based on a relational knowledge graph provided in an embodiment of the present invention; Figure 3 A schematic block diagram of an electronic device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating an application scenario of the blockchain transaction anomaly detection method based on associated knowledge graphs provided in this embodiment of the invention. Detailed Implementation

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

[0014] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0015] It should also 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.

[0016] It should also be further understood that the term "and / or" as used in this specification and appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations. This invention provides a method and apparatus for detecting blockchain transaction anomalies based on a relational knowledge graph. For specific application scenarios of this blockchain transaction anomaly detection method based on a relational knowledge graph, please refer to... Figure 4 , Figure 4 This diagram illustrates an application scenario of the blockchain transaction anomaly detection method based on relational knowledge graphs provided in this invention. The blockchain transaction anomaly detection method based on relational knowledge graphs is applied in, for example... Figure 4 In the application scenario, the blockchain transaction anomaly detection method based on the association knowledge graph is applied to the detection server 10. The detection server 10 is connected to the blockchain network 20 and acts as a monitoring node of the blockchain network 20. The detection server 10 can be implemented using a standalone server or a server cluster composed of multiple servers. The blockchain network 20 is a distributed hardware network formed by the interconnection of multiple blockchain nodes. The invention will now be described in detail through specific embodiments.

[0017] Figure 1 This is a flowchart illustrating the blockchain transaction anomaly detection method based on a relational knowledge graph provided in an embodiment of the present invention. Figure 1 As shown, the method includes the following steps S110-S170.

[0018] S110. If a transaction request initiated by a user within the blockchain network is received, the basic node feature information corresponding to the transaction request is obtained from the pre-stored associated knowledge graph.

[0019] If a transaction request initiated by a user within the blockchain network is received, the basic node feature information corresponding to the transaction request is retrieved from the pre-stored relational knowledge graph. The basic node feature information refers to a data set that characterizes the core attributes of the payer node corresponding to the current transaction request, and it originates from the pre-stored relational knowledge graph. This relational knowledge graph is a pre-built structured data network stored in the detection server. It is a topological network constructed by decoding, indexing, and structured storing historical transaction logs within the blockchain network. The relational knowledge graph is used to map various entities (such as wallet addresses, smart contracts, and transaction hashes) and their interrelationships within the blockchain network. The transaction request is the request information used to implement transaction payment. Specifically, the transaction request includes fields such as the payer's address (source transaction hash address), the payee's address (target transaction hash address), the transaction amount, the original currency, the target currency, the current exchange rate slippage parameter, the transaction fee parameter (used to calculate the required transaction fee), and risk control tags (such as high-risk address identifiers).

[0020] In the process of constructing the knowledge graph, semantic fields can be encoded into calldata (a read-only data area for parameters passed during external function calls) or event log (on-chain event log) during contract execution by extending the smart contract interface. After being parsed by the indexer, these fields are mapped to the knowledge graph for storage. Specifically, a transaction request involves at least two parties, and each party corresponds to a transaction node in the knowledge graph. The basic node feature information is the feature information created during the execution of the transaction request that corresponds to a single user. This basic node feature information can be used to represent the individual attributes of the user.

[0021] For example, when a cross-chain transaction request involving the exchange of a first currency for a second currency is received, the system extracts the node attributes of the corresponding transaction node from the associated knowledge graph as the basic node feature information. This includes the source transaction hash address, address type, transaction region, chain identifier, bridging protocol ID, connection port identifier, historical transaction frequency, total transaction amount, transaction success rate, average transaction amount, fund transfer difference, last interaction time, cross-chain connection type statistics, and risk control tag statistics. By directly obtaining multi-dimensional features from the pre-stored graph, the system avoids the data loss problem caused by information fragmentation in traditional methods.

[0022] S120. Based on the basic node feature information, the transaction request is parsed to obtain the corresponding transaction path information.

[0023] The system parses transaction requests based on fundamental node characteristic information to obtain corresponding transaction path information. Transaction path information refers to the sequence data of all intermediate steps and state changes that transaction funds undergo from the payer to the payee. Transaction path parsing is the process of reconstructing the logic of fund flow based on the source chain identifier, target chain identifier, and bridging protocol ID in the transaction request. Specifically, the system uses a global transaction identifier in the transaction request for transaction path parsing. This global transaction identifier is a unique identifier generated by combining the source transaction hash address, routing path, and target transaction hash address and performing a hash operation. It is used to connect multiple sub-transaction stages such as cross-chain transactions, exchanges, and payments.

[0024] In a specific embodiment, step S120 includes the following sub-steps: constructing a root node corresponding to the basic node feature information; obtaining the leaf node corresponding to the transaction request from the associated knowledge graph and adding it to the root node, thereby constructing a transaction tree structure; obtaining the node attributes of the leaf nodes in the transaction tree structure to obtain the corresponding transaction path information.

[0025] Specifically, the root node refers to the starting node of the transaction tree structure, serving as the logical starting point for parsing the entire transaction path. The root node is generated by extracting the core elements of the payer from the basic node feature information, specifically including the source transaction hash address, region, bridging protocol ID, connection port identifier, and timestamp. In this embodiment, this technical feature establishes the main object of the current transaction parsing, providing a benchmark anchor for subsequent attachment of related nodes. For example, when the detection server receives a transaction request initiated from the transaction network, the system automatically retrieves the transaction node corresponding to the request from the associated knowledge graph, extracts the node attribute combination corresponding to the transaction node as basic node feature information, and uses a hash algorithm to encapsulate this basic node feature information into a unique root node object. This method of constructing root nodes based on core elements ensures that each transaction request to be detected has an independent identity, avoiding confusion between different transaction paths and laying a solid foundation for subsequent structured parsing.

[0026] Furthermore, leaf nodes refer to transaction entity nodes located at the end or intermediate jump position in the transaction path, representing specific stages in the transaction flow. Leaf nodes are obtained by querying a pre-stored association knowledge graph. Specifically, the system uses the feature value of the root node constructed above as an index to retrieve preceding transaction nodes, subsequent transaction nodes, or cross-chain bridge nodes that are related to the transaction request in the association knowledge graph. The transaction tree structure is a hierarchical data structure composed of a root node and multiple leaf nodes connected by directed edges, used to visually reconstruct the entire lifecycle path of a transaction. In the constructed transaction tree structure, the root node is located at the top level, and multiple retrieved leaf nodes are sequentially attached below the root node to form a complete tree topology. For example, if the basic node feature information indicates that cross-chain operations are involved, the system will obtain the corresponding bridge protocol ID node and the receiving party transaction node from the knowledge graph as leaf nodes and add them below the root node. By dynamically loading leaf nodes and constructing a tree structure, fragmented node information that was originally scattered across different blockchain ledgers can be integrated into a coherent path, effectively solving the problem of fragmented and difficult-to-track transaction trajectories in a multi-chain environment.

[0027] Furthermore, node attributes can refer to a data set describing the specific state and parameters of a leaf node, which is a key element constituting complete transaction path information. Transaction path information is generated by traversing the constructed transaction tree structure, reading and aggregating the attribute data of all leaf nodes, specifically including the node hash address, bridging protocol type, exchange rate parameters, slippage settings, transaction fee details, and risk labels involved in each step of the transaction flow. In this embodiment, this technical feature transforms structured tree data into a linear or serialized path description that can be directly used by subsequent verification rules. For example, when traversing the transaction tree, the system extracts the bridging protocol ID stored in the leaf nodes to indicate which cross-chain bridge was used, extracts the exchange rate and slippage parameters to confirm the compliance of the exchange process, and assembles this information into the final transaction path string or object according to the logical order in which the transactions occurred. The resulting transaction path information not only includes the start and end points of the transaction but also records detailed intermediate flow information, providing sufficient data support for the next step of path integrity verification and sequence verification, significantly improving the granularity and accuracy of anomaly detection.

[0028] S130. Perform path verification on the transaction path information according to the preset path verification rules to obtain the corresponding path verification result.

[0029] The transaction path information is validated according to pre-defined path validation rules to obtain the corresponding path validation result. Path validation rules are a pre-defined set of standards used to determine the legality and logical correctness of a transaction path, including path compliance parameters and path dependency parameters. The specific execution process of path validation is divided into two dimensions: integrity validation and sequence validation. Integrity validation checks whether key intermediate proofs are missing from the transaction path information based on path compliance parameters. For example, it verifies whether a complete Payment Proof Hash (transaction certificate hash value) or Merkle Root covering all jump steps has been generated to ensure that no transaction step has been tampered with or omitted. Sequence validation verifies whether the logical order of each transaction step conforms to business rules based on path dependency parameters. For example, it confirms that the exchange operation must occur before the cross-chain transfer, and that the transaction fee payment record must exist before the final settlement. The path validation result is a Boolean value or status code indicating whether the path simultaneously meets the requirements of integrity and sequence.

[0030] In a specific embodiment, step S130 includes the following sub-steps: performing integrity verification on the transaction path information according to the path compliance parameters in the path verification rules to obtain an integrity verification result indicating whether the path is complete; performing sequence verification on the transaction path information according to the path dependency parameters in the path verification rules to obtain a sequence verification result indicating whether the path order is correct; and combining the integrity verification result and the sequence verification result to obtain a path verification result indicating whether the path has passed.

[0031] Specifically, path compliance parameters refer to configuration data used to define the minimum set of nodes and key connections that a legitimate transaction path must include. This data originates from a pre-built security policy library or regulatory compliance requirement documents. In this embodiment, this technical feature serves as a benchmark template for integrity verification, comparing the currently parsed transaction path information to determine if any parts are missing. Specifically, integrity verification is achieved by matching the actual node sequence in the transaction path information with the required node template defined in the path compliance parameters. If the transaction path information lacks any of the key nodes specified in the path compliance parameters, such as a cross-chain bridging node, an authentication node, or a specific clearing node, or if the connections between nodes are broken, preventing the formation of a closed loop, the integrity verification result is determined to be an incomplete path. For example, in a transaction scenario involving the transfer of stablecoins from a trading network to the Tron network, the path compliance parameters explicitly stipulate that a legitimate path must sequentially include a source address node, a cross-chain bridging protocol node, and a target address node. If the parsed transaction path information only includes the source address node and the target address node, but lacks the intermediate cross-chain bridging protocol node, the system determines that the path integrity verification fails based on the path compliance parameters, generating an incomplete path integrity verification result. This integrity comparison based on preset compliance parameters can effectively identify maliciously cut transaction chains and prevent attackers from circumventing audits by hiding key intermediate links.

[0032] Furthermore, path dependency parameters can refer to a set of rules used to define the logical sequence and causal constraints between the operation steps in a transaction path. These rules are derived from statistical analysis of historical normal transaction data or formal descriptions of business logic. In this embodiment, this technical feature ensures that the transaction process conforms to the established business logic, preventing logical inversions or illegal operation sequences. Specifically, sequence verification involves traversing the node sequence in the transaction path information and checking whether the execution order between adjacent nodes or specific node pairs satisfies the predecessor-successor constraints defined in the path dependency parameters. When an actual operation sequence is detected to violate the preset dependency relationship, the path sequence is determined to be incorrect. For example, in an automatic exchange payment scenario, the path dependency parameters stipulate that the exchange rate locking and exchange confirmation operations must be performed first, followed by the fund transfer operation. If the transaction path information shows that a fund transfer was initiated directly without completing the exchange confirmation, or if a reverse sequence of transfer before exchange occurs, the system determines that the path sequence verification fails based on the path dependency parameters, generating a sequence verification result indicating an incorrect path sequence. By introducing path dependency parameters for temporal logic verification, arbitrage attacks or fraudulent activities attempting to exploit operational timing vulnerabilities can be accurately identified and intercepted.

[0033] Furthermore, the comprehensive processing can refer to the logical AND operation between the integrity verification result and the sequence verification result generated in the aforementioned steps. In this embodiment, this technical feature serves to arrive at a final path validity conclusion through multi-dimensional joint judgment. Specifically, the comprehensive path verification result is considered successful only when the integrity verification result indicates a complete path and the sequence verification result indicates a correct path order; conversely, if either the integrity or sequence verification result fails, the final path verification result is also considered unsuccessful. Furthermore, the path verification result output in this step directly determines the execution direction of subsequent processes: if the result is successful, the system will allow entry into the subsequent related transaction node acquisition and analysis stage; if the result is unsuccessful, the system will immediately terminate the processing of the current transaction request and generate a corresponding abnormal alarm log. Thus, through a dual verification mechanism of integrity and sequence, a formalized and rigorous path validity judgment standard is constructed, significantly improving the system's defense capabilities against high-level attacks in complex multi-chain transaction scenarios and ensuring the auditability and security of the payment path.

[0034] S140. If the path verification result is successful, obtain the associated transaction node information corresponding to the basic node feature information from the associated knowledge graph according to the preset association judgment rules.

[0035] If the path verification passes, the system retrieves the associated transaction node information corresponding to the basic node feature information from the association knowledge graph according to preset association judgment rules. Associated transaction node information refers to the set of neighboring transaction nodes and their attribute data in the association knowledge graph that have a transaction relationship with the basic feature node of the current transaction. The basic feature node is the transaction node corresponding to the payer who initiated the transaction request. When the path verification passes, the system starts from the graph node corresponding to the basic node feature information and searches outwards according to preset rules to obtain first-level or multi-level associated transaction nodes.

[0036] In a specific embodiment, step S140 includes the following sub-steps: obtaining the associated transaction nodes in the associated knowledge graph that correspond to the basic node feature information according to the association judgment rules; and obtaining the node feature data of the associated transaction nodes as the corresponding associated transaction node information.

[0037] Association judgment rules define how to traverse the knowledge graph to uncover potential risk associations. This typically includes setting the association hierarchy and association rule filters. For example, if the association hierarchy is set to level two, neighboring transaction nodes that have a transaction relationship with the current transaction's basic feature node are obtained as level one nodes, and further, neighboring transaction nodes that have a transaction relationship with the neighboring node are obtained as level two nodes. If the association rule filter sets the transaction frequency to ≥3 and the connection weight to ≥0.25, then level one and level two nodes can be filtered based on the association rule filter and the transaction data between each node and the basic feature node, thereby selecting nodes that meet the association rule filter as associated transaction nodes.

[0038] Specifically, a related transaction node refers to a graph node in a pre-stored related knowledge graph that has a transaction relationship with the basic feature node of the current transaction request, located through pre-defined association judgment rules. The system determines the corresponding graph node in the related knowledge graph as the basic feature node based on the basic node feature information. Starting from the node corresponding to the basic node feature information, the system traverses its adjacent nodes in the related knowledge graph, filtering out nodes that meet the association judgment rules as related transaction nodes. For example, if the basic node feature information contains a specific cross-chain bridging protocol ID, the system checks whether each transaction node in the related knowledge graph uses the same cross-chain bridging protocol ID. The system will obtain all transaction nodes under that protocol that have transacted with the basic feature node, as neighboring transaction nodes with a transaction relationship with the basic feature node. Then, the system filters and judges the determined neighboring transaction nodes according to the association judgment rules to finally determine the related transaction node. Through this rule-based graph traversal mechanism, entities with implicit connections to the current transaction can be automatically discovered, thereby revealing potential fund circulation networks or clues to organized crime.

[0039] Furthermore, the node characteristic data of each associated transaction node is obtained and combined to obtain associated transaction node information. Node characteristic data refers to data information describing the connection relationship between associated transaction nodes and basic characteristic nodes. Node characteristic data includes a structured data set of associated transaction node attributes, transaction behavior attributes, and risk control attributes. Specifically, node characteristic data includes node identity attributes, such as address type and chain identifier; it also includes transaction behavior attributes, such as historical transaction frequency, total transaction amount, transaction success rate, average transaction amount, fund flow difference (inflow funds - outflow funds), most recent interaction time, and cross-chain connection type statistics; and it also includes risk control attributes, such as risk control tag statistics and connection weight (a coefficient value used to reflect the tightness of the connection between associated transaction nodes and basic characteristic nodes). For example, the formula for calculating connection weight can be [(exp(J / 2P1)-1) (exp(J / 2P2)-1)]. 1 / 2 exp is the power operation with the natural logarithm as the base, J is the total transaction amount between the basic feature node and the associated transaction node, P1 is the total transaction amount of the basic feature node, and P2 is the total transaction amount of the associated transaction node.

[0040] After identifying the related transaction nodes, the system directly reads the aforementioned data from the node attribute storage area of ​​the related knowledge graph and encapsulates it into related transaction node information for use by subsequent related analysis models. By extracting multi-dimensional node feature data, the abstract graph connections can be transformed into quantifiable analytical inputs, enabling subsequent models to comprehensively evaluate the risk transmission relationship between the current transaction and related entities, and effectively identify abnormal behaviors such as high-risk transactions.

[0041] S150. Perform correlation analysis on the basic node feature information and the related transaction node information according to the preset correlation analysis model to obtain the corresponding correlation analysis information.

[0042] Based on a pre-set correlation analysis model, correlation analysis is performed on the feature information of basic nodes and the information of related transaction nodes to obtain corresponding correlation analysis information. The correlation analysis model is a pre-trained deep learning model or graph neural network model used to quantitatively assess the risk correlation between a transaction entity and its related environment. The correlation analysis process involves transforming the feature information of basic nodes into a second feature vector and the information of related transaction nodes into a first feature vector, which are then input into the model for fusion calculation. Specifically, the model performs correlation analysis on the input feature information through a correlation layer between the input and output layers, thereby capturing the structural dependencies and feature interactions between basic nodes and related nodes, and outputting correlation analysis information reflecting the probability of risk propagation or abnormal transactions.

[0043] In a specific embodiment, step S150 includes the following sub-steps: extracting the corresponding first feature vector from the related transaction node information; extracting the corresponding second feature vector from the basic node feature information; and performing correlation analysis on the first feature vector and the second feature vector through the correlation analysis model to obtain the corresponding correlation analysis information.

[0044] Specifically, the first feature vector can refer to the feature vector representing the node attributes of related transaction nodes that have a transaction relationship with the current transaction request. The first feature vector is obtained by encoding the multi-dimensional attributes in the related transaction node information through a feature extraction algorithm. Specifically, the related transaction node information includes the node attributes, transaction behavior attributes, and risk status of the related transaction nodes; the extraction process aims to convert these unstructured data into fixed-length vectors that the model can process. Normalization calculations are performed on the historical transaction frequency, total transaction amount, average transaction power, average transaction amount, fund flow difference, most recent interaction time, and cross-chain connection type statistics of a certain related transaction node to obtain the corresponding normalized values; the risk control label ratio in the risk control label statistics of the related transaction node is also normalized to obtain normalized values, all of which are between [0,1]. Related transaction nodes are classified according to their identity attributes, including address type, transaction region, and chain identifier, and the normalized values ​​of the related transaction nodes are aggregated based on the classification results to form the first feature vector.

[0045] For example, the associated transaction node information contains three associated transaction nodes, whose classification results are the first category (low-risk area), the second category (high-risk area) and the third category (newly registered users). The normalized values ​​of the associated transaction nodes of each category can be mapped to coordinates in a continuous vector space through the embedding layer. After aggregation, the first feature vector is formed, and each vector value in the first feature vector is located between [0,1].

[0046] Furthermore, the second feature vector can refer to a numerical representation of the inherent attributes of the payer graph node (i.e., the basic feature node) in the current transaction request. The second feature vector is obtained by encoding the feature information of the basic node through the same or adapted feature extraction mechanism. The feature information of the basic node comes from the node attribute information of the basic feature node. The basic feature node can be classified according to the address type, transaction region, and chain identifier in the feature information of the basic node, and the corresponding classification result is obtained and mapped to obtain the type feature vector corresponding to the classification result. The transaction behavior attributes and risk control tag statistics are normalized to obtain normalized values, and the connection weight is reset to "1" (the node itself has the highest connection density). The normalization process is the same as the normalization process of the relevant feature information of the associated transaction node. The obtained type feature vector is combined with the normalized value to generate the second feature vector.

[0047] Furthermore, the correlation analysis model is a pre-built machine learning model used to evaluate the matching degree between a transaction ontology and its associated environment. Specifically, it can employ graph neural networks or attention mechanism networks. Correlation analysis information refers to the quantitative data output by the model describing the strength of the correlation between the two, including correlation coefficients, which can be a set of 1×N dimensional coefficient values. The correlation analysis process involves inputting a first feature vector and a second feature vector into the correlation analysis model. The model's internal correlation layer calculates the correlation relationship between the two sets of vectors through multiple nonlinear transformations. Specifically, if the model identifies a transaction in the second feature vector that involves a high-risk node in the first feature vector, the model will output a high-value model output, indicating a high correlation between the transaction and the high-risk trading environment. The model output values ​​in this application are output by the corresponding output nodes of the model. The model output values ​​are only used for model training. For example, a high model output value corresponds to high-risk sample data, and a low model output value corresponds to low-risk sample data. The output correlation coefficient is obtained by normalizing the output value of the last layer analysis node in the correlation layer. The number of the last layer analysis nodes in the correlation layer is N. After normalizing the output value of the last layer analysis node, the value range is between [0,1].

[0048] S160. Perform anomaly detection on the transaction request based on the preset anomaly detection model and the correlation analysis information to obtain the corresponding anomaly detection result.

[0049] Anomaly detection is performed on transaction requests based on an anomaly detection model and correlation analysis information to obtain corresponding anomaly detection results. The anomaly detection model is the core risk control engine deployed on the detection server, containing a dynamically configurable attention network. The model comprises an input layer, an attention network, an anomaly detection intermediate layer, and an output layer. The input layer takes the request feature vector corresponding to the transaction request as input. The attention network contains attention nodes that require parameter configuration. The anomaly detection intermediate layer contains intermediate nodes used for anomaly detection analysis, and the attention network performs weighted calculations on some of these intermediate nodes. The output layer outputs the anomaly probability score. Anomaly detection is performed by using correlation coefficients from the correlation analysis information to configure the attention network of the anomaly detection model in real time, adjusting the model's attention weights for different feature dimensions to focus more on the high-risk areas of the current transaction. Subsequently, the system inputs the request feature vector corresponding to the transaction request into the configured anomaly detection model, which outputs the final anomaly detection result. The anomaly detection result is typically classified as no anomaly or anomaly, and may include a specific anomaly probability score.

[0050] In a specific embodiment, step S160 includes the following sub-steps: configuring the attention network of the anomaly detection model according to the correlation coefficient in the correlation analysis information; obtaining the request feature vector corresponding to the transaction request; performing anomaly detection on the request feature vector according to the anomaly detection model with the attention network configured, and obtaining the corresponding anomaly detection result.

[0051] For example, when the output of the correlation analysis model indicates that a transaction involves a high-risk node, the attention network of the anomaly detection model is configured using the correlation coefficient of the correlation analysis information. This intelligently improves the sensitivity of the correlation analysis model to fund flow and frequency characteristics. In this embodiment, this technical feature dynamically adjusts static model parameters to a configuration that adapts to the risk level of the correlation analysis results, achieving adaptive adjustment for different risk correlations and significantly reducing false positive and false negative rates.

[0052] Specifically, the correlation coefficient can be a multidimensional coefficient representing the degree of risk correlation between the payer node of the current transaction and its surrounding related transaction nodes. The correlation coefficient can dynamically adjust the weight distribution of the attention network in the anomaly detection model, enabling the model to adaptively focus on transaction features that require special attention and achieve accurate anomaly detection. Specifically, the attention network is the core component of the anomaly detection model, used to assign different attention weights when processing sequence data. The attention network contains N attention nodes, and the correlation coefficient can be used to configure the attention parameters of the network nodes sequentially.

[0053] Furthermore, the request feature vector is the result of converting the current transaction request to be detected into a machine-processable numerical vector. Its source is the encoded raw data contained in the transaction request. Specifically, the request feature vector includes the source chain identifier of the payer's transaction node, the target chain identifier of the payee's transaction node, the bridging protocol ID used, the risk control tag, the transaction amount, the original currency, the target currency, the current exchange rate slippage parameter, and transaction fee parameters. The transaction amount in the transaction request can be normalized, and the relevant parameters such as the bridging protocol ID, protocol type, and exchange rate slippage parameter can be encoded into a numerical sequence. The feature data is mapped into a fixed-dimensional vector space through a pre-set feature extraction algorithm, thereby generating the corresponding request feature vector. In this embodiment, this technical feature is used to characterize the intrinsic attributes of a single transaction, serving as the ontological basis for anomaly detection analysis of the transaction request. This step converts the transaction request into direct input data for the anomaly detection model, carrying the full semantic information of this transaction behavior.

[0054] Furthermore, the anomaly detection result can refer to the model's output classification conclusion regarding whether the current transaction request poses a security risk. Its generation process relies on the deep processing of the acquired request feature vector by the configured attention network. Specifically, the configured anomaly detection model inputs the request feature vector into the weighted attention layer. The model calculates the anomaly probability score for each category—normal or abnormal—based on the weighted feature representation. If the calculated anomaly probability score exceeds a preset probability threshold, the result is considered anomaly; otherwise, it is considered normal. Since the attention network has been specifically configured based on the correlation coefficient, the model automatically strengthens its focus on the corresponding feature dimensions during calculation. Therefore, this step not only completes the final anomaly determination but also significantly improves the detection accuracy and robustness through a dynamic attention mechanism, effectively avoiding the problem of traditional static models missing complex correlation attacks.

[0055] S170. If the anomaly detection result is no anomaly, then execute the exchange payment according to the transaction request and generate the corresponding transaction log for distributed storage.

[0056] If the anomaly detection result is negative, the exchange payment is executed according to the transaction request, and a corresponding transaction log is generated and stored in a distributed manner. Exchange payment refers to the actual transfer of funds and currency conversion operations completed by calling smart contracts or cross-chain protocols based on the currency requirements and amount in the transaction request. This includes Swap operations executed by the automatic exchange module and transaction fee payment processing completed by the settlement module. The transaction log is a structured file that records the entire lifecycle data of this transaction. Its content not only includes traditional transfer hashes but also semantic fields such as the original payment currency, the merchant's target currency, the aggregation path identifier, the bridging protocol ID, the exchange rate slippage parameter, the user hash, and risk control tags. Distributed storage refers to writing the generated transaction log into a decentralized storage system such as the distributed ledger of the blockchain network or IPFS (InterPlanetary File System) to ensure the immutability and traceability of the data. If the detection result is abnormal, the transaction request is intercepted, that is, the exchange payment is terminated, and an anomaly message is displayed.

[0057] In a specific embodiment, after step S170, the method further includes the step of updating the associated knowledge graph based on the transaction log.

[0058] Specifically, a transaction log refers to a record file containing complete transaction chain data generated by the detection server after a transaction request has been executed for payment and confirmed to be without anomalies. This transaction log includes structured data such as the address hashes of both parties, the transaction amount, the aggregation path identifier used, the cross-chain bridging protocol ID, exchange rate parameters, slippage parameters, and risk control tags. By parsing the transaction log, new transaction entities and their interrelationships can be extracted, serving as a data source for updating the associated knowledge graph.

[0059] Furthermore, updating the knowledge graph can refer to writing the newly parsed nodes and edge relationships incrementally into a pre-stored graph database to correct or expand the existing graph structure. Specifically, if a transaction entity appearing in the log does not exist in the existing graph, a new graph node is constructed and assigned corresponding node attributes; if a transaction entity already exists but generates new interaction behavior, new directed edges are established between existing nodes, and the edge weight attributes are updated, such as connection weight, transaction frequency, cumulative amount, and risk control tag statistics. Through this closed-loop feedback mechanism based on real transaction logs, the knowledge graph can dynamically capture constantly changing transaction patterns and new attack paths in the blockchain network. For example, when a newly emerging cross-chain bridging protocol is detected to be frequently used for large-scale fund transfers, the system will automatically strengthen the connection weight between the corresponding graph nodes in the graph, making them occupy a more important position in subsequent path verification and association analysis. This significantly improves the timeliness and completeness of the knowledge graph, avoids misjudgments or omissions caused by using static and outdated graph data, and enables the system to have the ability to learn and iteratively optimize itself.

[0060] In the technical solution provided in this application, there is a close synergy among the various technical features. By obtaining basic node feature information from a pre-stored association knowledge graph and combining it with transaction path parsing technology, the fragmented transaction data from multiple chains is reconstructed into a logical chain with complete semantics, solving the problem of information fragmentation in traditional monitoring. Based on this, path verification rules perform dual verification of the completeness and sequence of the reconstructed path, ensuring the authenticity and reliability of the data entering the deep analysis stage and effectively blocking attacks attempting to forge paths. Furthermore, the association transaction node information mined using association judgment rules, along with basic feature information, is input into the association analysis model, enabling the anomaly detection model to make judgments based on global topological relationships rather than isolated data, significantly improving the accuracy of identifying hidden association risks and group fraud. Finally, under anomaly-free conditions, payments are executed and transaction logs containing extended fields are generated and distributed for storage. This not only ensures the smooth execution of transactions but also continuously enriches the association knowledge graph through a log feedback mechanism, forming a virtuous cycle. This comprehensively improves the accuracy, interpretability, and adaptive evolution capability of blockchain transaction anomaly detection.

[0061] The blockchain transaction anomaly detection method based on a relational knowledge graph disclosed in the above embodiments includes: obtaining basic node feature information corresponding to the transaction request from a pre-stored relational knowledge graph; parsing the transaction path to obtain transaction path information and performing path verification; if the path verification result is successful, obtaining related transaction node information corresponding to the basic node feature information from the relational knowledge graph and performing correlation analysis; performing anomaly detection on the correlation analysis information and the transaction request to obtain anomaly detection results; if no anomalies are found, executing the exchange payment according to the transaction request and generating transaction logs for distributed storage. This method, through path verification, correlation analysis, and anomaly detection, can accurately detect and intercept abnormal high-risk transaction behaviors, significantly improving the security of the payment system and the traceability of transaction paths.

[0062] Figure 2 This is a schematic block diagram of a blockchain transaction anomaly detection device based on a relational knowledge graph, provided as an embodiment of the present invention. Figure 2 As shown, corresponding to the above-mentioned blockchain transaction anomaly detection method based on relational knowledge graphs, the present invention also provides a blockchain transaction anomaly detection device based on relational knowledge graphs, wherein the device is configured in, as shown in, Figure 4 In application scenarios. For details, please refer to... Figure 2 The blockchain transaction anomaly detection device 700 based on a relational knowledge graph includes: The basic node feature information acquisition unit 701 is used to acquire basic node feature information corresponding to the transaction request from a pre-stored related knowledge graph if a transaction request initiated by a user in the blockchain network is received. The transaction path information acquisition unit 702 is used to parse the transaction request based on the basic node feature information to obtain the corresponding transaction path information. The path verification result acquisition unit 703 is used to perform path verification on the transaction path information according to the preset path verification rules and obtain the corresponding path verification result. The associated transaction node information acquisition unit 704 is used to acquire associated transaction node information corresponding to the basic node feature information from the associated knowledge graph according to the preset association judgment rules if the path verification result is passed. The association analysis unit 705 is used to perform association analysis on the basic node feature information and the related transaction node information according to the preset association analysis model to obtain the corresponding association analysis information. The anomaly detection result acquisition unit 706 is used to perform anomaly detection on the transaction request based on the preset anomaly detection model and the correlation analysis information, and obtain the corresponding anomaly detection result; The transaction log storage unit 707 is used to execute the exchange payment according to the transaction request and generate the corresponding transaction log for distributed storage if the anomaly detection result is no anomaly.

[0063] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the blockchain transaction anomaly detection device based on the association knowledge graph and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0064] The aforementioned blockchain transaction anomaly detection device based on relational knowledge graphs can be implemented as a computer program, which can, for example... Figure 3 It runs on the electronic device shown.

[0065] Please see Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention. The electronic device 800 can be a terminal or a server. The terminal can be an electronic device with communication functions. The server can be a standalone server or a server cluster composed of multiple servers.

[0066] See Figure 3 The electronic device 800 includes a processor 802, a memory, and a network interface 805 connected via a system bus 801. The memory may include a non-volatile storage medium 803 and internal memory 804.

[0067] The non-volatile storage medium 803 may store an operating system 8031 ​​and a computer program 8032. The computer program 8032 includes program instructions that, when executed, cause the processor 802 to perform a blockchain transaction anomaly detection method based on a relational knowledge graph.

[0068] The processor 802 provides computing and control capabilities to support the operation of the entire electronic device 800.

[0069] The internal memory 804 provides an environment for the execution of the computer program 8032 in the non-volatile storage medium 803. When the computer program 8032 is executed by the processor 802, the processor 802 can execute a blockchain transaction anomaly detection method based on a relational knowledge graph.

[0070] This network interface 805 is used for network communication with other devices. Those skilled in the art will understand that... Figure 3The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the electronic device 800 to which the present invention is applied. The specific electronic device 800 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0071] The processor 802 is used to run the computer program 8032 stored in the memory to implement the steps included in the above-mentioned blockchain transaction anomaly detection method based on association knowledge graph.

[0072] It should be understood that, in this embodiment of the invention, the processor 802 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0073] It will be understood by those skilled in the art 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 includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0074] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the steps included in the above-described blockchain transaction anomaly detection method based on a relational knowledge graph.

[0075] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0076] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0077] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0078] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0079] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0080] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A blockchain transaction anomaly detection method based on relational knowledge graphs, characterized in that, The method is applied to a detection server, which connects to a blockchain network and acts as a monitoring node of the blockchain network. The method includes: If a transaction request initiated by a user within the blockchain network is received, the basic node feature information corresponding to the transaction request is obtained from the pre-stored related knowledge graph; Based on the basic node feature information, the transaction request is parsed to obtain the corresponding transaction path information; The transaction path information is validated according to the preset path validation rules to obtain the corresponding path validation result. If the path verification result is successful, the associated transaction node information corresponding to the basic node feature information is obtained from the associated knowledge graph according to the preset association judgment rules. Based on a pre-set correlation analysis model, correlation analysis is performed on the basic node feature information and the related transaction node information to obtain the corresponding correlation analysis information; The transaction request is subjected to anomaly detection based on the preset anomaly detection model and the correlation analysis information to obtain the corresponding anomaly detection results; If the anomaly detection result is no anomaly, the exchange payment is executed according to the transaction request, and the corresponding transaction log is generated and stored in a distributed manner.

2. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 1, characterized in that, The step of parsing the transaction request based on the basic node feature information to obtain the corresponding transaction path information includes: Construct a root node corresponding to the basic node feature information; The leaf node corresponding to the transaction request is obtained from the associated knowledge graph and added to the root node, thereby constructing a transaction tree structure; Obtain the node attributes of the leaf nodes in the transaction tree structure to get the corresponding transaction path information.

3. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 1 or 2, characterized in that, The step of performing path verification on the transaction path information according to preset path verification rules to obtain the corresponding path verification result includes: The integrity of the transaction path information is verified according to the path compliance parameters in the path verification rules to obtain the integrity verification result of whether the path is complete. The transaction path information is sequentially verified according to the path dependency parameters in the path verification rules to obtain the sequential verification result of whether the path order is correct. By combining the integrity verification results and the sequence verification results, a path verification result indicating whether the path passes is obtained.

4. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 3, characterized in that, The step of obtaining related transaction node information corresponding to the basic node feature information from the related knowledge graph according to the preset association judgment rules includes: Based on the association judgment rules, obtain the associated transaction nodes in the associated knowledge graph that correspond to the feature information of the basic nodes; Obtain the node characteristic data of the associated transaction nodes as the corresponding associated transaction node information.

5. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 4, characterized in that, The step of performing correlation analysis on the basic node feature information and the related transaction node information according to a preset correlation analysis model to obtain corresponding correlation analysis information includes: The corresponding first feature vector is extracted from the associated transaction node information; The corresponding second feature vector is extracted from the basic node feature information; The first feature vector and the second feature vector are analyzed using the association analysis model to obtain the corresponding association analysis information.

6. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 5, characterized in that, The step of performing anomaly detection on the transaction request based on the preset anomaly detection model and the correlation analysis information to obtain the corresponding anomaly detection results includes: The attention network of the anomaly detection model is configured based on the correlation coefficients in the correlation analysis information; Obtain the request feature vector corresponding to the transaction request; Anomaly detection is performed on the request feature vector using an anomaly detection model configured with an attention network, and the corresponding anomaly detection results are obtained.

7. The blockchain transaction anomaly detection method based on relational knowledge graphs according to claim 6, characterized in that, After executing the exchange payment according to the transaction request and generating the corresponding transaction log for distributed storage, the process also includes: The associated knowledge graph is updated based on the transaction logs.

8. A blockchain transaction anomaly detection device based on a relational knowledge graph, characterized in that, The device is configured in a detection server, which is connected to a blockchain network and acts as a monitoring node of the blockchain network. The device is used to execute the blockchain transaction anomaly detection method based on a relational knowledge graph as described in any one of claims 1-7. The device includes: The basic node feature information acquisition unit is used to acquire basic node feature information corresponding to the transaction request from a pre-stored related knowledge graph if a transaction request initiated by a user in the blockchain network is received. The transaction path information acquisition unit is used to parse the transaction request based on the basic node feature information to obtain the corresponding transaction path information. The path verification result acquisition unit is used to perform path verification on the transaction path information according to the preset path verification rules and obtain the corresponding path verification result. The associated transaction node information acquisition unit is used to acquire associated transaction node information corresponding to the basic node feature information from the associated knowledge graph according to the preset association judgment rules if the path verification result is passed. The association analysis unit is used to perform association analysis on the basic node feature information and the related transaction node information according to the preset association analysis model to obtain the corresponding association analysis information. An anomaly detection result acquisition unit is used to perform anomaly detection on the transaction request based on a preset anomaly detection model and the correlation analysis information, and obtain the corresponding anomaly detection result; The transaction log storage unit is used to execute the exchange payment according to the transaction request and generate the corresponding transaction log for distributed storage if the anomaly detection result is no anomaly.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the blockchain transaction anomaly detection method based on the association knowledge graph as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions that, when executed by a processor, cause the processor to perform the blockchain transaction anomaly detection method based on a relational knowledge graph as described in any one of claims 1-7.

Images