Transaction data storage method and query method of block chain

Abstract

The embodiment of the invention discloses a transaction data storage method and query method of a block chain, relates to the field of block chains, and stores transaction data in a graph form after obtaining the transaction data of the block chain. Wherein the graph comprises an attribute table and a time sequence table, one line in the attribute table comprises all transaction data with a certain specific attribute value in a certain block, and the time sequence table comprises the line number of the transaction data of each block in the attribute table. Based on the data storage structure, when a query condition indicating the timestamp of the transaction data of a user is received, the line number of the transaction data meeting the query condition in the attribute table is determined from the time sequence table according to the timestamp in the query condition. And determining transaction data corresponding to the query condition from the attribute table, and displaying the transaction data to the user. And compression storage is performed through the attribute table, so that the storage space occupied by the graph is small. In this way, compared with the scheme in the prior art, it is not needed to enter the data items for query, and the query efficiency is high.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of blockchain, and in particular to a transaction data storage method and query method for blockchain. Background Art

[0002] Blockchain is a decentralized database technology that records transactions and other data between participating nodes in the form of blocks, using cryptographic methods to ensure data security. All new transactions are recorded in a block, and then multiple blocks are linked chronologically to form a growing chain, forming the blockchain. Each node stores a copy of the blockchain, achieving decentralization.

[0003] There are various types of blockchains, including public, private, and consortium blockchains. Each contains a vast amount of transaction data. As the volume of blockchain data grows, there's a need to analyze this data in many blockchain applications. For example, to ensure transaction transparency, a consortium blockchain stores the transaction data of all businesses in a city. To analyze the city's development, one can query the consortium chain for transaction data that meets certain criteria and analyze the data to determine trends within that data, thereby gaining insights into the city's development.

[0004] Because blockchain transaction data and graphs have similar structures, both consisting of nodes and edges, and graphs are well-suited for data analysis, a "blockchain + graph" approach can be used. Specifically, blockchain transaction data can be stored in the form of a graph, enabling blockchain data analysis using graph-based data analysis methods. In this "blockchain + graph" approach, nodes in the graph represent nodes participating in the blockchain, while edges represent transaction data between different nodes. A graph can represent a block in the blockchain.

[0005] Graphs in the prior art generally use adjacency lists or adjacency matrices to represent the topological relationships between different nodes. This approach has the following drawbacks:

[0006] First, storing blockchain data using adjacency lists or matrices consumes significant storage space. For example, an adjacency matrix is ​​typically an N*N matrix, where N is the number of nodes. In blockchain applications, the number of nodes is typically large, and with a large number of nodes, the adjacency matrix consumes significant storage space. Furthermore, a blockchain consists of multiple blocks, each corresponding to an adjacency matrix. To store transaction data across multiple blocks, multiple adjacency matrices are required. Therefore, storing blockchain transaction data using adjacency matrices consumes significant storage space.

[0007] Secondly, adjacency lists and adjacency matrices generally only indicate whether edges exist between nodes. If you want to store additional information about transaction data between nodes, such as transaction attributes and timestamps, you need to nest a matrix or array within the adjacency list or matrix to store this additional information.

[0008] Querying and analyzing blockchain transaction data is typically done based on conditions such as transaction attributes and / or transaction time. This means that searching for transactions that meet certain criteria requires first finding existing transactions using an adjacency list or matrix, and then filtering out matching transactions using nested matrices or arrays. This suggests that the existing "blockchain + graph" approach to transaction data is inefficient. Summary of the Invention

[0009] The present application provides a transaction data storage method and query method for blockchain, which solves the problems of large storage space occupation and low query efficiency.

[0010] According to a first aspect of the present application, a method for storing blockchain transaction data is provided. After acquiring blockchain transaction data, the transaction data is stored in the form of a graph. The graph includes an attribute table and a time series table. A row in the attribute table includes all transaction data with a specific attribute value in a block, and the time series table includes the row number of each block's transaction data in the attribute table. The attribute table is used to compress edges with the same attribute in a block, thereby reducing the storage space occupied by the graph.

[0011] In one alternative implementation, a row in the attribute table includes three types of data: the attributes of the transaction data in that row, the starting and ending nodes, and the transaction number. Transaction data is also stored in a transaction list, which contains all transaction information (or detailed information) and the transaction number. This allows the graph to store only the content relevant to the query, reducing the graph's space usage while still retaining the transaction list already stored in the blockchain, without changing the blockchain's original data storage method.

[0012] In an alternative embodiment, each row in the attribute table contains a key-value pair. The key in the key-value pair includes the attribute, start node, and end node of the transaction data in that row, with the attribute and node separated by a delimiter. The value in the key-value pair includes the transaction ID of that row. This allows for the graph to be stored in a key-value database, broadening the application of the method presented in this application.

[0013] In an alternative embodiment, where the attribute table includes key-value pairs, the start and end nodes of the transaction data are stored separately, with the attributes and nodes separated by a first delimiter, and the start and end nodes separated by a second delimiter, where the first and second delimiters are different. This facilitates data queries and allows for quick filtering of specific types of data, such as attribute data, based on the delimiters, thereby speeding up data queries.

[0014] In an optional implementation, the time series table also includes multiple key-value pairs, where the key in the key-value pair is the timestamp of the block, and the value in the key-value pair is the row number corresponding to the block in the corresponding key in the attribute table.

[0015] According to a second aspect of this application, a method for querying blockchain transaction data is provided, in which blockchain transaction data is stored in the manner described above. Upon receiving a query condition from a user indicating the timestamp of transaction data, the method first determines the number of rows in the attribute table containing transaction data that meet the query condition from a time series table based on the timestamp in the query condition. The method then determines the transaction data corresponding to the query condition from the attribute table and displays it to the user. Compared to existing solutions, this method improves query efficiency by enabling direct determination of transaction data that meets the query condition from the less complex time series table, eliminating the need to traverse multiple rows or perform queries within data items.

[0016] In an optional embodiment, when a row of the attribute table includes the three types of data mentioned above, and the transaction data is also stored in the form of a transaction list, the above-mentioned process of obtaining the corresponding transaction data from the attribute table includes determining the number of the transaction data that meets the query conditions from the attribute table, and obtaining and displaying the corresponding transaction data from the transaction list according to the number, thereby reducing the storage space occupied by the attribute table.

[0017] In an optional embodiment, the query conditions also include the starting node and / or ending node of the transaction data. In this case, the numbering process requires determining the number of the transaction data that meets the query conditions based on the starting node and ending node included in each row from the number of rows determined in the attribute table. The method shown in this application is highly efficient when querying transaction data that meets the starting node and ending node conditions.

[0018] In an optional embodiment, the query conditions also include attributes of the transaction data. Accordingly, during the query, the transaction data matching the query conditions is identified based on the attributes and numbers included in each row of the attribute table, within the number of rows specified in the attribute table. This ensures high efficiency of attribute queries and minimizes the storage space occupied by the attribute table.

[0019] In one optional embodiment, a graph has two attributes: a first attribute and a second attribute. Correspondingly, the attribute table includes a first attribute table and a second attribute table. Each row in the first attribute table includes all transaction data for the same block with the same first attribute value, while each row in the second attribute table includes all transaction data for the same block with the same second attribute value. If a query condition includes two attribute values, transaction data that meets the query condition is first searched in one attribute table, and then in the other attribute table. This method provided by this application can improve query efficiency.

[0020] In an optional embodiment, the query condition may specifically include the timestamp and / or timestamp range of the transaction data, so that the user can perform a more flexible query.

[0021] In an optional implementation, the blockchain is a consortium chain, and the method provided in this application has a better effect of improving query efficiency in the consortium chain scenario.

[0022] According to the third aspect of the present application, the present application provides an electronic device, including a memory and a processor, the memory is used to store computer programs, and the processor is used to execute computer programs to implement the above-mentioned blockchain transaction data storage method or blockchain transaction data query method.

[0023] According to the fourth aspect of the present application, the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned blockchain transaction data storage method or blockchain transaction data query method is implemented.

[0024] According to a fifth aspect of the present application, the present application provides a computer program product, comprising a computer-readable code, which, when executed by a processor, implements the above-mentioned blockchain transaction data storage method or blockchain transaction data query method.

[0025] It should be understood that the technical solutions provided in the third, fourth, and fifth aspects above, and their technical features can all correspond to the methods provided in the first or second aspect and their optional implementations, so the beneficial effects that can be achieved are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1A A schematic diagram of an adjacency list provided by the prior art;

[0027] Figure 1B A schematic diagram of an adjacency matrix provided by the prior art;

[0028] Figure 2A A schematic diagram of a timing diagram provided for related technology;

[0029] Figure 2B A schematic diagram of another timing diagram provided for related technology;

[0030] Figure 3 A schematic diagram of a property graph provided for related technology;

[0031] Figure 4 A simplified schematic diagram of a system architecture provided in an embodiment of the present application;

[0032] Figure 5 A schematic diagram of the composition of an electronic device provided in an embodiment of the present application;

[0033] Figure 6 A flowchart of a method for storing transaction data in a blockchain provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of a diagram provided in an embodiment of the present application;

[0035] Figure 8 A schematic diagram of a transaction data storage structure provided in an embodiment of the present application;

[0036] Figure 9 A flowchart of a method for querying transaction data in a blockchain provided in an embodiment of the present application;

[0037] Figure 10 A schematic diagram of an application scenario of the present application provided in an embodiment of the present application;

[0038] Figure 11 A flowchart of another blockchain transaction data query method provided in an embodiment of the present application;

[0039] Figure 12 A flowchart of another blockchain transaction data query method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] A blockchain is a decentralized, distributed ledger shared by participating nodes (hereinafter referred to as blockchain nodes). Blockchain nodes can be electronic devices with communication capabilities, each of which stores a copy of the blockchain. From a data structure perspective, a blockchain is a ledger composed of multiple blocks, each storing transaction data that occurred at a specific timestamp. Furthermore, each block includes a hash value of the data stored in the previous block, forming an immutable chain structure. Therefore, each node in the blockchain stores a copy of the ledger, which is also a copy of the blockchain. Each copy of the blockchain is identical, consisting of multiple linked blocks.

[0041] Regarding the specific data recorded on the blockchain, each block can contain metadata, a transaction list, and header data. The header, also known as the block header, includes basic block information, such as a timestamp and the hash value of the previous block. This header data is used to verify the legitimacy of the block and also links the block to the chain through the recorded hash value. The transaction list stores multiple transaction data entries. These transactions are all transactions participated in by nodes on the blockchain at a specific timestamp. The transaction list records detailed information about these transactions, such as the initiator, recipient, and transaction amount. When storing transaction data in the transaction list, one transaction is typically stored before the next. Metadata stores additional information beyond the transaction data, such as transaction notes and digital signatures. Metadata is used to record additional information related to the transaction.

[0042] There are various types of blockchains, including private, consortium, and public. A private blockchain is a type of blockchain that only allows participation from specific nodes and is typically controlled by a single node. A consortium blockchain is a type of blockchain that is jointly managed and participated in by multiple specific nodes. A public blockchain is a blockchain that all nodes can participate in. With the development of blockchain technology, it has been applied in a variety of fields, such as banking, healthcare, human resources, supply chain, and digital music distribution. Due to their distinct characteristics, the three types of blockchains are generally used in different scenarios. For example, private blockchains can be used within an enterprise to manage internal human resources, while consortium blockchains can be used across multiple enterprises, such as banks or hospitals, allowing multiple enterprises to jointly store user data or other information, thereby enabling information sharing.

[0043] Blockchains contain vast amounts of transaction data, and in each of the three blockchain application areas mentioned above, there's a need to analyze this data. For example, when consortium blockchains are applied to banking, they can record transactions across multiple bank accounts. By analyzing this transaction data, suspicious accounts can be identified, thereby safeguarding financial security. Another example is a consortium blockchain storing transaction data for all businesses in a city to ensure transparency. To analyze the city's development, one can query the consortium blockchain for transaction data that meets certain criteria and analyze the data to determine trends, thereby gaining insights into the city's development.

[0044] Considering that blockchain transaction data is structurally similar to a graph, consisting of nodes and edges, a blockchain edge connects two nodes and represents a transaction between them. Graphs are a well-suited structure for data analysis, and their algorithms can be used for search, analysis, and other purposes. Therefore, a "blockchain + graph" approach can be used to analyze blockchain transaction data. However, the key challenge in integrating blockchain and graphs is how to combine the data analysis capabilities of graphs with blockchains to achieve blockchain transaction data analysis.

[0045] When blockchain and graphs are combined, in order to analyze transaction data, it is first necessary to filter out the transaction data that needs to be analyzed. Therefore, in the "blockchain + graph" model, the first problem that needs to be solved is how to implement transaction data query.

[0046] Querying transaction data is essential for storing it. Related technologies include three methods for storing transaction data in the "blockchain + graph" framework. These methods correspond to three methods for querying transaction data. The following sections describe these three methods and their corresponding query methods. Furthermore, for ease of understanding, it should be noted that graph storage in related technologies does not refer to storing a traditional visual image. Rather, it refers to storing the topological structure between nodes and specific edge information (such as timestamps and attributes) through a specific data storage structure.

[0047] First, transaction data is stored in an adjacency list or adjacency matrix to represent the topological relationship between nodes.

[0048] An adjacency list is a set of vertices represented by an array. It is suitable for sparse graph structures. Each row in the adjacency list records the nodes connected to the node at the beginning of the row, such as Figure 1A As shown in the figure, node A is connected to node B, node C, and node D respectively. Therefore, in the adjacency table, the first row records node A and the nodes connected to node A in order, that is, node A, node B, node C, and node D. Node B is connected to node A and node C. Correspondingly, the second row records B and the nodes connected to node B, that is, node B, node A, and node C, and so on.

[0049] The adjacency matrix is ​​a matrix that indicates whether each node is connected by an edge. When the number of nodes is N, the adjacency matrix is ​​an N*N matrix. The value of each position in the matrix can be 0 or 1. The value of the i-th row and j-th column in the adjacency matrix can be used to indicate whether there is an edge from the i-th node to the j-th node. For example, when the value is 1, it means that the corresponding edge exists, and when the value is 0, it means that the corresponding edge does not exist. In blockchain applications, this value is also used to indicate whether there is transaction data with the initiator being the i-th node and the recipient being the j-th node. Figure 1B In the adjacency matrix, the first node is node A, the second node is node B, the third node is node C, and the fourth node is node B. The value of the first row and second column represents whether there is an edge from node A to node B. Figure 1B As shown in the figure, node A and node B are connected. Correspondingly, in the adjacency matrix, the value in row 1 and column 2 is 1. The same applies to other values ​​in the adjacency matrix.

[0050] As can be seen, both adjacency matrices and adjacency lists can only indicate whether transaction data exists between multiple nodes. To store additional transaction data information, such as timestamps and attributes, additional arrays must be nested within the adjacency list or matrix to store this additional transaction data. Furthermore, due to the nature of blockchain applications, if a transaction occurs between two parties, there will typically be multiple transactions between them. This results in many parallel edges when representing the blockchain using a graph. Parallel edges are defined as multiple edges between two nodes. However, adjacency matrices and adjacency lists cannot effectively represent these parallel edges.

[0051] The aforementioned transaction data storage method has the following issues. First, it cannot effectively represent parallel edges, making it unsuitable for blockchain scenarios. Second, data storage requires a large amount of space. The adjacency matrix requires an N*N matrix to represent the topology between nodes, and additional arrays are required to store additional information about the transaction data corresponding to each edge. This consumes a significant amount of space when there are many nodes. The adjacency table has the same number of rows as the number of nodes, so additional arrays are also required to store additional information about the transaction data corresponding to each edge, which also consumes a large amount of storage space. Furthermore, a blockchain consists of multiple blocks, and generally one block corresponds to one graph, meaning that each block requires an adjacency list or matrix. Storing blockchain transaction data using this data storage structure would consume a large amount of storage space when there are many blocks.

[0052] Regarding the method for querying transaction data using the aforementioned storage method, since the arrays corresponding to transaction data's timestamps, attributes, and other information are nested within the adjacency list and adjacency matrix, querying transaction data only supports explicit structured queries, without implicit time-series and attribute-based queries. Specifically, this data structure only supports querying whether transaction data exists between two nodes, or filtering transaction data by node. However, filtering transaction data by timestamp or attribute requires accessing each nested array to perform a data query. This implicit query offers no advantage over directly querying the transaction list, and is inefficient for querying transaction data that meets specific time and / or attribute conditions.

[0053] Second, the transaction data is stored in the following way: the transaction data of the blockchain is stored through a time sequence diagram.

[0054] like Figure 2A As shown, Figure 2A A visualization diagram that can be constructed through a generalized time series diagram. The characteristic of a time series diagram is that it changes over time. For each moment, it generates a data snapshot corresponding to that moment, thereby generating corresponding time series diagrams at different moments. Multiple time series diagrams can be composed as follows: Figure 2A The visualization diagram shown. For blockchains, each graph in the time series graph corresponds to a block, and the edges in the graph represent transaction data, that is, the transaction data stored in the block represented by the graph. In other words, the edges in the graph are also transaction data that occurred at the time corresponding to the block's timestamp.

[0055] For the data storage structure of the timing diagram, Figure 2B Taking the two blocks in the example, the timing diagram actually stores the transaction data in the following Tables 1 and 2. Figure 2B The numbers on the edges represent the edge numbers, and the letters on the edges represent the attributes of the edges.

[0056] Table 1

[0057] Block number Timestamp b1 t1 b2 t2

[0058] Table 2

[0059]

[0060]

[0061] From Table 1 and Table 2, we can see that in the data storage structure of the timing diagram, Table 1 includes timestamps corresponding to multiple blocks. Table 2 includes multiple transaction data, such as the first row of Table 2 is Figure 2B The transaction data corresponding to edge 1 (edge ​​number 1) in Figure 2BAs can be seen, the timestamp of edge 1 is t1, the starting node is node 1, the ending node is node 2, and the attribute of the edge is A. The different columns in Table 2 can represent different types of transaction data. For example, in Table 2, the first column is the timestamp corresponding to the transaction data, and the second column is the starting node of the transaction data.

[0062] The time series diagram makes it easier to query transaction data that meets different conditions based on data in different columns. For example, if you want to query transaction data with a certain attribute, you can traverse the fifth column of Table 2 above to find transaction data that meets the conditions.

[0063] The above transaction data storage method has the following problems: Because each transaction data is stored as a row in the time series table, the time series graph still takes up a lot of storage space. Furthermore, the above data storage structure contains redundant information. For example, if two transactions differ only in their timestamps, they will be stored in two different rows. This is equivalent to storing the same attributes, start node, and end node twice, resulting in redundancy.

[0064] While this transaction data storage method supports searching for matching transactions based on specific time and / or attribute conditions, query efficiency remains low. This is primarily due to the redundancy in the time series graph, which results in a large number of rows to be traversed, thus reducing query efficiency.

[0065] Third, the transaction data is stored in the following way: the transaction data of the blockchain is stored through the attribute graph.

[0066] like Figure 3 As shown in the figure, the generalized attribute graph will store the attributes of nodes and edges, and will compress the edges with the same attributes. Figure 2B Taking the blockchain in as an example, the attribute graph stores the transaction data of the blockchain through Table 3.

[0067] Table 3

[0068] Starting Node property Termination Node Edge Number Block number Timestamp 1 A [2,2] [1,2] [b1,b1] [t1,t1] 1 B [2,3,2] [3,4,5] [b1,b1,b2] [t1,t1,t2] 2 C [2,2] [6,7] [b2,b2] [t2,t2]

[0069] As can be seen from Table 3, the attribute graph stores attributes explicitly and compresses all edges with the same attribute into one row. For example, Figure 2BIn the example, the edges with attribute A are edge 1 and edge 2. The starting node of edge 1 and edge 2 are both 1 and the ending node is also 2. They belong to the same block b1 and have the same timestamp of t1. The above data is stored in the first row of Table 3 in the order of edge 1 and edge 2. It should be noted that although the starting node and ending node of edge 1 and edge 2 are the same, the ending node 2 is stored twice in the first row of Table 3, while the starting node is only stored once. This is because the starting nodes of the edges in other rows of Table 3 are the same, but the ending nodes are different. Therefore, from the perspective of data storage, the ending nodes need to be stored separately, and the starting nodes can be stored together.

[0070] This storage method saves storage space. Furthermore, fewer rows need to be traversed for attribute queries. Transaction data based on specific attribute conditions can be queried using the explicit query method, resulting in highly efficient attribute queries.

[0071] However, storing blockchain data using the aforementioned data storage structure can impact queries beyond attribute conditions. Specifically, data other than attributes, such as timestamps, is stored within the attribute table as an array. Therefore, searching for such data, such as transaction data with a specific timestamp, requires accessing the data item itself, essentially searching within the array for each row. For queries involving conditions other than attributes, this data storage structure increases the processing load and reduces the efficiency of transaction data queries.

[0072] In summary, the first method uses an adjacency matrix or adjacency table to store transaction data, which, due to their characteristics, takes up a lot of storage space. The second method uses a time series graph to store transaction data in a table format. While this method can save storage space compared to the first method, the edges are not compressed, and the problem of redundant storage still exists.

[0073] Furthermore, regarding query efficiency, the first method implicitly stores all data except for the existence of connections between nodes. Therefore, if you want to filter transaction data for certain conditions, you will need to query within the data item, resulting in low query efficiency. The second method also suffers from redundant storage, requiring traversal of a large number of rows, resulting in low query efficiency. While the third method can save storage space, since all data except attributes is implicitly stored, query efficiency for data other than attributes remains low. For example, queries based on time conditions are inefficient and unsuitable for most scenarios.

[0074] To address the aforementioned issues, this application proposes a blockchain transaction data storage and query method. After acquiring blockchain transaction data, the data is stored in the form of a graph. The graph comprises an attribute table and a time series table. A row in the attribute table includes all transaction data with a specific attribute value in a block, while the time series table includes the row number of each block's transaction data in the attribute table. Based on this data storage structure, upon receiving a query condition from a user indicating the timestamp of transaction data, the method first determines the number of rows in the attribute table containing transaction data that meet the query condition based on the timestamp in the query condition. The method then determines the transaction data corresponding to the query condition from the attribute table and displays it to the user. The attribute table compresses edges with the same attribute within a block, reducing the graph's storage space. Compared to existing solutions, this method improves query efficiency by directly determining transaction data that meets the query condition from the less complex time series table, eliminating the need to traverse multiple rows or perform queries within data items.

[0075] The method of this application is aimed at the transaction data of the blockchain. Based on the time sequence of the blockchain, the attributes of the edges in some application scenarios, and the characteristics of the large number of parallel edges in the application scenarios, a data storage method suitable for the blockchain is proposed. Compared with the method of storing transaction data through adjacency lists and adjacency matrices in the related art, the method of this application explicitly stores the timestamp data, so that the transaction data of a specific timestamp can be directly searched according to the time sequence table. In addition, the edges are compressed in this application, that is, the transaction data of the same attributes of the same block are stored in a row, which saves storage space compared to the N*N size matrix in the related art. In addition, compared with the timing graph solution in the related art, multiple edges are compressed and stored in this application, which can save more space than the timing graph.

[0076] In addition, the present application also designs a more efficient transaction data query method based on this data storage method. Compared with the method of querying transaction data through adjacency lists and adjacency matrices in the related art, the method of the present application does not need to enter the data item to query, which improves the query efficiency. Compared with the query method based on the time sequence graph in the related art, the present application compresses and stores multiple edges, so when searching, fewer rows need to be traversed, which also improves the query efficiency compared to the time sequence graph. Compared with the property graph solution in the related art, although the solution of the present application cannot save storage space compared to the property graph solution, the solution of the present application greatly improves the query efficiency by compressing some edges and ensuring that the storage space is not wasted. It balances the problem of query efficiency and storage space occupancy, making the query efficiency and storage space occupancy both better. Specifically, since the timestamp data is displayed and stored in the present application, there is no need to access the inside of the data item when traversing the query, which improves the query efficiency of querying data with a specific timestamp.

[0077] The implementation of the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0078] Figure 4 What is shown is a simplified schematic diagram of a system architecture to which the embodiments of the present application can be applied. Figure 4 As shown, the system architecture may include: node 41 and node 42. Node 41 and node 42 are nodes participating in the same blockchain, and the blockchain records transaction data of the two nodes. In addition, the system architecture used in this application may include more nodes, Figure 4 For the sake of convenience, only a system consisting of two nodes is shown. In the case of more nodes, all nodes included in the system are nodes participating in the same blockchain. Figure 4 The system architecture shown in the figure does not limit the present application.

[0079] Node 41 and node 42 can be any electronic device. For example, node 41 and node 42 can be any device such as a mobile phone, a computer, a tablet computer, a server, etc.

[0080] Node 41 and node 42 are nodes in the blockchain. Correspondingly, nodes 41 and 42 both store copies of the blockchain and can store the transaction data of the blockchain in the form of a graph. The transaction data of the blockchain is stored in accordance with the data storage method shown in this application, that is, the transaction data is stored through a time series table and an attribute table. Each row in the time series table stores the location of the transaction data of a block in the attribute table. The attribute table compresses and stores edges according to timestamps and attributes, and each row stores transaction data with the same timestamp (i.e., belonging to the same block) and attributes.

[0081] Nodes 41 and 42 can also respond to user operations and query for matching transaction data based on specific query conditions, such as timestamps and attributes. When the query conditions include timestamps, they can first search the time series table to determine the location of matching transaction data in the attribute table, and then output the corresponding transaction data through the attribute table. Query methods for other query conditions are described in detail below and are not detailed here.

[0082] Figure 5 This is a structural diagram of an electronic device shown in this application. The electronic device can be node 41 or node 42. Figure 5 The structures of nodes 41 and 42 in this application are described below.

[0083] like Figure 5As shown, the electronic device at least includes a communication interface 50, a processor 51 and a storage medium 52. The communication interface 50, the processor 51 and the storage medium 52 are connected via a system bus and communicate with each other.

[0084] The communication interface 50 is used to communicate with other devices, for example, to communicate with other nodes.

[0085] The storage medium 52 can be used to store data such as files. For example, it can be used to store blockchain ledgers. It can also be used to store software programs and application modules. For example, the storage medium 52 can be used to store blockchain smart contracts.

[0086] In some embodiments, the storage medium 52 includes internal memory and external memory. The internal memory is used to temporarily store data calculated by the processor 51 and data exchanged with the external memory. The external memory is used to store data such as software programs, application modules, and blockchain ledgers.

[0087] In the embodiment of the present application, the external memory is a non-volatile memory, such as at least one disk storage device, an electrically erasable programmable read-only memory (EEPROM), or a flash memory device, such as a NOR flash memory or a NAND flash memory. The non-volatile memory stores the operating system and application programs executed by the processor 51. The processor 51 can load running programs and data from the non-volatile memory into the internal memory and store the data content in a storage device specifically used for storage.

[0088] The storage medium 52 may exist independently and be connected to the processor 51 via the system bus 54. The storage medium 52 may also be integrated with the processor 51.

[0089] The processor 51 is the control center of the electronic device. Using various interfaces and circuits, the processor 51 connects the various components of the entire electronic device. By running or executing software programs and / or application modules stored in the storage medium 52 and accessing data stored in the storage medium 52, the processor 51 performs various functions of the storage device and processes data, thereby enabling blockchain transaction data queries and storage.

[0090] The processor 51 may include only a central processing unit (CPU), or a combination of a CPU, a digital signal processor (DSP), and a control chip in a communication unit. In the embodiment of the present application, the CPU may be a single computing core or may include multiple computing cores. In a specific implementation, as an embodiment, the processor 51 may include one or more CPUs.

[0091] A system bus is a circuit that interconnects the aforementioned components and transmits communications between them. Examples of such systems include the Industry Standard Architecture (ISA) bus, the Peripheral Component Interconnect (PCI) bus, the Extended Industry Standard Architecture (EISA) bus, or the Advanced Microcontroller Bus Architecture (AMBA). These systems can be divided into an address bus, a data bus, and a control bus.

[0092] In addition, the execution subject of the method proposed in this application can be executed independently by any node in the above-mentioned system. In other words, the method can be executed by node 41 or node 42. When the method is executed by a separate node, the time sequence table and attribute table used to represent the graph can be stored independently of the blockchain. That is, the transaction data in the blockchain is still stored in the original way, and the time sequence table and attribute table are stored separately outside the copy of the blockchain. In addition, the graph of this application can also be put on the chain, that is, the graph storing the transaction data is integrated into the block for storage. In this way, if the blockchain needs to be operated, multiple nodes in the system will need to jointly execute the method of this application through a consensus mechanism to ensure the reliability of the stored data and the reliability of the query results. In addition, the blockchain ledger can be exported by an electronic device independent of the above-mentioned system, and the above-mentioned method can be executed by an electronic device independent of the above-mentioned system. This application does not limit the execution subject of this method.

[0093] Next, the transaction data storage method shown in this application will be described. Figure 6 As shown, Figure 6 This is a flowchart of a method for storing transaction data on a blockchain proposed in this application according to an exemplary embodiment, comprising the following steps:

[0094] Step 601: Obtain transaction data from the blockchain.

[0095] In order to store the blockchain in the form of a graph, it is first necessary to obtain the transaction data of the blockchain.

[0096] Regarding the specific implementation of step 601, all transaction data on the blockchain can be obtained from the transaction list stored in the blockchain, and all transaction data can be stored in the form of a graph in step 602. Alternatively, when a new block is added to the blockchain, the transaction data corresponding to the new block can be obtained through a smart contract and added to the graph in real time. Specifically, several rows are added to the time series table and attribute table corresponding to the graph to store the transaction data corresponding to the new block, thereby achieving real-time query performance. This application does not limit the execution timing of step 601.

[0097] Step 602: Store the transaction data of the blockchain in the form of a graph.

[0098] The nodes of the graph correspond one-to-one to the nodes of the blockchain, and the edges of the graph correspond one-to-one to the transaction data of the blockchain. The graph includes an attribute table and a time series table. Each row in the attribute table includes all transaction data with the same attribute value belonging to the same block in the blockchain. The time series table includes the number of rows corresponding to the transaction data of each block in the attribute table.

[0099] First, let's explain the blockchain involved in this application. It should be noted that although this application mentions a time sequence table and an attribute table, the specific data storage structure of the time sequence table and attribute table in this application is different from the time sequence diagram and attribute diagram introduced in the related art.

[0100] The meaning of blockchain and blockchain nodes can be found in the previous text and in the prior art, and will not be repeated here. A graph is a structure composed of nodes and edges. In the graph used to store blockchain transaction data in this application, the nodes of the graph can correspond one-to-one with the nodes of the blockchain. The edges of the graph are used to represent a transaction between two nodes, and the edges store the transaction data corresponding to the transaction. If there are multiple transactions between two nodes, there will be multiple edges between the two nodes.

[0101] Transaction data, or the specific transaction information stored in each blockchain block, corresponds to transactions between blockchain nodes and describes basic transaction information, such as the transaction's starting and ending nodes and attributes. Using decentralized blockchain technology to record transactions between nodes ensures the security of transaction data. A transaction refers to the exchange of resources between two nodes, and its meaning varies across different blockchain application areas. For example, in finance, a blockchain can record monetary transactions between multiple nodes. In the supply chain, transactions can represent commodity transactions, logistics transactions, and traceability information, among other things. This application does not limit the specific transactions corresponding to transaction data.

[0102] The starting node of transaction data is the initiator of the transaction data, and the ending node is the recipient of the transaction data. Attributes can be used to indicate the type of transaction data. For example, in a consortium blockchain, a consortium chain stores transaction data for all businesses in a city. The attributes of the transaction data in the consortium chain can be used to indicate the type of transaction. For example, transaction data attributes can include: restaurant transactions, financial transactions, transportation transactions, etc.

[0103] After explaining the blockchain, the graph structure of this application will be explained.

[0104] First of all, it should be noted that the graph includes an attribute table and a time series table. That is, the graph is actually stored in the form of an attribute table and a time series table. When the graph is actually stored, an image is not stored. Instead, the edges between the nodes of the graph are represented by the time series table and the attribute table.

[0105] In the method of the present application, a data storage structure that balances the size of storage space and query efficiency is used in response to the characteristics of blockchain applications and query requirements. Specifically, blockchains generally have the characteristics of time sequence, a large number of parallel edges, and transaction data with attributes in some application scenarios. Correspondingly, for the query requirements of blockchain application scenarios, it is generally necessary to query the required transaction data based on attributes and timestamps. In some cases, transaction data is also queried based on the starting node and ending node of the transaction data. The starting node of the transaction data is also the initiator of the transaction, and the ending node of the transaction data is also the recipient of the transaction data. Therefore, the data storage structure used needs to focus on how to store timestamp attributes and parallel edges, and then based on this storage structure, the query efficiency of querying transaction data based on timestamps, attributes, starting nodes or ending nodes can be guaranteed.

[0106] In blockchain applications, there are typically many parallel edges, meaning multiple pieces of transaction data between two nodes. Furthermore, in certain blockchain applications, transactions often have attributes, though the number of attributes is typically limited. Therefore, to ensure high query efficiency and minimize graph storage space, edges with the same attribute within the same block can be compressed. This means storing all transactions with the same attribute within the same block in a single row within the attribute table. Transactions within the same block also have the same timestamp.

[0107] Regarding the method of storing attribute data and other data in an attribute table, a row in the attribute table represents transaction data with the same attribute for the same block. To reduce the storage space occupied by the attribute table, since transaction data in the same row have the same attributes, the attributes of the transaction data in each row can be stored once, and the remaining information of the transaction data in the row can be stored in the row. For example, if there are two transaction data pieces with a certain attribute in a block, the content of the two transaction data pieces, except for the attributes, can be stored in a column of a row in the attribute table, and the attributes corresponding to the row data can be stored in the other columns of the row, achieving compressed storage.

[0108] For timestamps, a time series table can be stored. Each row in the time series table records the number of rows stored in the attribute table for a block's transaction data. This avoids the problem of storing timestamp data in the attribute table. Due to the large number of attribute types, a block's transaction data would occupy many rows in the attribute table, resulting in redundant timestamp storage and consuming more storage space. Furthermore, this ensures that query efficiency is not significantly affected.

[0109] As for the specific storage method of the time series table, one block corresponds to one timestamp. Correspondingly, the time series table can store the correspondence between the timestamp and the location where the transaction data is stored in the attribute table. The time series table can also store the correspondence between the block number, timestamp and the location where the transaction data is stored in the attribute table. The time series table can also store the correspondence between the block number and the location where the transaction data is stored in the attribute table.

[0110] In an optional embodiment, the transaction data in the attribute table may not include the timestamp of the transaction data. Since the timestamp data has been stored in the time series table, this can further save storage space.

[0111] In this application, a time series table is used to store the location of each block's transaction data in the attribute table, and the attribute table is used to compress and store the transaction data. This can save storage space. For example, compared to the adjacency table and adjacency matrix solutions in the related art, the storage method of this application does not require separate storage for each block, saving storage space. For another example, compared to the time series graph method in the related art, this application performs compression, storing transaction data with the same attributes and the same timestamp in one row, saving storage space. Compared to the attribute graph in the related art, this application ensures a balance between query efficiency and storage space.

[0112] As for the specific storage location of the above-mentioned graph, the above-mentioned graph can be stored on-chain, that is, stored in a copy of the blockchain. When the graph is stored on-chain, since the graph is not stored according to blocks, in order to facilitate the implementation of the method of the present application, the graph in the present application can be stored together with the transaction list originally stored in the blockchain. That is, the method of the present application can store the graph on-chain on the basis of storing the transaction list. In addition, the graph can also be stored off-chain, so that when querying, there is no need to go through the consensus mechanism, that is, the query can be performed without the participation of multiple nodes, which reduces the amount of calculation.

[0113] In an alternative embodiment, multiple rows of transaction data for the same block can be stored in multiple contiguous rows in the attribute table. This allows the time series table to store only the start and end rows of each block's transaction data as stored in the attribute table, eliminating the need to record every row of transaction data stored in the attribute table. This can further save storage space.

[0114] Each row in the attribute table can directly list and store transaction data, for example, storing the information of transaction data 1 first, and then storing the information of transaction data 2.

[0115] In addition, in some cases, the query conditions for transaction data may include a starting node, an ending node, and / or attributes. In order to improve the query efficiency of transaction data in the attribute table, the data storage structure of the transaction data in the attribute table can be improved according to the query requirements. The transaction data can be integrated and the same type of data can be stored in a column or a fixed position in the row. For example, if the user's query requirements are related to the attributes, the starting node, and the ending node, two columns of data can be stored in the row. The first column stores the attributes of all transaction data in the row, and the second row stores the starting node and ending node corresponding to all data in the row. When there are multiple starting nodes or ending nodes for transaction data corresponding to a row, the multiple starting nodes can be listed in sequence according to the order in which other content of the transaction data is stored. For another example, if the user's query requirements are related to the attributes and the starting node, the attributes can be stored first in a row, and then the starting node, and the attributes and the starting node can be separated by a delimiter.

[0116] In other words, the data storage structure of the attribute table can be: each row of the attribute table includes first, second, and third types of data. The first type of data includes the attributes corresponding to the transaction data, the second type of data includes the start and end nodes corresponding to the transaction data stored in each row, and the third type of data includes the serial number corresponding to the transaction data stored in each row. Blockchain transaction data is also stored in the form of a transaction list, where each row in the transaction list indicates the specific information of a blockchain transaction data, including at least data not included in the attribute table and time series table. In some embodiments, the transaction list can also store all transaction data information. Storing this information in a graph facilitates querying transaction data that meets specific conditions.

[0117] Furthermore, the need to store transaction data serial numbers arises because, in some cases, some content in the transaction data is irrelevant to the query and therefore not part of the query criteria. For example, the transaction data may include the transaction amount, but the user doesn't need to use the transaction amount as a query criterion. In this case, only the relevant content for the query, such as the attributes, start and end nodes, can be stored in the attribute table. The serial number corresponding to each transaction data row can also be stored in each row.

[0118] In addition, a specific way of storing the three types of data may be to store the three types of data in different columns, or to store them in a fixed position in a row, with the different types of data separated by a separator. Of course, the above two examples do not limit the present application.

[0119] In an optional embodiment, in some cases, the query conditions required by the user may include multiple attributes. In this case, in order to improve the query efficiency, multiple attribute tables can be stored, and the attribute tables and attribute types correspond one to one. For example, the user may query based on two attributes of transaction data, namely the transaction type and the transaction amount. Then the two attributes correspond to one attribute table respectively.

[0120] The compression logic for transaction data stored in different attribute tables varies. Each attribute table compresses and stores data based on the attributes corresponding to that attribute table. Continuing with the example of transaction type and transaction amount, a row in the attribute table corresponding to the transaction type represents transaction data for the same block and of the same type. A row in the attribute table corresponding to the transaction amount represents transaction data for the same block and within the same amount range. The time series table stores the number of rows of transaction data for each block stored in the two attribute tables.

[0121] This can improve the efficiency of multiple attribute queries when performing queries later.

[0122] As mentioned above, the transaction list is part of the data originally stored in the blockchain. Through the above method, this application can add a graph structure that facilitates data query without changing the basic storage structure and storage method of the blockchain. Moreover, through the above storage method and query method, content that is irrelevant to the query conditions is not stored in the attribute table. In this way, the storage space occupied by the attribute table is saved without affecting the query efficiency.

[0123] The data storage method shown in this application will be described below through a specific embodiment. The transaction data stored in the blockchain in this specific embodiment is shown in Table 4 below.

[0124] Table 4

[0125] node Transaction data B-A "Number":"1","Attribute":"B","Block Number":"b1","Timestamp":"t1","Amount":"500","Weight":"0.75" C-A "Number":"2","Attribute":"C","Block Number":"b3","Timestamp":"t3","Amount":"375","Weight":"1.03" A-B "Number":"3","Attribute":"A","Block Number":"b1","Timestamp":"t1","Amount":"100","Weight":"0.15" A-B "Number":"4","Attribute":"A","Block Number":"b1","Timestamp":"t1","Amount":"200","Weight":"0.65" C-F "Number":"5","Attribute":"B","Block Number":"b2","Timestamp":"t2","Amount":"315","Weight":"0.63" A-C "Number":"6","Attribute":"A","Block Number":"b1","Timestamp":"t1","Amount":"170","Weight":"0.95" B-C "Number":"7","Attribute":"B","Block Number":"b1","Timestamp":"t1","Amount":"180","Weight":"0.83"

[0126] The blockchain transaction graph can be defined by the transaction data shown in Table 4. Blockchain transaction graph G = <V,E TP > is a directed multigraph. The direction in the graph represents the direction of the transaction, and multiply means that there are parallel edges in the graph. The blockchain transaction graph consists of edges and nodes. The node set V = {v1, v2, ..., v i Each node v in i It is a node of the blockchain and a participant of the blockchain transaction, such as the initiator or receiver of the transaction. TP ={<(v i ,v j ),T i ,T p ,A s >|v i ,v j ∈V} is used to represent a transaction. Each edge corresponds to three types of data: timestamp T i , transaction type attribute T p The nodes corresponding to the transaction data include the start node and the end node.

[0127] Correspondingly, the transaction data corresponding to Table 4 is shown in Figure 4. Figure 7 It should be noted that Figure 7 This is just a visual graph structure for easy understanding. It may not be stored in actual storage. Figure 7 The transaction data may not be stored in the form of Table 4 when actually stored. Table 4 is only an example shown for the convenience of illustrating the embodiment of the present application. Figure 7 The t1 on the edge represents the timestamp of the edge, the letters on the edge represent the attributes of the edge, and the numbers on the edge represent the edge number.

[0128] In addition, in the data storage structure of the graph used in this application based on query requirements, only the topology of the graph can be stored, without storing node information. Node information is generally not used as a query condition, and not storing node information can save storage space. As mentioned above, a graph can include an attribute table and a time series table. Figure 7 The attribute table corresponding to the diagram shown can be shown in Table 5, and the time series table can be shown in Table 6. The attribute table and time series table can be stored in a database. In this embodiment, the meanings of the time series table and attribute table are the same as above, that is, the time series table stores the number of rows stored in the attribute table for each block's transaction data, and a row in the attribute table stores transaction data with the same attribute for the same block.

[0129] Table 5

[0130] key Property Start_node Terminate_node Edge_id 1 A [First] [B,C] [3_4,6] 2 B [Second] [A, C] [1,7] 3 B [C] [Second] [5] 4 C [C] [First] [2]

[0131] Table 6

[0132] block_id timestamp Start_key Terminate_key 1 T1 1 2 2 T2 3 3 3 T3 4 4

[0133] The definitions of the column headers in the attribute table and timing table can be found in Table 7 and Table 8.

[0134] Table 7

[0135] Header Data Type Property Description Key int The id of each row in the attribute table Property String Property Value Start_node String[] The starting node set of transaction data Terminate_node String[] The terminal node set of transaction data Edge_id String[] Edge id set

[0136] Table 8

[0137] Attribute id Data Type Property Description block_id String Block id timestamp timestamp Block timestamp Start_key String The starting row ID of the block in the attribute table Terminate_key String The ending row ID of the block in the attribute table

[0138] The above data types are only used as examples and do not limit the present application. In some embodiments, the block_id may not be stored in the sequence table.

[0139] It's also important to note that edge IDs contain separators. These separators are used to separate two edges with the same start and end nodes, effectively separating the numbers of two parallel edges. For example, in Table 6, the separator is an underscore. In this case, the two edges separated by an underscore have the same start and end nodes. This storage method can further conserve storage space for the start and end nodes.

[0140] Based on the definitions in Tables 7 and 8, we can determine that the data stored in the first row of the time series table refers to the block with block number (ID) 1 and timestamp T1, which is stored in rows with IDs 1-2 in the attribute table. The meaning of the data stored in the other rows of the time series table is similar and will not be repeated here. The meaning of the tax bureau stored in the first row of the attribute table is that the ID of this row is 1, and the attribute value of all transaction data compressed and stored in this row is A. This row stores three transaction data, and the IDs of these three transaction data (edges) are 3, 4, and 6, respectively. The starting node of all three edges is A, and the corresponding ending node for transaction data numbers 3 and 4 is B, while the corresponding ending node for transaction data number 6 is C.

[0141] The above data storage structure can be generated by a smart contract. The smart contract can store the transaction data of newly generated blocks in the time series table and attribute table in real time. In addition, if the blockchain ledger contains historical transaction data, the smart contract can also read the blockchain ledger, read the metadata, transaction list, and header data of each block, and convert only the transaction list data into the attribute table and time series table.

[0142] A data writing interface can also be added to the smart contract. By calling the data writing interface, the data in the transaction list can be converted into the graph structure corresponding to Table 5 and Table 6 for storage.

[0143] In addition, in some cases, other information about the transaction data is required when displaying and analyzing the queried transaction data. Therefore, both the graph in this application and the original transaction list can be stored. The graph in this application is used to query the transaction data number. After obtaining the transaction data number, the transaction data with the corresponding number can be obtained from the transaction list for display and analysis.

[0144] In addition, the graph may also be stored using the storage structure of the following specific embodiment.

[0145] In some cases, the blockchain's storage method may not support the aforementioned storage of time series and attribute tables. For example, in the open-source consortium blockchain platform Hyperledger Fabric, the world state uses a key-value database called LevelDB. The following describes a method for storing attribute and time series tables using a key-value database.

[0146] In this embodiment, the members of the alliance chain are companies owned by a city, and the ledger of the alliance chain is used to record transactions between companies in the city. The ledger storage structure of the alliance chain 1 is as follows: Figure 8 As shown in the figure, the ledger consists of header data, transaction data and metadata. Transaction data is the main body of the ledger. Transaction data stores a lot of content. Figure 8 This is just for example and does not represent all the contents that will be stored in the actual transaction data storage. The actual transaction data may store more categories than Figure 8 Show more, and possibly more than Figure 8 The transaction data stored in alliance chain 1 is shown in Tables 9 and 10 below.

[0147] Table 9

[0148]

[0149] Table 10

[0150] Node Name Node number Company A First Company B Second Company B C

[0151] Transaction information is stored in the form of Table 9, and storage node information is stored in the form of Table 10. Transaction type is also the attribute of transaction data. As can be seen from the above table, transaction data includes transaction information and node information. Transaction information includes the starting node, ending node, transaction type, block ID, timestamp, and other transaction attributes of the transaction data. Node information mainly includes node name and node attributes.

[0152] Through the transaction data shown in Table 9 and Table 10, we can construct Figure 7 The transaction graph shown in the figure represents nodes of the blockchain, in other words, participants of blockchain transaction data, and an edge of the transaction graph indicates a piece of transaction data. Figure 7 Type A represents the catering type in this embodiment, type B represents the financial type in this embodiment, and type C represents the transportation type in this embodiment. Figure 7 The transaction graph extracts the timestamp, attributes, start node and end node of the transaction information in Table 9 and the id information of the transaction data.

[0153] The timing table and attribute table corresponding to the transaction graph can be shown in Table 11 and Table 12 respectively.

[0154] Table 11

[0155]

[0156]

[0157] Table 12

[0158] key Property Start_node Terminate_node Edge_id 1 "FOOD" [First] [B,C] [3_4,6] 2 "finance" [Second] [A, C] [1,7] 3 "finance" [C] [Second] [5] 4 "transportation" [C] [First] [2]

[0159] The meanings represented in Tables 11 and 12 can be found in the descriptions of Tables 5 and 6 above and will not be repeated here. The data storage structure shown in Tables 11 and 12 facilitates querying. The timing diagram in Table 11 is used to store the time attributes of transaction data, and the timing table facilitates querying based on time-related query conditions. The attribute table is used to store the main information of transaction data, such as the transaction data ID (also the edge ID), attributes, starting node, end node, and other information. Transaction data with the same attributes in a block are stored in the same row of the attribute table.

[0160] In addition, in the embodiment shown in this application, data is stored in a key-value storage format. The timing diagram and attribute diagram shown in Table 11 and Table 12 are only examples for easy understanding and are not actual storage formats.

[0161] Regarding the specific data storage format, in a key-value database, for a time series table, the block ID and timestamp can be combined as the key, and the block's starting row ID and ending row ID in the attribute table can be combined as the value. The block ID and timestamp are separated by an underscore "_", and the starting row ID and ending row ID are separated by a comma ",". When querying, keys can be traversed based on the timestamp condition, and the value is the query result.

[0162] In addition, in some embodiments, the block ID may not be stored. In other words, the time series table is stored in the form of a key-value database. The time series table includes multiple key-value pairs, the key in the key-value pair includes the timestamp of the block, and the value in the key-value pair includes the number of rows corresponding to the block in the attribute table.

[0163] For the attribute table, you can combine all values ​​except the edge ID as the key, and use the edge ID array as the value. You can use delimiters in the key, such as "_", to distinguish different types of data.

[0164] In other words, the attribute table is stored as a key-value database. That is, the attribute table includes multiple key-value pairs. The key in the key-value pair includes a first type of data and a second type of data, and the value in the key-value pair includes a third type of data. The first type of data and the second type of data are separated by a delimiter. The first type of data and the second type of data have the same meaning as above. The first type of data is the attribute, and the second type of data is the start node and the end node.

[0165] In addition, since the formats of the start node and the end node are similar, it is not convenient to determine the positions of the start node and the end node of each row by filtering data in a specific format. In order to facilitate the query and improve the query speed, different types of data can be separated by different separators.

[0166] In other words, the second type of data includes first subtype data and second subtype data, the first subtype data includes the starting node corresponding to the transaction data, and the second subtype data includes the ending node corresponding to the transaction data; the first type of data and the second type of data are distinguished by a first separator, and the first subtype data and the second subtype data are distinguished by a second separator, and the first separator and the second separator are different.

[0167] For example, you can use "*" to separate the start node from the previous data, and use "%" to separate the end node from the previous data. For another example, you can use different symbols to distinguish the start node. You can add single quotes outside the start node and curly braces outside the end node. In this way, the separator before the start node is "_'", and the separator before the end node is "'_{".

[0168] In this way, when performing a query, you can quickly search based on different delimiters. For example, in the above example, you can use a prefix query with single quotes or curly brackets to search for the start node or end node, which improves the query speed.

[0169] The timing diagram and attribute diagram of the data storage structure described above can be shown in Table 13 and Table 14 respectively. Figure 7 Similar, no further description is given here.

[0170] Table 13

[0171] key value 1_t3 1,2 2_t2 3,3 3_t3 4,4

[0172] Table 14

[0173] key value 1_”catering”_'”A”'_{"B”,”C”} ["3_4”,”6”] 2_”Finance”_'”B”'_{"A”,”C”} ["1”,”7”] 3_"Finance"_'"C"'_{"B"} ["5”] 4_”Transportation”_'”C”'_{"A"} ["2”]

[0174] After explaining the method for storing transaction data, the following two will describe a method for querying transaction data of a blockchain shown in this application in combination with a specific embodiment. Figure 9 As shown, Figure 9 This is a flowchart of a blockchain transaction data query method proposed in this application according to an exemplary embodiment, comprising the following steps:

[0175] Step 901: Obtain the query conditions input by the user.

[0176] The query condition indicates the timestamp of the transaction data to be queried. The graph's nodes correspond one-to-one to the nodes of the blockchain, and the graph's edges correspond one-to-one to the transaction data on the blockchain. The graph includes an attribute table and a time series table. Each row in the attribute table includes all transaction data with the same attribute value belonging to the same block in the blockchain. The time series table includes the number of rows in the attribute table corresponding to each block's transaction data.

[0177] The transaction data of the blockchain in this application can be Figure 6 The method of the embodiment shown is used for storage. For the detailed description of the figure, please refer to the above and will not be repeated here.

[0178] Regarding the specific implementation of step 901, a user can enter a query condition through the node's visual interface or select a query condition from a number of existing conditions, so that the node can obtain the query condition entered by the user. The user can be a user using a node device in the blockchain, and the node is a node in the blockchain. The user can enter the query condition through the node in the blockchain and obtain transaction data that meets the query condition.

[0179] The query condition is at least used to indicate the timestamp of the transaction data to be queried. In other words, the query condition is at least related to the timestamp. Specifically, the query condition may include the timestamp corresponding to the transaction data to be queried and / or the range of timestamps corresponding to the transaction data to be queried. For example, the query condition input by the user may be a specific time point. Then, the method of the present application needs to query the transaction data that occurred at the timestamp corresponding to the specific time point. For another example, the query condition input may also be a specific time period. Correspondingly, the method of the present application needs to query the transaction data that occurred within the specific time period. For another example, if the user inputs a specific time point and a specific time period, then the method of the present application needs to query the transaction data that occurred at the specific time point and the specific time period respectively.

[0180] Furthermore, in blockchain applications, users often enter multiple query conditions when performing queries. Accordingly, the query conditions in step 901 can be related not only to timestamps but also to other data. For example, the query conditions can include one or more of a specific attribute, a specific starting node, and a specific ending node. In other words, the query conditions can also be used to indicate one or more of the attributes, starting node, and ending node of the transaction data to be queried.

[0181] For example, the query conditions entered by the user may include: time period A, attribute B, and starting node C. Accordingly, this query condition is used to query transaction data whose timestamp is within time period A, whose attribute is B, and whose starting node is C. For another example, the query conditions entered by the user may include: time period A, attribute B, and non-starting node C. This query condition is used to query transaction data whose timestamp is within time period A, whose attribute is B, and whose starting node is not C. The above two examples do not limit the query conditions in this application. It is understood that query conditions can take various forms.

[0182] Step 902: Based on the query condition, determine the number of rows of transaction data in the attribute table that meet the query condition from the time series table.

[0183] The time series table stores the location of each block's transaction data in the attribute table. The specific storage method can be found in Figure 6 In the description of [ ]. If the time series table stores the correspondence between block numbers and transaction data locations in the attribute table, after obtaining the query conditions, the timestamp-related conditions in the query conditions can be converted into block numbers in advance using blockchain information. By searching the time series table, the transaction data to be queried can be determined based on the timestamp-related conditions included in the query conditions, that is, the number of transaction data rows in the attribute table that meet the query conditions.

[0184] The position of the transaction data to be queried in the attribute table can be quickly determined through the index of the time series table, so that the transaction data to be queried can be determined from the corresponding row of the attribute table, that is, the following step 903 is executed.

[0185] Step 903: Based on the determined number of rows, the transaction data corresponding to the query condition is determined from the attribute table, and the transaction data corresponding to the query condition is displayed to the user.

[0186] Regarding the specific implementation of step 903, if the query condition only indicates the timestamp of the transaction data to be queried, the transaction data in the corresponding row of the attribute table can be directly used as the transaction data to be queried, that is, the transaction data corresponding to the query condition. In this case, the attribute table can store only partial or complete transaction data information.

[0187] In addition, when the query condition is only used to indicate the timestamp of the transaction data to be queried, and the attribute table does not store all the transaction data information, in order to obtain all the transaction data information, the transaction data number stored in the attribute table can also be used to output the transaction data corresponding to the query condition from the transaction list.

[0188] Specifically, as mentioned above, in order to improve query efficiency and save storage space, the attribute table can be: each row of the attribute table includes first type data, second type data and third type data, the first type data includes the attributes of the transaction data, the second type data includes the starting node and the ending node of the transaction data, and the third type data includes the number of the transaction data; the transaction data of the blockchain is also stored in the form of a transaction list, which includes the information of the transaction data of the blockchain and the number of the transaction data.

[0189] Under the above storage structure, in step 903, the transaction data number corresponding to the query condition can be determined by searching, and the specific information of the transaction data corresponding to the query condition can be obtained from the transaction list. This specific information includes both information stored in the graph and information not stored in the time series table and attribute table, such as the transaction amount, transaction weight, etc. After obtaining this information, it can be displayed to the user.

[0190] In other words, when the attribute table includes the number of transaction data, step 903 may include: determining the number of transaction data corresponding to the query condition from the attribute table based on the determined number of rows; obtaining the transaction data corresponding to the query condition from the transaction list according to the determined number of transaction data; and displaying the transaction data corresponding to the query condition to the user.

[0191] It can be seen that the method of the present application can improve query efficiency. For example, when the query condition is at least related to the timestamp, compared to the adjacency list and adjacency matrix in the related art, the present application provides a means of querying based on the query condition of the timestamp. Compared with the timing graph solution of the related art, the present application reduces the number of rows traversed and improves the query efficiency. Compared with the attribute graph solution in the related art, the present application displays and stores the timestamp, which improves the efficiency of the query.

[0192] In the case where the query condition is also related to one or more of the attributes, starting nodes or ending nodes, etc., in step 903, further queries can be performed in the rows determined in the attribute table based on one or more conditions such as attributes, starting nodes or ending nodes to determine the transaction data that needs to be queried.

[0193] In an optional embodiment, when each row of the attribute table includes at least three types of data, if the query condition is related to any one of the attribute, the start node, and the end node, a query based on the aforementioned condition can be performed directly from the corresponding column or position of the determined row. For example, if the user's query condition is related to the attribute, and the attribute is stored in the first column, then the transaction data corresponding to the query condition can be determined in the first column of the determined row. If the query condition is related to at least two of the attribute, the start node, and the end node, a filter can be performed based on one query condition first, and then a query based on the other query condition can be performed from the filtered rows. The query method is similar to that described above and will not be repeated here.

[0194] If the query condition is related to the attribute, and is also related to any one or both of the starting node and the ending node, when making a specific query, you can first query in a certain row according to the attribute, and then further query based on other conditions in the row queried based on the attribute. Since the attributes of the transaction data stored in a row in the attribute table are the same, it can be determined that the attribute is displayed and stored in the attribute table, and other data may not be displayed and stored. The first step of screening by displaying the stored attributes can improve the efficiency of the query. Of course, you can also query based on the starting node or the ending node first, and then query based on the attribute. This application does not limit the specific query method.

[0195] After the query is completed, if the attribute table stores other data unrelated to the query conditions, the transaction data can be directly obtained from the attribute table and displayed to the user.

[0196] When the transaction data serial numbers are stored in the attribute table, if the query condition also indicates the corresponding starting and / or ending nodes of the transaction data to be queried, the process for determining the transaction data serial numbers can be as follows: from the number of rows determined in the attribute table, the serial numbers of the transaction data that meets the query condition can be determined based on the second-type data and the third-type data. In other words, the starting and ending nodes corresponding to the transaction data in that row of the second-type data can be stored in sequence, and the serial numbers of the transaction data in the third-type data can be stored in the same order as the serial numbers of the transaction data in the second-type data. The location of the transaction data that meets the query condition can be first searched in the second-type data, and the serial number of the transaction data that meets the query condition can be determined from the corresponding location in the third-type data. For example, if the transaction data that meets the query condition is determined to be the third and fourth in the first row and the first in the second row, then the serial numbers of the third and fourth transaction data in the first row of the third-type data can be determined as the serial numbers of the transaction data that meets the query condition. Furthermore, the serial number of the first transaction data in the second row of the third-type data can also be determined as the serial number of the transaction data that meets the query condition.

[0197] When the transaction data serial number is stored in the attribute table, if the query condition also indicates the attribute value of the transaction data to be queried, the process for determining the transaction data serial number may be as follows: from the number of rows determined in the attribute table, the serial number of the transaction data meeting the query condition is determined based on the first type of data and the third type of data. In other words, the row containing the transaction data meeting the query condition is first searched for in the first type of data, and the serial number of the transaction data meeting the query condition is then determined from the third type of data stored in that row.

[0198] Through the above query method, the efficiency of transaction data query can be improved.

[0199] After obtaining the transaction data corresponding to the query conditions, the transaction data can be directly displayed to the user in the form of a list, and the transaction data can also be analyzed and displayed to the user in the form of analysis results.

[0200] In addition, if Figure 6 In the illustrated embodiment, a user's query conditions may relate to multiple attributes, and multiple attribute tables may be stored. In other words, the attributes of the transaction data include a first attribute and a second attribute; the attribute table includes a first attribute table and a second attribute table, each row in the first attribute table includes all transaction data with the same first attribute value belonging to the same block in the blockchain, and each row in the second attribute table includes all transaction data with the same second attribute value belonging to the same block in the blockchain; the time series table includes the number of rows corresponding to each block's transaction data in the first attribute table and the second attribute table; the determined number of rows includes the determined number of rows in the first attribute table and / or the determined number of rows in the second attribute table.

[0201] In this case, if the query condition is related to any attribute, the rows in the attribute table corresponding to the attribute that matches the query condition can be determined based on the time series table, and the transaction data to be queried can be retrieved from the determined number of rows in the attribute table corresponding to the attribute. For example, if there are two attributes, namely the transaction type and the transaction amount, and the user's query condition is used to indicate that the transaction type is a catering transaction, then the transaction data that matches the query condition can be first determined based on the time-related conditions in the query condition. The corresponding row number in the attribute table corresponding to the transaction type can then be searched for within the determined number of rows in the attribute table.

[0202] In the above case, if the query conditions are related to at least two attributes, there can be multiple query methods. For example, if an attribute table stores the attribute values ​​of two attributes, you can search for the row storing the transaction data that meets the conditions of one attribute in the attribute table corresponding to the attribute, and then query the transaction data that meets the query conditions corresponding to the other attribute in the found row.

[0203] Alternatively, one attribute table may store only one attribute value, and transaction data meeting the query conditions may be searched in two attribute tables respectively, and the intersection of the transaction data corresponding to the two attribute tables may be used as the final query result.

[0204] In other words, when the attribute table stores the serial number of transaction data, the above query method is: when the query condition is used to indicate the attribute value of the first attribute of the transaction data to be queried, the serial number of the transaction data that meets the query condition is determined from the number of rows determined in the first attribute table based on the first type data and the third type data; when the query condition is used to indicate the attribute value of the second attribute of the transaction data to be queried, the serial number of the transaction data that meets the query condition is determined from the number of rows determined in the second attribute table based on the first type data and the third type data; when the query condition is used to indicate the attribute value of the first attribute and the attribute value of the second attribute of the transaction data to be queried, the serial number of the first transaction data corresponding to the attribute value of the first attribute indicated by the query condition is determined from the number of rows determined in the first attribute table based on the first type data and the second type data, and the serial number of the second transaction data corresponding to the attribute value of the second attribute indicated by the query condition is determined from the number of rows determined in the user's second attribute table based on the first type data and the second type data, and the intersection of the serial number of the first transaction data and the serial number of the second transaction data is used as the serial number of the transaction data that meets the query condition.

[0205] In this way, only one attribute value needs to be stored in each attribute table, which can save storage space. In addition, attribute data in both attribute tables are explicitly stored, which can ensure the query efficiency of attribute-related query conditions.

[0206] Furthermore, the execution entity of the method can be any node in the blockchain, requiring only one node to participate, reducing the amount of computation. Furthermore, graphs can be put on-chain, similar to blockchain accounting, allowing multiple nodes to collaborate through a consensus mechanism to query transaction data, improving the reliability of query results and the security of transaction data.

[0207] As for the implementation of the method of the present application, query logic can be added to the smart contract of the blockchain to complete automatic query through the smart contract.

[0208] As can be seen, compared to the time-series graph approach in the related art, this method for querying transaction data based on attributes requires fewer rows to be traversed, resulting in higher query efficiency, similar to the timestamp-based query conditions. Regarding the method for querying transaction data based on start and end nodes, compared to the time-series graph approach, although the compressed storage of transaction data requires access to the data item for querying, the storage space is significantly reduced, and the number of rows traversed is reduced. In the case of a large amount of transaction data, query efficiency may be improved due to the reduction in the number of rows traversed.

[0209] The method in this application ensures that storage space is not excessively occupied, and that querying transaction data based on various query conditions can achieve high query efficiency. Compared to the attribute graph solution in the related art, this application is a more balanced solution, ensuring that the efficiency of transaction data queries based on conditions such as attributes is not significantly reduced, while significantly improving the efficiency of transaction data queries based on time conditions (such as the timestamp mentioned above).

[0210] Furthermore, in an optional embodiment, the blockchain in this application may be a consortium blockchain. Compared to other types of blockchains, transaction data in consortium blockchain applications generally has attributes. The application of this application's method to consortium blockchains can significantly improve query efficiency.

[0211] The method of this application does not change the original architecture of the blockchain, such as Figure 10 As shown, only the graph used to store transaction data is stored in the storage layer of the blockchain, and a query interface is added to the smart contract layer. This application can support Figure 10 The smart contract layer allows for interface definition and implementation, and also allows for the expansion of graph topology on disk.

[0212] In summary, the method in this application proposes a data storage structure suitable for blockchain transaction data based on the sequential nature of blockchains, the attributes of edges in some application scenarios, and the high number of parallel edges in these application scenarios. Based on this data storage structure, a more efficient transaction data query method is designed, which also saves more storage space. Furthermore, as can be seen from the above analysis, the solution in this application can save storage space and improve query efficiency compared to adjacency lists, adjacency matrices, and time-series graphs.

[0213] It should be noted that compared to the attribute graph solutions in related technologies, the solution of this application significantly improves query efficiency by compressing some edges to ensure that storage space is not wasted. In this application, because timestamp data is displayed and stored, there is no need to access the internal data items when traversing queries, which improves the query efficiency of data with specific timestamps. On the basis of ensuring that the query efficiency of query conditions related to attributes is not excessively reduced, the efficiency of queries related to time is guaranteed, thus achieving a balance between query efficiency and storage space.

[0214] Next, the transaction data query method of the blockchain shown in this application will be described by still taking the two specific embodiments above as examples.

[0215] First, when the graph is stored in the form of Table 11 and Table 12 above, the following five query methods can be performed.

[0216] In this application, five query interfaces can be defined in the smart contract, namely, time point query interface, time period query interface, attribute query interface, start node query interface and end node query interface. The following will explain the five query interfaces respectively.

[0217] First, the time point query interface.

[0218] The input parameter of the time point query interface can include a time point, which can be a timestamp type of data. The input parameter is also the query condition entered by the user. Using this input parameter, you can query transaction data including the input time point.

[0219] The query process based on the time point query interface may include:

[0220] 1. Get the parameters input by the user. This step also corresponds to Figure 9 Step 901 in .

[0221] 2. Traverse the timestamp column of the block in the time series table and return the start row id (start_key) and end row id (terminate_key) of the block corresponding to the time point in the attribute table. This step also corresponds to Figure 9 Step 902 in .

[0222] 3. Convert the start row id and end row id from string type to int type. Through loop and prefix query, query all rows in the attribute table between the returned start row id and end row id, return the ids (edge_id) of all edges stored in these rows, and store the edge id array as elements in the first edge array, which is a binary array.

[0223] 4. Traverse the elements of the id array of each edge in the first edge array, use the string segmentation method to split the "_" and "," separators of each element in the edge id array to obtain the edge id corresponding to the query condition, and store the segmented elements in the second edge array.

[0224] 5. Obtain information about transaction data corresponding to all edges in the second edge array from the transaction list, and display the obtained information about the transaction data corresponding to the edges to the user, or analyze the obtained transaction data corresponding to the edges and display the analysis results to the user.

[0225] Steps 3, 4, and 5 correspond to Figure 9 Step 903 in .

[0226] Second, the time period query interface.

[0227] The input parameters of the time period query interface can include a start time point and an end time point. Both input parameters can be timestamp type data. Through these input parameters, you can query all transaction data with block timestamps between the start time point and the end time point.

[0228] The query process based on the time period query interface may include:

[0229] 1. Get the user input parameters, that is, the time period to be queried, including the starting time point t1 and the ending time point t2. This step corresponds to Figure 9 Step 901 in .

[0230] 2. In the time series table, t1 and t2 are used as the conditions for loop query, traverse the timestamp column of the block, and return the start row id and end row id values ​​of the rows corresponding to the queried t1 timestamp and t2 timestamp, and store them in the row id array. This step also corresponds to Figure 9 Step 902 in .

[0231] 3. Convert the elements in the row ID from string type to int type and sort them, retaining only the largest and smallest row IDs. Using a loop and prefix query, query all rows in the attribute table between the largest and smallest retained row IDs, return the IDs of all edges stored in these rows, and store the edge ID array as an element in the first edge array, a binary array.

[0232] The subsequent steps are identical to steps 4 and 5 of the time point query interface and are not detailed here. The row ID array is of type string[] and consists of the start and end row IDs found in the time series table. The first edge array in the time point and time period query interfaces is of type string[][] and is a binary array consisting of edge ID arrays. The first edge array mentioned later can also be of the same data type and is not detailed here.

[0233] In addition, Figure 9 The corresponding examples and the first and second embodiments described above describe query methods where the query conditions include at least time-related conditions. However, the data storage structure illustrated in the embodiments of this application can be used not only in the query scenarios described above, but also in scenarios where the query conditions are not time-related and only relate to at least one of an attribute, a start node, and an end node. The following describes how to query transaction data based on the above data storage structure in three scenarios where the query conditions relate to an attribute, a start node, and an end node, respectively.

[0234] Third, the attribute query interface.

[0235] The input parameters of the attribute query interface can include the attribute value to be queried, which can be a String type value. The input parameter is also the query condition entered by the user. Through this input parameter, transaction data with the attribute value entered can be queried.

[0236] The query process based on the attribute query interface may include:

[0237] 1. Get the attribute value p0 that needs to be queried entered by the user;

[0238] 2. Traverse the property value column in the attribute table, determine all rows in the column whose property value is p0, return the edge ID array of these rows, and store these edge ID arrays as elements in the first edge array to form binary data.

[0239] The subsequent steps are the same as the fourth and fifth steps of the time point query interface and are not repeated here.

[0240] Fourth, the starting node query interface.

[0241] The input parameter of the starting node query interface may include the node ID, which may be of string type. Through this input parameter, all transaction data whose starting node is the input node ID may be queried.

[0242] The query process based on the start node query interface may include:

[0243] 1. Get the id of the node entered by the user.

[0244] 2. In the attribute table, traverse the start node set (start_node) column of the transaction data, determine all array indexes in the array of this column whose values ​​are the IDs of the input nodes, query the element corresponding to the determined array index in the ID array of the edge of the corresponding row, and store these elements in the first edge array.

[0245] The subsequent steps are the same as steps 4 and 5 of the time point query interface and will not be repeated here. As mentioned above, the starting node set and the edge ID column are both stored in arrays. There is a correspondence between the two arrays, that is, the elements separated by the "," delimiter in the two arrays are one-to-one corresponding. For example, in the starting node set of a row, the third element separated by the "," delimiter is A, and in the edge ID array, the third element separated by the "," delimiter is 4. Therefore, the element corresponding to the array index A is 4.

[0246] Fifth, terminate the node query interface.

[0247] Similar to the starting node query interface, the input parameter of the ending node query interface may include the node ID, which may be of string type. Through this input parameter, all transaction data whose ending node is the input node ID may be queried.

[0248] As for the process of querying based on the end node query interface, the process is similar to the process of querying based on the start node query interface. The difference from the above process is that the end node set is traversed in the second step.

[0249] The present application provides five methods for querying transaction data. Any of the five query methods can be combined, such as any two combinations, any three combinations, any four combinations, etc. The query methods after the combination can be detailed in the above description. Figure 6 The description is not repeated here.

[0250] For the query method of combining any two or three of the third, fourth, and fifth above, that is, querying the attributes, starting nodes, and / or ending nodes in the attribute table at the same time, the edge set that meets the input query parameters is determined.

[0251] Secondly, when the graph is stored in a key-value database, that is, when the graph is stored based on Tables 13 and 14, time point queries, time period queries, attribute queries, start node queries, and end node queries can be performed. These five query methods are explained below.

[0252] First, time point query and time period query.

[0253] For point-in-time queries, the parameter obtained through the point-in-time query interface may be "{time:t1}", which indicates that the query is based on a point-in-time, and t1 is the input point-in-time to be queried. Through this parameter, transaction data with a timestamp of t1 can be queried.

[0254] For time period query, the parameter obtained through the time period query interface can be "{start_time:t1,terminate_time:t2}". This parameter is used to indicate that the user is querying based on the time period, and the transaction data to be queried is within the time range of t1 and t2.

[0255] like Figure 11 As shown, the specific query process may include:

[0256] Step 101: Determine the time point or time range to be queried based on the acquired parameters.

[0257] Specifically, if the parameter is in the form of "{time:t1}", it can be determined that it is a time point query, and the time point to be queried is determined to be t1. If the parameter is in the form of "{start_time:t1,terminate_time:t2}", it can be determined that it is a time period query, and the time period to be queried is determined to be t1-t2.

[0258] Step 1021: When the parameter is a time point, the input time point is searched through a prefix search.

[0259] Specifically, in a database with a key-value storage structure, you can use a prefix query to find the key containing "t1", return its value, and store the two values ​​as two strings.

[0260] Step 1022: When the parameter is a time period, the input time period is searched through prefix search and loop search.

[0261] Specifically, in a database with a key-value storage structure, you can use prefix query and loop to query the keys in "t1" and "t2", return all value values, and store all returned value values ​​in the row ID array.

[0262] Step 103: Determine the corresponding row ID through prefix query and loop query to obtain the first edge array.

[0263] Specifically, for time period queries, you can first determine the maximum and minimum values ​​from the row ID array, perform a prefix query in the database, determine the keys that contain all values ​​between the maximum and minimum values, return the values ​​corresponding to these keys, and store the values ​​in the first side array.

[0264] For time point query, the method is similar to the time period query method, except that there is no need to determine the maximum and minimum values ​​in the row id array. Step 1021 obtains two strings, namely the maximum and minimum values, which will not be repeated here.

[0265] Step 104 : Separate the elements in the first edge array according to the delimiter using a string segmentation method, and return the second edge array obtained after the separation.

[0266] The transaction data corresponding to the second edge array may be displayed to the user later. The specific implementation of step 104 can be found above and will not be described in detail here.

[0267] Second, attribute, start node and end node query

[0268] For attribute query, the parameter obtained through the attribute query interface can be "{property:"finance,catering"}", which is used to indicate the query for transaction data based on the attribute, and the transaction data to be queried is the financial and catering types. For the starting node query, the parameter obtained through the starting node query interface can be "{startnode:'"A","B"'}", which is used to indicate the query for transaction data based on the starting node, and the transaction data to be queried is the starting nodes A and B. For the terminating node query, the parameter obtained through the terminating node query interface can be "{terminatenode:{"A","B"}}", which is used to indicate the query for transaction data based on the terminating node, and the transaction data to be queried is the terminating nodes A and B.

[0269] In this query method, single quotes and curly brackets are used to distinguish the start node and the end node, which can improve the query rate.

[0270] like Figure 12 As shown, the specific query process may include:

[0271] Step 111: Determine the attribute, starting node, or ending node to be queried according to the acquired parameters.

[0272] For example, if the parameter is in the form of {property:"Finance,Catering"}, the property of the transaction data to be queried can be determined to be finance or catering. If the parameter is in the form of {startnode:'"A","B"'}, the starting node of the transaction data to be queried can be determined to be A or B. If the parameter is in the form of {terminatenode:{"A","B"}}, the ending node of the transaction data to be queried can be determined to be A or B.

[0273] Step 1121: When the parameter is an attribute, query the input attribute through prefix query.

[0274] Specifically, you can query the database for keys containing finance or catering keys, return their values, and store the returned values ​​in the first side array.

[0275] Step 1122: When the parameter is a starting node, the input starting node is searched through a single quote prefix query.

[0276] Specifically, you can query the database for keys containing A or B in single quotes, return the corresponding value, and store the returned value in the first side array.

[0277] Step 1123: When the parameter is a termination node, the input termination node is searched through a curly brace prefix query.

[0278] Specifically, you can query the database for the key that includes A or B in the curly brackets, return the corresponding value, and store the returned value in the first side array.

[0279] Step 113: Separate the elements in the first edge array according to the delimiter using a string segmentation method, and return the second edge array obtained after separation.

[0280] The transaction data corresponding to the second edge array may be displayed to the user later. The specific implementation of step 113 can be found above and will not be described in detail here.

[0281] The graph access interface defined on the basis of the transaction graph takes into account the comprehensiveness of blockchain queries compared to the access methods of the attribute graph and the timing graph of related technologies. It considers multiple factors such as timing, attributes, and parallel edges, thereby optimizing the overall access efficiency.

[0282] In addition, the above Figure 11 and Figure 12The query interface shown can be implemented through a smart contract. When the consortium chain is implemented through the Fabric platform, the API called by the smart contract developer to interact with the underlying database is implemented in the shim package of the Fabric source code. The multiple query interfaces in the embodiments of the present application can also be implemented in the shim package.

[0283] This application also provides a blockchain transaction data storage device, including:

[0284] The acquisition module is used to obtain transaction data from the blockchain.

[0285] The storage module is used to store blockchain transaction data in the form of a graph, with one-to-one correspondence between the nodes of the graph and the nodes of the blockchain, and one-to-one correspondence between the edges of the graph and the transaction data of the blockchain. The graph includes an attribute table and a time series table. Each row of the attribute table includes all transaction data with the same attribute value belonging to the same block in the blockchain. The time series table includes the number of rows corresponding to the transaction data of each block in the attribute table.

[0286] In an optional embodiment, each row of the attribute table includes first type data, second type data and third type data, the first type data includes attributes of the transaction data, the second type data includes the starting node and the ending node of the transaction data, and the third type data includes the number of the transaction data; the transaction data of the blockchain is also stored in the form of a transaction list, and the transaction list includes information about the transaction data of the blockchain and the number of the transaction data.

[0287] In an optional embodiment, the attribute table includes multiple key-value pairs, the multiple key-value pairs included in the attribute table correspond one-to-one to the rows of the attribute table, the key in the key-value pair includes first type data and second type data, and the value in the key-value pair includes third type data; the first type data and the second type data are distinguished by a separator.

[0288] In an optional embodiment, the second type of data includes first subtype data and second subtype data, the first subtype data includes the starting node corresponding to the transaction data, and the second subtype data includes the ending node corresponding to the transaction data; the first type of data and the second type of data are distinguished by a first separator, and the first subtype data and the second subtype data are distinguished by a second separator, and the first separator and the second separator are different.

[0289] In an optional implementation, the time series table includes multiple key-value pairs, the key in the key-value pair includes the timestamp of the block, and the value in the key-value pair includes the row number corresponding to the block in the attribute table.

[0290] This application also provides a blockchain transaction data query device. The blockchain transaction data is stored in the form of a graph, with one-to-one correspondence between the nodes of the graph and the nodes of the blockchain, and one-to-one correspondence between the edges of the graph and the transaction data of the blockchain. The graph includes an attribute table and a time series table. Each row of the attribute table includes all transaction data with the same attribute value belonging to the same block in the blockchain, and the time series table includes the number of rows corresponding to the transaction data of each block in the attribute table. The device includes:

[0291] The acquisition module is used to obtain the query conditions input by the user; the query conditions are used to indicate the timestamp of the transaction data to be queried.

[0292] The determination module is used to determine the number of rows of transaction data that meet the query conditions in the attribute table from the time series table based on the query conditions.

[0293] The display module is used to determine the transaction data corresponding to the query condition from the attribute table based on the determined number of rows, and display the transaction data corresponding to the query condition to the user.

[0294] In an optional embodiment, each row of the attribute table includes first type data, second type data and third type data, the first type data includes attributes of the transaction data, the second type data includes the starting node and the ending node of the transaction data, and the third type data includes the number of the transaction data; the transaction data of the blockchain is also stored in the form of a transaction list, and the transaction list includes information about the transaction data of the blockchain and the number of the transaction data; in this case, the determination module is specifically used to determine the number of the transaction data corresponding to the query condition from the attribute table based on the determined number of rows; obtain the transaction data corresponding to the query condition from the transaction list according to the determined number of the transaction data; and display the transaction data corresponding to the query condition to the user.

[0295] In an optional embodiment, the query condition is further used to indicate the starting node and / or ending node of the transaction data to be queried. The determination module is used to: determine the number of transaction data that meets the query condition based on the second type of data and the third type of data from the number of rows determined in the attribute table.

[0296] In an optional embodiment, the query condition is further used to indicate the attribute value of the transaction data to be queried. The determination module is used to: determine the number of transaction data that meets the query condition based on the first type of data and the third type of data from the number of rows determined in the attribute table.

[0297] In an optional embodiment, the attributes of the transaction data include a first attribute and a second attribute; the attribute table includes a first attribute table and a second attribute table, each row in the first attribute table includes all transaction data with the same first attribute value belonging to the same block in the blockchain, and each row in the second attribute table includes all transaction data with the same second attribute value belonging to the same block in the blockchain; the time series table includes the number of rows corresponding to the transaction data of each block in the first attribute table and the second attribute table; the determined number of rows includes the determined number of rows in the first attribute table and / or the determined number of rows in the second attribute table. The determination module is used to: when a query condition is used to indicate an attribute value of a first attribute of transaction data to be queried, determine the number of transaction data that meets the query condition from the number of rows determined in the first attribute table based on the first type data and the third type data; when the query condition is used to indicate an attribute value of a second attribute of the transaction data to be queried, determine the number of transaction data that meets the query condition from the number of rows determined in the second attribute table based on the first type data and the third type data; when the query condition is used to indicate an attribute value of the first attribute and an attribute value of the second attribute of the transaction data to be queried, determine the number of first transaction data corresponding to the attribute value of the first attribute indicated by the query condition from the number of rows determined in the first attribute table based on the first type data and the second type data, and determine the number of second transaction data corresponding to the attribute value of the second attribute indicated by the query condition from the number of rows determined in the user second attribute table based on the first type data and the second type data, and use the intersection of the number of the first transaction data and the number of the second transaction data as the number of the transaction data that meets the query condition.

[0298] In an optional implementation, the query condition includes a timestamp corresponding to the transaction data to be queried and / or a range of timestamps corresponding to the transaction data to be queried.

[0299] In an optional embodiment, the blockchain is a consortium chain.

[0300] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0301] The modules described as separate components may or may not be physically separate, and the components shown as modules may be one physical module or multiple physical modules, that is, they may be located in one place or distributed in multiple places. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0302] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0303] The present application also provides an electronic device including a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the above-mentioned blockchain transaction data storage method or blockchain transaction data query method.

[0304] The present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the above-mentioned blockchain transaction data storage method or blockchain transaction data query method.

[0305] The present application also provides a computer program product, including a computer-readable code, which, when executed by a processor, implements the above-mentioned blockchain transaction data storage method or blockchain transaction data query method.

[0306] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A transaction data storage method for a blockchain, characterized in that: The method comprises: Obtain transaction data from the blockchain; The transaction data of the blockchain is stored in the form of a graph, wherein the nodes of the graph correspond one-to-one to the nodes of the blockchain, and the edges of the graph correspond one-to-one to the transaction data of the blockchain; the graph includes an attribute table and a time series table, each row of the attribute table includes all transaction data of the same attribute value belonging to the same block in the blockchain, and the time series table includes the number of rows in the attribute table corresponding to the transaction data of each block.

2. The method according to claim 1, characterized in that Each row of the attribute table includes first type data, second type data and third type data, the first type data includes attributes of transaction data, the second type data includes the starting node and ending node of the transaction data, and the third type data includes the number of the transaction data; the transaction data of the blockchain is also stored in the form of a transaction list, and the transaction list includes information about the transaction data of the blockchain and the number of the transaction data.

3. The method according to claim 2, characterized in that The attribute table includes multiple key-value pairs key-value, the multiple key-value pairs included in the attribute table correspond one-to-one to the rows of the attribute table, the key in the key-value pair includes the first type of data and the second type of data, and the value in the key-value pair includes the third type of data; the first type of data and the second type of data are distinguished by a separator.

4. The method according to claim 3, characterized in that The second type data includes first subtype data and second subtype data, the first subtype data includes a starting node corresponding to the transaction data, and the second subtype data includes an ending node corresponding to the transaction data; the first type data and the second type data are distinguished by a first separator, and the first subtype data and the second subtype data are distinguished by a second separator, and the first separator and the second separator are different.

5. The method according to any one of claims 1 to 4, characterized in that The time series table includes multiple key-value pairs, the key in the key-value pair includes the timestamp of the block, and the value in the key-value pair includes the row number corresponding to the block in the attribute table.

6. A method for querying transaction data of a blockchain, characterized in that: The transaction data of the blockchain is stored in the form of a graph, with nodes of the graph corresponding one-to-one to nodes of the blockchain, and edges of the graph corresponding one-to-one to transaction data of the blockchain. The graph includes an attribute table and a time series table. Each row of the attribute table includes all transaction data with the same attribute value belonging to the same block in the blockchain. The time series table includes the row number of the transaction data of each block in the attribute table. The method comprises: Obtaining a query condition input by a user; the query condition is used to indicate the timestamp of the transaction data to be queried; Based on the query condition, determining the number of rows of transaction data that meets the query condition in the attribute table from the time series table; Based on the determined number of rows, transaction data corresponding to the query condition is determined from the attribute table, and the transaction data corresponding to the query condition is displayed to the user.

7. The method according to claim 6, characterized in that Each row of the attribute table includes first type data, second type data, and third type data. The first type data includes attributes of transaction data, the second type data includes the starting node and ending node of the transaction data, and the third type data includes the transaction data number. The transaction data of the blockchain is also stored in the form of a transaction list, which includes information about the transaction data of the blockchain and the transaction data number. The determining, based on the determined number of rows, transaction data corresponding to the query condition from the attribute table, and presenting the transaction data corresponding to the query condition to the user includes: Based on the determined number of rows, determining the serial number of the transaction data corresponding to the query condition from the attribute table; According to the determined transaction data number, acquiring the transaction data corresponding to the query condition from the transaction list; The transaction data corresponding to the query condition is displayed to the user.

8. The method according to claim 7, characterized in that The query condition is also used to indicate the starting node and / or ending node of the transaction data to be queried; The determining, based on the determined number of rows, from the attribute table, the serial number of the transaction data corresponding to the query condition includes: The serial number of the transaction data meeting the query condition is determined from the number of rows determined in the attribute table according to the second type of data and the third type of data.

9. The method according to claim 7, characterized in that The query condition is also used to indicate the attribute value of the transaction data to be queried; The determining, based on the determined number of rows, from the attribute table, the serial number of the transaction data corresponding to the query condition includes: The serial number of the transaction data meeting the query condition is determined from the number of rows determined in the attribute table according to the first type of data and the third type of data.

10. The method according to claim 9, characterized in that The attributes of the transaction data include a first attribute and a second attribute; the attribute table includes a first attribute table and a second attribute table, each row in the first attribute table includes all transaction data with the same first attribute value belonging to the same block in the blockchain, and each row in the second attribute table includes all transaction data with the same second attribute value belonging to the same block in the blockchain; the time series table includes the number of rows corresponding to the transaction data of each block in the first attribute table and the second attribute table; the determined number of rows includes the determined number of rows in the first attribute table and / or the determined number of rows in the second attribute table; Determining the serial number of transaction data that meets the query condition based on the first type of data and the third type of data from the number of rows determined in the attribute table includes: In a case where the query condition is used to indicate an attribute value of a first attribute of transaction data to be queried, determining, from the number of rows determined in the first attribute table, the serial number of the transaction data that meets the query condition based on the first type of data and the third type of data; In a case where the query condition is used to indicate an attribute value of a second attribute of the transaction data to be queried, determining, from the number of rows determined in the second attribute table, the number of the transaction data that meets the query condition based on the first type of data and the third type of data; In a case where the query condition is used to indicate the attribute value of the first attribute and the attribute value of the second attribute of the transaction data to be queried, the number of the first transaction data corresponding to the attribute value of the first attribute indicated by the query condition is determined from the number of rows determined in the first attribute table based on the first type of data and the second type of data, and the number of the second transaction data corresponding to the attribute value of the second attribute indicated by the query condition is determined from the number of rows determined in the user second attribute table based on the first type of data and the second type of data, and the intersection of the number of the first transaction data and the number of the second transaction data is used as the number of the transaction data that meets the query condition.

11. The method according to any one of claims 6 to 10, characterized in that: The query condition includes a timestamp corresponding to the transaction data to be queried and / or a range of timestamps corresponding to the transaction data to be queried.

12. The method according to any one of claims 6 to 11, characterized in that: The blockchain is a consortium chain.

13. An electronic device, characterized in that: It includes a memory and a processor, the memory is used to store a computer program, and the processor is used to execute the computer program to implement the transaction data storage method of the blockchain described in any one of claims 1 to 5 or the transaction data query method of the blockchain described in any one of claims 6 to 12.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the transaction data storage method of the blockchain described in any one of claims 1 to 5 or the transaction data query method of the blockchain described in any one of claims 6 to 12.

15. A computer program product, characterized in that The method comprises a computer-readable code, which, when executed by a processor, implements the transaction data storage method of the blockchain described in any one of claims 1 to 5 or the transaction data query method of the blockchain described in any one of claims 6 to 12.

Images