A decentralized cross-chain transaction tracking method, device, equipment and storage medium

Abstract

The application discloses a kind of decentralized cross-chain transaction tracking method, device, equipment and storage medium, method includes: from each decentralized cross-chain bridge platform acquisition cross-chain bridge transaction information;According to cross-chain bridge transaction information, the function semantic feature and structural feature of transaction process are extracted respectively, and deposit transaction identification is carried out according to function semantic feature and structural feature using preset classifier;If the identification result is deposit transaction, then cross-chain entity information is extracted according to source chain deposit transaction using preset head and tail boundary prediction method, and source chain deposit metadata is obtained, and source chain deposit transaction is obtained according to deposit identification result screening;According to preset business rules and source chain deposit transaction, target chain withdrawal transaction is matched for source chain deposit metadata in pre-set candidate withdrawal transaction.This application can solve the technical problems that most of the prior art do not support token asset cross-chain transfer, do not support historical transaction query, and have strong dependence on bridge API, resulting in weak actual tracking function and poor effect.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a decentralized cross-chain transaction tracking method, apparatus, device, and storage medium. Background Technology

[0002] Cross-chain bridge transaction tracing refers to the uniquely identifiable transactions executed by a cross-chain bridge on both the source and target chains. Solving this research problem can improve the traceability of cross-chain bridge applications. The issue of cross-chain bridge transaction tracing is of paramount concern to cross-chain bridge developers, regulators, and ordinary users. For bridge developers, the lack of cross-chain transaction tracing technology can lead to difficulties in detecting token leakage vulnerabilities in cross-chain bridges, potentially triggering bridge attacks. Furthermore, the lack of efficient cross-chain transaction tracing tools allows malicious actors to exploit cross-chain bridges to obfuscate and transfer illicit assets, posing compliance risks to cross-chain bridge developers. For regulators, tracking money laundering transactions on cross-chain bridge applications becomes challenging, impacting the overall financial security of the DeFi ecosystem. For ordinary users of cross-chain bridges, the difficulty in uniformly and quickly tracking cross-chain transactions affects user experience and confidence. In conclusion, researching the issue of cross-chain bridge transaction tracing is crucial for all stakeholders involved in cross-chain bridge applications.

[0003] Most current cross-chain bridge transaction tracking technologies do not support cross-chain transfer of token assets, do not support historical transaction queries, and are highly dependent on bridge APIs, resulting in weak actual tracking functions and poor performance. They are also difficult to widely support transaction associations of various cross-chain bridges and cannot well meet the transaction tracking needs on DeFi cross-chain bridges. Summary of the Invention

[0004] This application provides a decentralized cross-chain transaction tracking method, device, equipment, and storage medium to solve the technical problems that most existing technologies do not support cross-chain transfer of token assets, do not support historical transaction queries, and are highly dependent on bridge APIs, resulting in weak actual tracking functions and poor performance.

[0005] In view of this, the first aspect of this application provides a decentralized cross-chain transaction tracking method, including:

[0006] Cross-chain bridge transaction information is collected from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram.

[0007] Based on the cross-chain bridge transaction information, the functional semantic features and structural features of the transaction process are extracted respectively, and a preset classifier is used to judge the deposit transaction based on the functional semantic features and the structural features to obtain the deposit identification result;

[0008] If the deposit identification result is a deposit transaction, then the preset head and tail boundary prediction method is used to extract cross-chain entity information based on the source chain deposit transaction to obtain source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result.

[0009] Based on preset business rules and the source chain deposit transaction, a target chain withdrawal transaction is matched with the source chain deposit metadata from the preset candidate withdrawal transactions.

[0010] Preferably, the step of extracting functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and using a preset classifier to judge the deposit transaction based on the functional semantic features and the structural features to obtain the deposit identification result includes:

[0011] Based on the cross-chain bridge transaction information, extract the called function information and map it into function text;

[0012] The function text is converted into an embedded representation using the CodeBert natural language model to obtain the function's semantic features;

[0013] The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, and structural features are generated.

[0014] The semantic features of the function and the structural features, which are concatenated into a comprehensive feature vector, are input into a preset classifier for binary classification of deposit transactions to obtain deposit identification results, which include non-deposit transactions and deposit transactions.

[0015] Preferably, if the deposit identification result is a deposit transaction, a preset head-and-tail boundary prediction method is used to extract cross-chain entity information based on the source chain deposit transaction to obtain source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result, including:

[0016] If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction;

[0017] Based on the Bert model and BiLSTM, a preset head and tail boundary prediction method is used to extract cross-chain entity information from the logs of the source chain deposit transactions to obtain source chain deposit metadata.

[0018] Preferably, the step of matching the source chain deposit metadata with the target chain withdrawal transaction based on preset business rules and the source chain deposit transaction in a preset candidate withdrawal transaction includes:

[0019] The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules;

[0020] Based on the asset type matching rules, a first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions;

[0021] Based on the transaction time matching rules, second candidate withdrawal transactions within the transaction time limit are selected from the first candidate withdrawal transactions according to the time threshold;

[0022] Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and a third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold.

[0023] The third candidate withdrawal transaction is used as the target chain withdrawal transaction of the source chain deposit metadata.

[0024] The second aspect of this application provides a decentralized cross-chain transaction tracking device, comprising:

[0025] The information acquisition unit is used to collect cross-chain bridge transaction information from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram.

[0026] The transaction identification unit is used to extract the functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and to use a preset classifier to judge the deposit transaction based on the functional semantic features and the structural features to obtain the deposit identification result.

[0027] The data extraction unit is used to extract cross-chain entity information based on the source chain deposit transaction using a preset head and tail boundary prediction method if the deposit identification result is a deposit transaction, thereby obtaining source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result.

[0028] The transaction matching unit is used to match the target chain withdrawal transaction with the source chain deposit metadata from the preset candidate withdrawal transactions based on preset business rules and the source chain deposit transaction.

[0029] Preferably, the transaction identification unit is specifically used for:

[0030] Based on the cross-chain bridge transaction information, extract the called function information and map it into function text;

[0031] The function text is converted into an embedded representation using the CodeBert natural language model to obtain the function's semantic features;

[0032] The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, and structural features are generated.

[0033] The semantic features of the function and the structural features, which are concatenated into a comprehensive feature vector, are input into a preset classifier for binary classification of deposit transactions to obtain deposit identification results, which include non-deposit transactions and deposit transactions.

[0034] Preferably, the data extraction unit is specifically used for:

[0035] If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction;

[0036] Based on the Bert model and BiLSTM, a preset head and tail boundary prediction method is used to extract cross-chain entity information from the logs of the source chain deposit transactions to obtain source chain deposit metadata.

[0037] Preferably, the transaction matching unit is specifically used for:

[0038] The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules;

[0039] Based on the asset type matching rules, a first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions;

[0040] Based on the transaction time matching rules, second candidate withdrawal transactions within the transaction time limit are selected from the first candidate withdrawal transactions according to the time threshold;

[0041] Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and a third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold.

[0042] The third candidate withdrawal transaction is used as the target chain withdrawal transaction of the source chain deposit metadata.

[0043] A third aspect of this application provides a decentralized cross-chain transaction tracking device, the device including a processor and a memory;

[0044] The memory is used to store program code and transmit the program code to the processor;

[0045] The processor is used to execute the decentralized cross-chain transaction tracking method described in the first aspect according to the instructions in the program code.

[0046] The fourth aspect of this application provides a computer-readable storage medium for storing program code for executing the decentralized cross-chain transaction tracking method described in the first aspect.

[0047] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0048] This application provides a decentralized cross-chain transaction tracking method, comprising: collecting cross-chain bridge transaction information from various decentralized cross-chain bridge platforms, the cross-chain bridge transaction information including cross-chain bridge link information, transaction-related information, and token call network graph; extracting functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and using a preset classifier to judge deposit transactions based on the functional semantic features and structural features to obtain deposit identification results; if the deposit identification result is a deposit transaction, then using a preset head and tail boundary prediction method to extract cross-chain entity information based on the source chain deposit transaction to obtain source chain deposit metadata, and filtering source chain deposit transactions based on the deposit identification results; matching target chain withdrawal transactions for source chain deposit metadata from preset candidate withdrawal transactions according to preset business rules and source chain deposit transactions.

[0049] The decentralized cross-chain transaction tracking method provided in this application not only considers transaction-related information but also supports the analysis of cross-chain token transfers. Furthermore, combining semantic analysis and network graph structure analysis can determine the source chain deposit transaction status. Transaction tracking based on matching source chain deposit transactions with target chain withdrawal transactions avoids dependence on internal APIs, improving the versatility and generalization of the cross-chain transaction tracking method. In addition, the operation of matching and filtering target chain withdrawal transactions from pre-set candidate withdrawal transactions based on preset business rules and source chain deposit transactions ensures the accuracy of matching and tracking, while significantly reducing data scale and time costs, and supporting historical transaction queries. Therefore, this application can solve the technical problems of existing technologies that mostly do not support cross-chain transfer of token assets, do not support historical transaction queries, and have a strong dependence on bridge APIs, resulting in weak actual tracking functions and poor performance. Attached Figure Description

[0050] Figure 1 A flowchart illustrating a decentralized cross-chain transaction tracking method provided in this application embodiment;

[0051] Figure 2 A schematic diagram of the structure of a decentralized cross-chain transaction tracking device provided in this application embodiment;

[0052] Figure 3 A schematic diagram illustrating a practical application architecture example of the decentralized cross-chain transaction tracking method provided in this application. Detailed Implementation

[0053] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0054] For easier understanding, please refer to Figure 1 An embodiment of a decentralized cross-chain transaction tracking method provided in this application includes:

[0055] Step 101: Collect cross-chain bridge transaction information from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram.

[0056] It should be noted that cross-chain bridge transaction information collected from various decentralized cross-chain bridge platforms can be stored in a MongoDB NoSQL database. The corresponding cross-chain bridge transaction information can be divided into link information and transaction-related information. Link information includes hyperlinks to the cross-chain bridge's official website, hyperlinks to the cross-chain bridge's documentation, and the contract addresses and tags of the cross-chain bridge on different chains. Transaction-related information includes basic transaction information and related transaction information. By constructing a token call network using internal and external transactions, a token call network graph can be obtained; the acquired data can be stored in the Galaxybase graph database.

[0057] Furthermore, the blockchains involved in decentralized cross-chain bridges are based on distributed public ledgers, whose public blockchains store all transaction records occurring on the corresponding blockchain platform, ensuring a complete and observable data source. Moreover, basic transaction information includes, but is not limited to, the blockchain on which the transaction occurred, the transaction hash, the transaction sender, the transaction receiver, the transaction sending time, the transaction assets, the transaction amount, the transaction input binary code, and the transaction event log.

[0058] Step 102: Extract the functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and use a preset classifier to judge the deposit transaction based on the functional semantic features and structural features to obtain the deposit identification result.

[0059] Further, step 102 includes:

[0060] Extract the called function information from the cross-chain bridge transaction information and map it to function text;

[0061] The function text is converted into an embedded representation using the CodeBert natural language model to obtain the semantic features of the function;

[0062] The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, generating structural features.

[0063] The semantic and structural features of the function, which are concatenated into a comprehensive feature vector, are input into a preset classifier for binary classification of deposit transactions to obtain deposit identification results, which include non-deposit transactions and deposit transactions.

[0064] It should be noted that the deposit transaction identification process extracts relevant semantic and structural features based on the cross-chain bridge contract and transaction tags, and determines the task of the deposit transaction accordingly. By parsing the binary code of the transaction input, the information of the called functions is obtained based on the cross-chain bridge transaction information. This called function information includes, but is not limited to, function name, parameter name, and parameter type. This called function information is then encoded and mapped into a textual representation. Specifically, the hexadecimal string of the transaction input is parsed using an interface provided by a third-party web3 client library, and the called function information contained in the string is uniformly represented as... .in, Indicates the function name. Representing a list format, Indicates the parameter name. This represents the parameter values. Based on a unified representation, and considering the effectiveness of semantic extraction, parameter names are normalized: the original function names are retained, all parameter values ​​are ignored, and other parameter names unrelated to the subsequent cross-chain transaction metadata are mapped to... :

[0065]

[0066] in, It is a normalization function. This represents the normalized parameter name related to key deposit information. This is a set of normalized parameter names.

[0067] Based on normalization, the predefined parameter mapping formula above can be used to convert the transaction's invoked function information into text, i.e., function text. Then, Microsoft's CodeBert natural language model is used to convert the function text into an embedded representation with function semantic information, yielding the function semantic features F. It is understandable that the model is pre-trained and optimized to ensure semantic extraction performance.

[0068] Structural features are information obtained from statistics in the token call network graph. In this embodiment, the MoTS network module algorithm is used to count the number of occurrences of 16 specific modules in the token call network subgraph, and the 16-dimensional vector formed by the statistical results is used as the structural feature S of the transaction.

[0069] By concatenating the extracted semantic features F and structural features S into vectors, a comprehensive feature vector can be obtained. The data is input into a preset classifier for deposit transaction analysis, and the results are categorized as non-deposit transactions and deposit transactions. Therefore, the preset classifier is a binary classifier. Furthermore, the preset classifier in this embodiment uses a random forest classifier. Other more efficient and reliable classifiers can be substituted; this is merely an example and not a limitation.

[0070] Step 103: If the deposit identification result is a deposit transaction, the preset head and tail boundary prediction method is used to extract cross-chain entity information based on the source chain deposit transaction to obtain the source chain deposit metadata. The source chain deposit transaction is selected based on the deposit identification result.

[0071] Further, step 103 includes:

[0072] If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction;

[0073] Based on the Bert model and BiLSTM, a pre-defined head and tail boundary prediction method is used to extract cross-chain entity information from the logs of source chain deposit transactions to obtain source chain deposit metadata.

[0074] It should be noted that if the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transactions. The log text information of the source chain deposit transactions can be used to extract relevant entity information; this embodiment uses the BERT model to obtain the contextual embedding representation from the log text information. Using BiLSTM to learn perceptual representations of text sentences And by using additive concatenation, a multi-granularity fused text embedding representation is obtained. :

[0075]

[0076] The perception of text sentences can yield context-aware representations. .

[0077] Next, a pre-defined head and tail boundary prediction method is used to calculate and predict the tail marker using the Sigmoid function:

[0078]

[0079] in, , These represent the learning weights and learning biases in the prediction process, respectively. This is the context-aware embedding representation for the i-th position. Based on the predicted tail tag, the head tag of the key cross-chain information entity is predicted; a conditional normalization layer is used to process each type of cross-chain information to generate a high-quality conditional vector. Provides additional contextual information:

[0080]

[0081]

[0082]

[0083] in, For conditional vectors, For the input vector, The mean, For variance, , All are learning weights. , All are learning biases. For vector dimensions, , All of these are intermediate learnable parameters.

[0084] For each preset tail vector obtained above ,generate Embedded representation:

[0085]

[0086] based on Embedded representation, calculate the prediction head label:

[0087]

[0088] in, The header tag represents the vector. Based on the predicted tail tag and predicted header tag, the corresponding cross-chain key entity information is extracted to obtain the source chain deposit metadata. .

[0089] Step 104: Based on the preset business rules and source chain deposit transactions, match the target chain withdrawal transactions for the source chain deposit metadata in the preset candidate withdrawal transactions.

[0090] Further, step 104 includes:

[0091] The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules;

[0092] Based on the asset type matching rules, the first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions;

[0093] Based on the transaction time matching rules, the second candidate withdrawal transaction within the transaction time limit is selected from the first candidate withdrawal transactions according to the time threshold;

[0094] Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and the third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold.

[0095] The third candidate withdrawal transaction is used as the target chain withdrawal transaction in the source chain's deposit metadata.

[0096] It should be noted that the preset business rules in this embodiment include, but are not limited to, the three rules mentioned above. More relevant rules can be set according to actual conditions to help determine the withdrawal transactions on the target chain more quickly and accurately. In addition, the preset candidate withdrawal transactions are information obtained in advance on the target chain; and by performing hierarchical filtering based on multiple different business rules, withdrawal transactions that match deposit transactions can be found.

[0097] The screening process for the first candidate withdrawal transaction is an asset type matching process. The withdrawal transactions with the same asset type as the source chain deposit transactions are selected from the pre-set candidate withdrawal transactions. Generally, there will be multiple withdrawal transactions that meet the conditions, which will be selected as the first candidate withdrawal transactions.

[0098] Then, the transaction timestamps of the first candidate withdrawal transactions were analyzed. According to the cross-chain transaction business logic of the cross-chain bridge app, withdrawal transactions are typically completed within 30 minutes or less after the deposit transaction is confirmed. Based on the transaction timestamp information, time constraints were filtered. Candidate transactions with a time threshold less than 30 minutes are considered. If the time threshold is set at 30 minutes, and no candidate transaction occurs, an additional 10% of the time is added. This process continues iteratively until a target chain transaction that meets the criteria is identified, i.e., the second candidate withdrawal transaction. At this point, multiple transactions may meet the criteria.

[0099] Next, based on the transaction amount matching rules, the transaction fee percentage is calculated according to the transaction amount information in the source chain deposit metadata. Then, based on the transaction fee percentage and its threshold, a third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions. This is because, according to the business logic of cross-chain transactions, cross-chain transaction fees typically account for approximately 0%-3% of the deposit transaction amount. The transaction fee percentage can be calculated based on the transaction amount information.

[0100]

[0101] in, Metadata for source chain deposits, For the transaction amount, , These are the source chain and the target chain, respectively.

[0102] There are two percentage thresholds, which constitute the percentage range. In other words, choose the percentage of transaction fees. The candidate transaction was selected as the third candidate withdrawal transaction, namely the target chain withdrawal transaction based on the source chain's deposit metadata. Because... There may be special cases where the percentage is greater than 3%, so we will use 3% as the percentage here. The lower limit, 100% as The upper limit is gradually relaxed, and the candidate transactions are also screened. Under normal circumstances, after screening according to the above preset business rules, the number of target chain withdrawal transactions can be obtained. If no target chain withdrawal transactions are found, the screening conditions can be relaxed to expand the search space; if there are more than one target chain withdrawal transaction, the screening conditions can be tightened to narrow the search space until a matching source chain deposit transaction and target chain withdrawal transaction are obtained.

[0103] For easier understanding, please refer to the following for applying the decentralized cross-chain transaction tracking method of this application to specific scenarios. Figure 3 This system allows for data analysis and information processing at the data layer, algorithm layer, business logic layer, and view layer, enabling cross-chain transaction tracking. Cross-chain bridge transaction information obtained from various cross-chain bridge platforms is passed through the data layer interface. Input data channel information can be placed into a message queue to achieve asynchronous requests. The algorithm layer and business logic layer listen to the queue and process the requests themselves, thus improving response speed. The information extraction and data processing process relies on the AMQP asynchronous communication protocol. Furthermore, based on the interface provided by the algorithm layer, cross-chain transaction pair information is obtained. Using the FastAPI backend framework, combined with Nginx load balancing technology and Uvicorn asynchronous concurrency, a query and access interface related to cross-chain transactions is provided to the view layer. The view layer, by calling the interface provided by the business logic layer, provides users with functions for querying cross-chain bridge information, cross-chain transaction status, and real-time cross-chain transaction monitoring.

[0104] The decentralized cross-chain transaction tracking method provided in this application not only considers transaction-related information but also supports the analysis of cross-chain token transfers. Furthermore, combining semantic analysis and network graph structure analysis can determine the source chain deposit transaction status. Transaction tracking based on matching source chain deposit transactions with target chain withdrawal transactions avoids reliance on internal APIs, improving the versatility and generalization of the cross-chain transaction tracking method. Additionally, the operation of matching and filtering target chain withdrawal transactions from pre-set candidate withdrawal transactions based on preset business rules and source chain deposit transactions ensures the accuracy of matching and tracking, while significantly reducing data scale and time costs, and supporting historical transaction queries. Therefore, this application's embodiments can solve the technical problems of existing technologies that mostly do not support cross-chain transfer of token assets, do not support historical transaction queries, and have a strong dependence on bridge APIs, resulting in weak actual tracking functions and poor performance.

[0105] For easier understanding, please refer to Figure 2 This application provides an embodiment of a decentralized cross-chain transaction tracking device, comprising:

[0106] The information acquisition unit 201 is used to collect cross-chain bridge transaction information from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram.

[0107] The transaction identification unit 202 is used to extract the functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and to use a preset classifier to judge the deposit transaction based on the functional semantic features and structural features to obtain the deposit identification result.

[0108] The data extraction unit 203 is used to extract cross-chain entity information based on the source chain deposit transaction by using a preset head and tail boundary prediction method if the deposit identification result is a deposit transaction, thereby obtaining the source chain deposit metadata. The source chain deposit transaction is selected based on the deposit identification result.

[0109] The transaction matching unit 204 is used to match the target chain withdrawal transaction with the source chain deposit metadata from the preset candidate withdrawal transactions based on the preset business rules and the source chain deposit transaction.

[0110] Furthermore, the transaction identification unit 202 is specifically used for:

[0111] Extract the called function information from the cross-chain bridge transaction information and map it to function text;

[0112] The function text is converted into an embedded representation using the CodeBert natural language model to obtain the semantic features of the function;

[0113] The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, generating structural features.

[0114] The semantic and structural features of the function, which are concatenated into a comprehensive feature vector, are input into a preset classifier for binary classification of deposit transactions to obtain deposit identification results, which include non-deposit transactions and deposit transactions.

[0115] Furthermore, the data extraction unit 203 is specifically used for:

[0116] If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction;

[0117] Based on the Bert model and BiLSTM, a pre-defined head and tail boundary prediction method is used to extract cross-chain entity information from the logs of source chain deposit transactions to obtain source chain deposit metadata.

[0118] Furthermore, the transaction matching unit 204 is specifically used for:

[0119] The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules;

[0120] Based on the asset type matching rules, the first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions;

[0121] Based on the transaction time matching rules, the second candidate withdrawal transaction within the transaction time limit is selected from the first candidate withdrawal transactions according to the time threshold;

[0122] Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and the third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold.

[0123] The third candidate withdrawal transaction is used as the target chain withdrawal transaction in the source chain's deposit metadata.

[0124] This application also provides a decentralized cross-chain transaction tracking device, which includes a processor and a memory;

[0125] The memory is used to store program code and transfer the program code to the processor;

[0126] The processor is used to execute the decentralized cross-chain transaction tracking method in the above method embodiments according to the instructions in the program code.

[0127] This application also provides a computer-readable storage medium for storing program code for executing the decentralized cross-chain transaction tracking method in the above method embodiments.

[0128] In the several embodiments provided in this application, 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 instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0129] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0131] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, 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 for executing all or part of the steps of the methods described in the various embodiments of this application through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0132] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A decentralized cross-chain transaction tracking method, characterized in that, include: Cross-chain bridge transaction information is collected from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram. Based on the cross-chain bridge transaction information, functional semantic features and structural features of the transaction process are extracted respectively. A preset classifier is then used to judge the deposit transaction based on the functional semantic features and the structural features to obtain the deposit identification result, specifically including: Based on the cross-chain bridge transaction information, extract the called function information and map it into function text; The function text is converted into an embedded representation using the CodeBert natural language model to obtain the function's semantic features; The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, and structural features are generated. The semantic features of the function and the structural features, which are concatenated into a comprehensive feature vector, are input into a preset classifier to perform binary classification of deposit transactions, thereby obtaining a deposit identification result. The deposit identification result includes non-deposit transactions and deposit transactions. If the deposit identification result is a deposit transaction, then the preset head and tail boundary prediction method is used to extract cross-chain entity information based on the source chain deposit transaction to obtain source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result. Based on preset business rules and the source chain deposit transaction, a target chain withdrawal transaction is matched with the source chain deposit metadata from the preset candidate withdrawal transactions.

2. The decentralized cross-chain transaction tracking method according to claim 1, characterized in that, If the deposit identification result is a deposit transaction, then a preset head-and-tail boundary prediction method is used to extract cross-chain entity information based on the source chain deposit transaction to obtain source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result, including: If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction; Based on the Bert model and BiLSTM, a preset head and tail boundary prediction method is used to extract cross-chain entity information from the logs of the source chain deposit transactions to obtain source chain deposit metadata.

3. The decentralized cross-chain transaction tracking method according to claim 1, characterized in that, The step of matching the source chain deposit metadata with the target chain withdrawal transaction based on preset business rules and the source chain deposit transaction includes: The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules; Based on the asset type matching rules, a first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions; Based on the transaction time matching rules, second candidate withdrawal transactions within the transaction time limit are selected from the first candidate withdrawal transactions according to the time threshold; Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and a third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold. The third candidate withdrawal transaction is used as the target chain withdrawal transaction of the source chain deposit metadata.

4. A decentralized cross-chain transaction tracking device, characterized in that, include: The information acquisition unit is used to collect cross-chain bridge transaction information from various decentralized cross-chain bridge platforms. The cross-chain bridge transaction information includes cross-chain bridge link information, transaction-related information, and token call network diagram. The transaction identification unit is used to extract the functional semantic features and structural features of the transaction process based on the cross-chain bridge transaction information, and to use a preset classifier to judge the deposit transaction based on the functional semantic features and the structural features to obtain the deposit identification result. Specifically, the transaction identification unit is used for: Based on the cross-chain bridge transaction information, extract the called function information and map it into function text; The function text is converted into an embedded representation using the CodeBert natural language model to obtain the function's semantic features; The network motif algorithm is used to count the number of times a specific motif appears in the token call network graph, and structural features are generated. The semantic features of the function and the structural features, which are concatenated into a comprehensive feature vector, are input into a preset classifier to perform binary classification of deposit transactions, thereby obtaining a deposit identification result. The deposit identification result includes non-deposit transactions and deposit transactions. The data extraction unit is used to extract cross-chain entity information based on the source chain deposit transaction using a preset head and tail boundary prediction method if the deposit identification result is a deposit transaction, thereby obtaining source chain deposit metadata. The source chain deposit transaction is obtained by filtering based on the deposit identification result. The transaction matching unit is used to match the target chain withdrawal transaction with the source chain deposit metadata from the preset candidate withdrawal transactions based on preset business rules and the source chain deposit transaction.

5. The decentralized cross-chain transaction tracking device according to claim 4, characterized in that, The data extraction unit is specifically used for: If the deposit identification result is a deposit transaction, then the deposit transaction information on the source chain is filtered out based on the deposit identification result to obtain the source chain deposit transaction; Based on the Bert model and BiLSTM, a preset head and tail boundary prediction method is used to extract cross-chain entity information from the logs of the source chain deposit transactions to obtain source chain deposit metadata.

6. The decentralized cross-chain transaction tracking device according to claim 4, characterized in that, The transaction matching unit is specifically used for: The preset business rules include asset type matching rules, transaction time matching rules, and transaction amount matching rules; Based on the asset type matching rules, a first candidate withdrawal transaction with the same asset type as the source chain deposit transaction is selected from the pre-set candidate withdrawal transactions; Based on the transaction time matching rules, second candidate withdrawal transactions within the transaction time limit are selected from the first candidate withdrawal transactions according to the time threshold; Based on the transaction amount matching rules, the transaction fee ratio is calculated according to the transaction amount information in the source chain deposit metadata, and a third candidate withdrawal transaction within the transaction amount constraint is selected from the second candidate withdrawal transactions based on the transaction fee ratio and the ratio threshold. The third candidate withdrawal transaction is used as the target chain withdrawal transaction of the source chain deposit metadata.

7. A decentralized cross-chain transaction tracking device, characterized in that, The device includes a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the decentralized cross-chain transaction tracking method according to any one of claims 1-3 according to the instructions in the program code.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for executing the decentralized cross-chain transaction tracking method according to any one of claims 1-3.

Images