Transaction analysis and visualization

Abstract

A computer implementation method for disassembling a blockchain containing transactions in a digital currency for analysis and display is disclosed. The method first involves determining the range of blocks within the blockchain. Then, each block within the range of blocks in the blockchain is unpacked into a table having one or more rows for the input and output data for each transaction stored in the block. Then, for the range of blocks in the blockchain, entity information and transaction information are aggregated into a block analysis table. Computing network nodes and computer program products adapted for the implementation of such a method are also disclosed.

Description

Technical Field

[0001] The present disclosure generally relates to the analysis of visualisation of transactions, and more particularly to that for digital currencies stored within a blockchain. More specifically, although not exclusively, the present disclosure relates to the analysis and visualisation of whether transactions for digital currencies stored within a blockchain are fraudulent or not.

[0002] Cross-reference to related applications This application claims the benefit and priority of European Patent Application No. 23180153.1, filed on June 19, 2023. The entire disclosure of the above application is incorporated herein by reference.

Background Art

[0003] Blockchain cryptocurrencies are generally regarded as secure currencies because their structure is designed to provide an immutable ledger regarding transactions and are recorded and stored in a distributed manner across a network. However, since the major cryptocurrency blockchain protocols use a pseudonymous system where the identity of the user remains hidden, these systems are increasingly being used for illegal purposes such as the purchase of prohibited items on the dark net market.

[0004] While the majority of blockchain cryptocurrency transactions are related to legitimate activities, cryptocurrency-related crimes are a major concern for governments and regulators worldwide. Crypto exchanges, in particular, are a major focus of interest within the cryptocurrency network because they are used by criminals to launder funds obtained from illegal cryptocurrency transactions (e.g., ransomware proceeds) to obtain fiat currency (e.g., government-backed currency). As a result, regulations have been introduced requiring cryptocurrency exchanges to implement measures such as Know Your Customer (KYC) checks for customers trading and buying cryptocurrencies.

[0005] Currently, there are several public resources that provide information on some of the addresses associated with illegal or fraudulent cryptocurrency activity. Examples of these include ESET, Kaspersky Lab, Malwarebytes, and Symantec. However, each block in a cryptocurrency blockchain can contain thousands of transactions. For example, a block on the Bitcoin blockchain can contain an average of about 2,700 transactions, and there are over 770,000 blocks on the Bitcoin blockchain. Furthermore, each transaction (e.g., a fund transfer) can involve a large number of different inputs (e.g., the wallet or address making the fund transfer) and outputs (the wallet or address receiving the transferred funds). A Bitcoin transaction can involve as many as 2,000 inputs and outputs; therefore, analyzing these in relation to fraudulent activity is computationally inefficient, and obtaining any coherent overall picture of the resulting position can be extremely difficult. [Overview of the project]

[0006] As mentioned above regarding the background technology, identifying, analyzing, and visualizing fraudulent transactions in blockchain-based cryptocurrencies such as Bitcoin remains a subject of ongoing research interest.

[0007] Currently, Bitcoin transactions can be heuristically labeled as fraudulent by analyzing the input and output addresses (or wallets) involved in the transaction, and this can be visualized using the user interface of conventional applications. The information provided about cryptocurrencies is vast and complex, with any individual transaction potentially involving around 2000 inputs and outputs, each of which can be associated with more than 100 features (e.g., individual columns about the data). Therefore, achieving heuristic methods for labeling transactions as fraudulent in real time is difficult, and the analysis path or display format can be cumbersome. Thus, the objective of various embodiments is to develop systems and methods that can be used to efficiently decompose cryptocurrency transaction information for analysis and display.

[0008] Accordingly, according to a first aspect of the present disclosure, the following method is provided: a computer implementation method for disassembling a blockchain including transactions in a digital currency for analysis and display, the method comprising: determining a range of blocks in the blockchain; unpacking each block within the range of blocks in the blockchain into a table having one or more rows for input and output data for each transaction stored in the block; and aggregating entity information and transaction information into a block analysis table for the range of blocks in the blockchain.

[0009] As mentioned above, blockchain technology has become widely known for its ability to securely record and store transaction data in a decentralized manner. However, understanding and interpreting raw blockchain data can be difficult due to its complex structure and enormous volume. There is a need for an efficient and user-friendly solution to help users make informed decisions by visualizing this data and providing statistical insights. This approach, which involves decomposing blockchain transactions and aggregating data on an entity-by-entity basis, enables effective analysis and visualization.

[0010] This approach, particularly when used in relation to real-time labeling of transactions related to fraudulent activity, can resolve the complexity of cryptocurrency transactions and enable direct analysis and visualization of transactions.

[0011] In the embodiment, after unpacking each block, the method further includes the step of merging the tables for each block into a merged dataframe. The step of aggregating entity information and transaction information into block analysis tables may include extracting the aggregated entity information and aggregated transaction information for the aggregated entity information from the merged dataframe using one or more scripts or functions.

[0012] In this embodiment, transaction data is stored in a tree-like structure, and the step of unpacking each block within the range of the block may include, for each block within the range of the block: unpacking the block into a table having one or more rows for the input and output data for each transaction stored in the block; and aggregating the one or more rows for the input and output data to form an aggregated row for the transaction data for each transaction. In this case, the step of unpacking the block may include: unpacking the block into multiple stages; and performing an outer join between the multiple stages to obtain a table having one or more rows for the input and output data for each transaction. The step of performing the outer join may include: using the SCHEMA.DATASET.btc_block_stg table as the primary table; and performing an outer join to the stage among the multiple stages to extract non-nested information from the block into the table. In this case, the block may be stored in NoSQL format. If transaction data is stored in such a structure, the step of aggregating one or more rows of the input and output data may include merging the one or more rows into a single row by performing statistical aggregation on the values ​​of each field in each row of the input and output data.

[0013] In embodiments, the method may further include the step of labeling some or each of the transactions as fraudulent, the labeling step being based in part on whether the recipients listed in the transaction data are known to be involved in fraudulent activity.

[0014] In the embodiment, the digital currency may be based on an Unspent Transaction Output (UTxO) design. In the embodiment, the method may further include the step of analyzing digital currency activity using the block analysis table. In the embodiment, the method may further include the step of displaying digital currency activity using the block analysis table.

[0015] According to a second aspect of this disclosure, a node in a computing network is provided for disassembling a blockchain containing transactions in a digital currency for analysis and display, the node being configured to: determine a range of blocks in the blockchain; unpack each block within the range of blocks in the blockchain into a table having one or more rows for input and output data for each transaction stored in the block; and aggregate entity information and transaction information into a block analysis table for the range of blocks in the blockchain. Such a node may be further configured to perform any version of the method of the first aspect.

[0016] A third aspect of the present disclosure provides a computer program product comprising a computer-readable medium, wherein computer-readable code is embodied within the computer-readable medium, and the computer-readable code is configured to cause the computer or processor to perform the method provided in the first aspect of the present disclosure when executed by a suitable computer or processor. [Brief explanation of the drawing]

[0017] [Figure 1] This figure shows an exemplary computing node suitable for implementing embodiments of the present disclosure. [Figure 2]This figure illustrates an exemplary method for decomposing a blockchain, including transactions, in a digital currency, according to embodiments of the present disclosure. [Figure 3] This figure illustrates exemplary embodiments of unpacking transaction data stored within blocks of a blockchain, according to some embodiments of the present disclosure. [Figure 4A] This diagram shows exemplary input and output rows for transaction data related to an exemplary transaction. [Figure 4B] This figure shows exemplary aggregated transaction data for the exemplary input and output rows of the transaction data shown in Figure 4A. [Figure 5] This schematic diagram illustrates exemplary steps for obtaining an aggregated transaction table for use in embodiments of the present disclosure. [Figure 6] A schematic diagram illustrating block decomposition according to an embodiment of the present disclosure, wherein aggregated transactions are provided, and subsequently aggregated entities and transaction information are provided. [Figure 7] This is a schematic diagram showing software elements adapted to perform the steps shown in Figure 6 according to embodiments of the present disclosure. [Figure 8] This figure shows an example output from the block decomposition process shown in Figure 6. [Modes for carrying out the invention]

[0018] As described in the above summary, the present disclosure relates to providing a basis for the analysis and display of transactions in digital currencies (e.g., cryptocurrencies), preferably related to determining whether individual transactions are fraudulent, and more generally enabling the evaluation of an entire digital currency transaction system. Due to the complexity of general digital currency transactions, it is difficult to provide information suitable for analysis and display.

[0019] FIG. 1 shows nodes (e.g., computing nodes) according to some embodiments. Node 100 can generally be configured to perform any of the methods and functions described in the present disclosure (e.g., be made to operate so), and examples can include method 200 and method 700 described later.

[0020] In some embodiments, node 100 includes a processor 102, a memory 104, and an instruction set 106. The memory has instruction data (e.g., compiled code) representing the instruction set 106. The processor can be configured to communicate with the memory and execute the instruction set. When the instruction set is executed by the processor, it can cause the processor to perform any of the methods of the present disclosure, such as method 200 described later.

[0021] Processor (e.g., processing circuit or logic) 102 can be any type of processor, such as a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), or any other type of processing unit. Processor 102 can include one or more sub-processors, processing units, multi-core processors, or modules that cooperate in a distributed manner to control the node in the disclosed manner.

[0022] Node 100 can include a memory 104. In some embodiments, the memory 104 of node 100 can be configured to store program code or instructions that are executed by the processor 102 of node 100 to perform the functions described in this disclosure. The memory 104 of node 100 can be configured to store any data or information, such as requests, resources, information, data, signals, or things similar to those described. The processor 102 of node 100 can control the memory 104 of node 100 to store such information.

[0023] In some embodiments, node 100 can be a virtual node, such as a virtual machine or any other containerized computer node. In such embodiments, the processor 102 and the memory 104 can each be part of larger processing and memory resources.

[0024] Note that computing node 100 can include other components shown in FIG. 1. For example, node 100 can include a power source (e.g., a mains power source or a battery power source). Node 100 can further include a wireless transmitter and / or a wireless receiver for wireless communication with other computing nodes. In some embodiments, node 100 can further include a user input device, such as a mouse, keyboard, or touchpad, for receiving input user data. In some embodiments, node 100 can further include a display for displaying any of the data described, including, for example, any output (or intermediate data product) for any of the methods described.

[0025] As described above, node 100 is used to perform analysis and display of digital currency transactions stored in the blockchain. Therefore, in some embodiments, node 100 may be located within a peer-to-peer network involved in storing the blockchain. In other embodiments, as will be further detailed below, node 100 may be provided in (or otherwise associated with) a currency exchange, enabling the analysis and display of information regarding transactions in digital currency.

[0026] As described above, in some embodiments, node 100 is configured to determine the range of blocks in the blockchain. It is also configured to unpack each block within the range of blocks in the blockchain into a table having one or more rows for the input and output data for each transaction stored in the block. For the range of blocks in the blockchain, node 100 is configured to aggregate entity information and transaction information into a block analysis table.

[0027] Those skilled in the art will be familiar with blockchain, but simply put, a blockchain is a distributed database that maintains a continuously growing list of ordered records (e.g., blocks). Each block contains the cryptographic hash of the previous block, a timestamp, and transaction data about the transactions captured within the block. In this way, a chain is created. The blockchain is stored in a decentralized, distributed, and public digital ledger, which is used to record transactions in a peer-to-peer network. Each server in the distributed system stores a copy of the ledger and communicates with other servers in the distributed system to build a consensus on transactions that have occurred. It is not possible to retrospectively change the record of transactions without changing all subsequent blocks and building a consensus with other servers in the peer-to-peer network. For this reason, blocks in the blockchain gradually become fixed and immutable. For further information, please refer to the paper Nofer, M., Gomber, P., Hinz, O. et al. “Blockchain” Bus Inf Syst Eng 59, 183-187 (2017).

[0028] The embodiments of this disclosure relate to digital currencies stored within a blockchain, which in other embodiments may be referred to as cryptocurrencies. Those skilled in the art will understand cryptocurrencies, which, unlike fiat currencies, are generally backed by a government and can be transferred digitally or using physical currency. Generally, the digital currencies described herein may be cryptocurrencies based on an Unspent Transaction Output (UTxO) design. Examples of such cryptocurrencies include, but are not limited to, Bitcoin, Bitcoin cash, and Litecoin. Those skilled in the art will understand Bitcoin; see, for example, Bohme, Rainer, Nicolas Christin, Benjamin Edelman, and Tyler Moore. 2015: “Bitcoin: Economics, Technology, and Governance.” Journal of Economic Perspectives, 29 (2):213-38.

[0029] This disclosure relates to transactions. In this sense, a transaction is the transfer of funds (e.g., currency items) from a first entity to a second entity on the blockchain. In this sense, an entity can be the owner of funds on the blockchain. An entity may also be referred to as an addressee. Digital currencies can be held in a wallet belonging to an entity or an addressee. Therefore, a transaction can also be described as the transfer of funds from a first wallet to a second wallet.

[0030] Cryptocurrency transactions can be characterized as illicit or fraudulent for a number of reasons. For example, a transaction may be considered fraudulent if it involves entities engaged in illegal activity or if it involves the transfer of funds for illegal purposes, including but not limited to: money laundering; fraud; embezzlement; blackmail; darknet markets; and / or funds obtained through ransomware. Furthermore, a transaction may be considered fraudulent or illegal if it contains digital coins derived from illegal transactions (for example, of the types described above), even if the entities or wallets involved in the transaction are not directly linked to illegal activity. These are merely examples, and a transaction may be labeled as fraudulent for reasons other than those listed above.

[0031] While this disclosure is directed toward the analysis and visualization of transactions, it is particularly effective when used in conjunction with methods for predicting whether a transaction is fraudulent or not. Although not detailed here, the directions presented here can be used with any method for predicting or determining the fraudulent nature of a transaction, and the directions for analysis and visualization of transactions described herein can be readily used in the applicant's concurrently filed applications, “Predicting Fraudulent Transactions” and “Predicting Whether Transactions Concerning Digital Currencies Stored in a Blockchain Are Fraudulent or Not,” which are incorporated by reference. In this context and in these concurrently filed applications, “predicting” may involve estimating, using a model trained with machine learning processes, whether wallets or users involved in illegal activity are involved in a transaction or whether a transaction includes cryptocurrency originating from illegal activity. The prediction may be in the form of labels, such as binary labels.

[0032] Figure 2 illustrates a method for disassembling a blockchain containing transactions in a digital currency for analysis and display. Method 200 can be implemented on a computer and can be executed by a computing node such as the node 100 described above.

[0033] In embodiments of the present disclosure, the method performs the following steps. In the first step, the method determines the range of blocks in the blockchain. The method then unpacks each block within the range of blocks in the blockchain into a table having one or more rows for input and output data for each transaction stored in the block. The method then aggregates entity information and transaction information into a block analysis table for the range of blocks in the blockchain (S206).

[0034] Such blockchains can be stored in the cloud. For example, if the digital currency is Bitcoin, Google Cloud can be used to store the blockchain data. Google Cloud data can be accessed using query tools such as BigQuery. Resources such as Jupyter Notebook can be used to query the range of blocks. Past transaction data can be held within blocks of the blockchain stored in the cloud, for example. Therefore, in S202, method 200 may include retrieving blocks in the blockchain within a specified range (for example, from cloud storage such as Google Cloud).

[0035] The data within the received block may be arranged in a tree-like structure (e.g., a Merkle tree). In some embodiments, the block is stored in NoSQL storage. Therefore, S202 may include unpacking the tree-like structure and presenting each transaction as multiple input and output rows for the transaction data.

[0036] In Bitcoin, each block in the Bitcoin blockchain can contain approximately 2,700 transactions, and each transaction can have around 2,000 inputs and outputs. The inputs and outputs of a transaction contain information indicating which entities (e.g., which address or wallet) are transferring funds to which other addresses (e.g., which other address or wallet) in the transaction. Input transaction data is data about the entities making the fund transfer in the transaction. Output transaction data is data about the entities receiving the funds in the transaction (the beneficiaries / recipients of the transaction). Because more than one wallet can contribute funds to a single transaction, a transaction can have more than one input. Also, because the transferred funds can be split among two or more recipients of the transaction, a transaction can have more than one output.

[0037] In embodiments described herein, S202 includes the step of unpacking a block in the blockchain into a table having one or more rows for input and output data for a first transaction stored in the block.

[0038] Unpacking or unnesting data from a database (e.g., BigQuery, cloud storage, etc.) can be done using rules or schemas for dividing data packets within the database. Transactional data within a block can be stored in a tree-like structure such as a Merkle tree. Another example is that a block can be stored in one or more Avro(TM) block files in Apache Avro(TM) format, as described in the paper Hukill, GS, & Hudson, C. (2018): “Avro: Overview and Implications for Metadata Processing”.

[0039] In such embodiments, the unpacking step includes: unpacking a block into multiple stages; and performing an outer join between the multiple stages to obtain a table having one or more rows for the input and output data for the first transaction.

[0040] In one embodiment where the digital currency is Bitcoin, the step of unpacking the blockchain blocks is performed to create multiple schemas to accommodate various sublevels of the Bitcoin dataset. This unpacking or unnesting is a result of unwinding the Avro(TM) block files into standard tables. The following steps are taken in this process: - Step to unpack NoSQL format data into a staging table. - A step to unpack each level into individual stages. - The primary table is SCHEMA.DATASET.btc_block_stg, which performs an outer join with the remaining stages to extract the unnested information into a single table.

[0041] The unpacking process is shown in Figure 3. In summary, a cryptoblock contains core information, and the purpose of S202 in the Bitcoin embodiment is to unpack the avro file to the transactional data level. This unpacking process results in a table containing rows for each element of an array in the non-SQL data contained within the database. The table obtained from the unpacking of the non-SQL data includes markings or identifiers indicating whether a row corresponds to a transaction input or output. Appendix I shows an exemplary example of a table obtained from the unpacking of a DataFrame, relating to an embodiment where the digital currency stored in the blockchain is Bitcoin.

[0042] Because each transaction within the blockchain has multiple inputs and outputs, an unpacked cryptocurrency block can contain thousands of rows. Due to the sheer volume of data associated with each transaction, many heuristic methods may become computationally intensive to process transactions in real time as part of the verification process.

[0043] Therefore, in embodiments of this disclosure, S202 can aggregate one or more rows of input and output data to form aggregated rows for transaction data for each transaction. Transaction data unpacked from a DataFrame can be aggregated or compressed in a manner that reduces the number of features in the data to a more suitable size, thus enabling efficient processing and analysis of the data. Both transaction data related to the first transaction and transaction data related to the second transaction preceding the first transaction can be aggregated.

[0044] Therefore, after the data has been unpacked (for example, from a non-SQL database), one or more rows of transactional data for input and output can be aggregated to form aggregated rows for transactional data for a transaction. This type of data compression enables data-driven analysis and decision-making, allows for customization of different levels of granularity based on specific data requirements, and prevents the loss of information contained in non-nested data.

[0045] One or more rows of input and output data can be aggregated into a single row for the data. In other embodiments, one or more rows of input and output data can be aggregated into two rows of data, where the first row contains the aggregated input to the transaction and the second row contains the aggregated output to the transaction. These are merely examples, and it should be understood that one or more rows of input and output data can be similarly aggregated to generate more than two rows of aggregated data.

[0046] Aggregation (or compression) can be performed in various ways. For example, in some embodiments, statistical aggregation is performed on each field (or feature) within one or more rows. In this sense, statistical aggregation can be one or any combination of count, mean, median, mean, mode, standard deviation, or range for one or more input and output values ​​of a transaction. However, these are merely examples, and it should be understood that other functions can be similarly applied to combine values ​​within fields.

[0047] It should also be understood that different types of statistical aggregation can be performed on different fields. For example, the values ​​of a first field can be aggregated using a first function (e.g., selected from count, mean, median, mean, mode, standard deviation, or range), and the values ​​of a second field can be aggregated using a second function (e.g., selected from count, mean, median, mean, mode, standard deviation, or range). Aggregation condenses the information within a transaction, reducing the computational cost of data processing without significant loss of information.

[0048] Appendix II provides examples of different functions that can be used to aggregate different fields of input and output data, in an embodiment where the digital currency stored in the blockchain is Bitcoin.

[0049] In the example in Appendix II, the creation of an aggregated transaction table follows a process similar to that of creating a granular transaction table, which is formed by unpacking data. For the aggregated table, functions are applied to the underlying data at the same stage to extract information and create a single-line transaction table. The column for simplified calculations indicates the type of function applied. The process can be summarized as follows: - Step to unpack NoSQL format data into a staging table. - A step to unpack each level into individual stages. - The primary table is SCHEMA.DATASET.btc_block_stg, which performs an outer join with the remaining stages to extract non-nested information into a single table. - Perform joins via functions to construct aggregated transaction tables. - This table includes a label field (illegal flag), which in this example is manually assigned to transactions based on the underlying entity assigned to the address label (e.g., obtained using heuristic methods such as cipher trace), and this is done using the following rule: If any of the following flags = 1, the illegal label is set to = 1 -> dark market, mixer, gambling, high risk exchange, criminal, ransomware, sanctioned. See S206 for more details. - In this embodiment, exemplary inputs to S204 are shown in Figure 4a, and the aggregated transaction data of exemplary outputs is shown in Figure 4b. - Each transaction has a total of approximately 100 features.

[0050] In embodiments, the method may further include labeling transaction data (or aggregated rows of transaction data, if aggregated as described above) for a transaction depending on whether the transaction was fraudulent or not. The labeling can be done in any known manner. For example, a heuristic method can be used to label the data as fraudulent or not.

[0051] In one embodiment, a binary flag is used as a label to indicate whether a transaction is invalid or not (for example, "0" could indicate that it is not invalid, and "1" could indicate that it is invalid, or vice versa).

[0052] A binary flag can be set based on whether any of the underlying entities assigned to an address label are known to be associated with malicious activity. For example, a binary flag can be set to indicate that a transaction is malicious if any of the addresses in one or more input and output rows of the transaction data for the transaction in question are associated with a dark market, high-risk exchange, criminal activity, ransomware, or sanctioned entity.

[0053] One example involves labeling transactions using tools such as CipherTrace(TM). For instance, the various flags output by CipherTrace(TM) can be combined into a single binary flag. However, it should be noted that CipherTrace(TM) is merely an example, and any other tool that heuristically labels transactions as either fraudulent or not can be used in a similar manner.

[0054] These are merely examples, and it should be noted that other methods for labeling transactions can be used similarly. For example, labels can be in the form of probabilities or other scores.

[0055] Figure 5 illustrates exemplary methods according to several embodiments of the present disclosure. In S501, a block in the blockchain is retrieved (e.g., from the cloud as described above), unpacked, and the transactions contained therein are deciphered. In S502, the outputs and inputs contained within the unpacked transactions are deciphered. In S503, the inputs and outputs are placed in a large transaction table using the transaction ID as the primary key. Transaction data for neighboring transactions is also added using the hash identifier of the previous transaction, which provides the association. In S504, the data is combined with another data source, such as CipherTrace(TM) described above, to label the input and output rows of the transaction data as either invalid or invalid. In S505, in this embodiment, the labeled inputs and outputs are aggregated into a single row of aggregated transaction data. This aggregation can significantly reduce computational costs.

[0056] Figure 6 illustrates how the unpacking method in Figure 5 can be adapted to embodiments of the present disclosure. As previously mentioned, the scope of block 600 can be queried using the Google Cloud API with well-known resources such as Jupyter Notebook. The block is then downloaded as shown in Figure 5 and prepared in an aggregated transactional format 602 containing transactional information and entity information necessary for analysis and visualization. This makes the amount of data easily manageable with a single resource, and the blocks in the aggregated transactional format 602 can be compiled into a merged data frame 604. Data for use in analysis and visualization can be extracted from this merged data frame 604: a first script 606 (or function, set of scripts, or set of scripts and functions) extracts aggregated entity information 610 from the merged data frame 604; and a second script 608 (or function, set of scripts, or set of scripts and functions) extracts aggregated transactional information for use with the aggregated entity information 610. All of this information can be aggregated into a new block analysis table 612 for visualization and data analysis.

[0057] Figure 7 shows elements of a software solution (which can be implemented, for example, as a Python-based script using standard data science libraries familiar to those skilled in the art) for performing this extraction and aggregation process for visualization. This software solution 700 is adapted to provide both visualization of transactions stored in the blockchain and statistical information accompanying this visual output. Such a solution can be implemented as a standalone software application, a web application, or as a plug-in to a blockchain wallet or other related software.

[0058] This software solution extracts transaction data from the blockchain, processes this data, and creates a visual representation. Furthermore, it calculates statistical parameters such as the mean, median, and standard deviation, and presents them in a visual format for easier understanding. Such a solution simplifies the processing for analyzing and understanding blockchain transactions. This allows data to be presented in a more interpretable manner, reducing the complexity associated with raw blockchain data. This software solution provides a scalable system capable of efficiently handling large amounts of data. This also enables customization based on user preferences. An exemplary implementation of such software solution 700 includes the following modules.

[0059] The data extraction module 702 connects to the relevant blockchain via the relevant API or installation of a local blockchain node and extracts transaction data. It then filters and structures this data for further processing. The extracted data may include, but is not limited to, transaction ID, timestamp, involved addresses, amount transferred, block ID, etc.

[0060] The data processing module 704 processes the extracted data and prepares it for visualization and statistical analysis. This can be implemented using data structures such as pandas.DataFrame for efficient data handling and manipulation. It organizes the data in a manner that highlights the key functions necessary for analysis and visualization.

[0061] Visualization module 706 can utilize libraries such as Matplotlib and Seaborn to visualize processed data. This allows for the creation of various types of figures and graphs, including bar charts, line charts, pie charts, and heatmaps. Users can select the type of visualization based on their preferences. Interactive visualizations using libraries such as Plotly are also supported, allowing users to gain further detail through zooming, panning, and hovering over data points.

[0062] The statistical analysis module 708 performs statistical calculations on data. It calculates the mean, median, and standard deviation of various parameters such as transaction volume, block size, total transaction volume, total transaction volume, aggregated sum, and confirmation time. It can also provide a histogram of the frequency distribution of the parameters. For these calculations, implementations can utilize libraries such as numpy and scipy.

[0063] The user interface module 710 provides an intuitive interface for the user to interact with the system. The module can provide functions including options for selecting the type of visualization, the statistical parameters to be calculated, the time range for analysis, and further details.

[0064] Export module 712 allows users to export visualized data and statistical results in various formats such as PNG, JPEG, CSV, or JSON for further use.

[0065] This approach makes it easy to analyze and visualize transactions across a wide range of the blockchain, which is not realistically achievable from raw data due to its volume and complexity. As a result, it becomes possible to analyze transactions within a block range and understand the underlying data (labels, transaction volume, mining volume, etc.). Such analysis results can also include identifying bugs when there are outliers in classified entities. Furthermore, model performance (e.g., performance in labeling transactions as fraudulent) can be evaluated across a wide range of transactions, and it can be determined whether the fraudulent transaction detection model is particularly superior or inferior to existing analytics (e.g., for specific entity types).

[0066] By using this method, which provides analysis and visualization of transactions across the blockchain, the following results can be achieved: • It can inform customers of the current illegal landscape for a given month, and can also provide aggregated information about current transactions within the network (average transaction value, current transactions within a 24-hour period, etc.). Existing cryptocurrency analysis products (such as CipherTrace Inspector) can use this method to build landing page analytics for data stored for evaluation. • Current data output can be evaluated to classify entities or to validate entity classifications. Any errors within the existing pipeline will be identified because, if large entities are misclassified, it will lead to spikes for a given entity. • It can identify trends in criminal activity (see below). The quality of Bitcoin transaction monitoring can be backtested. By extracting results from the model and comparing them with actual entities, the underlying model performance trends can be identified (e.g., whether the model excels at identifying darknet marketplace transactions, gambling transactions, mixing, etc.).

[0067] An exemplary use of this analysis and visualization is shown in Figure 8. This illustrates both the perception of the current illegal landscape and the identification of trends in criminal activity. Here, the bar graph for Bitcoin entities shows a spike in the DarkMarket in February 2022, with addresses reaching higher levels as a result of a significant increase in the number of input addresses during this period. This was determined to be the result of a large amount of Bitcoin being moved from the darknet market, which was shut down by law enforcement during this period. This spike can be inferred to be the result of illegal activity, with criminals withdrawing large sums of money from the DarkMarket.

[0068] Turning to another embodiment, a computer program product comprising a computer-readable medium is further provided, the computer-readable medium including computer-readable code embodied therein, the computer-readable code being configured such that, when executed by a suitable computer or processor, the computer or processor implements one or more of the methods described herein (e.g., Method 200 and / or Method 700).

[0069] Accordingly, it is understood that this disclosure also applies to computer programs, particularly computer programs on or within a medium, which are adapted to result in the implementation of embodiments. The programs may be, for example, in the form of partially compiled source code, object code, code intermediate source, and object code, or any other form suitable for use in embodiments of the methods described herein.

[0070] It is further understood that such programs can have many different architectural designs. For example, program code that implements the functionality of a method or system can be subdivided into one or more subroutines. Many different techniques for distributing functionality among these subroutines will become apparent to those skilled in the art.

[0071] Subroutines are stored together in a single executable file to form an embedded program. Such an executable file contains computer executable instructions, such as processor instructions and / or interpreter instructions (e.g., Java interpreter instructions). Alternatively, one, more, or all of the subroutines are stored in at least one external library file and linked statically or dynamically, for example, at runtime, to the main program. The main program contains at least one call to at least one of the subroutines. The subroutines further contain function calls to each other.

[0072] The medium for a computer program is any entity or device capable of recording the program. Examples of mediums include data storage devices such as CD-ROMs or semiconductor ROMs, or magnetic storage media such as hard disks. Furthermore, the medium is a transmittable medium, such as electrical or optical signals, carried via electrical or optical cables, or by wireless or other means. If the program is embodied in such signals, the medium consists of such cables or other devices or means. Alternatively, the medium is an integrated circuit in which the program is incorporated, and the integrated circuit is adapted to perform or used to perform the relevant methods.

[0073] Modifications of the disclosed embodiments can be understood and implemented by those skilled in the art in relation to the implementation of the claimed disclosure by considering the drawings, this disclosure, and the appended claims. In the claims, the term “equipment” does not exclude other elements or steps, and the singular does not exclude the plural. One processor or other unit implements the functions of several items described in the claims. Alternatively, one or more processors or other units may jointly perform the single functional aspects described in the claims.

[0074] Within the scope of this application, the various aspects, embodiments, examples, alternatives, and especially their individual features described in the preceding paragraphs, claims, and / or the following detailed description and drawings are expressly intended to be treated independently or in any combination. That is, any embodiment and / or features of any embodiment can be combined in any aspect and / or combination, provided that their features are not incompatible. The applicant reserves the right to modify any claim originally stated or to state any new claims, including the right to make any claim originally stated dependent on and / or incorporate any feature of any other claim, even if not originally stated in such manner. No reference numeral in the claims shall be construed to limit the scope of the claims.

[0075] [Table 1-1] [Table 1-2]

[0076] [Table 2-1] [Table 2-2] [Table 2-3] [Table 2-4]

Claims

1. A computer implementation method for decomposing a blockchain including transactions in a digital currency for analysis and display, the method is The steps include determining the range of blocks within the blockchain (202), The steps include unpacking (204) each block within the range of the block in the blockchain into a table having one or more rows for input and output data for each transaction stored in the block, (206) Steps include aggregating entity information and transaction information in a block analysis table for the range of the block within the blockchain, Methods that include...

2. A method according to claim 1, further comprising the step of unpacking each block and then merging the table for each block into a merged data frame.

3. A method according to claim 2, wherein the step of aggregating entity information and transaction information into the block analysis table includes extracting the aggregated entity information and aggregated transaction information relating to the aggregated entity information from the merged data frame using one or more scripts or functions.

4. In the method according to any one of claims 1 to 3, the transaction data is stored in a tree structure, and the step (202) of unpacking each block within the range of the block is performed for each block within the range of the block: The steps include unpacking the block into a table having one or more rows for input and output data for each transaction stored within the block, A method comprising the step of aggregating one or more rows of the aforementioned input and output data to form aggregated rows of transaction data for each transaction.

5. In the method according to claim 4, the step of unpacking the block is: The steps include unpacking the aforementioned block into multiple stages, A method comprising the step of performing an outer join between the aforementioned multiple stages to obtain a table having one or more rows for the input and output data for each transaction.

6. The step of performing the external coupling in the method according to claim 5 is: The steps include using the SCHEMA.DATASET.btc_block_stg table as the primary table, A method comprising the step of performing an outer join on one of the aforementioned stages to extract non-nested information from the block into the table.

7. In the method according to any one of claims 4 to 6, The aforementioned block is stored in NoSQL format.

8. A method according to any one of claims 4 to 7, wherein the step of aggregating one or more rows of the input and output data includes integrating the one or more rows into a single row by performing statistical aggregation of the values ​​of each field in each row of the input and output data.

9. A method according to any one of claims 1 to 8, further comprising the step of labeling some or each of the transactions as fraudulent, wherein the labeling step (204) is in part on whether the addressee listed in the transaction data is known to be involved in fraudulent activity.

10. A method according to any one of claims 1 to 9, wherein the digital currency is based on an Unspent Transaction Output (UTxO) design.

11. A method according to any one of claims 1 to 10, further comprising the step of analyzing digital currency activity using the block analysis table.

12. A method according to any one of claims 1 to 11, further comprising the step of displaying digital currency activity using the block analysis table.

13. A node in a computing network that decomposes a blockchain containing transactions in a digital currency for analysis and display, wherein the node: The steps include determining the range of blocks within the aforementioned blockchain, The steps include unpacking each block within the range of the block in the blockchain into a table having one or more rows for input and output data for each transaction stored in the block, The steps include aggregating entity information and transaction information into a block analysis table for the scope of the block within the blockchain, A node configured to run [the command / function].

14. A node according to claim 13, wherein the node is further configured to perform the method described in any one of claims 2 to 12.

15. A computer program product comprising a computer-readable medium, wherein computer-readable code is embodied within the computer-readable medium, and the computer-readable code is configured such that, when executed by a suitable computer or processor, it causes the computer or processor to perform the method described in any one of claims 1 to 12.

Images