A homologous transaction identification method based on Ethereum node time information

Abstract

The present invention relates to a method for identifying homologous transactions based on Ethereum node time information, and belongs to the field of blockchain technology. This method aims to utilize the time information leaked by fixed nodes in the Ethereum network to perform feature expression on the network attributes of transactions, and realize correlation analysis of massive transactions from the network layer. This method utilizes the network attribute characteristics of transactions and associates transactions with nodes as entities. By detecting the time order of transaction flooding broadcasts from multiple fixed nodes, a unified feature representation is performed on the broadcast process of each transaction, and transactions with similar broadcast processes, that is, transactions entering the network from the same source node, are clustered into one entity. This method can cover all transactions in Ethereum and can resist the influence of mixed currency contracts.

Description

Technical Field

[0001] The present invention relates to a homologous transaction identification method based on Ethereum node time information, and belongs to the technical field of blockchain. Background Art

[0002] Since the introduction of blockchain technology, various cryptocurrencies based on it have emerged one after another. Among them, Ethereum, as the first blockchain platform to support smart contracts, has garnered widespread attention. In cryptocurrency systems like Ethereum, users can freely apply for pseudonyms unrelated to their real identities and conduct transactions under these pseudonyms. These pseudonyms are controlled by the user's private keys. Although all transaction records associated with these pseudonyms, including transaction amounts, transaction times, and account addresses, are publicly visible in the blockchain to achieve decentralized consensus, no one knows the true identity of the pseudonym, thus protecting user privacy.

[0003] Due to its enormous market value and anonymous nature, various malicious activities frequently occur on Ethereum. These malicious activities directly harm the economic interests of users and undermine the security of the blockchain ecosystem. Therefore, some research institutions and companies have begun analyzing public data on the blockchain, analyzing the correlations between different pseudonyms, and identifying different pseudonyms of the same user to assess cryptocurrency assets, map capital flows, and support law enforcement.

[0004] Existing transaction correlation methods for Ethereum can be divided into two categories: user-habit-based and scenario-specific. User-habit-based methods utilize the uniqueness of pseudonymous users and analyze user behavior patterns, such as account transaction time, transaction fees, and transaction amounts, to develop heuristic rules that cluster different accounts of the same user into a single entity, allowing for statistical analysis of transactions across the entire network. Scenario-based methods utilize specific rules in specific Ethereum scenarios (e.g., deposit address reuse, multiple short positions, and self-authorization) to develop heuristic clustering methods based on these rules to correlate the initiators of different transactions.

[0005] However, these association methods require knowledge of the account addresses of both the initiator and recipient of each transaction, which is affected by the coin-mixing protocol. Once a user uses a coin-mixing contract to block the connection between the initiator and recipient, these methods become ineffective. Furthermore, because they exploit user behavior and specific rules, these association methods can only link a small number of eligible transactions, leaving the majority unaffected.

[0006] In summary, the current methods for transaction correlation on Ethereum have shortcomings such as limited coverage and poor robustness. Summary of the Invention

[0007] The purpose of the present invention is to overcome the defects of the existing technology and creatively propose a same-source transaction identification method based on Ethereum node time information.

[0008] This method aims to leverage the time information leaked from fixed nodes in the Ethereum network to characterize the network properties of transactions, enabling correlation analysis of massive transactions at the network level. This method covers all transactions in Ethereum and is resistant to the influence of coin-mixing contracts.

[0009] The innovation of this method lies in leveraging a common characteristic of all transactions: network properties, to associate transactions using nodes as entities. By detecting the temporal order of transaction flooding broadcasts from multiple fixed nodes, a unified feature representation is created for each transaction's broadcast process. Transactions with similar broadcast processes, i.e., those entering the network from the same source node, are clustered into a single entity.

[0010] The technical solutions adopted in the present invention are as follows.

[0011] A method for identifying same-source transactions based on Ethereum node time information includes the following steps:

[0012] Step 1: Monitor the network and collect transaction network information.

[0013] To correlate transactions, we first deploy a client on the Ethereum network, collect network-layer data of the transactions, and then store this data for subsequent analysis.

[0014] Specifically, step 1 may include the following steps:

[0015] Step 1.1: Modify the source code of the Ethereum client (such as the geth client, full name go-ethereum) and record transaction information.

[0016] Because the Ethereum client is user-oriented, it hides the process of how nodes interact with their neighbors in the network and directly presents the final interaction results to the user. Therefore, it is necessary to modify the Ethereum client source code so that when a node receives a transaction relayed by a neighboring node, it records the transaction log information, including the transaction timestamp, transaction hash, relay node IP address, and the transaction initiator account.

[0017] Specifically, a four-tuple (h, a, p, t) is used to describe each transaction relayed by a neighboring node, where t represents the timestamp of the transaction, h represents the transaction hash, p represents the relay node IP, and a represents the initiator account of the transaction.

[0018] Step 1.2: Deploy the Ethereum client and monitor the network.

[0019] Deploy the client in the Ethereum mainnet to run in fast sync mode as a probe node.

[0020] In fast sync mode, the probe node receives blocks and transactions relayed by neighbor nodes, but does not verify and forward new transactions and blocks.

[0021] Step 2: Data processing.

[0022] First, set the time threshold T and the minimum number of replicas M.

[0023] At intervals of T, divide the logged log information into intervals. For the data in each interval, extract the log information (which can be extracted using a Python script), and save the transaction hash, the timestamp of the transaction, the initiating account of the transaction, and the relay node IP (which can be saved in JSON format).

[0024] For each transaction tx, record tx = {h, a, (p i , t i ) | i = 0, 1…}, and count the time when different nodes relay the transaction to the probe node. Among them, p i is the IP of different neighbor nodes, and t i is the relative time when the probe receives the transaction replica forwarded by the neighbor node (that is, subtract the minimum timestamp of each transaction). At the same time, eliminate transactions with less than M received replicas and abnormal data transactions (due to network interruptions, etc.). Finally, record the set of neighbor nodes P for all transactions, P = {p i | i = 0, 1…}.

[0025] Step 3: Construct homologous transaction pairs and non - homologous transaction pairs.

[0026] Among them, homologous transaction pairs refer to two transactions that enter the network from the same source node. Non - homologous transaction pairs refer to two transactions that enter the network from different source nodes.

[0027] Based on the fact that users do not frequently switch the network access node in a short period of time, the present invention proposes a heuristic clustering rule for identifying homologous transaction pairs and non - homologous transaction pairs, which specifically includes:

[0028] Rule 1: For any two transactions tx1, tx2, if tx1.a == tx2.a and |tx1.t - tx2.t| < T, then tx1 and tx2 are homologous transaction pairs.

[0029] Rule 2: Same-origin transaction pairs tx1-tx2 occur at time t1 and t2, respectively; same-origin transaction pairs tx3-tx4 occur at time t3 and t4, respectively. If t1, t2 intersect with t3, t4, then tx3 and tx1 are not same-origin transaction pairs, and tx2 and tx4 are not same-origin transaction pairs.

[0030] For the transactions obtained in step 2, construct homologous transaction pairs according to rule 1, and construct non-homologous transaction pairs according to rule 2.

[0031] Step 4: Unify the reference nodes of different transaction timestamps to obtain a unified expression.

[0032] Specifically, select p0 in the IP set P as the reference node, and relativize the homologous transaction pairs and non-homologous transaction pairs obtained in step 3. i Subtract the timestamp t0 corresponding to the p0 node, t i =t i -t0.

[0033] Then, according to the order of IP in P, the time series in the transactions are reordered to construct relative time series with the same meaning (relative to the same node) and the same order for each comparison.

[0034] Step 5: Analyze the broadcast process of homologous transaction pairs, perform feature representation on the similarities of homologous transaction pairs, and unify the feature representation of homologous transaction pairs and non-homologous transaction pairs.

[0035] Specifically, step 5 includes the following steps:

[0036] Step 5.1: Similarity representation of trading pairs.

[0037] Because network topology remains constant over short periods of time, two flood broadcasts originating from the same source node will likely reach the designated node along the same path. If two nodes reach the same path, the time difference between the two broadcasts remains the same.

[0038] Therefore, the absolute time difference and time difference trend change of the two transactions in the transaction pair are counted separately to reflect the similarity of the two broadcast processes of the same-source transaction pair.

[0039] Calculate the absolute time difference box of the trading pair through the binning method in feature engineering t , calculated as follows:

[0040]

[0041] in, Respectively represent the two transactions tx1 and tx2 in the transaction pair by node p iThe relative timestamp during relaying; I is the set time interval, indicating the tolerance to time fluctuations; n is the number of relative timestamps received in the time series.

[0042] The time trend between different nodes is another key attribute. Using the quotient method, the trend of any two nodes is calculated. t , as follows:

[0043]

[0044] in, Respectively represent the two transactions tx1 and tx2 in the transaction pair being processed by node p i 、p j The relative timestamp of the relay. The second item is the reciprocal of the first item to avoid the influence of the denominator on the result.

[0045] Step 5.2: Feature extraction.

[0046] Feature extraction is performed on the absolute time difference sequence and change trend sequence of the transaction pairs respectively, and features describing the similarities of homologous transaction pairs are extracted for model training and learning.

[0047] Step 6: Perform model training and cross-validation on the original dataset obtained in step 4 and the feature dataset obtained in step 5 to identify homologous transaction pairs.

[0048] Beneficial effects

[0049] Compared with the prior art, the method of the present invention has the following advantages:

[0050] (1) The method of the present invention clusters transaction pairs that enter the network from the same source node by deploying probe nodes connected to selected fixed nodes. The method covers most transactions in the entire network and can resist the influence of mixed currency contracts.

[0051] (2) By analyzing the user's behavior patterns, the present invention proposes a heuristic construction method for homologous transaction pairs and non-homologous transaction pairs. By using the network layer information of the transaction, homologous transaction pairs and non-homologous transaction pairs are constructed as data sets for subsequent analysis.

[0052] (3) This paper designs a new feature representation method to describe the similarity of network attributes of homologous transactions in the network.

[0053] This invention is intended for legal purposes. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 The transaction association flow chart of the method of the present invention. DETAILED DESCRIPTION

[0055] The method of the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be noted that the implementation of the present invention is not limited to the following embodiments, and any modifications or changes made to the present invention will fall within the scope of protection of the present invention.

[0056] Example

[0057] A homologous transaction identification method based on Ethereum node time information.

[0058] Figure 1 This is a flowchart of the Ethereum transaction correlation method using fixed node time leakage. Figure 1 When the present invention is implemented, the following steps are included:

[0059] Step 1: Download the geth client source code from the official Ethereum website and modify the client code to record a copy of the received transactions. Set the geth client's maximum number of connections to its default value (50) and relax the limit on the number of actively connected nodes, allowing more than 1 / 3 of the maximum number of actively connected nodes. The final number of connected nodes is between 15 and 35.

[0060] Step 2: Considering the routing status and data packet propagation speed of the Ethereum P2P network, set the time threshold T = 10 minutes and the minimum number of replicas M = 15.

[0061] Count the relay nodes and relay timestamps of each transaction and calculate the union P of relay nodes.

[0062] Step 3: Based on the proposed heuristic clustering rules 1 and 2, perform heuristic clustering on transactions in different intervals to construct homologous transaction pairs and non-homologous transaction pairs.

[0063] Step 4: Select node p0 in P. Use p0 as the reference node to relativize the relay timestamps of all other nodes. Note that o0 should be a node that exists in the list of all transaction relay nodes. The specific relativization method is for each transaction, node p i Relay timestamp t i =t i -t0, where t0 is the relay timestamp of node o0. Then, based on the node order in P, the timestamps of all transactions are reordered to ensure that the timestamp sequences of all transactions are in the same order. Finally, the original transaction pair dataset is obtained. The sample data in the dataset consists of two timestamp sequences of transaction pairs, and the labels are determined by whether they are homologous. If the transaction pair is homologous, the label is 1; if the transaction pair is non-homologous, the label is 0. There are 5704 samples in the dataset, with half each consisting of homologous transaction pairs and non-homologous transactions.

[0064] Step 5: Based on Equations 1 and 2, the transaction pair dataset is similarity-represented, where I = 50. The two timestamp sequences for each transaction pair are merged into a vector representing similarity, consisting of an absolute time difference sequence and a trend sequence. Feature extraction is performed on the absolute time difference sequence and trend sequence in each similarity vector. Common features between the two include mean, standard deviation, minimum, first quartile, median, third quartile, maximum, range, kurtosis, skewness, mean absolute difference (AAD), median absolute deviation (MAD), and interquartile range (IQR), totaling 13 dimensions. Furthermore, key numerical ratio features are extracted for the absolute time difference sequence, including values ​​greater than 0, less than 0, equal to 0, greater than b, less than -b, greater than 2*b, less than -2*b, greater than 3*b, less than -3*b, greater than 4*b, and less than -4*b, where b is related to the value of I (in this case, b = 5). For trend sequences, we extracted key numerical ratio features, including those greater than 0, less than 0, positive sum, negative sum, total, greater than 3, less than -3, greater than 4, less than -4, greater than, and less than -5. Finally, the two timestamp sequences for each transaction pair were converted into a 48-dimensional feature vector, generating a feature dataset from the original transaction pair dataset.

[0065] Step 6: Select a classifier for feature learning and identify homologous trading pairs. Traditional machine learning methods (SVM, DecisionTree, RandomForest, XGBoost) and multi-layer perceptrons were tested to select the most appropriate classifier model.

[0066] We performed a Grid Search on traditional machine learning models, selecting the optimal parameters and comparing the results. The optimal parameters for SVM were max_depth = 6, max_feature = 0.3, and min_samples_split = 4. The optimal parameters for DecisionTree were max_depth = 6, max_features = 0.3, and min_samples_split = 4. The optimal parameters for RandomForest were n_estimators = 15, max_features = 0.5, max_depth = 8, and min_samples_split = 12. The optimal parameters for XGBoost were learning_rate = 0.3222, n_estimators = 500, max_depth = 10, subsample = 0.8, and colsample_bytree = 0.9. Multilayer Perception achieved optimal results using a three-layer neural network with RELU as the activation function and FocalLoss as the loss function.

[0067] The results show that the multilayer perceptron is the most suitable classifier model, capable of identifying homologous transaction pairs, that is, whether two transactions entered the network from the same source node, with an F1 score of 97%. The recognition performance of homologous transaction pairs by different classifiers is shown in Table 1:

[0068] Table 1 Identification effect of homologous transaction pairs by different classifiers

[0069] Classifier Precision Recall F1 Support Vector Machine 0.9149 0.8597 0.886441485 DT 0.8787 0.8588 0.86863604 RF 0.9639 0.9474 0.955578779 XGBoost 0.9712 0.9658 0.968492473 NeuralNetwork 0.9747 0.97969 0.97718863

[0070] Comparative Verification

[0071] This example compares the same-source transaction identification method based on Ethereum node time information of the present invention with other transaction association methods to verify that the method of the present invention has better same-source transaction pair identification capabilities.

[0072] A comparative method (https: / / orbilu.uni.lu / bitstream / 10993 / 39724 / 1 / biryukov-tikhomirov-deanonymization-and-linkability.pdf) uses the relay timestamps of the first N nodes to describe the network properties of a transaction. These timestamps are then weighted and the similarity of the weight vectors is used to determine whether two transactions have the same origin.

[0073] The comparison method uses the concept of adjusted anonymity degree to illustrate the effectiveness of the association, with lower values ​​indicating more effective association methods.

[0074] For better comparison, this example will use the same method to measure the association effect. adj The calculation is as follows:

[0075] d adj =1-(1-e)(1-d)

[0076]

[0077] Where e represents the median square error between the probability distribution and the true distribution. i represents the probability that the transaction has the same source as the target transaction. d is the ratio of the calculated information entropy to the maximum entropy. N represents the number of transactions.

[0078] To ensure generality, this example will use the following method to calculate the probability p that two transactions have the same origin:

[0079] p=p0pre+(1-p0)(1-pre)

[0080] Wherein, p0 represents the average probability of the output probability distribution of the classifier of the present invention, and pre represents the recognition accuracy of the model.

[0081] The results show that the adjusted anonymity D adj =0.563, which is much higher than the adjusted anonymity d of the comparison method. adj =0.879. The fixed N-node timestamps used in this invention can better represent the network attributes of transactions and achieve better transaction correlation effects. The comparison of the effects of the first N-node timestamps and the fixed N-node timestamps is shown in Table 2:

[0082] Table 2 Comparison of the effects of the first N nodes timestamp and the fixed N nodes timestamp

[0083] Method Timestamp Applicable Network Number of nodes <![CDATA[d adj ]]> Comparison Method First Bitcoin 1000 0.879 This method Fixed Ethereum 35 0.563

[0084] The above description describes the implementation mode of the present invention in combination with the drawings and embodiments. However, for those skilled in the art, several improvements can be made without departing from the principles of this patent, and these also fall within the scope of protection of this patent.

Claims

1. A method for identifying homologous transactions based on Ethereum node time information, characterized in that: It includes the following steps: Step 1: Monitor the network and collect transaction network information; First, deploy a client in the Ethereum network, collect the network layer data of transactions, and then store these data for subsequent analysis; Step 2: Data processing; First, set the time threshold T and the minimum number of replicas M; Partition the recorded log information at intervals of T; for the data in each interval, extract the log information and save the transaction hash, the timestamp of the transaction, the initiator account of the transaction, and the relay node IP; For each transaction tx, record tx={h,a,(p i ,t i )|i=0,1…}, h represents the transaction hash, a represents the transaction initiator account statistics of the time it takes for different nodes to relay the transaction to the probe node, p i For different neighbor node IPs, t i The relative time when the probe receives the transaction copy forwarded by the neighbor node; At the same time, filter out transactions with less than M received replicas and abnormal data transactions; Finally, the neighbor node set P that records all transactions, P = {p i |i=0,1…}; Step 3: Construct homologous transaction pairs and non-homologous transaction pairs; Among them, homologous transaction pairs refer to two transactions that enter the network from the same source node; non-homologous transaction pairs refer to two transactions that enter the network from different source nodes; Adopt a heuristic clustering rule for identifying homologous transaction pairs and non-homologous transaction pairs, specifically including: Rule 1: For any two transactions tx1, tx2, if tx1.a == tx2.a and |tx1.t - tx2.t| < T, then tx1 and tx2 are homologous transaction pairs; Rule 2: For homologous transaction pairs tx1 - tx2, which occur at times t1, t2 respectively; for homologous transaction pairs tx3 - tx4, which occur at times t3, t4 respectively; if there is a time intersection between t1, t2 and t3, t4, then tx3 and tx1 are non-homologous transaction pairs, and tx2 and tx4 are non-homologous transaction pairs; For the transactions obtained in Step 2, construct homologous transaction pairs according to Rule 1 and non-homologous transaction pairs according to Rule 2; Step 4: Unify the reference nodes of different transaction timestamps to obtain a unified expression; Select p0 in the IP set P as the reference node, and relativize the homologous transaction pairs and non-homologous transaction pairs obtained in step 3; i Subtract the timestamp t0 corresponding to the p0 node, t i =t i -t0; Then, reorder the time series in the transaction according to the IP order in P to construct a relative time series with the same meaning and the same order for each comparison; Step 5: Analyze the broadcast process of homologous transaction pairs, represent the similarity of homologous transaction pairs, and unify the feature representations of homologous transaction pairs and non-homologous transaction pairs; Step 6: Perform model training and cross-validation on the original dataset obtained in Step 4 and the feature dataset obtained in Step 5, so as to realize the identification of homologous transaction pairs.

2. A method for identifying homologous transactions based on Ethereum node time information as claimed in claim 1, characterized in that: Step 1 includes the following steps: Step 1.1: Modify the Ethereum client source code to record transaction information; Modify the Ethereum client source code to record the log information of transactions when the node receives a transaction relayed by a neighbor node, including the timestamp of the transaction, the transaction hash, the relay node IP, and the initiator account of the transaction; Use a quadruple (h, a, p, t) to describe each transaction relayed by a neighbor node, where t represents the timestamp of the transaction, h represents the transaction hash, p represents the relay node IP, and a represents the initiator account of the transaction; Step 1.2: Deploy the Ethereum client to monitor the network; Deploy a client in the Ethereum main network to run in the fast sync mode as a probe node; In the fast sync mode, the probe node receives the blocks and transactions relayed by neighbor nodes, but does not verify and forward new transactions and blocks.

3. A method for identifying homologous transactions based on Ethereum node time information as claimed in claim 1, characterized in that: Step 5 includes the following steps: Step 5.1: Similarity representation of transaction pairs The absolute time difference and time difference trend of two transactions in a transaction pair are counted separately to reflect the similarity of the two broadcast processes of the same transaction pair; Calculate the absolute time difference box of the trading pair through the binning method in feature engineering t , calculated as follows: in, Respectively represent the two transactions tx1 and tx2 in the transaction pair by node p i Relative timestamp during relay; I is the set time interval, indicating the tolerance to time fluctuations; n is the number of relative timestamps received in the time series; The time trend between different nodes is another key attribute; the trend between any two nodes is calculated by taking the quotient method. t , as follows: in, Respectively represent the two transactions tx1 and tx2 in the transaction pair being processed by node p i 、p j The relative timestamp at the time of relaying, and the second item is the reciprocal of the first item, to avoid the influence of the denominator choice on the result; Step 5.2: Feature extraction; Feature extraction is performed on the absolute time difference sequence and change trend sequence of the transaction pairs respectively, and features describing the similarities of homologous transaction pairs are extracted for model training and learning.

Images