COMPUTER-IMPLEMENTED METHOD FOR STORING DATA USING A DISTRIBUTED TRANSACTION DATABASE, COMPUTER PROGRAM PRODUCT, AND NETWORK

Abstract

In a computer-implemented method for storing data in a network of linked computing units (10, 20, 30, 40, 50, 60) using a distributed transaction database (GDB), a distributed transaction database (GDB) in the form of a distributed graph database formed using nodes is used, and data is stored in at least one node (N) of the graph database, wherein the node (N) is stored using a real sub-quantity of the computing units (10, 20, 30, 40, 50, 60) of the network. The computer program product can be loaded directly into a storage device of an electronic computing unit (10, 20, 30, 40, 50, 60) and has program means in order to early out the steps of the method when the program is ran in a computing unit. The network of linked computing units (10, 20, 30, 40, 50, 60) stores a distributed transaction database (GDB) in the form of a distributed graph database comprising nodes (N) in which data is stored according to such a method.

Claims

1. A computer-implemented method for storing data in a network of linked computing units using a distributed transaction database, the method comprising: generating the distributed transaction database in a form of a distributed graph database using a plurality of nodes; and storing the data in at least one node of the distributed graph database, wherein the at least one node is stored using a true subset of the linked computing units of the network.

2. The method of claim 1, wherein the data comprises transaction data of transactions of computing units of the network and wherein the true subset of the linked computing units comprises computing units that participate in the transactions of the transaction data.

3. The method of claim 1, wherein the node is part of a path of a graph of the distributed graph database formed with the node.

4. The method of claim 3, wherein the path forms a branch of the graph.

5. The method of claim 3, wherein the path forms a loop of the graph.

6. The method of claim 3, wherein the data stored in nodes of the path is transaction data of transactions of computing units of the network, that are assigned to an application.

7. The method of claim 1, wherein the data is stored in at least one node of the distributed graph database that includes multiple paths, the nodes of which are each stored by true subsets of linked computing units of the network, wherein the true subsets include an intersection that is different from the true subsets.

8. The method of claim 7, wherein the intersection is empty.

9. The method of claim 7, wherein the intersection is not empty.

10. A computer program product loaded directly into a non-transitory computer implemented storage medium of an electronic computing unit containing machine-readable instructions executable by the electronic computing unit, the machine-readable instructions comprising: generating a distributed transaction database in a form of a distributed graph database using a plurality of nodes; and storing data in at least one node of the distributed graph database, wherein the at least one node is stored using a true subset of a plurality of electronic computing units comprising at least the electronic computing unit.

11. A system comprising: a network of linked computing units configured to store a distributed transaction database (GDB) in a form of a distributed graph database, comprising nodes in which data is stored in at least one node of the distributed graph database, wherein the at least one node is stored using a true subset of the linked computing units of the network.

12. The system of claim 11, wherein the data comprises transaction data of transactions of the linked computing units of the network and wherein the true subset of the linked computing units comprises computing units that participate in the transactions of the transaction data.

13. The system of claim 11, wherein the node is part of a path of a graph of the distributed graph database formed with the node.

14. The system of claim 13, wherein, wherein the path forms a branch of the graph.

15. The system of claim 13, wherein the path forms a loop of the graph.

16. The system of claim 13, wherein the data stored in nodes of the path is transaction data of transactions of the linked computing units of the network, that are assigned to an application.

17. The system of claim 11, wherein the data is stored in at least one node of the distributed graph database that includes multiple paths, the nodes of which are each stored by true subsets of the linked computing units of the network, wherein the true subsets include have an intersection that is different from the true subsets.

18. The system of claim 17, wherein the intersection is empty.

19. The system of claim 17, wherein the intersection is not empty.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0036] FIG. 1 depicts a schematic view of a distributed transaction database in the form of a distributed graph database in a principle diagram according to an embodiment.

[0037] FIG. 2 depicts steps of the method schematically in a principle diagram according to an embodiment.

DETAILED DESCRIPTION

[0038] The distributed transaction database depicted in FIG. 1 is a distributed graph database GDB. The graph database GDB forms a distributed ledger. In the graph database GDB, data is entered in nodes N, that are connected to each other via edges. The edges represent cryptographic connections between the nodes N, that in the embodiment shown are hash values. In other embodiments that are not shown separately, other types of one-way functions or cryptographic keys may be used to link the nodes N.

[0039] The graph database GDB is formed with a graph G, that includes individual nodes N. The nodes N of the graph G are linked to each other by cryptographic methods that represent a consensus mechanism, in the embodiment shown, a “Proof of Work” or a “Proof of Stake”. Other consensus mechanisms may also be used in other embodiments that are not shown separately. The link is shown in FIG. 1 by arrows connecting the nodes N. The graph database GDB is designed to store data from supply chains. The graph G of the graph database GDB maps the internal structure of the supply chain, that has application-specific branches. Depending on the application case, for the different branches there are different units affected by the application, that is reflected in different computing units 10, 20, 30, 40, 50, 60 of the network that stores and thus operates the graph database GDB.

[0040] The computing units 10, 20 30, 40, 50, 60 in the context are computers operating as servers. In principle, in other embodiments, not shown separately, a computing unit 10, 20, 30, 40, 50, 60 may also be formed as a logical computing unit, that in turn is implemented via a distributed computer network, for example via a cloud network.

[0041] Storage by a computing unit 10, 20, 30, 40, 50, 60 means storage in a memory of the computing unit 10, 20, 30, 40, 50, 60, in this case a random-access memory. In other embodiments, not shown specifically, this may also refer to storage in a memory allocated to one of the computing units 10, 20 30, 40, 50, 60. In other embodiments, not shown specifically, that correspond to the embodiment shown, the memory may also be a data carrier, such as a hard disk or a cloud storage system assigned to the computing unit and linked to the computing unit 10, 20, 30, 40, 50, 60 for signal communication.

[0042] A root of the graph database GDB is shown in FIG. 1 as a node N located on the far left. This root contains only initialization data and configuration data of the network as well as administration data for further administration of the network 10, 20, 30, 40, 50, 60. Consequently, data stored in this node N is stored over a small subset of computing units 10 of the network 10, 20, 30, 40, 50, 60. The data of the node N is stored redundantly by the computing units 10 of the subset. The graph G branches progressively from this node N into two branches, that represent different use-case applications.

[0043] A first application case involves the subset of the computing units 10 and a further subset of the computing units 20, that in the embodiment shown in FIG. 1 forms the application case branching off at the top. A second application case involves the computing units 10, 30. Consequently, in the first application case, the nodes N are stored redundantly using the computing units 10, 20, in the second application case using the computing units 10, 30.

[0044] In both application cases, later in the procedure the computing units of a subset 40 are also involved, that, as shown in FIG. 1 moving rightwards, store transaction data in the nodes N and maintain copies of the nodes N.

[0045] In FIG. 1 right at the top, a private side-chain SC branches off from the graph G. The nodes N of the private side-chain SC only contain data of the computing units 20, 50, 60, whereas the data stored there no longer affects the computing units 10. As a result, data of the computing units 10 is not stored in the node N of the private side-chain. Instead, the nodes N of the private side-chain SC are only stored using the computing units 20, 50, 60.

[0046] After the application case for the private side-chain SC has been completed, the private side-chain SC is reunited with the rest of graph G.

[0047] Shown at the bottom is an example of a branch in which a branch GB branches downwards.

[0048] Although the branch GB also relates to transactions of the computing units 10, 30, so that the subset of the computing units 10, 30 that the branch GB relates to does not differ from the subset of the computing units 10, 30, from which the branch GB branches off. However, the branch GB forms a new application case, that by the branch GB is thus also represented in the structure of the graph G as a separate branch GB.

[0049] In the embodiment shown, the computing units 10 form consortium computing units 10, that store all nodes N of the graph G with the exception of the nodes N of the private side-chain SC.

[0050] By the method, data is stored in the nodes N of the graph G of the distributed graph database GDB. The method for storing the data in the nodes N is based on the branch GB of FIG. 1 as shown in FIG. 2: when a new node N of the graph G is available, the computing units 10, 30 that interact in a particular application case are first identified. This subset of the computing units 10, 30 therefore also place data in node N of the application case. The identification of this subset of the computing units 10, 30 takes place in step STE1.

[0051] The computing units 10, 30 of the subset in turn make their computing units 10, 30 available in order to store the node N of the graph G. A list of these computing units 10, 30, for example in the form of MAC addresses or IP addresses, is transmitted to all computing units 10, 30 of the subset. Each computing unit 10, 30 thus accepts a list of the computing units 10, 30 available for this application case in a step STE2.

[0052] Then, the computing units 10, 30 create a branch GB of node N, that is specific to this application case. Each computing device 10, 30 that places data into these nodes N transmits the data that it places to all computing devices 10, 30 of the subset, in a step STE3.

[0053] At the same time, a set of copies of data from all other computing devices 10, 30 is obtained from each computing device 10, 30 in a step STE4.

[0054] In addition, copies of the data stored in the nodes N of the branch GB are stored in the consortium computing devices 10—with the exception of the data of nodes N in private side-chains SC.

[0055] It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present embodiments. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims may, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent, and that such new combinations are to be understood as forming a part of the present specification.

[0056] While the present embodiments have been described above by reference to various embodiments, it may be understood that many changes and modifications may be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combinations of embodiments are intended to be included in this description.