A storage system for cross-subject data flow

Abstract

The embodiment of the application provides a kind of to cross subject data flow's storage system, it is related to distributed ledger technology field.The storage system includes application end and server, the server includes graph account module and sequencing engine module;The application end provides data flow service for transaction subject, and the record generated by data flow is transmitted to the server, the type of the record includes: unordered storage record and ordered storage record;The server judges the type of the record, calls the graph account module and stores the unordered storage record according to the random fragmentation method of graph structure, calls the sequencing engine module and stores the ordered storage record according to the hierarchical sequencing consensus method.The storage system for cross subject data flow provided in the embodiment of the application separates unordered storage and sequencing storage, realizes the high-performance storage of cross subject data flow scene.

Description

Technical Field

[0001] This application relates to the field of distributed ledger technology, and in particular to a notarization system for cross-entity data circulation. Background Technology

[0002] With the development of blockchain and smart contract technologies, the application areas of distributed ledger technology have expanded from financial fields such as cryptocurrencies to many fields where data circulation is a core requirement. Cross-entity data circulation has become one of the core requirements and challenges of distributed ledger industry applications. In cross-entity data circulation scenarios, distributed ledgers are mainly used to store key data and key processing procedures in data circulation.

[0003] Compared to other application areas of distributed ledger technology, cross-entity data circulation scenarios, while maintaining the tamper-proof and loss-proof nature of ledger data, also have increasingly higher performance requirements, necessitating distributed ledgers to achieve a write throughput of over 1 million records per second in public network environments with thousands of nodes. Existing distributed ledger-based cross-entity data circulation and evidence preservation systems struggle to meet the large-scale and high-performance demands of these scenarios. Therefore, achieving high-performance evidence preservation for cross-entity data circulation is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide an evidence storage system for cross-subject data circulation, so as to overcome the above problems or at least partially solve the above problems.

[0005] This application provides an evidence storage system for cross-entity data circulation. The evidence storage system includes an application terminal and a server terminal. The server terminal includes a graph ledger module and a sequencing engine module.

[0006] The application provides data circulation services to the transaction entities and transmits the records generated by the data circulation to the server. The types of records include: unordered evidence records and ordered evidence records.

[0007] The server determines the type of the record, calls the graph ledger module to perform unordered storage of the unordered evidence record according to the graph structure random sharding method, and calls the ordering engine module to perform ordered storage of the ordered evidence record according to the hierarchical ordering consensus method.

[0008] Optionally, the graph ledger module is invoked to perform unordered storage of the unordered evidence records according to the random sharding method of the graph structure, including:

[0009] The server sends the disordered evidence records to the graphical ledger module;

[0010] After the number of unordered evidence records in the graphical ledger module reaches a first quantity threshold and / or the time interval between new block creations reaches a first time threshold, the graphical ledger module will package the received unordered evidence records into a new block.

[0011] Multiple network nodes are randomly selected to form a shard, and the new block is saved to each network node of the shard. The new block and other blocks form a directed acyclic graph structure.

[0012] Optionally, the ordering engine module is invoked to perform ordering and storage of the ordered evidence records according to the hierarchical ordering consensus method, including:

[0013] The server sends the ordered evidence storage record to the sequencing engine module;

[0014] After the number of ordered evidence records in the ordering engine module reaches the second quantity threshold and / or the time interval between ordering block creation reaches the second time threshold, the ordering engine module will package the received ordered evidence records into an ordering block according to the record order.

[0015] The ordered blocks are converted into ledger blocks and transmitted to the graph ledger module, so that the graph ledger module performs unordered storage of the ledger blocks according to the random sharding method of the graph structure. The ledger blocks represent the record sequence of ordered storage records.

[0016] Optionally, the sequencing engine module packages the received ordered evidence records into a sequencing block according to the record order, including:

[0017] The sequencing engine module detects whether there are associated sequencing fragments of the ordered evidence storage records;

[0018] In the presence of the associated ordered shards, the ordered evidence record is sent to the associated ordered shards so that the associated ordered shards generate the ordered blocks based on ordered consensus;

[0019] In the absence of the associated ordered shard, an associated ordered shard of the ordered evidence record is created based on the random sharding method, and the ordered evidence record is sent to the created associated ordered shard, so that the created associated ordered shard generates the ordered block based on the ordered consensus.

[0020] Optionally, the graphical ledger module is equipped with a record query interface;

[0021] Specifically, the application terminal is used to execute: transmitting the record ID to the server terminal, where the record ID is the record ID returned by the graph ledger module after completing the storage of the unordered evidence record;

[0022] Specifically, the server is used to execute: calling the record query interface of the graphical ledger module based on the record ID to obtain the evidence record corresponding to the record ID.

[0023] Optionally, the sequencing engine module is equipped with a record query interface and a sequence query interface;

[0024] The application terminal is specifically used to perform: transmitting the record ID and / or sequence identifier to the server, wherein the record ID is the record ID returned by the sequence engine module after completing the storage of the ordered evidence record, and the sequence identifier is the sequence identifier carried in the ordered evidence record, or the sequence identifier is a new sequence identifier returned after completing the storage of the ordered evidence record.

[0025] The server is specifically used to perform the following: calling the record query interface of the sequencing engine module based on the record ID and / or the sequencing identifier to obtain the evidence storage record corresponding to the record ID; and calling the sequence query interface of the sequencing engine module based on the sequencing identifier to obtain the evidence storage sequence record corresponding to the sequencing identifier.

[0026] Optionally, a smart contract executor is deployed in the sequencing engine module;

[0027] The smart contract executor processes the ordered evidence records in the associated sequenced block to keep each network node in the associated sequenced block in the same state.

[0028] Optionally, the smart contract executor processes the ordered evidence records in the associated sequenced block, including:

[0029] After the associated ordered shards generate the ordered block based on the ordered consensus, the smart contract executor reads the ordered evidence records in the ordered block one by one;

[0030] The new state of the ordered block is obtained by using the method specified in the call read code represented by the ordered evidence record, the current state of the ordered block, the code of the method, and the parameters in the smart contract call.

[0031] Write the new state of the ordered block to each network node of the associated ordered fragment.

[0032] Optionally, the record includes a sequence identifier field; the server determines the type of the record, including:

[0033] Determine whether the sequence identifier field of the record is empty;

[0034] If the sequence identifier field of the record is empty, the record is identified as an unordered evidence record;

[0035] If the sequence identifier field of the record is not empty, the record is identified as an ordered evidence record.

[0036] Optionally, after the next new block is generated, the graphical ledger module randomly selects multiple network nodes to form a new shard, and saves the next new block to each network node of the new shard.

[0037] The embodiments of this application have the following advantages:

[0038] In this embodiment, based on the increasing demand for unordered evidence storage services and the dispersed demand for ordered evidence storage services in cross-entity data circulation scenarios, an evidence storage system for cross-entity data circulation, consisting of an application terminal and a server terminal, is provided. The application terminal provides data circulation services to the transaction entities and transmits the records generated by the data circulation to the server terminal. The server terminal then determines the type of the record and calls the graph ledger module to perform unordered evidence storage of the unordered evidence storage records according to the random sharding method of the graph structure, and calls the ordering engine module to perform ordered evidence storage of the ordered evidence storage records according to the hierarchical ordering consensus method.

[0039] The evidence storage system for cross-entity data circulation provided in this application separates unordered evidence storage from ordered evidence storage. For unordered evidence records where the storage order does not need to be considered, a random sharding method based on a graph structure is used to achieve high-performance parallel evidence storage for a large number of unordered evidence records in cross-entity data circulation scenarios, reducing network and storage pressure. At the same time, a separate ordered evidence storage is performed for a small number of ordered evidence records, providing a stable ordered evidence storage service. Thus, high-performance evidence storage is achieved for cross-entity data circulation scenarios. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the architecture of an evidence storage system for cross-subject data circulation provided in an embodiment of this application;

[0042] Figure 2 This is a schematic diagram of the directed acyclic graph structure and the blockchain-like structure in the embodiments of this application;

[0043] Figure 3 This is a schematic diagram of the structure of ordered block data provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of a smart contract execution unit provided in an embodiment of this application;

[0045] Figure 5 This is a flowchart of a data storage system for cross-entity data circulation provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of an evidence storage system architecture for cross-subject data circulation provided in an embodiment of this application. Detailed Implementation

[0047] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] Analysis of cross-entity data flow scenarios based on distributed ledgers reveals that in most business processes, the chronological order of records on the ledger does not affect the overall workflow. Furthermore, the few sequence-sensitive transactions are relatively dispersed, meaning that transactions requiring unordered evidence storage tend to be more numerous, while those requiring ordered evidence storage are less so. In other words, a large number of records generated in cross-entity data flow scenarios do not require ordered evidence storage; only a small number do. The increasing prevalence of unordered evidence storage and the dispersed nature of ordered evidence storage suggest that ordered and unordered evidence storage can be separated.

[0049] Therefore, to address the issue that existing data storage systems cannot meet the large-scale and high-performance requirements of cross-entity data circulation scenarios, the applicant proposes the following technical concept: separating unordered storage and ordered storage. For unordered storage records where the storage order does not need to be considered, a graph-structured random sharding method is used to perform unordered storage on a large number of unordered storage records in cross-entity data circulation scenarios, while a small number of ordered storage records are stored in ordered order separately. This enables high-performance parallel storage of a large number of unordered storage records, reducing network and storage pressure, while also achieving ordered storage of ordered storage records.

[0050] Reference Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of an evidence storage system for cross-entity data circulation provided in an embodiment of this application. For example... Figure 1 As shown in the figure, the evidence storage system for cross-entity data circulation provided in this application includes an application terminal and a server terminal. The server terminal includes a graph ledger module and a sequencing engine module.

[0051] The application provides data circulation services to the transaction entities and transmits the records generated by the data circulation to the server. The types of records include: unordered evidence records and ordered evidence records.

[0052] The server determines the type of the record, calls the graph ledger module to perform unordered storage of the unordered evidence record according to the graph structure random sharding method, and calls the ordering engine module to perform ordered storage of the ordered evidence record according to the hierarchical ordering consensus method.

[0053] In this embodiment, the application provides data circulation services to the transaction entities, such as supporting government data circulation and trusted data aggregation. Different transaction entities circulate data through the application, generating different types of records. Unordered evidence records are those whose chronological order does not need to be considered during evidence storage, while ordered evidence records are those whose chronological order needs to be considered during evidence storage. The application transmits the generated records to the server through a unified interface. Upon receiving the records, the server determines their type to subsequently decide whether to perform unordered or ordered evidence storage.

[0054] Furthermore, for unordered evidence records that do not require consideration of storage order, a graph-structured random sharding method is used to achieve high-performance parallel storage of a large number of unordered evidence records in cross-entity data flow scenarios, reducing network and storage pressure. Simultaneously, the graph ledger module uses a graph-structured random sharding method to perform unordered evidence storage, ensuring the ledger data's tamper-proof and loss-proof properties while improving performance. The ordering engine module employs a hierarchical ordering consensus method for ordering evidence storage. This method constructs a sharded ordering consensus based on unordered evidence storage, providing ordering services for record sets requiring ordering, ordering them into chain-like block data, and writing them into the graph-structured consensus storage through unordered evidence storage. Therefore, high-performance evidence storage is achieved for cross-entity data flow scenarios.

[0055] In one optional embodiment, the record includes a sequence identifier field; the server determines the type of the record by:

[0056] Determine whether the sequence identifier field of the record is empty; if the sequence identifier field of the record is empty, determine the record as an unordered evidence record; if the sequence identifier field of the record is not empty, determine the record as an ordered evidence record.

[0057] In this embodiment, to identify whether a record is an unordered or ordered evidence record, in addition to the inherent fields such as ID, initiator, receiver, and content, this embodiment adds a sequence identifier field to the record's data structure. Records with the same sequence identifier are sorted to generate a record sequence, thereby storing consistent content and order information in the system. Therefore, when the server receives a record, it determines the record's type—whether it is an unordered or ordered evidence record—based on the record's sequence identifier.

[0058] In one optional embodiment, the graphical ledger module is invoked to perform unordered storage of the unordered evidence records according to the random sharding method of the graphical structure, including:

[0059] The server sends the unordered evidence records to the graph ledger module; after the number of unordered evidence records in the graph ledger module reaches a first quantity threshold and / or the new block creation time interval reaches a first time threshold, the graph ledger module packages the received unordered evidence records into a new block; multiple network nodes are randomly selected to form a shard, and the new block is saved in each network node of the shard, and the new block forms a directed acyclic graph structure with other blocks.

[0060] In this embodiment, the first quantity threshold is set according to the actual evidence storage needs. For example, if the first quantity threshold is 10, the graph ledger module will package the 10 unordered evidence storage records into a new block after receiving them. The new block creation time interval refers to the time between the creation of a new block and the creation of the next new block in the graph ledger module. The first time threshold is set according to the actual evidence storage needs. For example, if the first time threshold is 10 seconds, the graph ledger module will package the received unordered evidence storage records into a new block after the new block creation time interval reaches 10 seconds.

[0061] In specific implementation, the following two situations apply: 1) When the number of unordered evidence records in the graph ledger module reaches the first quantity threshold, the received unordered evidence records are packaged into a new block; 2) When the time interval between the creation of a new block reaches the first time threshold, even if the number of unordered evidence records in the graph ledger module has not yet reached the first quantity threshold, the received unordered evidence records need to be packaged into a new block.

[0062] Furthermore, while increasing record write throughput, to ensure data tamper-proof and loss-proof protection, multiple network nodes are randomly selected from all network nodes to form shards. Then, based on witness consensus, new blocks are saved to each network node in the shards. For example, if there are 50 network nodes, 10 network nodes are randomly selected as shards, and new blocks are saved to these 10 network nodes respectively.

[0063] In this context, the Directed Acyclic Graph (DAG) structure refers to treating blocks in a distributed ledger as vertices of a graph, and the links between blocks formed by prior order relationships as directed edges. All blocks in the ledger then form a DAG. Because newly generated blocks form a DAG with other blocks, when all blocks are used for consensus, a DAG structure can have more successor blocks compared to a chain-like structure. Subgraphs rooted at any block also typically have more blocks. For example... Figure 2 As shown, when all blocks in a chain-like structure are added to the ledger, it's equivalent to storing the same set of blocks using both structures. The directed acyclic graph (DAG) structure has significantly more edges (i.e., more blockchain connections) than the chain-like structure, meaning its blocks are confirmed by more subsequent blocks. If a block is tampered with, in a DAG structure, many subsequent blocks need to be tampered with simultaneously, and even more subsequent blocks need to be tampered with; otherwise, the tampered data will be discovered, thus increasing the difficulty of tampering with block data. Therefore, with a DAG structure, using all blocks as consensus has a higher difficulty of tampering, resulting in stronger tamper resistance. Simultaneously, blocks generated by the graph ledger module are no longer discarded, and the graph ledger module can collect unordered evidence records in parallel and generate new blocks, improving record throughput and scalability.

[0064] Furthermore, to improve the parallelism of record writing while maintaining the loss prevention of block data, the graph ledger module randomly selects multiple network nodes to form a new shard after the next new block is generated, and saves the next new block to each network node of the new shard.

[0065] In this embodiment, to improve the tamper-proof nature of sharded consensus, different network nodes are selected to form shards each time. Since the order of unordered evidence records does not need to be preserved in cross-entity data flow scenarios, and network nodes do not need to detect whether records are duplicated, network nodes can participate in the consensus process without pre-preserved records. Therefore, the unordered evidence preservation method can increase the frequency of shard reconfiguration (i.e., re-randomly selecting multiple network nodes to form new shards), reaching the highest frequency of re-determining shards for each block generated, ensuring that blocks generated in each cycle are stored on different nodes. Simultaneously, if shards overlap, the consensus within a shard does not interfere with each other because pre-preserved records are not required for consensus within that shard. Therefore, the parallelism of record writing is improved while maintaining the loss-proof nature of block data.

[0066] In one optional embodiment, the ordering engine module is invoked to perform ordering and notarization of the ordered notarization records according to a hierarchical ordering consensus method, including:

[0067] The server sends the ordered evidence records to the sequencing engine module; after the number of ordered evidence records in the sequencing engine module reaches a second quantity threshold and / or the time interval between sequencing block creation reaches a second time threshold, the sequencing engine module packages the received ordered evidence records into a sequencing block according to the record order; the sequencing block is converted into a ledger block and transmitted to the graph ledger module, so that the graph ledger module performs unordered evidence storage on the ledger block according to the graph structure random sharding method, and the ledger block represents the record sequence of ordered evidence records.

[0068] In this embodiment, the second quantity threshold is set according to the actual evidence storage needs. For example, if the first quantity threshold is 15, the sequencing engine module, after receiving 15 ordered evidence storage records, will package the 15 ordered evidence storage records into a sequencing block according to the record order. The sequencing block creation time interval refers to the time from the creation time of the previous sequencing block to the creation time of the next sequencing block in the sequencing engine module. The second time threshold is set according to the actual evidence storage needs. For example, if the second time threshold is 15 seconds, the sequencing engine module will package the received ordered evidence storage records into a sequencing block after the sequencing block creation time interval reaches 15 seconds.

[0069] Among them, ordered blocks are a type of chain-structured block data, such as... Figure 3As shown. At this point, the chain-structured block data cannot be directly stored out of order by the graph ledger module. Therefore, after obtaining ordered shards, the ordering engine module transforms the ordered blocks into ledger blocks that the graph ledger module can store. Specifically, it embeds the ordered blocks into the ledger block data to retain sufficient information in the ledger blocks, displaying the sequential relationship of the same ordered identifier record set, and allowing the recovery of records from the ordered blocks from the ledger blocks. Furthermore, the graph ledger module stores the ledger blocks out of order according to the graph structure's random sharding method. That is, the graph ledger module randomly selects multiple network nodes to form shards and saves the ledger blocks to each network node of the shards, making them part of the graph structure consensus storage, thus ensuring the tamper-proof nature of the block data.

[0070] Specifically, the sequencing engine module packages the received ordered evidence records into a sequencing block according to the record order, including:

[0071] The ordering engine module detects whether there is an associated ordering shard of the ordered evidence record; if the associated ordering shard exists, the ordered evidence record is sent to the associated ordering shard so that the associated ordering shard generates the ordering block based on ordering consensus; if the associated ordering shard does not exist, an associated ordering shard of the ordered evidence record is created based on a random sharding method, and the ordered evidence record is sent to the created associated ordering shard so that the created associated ordering shard generates the ordering block based on ordering consensus.

[0072] In this embodiment, the ordered evidence records carry corresponding sequence identifiers, and the associated sequence fragments of the ordered evidence records are the sequence fragments corresponding to the sequence identifiers. The associated sequence fragments sort records with the same sequence identifiers, and the ordered evidence records with the same sequence identifiers are ordered to form a chain-like block data (i.e., a sequenced block).

[0073] In one optional embodiment, the graphical ledger module is equipped with a record query interface;

[0074] The application is specifically used to: transmit the record ID to the server, where the record ID is the record ID returned by the graph ledger module after completing the storage of the unordered evidence record; the server is specifically used to: call the record query interface of the graph ledger module based on the record ID to obtain the evidence record corresponding to the record ID.

[0075] In this embodiment, the graphical ledger module generates record IDs by calculating the hash value of all data in the unordered evidence record except for the ID, and then returning this hash value to the user after the unordered evidence record is stored. The user can then retrieve the evidence record corresponding to the obtained record ID by entering the corresponding record ID in the application.

[0076] In one optional embodiment, the sequencing engine module is deployed with a record query interface and a sequence query interface;

[0077] The application terminal is specifically used to perform: transmitting the record ID and / or sequence identifier to the server, wherein the record ID is the record ID returned by the sequence engine module after completing the storage of the ordered evidence record, and the sequence identifier is the sequence identifier carried in the ordered evidence record, or the sequence identifier is a new sequence identifier returned after completing the storage of the ordered evidence record.

[0078] The server is specifically used to perform the following: calling the record query interface of the sequencing engine module based on the record ID and / or the sequencing identifier to obtain the evidence storage record corresponding to the record ID; and calling the sequence query interface of the sequencing engine module based on the sequencing identifier to obtain the evidence storage sequence record corresponding to the sequencing identifier.

[0079] In this embodiment, the new sequence identifier differs from the sequence identifier carried in the ordered evidence record. The new sequence identifier is either directly specified by the application or automatically generated. Specifically, when performing ordered evidence storage on an ordered evidence record, the application directly assigns a new sequence identifier to the record and returns it to the user after the storage is completed. Alternatively, if the application does not directly assign a new sequence identifier, it automatically assigns one to the record by calling the server's interface and returns it to the application after storage is completed, allowing the application to return this identifier to the user.

[0080] When calling the record query interface to obtain the evidence record corresponding to the record ID, there are two specific implementation methods: 1) Querying the evidence record using the sequence identifier and record ID. In this case, the sequence engine module only checks the corresponding sequenced evidence records to obtain the corresponding evidence record; 2) Querying the evidence record using only the record ID. In this case, the sequence engine module will query all evidence records to obtain the corresponding evidence record. Simultaneously, users can use the sequence identifier to query the sequenced records with the same identifier. Furthermore, additional conditions can be added to filter records or control the length of the returned record sequence.

[0081] In one optional embodiment, a smart contract executor is deployed in the sequencing engine module; the smart contract executor processes the ordered evidence records in the associated sequencing block to keep each network node in the associated sequencing block in the same state.

[0082] In this embodiment, a smart contract is a program that can be stored in a ledger and run on the ledger. The code and call requests of a smart contract can be represented in the form of records. The process by which these records are processed by the smart contract mechanism to create or change the state of the smart contract is called record execution. Identical smart contracts deployed in any location will become identical in state after executing the same smart contract call, provided they start from the same state. Based on this, a data storage system for cross-entity data flow can maintain a copy of the code and state of the same smart contract on each network node. Combined with a smart contract executor, the record of the smart contract can be processed on any network node, ensuring that all network nodes in the associated ordered blocks remain in the same state. Therefore, by deploying a smart contract executor in the ordering engine module, the ordered data storage service supported by the ordering engine becomes more intuitive. Simultaneously, the data such as the ordered blocks and stored records generated by the ordered sharding can be easily queried through smart contract calls, facilitating use and testing.

[0083] Specifically, the minimum structure for a smart contract to provide services consists of code, a copy of the state, and a smart contract executor. With these three parts, this minimum structure can independently execute smart contract calls to process ordered evidence records in a linked sequence block, ensuring that all network nodes in the linked sequence block remain in the same state.

[0084] like Figure 4 As shown, combining this minimal structure with the minimal structure of ordered sharding, we obtain ordered units that can provide smart contract services, i.e., ordered shards that can maintain smart contracts, or smart contract shards. The ordered units of such ordered shards are called smart contract execution units. The sorter, consensus mechanism, and data management are all original components of the ordered unit. Based on this, by using records to represent the code and calls of the smart contract, we can obtain and execute the record sequence from the generated ordered blocks, constructing copies of the smart contract's code and state. The ordered unit and ordered shard are constructed when the first ordered record of the ordered identifier is passed in; the smart contract's code and state copies are also initialized at this time.

[0085] Specifically, the smart contract executor processes the ordered evidence records in the associated ordered block, including: after the associated ordered shard generates the ordered block based on the ordered consensus, the smart contract executor reads the ordered evidence records in the ordered block one by one; obtains the new state of the ordered block according to the method specified in the call reading code represented by the ordered evidence records, the current state of the ordered block, the code of the method, and the parameters in the smart contract call; and writes the new state of the ordered block to each network node of the associated ordered shard.

[0086] In practical applications, the evidence storage system for cross-entity data circulation uses JavaScript as the programming language for smart contracts and a modified JavaScript executor as the executor for smart contracts. It also provides some built-in functional APIs to implement complex application logic and functions.

[0087] Figure 5 This is a flowchart of a data storage system for cross-entity data circulation provided in this application embodiment. First, the application transmits records carrying sequence identifiers generated during data circulation to the server. After receiving the records, the server calls the graph ledger module or the sequence engine module to perform data storage based on the sequence identifiers of the records.

[0088] When the sequence identifier of a record is empty, it means that the record needs to be stored out of order, i.e., it is an out-of-order storage record. At this time, the out-of-order storage record is sent to the graph ledger module. After the number of out-of-order storage records in the graph ledger module reaches the first quantity threshold or the time interval between new block creation reaches the first time threshold, the received out-of-order storage records are packaged into a new block. Multiple network nodes are randomly selected to form a shard, and the new block is saved in each network node of the shard. The new block and other blocks form a directed acyclic graph structure, i.e., a consensus storage with a graph structure is formed.

[0089] When the sequence identifier of a record is not empty, it indicates that the record needs to be stored in order, i.e., it is an ordered storage record. The server sends the ordered storage record to the ordering engine module. The ordering engine module checks whether there is an associated ordered shard of the ordered storage record. If an associated ordered shard exists, the ordered storage record is sent to the associated ordered shard. If no associated ordered shard exists, an associated ordered shard of the ordered storage record is created based on the random sharding method, and the ordered storage record is sent to the created associated ordered shard, thus obtaining the ordered block. The ordering engine module converts the ordered block into a ledger block and transmits it to the graph ledger module, so that the graph ledger module can perform unordered storage of the ledger block according to the random sharding method of the graph structure, making it part of the consensus storage of the graph structure.

[0090] Figure 6This is a schematic diagram of an evidence storage system architecture for cross-entity data circulation provided in this application embodiment. Specifically, the evidence storage system architecture for cross-entity data circulation is divided into a network layer, storage layer, consensus layer, protocol layer, and application layer from bottom to top. The network layer is built on a peer-to-peer network composed of multiple physical nodes. These physical nodes belong to different organizations or institutions and are controlled by their respective access mechanisms. Therefore, the evidence storage system for cross-entity data circulation belongs to an open consortium blockchain / public permissioned blockchain system. The network layer is responsible for communication between network nodes, providing interfaces for obtaining information such as neighboring network node lists, network node status, communication addresses, and certificates. For cross-entity data circulation scenarios with high performance requirements, the network layer can adopt a hybrid peer-to-peer network architecture, using a centralized directory to collect network node information while retaining the point-to-point communication capabilities of network nodes, thus reducing the workload of upper layers.

[0091] Based on the business needs of cross-entity data flow scenarios, the storage layer defines new record and block data structures. For unordered evidence storage, the graph ledger module packages records into blocks, forming a parallelized directed acyclic graph structure. For ordered evidence storage, the ordering engine module groups and orders records according to ordering identifiers, uses ordered blocks to represent the ordering results, and forms multiple ordered blockchains. Ordered blocks are transformed one-to-one into ledger blocks by embedding structural information into the record content and stored in the parallel graph structure.

[0092] The consensus layer provides both high-frequency random sharding consensus for unordered evidence storage and sharded ordered consensus for ordered evidence storage. High-frequency random sharding consensus packages records received by nodes into blocks and randomly selects some nodes as shards for storing these blocks, forming a parallel graph structure at the storage layer. Then, an ordered consensus layer is constructed based on the high-frequency random sharding consensus, forming a hierarchical consensus structure. The sharded ordered consensus in the ordered consensus layer groups and orders record sets with different order identifiers, producing a globally ordered ordered blockchain.

[0093] The protocol layer provides interfaces to users and upper-layer applications to offer two types of evidence storage services. For unordered evidence storage, the protocol layer primarily provides two interfaces: evidence storage and query. It then forwards requests to the high-frequency random shard consensus mechanism for record storage and record querying. For ordered evidence storage, the protocol layer primarily provides three interfaces: evidence storage, record querying, and sequence querying. It then forwards requests to the corresponding ordered shards according to the record routing mechanism, whereby the ordered shards perform ordered evidence storage, record querying, and record sequence querying.

[0094] The application layer provides unordered and ordered evidence storage services for cross-entity data circulation scenarios, supporting applications such as government data circulation and trusted data aggregation.

[0095] Specifically, the graph ledger module implements an unordered evidence storage method based on graph-structured random sharding. It primarily addresses unordered evidence storage in cross-entity data flow scenarios, while also handling the final evidence storage in ordered evidence storage services. The graph ledger module supports two main interfaces for the protocol-layer unordered evidence storage service: record storage and record query. At the storage layer, the graph ledger module organizes blocks into a directed acyclic graph (DAG) and stores copies of different blocks on different nodes, forming a parallelized DAG structure. At the consensus layer, the graph ledger module uses a random sharding consensus algorithm, randomly selecting some nodes as shards for new block evidence storage each time a new block is generated.

[0096] The sequencing engine module is an implementation of a hierarchical sequencing consensus method based on unordered evidence storage. It provides ordered evidence storage services for cross-entity data circulation scenarios, grouping and ordering records according to sequencing identifiers. The sequencing engine module supports three main interfaces for the protocol layer's ordered evidence storage service: record storage, record query, and sequence query. At the storage layer, the sequencing engine uses sequence blocks to organize records and maintain their order relationships, and can convert sequence blocks one-to-one into ledger blocks. At the consensus layer, the sequencing engine adopts a hierarchical consensus structure, selecting nodes to form sequence shards for each sequencing identifier. These shards are responsible for sequencing records and generating sequence blocks, providing sharded sequencing consensus for the ordered evidence storage service. After sequence blocks are generated, the sequence shards transform them into a record set that the graph ledger module can process to complete the final evidence storage. At the protocol layer, the sequencing engine routes records to the corresponding sequence shards according to their sequencing identifiers for subsequent processing.

[0097] In this embodiment, based on the characteristics of the increasing demand for unordered evidence storage services and the dispersed demand for ordered evidence storage services in cross-entity data circulation scenarios, an evidence storage system for cross-entity data circulation, composed of an application end and a server end, is provided. By separating unordered evidence storage and ordered evidence storage, for unordered evidence storage records where the storage order does not need to be considered, a random sharding method with a graph structure is used to achieve high-performance parallel evidence storage for the large number of unordered evidence storage records generated in cross-entity data circulation scenarios, reducing network and storage pressure; at the same time, a separate ordered evidence storage is performed for the small number of ordered evidence storage records, providing a stable ordered evidence storage service. Thus, high-performance evidence storage for cross-entity data circulation scenarios is achieved.

[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0099] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of systems according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0100] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0101] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0102] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0103] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0104] The above provides a detailed description of a data storage system for cross-entity data circulation provided by this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data storage system for cross-entity data circulation, characterized in that, The evidence storage system includes an application terminal and a server terminal, and the server terminal includes a graph ledger module and a sequence engine module. The application provides data circulation services to the transaction entities and transmits the records generated by the data circulation to the server. The types of records include: unordered evidence records and ordered evidence records. The server determines the type of the record, calls the graph ledger module to perform unordered storage of the unordered evidence record according to the graph structure random sharding method, and calls the ordering engine module to perform ordered storage of the ordered evidence record according to the hierarchical ordering consensus method. The process of calling the ordering engine module to perform ordering and storage of the ordered evidence records according to the hierarchical ordering consensus method includes: The server sends the ordered evidence storage record to the sequencing engine module; After the number of ordered evidence records in the ordering engine module reaches the second quantity threshold and / or the time interval between ordering block creation reaches the second time threshold, the ordering engine module will package the received ordered evidence records into an ordering block according to the record order. The ordered blocks are converted into ledger blocks and transmitted to the graph ledger module, so that the graph ledger module performs unordered storage of the ledger blocks according to the random sharding method of the graph structure. The ledger blocks represent the record sequence of ordered storage records. The ordering engine module packages the received ordered evidence records into an ordered block according to the record order, including: The sequencing engine module detects whether there are associated sequencing fragments of the ordered evidence storage records; In the presence of the associated ordered shards, the ordered evidence record is sent to the associated ordered shards so that the associated ordered shards generate the ordered blocks based on ordered consensus; In the absence of the associated ordered shard, an associated ordered shard of the ordered evidence record is created based on the random sharding method, and the ordered evidence record is sent to the created associated ordered shard, so that the created associated ordered shard generates the ordered block based on the ordered consensus.

2. The evidence storage system according to claim 1, characterized in that, The graphical ledger module is invoked to perform unordered storage of the unordered evidence records according to the random sharding method of the graphical structure, including: The server sends the disordered evidence records to the graphical ledger module; After the number of unordered evidence records in the graphical ledger module reaches a first quantity threshold and / or the time interval between new block creations reaches a first time threshold, the graphical ledger module will package the received unordered evidence records into a new block. Multiple network nodes are randomly selected to form a shard, and the new block is saved to each network node of the shard. The new block and other blocks form a directed acyclic graph structure.

3. The evidence storage system according to claim 1, characterized in that, The graphical ledger module is equipped with a record query interface; Specifically, the application terminal is used to execute: transmitting the record ID to the server terminal, where the record ID is the record ID returned by the graph ledger module after completing the storage of the unordered evidence record; Specifically, the server is used to execute: calling the record query interface of the graphical ledger module based on the record ID to obtain the evidence record corresponding to the record ID.

4. The evidence storage system according to claim 1, characterized in that, The sequencing engine module is equipped with a record query interface and a sequence query interface; The application terminal is specifically used to perform: transmitting the record ID and / or sequence identifier to the server, wherein the record ID is the record ID returned by the sequence engine module after completing the storage of the ordered evidence record, and the sequence identifier is the sequence identifier carried in the ordered evidence record, or the sequence identifier is a new sequence identifier returned after completing the storage of the ordered evidence record. The server is specifically used to perform the following: calling the record query interface of the sequencing engine module based on the record ID and / or the sequencing identifier to obtain the evidence storage record corresponding to the record ID; and calling the sequence query interface of the sequencing engine module based on the sequencing identifier to obtain the evidence storage sequence record corresponding to the sequencing identifier.

5. The evidence storage system according to claim 1, characterized in that, A smart contract executor is deployed in the sequencing engine module; The smart contract executor processes the ordered evidence records in the associated ordered shards to keep each network node in the associated ordered shards in the same state.

6. The evidence storage system according to claim 5, characterized in that, The smart contract executor processes the ordered evidence records in the associated ordered shards, including: After the associated ordered shards generate the ordered block based on the ordered consensus, the smart contract executor reads the ordered evidence records in the ordered block one by one; The new state of the ordered block is obtained by using the method specified in the call read code represented by the ordered evidence record, the current state of the ordered block, the code of the method, and the parameters in the smart contract call. Write the new state of the ordered block to each network node of the associated ordered fragment.

7. The evidence storage system according to claim 1, characterized in that, The record includes a sequence identifier field; the server determines the type of the record, including: Determine whether the sequence identifier field of the record is empty; If the sequence identifier field of the record is empty, the record is identified as an unordered evidence record; If the sequence identifier field of the record is not empty, the record is identified as an ordered evidence record.

8. The evidence storage system according to claim 2, characterized in that, After a new block is generated, the graphical ledger module randomly selects multiple network nodes to form a new shard, and saves the new block to each network node of the new shard.

Images