On-chain transaction graph and off-chain sentiment feature linkage detection method for multi-source heterogeneous data fusion

Abstract

The application discloses a multi-source heterogeneous data fusion on-chain transaction graph and off-chain emotion feature linkage detection method, relates to the technical field of blockchain data analysis, and realizes adaptive adjustment of an on-chain query range by sequentially slicing an emotion propagation graph constructed by off-chain user forwarding and reply relationships and generating a ripple window, significantly reduces invalid scanning of irrelevant blocks, and improves the pertinence and computing efficiency of cross-source data retrieval; meanwhile, accurate screening of target smart contract call records, in combination with static partitioning based on address prefixes and a user-address mapping table, can quickly discover potential associations between off-chain users and on-chain addresses without the need for accurate addresses, effectively overcoming traditional cross-source detection defects, thereby providing a high-sensitivity, low-redundancy and scalable linkage detection means for cross-border declaration event monitoring and other scenarios.

Description

Technical Field

[0001] This invention relates to the field of blockchain data analysis technology, and in particular to a method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features by fusing multi-source heterogeneous data. Background Technology

[0002] In recent years, blockchain technology has been increasingly applied in cross-border payments, supply chain finance, and digital asset trading. On-chain transaction graphs (including fund transfers between addresses and smart contract call records) have become important data sources for regulatory compliance and risk control. Meanwhile, user forwarding and replying behaviors on off-chain social media platforms regarding topics such as cross-border transactions and foreign exchange fluctuations form a dynamic network containing emotional propagation paths. However, existing technical solutions often treat on-chain and off-chain data as independent statistical signals, lacking deep integration of the individual-level, temporal coupling between the off-chain emotional propagation structure and specific on-chain address behavior. Furthermore, cross-source query windows typically employ fixed-time alignment strategies, making it difficult to adapt to the suddenness and randomness of off-chain emotional fluctuations. This results in limited detection sensitivity or computational redundancy in scenarios such as monitoring abnormal cross-chain transaction reporting.

[0003] For example, CN118013102B discloses an on-chain digital content public opinion propagation early warning method based on multimodal features. By collecting tweet text, repost, comment, and like data, and on-chain transaction records, it calculates the daily public opinion propagation index and generates early warning signals using moving averages and isolated forest models. In the multimodal processing stage, it constructs time series features of transaction modality (price, trading volume), text modality (VAD sentiment dictionary), and momentum modality (public opinion index), respectively. Then, it uses gated cyclic units in hyperbolic space for temporal encoding and achieves feature fusion through cross-modal attention and temporal attention modules. Finally, LightGBM outputs the public opinion early warning judgment. Its advantage lies in integrating multiple data modalities and introducing hyperbolic geometric capture of power-law distribution characteristics. However, its main focus is on providing early warning of the overall sentiment trend of on-chain digital content, treating each tweet as an independent sample for VAD feature aggregation. Furthermore, cross-source alignment relies on a fixed daily window and cannot dynamically adjust the on-chain query range based on real-time fluctuations in off-chain interaction density. Therefore, in the precise detection scenarios of specific address behaviors such as foreign exchange declaration events in cross-border payments and supply chain finance, it suffers from weak structural coupling, rigid query windows, and coarse address association granularity.

[0004] CN119172149A discloses a method for deanonymizing blockchain addresses and off-chain intelligence based on feature recognition. First, it obtains message data related to a preset business from a Telegram group, extracting primary information such as addresses and transfer details through OCR, word segmentation, and regular expression matching. Simultaneously, it obtains intelligence data from web pages and determines whether it contains on-chain addresses. If no complete address is found, fuzzy matching is performed based on transaction time and amount. Then, it matches the off-chain primary information with on-chain transaction data to obtain user addresses, and further analyzes fund flows to identify core addresses, thereby determining whether different activities belong to the same organization. Its advantage lies in achieving proactive association between off-chain instant messaging intelligence and on-chain transactions. However, the intelligence source is mainly limited to the specific platform of Telegram groups, and the matching strategy heavily relies on precise time windows and transaction amount fluctuation ranges. When off-chain intelligence only contains sentiment-driven behavior without direct address or precise time and amount information, this scheme cannot establish an effective association. Furthermore, the lack of an adaptive block range generation mechanism based on the fluctuation of interactive data, as well as the absence of static address prefix partitioning and user-address mapping table for fast prefix matching, results in low computational efficiency when dealing with large-scale address sets, making it difficult to meet the needs of multi-entity, multi-level address association analysis in supply chain finance. Summary of the Invention

[0005] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and title of the present application, to avoid obscuring the purpose of this section, the abstract and title of the invention. Such simplifications or omissions shall not be used to limit the scope of the present invention.

[0006] In view of the aforementioned existing problems, the present invention is proposed.

[0007] Therefore, the technical problem solved by this invention is: how to provide a linkage detection technology that can deeply integrate off-chain emotion propagation structure, dynamically adapt to on-chain query range, and efficiently realize fuzzy address association.

[0008] To address the aforementioned technical problems, this invention provides the following technical solution: a method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data, characterized by: acquiring off-chain user interaction data and dividing it into multiple time-series segments according to a preset fixed duration; for each time-series segment, dynamically determining the subsequent time interval based on the fluctuation level of the interaction data before the end timestamp, forming a ripple window from the block heights falling within the subsequent time interval, and associating the block height range corresponding to the ripple window as metadata to the corresponding time-series segment; based on the time-series segments associated with the ripple window, extracting smart contract call records from the on-chain transaction graph whose block heights are within the range corresponding to the ripple window, and marking call records that meet preset bytecode matching conditions as target call records; dividing on-chain addresses into multiple static partitions according to address prefixes, obtaining the binding address corresponding to the user identifier from the time-series segment associated with the target call record, retaining address pairs where the address involved in the target call record and the binding address belong to the same static partition, and outputting the address pairs.

[0009] As a preferred embodiment of the present invention, the segmentation into multiple time-series fragments includes: constructing an initial interaction graph using each forwarding or reply behavior as a directed edge and user identifiers as nodes; dividing the time axis into continuous and non-overlapping time intervals with the preset fixed duration; extracting the directed edges whose timestamps fall into each time interval and their endpoint nodes to form an interaction subgraph; generating an empty subgraph for intervals without edges; and packaging the start and end timestamps of each time interval as fragment identifiers with the corresponding interaction subgraphs to form a time-series fragment.

[0010] As a preferred embodiment of the present invention, the dynamic determination of subsequent time intervals includes: counting the number of edges in the interaction subgraph corresponding to each time segment; for at most N windows before the end timestamp, where N is a preset number; if the actual number of obtainable windows is less than 2, then the fluctuation level is set to zero; otherwise, the ratio of the difference in the number of edges between adjacent windows to the number of edges of the previous window is calculated based on the actual obtained windows, and the standard deviation of the ratio is used as the fluctuation level of the data density; the ripple window length is determined based on the calculation result of the fluctuation level and a preset coefficient, wherein the ripple window length is at least one and does not exceed a preset maximum window length; starting from the end timestamp of the time segment, a subsequent time interval is generated based on a preset average block time interval, wherein the length of the subsequent time interval is equal to the product of the ripple window length and the average block time interval; the heights of all blocks whose block timestamps fall within the subsequent time interval are obtained and arranged in ascending order; if there is at least one block, then the minimum height and the maximum height among them form a continuous integer interval as the block height range corresponding to the ripple window; if there are no blocks in the subsequent time interval, then the ripple window is empty.

[0011] As a preferred embodiment of the present invention, the following steps are taken: traversing each time-series shard with ripple window parameters, for the block height range, querying all smart contract call records within the block height range from the on-chain transaction graph, each call record containing at least a call record hash, initiator address, receiver address, and call data; extracting a preset-length prefix bytecode from the call data in each call record, if the prefix bytecode matches any feature code in a preset feature code library, then marking the call record as a target call record; saving the call record hash, original call data, and associated time-series shard identifier for each target call record, and outputting a list of target call records.

[0012] As a preferred embodiment of the present invention, the step of dividing the on-chain address into multiple static partitions according to the address prefix includes: obtaining the hexadecimal representation of all addresses in the on-chain transaction graph, taking a fixed-length prefix of each address as a partition identifier, and grouping addresses with the same prefix into the same static partition.

[0013] As a preferred embodiment of the present invention, the step of obtaining the binding address corresponding to the user identifier includes: querying a pre-set user-address mapping table with the user identifier as the key to obtain the on-chain address bound to the user identifier; the mapping table is pre-constructed based on the explicit binding relationship between off-chain users and on-chain addresses.

[0014] As a preferred embodiment of the present invention, the feature codes in the preset feature code library include bytecode corresponding to contract filing operations, bytecode corresponding to tax calculation hash generation operations, or bytecode corresponding to fund transfer instruction operations; the original data to be called includes the transaction initiator address, the receiver address, and the data to be called.

[0015] This invention also provides a multi-source heterogeneous data fusion system for the linkage detection of on-chain transaction graphs and off-chain sentiment features, comprising: a graph sharding module, which acquires off-chain user interaction data and divides it into multiple time-series shards according to a preset fixed duration; a ripple window generation module, which dynamically determines the subsequent time interval for each time-series shard based on the fluctuation level of the interaction data before the end timestamp, forms a ripple window by assembling the block heights falling within the subsequent time interval, and associates the block height range corresponding to the ripple window as metadata with the corresponding time-series shard; an event marking module, which extracts smart contract call records whose block heights are within the range corresponding to the ripple window from the on-chain transaction graph based on the time-series shards associated with the ripple window, and marks the call records that meet the preset bytecode matching conditions as target call records; and a partition linkage module, which divides on-chain addresses into multiple static partitions according to address prefixes, obtains the binding address corresponding to the user identifier from the time-series shard associated with the target call record, retains address pairs where the address involved in the target call record and the binding address belong to the same static partition, and outputs the address pairs.

[0016] The beneficial effects of this invention are as follows: By segmenting the sentiment propagation graph constructed from the forwarding and replying relationships of off-chain users according to time sequence and dynamically generating ripple windows based on the fluctuation of interaction data, this invention achieves adaptive adjustment of the on-chain query range, significantly reducing invalid scanning of irrelevant blocks and improving the targeting and computational efficiency of cross-source data retrieval. At the same time, by combining a preset bytecode matching mechanism to accurately filter target smart contract call records, and with the static partitioning based on address prefixes and the user-address mapping table, it can quickly discover potential associations between off-chain users and on-chain addresses without requiring precise addresses. This effectively overcomes the shortcomings of traditional cross-source detection, such as rigid time alignment, low address matching efficiency, and inability to integrate propagation structure information. Thus, it provides a highly sensitive, low-redundancy, and scalable linkage detection method for scenarios such as cross-border declaration event monitoring. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are 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. Wherein: Figure 1 This is a flowchart of the method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data, as shown in this invention.

[0018] Figure 2 This is a schematic diagram of the ripple window generation and block query sub-process of the present invention.

[0019] Figure 3This is a structural diagram of the on-chain transaction graph and off-chain sentiment feature linkage detection system for multi-source heterogeneous data fusion as shown in this invention. Detailed Implementation

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0021] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this invention.

[0022] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0023] According to an embodiment of the present invention, in combination Figures 1-2 The flowchart shown illustrates a method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features, which integrates multi-source heterogeneous data. This method can be applied to foreign exchange control declaration scenarios for cross-border blockchain transactions. For example, smart contract call records in the on-chain transaction graph may include operations related to cross-border declarations, such as contract filing, tax calculation hash generation, and fund transfers; off-chain sentiment data may originate from user discussions on topics such as cross-border payments and foreign exchange fluctuations on social media. The address pairs detected by this invention can be further used to identify abnormal declaration behavior or assist regulatory agencies in conducting compliance audits. Specifically, the following operational steps are included: S1: Obtain off-chain user interaction data and divide it into multiple time-series shards according to a preset fixed duration.

[0024] In this embodiment, user interaction data is acquired from at least one off-chain media platform, and the data is discretized in time dimension in units of preset fixed durations to generate a series of time-series slices arranged in chronological order. Each time-series slice contains an interaction subgraph within a time window and its time identifier, providing structured off-chain data input for subsequent steps. Here, sentiment characteristics do not refer to the result of classifying the sentiment polarity of text content, but rather to the propagation topology and dynamic fluctuation patterns formed by interactions such as forwarding and replying between off-chain users. These interactions themselves are considered as the propagation paths of sentiment signals in social networks, and the temporal changes in interaction density reflect the instability and propagation intensity of group emotions. This invention does not rely on sentiment analysis of text semantics, but instead uses the fluctuation of the number of edges in the interaction graph as a representation of sentiment characteristics, thereby enabling linkage detection with on-chain transaction behavior. The specific operation is as follows: S1.1: Acquire forwarding and replying relationship data between users in real time or in batches through the application programming interface provided by the social media platform. Each interaction record shall contain at least the following four fields: initiating user ID, target user ID, interaction type, such as forwarding or replying, and timestamp.

[0025] Each interaction record is treated as a directed edge, with the direction of the edge pointing from the initiating user to the target user; each user identifier is treated as a node. This constructs an initial interaction graph, which includes a set of nodes and a set of directed edges, fully reflecting all forwarding and replying relationships between users within a preset time period.

[0026] It should be noted that the interactive data corresponds to the propagation path of sentiment information in off-chain social networks. This invention does not presuppose a causal relationship between this propagation and any on-chain behavior, but only uses it as a time-series signal reflecting the activity of off-chain users to adaptively adjust the query scope of subsequent on-chain data.

[0027] S1.2: Set a preset fixed duration as the basic time window length.

[0028] In this embodiment, the preset fixed duration is 300 seconds. This duration can be adjusted according to the expected active cycle of off-chain interactive data and the average block time of the blockchain. The typical value range is 60 seconds to 3600 seconds.

[0029] A better approach is to divide the entire timeline into multiple continuous and non-overlapping time intervals, using a preset zero point, such as the Unix epoch, as the baseline. Each time interval is represented as... The interval length is equal to the preset fixed duration, and adjacent intervals adopt the left-closed and right-open rule at the boundary to ensure that each interaction record uniquely belongs to one interval.

[0030] Furthermore, for each time interval, perform the following operations: from the initial interaction graph, filter out all directed edges whose timestamps fall within that interval; extract the two endpoints of the filtered directed edges, namely the initiating user identifier and the target user identifier, to form the node set corresponding to that time interval.

[0031] It should be noted that nodes themselves do not have a timestamp attribute. Therefore, a user identifier will only be included in the node set of the current subgraph if at least one edge of a user identifier falls within this interval.

[0032] The selected directed edges and their endpoint nodes are combined to form an interaction subgraph. This subgraph only contains the actual interactions that occur within the interval and the participating users. If there are no directed edges within a certain time interval, an empty subgraph with an empty set of nodes and an empty set of directed edges is generated. The introduction of the empty subgraph ensures continuity on the time axis, preventing missing time points in the subsequent edge count sequence and thus avoiding statistical bias.

[0033] The preset fixed duration can be configured according to the application scenario, for example, it can be an integer multiple of the average block time of the target blockchain network to facilitate subsequent time alignment. In this embodiment, no specific value is limited, only that it is a positive number.

[0034] It should be noted that the left-closed, right-open property of the time interval ensures that each edge has a unique affiliation, avoiding duplicate boundary counting. Using this method, continuous off-chain interaction data can be discretized into a series of subgraphs arranged in chronological order, with each subgraph independently reflecting the interaction density and structure within that time window.

[0035] S1.3: Package the interaction subgraph corresponding to each time interval, along with the start and end timestamps of that time interval, into a time series slice. For easy indexing, assign a unique window number to each time series slice. The window number corresponds one-to-one with the integer parameter k (k=0,1,2,...) in the time interval division, where k=0 corresponds to the first window starting from the zero point of the start time.

[0036] All time-series slices are organized into a time-series slice set according to time order and output to subsequent steps. This set supports random access, that is, the corresponding slice and incremental update can be directly obtained according to the window number.

[0037] Each time-series slice is essentially a time-graph tuple, containing both start and end timestamps and structured graph data.

[0038] In real-time monitoring scenarios, whenever a new time-series shard is generated, this invention automatically triggers steps S2 to S4. Based on the interaction density characteristics appearing within the time window corresponding to that shard, the query window for the subsequent block height range is dynamically adjusted to detect whether there are smart contract call records with target bytecode within that range. This data-driven adaptive mechanism focuses computing resources on active off-chain periods, improving the efficiency of cross-source correlation queries.

[0039] S2: For each time-series shard, dynamically determine the subsequent time interval based on the fluctuation level of the interaction data before the end timestamp, form a ripple window by the block heights falling into the subsequent time interval, and associate the block height range corresponding to the ripple window as metadata with the corresponding time-series shard.

[0040] S2.1: For each time slice in the time slice set output in step S1, denoted as... ,in This is the window number. Read the interaction subgraph contained in this time series slice, count the number of directed edges in this subgraph, and denote it as . For an empty subgraph, i.e., where both the node set and edge set are empty, the number of edges is... =0.

[0041] The number of edges obtained from the statistics With the corresponding window number The edges are stored in relation to each other, forming a sequence of edge counts. This sequence is continuous on the time axis because step S1.2 ensured that a corresponding subgraph was generated for each time interval (including the edgeless interval).

[0042] It should be noted that the number of sides Directly reflects the first The activity level of offline user interactions within a time window. The larger the value, the more intensive the forwarding or replying behavior within that window; a value of zero indicates no interaction behavior within that window. The edge count sequence will be used as the basis for subsequent fluctuation calculations, and its completeness ensures the stability of the statistical results.

[0043] S2.2: For the current time-series fragment Get the end timestamp Get the contents The preset number of edges, including those before the end timestamp, is denoted as the edge sequence of N windows. In this embodiment, N is 5. Generally, the value of N ranges from 3 to 10, and can be adjusted according to the expected fluctuation frequency of off-chain interaction data.

[0044] Specifically, the number of edges of N windows, from max(1, i-N+1) to i, is taken. When the total number of windows is less than N, all existing windows are used. Here, the preset number N is a configurable positive integer used to limit the range of windows participating in the volatility calculation. The value of N determines the sensitivity of the volatility to long-term trends or short-term abrupt changes: the larger N is, the more the volatility reflects macroeconomic trends; the smaller N is, the more sensitive the response to local abrupt changes. This embodiment does not limit the specific value of N and can be set according to actual needs, only requiring it to be greater than or equal to 2.

[0045] For the selected window sequence above (assuming there are a total of...), One window, ≤N), calculate the rate of change of the number of edges between adjacent windows in chronological order. For the , windows ( ≥2), rate of change Calculate according to the following formula:

[0046] Where, the denominator is taken The larger value in 1. This setting ensures that when When the denominator is 1, the error of dividing by zero is avoided, and the rate of change has a clear upper bound.

[0047] It should be noted that by using the maximum value function as the denominator, the rate of change when the number of sides jumps from 0 to a positive number is that positive value, which can truly reflect the dramatic change from nothing to something.

[0048] The calculated rate of change , ,..., This forms a rate of change sequence. The sample standard deviation of this sequence is calculated and denoted as . This refers to the degree of fluctuation in the density of interactive data.

[0049] When the number of windows is less than 2, the rate of change cannot be calculated; in this case, the degree of fluctuation will be... Set to zero. When the number of windows is equal to 2 (i.e. =2), the rate of change sequence contains only one value. The sample standard deviation is undefined, and will also be... Set it to zero.

[0050] It can be seen that by defining the degree of volatility based on standard deviation, a quantitative assessment of the drastic changes in the density of interactive data is achieved. Compared to simply using the sum or maximum of the rates of change, standard deviation can eliminate the interference of overall offset and more accurately reflect the randomness and instability of volatility, thus providing a more reliable basis for the subsequent adaptive adjustment of the ripple window length. Furthermore, the degree of volatility... This directly determines the length of the ripple window. When off-chain interaction data fluctuates drastically within recent windows (e.g., the number of edges fluctuates wildly), A large value indicates that the off-chain environment is in an unstable and active state. Based on this, the present invention expands the subsequent query range to cover a longer on-chain time interval, avoiding the omission of potentially temporally adjacent contract call records due to an overly narrow query range.

[0051] S2.3: The degree of fluctuation calculated based on step S2.2 Determine the ripple window length as follows: :

[0052] in, As a preset coefficient, in this embodiment, The value is 2. The value of is related to the average block time and volatility sensitivity of the blockchain; a value range of 1 to 5 is recommended. The larger the value, the longer the ripple window for the same level of fluctuation. `floor` indicates rounding down. A preset maximum window length is also set. It can be set to 20 to prevent a single query from covering too many blocks. If the above calculation result exceeds... Then take Among them, the length of the ripple window The minimum value is 1, meaning the minimum window length is 1.

[0053] The above method, using linear mapping and lower bound constraints to determine the ripple window length, achieves a smooth, monotonic transformation from fluctuation intensity to time interval length. It should be noted that the fluctuation intensity... This reflects the recent instability of off-chain interaction density. Empirical observations suggest that for every unit increase in the standard deviation of interaction density, the temporal dispersion of on-chain associated events increases approximately linearly. This is achieved through coefficients... Will Mapping to the window length makes the degree of fluctuation proportional to the query range. The value can be adjusted according to the block production speed of the target blockchain network and the business scenario. Rounding down ensures that the window length is an integer, and adding 1 ensures that the minimum window length is 1, avoiding empty windows.

[0054] S2.4: Fragment based on the current time sequence End timestamp Starting from the preset average block time interval This generates a subsequent time interval. The subsequent time interval is represented as follows:

[0055] in, This is a statistical average based on the historical block times of the target blockchain network, representing the average time required for the target blockchain network to produce a new block. For example, for the Ethereum mainnet, it can be set to... Seconds; for other blockchain networks, the configuration should be based on the average historical block time.

[0056] The above operations are based on the starting point of the subsequent time interval. Instead of the current system time, the on-chain block time is used to ensure consistency in time logic. This means that blocks are only included in the query scope after the time window for off-chain interaction data has ended. This design avoids incorrectly including blocks before the off-chain window ends in the query, maintaining temporal causality. In offline analysis scenarios, if subsequent time intervals may fall entirely within the historical block time range, direct querying is possible. In real-time monitoring scenarios, however, it is necessary to wait for a new block to be generated or to set a timeout mechanism.

[0057] S2.5: Based on the timestamps of each block in the on-chain block data, determine that all block timestamps fall within the subsequent time interval generated in step S2.4. The blocks within. Get the block heights of these blocks and sort them in ascending order.

[0058] If at least one block exists within a subsequent time interval, then the height of the smallest block is taken. and maximum block height This constitutes a continuous block height range. The height range of this block is the ripple window.

[0059] If no blocks are available in the subsequent time interval—for example, in a real-time scenario where no new blocks have been generated and the time interval has not yet ended, or in an offline scenario where there is indeed no block data within that time interval—the ripple window will be empty, and the block height range will not exist. In this case, setting the ripple window parameter to null indicates that no blocks need to be queried.

[0060] Furthermore, the block height range (if it exists) is used as a ripple window parameter and appended to the current time-series fragment. In the metadata, time series slices with ripple window parameters are formed, denoted as... The ripple window parameters must include at least the starting block height. and end block height It can also include other representations such as a list of block heights, as long as it can uniquely identify the set of blocks to be queried.

[0061] If the ripple window is empty, the subsequent step S3 will skip the current time-series slice and will not perform any query of call records, thereby avoiding invalid calculations.

[0062] It should be noted that because the block generation time of the blockchain is not strictly uniform, the actual number of blocks falling into subsequent time intervals may be zero, one, or more. This step uses actually existing blocks as the standard, rather than sampling or interpolating uniformly over time. Furthermore, this invention uses a continuous interval consisting of the minimum and maximum heights as the representation of the ripple window, which can utilize the range query function of the blockchain database or index to improve query efficiency. It should be noted that there may be block heights that do not actually exist within this continuous interval (i.e., virtual heights where no blocks have been generated), but these will be automatically skipped during database queries and will not affect the accuracy of the results.

[0063] Furthermore, the generated ripple window directly points to a batch of blocks adjacent to the current time-series shard. The smart contract call records in these blocks will be filtered in subsequent steps. Since the length of the ripple window is dynamically determined by the volatility of off-chain interaction data, the query range automatically expands to cover longer on-chain time periods when off-chain interactions are active and volatile; conversely, the query range shrinks when off-chain interactions are stable, reducing invalid scans. This adaptive mechanism allows cross-source queries to focus on time periods with significant changes in off-chain data, improving the targeting and efficiency of queries.

[0064] S2.6: Traverse all timing slices For each slice, perform steps S2.1 to S2.5 as described above to obtain the corresponding time-series slice with ripple window parameters. All Organize them into a new time-series fragment set according to the original order.

[0065] As can be seen, each time-series shard output by the above steps, in addition to retaining the original interaction subgraph and time identifier, also includes a dynamically calculated on-chain block height range. This interaction-block association data structure provides clear navigation information for subsequent cross-source queries, enabling the entire method to achieve adaptive mapping from off-chain interaction density to on-chain event range. Compared to fixed time windows or manually setting query ranges, this significantly improves processing efficiency and automation.

[0066] S3: Based on the temporal shards after the associated ripple window, extract smart contract call records from the on-chain transaction graph whose block height is within the range corresponding to the ripple window, and mark the call records that meet the preset bytecode matching conditions as target call records.

[0067] S3.1: Obtain the timing slices of the output with ripple window parameters. From time-series sharding The ripple window parameter, i.e., the block height range, is read from the metadata. If the block height range does not exist, i.e. the ripple window is empty, it means there are no blocks in the subsequent time interval. In this case, the current time series shard is skipped, no query operation is performed, and the next time series shard is processed directly.

[0068] If the block height range is not empty, the smart contract call record table is queried from the pre-built on-chain transaction graph. This smart contract call record table is a pre-built database constructed by synchronizing full data from blockchain nodes or subscribing to block events, and includes at least the block height, call record hash, initiator address, receiver address, and call data.

[0069] Filter out all blocks with heights between and The call records between points (including endpoint values) constitute a candidate call record set, denoted as . .

[0070] The on-chain transaction graph can be constructed based on the full data synchronized by blockchain node clients (such as Geth and FISCOBCOS nodes), or it can be obtained on demand through the block explorer application programming interface (API). This embodiment does not limit the specific implementation method, as long as it can provide the ability to query call records by block height range.

[0071] Candidate call record set It could be empty. For example, there might be blocks within the block height range, but these blocks don't contain any smart contract call transactions; they might only contain ordinary transfer transactions. Since it is an empty set, subsequent processing will be skipped.

[0072] It should be noted that the block height range is dynamically determined by the fluctuation of off-chain interaction data in step S2. Therefore, the candidate call record set naturally focuses on a batch of blocks generated after the period of active off-chain interaction. This design concentrates computing resources on on-chain events that may be temporally close to off-chain behavior, improving the efficiency of cross-source correlation queries.

[0073] S3.2: For the obtained candidate call record set For each call record in the database, perform the following operations: First, extract the call data field from the call record. The call data is a hexadecimal string whose structure conforms to the Ethereum Virtual Machine (EVM) call specification: the first 4 bytes are the function selector, i.e., the function signature bytecode, and the subsequent bytes are the function parameter encoding. Second, extract the first 4 bytes of the call data (i.e., the first 8 hexadecimal characters) as the function signature bytecode of the call record.

[0074] Furthermore, the extracted function signature bytecode is compared one by one with the signatures in a preset signature library. The preset signature library pre-stores signatures corresponding to at least one type of target smart contract operation, including but not limited to bytecodes corresponding to contract filing operations, bytecodes corresponding to tax calculation hash generation operations, and bytecodes corresponding to fund transfer instruction operations.

[0075] Specifically, the bytecode corresponding to the contract filing operation corresponds to the function in the smart contract used to register cross-border trade contracts and generate a unique filing identifier; the bytecode corresponding to the tax calculation hash generation operation corresponds to the function in the smart contract used to calculate the taxes payable according to tax law rules and generate a tax certificate hash; and the bytecode corresponding to the fund transfer instruction operation corresponds to the function in the smart contract used to execute fund transfers and trigger payment instructions.

[0076] If the function signature bytecode is exactly the same as any feature in the preset feature library (exact match), the call record is marked as a target call record, denoted as p; if the function signature bytecode does not match any feature in the preset feature library, the call record is ignored, and the process continues to the next record. It can be seen that the matching method uses exact byte matching, meaning the first 4 bytes are completely equal. This eliminates the need for complete decoding or simulated execution of the call data, ensuring a lightweight and efficient matching process.

[0077] It should be noted that the preset signature library can be obtained by parsing the Application Binary Interface (ABI) of the target smart contract, or extracted from officially released contract templates or historical audit records. The construction of the signature library is independent of the specific execution of this invention; it only needs to be configured before execution.

[0078] The contract filing, tax hash generation, and fund transfer instructions described above are merely exemplary operation types. This method does not limit the specific business meaning; it only considers them as smart contract calls with specific bytecode. The signature library can be flexibly configured according to actual application scenarios.

[0079] As can be seen, the target call records represent a type of on-chain operation with specific business semantics, such as contract registration, tax calculation, and fund transfer. These operations have no causal relationship with off-chain interaction data and are only used as objects for subsequent address association matching. Through this filtering step, subsequent steps only need to process these target call records, rather than all call records, further focusing the scope of analysis.

[0080] S3.3: For each call record marked as target call record p, save complete event information, including at least the call record hash, the original call data, and the timing fragment identifier.

[0081] The call record hash is a hash value calculated using the keccak256 algorithm, serving as a unique and immutable credential for the record on the blockchain. The original call data contains complete field information of the call record, specifically including the initiator's address, the receiver's address, and the call data.

[0082] All saved target call records are organized into a target call record list according to the detection order (e.g., ascending order by block height, or order by discovery time), denoted as . For each time-series slice Output the corresponding The target call record list for all time-series shards can be merged into a global list, or the shards can be kept independently organized, as long as the association between each record and its source time-series shard can be preserved.

[0083] If no call record in the candidate call record set matches the preset feature code library, then If the list is empty, output an empty result.

[0084] It should be noted that the same block height may contain multiple call records, and each call record is saved as an independent target call record if it matches the feature code.

[0085] S3.4: In practical applications, due to potential blockchain reorganization or node data synchronization delays, the block height range queried in step S3.1 may be incomplete. To enhance robustness, the following optional processing can be added to this step: After querying, verify whether all blocks within the block height range have been finally confirmed, for example, based on a preset threshold for the number of confirmed blocks. For blocks that have not yet been confirmed, the query request can be temporarily stored and executed after confirmation.

[0086] If a blockchain reorganization is detected that causes a change in the block height range (e.g., the original...), If it is no longer at its maximum height, then S3.1 to S3.3 will be re-executed.

[0087] The above-mentioned optional processing methods are conventional technical means in this field and are not core steps of this method. Therefore, they are not included as necessary features, but they can be described in specific embodiments to demonstrate the completeness of the solution.

[0088] S4: Divide the on-chain address into multiple static partitions according to the address prefix, obtain the binding address corresponding to the user identifier from the time-series fragment associated with the target call record, retain the address pairs in which the address involved in the target call record and the binding address belong to the same static partition, and output the address pairs.

[0089] In this embodiment of the invention, for each target call record output in step S3, the involved on-chain transaction addresses are partitioned and aligned with the user-bound addresses corresponding to the interaction subgraphs in the associated time-series shards. Address pairs located in the same static partition are retained and output as the association result. This process achieves efficient cross-source address matching through address prefix pre-partitioning and hash indexing, and specifically includes the following sub-steps: S4.1: Retrieve all on-chain addresses appearing in the on-chain transaction graph. The address is a hexadecimal string conforming to the blockchain address format, such as the Ethereum or compatible chain address format, i.e., a length of 40 hexadecimal characters, excluding the 0x prefix. For each address, the first fixed-length hexadecimal characters are used as the partition prefix. In this embodiment, the fixed-length prefix is ​​preset to 4, meaning the first 4 hexadecimal characters of each address, totaling 16 bits, are used as the partition identifier. This length can be configured during system initialization; a value between 4 and 6 is recommended, with larger prefixes resulting in more refined partitioning.

[0090] The fixed length of bits is a preset system parameter that remains unchanged once determined.

[0091] Furthermore, all addresses are divided according to their partition prefixes: each unique prefix value corresponds to a static partition, and all addresses with the same prefix are grouped into the same partition. The total number of static partitions is equal to the size of the prefix value range; for example, when the prefix is ​​4 hexadecimal digits, the total number of partitions is 16 to the power of 4, or 65536. Once this partition mapping relationship is established, it remains unchanged in all subsequent detection processes, hence the name static partitioning.

[0092] It should be noted that the choice of fixed-length bits needs to strike a balance between partition granularity (number of partitions) and the number of addresses within each partition. More prefix bits result in finer partitioning, but fewer addresses per partition, leading to faster matching; fewer prefix bits result in coarser partitioning, more addresses per partition, slower matching, but potentially higher recall. This embodiment does not limit the specific number of bits, only requiring it to be a preset constant.

[0093] Furthermore, static partitions can be constructed during system initialization by scanning the entire chain of addresses and stored as a hash table structure, where the key is a prefix value and the value is a list of addresses under that prefix. When a new address appears, it can be incrementally updated to the corresponding partition.

[0094] As can be seen, this embodiment of the invention uses address prefixes for static partitioning, transforming the original address matching problem, which required pairwise comparisons, into a fast lookup problem based on a partition index. Specifically, if there is no partitioning, it matches two address sets. and need Second comparison; after introducing partitioning, only extraction is needed separately. and The time complexity is reduced to the prefix of each address, and then the prefixes are compared to see if they are equal. This means that a hash table can be used to find if there is an intersection between partitions. This optimization has significant performance advantages in large-scale data processing scenarios.

[0095] Furthermore, static partitioning provides an efficient indexing basis for determining the same static partition in the subsequent step S4.3. Since on-chain addresses and off-chain user-bound addresses may not be exactly the same—that is, the same entity may use different addresses—addresses derived from the same entity often have the same prefix. Therefore, prefix matching can achieve fuzzy association at the entity level while protecting the complete privacy of addresses.

[0096] S4.2: For each target call record p output in step S3, extract the set of on-chain transaction addresses involved from the original call data stored in the record. The original data to be called includes at least the initiator's address and the recipient's address. The initiator's address is the address of the transaction sender that initiated the smart contract call; the recipient's address is the address of the smart contract account being called.

[0097] The two addresses mentioned above together constitute the transaction address set. It should be noted that some special types of transactions (such as contract creation transactions) may not have a recipient address. In this case, the recipient address field can be considered empty, and only the initiator address is added to the set. The transaction address set... The addresses in the table are all standard hexadecimal strings, and their prefixes will be calculated in subsequent step S4.3.

[0098] If two addresses are identical, they are deduplicated.

[0099] If the target call record contains other address fields, such as third-party addresses encoded in the call parameters, these can also be extracted according to actual application requirements. This embodiment only extracts the initiator and receiver as the minimum necessary set, but the possibility of expanding to extract more addresses is not excluded.

[0100] S4.3: Based on the time-series fragment identifier associated with the target call record p Locate the corresponding timing slice generated in step S1. From time-series sharding Extract all user identifiers, i.e., user IDs, contained in the interaction subgraph. The user identifiers are derived from the nodes constructed in step S1 when building the initial interaction graph, including the initiating user identifier and the target user identifier in the forwarding behavior, and the initiating user identifier and the target user identifier in the reply behavior.

[0101] Then, using a pre-built user-address mapping table, each user identifier is converted into a corresponding on-chain address. For each user identifier, a lookup is performed in the user-address mapping table. If one or more corresponding on-chain addresses are found, all of these addresses are added to the binding address set. If no address is found, meaning the user has not yet bound any on-chain address, the user identifier will be ignored and no address will be generated.

[0102] The user-address mapping table is constructed as follows: it is pre-established based on the explicit binding relationship between off-chain social media users and on-chain addresses. This explicit binding relationship can be obtained through one or more of the following methods: users actively declare their on-chain addresses on social media platforms, such as in their profiles or pinned messages; users verify their control over a specific on-chain address using digital signatures and record the binding relationship in a Distributed Identity (DID) document; or system administrators manually enter the binding relationship based on trusted authentication results.

[0103] Finally, the set of bound addresses is obtained. This includes several on-chain addresses. It may be empty, for example, if all users in the interaction subgraph have not bound an address, then subsequent matching will yield no results.

[0104] It should be noted that a single user identifier can be bound to multiple on-chain addresses (e.g., addresses on different blockchain networks, or multiple wallet addresses on the same network). This includes all these addresses; and multiple user identifiers may also be bound to the same on-chain address (e.g., multiple operators of a corporate account), in which case the address may be... The characters appear multiple times, but deduplication is usually performed before subsequent matching.

[0105] S4.4: For the set of transaction addresses obtained in step S4.2 and the set of binding addresses obtained in step S4.3 Perform the following partition matching operation: for Each address in The fixed-length hexadecimal prefix before calculation (Using the same fixed-length number of bits as in step S4.1); for Each address in Calculate the hexadecimal prefix of its fixed-length digits. ;judge Is it equal to If they are equal, then record the address pair. This is a related matching result.

[0106] Collect all the address pairs that satisfy the prefix equality condition to form the association result set. Among them, the results Each element in the array is a pair. This indicates the on-chain address appearing in the target call record. The address bound to a user in the interaction subgraph corresponding to the associated time series shard. Partitions with the same prefix.

[0107] like or If empty, then It is an empty set.

[0108] It's important to note that the above operations employ a prefix equality matching strategy, rather than an exact address equality matching strategy. This is a fuzzy matching method, meaning that the same entity, such as a company or a high-frequency trader, typically uses multiple addresses derived from the same root key, and these addresses often share the same prefix. Therefore, prefix matching can capture associations between different addresses under the same entity without requiring the addresses to be exactly the same. During the matching process, if multiple user-bound addresses have the same prefix and are equal to... The prefix, then the same Possibly with multiple Matching, in this case, multiple pairs are output. Similarly, the same b may be associated with multiple... match.

[0109] Ultimately, the matching results It can be used directly as the final output, or it can be further aggregated, such as deduplicating by address or summarizing by event. This embodiment does not limit the post-processing method.

[0110] As can be seen, this embodiment of the invention achieves rapid alignment of on-chain transaction addresses with off-chain user-bound addresses through prefix partitioning matching. Compared to traditional exact address matching, this invention can discover associations between different addresses used by the same entity in different domains, expanding the coverage of cross-source associations. Simultaneously, since only prefixes are compared rather than complete addresses, address privacy is protected to some extent (same prefixes do not necessarily mean the same address). The time complexity of this matching method is O(n log n). It has excellent real-time processing capabilities.

[0111] S4.5: Set of associated results corresponding to all target call records p The results are aggregated to form a global correlation result. Output the correlation results. It can be stored in one or more of the following forms, such as in a structured data format (e.g., JSON, CSV) in a database for subsequent querying or visualization, pushed to downstream systems in real time through an application programming interface (API), or presented in a list or graphical manner in a monitoring interface.

[0112] Each associated result entry must contain at least the following information: the hash value of the target call record, the associated time-series shard identifier, and the on-chain address. The information includes the binding address b and the prefix value used for matching. This information allows for a complete traceability of the origin of the association.

[0113] It should be noted that the output correlation results themselves do not contain any judgment on normality or abnormality; they only provide technical data correlations. Downstream systems can further analyze these correlation results in conjunction with other business rules.

[0114] If it is necessary to filter the results, for example, to retain only address pairs that appear more frequently than a threshold, this can be an optional post-processing step and is not a necessary feature of this invention.

[0115] like Figure 3 As shown, the present invention also includes a multi-source heterogeneous data fusion system for detecting the linkage between on-chain transaction graphs and off-chain sentiment features, comprising: The graph sharding module constructs an emotion propagation graph based on the relationship between off-chain user forwarding and replying, divides it into multiple time-series shards according to a fixed time window, and outputs a set of time-series shards. The ripple window generation module takes the time interval as the starting point of the time window of each time segment, and forms a ripple window by the height of the blocks falling within the time interval, and outputs the time segment with ripple window parameters. The event marking module extracts smart contract call records whose block height falls within the block height range from the on-chain transaction graph based on the time-series shards with ripple window parameters. It marks the call records that match the preset reporting rules as cross-border reporting events and outputs the events and their associated time-series shard identifiers. The partition linkage module divides the on-chain addresses into static partitions based on address prefixes, obtains the binding address corresponding to the user identifier from the associated time-series fragments, retains the address pairs in the same partition as the address involved in the cross-border declaration event and the binding address, and outputs them as the linkage detection results.

[0116] The present invention also includes one or more processors and a memory.

[0117] The memory is used to store operable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. These operations include the flow of the multi-source heterogeneous data fusion on-chain transaction graph and off-chain sentiment feature linkage detection method described in the foregoing embodiments, especially... Figure 1 The flowchart of the method is shown.

[0118] Other aspects disclosed in the embodiments of the present invention also propose a computer-readable medium for storing software, the software including instructions executable by one or more computers, the instructions causing the one or more computers to perform operations, including the flow of the multi-source heterogeneous data fusion on-chain transaction graph and off-chain sentiment feature linkage detection method of the foregoing embodiments, especially... Figure 1 The flowchart of the method is shown.

[0119] It should be recognized that embodiments of the present invention may be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium.

[0120] The method can be implemented using standard programming techniques, including a non-transitory computer-readable storage medium configured with a computer program in the computer program, wherein the storage medium is configured such that the computer operates in a specific and predefined manner.

[0121] Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system; however, if required, the program can be implemented in assembly or machine language.

[0122] In any case, the language can be either compiled or interpreted.

[0123] Furthermore, for this purpose, the program can run on programmed application-specific integrated circuits.

[0124] The processes described herein (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program includes a plurality of instructions executable by one or more processors.

[0125] Furthermore, the method can be implemented in any suitable computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices.

[0126] Various aspects of the present invention can be implemented in machine-readable code stored on a non-transitory storage medium or device, whether portable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein.

[0127] Furthermore, machine-readable code, or parts thereof, can be transmitted via wired or wireless networks.

[0128] When such media includes instructions or programs that combine with a microprocessor or other data processor to implement the steps described above, the invention described herein includes these and other different types of non-transitory computer-readable storage media.

[0129] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data, characterized by: include: Acquire off-chain user interaction data and divide it into multiple time-series shards according to a preset fixed duration; For each time-series slice, the subsequent time interval is dynamically determined based on the fluctuation of the interaction data before the end timestamp. The block heights falling within the subsequent time interval are used to form a ripple window, and the block height range corresponding to the ripple window is used as metadata and associated with the corresponding time-series slice. Based on the temporal shards after the associated ripple window, extract smart contract call records whose block height is within the range corresponding to the ripple window from the on-chain transaction graph, and mark the call records that meet the preset bytecode matching conditions as target call records; The on-chain address is divided into multiple static partitions according to the address prefix. The binding address corresponding to the user identifier is obtained from the time-series slice associated with the target call record. Address pairs in which the address involved in the target call record and the binding address belong to the same static partition are retained and the address pairs are output. The dynamic determination of subsequent time intervals includes: counting the number of edges in the interaction subgraph corresponding to each time segment; for at most N windows before the end timestamp, where N is a preset number; if the actual number of windows obtained is less than 2, the fluctuation level is set to zero; otherwise, the ratio of the difference in the number of edges between adjacent windows to the number of edges of the previous window is calculated based on the actual number of windows obtained, and the standard deviation of the ratio is used as the fluctuation level of the data density; the ripple window length is determined based on the calculation result of the fluctuation level and a preset coefficient, where the ripple window length is at least one and does not exceed a preset maximum window length; starting from the end timestamp of the time segment, subsequent time intervals are generated based on a preset average block time interval, where the length of the subsequent time interval is equal to the product of the ripple window length and the average block time interval; the heights of all blocks whose block timestamps fall within the subsequent time interval are obtained and sorted in ascending order; if there is at least one block, the minimum and maximum heights of the blocks are used to form a continuous integer interval as the block height range corresponding to the ripple window; if there are no blocks in the subsequent time interval, the ripple window is empty.

2. The method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data as described in claim 1, characterized in that: The segmentation into multiple time-series fragments includes: Each forwarding or replying action is used as a directed edge, and user identifiers are used as nodes to construct an initial interaction graph; The timeline is divided into continuous and non-overlapping time intervals with the preset fixed duration. The directed edges and their endpoint nodes that the timestamps fall into each time interval are extracted to form an interactive subgraph. An empty subgraph is generated for the edgeless interval. The start and end timestamps of each time interval are used as fragment identifiers and packaged with the corresponding interaction subgraphs to form time-series fragments.

3. The method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data as described in claim 1, characterized in that: Iterate through each time-series shard with ripple window parameters, and for the block height range, query all smart contract call records in the on-chain transaction graph where the block height is within the block height range. Each call record contains at least the call record hash, the initiator address, the receiver address, and the call data. Extract the preset length prefix bytecode of the call data in each call record. If the prefix bytecode is consistent with any feature code in the preset feature code library, then mark the call record as the target call record. For each target call record, save the call record hash, the original call data, and its associated time-series fragment identifier, and output a list of target call records.

4. The method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data as described in claim 1, characterized in that: The process of dividing the chain address into multiple static partitions based on the address prefix includes: Obtain the hexadecimal representation of all addresses in the on-chain transaction graph, take a fixed-length prefix for each address as a partition identifier, and group addresses with the same prefix into the same static partition.

5. The method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data as described in claim 1, characterized in that: The step of obtaining the binding address corresponding to the user identifier includes: By querying the pre-set user-address mapping table with the user identifier as the key, the on-chain address bound to the user identifier can be obtained; The mapping table is pre-built based on the explicit binding relationship between off-chain users and on-chain addresses.

6. The method for detecting the linkage between on-chain transaction graphs and off-chain sentiment features based on the fusion of multi-source heterogeneous data as described in claim 3, characterized in that: The feature codes in the preset feature code library include bytecode corresponding to contract filing operations, bytecode corresponding to tax calculation hash generation operations, or bytecode corresponding to fund transfer instruction operations. The original data to be called includes the address of the transaction initiator, the address of the recipient, and the data to be called.

7. A multi-source heterogeneous data fusion-based on-chain transaction graph and off-chain sentiment feature linkage detection system, based on the multi-source heterogeneous data fusion-based on-chain transaction graph and off-chain sentiment feature linkage detection method according to any one of claims 1 to 6, characterized in that: Also includes: The graph sharding module acquires off-chain user interaction data and divides it into multiple time-series shards according to a preset fixed duration. The ripple window generation module dynamically determines the subsequent time interval for each time segment based on the fluctuation level of the interaction data before the end timestamp. It forms a ripple window by assembling the block heights that fall within the subsequent time interval and associates the block height range corresponding to the ripple window as metadata with the corresponding time segment. The event marking module extracts smart contract call records whose block height is within the range of the ripple window from the on-chain transaction graph based on the temporal shards after the associated ripple window, and marks the call records that meet the preset bytecode matching conditions as target call records. The partition linkage module divides the on-chain address into multiple static partitions according to the address prefix, obtains the binding address corresponding to the user identifier from the time-series slice associated with the target call record, retains the address pairs that belong to the same static partition as the address involved in the target call record and the binding address, and outputs the address pairs.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the multi-source heterogeneous data fusion on-chain transaction graph and off-chain sentiment feature linkage detection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the multi-source heterogeneous data fusion on-chain transaction graph and off-chain sentiment feature linkage detection method as described in any one of claims 1 to 6.

Images