Blockchain address entity recognition method and device based on multi-stage heuristic

Abstract

The application discloses a kind of based on multi-stage heuristic's blockchain address entity identification method and equipment, including extracting key field containing UTXO level information from original blockchain data;Original blockchain data is reorganized into standardized table;Directed bipartite graph is constructed;Transaction in graph is divided into simple transaction and complex transaction;All transactions are sorted according to timestamp from small to large, for simple transaction, simple heuristic fast clustering is carried out by applying high credibility rule;Complex heuristic rule is executed to remaining transaction, and fine entity identification is realized;Address set triggered by simple heuristic and complex heuristic rule is merged into unified entity, and complete address-entity mapping table is output.The application significantly improves address clustering accuracy, can identify complex transaction mode, fills the processing blank of privacy-enhanced transaction for existing method, quickly processes explicit transaction by simple heuristic, complex heuristic finely processes difficult transaction, and overall computing efficiency is significantly improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain transaction technology, and in particular to a blockchain address entity identification method and device based on multi-stage heuristics. Background Technology

[0002] As the blockchain ecosystem rapidly expands, on-chain behavioral analysis is becoming increasingly important in areas such as transaction auditing, address entity identification, and regulatory technology. In recent years, reconstructing transaction graphs, identifying address-owned entities, and recovering true fund paths from massive amounts of blockchain data have become key challenges for both academia and industry.

[0003] Existing blockchain address clustering and entity recognition methods mainly suffer from the following problems:

[0004] (1) Insufficient accuracy of single heuristic: Existing methods usually use a single heuristic rule (such as "common input address heuristic" or "change address heuristic"), which is prone to incorrect clustering due to transaction types such as topological confusion, batch payment, and address reuse, and incorrectly merges unrelated addresses into the same entity.

[0005] (2) Lack of a hierarchical processing mechanism: Existing methods do not differentiate the processing priority between simple and complex transactions, leading to a waste of computational resources. Simple transactions (such as initial block incentive transactions, merge transactions, and standard payments) can be directly identified through fast rules, while complex transactions (such as transactions with change and topology confusion transactions) require more refined multi-rule judgments. Confusion processing results in low overall identification efficiency and is prone to misjudgment in complex transactions.

[0006] (3) Single rule for identifying change address: Existing methods usually only use the single rule of "unique new address" to identify change, ignoring multi-dimensional information such as address reuse, input necessity, rounding characteristics of transaction value, and frequency of historical use of address, resulting in low recall rate and high false positive rate for change identification.

[0007] (4) Insufficient ability to handle topology-obfuscated transactions: For privacy-enhancing transactions such as topology-obfuscated transactions, existing methods lack explicit identification mechanisms and pollution analysis capabilities. They either completely abandon clustering (causing omissions in entity identification) or incorrectly merge the addresses of all participants (causing large-scale incorrect clustering), failing to achieve a balance between deanonymization and accuracy. Summary of the Invention

[0008] To address the shortcomings of existing blockchain address entity recognition technologies, such as insufficient accuracy of single heuristics, lack of hierarchical processing mechanisms, simplistic change-finding rules, and inadequate ability to handle topologically confused transactions, this invention proposes a blockchain address entity recognition method and device based on multi-stage heuristics. Through block parsing, transaction graph construction, transaction type identification, hierarchical heuristic clustering, multi-rule change-finding detection, and topologically confused transaction pollution analysis, it achieves high-precision and scalable blockchain address entity recognition.

[0009] This invention first provides a blockchain address entity identification method based on a multi-stage heuristic, comprising the following steps:

[0010] Extract key fields containing UTXO (Unspent Transaction Output) level information from the raw blockchain data to provide a basic data source for accurately identifying which addresses belong to the same entity.

[0011] Distributed data acquisition is used to reorganize the original blockchain data into a standardized table, which includes a transaction node table, a UTXO flow edge table, and an address table.

[0012] Construct a directed bipartite graph G=(V,E), where the node set V includes transaction nodes and address nodes, and each directed edge in the edge set E represents the cost relationship of a UTXO, that is, from an address node to a transaction node or from a transaction node to an address node.

[0013] The transactions in Figure G are divided into simple transactions and complex transactions. A simple transaction is a transaction that meets one of the following conditions:

[0014] (a) Initial block incentive transactions;

[0015] (b) Transactions with a single output address;

[0016] (c) Output transactions with a total of 2 addresses;

[0017] (d) Transactions with 1 input address, no more than 3 output addresses, and containing only a basic payment script; the basic payment script is a script type used for direct value transfer and does not contain conditional execution, multi-signature, or topology obfuscation structures.

[0018] The complex transaction refers to any transaction other than the simple transaction.

[0019] Based on graph G, auxiliary functions and data structures are constructed to help with entity identification; all transactions are sorted by timestamp from smallest to largest; for the simple transactions, a simple heuristic fast clustering is performed using high-confidence rules; the remaining transactions are traversed again by time sequence index from smallest to largest, and then complex heuristic rules are executed to achieve refined entity recognition.

[0020] The addresses triggered by simple and complex heuristics are merged into a unified entity, and a complete address-entity mapping table is output.

[0021] Preferably, the key fields also include block-level information, transaction-level information, and an identifier field, wherein the identifier field is used to identify the signature of the verification node.

[0022] Preferably, the UTXO flow edge table records all spending relationships, including source node identifier, target node identifier, source location, target location, address, and transaction value, for constructing address-transaction association relationships.

[0023] Furthermore, transactions with one output address are classified as merged transactions, transactions with two output addresses are classified as standard payment transactions, and transactions with one input address, no more than three output addresses, and containing only the basic payment script are classified as single-input low-output transactions.

[0024] Preferably, the auxiliary functions include an input / output address set function, used to extract a unique address set by traversing all incoming and outgoing edges of a transaction, and a transaction in-degree / out-degree function, used to return the number of input / output addresses; the data structure includes an address metadata dictionary and a transaction metadata dictionary.

[0025] Preferably, the execution of complex heuristic rules on the remaining transactions includes identifying and deanonymizing topologically confused transactions, and identifying transactions involving change.

[0026] More preferably, a non-initial block incentive transaction is determined to be a topology confusion transaction when it meets the following conditions: all input addresses are different from the currently known clusters; the number of output addresses is ≥10.

[0027] Furthermore, the identification of transactions involving change includes applying the following rules in sequence: address reuse rule, input redundancy rule, new address rule, rounding number rule, and address low reuse rule. When any rule generates a unique candidate address, the change address is merged with all input addresses into the same cluster to achieve complete entity identification of the transaction. If no rule is matched or multiple candidates are generated, the change identification of the transaction is abandoned.

[0028] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, characterized in that, when the processor executes the program, it implements the steps of the multi-stage heuristic blockchain address entity identification method described in any of the above technical solutions.

[0029] The beneficial effects of this invention are reflected in:

[0030] (1) Significantly improve the accuracy of address clustering: By combining two-stage heuristics and five-rule cascade zero-finding detection, the erroneous clustering caused by a single heuristic is greatly reduced, and the entity recognition accuracy is significantly improved compared with traditional methods;

[0031] (2) It can identify complex transaction patterns: It can explicitly identify and process complex transaction types such as topology confusion transactions, bidirectional input aggregation transactions, batch payments, and multiple change strategies, filling the gap in the processing of privacy-enhancing transactions in existing methods;

[0032] (3) Efficient hierarchical processing mechanism: Simple heuristics are used to quickly process clear transactions, while complex heuristics are used to process difficult transactions in detail, resulting in a significant improvement in overall computational efficiency;

[0033] (4) End-to-end complete process: from data collection → transaction graph construction → transaction type identification → hierarchical heuristic clustering → application visualization, realizes an integrated solution for on-chain entity identification, which can be directly deployed in actual business scenarios such as transaction auditing and risk assessment. Attached Figure Description

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

[0035] Figure 1 This is a flowchart of a multi-stage heuristic blockchain address entity identification method according to an embodiment of the present invention. Detailed Implementation

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

[0037] It should be noted that the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0038] This embodiment proposes a multi-stage heuristic-based blockchain address entity identification method, including the following steps:

[0039] S1. Extract key fields containing UTXO-level information from the raw blockchain data to provide a basic data source for accurately identifying which addresses belong to the same entity.

[0040] Specifically, by calling the public API (Application Programming Interface) or building a self-built full node, the raw block JSON (JavaScript Object Notation) data is obtained block by block, and the following key fields are extracted for subsequent entity recognition:

[0041] Block-level information, including block height, block hash, and timestamp;

[0042] Transaction-level information, including transaction ID, transaction hash, transaction fee, and time-series index;

[0043] UTXO-level information, including the input UTXO list such as previous transactions, previous index, address, transaction value, etc., and the output UTXO list such as address, transaction value, output index, whether it has been spent, etc.

[0044] The identification field includes a hexadecimal-to-ASCII parsing of the first input script for the initial block incentive transaction, used to identify the signature of the validator node.

[0045] The complete UTXO flow relationship obtained in this step is the data foundation for all subsequent entity recognition rules.

[0046] S2. Distributed data acquisition is adopted to reorganize the original blockchain data into a standardized table, which includes a transaction node table, a UTXO flow edge table, and an address table.

[0047] Specifically, by designing a distributed data acquisition module, it can support automated data retrieval from any block range, adapting to the entity analysis needs of different time ranges. Furthermore, it prioritizes high-speed downloading of data from the preprocessed dataset; if this fails, it calls the API in real-time to crawl the data block by block and write it to the local CSV (Comma-Separated Values), ensuring robustness in data acquisition.

[0048] Three standardized tables are generated for entity identification: a transaction node table, which records the transaction hash, block height, transaction fee, number of inputs / outputs, total value of inputs / outputs, and time-series index for each transaction, used for transaction type identification and time-series processing; a UTXO flow edge table, which records all UTXO spending relationships (source node identifier, target node identifier, source location, target location, address, and transaction value), used to construct address-transaction associations; and an address table, which records all deduplicated addresses and their initial cluster identifiers, used for storing and querying entity clustering results.

[0049] S3. Construct a directed bipartite graph G=(V,E), where the node set V includes transaction nodes and address nodes, and each directed edge in the edge set E represents the cost relationship of a UTXO, that is, from an address node to a transaction node or from a transaction node to an address node.

[0050] It should be noted that the transaction nodes include the initial block incentive virtual nodes, and the address nodes include the corresponding addresses of unspent UTXOs. Edge attributes include address, transaction value, source location, and destination location, fully preserving the UTXO transaction value and location information.

[0051] S4. Divide the transactions in graph G into simple transactions and complex transactions, that is, perform rapid statistical analysis on graph G to provide a basis for decision-making in subsequent phased heuristic processing.

[0052] (1) First, extract the set of input / output addresses, transaction fees, and total input / output transaction values ​​for each transaction as necessary input data for subsequent rule judgment.

[0053] (2) Next, identify several simple transaction types, including but not limited to:

[0054] The initial block incentive transaction identification checks whether there are nodes with specific protocol layer generated identifiers in the input. If so, the output address of such transactions belongs to the verification node.

[0055] Genesis node transaction identification requires that the initial block incentive transaction be met and the block height be <19500. This is the accounting reward. These addresses are assigned to the genesis node cluster to prevent misjudgment as ordinary node collaboration clusters.

[0056] Merged transaction identification: This type of transaction outputs 1 address, indicating that the user merges assets from multiple addresses into one address. All input addresses belong to the same entity, and no change check is required subsequently.

[0057] Standard payment transaction identification outputs two addresses, which is a typical scenario of "one receiving address + one change address";

[0058] Single-input low-output transactions are transactions with one input address and no more than three output addresses. They contain only a basic payment script and are simple forwarding or small-amount distribution transactions. The basic delivery script is used for direct value transfer and does not contain scripts with conditional execution, multi-signature, or topology obfuscation structures.

[0059] Other transactions besides those mentioned above are considered complex transactions, such as: high-input high-output transactions (number of input addresses greater than or equal to 2 and number of output addresses greater than or equal to 3), high-output transactions (number of input addresses is 1 and number of output addresses greater than or equal to 4), transactions containing complex logic scripts such as OP_RETURN, multi-signature, bidirectional input aggregation, consumption transactions with potential change, and suspected topology obfuscation transactions that meet the condition of having ≥10 output addresses and inputs from different clusters. These obfuscated transactions aim to hide the flow of funds and are easily misjudged by traditional rules, requiring specialized pollution analysis methods for subsequent processing.

[0060] (3) Count the number of isolated UTXOs to provide a reference for verifying the integrity of entity recognition. If there are too many isolated UTXOs, it may mean that there are omissions in entity recognition.

[0061] The transaction type pre-identification step determines which transactions use simple heuristics and which use complex heuristics.

[0062] S5. Based on graph G, construct auxiliary functions and data structures to help with entity identification; sort all transactions by timestamp from smallest to largest; for the simple transactions, apply high-confidence rules to perform simple heuristic fast clustering; traverse the remaining transactions again by time sequence index from smallest to largest, and then execute complex heuristic rules to achieve refined entity recognition.

[0063] Specifically, the auxiliary functions include an input / output address set function, which is used to extract a unique set of addresses by traversing all incoming and outgoing edges of a transaction, and a transaction in-degree / out-degree function, which is used to return the number of input / output addresses.

[0064] The data structure includes an address metadata dictionary and a transaction metadata dictionary. The address metadata dictionary records the first occurrence time and historical usage count of each address, while the transaction metadata dictionary records the time sequence index and block height of each transaction to avoid logical errors caused by processing later transactions first.

[0065] In particular, by ensuring that the first appearance time of an address is accurately recorded, the historical usage count of an address is correctly accumulated, and the cluster merging operation conforms to the actual timeline of fund flows, entity identification is ensured according to the actual order of transactions, avoiding erroneous judgments caused by timeline confusion.

[0066] The application of high-confidence rules for simple heuristic fast clustering refers to traversing all transactions from smallest to largest according to the time sequence index, and applying the following simple heuristic rules to each transaction to directly complete the identification of entities with clear attribution relationships:

[0067] (1) Genesis node accounting transaction rules: If a transaction is a genesis node accounting transaction (initial block incentive transaction and block height < 19500), all output addresses will be assigned to the genesis node cluster to realize the identification of genesis node entities;

[0068] (2) Normal initial block incentive transaction rules: If the transaction is a normal initial block incentive transaction, all output addresses will be assigned to the same verification node cluster to realize the identification of node collaborative cluster entities;

[0069] (3) Merging transaction rules: If the transaction is a merged transaction, that is, the output address is unique, then according to the multi-input ownership assumption, all input addresses and the unique output address are grouped into the same cluster to realize the entity identification of user fund integration behavior;

[0070] (4) Standard payment transaction rules: If the transaction is a standard payment transaction, i.e., output address = 2, then according to the multiple-input ownership assumption, all input addresses are grouped into the same payer cluster to realize payment entity identification; note that change is not identified at this stage, only the payer is identified.

[0071] It is important to note that whenever the above rules are triggered, the cluster merge function is immediately invoked to merge the historical clusters of the relevant addresses into a single entity and to update the address → cluster mapping table synchronously.

[0072] Applying complex heuristics to the remaining transactions specifically includes:

[0073] A non-initial block incentive transaction is determined to be a topology obfuscation transaction when it meets the following two conditions: (a) all input addresses are currently known to be different clusters, indicating that multiple parties are involved; (b) the number of output addresses is ≥10, which meets the typical characteristics of obfuscation services.

[0074] For identified topologically obfuscated transactions, perform contamination analysis to achieve partial deanonymization:

[0075] (a) Find the maximum and second largest values ​​from the input transaction values;

[0076] (b) Select addresses from the output transaction values ​​that are strictly within the range of [second largest value, largest value] as candidate change addresses;

[0077] (c) If the candidate address is unique, it is determined that it belongs to the same entity as the address with the largest input transaction value, and the two are grouped into the same cluster to realize the entity identification of the main participants in the topology confusion transaction.

[0078] This step is based on the empirical rule that the largest input in a topologically confused transaction usually obtains change within a range. It achieves partial deanonymization without compromising the privacy of other participants, filling the gap in existing methods that cannot handle topologically confused transactions.

[0079] For transactions involving change that are not topologically confused, the system uses five strictly prioritized rules to integrate multi-dimensional information such as address reuse, transaction value characteristics, time characteristics, and usage frequency to accurately identify the change address, thus solving the problems of "single change identification rules" and "low recall rate and high false positive rate".

[0080] For transactions involving change that are not topologically confusing, the change address identification rules are executed in the following order of priority to achieve accurate entity identification:

[0081] Rule 1 (Address Reuse Rule): If there is an intersection between the input address cluster and the output address cluster, the intersection address is determined to be a change address (based on the common transaction behavior of "returning change to the original address"). Once a match is found, the judgment stops immediately.

[0082] Rule 2 (Input Redundancy Rule): If there is an address in the output whose transaction value is less than at least one input transaction value, then the address is determined to be a change address (based on the economic rationality that "change transaction value is usually less than a single input value"), and the judgment stops immediately after the match is found.

[0083] Rule 3 (New Address Rule): If an address appears for the first time in the output (birthday equals the current transaction time sequence index), then the address is determined to be a change address (based on the privacy protection behavior of "using new addresses for change"). Once a match is found, the judgment stops immediately.

[0084] Rule 4 (Rounding Number Rule): When the output consists of exactly two addresses, if the decimal places of the transaction value at one address are significantly longer than those at the other (e.g., 0.12345678 Unit vs 1.0 Unit), then the address with the longer decimal places is determined to be the change address (based on the user habit of "payment transaction values ​​tending to be rounded"). Once this is hit, the judgment will stop immediately.

[0085] Rule 5 (Low Address Reuse Rule): In the remaining candidate set, if there is an address with a historical usage count ≤ 2, then the address is determined to be a change address (based on the design that "change addresses are usually low reused"). Once a match is found, the judgment stops immediately.

[0086] If and only if any of the above rules generates a unique candidate address, the change address will be forcibly merged with all input addresses into the same cluster to achieve complete entity identification of the consumer transaction. If no rule matches or multiple candidates are generated, the change identification for that transaction will be abandoned to avoid introducing erroneous clustering.

[0087] The five-rule cascaded decision tree, through strict priority sorting, makes full use of multi-dimensional information such as address reuse, transaction value characteristics, time characteristics, and usage frequency, which significantly improves the recall and accuracy of change identification compared to the traditional single "new address rule".

[0088] S6. Merge the address sets triggered by simple and complex heuristic rules into a unified entity and output a complete address-entity mapping table.

[0089] When each rule of the simple heuristic and complex heuristic is triggered, the cluster merging function is immediately called to query the historical cluster to which each address in the current set of addresses to be merged belongs, merge all the historical clusters involved into a single new cluster, and synchronously update the address → cluster mapping table and the cluster → address set table.

[0090] The cluster merging operation is unidirectional and irreversible, ensuring that the entity identification results converge monotonically with the transaction timeline, thus avoiding circular dependencies and logical contradictions.

[0091] After completing a two-phase heuristic traversal of all transactions, a final address-cluster mapping table is output, where each cluster represents an identified blockchain transaction entity. Cluster merging is the execution mechanism for all the aforementioned rules, ensuring the consistency and integrity of entity identification results.

[0092] The multi-stage heuristic blockchain address entity identification method in this embodiment is encapsulated into a directly usable business tool that can support practical application scenarios such as transaction auditing and risk assessment.

[0093] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, characterized in that, when the processor executes the program, it implements the steps of the multi-stage heuristic blockchain address entity identification method described in any of the above technical solutions.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A multi-stage heuristic based blockchain address entity recognition method, characterized in that, The method comprises the following steps: extracting key fields containing UTXO level information from original blockchain data to provide a basic data source for subsequent accurate identification of which addresses belong to the same entity; adopting distributed data collection to reorganize the original blockchain data into a standardized table, which comprises a transaction node table, a UTXO flow edge table and an address table; constructing a directed bipartite graph G=(V, E), wherein the node set V comprises transaction nodes and address nodes, and each directed edge in the edge set E represents a spending relationship of a UTXO, i.e. from an address node to a transaction node or from a transaction node to an address node; dividing the transactions in the graph G into simple transactions and complex transactions, wherein the simple transactions refer to transactions satisfying one of the following conditions: (a) initial block incentive transactions; (b) transactions with one output address; (c) transactions with two output addresses; (d) transactions with one input address, no more than three output addresses and only containing basic payment scripts; the basic payment scripts are script types for direct value transfer and do not contain conditional execution, multiple signatures or topology confusion structures; the complex transactions refer to other transactions other than the simple transactions; based on the graph G, constructing auxiliary functions and data structures to help entity judgment; and sorting all transactions in ascending order of timestamp; for the simple transactions, applying high-confidence rules to perform simple heuristic fast clustering; and for the remaining transactions, traversing again in ascending order of time sequence index and performing complex heuristic rules to realize fine-grained entity recognition; merging address sets triggered by the simple heuristic and complex heuristic rules into a unified entity and outputting a complete address-entity mapping table.

2. The multi-stage heuristic based blockchain address entity identification method of claim 1, wherein, The key fields further comprise block level information, transaction level information and an identification field for identifying a verification node signature.

3. The multi-stage heuristic based blockchain address entity identification method of claim 1, wherein, The UTXO flow edge table records all spending relationships, including source node identification, target node identification, source position, target position, address and transaction value, for constructing address-transaction association relationships.

4. The multi-stage heuristic based blockchain address entity identification method of claim 1, wherein, The transactions with one output address are regarded as merged transactions, the transactions with two output addresses are regarded as standard payment transactions, and the transactions with one input address, no more than three output addresses and only containing basic payment scripts are regarded as single-input low-output transactions.

5. The multi-stage heuristic based blockchain address entity identification method of claim 1, wherein, The auxiliary functions comprise input / output address set functions for extracting unique address sets by traversing all input edges and output edges of a transaction, and transaction input / output degree functions for returning the number of input / output addresses; and the data structures comprise an address metadata dictionary and a transaction metadata dictionary.

6. The multi-stage heuristic based blockchain address entity identification method of claim 1, wherein, The complex heuristic rules performed on the remaining transactions comprise identification and de-anonymization of topology confusion transactions and identification of transactions with zero consumption.

7. The multi-stage heuristic based blockchain address entity identification method of claim 6, wherein, When a non-initial block incentive transaction satisfies the following conditions, it is determined as a topology confusion transaction: all input addresses are currently known to belong to different clusters; and the number of output addresses is greater than or equal to 10. 8.The multi-stage heuristic based blockchain address entity identification method of claim 6, wherein, The identifying the change-for-consumption transaction comprises sequentially applying the following rules: an address reuse rule, an input redundancy rule, a newborn address rule, a rounding number rule, and an address low reuse rule, and when any rule produces a unique candidate address, merging the change address with all input addresses into the same cluster to achieve complete entity identification of the consumption transaction; If no rule hits or multiple candidates are produced, the change identification of the transaction is abandoned.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program, when executed by the processor, is arranged to perform the method of any one of claims 1 to 8. The processor implements the steps of the multi-stage heuristic-based blockchain address entity identification method of any one of claims 1-8 when executing the program.

Images