A method and system for collecting, storing and analyzing blockchain transaction data

Abstract

The present invention relates to the field of blockchain smart contract technology and discloses a method for collecting, storing, and analyzing blockchain transaction data. This method utilizes distributed technology and multiple nodes to perform distributed extraction of blockchain transaction data. This method allows for rapid revisiting of blocks, rapidly collecting blockchain transaction data, generating structured transaction data, and establishing a relational blockchain transaction database that supports the use of a relational query language to analyze the relationships between transaction data. The present invention also discloses a blockchain transaction data collection, storage, and analysis system, comprising a distributed blockchain transaction data collection unit and a blockchain transaction database unit. The present invention is used to rapidly collect and analyze blockchain transaction data and store it in a relational blockchain transaction database to extract the commercial value of the blockchain data.

Description

Technical Field

[0001] The present invention relates to the field of blockchain smart contract technology. Specifically, it relates to a method and system for collecting, storing and analyzing blockchain transaction data. The method is used to quickly collect and analyze blockchain transaction data and store it as a relational blockchain transaction database to extract the commercial value of the blockchain data. Background Art

[0002] The massive amount of data generated by blockchain systems brings enormous commercial value, but also presents technical challenges for analyzing heterogeneous blockchain data. As the volume of blockchain data continues to grow, existing methods for collecting blockchain transaction data, which rely on synchronized data from the mainnet and replay it, are slow and rely on peer-to-peer networks between blockchain nodes. Furthermore, the inconsistent storage structure of collected data complicates transaction data analysis. While blockchain transaction data holds enormous commercial value, effective methods for extracting this value from it are lacking. This is because existing methods for storing blockchain transaction data simply store transactions by ID and content in a key-value database, failing to establish a relational database for the transaction data. Consequently, they do not support the use of relational query languages ​​to analyze connections between transaction data.

[0003] Patent CN111680105A discloses a blockchain-based distributed relational database management method and system. The present invention differs from CN111680105A in that the patent primarily combines blockchain and relational databases, using blockchain as a storage facility for the relational database. The present invention, on the other hand, utilizes a multi-node, distributed approach to extract transaction data from the blockchain and organizes it into a relational database to support relational queries, analyze associations between blockchain addresses, and extract the commercial value of the transaction data. Patent CN109726249A discloses a decentralized chip R&D transaction data storage method and system. The present invention differs from CN109726249A in that the patent primarily utilizes blockchain for decentralized storage of chip R&D transaction data, storing it on the blockchain. The present invention, on the other hand, utilizes a multi-node, distributed approach to extract transaction data from the blockchain and organize it into a relational database.

[0004] In order to more effectively solve the problems existing in existing methods, quickly collect blockchain transaction data, generate structured transaction data, and quickly collect and analyze blockchain transaction data, the present invention provides a method and system for using multiple nodes to perform distributed collection of blockchain transaction data and establish a relational blockchain transaction database to store transaction data. Summary of the Invention

[0005] The purpose of the present invention is to provide a method and system for collecting, storing and analyzing blockchain transaction data, thereby realizing the function of rapidly collecting and analyzing blockchain transaction data, and having the effect of storing the blockchain as a relational blockchain transaction database to extract the commercial value of the blockchain data.

[0006] The present invention is implemented through the following technical solution: a method for collecting, storing and analyzing blockchain transaction data, comprising the following steps:

[0007] Step S1. Start the blockchain master node and download the complete snapshot and data log from the node that has completed blockchain data synchronization;

[0008] Step S2. Read the downloaded snapshot from the master node and calculate the total number of blocks that need to be replayed and transaction data collected;

[0009] Step S3. The master node starts N slave nodes and calculates the replay start position P1 to PN of each slave node according to the number of blocks;

[0010] Step S4. The master node reads the downloaded node snapshot, obtains the blockchain states 1 to N corresponding to the replay start positions P1 to PN, and initializes the slave node to the blockchain state corresponding to its replay start position;

[0011] Step S5. The master node divides the downloaded data log into N blocks from positions P1 to PN, and distributes the N blocks of data log to N slave nodes;

[0012] Step S6. The slave node reads the data log distributed by the master node, replays all blocks in the data log, captures the intermediate process information of transaction execution in the blockchain Ethereum virtual machine, records the difference in the world state after each block is executed in sequence in the Ethereum virtual machine, and extracts the transaction data in the block;

[0013] Step S7. The slave node de-duplicates and removes redundant information from the extracted transaction data, compresses it, and saves it in a formatted CSV or JSON file in block number order.

[0014] Step S8. Initialize the transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information;

[0015] Step S9. Read the formatted transaction data file and obtain the transaction content in the formatted transaction data file;

[0016] Step S10: Update the block table, address table, and transaction table information involved in each transaction according to the transaction content.

[0017] In order to better implement the present invention, further, the method for calculating the replay start position of each slave node in step S3 includes:

[0018] The specific calculation method for the replay starting position of each slave node is Pi = (i - 1) * B / N, where i represents the slave node number, which is numbered from 1 to N, B represents the total number of blocks B that need to be collected, and N represents the number of slave nodes.

[0019] In order to better implement the present invention, further, step S6 includes:

[0020] When the Ethereum virtual machine executes the transactions saved in the block, the slave node performs a hash operation on the detailed transaction data to generate transaction data.

[0021] In order to better implement the present invention, further, the updating method of the block table in step S10 includes:

[0022] Extract the block number, block time, packaged block address and other information from the transaction content, and count all transaction quantities contained in the block and store them in the block table.

[0023] In order to better implement the present invention, further, the address table updating method in step S10 includes:

[0024] Extract the sender address and receiver address of the transaction content. If the sender address or receiver address does not exist in the address table, add a record to the address table and set the fund balance and transaction count of the address to 0. Then, read the fund balance and transaction count of the sender address and transfer the funds.

[0025] In order to better implement the present invention, further, the updating method of the transaction table in step S10 includes:

[0026] Insert the transaction block, transaction ID, sender and receiver addresses, and transaction content into the transaction table as a new record.

[0027] In order to better implement the present invention, the present invention further provides a blockchain transaction data collection, storage and analysis system, including a distributed blockchain transaction data collection unit and a blockchain transaction database unit, wherein:

[0028] A distributed blockchain transaction data collection unit, which is used to read the complete snapshot and log data downloaded from the nodes that have completed data synchronization, replay blocks from the log data, extract transaction data, deduplicate and compress the extracted transaction data, and finally save the transaction data into a structured CSV or JSON file;

[0029] The blockchain transaction database unit is used to initialize the blockchain transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information; is used to read the formatted transaction data file extracted by the distributed blockchain transaction data collection unit, and read the transaction content in the file; is used to parse the transaction content and update the block table, address table and transaction table information involved in each transaction.

[0030] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0031] (1) The present invention can collect blockchain transaction data in a distributed manner, using a master node to control multiple slave nodes to replay the blockchain in parallel, thereby exponentially increasing the speed of blockchain transaction data collection;

[0032] (2) The present invention directly downloads the complete snapshot and data log from the blockchain node that has completed data synchronization, downloading all blocks at once, without the need to synchronize and replay each block from the blockchain P2P node, so the data collection speed is faster;

[0033] (3) The present invention can store blockchain transaction data as a relational transaction database, which can reduce the storage space overhead of storing transaction data, support the use of relational query language to query transactions, analyze the relationship between blockchain addresses, and extract the commercial value of transaction data. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The present invention is further described in conjunction with the following drawings and embodiments, and all concepts and innovations of the present invention should be regarded as disclosed contents and the protection scope of the present invention.

[0035] Figure 1 A flowchart of a method for collecting, storing and analyzing blockchain transaction data provided by the present invention.

[0036] Figure 2 A flowchart of node transaction collection in a method for collecting, storing and analyzing blockchain transaction data provided by the present invention.

[0037] Figure 3 This is a structural diagram of a blockchain transaction data collection, storage and analysis system provided by the present invention. DETAILED DESCRIPTION

[0038] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. It should be understood that the described embodiments are only part of the embodiments of the present invention, not all of the embodiments, and therefore should not be regarded as limiting the scope of protection. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technical personnel in this field without making creative work are within the scope of protection of the present invention.

[0039] In describing this invention, it should be noted that blockchain masternodes are a unique feature of some current blockchains. Masternodes are typically more extensively equipped than regular nodes. In addition to validating, storing, and transmitting transactions, masternodes sometimes facilitate other blockchain events, such as voting, executing protocol operations, and adhering to blockchain laws, depending on their nature. Masternodes are typically always online and provide significantly more memory than regular nodes. Because masternode ownership typically requires more resources (power, uptime, maintenance, storage space, memory), ownership is often compensated in the form of interest. However, not everyone can operate a masternode. The ability to control masternodes can be abused, and projects such as DASH and Ethereum use and create masternodes within their structures.

[0040] Example 1:

[0041] A method for collecting, storing, and analyzing blockchain transaction data in this embodiment includes the following steps:

[0042] Step S1. Start the blockchain master node and download the complete snapshot and data log from the node that has completed blockchain data synchronization;

[0043] Step S2. Read the downloaded snapshot from the master node and calculate the total number of blocks that need to be replayed and transaction data collected;

[0044] Step S3. The master node starts N slave nodes and calculates the replay start position P1 to PN of each slave node according to the number of blocks;

[0045] Step S4. The master node reads the downloaded node snapshot, obtains the blockchain states 1 to N corresponding to the replay start positions P1 to PN, and initializes the slave node to the blockchain state corresponding to its replay start position;

[0046] Step S5. The master node divides the downloaded data log into N blocks from positions P1 to PN, and distributes the N blocks of data log to N slave nodes;

[0047] Step S6. The slave node reads the data log distributed by the master node, replays all blocks in the data log, captures the intermediate process information of transaction execution in the blockchain Ethereum virtual machine, records the difference in the world state after each block is executed in sequence in the Ethereum virtual machine, and extracts the transaction data in the block;

[0048] Step S7. The slave node de-duplicates and removes redundant information from the extracted transaction data, compresses it, and saves it in a formatted CSV or JSON file in block number order.

[0049] Step S8. Initialize the transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information.

[0050] like Figure 1 As shown in this embodiment, the primary application scenario of the present invention is the collection and storage of transaction data from multiple public blockchain platforms with large data volumes. On the one hand, the data volume of public blockchain platforms is enormous, with block transaction history data reaching over ten terabytes, the number of blocks reaching tens of millions, and the number of transactions exceeding one billion. As the volume of blockchain data continues to increase, existing blockchain transaction data collection methods use a single node and a P2P network synchronization method to download and replay blocks one by one, resulting in slow data collection and no longer meeting the needs for replaying and collecting blockchain transaction data. The present invention, however, enables distributed extraction of blockchain transaction data using multiple nodes, enabling rapid revisiting of blocks and collection of transaction data. On the other hand, the commercial value of blockchain transaction data is enormous, but there is a lack of effective methods for extracting this commercial value from transaction data. This is because existing blockchain transaction data storage methods simply store transactions according to transaction ID and transaction content in a key-value database, failing to establish a relational database for the transaction data and, therefore, not supporting the use of relational query languages ​​to analyze the relationships between transaction data. The present invention generates structured transaction data and establishes a relational blockchain transaction database, supporting the use of relational query languages ​​to analyze the relationships between transaction data.

[0051] This method uses distributed technology to replay blockchain transaction data in parallel. A master node distributes the replay tasks, while multiple slave nodes collect transaction data in parallel, starting from different block numbers. After cleaning and filtering the blockchain transaction data, the slave nodes organize it into a uniformly structured formatted file and aggregate it to the master node, facilitating further analysis of the transaction data. Furthermore, this method directly downloads a complete snapshot and data log from a synchronized blockchain node, processes the snapshot and data log locally, and collects transaction data, rather than synchronizing and replaying each block individually through a peer-to-peer network between blockchain nodes. In this embodiment, the snapshot in step S2 refers to the blockchain world state at a specific moment. The blockchain world state primarily includes the smart contracts deployed on the blockchain at that moment, the data stored by these smart contracts, all blockchain addresses at that moment, and the transaction history. The data log described in step S5 refers to a data file generated by the blockchain node, containing information about all blocks. The Ethereum virtual machine described in step S6 is a stack-based virtual machine used to execute the transactions contained in the block.

[0052] Example 2:

[0053] This embodiment is further optimized based on the embodiment 1. This embodiment discloses: Step S8. Initialize the transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information;

[0054] Step S9. Read the formatted transaction data file and obtain the transaction content in the formatted transaction data file;

[0055] Step S10: Update the block table, address table, and transaction table information involved in each transaction according to the transaction content.

[0056] This embodiment reads transactions from a structured transaction data file and serializes the transaction information. Abnormal transaction data is detected by monitoring the change in the transaction balance status after each transaction is executed on the address on the blockchain. For example, the following steps are performed:

[0057] Establish a blockchain status database to save the transaction status BS of the blockchain address, the historical average transaction status change BD, and the associated transaction graph G.

[0058] The formatted transaction data file extracted by the method described in Invention Summary 1 is read, and the transaction content is parsed based on the transaction data in the file.

[0059] Based on the transaction content, update the transaction status BS' of two or more addresses involved in each transaction, calculate the current single transaction change BD' of each address caused by the current transaction, and update the address-associated transaction graph G and the historical average transaction change BD.

[0060] Based on the difference between the current single transaction change BD' and the historical average change BD of each address, as well as the address-associated transaction graph G, determine whether the current transaction is an abnormal transaction.

[0061] The transaction state (BS) is a vector that stores information including, but not limited to, the current amount of each data currency at an address. The historical average transaction state change vector (BD) stores the weighted average of all historical transaction state changes for that address. The address-linked transaction graph (G) stores the transaction connections between addresses. Vertices in the graph represent addresses, while edges represent the historical transaction amounts or the most recent single transaction amount between the addresses represented by two vertices, or whether the addresses represented by two vertices belong to the same organization or entity. The formatted transaction data file stores all transaction data on all blockchains in a structured manner. The historical average transaction change (BD) is calculated using a weighted average. The address-linked transaction graph is updated by adding an edge if one does not exist between two vertices representing addresses. The edge weight is increased by the transaction amount. If an edge exists between two vertices, the edge weight is increased by the transaction amount. Furthermore, addresses represented by vertices that have traded with each other more than a certain number of times are marked as belonging to the same organization or entity. Criteria for determining whether a transaction is abnormal include, but are not limited to: the change in the current single transaction significantly exceeds the historical average transaction status change, or significantly exceeds the historical transaction amount of the two addresses in the address-linked transaction graph G, and the two addresses do not belong to the same organization or entity. The processing of the recipient address is similar to the address table update method: the transaction balance is increased by the transaction amount of the current transaction, and the transaction count is incremented by one.

[0062] The rest of this embodiment is the same as that of embodiment 1, so it will not be described again.

[0063] Example 3:

[0064] This embodiment further optimizes the above-mentioned embodiments 1 or 2. Before starting the blockchain master node, this embodiment first instrumentes the slave blockchain client code, adding transaction data capture and processing code. This embodiment instrumentes the blockchain functions that read blocks from log files, parse block information, and execute transactions within those blocks. Specifically, the instrumented code within the function that reads blocks from log files records the current log location. The instrumented code within the function that parses block information records block header information, including the block number, block hash, parent block hash, and timestamp. The instrumented code within the function that executes transactions within blocks reads detailed transaction information, including the initiator's address, recipient address, transaction amount, and transaction inputs.

[0065] The rest of this embodiment is the same as that of the above-mentioned embodiment 1 or 2, and thus will not be described in detail.

[0066] Example 4:

[0067] This embodiment further optimizes any one of the above embodiments 1-3, and discloses:

[0068] Start the blockchain master node and download the complete snapshot and data log from the node that has completed blockchain data synchronization. The master node starts by downloading the complete snapshot and data log from the node that has completed blockchain data synchronization. After the snapshot and data log are downloaded, the master node reads the downloaded node snapshot and calculates the total number of blocks B that need to be replayed and collected for transaction data. Subsequently, the master node starts N slave nodes numbered 1-N, replays and collects the number of blocks of transaction data as needed, and calculates the replay start position P1 to PN for each slave node. The specific calculation method for the replay start position of each slave node is:

[0069] Pi = (i - 1) * B / N;

[0070] Wherein, i represents the slave node number, which is numbered from 1 to N, B represents the total number of blocks B that need to be collected, and N represents the number of slave nodes. After calculating the replay start position, the master node reads the downloaded node snapshot, obtains the blockchain state 1 to state N corresponding to the replay start position P1 to PN, and initializes the slave node to the blockchain state corresponding to its replay start position. The master node then divides the downloaded data log from the position into N blocks, and distributes these N blocks of data logs to N slave nodes. The snapshot referred to in this embodiment refers to the blockchain world state of the blockchain at a certain moment. The blockchain world state mainly includes: the smart contracts that have been deployed on the blockchain at a certain moment and the data stored by these smart contracts, all blockchain addresses at a certain moment, and transaction history. The main purpose of this stage is to make the blockchain state Si of each slave node numbered i consistent with the blockchain state corresponding to the replay start position block Pi, so that the local node can start reading the block and replay it from the position specified by the master node;

[0071] The slave node reads the data log distributed by the master node, replays all blocks in the data log, captures intermediate transaction execution information within the blockchain's EVM (Ethereum Virtual Machine), records the difference in the world state after each block's transactions are sequentially executed within the EVM, and extracts the transaction data within the block. In this embodiment, when the EVM executes a transaction stored in a block, the slave node hashes the detailed transaction data to generate a transaction digest, and writes the transaction data to a main memory buffer. When the buffer is full, the transaction data processing code initiates a second thread to extract information such as the initiator address, recipient address, transaction amount, and transaction input from the transaction data in the buffer by block number. The data is organized into a structured CSV format file, compressed, and written to a persistent storage medium. The generated transaction digest is then used to verify the integrity and correctness of the transaction data. The hashing methods used to generate the transaction digest in this embodiment include, but are not limited to, MD5, SHA256, and SHA3. The data compression methods used include, but are not limited to, DEFLATE, RLP, and any other algorithm capable of data compression. The specific implementation techniques used in this embodiment do not in any way limit the scope of the present invention.

[0072] The master node collects the structured data files generated by the slave nodes and aggregates them into a complete blockchain transaction data file. The specific collection and aggregation method is: traversing all slave nodes according to the block replay start position, concatenating the structured data files generated by each slave node in the order of the replayed block number, and generating a complete blockchain transaction data file.

[0073] The rest of this embodiment is the same as any of the above embodiments 1-3, so it will not be repeated here.

[0074] Example 5:

[0075] This embodiment further optimizes any of the above embodiments 1-4. In this embodiment, the transaction database is initialized, a block table is established to store block information, an address table is established to store address information, and a transaction table is established to store transaction information. The data structures of the address table, block table, and transaction table used in this embodiment are as follows: "Address" is the data structure of the address table, where the "Addr" field stores the hexadecimal representation of the address, the "BlockNum" and "TransactionID" fields store the block number and transaction number where the address first appears in a blockchain transaction, and the "Code" field stores the bytecode of the smart contract deployed at the address. "Transaction" is the data structure of the transaction table, where the "Id" field stores the transaction hash value, the "BlockNum" and "BlockTime" fields store the block number and block time of the transaction, the "Receiver", "Sender", and "Amount" fields store the recipient, sender, and transaction amount of the transaction, respectively, and the "Data" field stores the complete transaction information. "Block" is the data structure that stores block information, where the "BlockNum" and "BlockTime" fields store the block number and block time, and the "Miner" field stores the address that produced the block. For example:

[0076] type Address struct {

[0077] Addr string `gorm:"type:varchar(13);primaryKey"`

[0078] BlockNum uint64

[0079] TransactionId string `gorm:"type:varchar(64)"`

[0080] Code []byte `gorm:"type:bytea"`

[0081] }

[0082] type Transaction struct {

[0083] Id string `gorm:"type:varchar(64);primaryKey"`

[0084] BlockNum uint64

[0085] BlockTime time.Time

[0086] Receiver Address

[0087] Sender Address

[0088] Amount uint64

[0089] Data []byte `gorm:"type:bytea"`

[0090] }

[0091] type Block struct {

[0092] BlockNum uint64

[0093] BlockTime time.Time

[0094] Miner Address

[0095] }.

[0096] The rest of this embodiment is the same as any of the above embodiments 1-4, so it will not be repeated here.

[0097] Example 6:

[0098] This embodiment further optimizes any one of the above embodiments 1-5, reads the formatted transaction data file extracted by the distributed blockchain transaction data collection unit, and reads the transaction content in the file. In this embodiment, the structured transaction data file uses the CSV format. The blockchain transaction database reads the records in the CSV file one by one, reads the various attributes in the record, and constructs a complete transaction content.

[0099] Based on the transaction content, the block table, address table, and transaction table information involved in each transaction are updated. The block table is updated by extracting information from the transaction content, such as the block number, block generation time, and address of the packaged block. The number of transactions contained in the block is then counted and stored in the block table. The address table is updated by extracting the sender and receiver addresses from the transaction content. If the sender or receiver address does not exist in the address table, a record is added to the address table, and the balance and transaction count for that address are set to 0. The sender's balance and transaction count are then read, and the transaction amount is subtracted from the balance, while the transaction count is incremented. The receiver's address is processed similarly: the balance is incremented by the transaction amount, and the transaction count is incremented. The transaction table is updated by inserting the transaction's block, transaction ID, sender and receiver addresses, and transaction content into the transaction table as a new record.

[0100] The rest of this embodiment is the same as any of the above embodiments 1-5, so it will not be repeated here.

[0101] Example 7:

[0102] This embodiment is further optimized based on any one of the above embodiments 1-6. Figure 1-Figure 3 As shown, the present invention provides a blockchain transaction data collection and abnormal transaction analysis system, which includes two units, namely a distributed blockchain transaction data collection unit and a blockchain transaction database unit.

[0103] The distributed blockchain transaction data collection unit reads the complete snapshot and log data downloaded from nodes that have completed data synchronization, replays blocks from the log data, extracts transaction data, deduplicates and compresses the extracted transaction data, and finally saves the transaction data into a structured CSV or JSON file. To quickly replay transaction data, the distributed blockchain transaction data collection unit uses a master node to distribute the replay task. Multiple slave nodes collect transaction data in parallel starting from different block numbers. After cleaning and filtering the blockchain transaction data, the slave nodes organize it into a uniformly formatted file and aggregate it to the master node to facilitate further analysis of the transaction data. Instead of connecting to the blockchain P2P node network and synchronizing data block by block from other nodes on the network, the distributed blockchain transaction data collection unit directly downloads the complete snapshot and log data from the nodes that have completed data synchronization.

[0104] The role of the blockchain transaction database is to use the structured transaction data files generated by the local nodes of the blockchain in this embodiment to establish a relational database of blockchain transactions, so as to reduce the storage space overhead of storing transaction data, support the use of SQL statements to query transactions, analyze the relationship between blockchain addresses, and extract the commercial value of transaction data.

[0105] The rest of this embodiment is the same as any of the above embodiments 1-6, so it will not be repeated here.

[0106] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any simple modification or equivalent change made to the above embodiment based on the technical essence of the present invention falls within the scope of protection of the present invention.

Claims

1. A method for collecting, storing and analyzing blockchain transaction data, characterized in that: The following steps are involved: Step S1. Start the blockchain master node and download the complete snapshot and data log from the node that has completed blockchain data synchronization; Step S2. Read the downloaded snapshot from the master node and calculate the total number of blocks that need to be replayed and transaction data collected; Step S3. The master node starts N slave nodes and calculates the replay start position P1 to P2 of each slave node according to the number of blocks. N ; Step S4. The master node reads the downloaded node snapshot and obtains the replay start position P1 to P N The corresponding blockchain states 1 to N, and the slave node is initialized to the blockchain state corresponding to the replay start position; Step S5. The master node moves from P1 to P N The location splits the downloaded data log into N blocks and distributes the N blocks of data log to N slave nodes; Step S6. The slave node reads the data log distributed by the master node, replays all blocks in the data log, captures the intermediate process information of transaction execution in the blockchain Ethereum virtual machine, records the difference in the world state after each block is executed in sequence in the Ethereum virtual machine, and extracts the transaction data in the block; Step S7. The slave node de-duplicates and removes redundant information from the extracted transaction data, compresses it, and saves it in a formatted CSV or JSON file in block number order. Step S8. Initialize the transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information; Step S9. Read the formatted transaction data file and obtain the transaction content in the formatted transaction data file; Step S10: Update the block table, address table, and transaction table information involved in each transaction according to the transaction content.

2. A method for collecting, storing and analyzing blockchain transaction data according to claim 1, characterized in that: The method for calculating the replay start position of each slave node in step S3 includes: The specific calculation method for the replay starting position of each slave node is Pi = (i - 1) * B / N, where i represents the slave node number, which is numbered from 1 to N, B represents the total number of blocks B that need to be collected, and N represents the number of slave nodes.

3. A method for collecting, storing and analyzing blockchain transaction data according to claim 1, characterized in that: The step S6 comprises: When the Ethereum virtual machine executes the transactions saved in the block, the slave node performs a hash operation on the detailed transaction data to generate transaction data.

4. A method for collecting, storing and analyzing blockchain transaction data according to claim 1, characterized in that: The updating method of the block table in step S10 includes: Extract the block number, block time, and packaged block address information from the transaction content, and count all transaction quantities contained in the block and store them in the block table.

5. A method for collecting, storing and analyzing blockchain transaction data according to claim 1, characterized in that: The updating method of the address table in step S10 includes: Extract the sender address and receiver address of the transaction content. If the sender address or receiver address does not exist in the address table, add a record to the address table and set the fund balance and transaction count of the address to 0. Then, read the fund balance and transaction count of the sender address, subtract the transaction amount of the transaction from the fund balance, and increase the transaction count by one.

6. A method for collecting, storing and analyzing blockchain transaction data according to claim 1, characterized in that: The updating method of the transaction table in step S10 includes: Insert the transaction block, transaction ID, sender and receiver addresses, and transaction content into the transaction table as a new record.

7. A system for collecting, storing and analyzing blockchain transaction data, for executing the method for collecting, storing and analyzing blockchain transaction data as claimed in claim 1; characterized in that: It includes a distributed blockchain transaction data collection unit and a blockchain transaction database unit, wherein: A distributed blockchain transaction data collection unit, which is used to read the complete snapshot and log data downloaded from the nodes that have completed data synchronization, replay blocks from the log data, extract transaction data, deduplicate and compress the extracted transaction data, and finally save the transaction data into a structured CSV or JSON file; The blockchain transaction database unit is used to initialize the blockchain transaction database, establish a block table to store block information, establish an address table to store address information, and establish a transaction table to store transaction information; is used to read the formatted transaction data file extracted by the distributed blockchain transaction data collection unit, and read the transaction content in the file; is used to parse the transaction content and update the block table, address table and transaction table information involved in each transaction.

Images