EP3617978A1 - Distributed database system comprising a plurality of database instances and method for operating the same - Google Patents

Abstract

A distributed database system (1) with several database instances (10, 20) is proposed. A respective one of the plurality of database instances (10, 20) is formed by a number of node devices (12, 13, 14; 22, 23, 24), which are set up to jointly base one of several transaction books (11, 21) of the distributed database system (1) to manage. The distributed database system (1) is set up to confirm a transaction (4) to be confirmed by including it in the transaction book (11, 21) of one or more of the several database instances (10, 20). Here, the distributed database system (1) is set up to decide which of the plurality of database instances (10, 20) confirms the transaction (4). The application design can be simplified, and there can be an improved automated distribution of a transaction load of the distributed database system via the multiple database instances. A method and a computer program product for operating a distributed database system with multiple database instances are also proposed.

Description

The present invention relates to the field of distributed database systems, and more particularly, to a distributed database system with multiple database instances.

In a distributed database system, implemented with blockchain technology, for example, transactions without a clearing house or a special relationship of trust between the transaction partners or a clearing house can be processed transparently and tamper-proof based on a consensus between the transaction partners. A transaction data record can include or reference program code that is executed in the distributed database system when the transaction is confirmed (so-called "smart contract"). Such a distributed database system is suitable as a transparent, manipulation-protected IT infrastructure platform for controlling an industrial automation system.

When configuring a consensus rule of such a distributed database system, there is a trade-off situation between parameters such as transaction throughput and strength of manipulation protection. Distributed database systems with several differently configured database instances, which are also called main and side chains, are therefore known. It is the responsibility of a user or an entity external to the database system to decide which of the database instances a respective transaction to be confirmed should be made available for confirmation. For a particular type of transaction, this decision is therefore usually made in the design phase of the respective application, such as the industrial automation system.

Against this background, it is an object of the present invention to provide an improved distributed database system with multiple database instances.

Accordingly, a distributed database system with multiple database instances is proposed. A respective one of the several database instances is formed by a number of node devices which are set up to jointly manage one of several transaction books of the distributed database system based on consensus. The distributed database system is set up to confirm a transaction to be confirmed by adding one or more of the several database instances to the transaction book. Here, the distributed database system is set up to decide which of the several database instances is used to confirm the transaction to be confirmed.

In particular, the decision as to which of the plurality of database instances the transaction to be confirmed is left to the distributed database system alone.

The application design can thus advantageously be simplified and an improved and automated distribution of a transaction load to be handled by the distributed database system can take place over the multiple database instances.

The transaction book ("ledger") of a respective database instance of the distributed database system can be represented as a chain or path of confirmed blocks. In particular, a respective block comprises a number of transactions confirmed in the transaction book. The chaining can be formed by means of chaining checksums. A respective one of the number of node devices of the database instance can store a chain of confirmed blocks, which represents a consensus version of the transaction book of the database instance. In particular, the respective database instance can be a block chain or a block chain, such as a main chain or a side chain.

In the present case, a number means a number of one or more.

A respective database instance is in particular a distributed database instance.

“The database system is set up for this” is to be understood in particular to mean that the database system can have a means that is set up to implement the respective functionality. A respective means can be a means provided separately or centrally, such as a separate device or unit. Alternatively, the respective means can be implemented in a decentralized or distributed manner. In particular, the respective means can be implemented by functionality of one or more of the multiple database instances. More specifically, the respective means can be implemented by functionality of a respective node device of the plurality of node devices of the plurality of database instances.

A preferred mode of operation of a respective database instance is briefly explained. The number of node devices of a respective database instance can be managed jointly and consensus-based in particular in the following manner in the transaction book of the database instance:

A copy or representation of the transaction book of the respective database instance can be stored in the respective number of node devices. The transaction book comprises a chain of confirmed transactions. In particular, the transaction book comprises a chain of confirmed blocks, each confirmed block comprising a number of confirmed transactions.

If a transaction to be confirmed is provided to the database instance, the confirmation of the transaction to be confirmed can be made Transaction in the transaction book of the database instance takes place in particular as follows:

A block-forming node device of the number of node devices of the database instance can include the transaction to be confirmed in a block formed by it. The block-forming node device can check the transaction to be confirmed. The checking can in particular include the execution of a program code or smart contracts included in the transaction, which describes the transaction. If the check is successful, the block-forming node device can: secure the block formed against manipulation with a data block checksum; concatenate with a chaining checksum with the last confirmed block of the transaction book representation stored in the block-forming node device; provided with a proof value corresponding to the consensus rule, such as a proof-of-work, proof-of-stake; and provide the formed block as an unconfirmed block in the database instance.

To create the proof value, it may be necessary to use or keep a predetermined amount of resources, such as computing time, storage space or crypto tokens. This can serve as protection against subsequent manipulation.

Thereupon a plurality and preferably all of the number of node devices can check the unconfirmed block provided in the database. In particular, it can be checked whether the proof value corresponds to the consensus rule, whether the unconfirmed block can be linked to the representation of the transaction book stored in the verifying node device, whether the data block checksum is correct and whether the transactions to be confirmed contained in the unconfirmed block are valid same way as can be checked by the block forming device when forming the unconfirmed block. If the test is successful, the respective testing node device can activate the unconfirmed block attach the transaction book representation stored in it.

The consensus rule implemented by the node devices of the database instance and taken into account in the respective checking can be set up in such a way that, despite the absence of a clearing house and despite the fact that not all of the node devices of the distributed database system communicate directly with one another and / or trust one another can form a majority consensus in such a way that in the majority and preferably all of the node devices the same representation of the transaction book of the database instance is stored, which in the present case is referred to as the "consensus version of the transaction book" or, for simplicity, as "the transaction book".

“Provision in the database instance” with regard to an unconfirmed or confirmed transaction and / or an unconfirmed block means in particular that the unconfirmed transaction or unconfirmed block is transmitted to at least one of the node devices of the database instance. The provided transaction to be confirmed or the provided unconfirmed block can be transmitted directly, indirectly or in a peer-to-peer manner to the rest of the node devices of the same database instance.

Analogously to this, “providing to the distributed database system” or “providing the distributed database system” with regard to an unconfirmed or to be confirmed transaction means in particular that the unconfirmed or to be confirmed transaction is to at least one of the node devices of one of the database instances of the distributed database system is transmitted from where it is transmitted directly, indirectly or in a peer-to-peer manner to the other of the node devices of other of the database instances can and preferably all of the node devices of all of the database instances can be transmitted.

The transaction to be confirmed can in particular be an unconfirmed transaction provided to the distributed database system.

According to the proposal, the distributed database system makes the decision as to which of the several database instances the transaction to be confirmed is confirmed. In other words, the distributed database system decides in which one and / or in which of the several transaction books of the distributed database system the transaction to be confirmed is recorded as a confirmed transaction.

The decision can be made centrally or distributed or based on consensus. The decision can be made explicitly before the transaction to be confirmed is made available for confirmation based on the decision to the one or more of the multiple database instances. The decision can be made implicitly. Here, the transaction to be confirmed can be made available to a large number and preferably all of the multiple database instances, and the decision can be made implicitly with the confirmation or as a result of the confirmation of the transaction to be confirmed by the one or more database instances, as will be explained in more detail below becomes.

According to one embodiment, the distributed database system is set up to decide, depending on a state of the respective database instance, by which of the several database instances the transaction to be confirmed is confirmed.

The “state of the respective database instance” is to be understood in particular as an automatically measurable or otherwise determinable state that relates to the operation of the distributed one Database system or one or more of the multiple database instances affects.

The distributed database system can, for example, be set up to determine the state depending on a number of parameters, such as: number of transactions confirmed in a given past time period per time unit in a respective database instance; current memory size of the transaction book of a respective database instance; current or time-averaged transaction and / or computing load of the respective database instance and the like.

The decision based on the state can be made in such a way that the fastest possible confirmation, the best possible load distribution across the database instances, the most favorable distribution of the memory requirement of the respective database instance and the like can be achieved. This decision can also be made explicitly in advance or implicitly during or as a result of the confirmation.

In this way, an automated distribution of the transaction load can advantageously be implemented in the distributed database system.

According to a further embodiment, the distributed database system is set up to determine a computing load for each of the database instances and to decide that the transaction to be confirmed is confirmed by the one or more of the database instances with the lowest computing load.

The load of each database instance can be an average load or a peak load of the number of node devices of the database instance. The load can in particular be a computing load, a transaction load or the like.

The node devices of the database instance can regularly exchange load information with one another. Similarly, the multiple database instances can regularly exchange load information with one another. In this way, a respective node device and a respective database instance can have information about a load of its own as well as the other of the several database instances.

In particular, a respective one of the multiple database instances can be set up in such a way that it only confirms the transaction to be confirmed if the confirming database instance is the database instance with the lowest or one of the lowest loads among the multiple database instances.

Accordingly, an explicit decision can advantageously be made which balances the load in the distributed database system.

According to a further embodiment, the distributed database system is set up to decide, depending on one or more references to the transaction to be confirmed, by which of the plurality of database instances the transaction to be confirmed is confirmed.

A transaction to be confirmed can refer to past transactions (also referred to as "backward transaction"). For example, a crypto token transaction that transacts a crypto token from a sender wallet to a recipient wallet can refer to a past crypto token transaction in which the crypto token was transacted into the sender wallet for its authorization to transact the crypto token to document.

In particular, in order to check the transaction to be confirmed, it may therefore be necessary to call up or check past transactions. In certain cases, such as when there is no inter-chain or cross-database communication is provided, it may therefore be necessary for the transaction to be confirmed to be confirmed in a specific transaction book in which its withdrawals can be reversed.

The decision according to the present embodiment can be made implicitly when confirming that a database instance in which the reference of the transaction to be confirmed cannot be resolved (the related transaction is not in the transaction book of the database instance) cannot successfully check the transaction to be confirmed, while the database instance in which the back reference of the transaction to be confirmed can be resolved, the checking of the transaction to be confirmed is successful.

Accordingly, even in the case of an automated distribution of transactions to be confirmed over a plurality of database instances, those transactions which have to be confirmed in a specific one of the plurality of database instances can be confirmed in the correct database instance.

According to a further embodiment, the distributed database system is set up to only consider a particular database instance when deciding which of the plurality of database instances the transaction to be confirmed is valid if the database instance is specified by the transaction to be confirmed.

Accordingly, a transaction to be confirmed provided to the distributed database system can specify from which or which of the database instances it is to be confirmed.

For example, a critical transaction to be confirmed can only specify those database instances which have a predefined minimum level of manipulation protection, in order to advantageously avoid them within the scope of the automated one Load balancing in a database instance with insufficient protection against manipulation.

According to a further embodiment, the distributed database system is set up to decide, by means of an automatic, decentralized consensus-building between the several database instances, by which of the several database instances the transaction to be confirmed is confirmed.

In other words, an explicit decision about which of the database instances the transaction to be confirmed that is made before the confirmation is confirmed can be dispensed with. Rather, a competitive situation can be created between the database instances in which a consensus, which confirms the transaction to be confirmed, is automatically established.

For example, a condition for the validity of a transaction or a block to be checked within the framework of the consensus rule of a respective database instance is that the transaction, in order to be confirmed as valid, must not yet be confirmed in any other of the database instances. This can be verified, for example, by inter-chain communication.

A self-regulating distribution of the transaction load over several database instances can thus advantageously be realized.

According to a further embodiment, the distributed database system is set up to hold a number of unconfirmed transactions. A respective one of the multiple database instances is set up to select and confirm the transaction to be confirmed from the number of unconfirmed transactions held. Here, the distributed database system is set up to remove the transaction to be confirmed from the number of unconfirmed transactions as soon as a defined number of Database instances has confirmed the transaction to be confirmed.

The unconfirmed transaction can be a transaction that has been made available to the database system and is to be confirmed by the database system. The term "unconfirmed transaction" is used in particular to refer to a transaction for which it has not yet been decided which of the database instances it confirms, while the term "transaction to be confirmed" is used in particular to refer to a transaction or an instance or copy Identify a transaction selected by a database instance to confirm.

In this context, “to be held” is to be understood in particular to mean that a pool (a held number) of the unconfirmed transactions is held in a central or decentralized storage means in such a way that each of the database instances (each of the node devices of each of the database instances) has access to them. A decentralized storage means can be understood, for example, to mean that an instance of the pool of unconfirmed transactions is stored at least one, preferably each, of the node devices of each of the database instances and information about the addition or removal of a transaction from the pool to peer-to-peer -Ways or the like are exchanged between the node devices of the database instances.

The defined number of database instances that the transaction to be confirmed has confirmed, from which the transaction to be confirmed is removed from the pool of the unconfirmed transaction, can be a predefined number and can be one or more. The defined number can be defined depending on the type, such as a given level of manipulation protection or the like, of the confirming database instance. For example, the transaction to be confirmed can either be from the number of unconfirmed stocks Transaction are removed as soon as the transaction to be confirmed is confirmed by a main chain, or as soon as the transaction to be confirmed is confirmed by several side chains.

By maintaining the pool of unconfirmed transactions, from which the transaction to be confirmed is removed if it has been confirmed enough times, automatic decentralized consensus-building between the several database instances can take place particularly advantageously, by means of which of the several database instances the transaction to be confirmed is confirmed .

According to a further embodiment, the defined number of database instances can be defined by the transaction to be confirmed.

Accordingly, the defined number of database systems by which the transaction to be confirmed is confirmed before it is removed from the pool of held unconfirmed transactions can be defined or specified by the transaction.

This decision can thus advantageously be left to an application designer depending on the type of transaction to be provided and need not be predefined in the distributed database system.

According to a further embodiment, a consensus rule of a respective one of the database instances is set up in such a way that remuneration for confirming the transaction to be confirmed is only given a number of times specified by the transaction to be confirmed.

Accordingly, an incentive to confirm a transaction may be lost once the transaction has been assigned the specified number of times. Thus, it can also be advantageously chosen by an application designer by suitable selection the remuneration and the specified number of times are implicitly specified by how many database instances the transaction to be confirmed is to be confirmed.

According to a further embodiment, the database system is set up to synchronize the transaction books of the plurality of database instances with one another at predefined time intervals.

For example, a respective status, which is defined by the sequence of transactions in the transaction book of the respective database instance, can be synchronized between the database instances at predefined time intervals.

The predefined time interval can, for example, be predefined by the time interval which, according to the consensus rule of those of the database instances with the lowest block formation rate, elapses on average between the formation of one or a number of blocks. It should be noted that the predefined time interval can be an average value, which results in the statistical average, and the time intervals between two respective synchronization can vary.

Such a regular synchronization between the several database instances can advantageously achieve that a new transaction to be confirmed, which is provided after one of the synchronizations and contains a reference that relates to a transaction before the synchronization, while maintaining the reference in any one which can be confirmed by several database instances. In this embodiment, a back-to-be-confirmed transaction is confirmed in a specific database instance, for example, if a back-reference of the transaction to be confirmed relates to a back-to-back transaction that was confirmed after the last synchronization in the past; otherwise, a back-referenced transaction can also be confirmed in any of the database instances.

According to a further embodiment, the plurality of database instances are set up to verify that the transaction to be confirmed is referenced back across the database instances when the transaction to be confirmed is confirmed by one of the plurality of database instances.

This can be achieved, for example, by means of cross-database communication or inter-chain communication. In other words, a respective node device of each of the database instances can have at least read access to the transaction books of all of the other database instances.

Accordingly, each transaction to be confirmed can advantageously be confirmed in each of the transaction books, since any existing back references to the transaction to be confirmed can be resolved across database instances. This can further improve the balanced distribution of the transaction load.

According to a further embodiment, the transaction book of one of the plurality of database instances is a general ledger and the transaction book of a respective further of the plurality of database instances is a respective page book cryptographically linked to the general ledger.

The cryptographic link can be achieved, for example, by confirming a hash value of a current status of the page book in the general ledger at predetermined time intervals.

Thus, even if a respective page book has weaker protection against manipulation than the general ledger based on the consensus rule of the associated database instance, the page book can nevertheless benefit in the long term from the higher protection against manipulation of the general ledger.

According to a further embodiment, the distributed database system is set up to confirm the transaction to be confirmed either in the general ledger or in a number of the side books.

In other words, a single confirmation in the general ledger may be sufficient, whereas in the case of a confirmation in the subledger, multiple confirmations may be required.

In this way, tamper protection of the confirmed transaction can advantageously be improved by repeatedly confirming the transaction to be confirmed in several page books even if the transaction to be confirmed is not confirmed in the general ledger. If, on the other hand, the transaction to be confirmed is confirmed in the general ledger, this can be regarded as sufficient and resources for multiple confirmations in further transaction books can be saved in this case.

The respective unit, for example a node device, database system and / or distributed database system, can be implemented in terms of hardware and / or software. In the case of a hardware implementation, the respective unit can be designed as a device or as part of a device, for example as a computer or as a microprocessor or as a control computer. In the case of a software implementation, the respective unit can be designed as a computer program product, as a function, as a routine, as part of a program code or as an executable object.

Furthermore, a computer program product is proposed, which causes the method as explained above to be carried out on a program-controlled device.

A computer program product, such as a computer program means, can, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or also in the form of a downloadable file provided or delivered from a server on a network. This can be done, for example, in a wireless communication network by transmitting a corresponding file with the computer program product or the computer program means.

According to a further aspect, a method for operating a distributed database system with several database instances is proposed. A respective one of the several database instances is formed by a number of node devices, which are set up to jointly manage one of several transaction books of the distributed database system based on consensus. The method comprises confirming a transaction to be confirmed by adding one or more of the multiple database instances to the transaction book, the distributed database system deciding which of the multiple database instances to confirm the transaction to be confirmed.

The embodiments and features described for the proposed distributed database system apply accordingly to the proposed method.

Further details and further variants of distributed database systems based on block chain technology, to which the proposed solution is applicable, are explained below.

Unless otherwise stated in the description below, the terms "perform", "calculate", "computer-aided", "calculate", "determine", "generate", "configure", "reconstruct" and the like preferably refer to Actions and / or processes and / or processing steps that change and / or generate data and / or convert the data into other data, the data being represented or may be present in particular as physical quantities, for example as electrical impulses. In particular, the term "computer" should be as possible be broadly designed to cover in particular all electronic devices with data processing properties. Computers can thus be, for example, personal computers, servers, programmable logic controllers (PLC), handheld computer systems, pocket PC devices, mobile radio devices and other communication devices which can process data with the aid of computers, processors and other electronic devices for data processing.

In the context of the invention, “computer-aided” can be understood to mean, for example, an implementation of the method in which, in particular, a processor executes at least one method step of the method.

In the context of the invention, a processor can be understood to mean, for example, a machine or an electronic circuit. A processor can in particular be a main processor (English: Central Processing Unit, CPU), a microprocessor or a microcontroller, for example an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. . A processor can also be, for example, an IC (Integrated Circuit), in particular an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), or a DSP (digital signal processor) or a graphics processor GPU (Graphic Processing Unit). A processor can also be understood to mean a virtualized processor, a virtual machine or a soft CPU. It can also be a programmable processor, for example, which is equipped with configuration steps for executing the method according to the invention or is configured with configuration steps such that the programmable processor executes the inventive methods Features of the method, the component, the modules or other aspects and / or partial aspects of the invention are realized.

A “storage unit”, a “storage module” and the like can be understood in connection with the invention, for example, to be volatile memory in the form of random access memory (RAM) or permanent storage such as a hard disk or a data carrier.

In the context of the invention, a “module” can be understood to mean, for example, a processor and / or a storage unit for storing program instructions. For example, the processor is specifically designed to execute the program instructions in such a way that the processor executes functions in order to implement or implement the method according to the invention or a step of the method according to the invention. A module can, for example, also be a node of the distributed database system, which, for example, realizes the specific functions / features of a corresponding module. The respective modules can for example also be designed as separate or independent modules. For this purpose, the corresponding modules can include further elements, for example. These elements are, for example, one or more interfaces (e.g. database interfaces, communication interfaces - e.g. network interface, WLAN interface) and / or an evaluation unit (e.g. a processor) and / or a storage unit. For example, data can be exchanged using the interfaces (e.g. received, transmitted, sent or made available). By means of the evaluation unit, data can be compared, checked, processed, assigned or calculated, for example in a computer-assisted and / or automated manner. By means of the storage unit, data can be stored, accessed or made available, for example, in a computer-assisted and / or automated manner.

Under "include", particularly in relation to data and / or information, may be in connection with the invention, for example a (computer-aided) storage of corresponding information or a corresponding date in a data structure / data record (which, for example, is in turn stored in a storage unit) can be understood.

“Assign”, in particular with regard to data and / or information, can be understood in connection with the invention, for example, to be a computer-assisted assignment of data and / or information. For example, a first date is assigned a second date using a memory address or a unique identifier (UID), in which e.g. B. the first date is stored together with the memory address or the unique identifier of the second date together in a data record.

In the context of the invention, “providing”, in particular with regard to data and / or information, can be understood to mean, for example, computer-assisted provision. The provision takes place, for example, via an interface (for example a database interface, a network interface, an interface to a storage unit). Corresponding data and / or information can be transmitted and / or sent and / or called up and / or received via this interface, for example when it is made available.

In connection with the invention, “provide” can also be understood to mean, for example, loading or storing, for example a transaction with corresponding data. This can be done, for example, on or from a memory module. “Provision” can also be understood to mean, for example, a transmission (or a transmission or a transmission) of corresponding data from one node to another node of the block chain or of the distributed database system (or its infrastructure).

In connection with the invention, a “smart contract process” can be understood in particular to mean executing a program code (for example the control commands) in a process by the distributed database system or its infrastructure.

A "checksum", for example a data block checksum, a data checksum, a node checksum, a transaction checksum, a chaining checksum or the like, can be understood in connection with the invention, for example, to be a cryptographic checksum or cryptographic hash or hash value, in particular by means of a cryptographic Hash function via a data record and / or data and / or one or more of the transactions and / or a partial area of a data block (e.g. the block header of a block of a block chain or data block header of a data block of the distributed database system or only a part of the Transactions of a data block) are formed or calculated. A checksum can in particular be a checksum or hash value (s) of a hash tree (e.g. Merkle tree, Patricia tree). Furthermore, this can in particular also be understood to mean a digital signature or a cryptographic message authentication code. Using the checksums, for example, cryptographic protection / manipulation protection for the transactions and the data (records) stored therein can be implemented on different levels of the database system. For example, if a high level of security is required, the checksums are generated and checked at the transaction level. If less security is required, the checksums are generated and checked at the block level (e.g. over the entire data block or only over part of the data block and / or part of the transactions).

In the context of the invention, a “data block checksum” can be understood to mean a checksum which is calculated, for example, over part or all of the transactions in a data block. A node can then, for example Check / determine the integrity / authenticity of the corresponding part of a data block using the data block checksum. Additionally or alternatively, the data block checksum can in particular also have been formed via transactions of a previous data block / predecessor data block of the data block. The data block checksum can in particular also be implemented by means of a hash tree, for example a Merkle tree [1] or a Patricia tree, the data block checksum in particular the root checksum of the Merkle tree or a Patricia tree or one binary hash tree. In particular, transactions are secured by means of further checksums from the Merkle tree or Patricia tree (e.g. using the transaction checksums), the further checksums in particular being leaves in the Merkle tree or Patricia tree. The data block checksum can thus secure the transactions, for example, by forming the root checksum from the further checksums. The data block checksum can be calculated in particular for transactions of a specific data block of the data blocks. In particular, such a data block checksum can be included in a subsequent data block of the specific data block in order to chain this subsequent data block, for example, with its previous data blocks and, in particular, thereby to make it possible to check the integrity of the distributed database system. As a result, the data block checksum can, for example, take over the function of the chaining checksum or be included in the chaining checksum. The header of a data block (e.g. a new data block or the data block for which the data block checksum was formed) can comprise the data block checksum, for example.

“Transaction checksum” can be understood in connection with the invention as a checksum that is formed in particular via a transaction of a data block. In addition, a calculation of a data block checksum for a corresponding data block can be accelerated, for example, since calculations for this have already been calculated Transaction checksums as sheets z. B. a Merkle tree can be used.

In the context of the invention, a "chaining checksum" can be understood to mean a checksum which in particular indicates or references a respective data block of the distributed database system to the previous data block of the distributed database system (frequently referred to in the specialist literature as "previous block hash") [1 ]. For this purpose, a corresponding chaining checksum is formed, in particular for the corresponding previous data block. For example, a transaction checksum or the data block checksum of a data block (that is, an existing data block of the distributed database system) can be used as the chaining checksum in order to chain a new data block with an (existing) data block of the distributed database system. However, it is also possible, for example, for a checksum to be formed via a header of the previous data block or over the entire previous data block and to be used as a chaining checksum. This can also be calculated for several or all of the previous data blocks, for example. It is also possible, for example, for the chaining checksum to be formed via the header of a data block and the data block checksum. However, a respective data block of the distributed database system preferably comprises a chaining checksum, which was calculated for a previous data block, in particular even more preferably the directly preceding data block, of the respective data block or refer to it. For example, it is also possible for a corresponding chaining checksum to be formed only over part of the corresponding data block (for example, previous data block). In this way, for example, a data block can be realized which comprises an integrity-protected part and an unprotected part. This could be used, for example, to implement a data block whose integrity-protected part cannot be changed and whose unprotected part can also be changed later. Under In this case, integrity-protected means in particular that a change in integrity-protected data can be determined by means of a checksum.

The data, which are stored, for example, in a transaction of a data block, can in particular be provided in different ways. Instead of the data, e.g. B. User data such as measurement data, measurement values, control values, or data / ownership relationships to assets, for example, a transaction of a data block can only include the checksum for this data. The corresponding checksum can be implemented in different ways. This can e.g. B. a corresponding data block checksum of a data block (with the corresponding data) of another database or the distributed database system, a transaction checksum of a data block with the corresponding data (of the distributed database system or another database) or a data checksum that was formed over the data.

In addition, the corresponding transaction can include a reference or an indication of a storage location (e.g. an address of a file server and details of where the corresponding data can be found on the file server; or an address of another distributed database which comprises the data) . The corresponding data could then, for example, also be provided in a further transaction of a further data block of the distributed database system (for example if the corresponding data and the associated checksums are contained in different data blocks). However, it is also conceivable, for example, that this data is made available via another communication channel (eg via another database and / or a cryptographically secured communication channel).

In addition to the checksum, for example, an additional data record (for example a reference or information on a storage location) can also be stored in the corresponding transaction, which in particular indicates a storage location where the data is retrieved can be. This is particularly advantageous in order to keep the data size of the block chain or the distributed database system as small as possible.

In the context of the invention, “security-protected” can be understood to mean, for example, protection that is implemented in particular by a cryptographic method. For example, this can be implemented by using the distributed database system for the provision or transmission or transmission of corresponding data / transactions. This is preferably achieved by a combination of the different (cryptographic) checksums, in particular by synergistically interacting, for example to improve the security or the cryptographic security for the data of the transactions. In other words, "security-protected" in connection with the invention can also be understood to mean "cryptographically protected" and / or "manipulation-protected". "Tamper-proof" can also be referred to as "integrity-protected".

In the context of the invention, “linking the / of data blocks of a distributed database system” can be understood, for example, to mean that data blocks each comprise information (for example, chaining checksum) which refer to another data block or several other data blocks of the distributed database system or these refer to [1] [4] [5].

“Inserting into the distributed database system” and the like can be understood in connection with the invention, for example, that in particular a transaction or the transactions or a data block with its transactions is transmitted to one or more nodes of a distributed database system. If, for example, these transactions are successfully validated (e.g. by the node (s)), these transactions are distributed in particular as a new data block with at least one existing data block Database system concatenated [1] [4] [5]. For this purpose, the corresponding transactions are stored in a new data block, for example. In particular, this validation and / or chaining can be carried out by a trustworthy node (for example a mining node, a block chain oracle or a block chain platform). In particular, a block chain platform can be understood to mean a block chain as a service, as is proposed in particular by Microsoft or IBM. In particular, a trustworthy node and / or a node can each store a node checksum (e.g. a digital signature) in a data block (e.g. in the data block they validated and generated, which is then linked), in particular to enable the creator of the data block to be identified and / or to enable the node to be identified. This node checksum indicates which node, for example, has linked the corresponding data block to at least one other data block of the distributed database system.

In connection with the invention, “transaction” or “transactions” can be understood to mean, for example, a smart contract [4] [5], a data structure or a transaction data record, which in particular comprises one of the transactions or several transactions. In the context of the invention, “transaction” or “transactions” can also be understood to mean, for example, the data of a transaction in a data block of a block chain. In particular, a transaction can include a program code that, for example, implements a smart contract. For example, in the context of the invention, a transaction can also be understood to mean a tax transaction and / or confirmation transaction. Alternatively, a transaction can be, for example, a data structure that stores data (e.g. the control commands and / or contract data and / or other data such as video data, user data, measurement data, etc.). In particular, “storing transactions in data blocks”, “storing transactions” and the like is understood to mean direct storage or indirect storage. Direct storage can be understood, for example, to mean that the corresponding data block (of the distributed database system) or the corresponding transaction of the distributed database system) comprises the respective data. Indirect storage can be understood here, for example, to mean that the corresponding data block or the corresponding transaction comprises a checksum and optionally an additional data record (for example a reference or an indication of a storage location) for corresponding data and therefore does not include the corresponding data directly in the data block (or the transaction) are stored (i.e. instead only a checksum for this data). In particular, when storing transactions in data blocks, these checksums can be validated, for example, as is explained, for example, under "inserting into the distributed database system".

In the context of the invention, a “program code” (for example a smart contract) can be understood to mean, for example, one program command or several program commands, which are stored in particular in one or more transactions. The program code can be executed in particular and is executed, for example, by the distributed database system. This can be implemented, for example, using an execution environment (for example a virtual machine), the execution environment or the program code preferably being Turing-complete. The program code is preferably executed by the infrastructure of the distributed database system [4] [5]. For example, a virtual machine is implemented through the infrastructure of the distributed database system.

A "smart contract" can be understood in connection with the invention, for example, to be an executable program code [4] [5] (see in particular the definition "program code"). The smart contract is preferably stored in a transaction of a distributed database system (e.g. a block chain), for example in a data block of the distributed database system. For example, the smart contract can be executed in the same way as explained in the definition of "program code", in particular in connection with the invention.

In connection with the invention, “proof-of-work” or “proof-of-work proof” can be understood to mean, for example, solving a computation-intensive task that is to be solved in particular depending on the data block content / content of a specific transaction [1 ] [4] [5]. Such a computationally intensive task is also referred to as a cryptographic puzzle, for example.

Under a "distributed database system", which can also be referred to as a distributed database, for example, in connection with the invention, a decentrally distributed database, a block chain (English blockchain), a distributed ledger, a distributed storage system, a distributed ledger technology ( DLT) based system (DLTS), an audit-proof database system, a cloud, a cloud service, a block chain in a cloud or a peer-to-peer database. Different implementations of a block chain or a DLTS, for example, can also be used. B. a block chain or a DLTS using a Directed Acylic Graph (DAG), a cryptographic puzzle, a hash graph or a combination of the implementation variants mentioned [6] [7]. Different consensus rules or consensus algorithms can also be implemented, for example. This can be, for example, a consensus procedure using a cryptographic puzzle, Gossip about Gossip, Virtual Voting or a combination of the above-mentioned procedures (e.g. Gossip about Gossip combined with Virtual Voting) [6] [7]. If, for example, a block chain is used, this can in particular be based on a bitcoin Realization or an Ethereum-based realization can be implemented [1] [4] [5]. A "distributed database system" can also be understood to mean, for example, a distributed database system, of which at least some of its nodes and / or devices and / or infrastructure are implemented by a cloud. For example, the corresponding components are implemented as nodes / devices in the cloud (e.g. as a virtual node in a virtual machine). This can be done using VM goods, Amazon Web Services or Microsoft Azure, for example. Due to the high flexibility of the implementation variants explained, in particular partial aspects of the implementation variants mentioned can be combined with one another, for example by B. a hash graph is used as a block chain, the block chain itself z. B. can also be blockless.

For example, if a Directed Acylic Graph (DAG) is used (e.g. IOTA or Tangle), transactions or blocks or nodes of the graph are connected to one another via directed edges. This means in particular that (all) edges (always) have the same direction, similar to e.g. B. is at time. In other words, it is in particular not possible to start or jump to the transactions or the blocks or the nodes of the graph backwards (ie against the same common direction). Acyclic means in particular that there are no loops when the graph is run through.

The distributed database system can be, for example, a public distributed database system (e.g. a public block chain) or a closed (or private) distributed database system (e.g. a private block chain).

If it is, for example, a publicly distributed database system, this means that new nodes and / or devices without distributed credentials or without authentication or without credentials or without credentials Database system can join or be accepted by this. In such a case, in particular, the operators of the nodes and / or devices can remain anonymous.

If the distributed database system is, for example, a closed, distributed database system, new nodes and / or devices need, for example, a valid proof of authorization and / or valid authentication information and / or valid credentials and / or valid login information in order to be able to join the distributed database system or from to be accepted.

A distributed database system can, for example, also be a distributed communication system for data exchange. This can be, for example, a network or a peer-2-peer network.

Under "data block", which can also be referred to as a "link" or "block", depending on the context and implementation, in connection with the invention, for example, a data block of a distributed database system (for example a block chain or a peer-to-peer) Peer database) can be understood, which is realized in particular as a data structure and preferably comprises one of the transactions or more of the transactions. In an implementation, for example, the database (or the database system) can be a DLT-based system (DLTS) or a block chain and a data block can be a block of the block chain or the DLTS. A data block can include, for example, information on the size (data size in bytes) of the data block, a data block header, a transaction counter and one or more transactions [1]. The data block header can include, for example, a version, a chaining checksum, a data block checksum, a time stamp, a proof-of-work proof and a nonce (one-time value, random value or counter used for the proof-of-work proof) [1] [4] [5]. A data block can, for example, only be a specific memory area or address area of the total data that is stored in the distributed database system. This allows, for example, blockless distributed database systems, such as. B. implement the IoT Chain (ITC), IOTA, and Byteball. In particular, the functionalities of the blocks of a block chain and the transactions are combined with one another in such a way that, for. B. the transactions themselves secure the sequence or chain of transactions (of the distributed database system) (in particular, they are stored in a security-protected manner). For this purpose, for example, the transactions themselves can be linked to one another with a chaining checksum, in that a separate checksum or the transaction checksum of one or more transactions is used as the chaining checksum, which is also saved in the corresponding new transaction when a new transaction is stored in the distributed database system. In such an embodiment, a data block can also include one or more transactions, for example, in the simplest case a data block corresponding to a transaction.

In the context of the invention, “nonce” can be understood to mean, for example, a cryptographic nonce (abbreviation for: “used only once” [2] or “number used once” [3]). In particular, a nonce denotes a combination of numbers or letters, which is preferably used once in the respective context (e.g. transaction, data transmission).

"Previous data blocks of a (certain) data block of the distributed database system" can be understood in connection with the invention, for example, the data block of the distributed database system which in particular directly precedes a (certain) data block. Alternatively, "previous data blocks of a (certain) data block of the distributed database system" can also be understood to mean, in particular, all data blocks of the distributed database system that precede the specific data block. In this way, for example, the chaining checksum or the transaction checksum can be formed in particular only via the data block (or its transactions) preceding the specific data block or via all data blocks (or its transactions) preceding the first data block.

Under a "block chain node", "node", "node of a distributed database system", "node device" and the like, in connection with the invention, for example, devices (e.g. field devices, mobile telephones), computers, smart phones, clients or participants are understood who perform operations (with) the distributed database system (e.g. a block chain) [1] [4] [5]. Such nodes can, for example, execute transactions of a distributed database system or their data blocks or insert or chain new data blocks with new transactions into the distributed database system by means of new data blocks. In particular, this validation and / or chaining can be carried out by a trustworthy node (for example a mining node) or exclusively by trustworthy nodes. A trustworthy node is, for example, a node that has additional security measures (for example firewalls, access restrictions to the node or the like) in order to prevent manipulation of the node. Alternatively or additionally, for example, when a new data block is concatenated with the distributed database system, a trustworthy node can store a node checksum (for example a digital signature or a certificate) in the new data block. In particular, it can be used to provide evidence that indicates that the corresponding data block was inserted by a specific node or indicates its origin. The devices (e.g. the corresponding device) are, for example, devices of a technical system and / or industrial system and / or an automation network and / or a production system, which in particular are also a node of the distributed database system. The devices can be field devices, for example or devices in the Internet of Things, which in particular are also a node of the distributed database system. Nodes can, for example, also comprise at least one processor in order to e.g. B. execute their computer-implemented functionality.

Under a "block chain oracle" and the like can be understood in connection with the invention, for example nodes, devices or computers that z. B. have a security module that is implemented, for example, by means of software protection mechanisms (e.g. cryptographic processes), mechanical protection devices (e.g. a lockable housing) or electrical protection devices (e.g. tamper protection or a protection system, that deletes the data of the security module in the event of improper use / treatment of the blockchain oracle). The security module can include, for example, cryptographic keys, which are necessary for the calculation of the checksums (e.g. transaction checksums or node checksums).

In the context of the invention, a “computer” or a “device” can include, for example, a computer (system), a client, a smart phone, a device or a server, each of which is arranged outside the block chain or no participant of the distributed one Database system (e.g. the block chain) (i.e. do not perform any operations with the distributed database system or only query them, but without carrying out transactions, inserting data blocks or calculating proof-of-work evidence). Alternatively, a computer in particular can also be understood to mean a node of the distributed database system. In other words, a device can be understood to mean in particular a node of the distributed database system or a device outside the block chain or the distributed database system. A device outside of the distributed database system can, for example, access the data (for example transactions or tax transactions) of the distributed database system and / or from nodes (for example by means of Smart contracts and / or blockchain oracles) can be controlled. If, for example, a device is activated or controlled (for example a device designed as a node or a device outside the distributed database system) by a node, B. by means of a smart contract, which is stored in particular in a transaction of the distributed database system.

Further possible implementations of the invention also include combinations of features or embodiments described above or below with reference to the exemplary embodiments that are not explicitly mentioned. The person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.

• Fig. 1 veranschaulicht schematisch ein verteiltes Datenbanksystem gemäß einem ersten Ausführungsbeispiel sowie ein Verfahren zum Betreiben desselben;
• Fig. 2 zeigt Details einer möglichen Ausgestaltung eines der Transaktionsbücher des verteilten Datenbanksystems;
• Fig. 3 veranschaulicht schematisch ein verteiltes Datenbanksystem und Aspekte seines Betriebs gemäß einem zweiten Ausführungsbeispiel.

Further advantageous refinements and aspects of the invention are the subject of the subclaims and the exemplary embodiments of the invention described below. The invention is explained in more detail below on the basis of preferred embodiments with reference to the attached figures.

• Fig. 1 schematically illustrates a distributed database system according to a first exemplary embodiment and a method for operating the same;
• Fig. 2 shows details of a possible embodiment of one of the transaction books of the distributed database system;
• Fig. 3 schematically illustrates a distributed database system and aspects of its operation according to a second embodiment.

In the figures, elements that are the same or have the same function have been provided with the same reference symbols, unless stated otherwise.

Fig. 1 schematically illustrates a distributed database system 1 according to a first exemplary embodiment and a method for operating the same.

The distributed database system 1 has a first database instance 10 and a second database instance 20. The first database instance 10 is formed by the node devices 12, 13 and 14. The second database instance 20 is formed by the node devices 22, 23, 24.

The node devices 12, 13, 14 of the first database instance 10 jointly and consensus-based manage the transaction book 11 of the distributed database system 1. The node devices 22, 23, 24 of the second database instance 20 jointly and consensus-based manage the transaction book 21 of the distributed database system 1.

When the distributed database system 1 is provided with a transaction 4 to be confirmed, in step S1 of the method for operating the distributed database system 1, the distributed database system 1 confirms the transaction 4 to be confirmed by converting the transaction 4 to be confirmed into one or both of the confirmed transactions Transaction books 11, 21 records.

In this case, the distributed database system 1 decides which of the plurality of database instances 10, 20 to confirm the transaction 4 to be confirmed. In other words, the distributed database system 1 decides whether the transaction 4 to be confirmed is recorded by the first database instance 10 in the transaction book 11 and / or by the second database instance 20 in the transaction book 21.

In particular, it goes without saying that the node devices 12, 13, 14, 22, 23, 24 are communicatively networked with one another in order to jointly implement the functionality described above.

In particular, it is further understood that the schematically represented transaction books 11, 21 are representations of a respective transaction book 11, 21 stored in a distributed manner in the distributed database system 1. In particular, a representation of the transaction book 11 can be stored on each of the node devices 12, 13, 14, wherein a consensus rule of the database instance 10 ensures that the respective representations are completely or substantially matched to one another, and on each of the node devices 22, 23, 24 A representation of the transaction book 21 can be stored, a consensus rule of the database instance 20 ensuring that the respective representations are matched to one another.

Fig. 2 shows details of a possible embodiment of one of the transaction books 11, 21 of the distributed database system 1 Fig. 1 Referred. The transaction book 11 of the database instance 10 is described by way of example, but the description also applies analogously to the transaction book 21 of the database instance 20.

The in Fig. 2 The section of the transaction book 11 shown according to the possible embodiment comprises three blocks 101, 102, 103. A respective block 101, 102, 103 each comprises a header data section K and a user data section N.

The header data section K of block 101 comprises a data block checksum 1014, a chaining checksum 1012 and a verification value 1011. Analogously to this, the header data sections K of blocks 102 and 103 each include a data block checksum 1024, 1034, a chaining checksum 1022, 1032 and a verification value 1021, 1031.

The user data section N of the respective block 101, 102, 103 each comprises a number of confirmed transactions, which are shown as rounded rectangles. One of the confirmed transactions bears the reference number 5 as an example.

The transactions 5 each include user data of the distributed database system 1. In particular, a respective transaction 5 can include data and / or program code (so-called smart contracts), which indicate a transition from a state that the transaction book 11 of the distributed database system 1 had to before the confirmation of the Transaction 5 describes, describes in a state that the transaction book 11 of the distributed database system 11 describes after the confirmation of the transaction 5. By gradually tracking the blocks 101, 102, 103 and the transactions 5 therein, the state described by the transaction book 11 can be transparently understood at every current and past point in time. Here, status can be understood to mean any type of data that can be reconstructed from a sequence of transactions. The entirety of all account balances in a number of addresses or cryptowallets defined in the database instance 10 may be mentioned purely by way of example. However, states such as control or switching states of actuators of an industrial automation system and the like are also conceivable, for example, a transaction representing a respective switching operation.

The respective data block checksum 1014, 1024, 1034 is in particular a cryptographic hash value which protects the transactions 5 of the respective block 101, 102, 103 against manipulation. In particular, the data block checksum 1014, 1024, 1034 can be a root value of a Merkle or Patricia hash tree.

The respective chaining checksum 1012, 1022, 1032 is a cryptographic hash value of the preceding block 101, 102. In particular, the chaining checksum 1022 is a cryptographic hash value of the entire block 101. The chaining hash value 1032 is a cryptographic hash value of the entire block 62. The respective chaining Hash value 1012, 1022, 1032 can define the order in which the blocks 101, 102, 103 are linked and can secure the transaction book 11 against manipulation. Would the 5 designated the If transactions 5 were subsequently manipulated, this would not only invalidate the data block checksum 1014, but also the chaining checksum 1022 and each subsequent chaining checksum 1032.

The respective proof value 1011, 1021, 1031 is a value that can be understood in such a way that it serves a legitimate interest of those of the account devices 12-14 that formed the respective block 101, 102, 103 (hereinafter "block-forming node device ") to document the inclusion of block 101, 102, 103 in the transaction book 11. The proof value 1011, 1021, 1031 is in particular set up in such a way that it can be verified in a verifiable manner a quantity of computing power (so-called proof-of-work) used by the block-forming node device 12-14, a quantity of crypto tokens held for a certain duration (so-called Proof-of-Stake), a lot of resources used elsewhere and / or an authorization such as a signature of a privileged ledger.

The confirmation of a transaction 4 to be confirmed by the database instance 10 can in particular proceed as described below. It is assumed that the in Fig. 2 block 103 shown at the beginning of the process is not yet part of the transaction book 11, that is, the transaction book 11 at the beginning of the process now described only consists of the confirmed blocks 101 and 102.

The block-forming node device, for example the node device 12, forms the block 103, which has not yet been confirmed, checks the transaction 4 to be confirmed for validity, accepts the transaction 4 to be confirmed or a copy thereof as a confirmed transaction in the unconfirmed block 103 , determines the data block checksum 1034 of the unconfirmed block 13, concatenates the unconfirmed block 103 with the last confirmed block 102 of the transaction book 11, for which purpose it links the chaining checksum 1032 of the unconfirmed block to the cryptographic hash value of the the last confirmed block 102 of the transaction book 11, and determines the proof value 1031 of the unconfirmed block 103. The unconfirmed block 103 thereby becomes the new last block 103 of the transaction book 11 in the representation of the transaction book 11 stored on the block-forming node device 12. If so If an unconfirmed block is successfully formed, the block-forming node device 12 makes the unconfirmed block 103 available to the other node devices 13, 14 of the same database instance 10. These check the unconfirmed block 103 and, if the check is successful, also add it to the representation of the transaction book 11 stored in them as the new last block 103 of the transaction book 11.

If there is a majority consensus in this way, block 103 in particular and all transactions stored therein are deemed to have been confirmed by database instance 10.

The mentioned checking processes can in particular include checking whether the transaction 4 to be confirmed of the unconfirmed block 103 describes a valid state transition. In this case, program code of a smart contract included or referenced by the transaction 4 to be confirmed can be executed. Furthermore, the mentioned checking processes can include a check of the data block checksum 1034 for correctness, the chaining checksum 1032 for correctness, and a check of the evidence value 1031 for compliance with the requirements of the consensus rule of the database instance 10.

In particular, the requirement of the consensus rule of the database instance 10 that a respective block 101, 102, 103 should contain such a proof value 1011, 1021, 1031 can make the formation of a correct block 101-103 corresponding to the consensus rule more difficult or more expensive. This can serve to protect against manipulation, since a subsequent modification of the transaction book 11 also results in a renewed resource-intensive process Determination of changed detection values 1011, 1021, 1031 may be necessary.

The possible embodiment was described on the basis of database instance 10 and transaction book 11, but applies analogously to database instance 20 and transaction book 21.

In view of the above, it becomes clear that the confirmation of the transaction 4 to be confirmed can be a computationally expensive process. In particular, the exact amount of computing effort for confirming a respective transaction 4 to be confirmed can be difficult to plan, since different transactions 4 to be confirmed can comprise smart contracts of different complexity.

A temporary overload situation with an excessive transaction load can therefore occur in one of the database instances 11, 12.

In the distributed database system 1 according to the possible embodiment, this is countered by the fact that the distributed database system 1 can decide to confirm the transaction 4 to be confirmed either in the transaction book 11 of the database instance 10 or in the transaction book 12 of the database instance 20.

Specifically, according to a development of the first exemplary embodiment, the node devices 12-14, 22-24 exchange status information with one another about the status of the respective database instances 10, 20. The status information can comprise any type of suitable status information, for example a computing power of a respective one of the node devices 12-14, 22-24 of the respective database instance 10, 20, a size of the respective transaction book 11, 21, an average transaction throughput of the respective database instance 10, 20 and the like.

Accordingly, each of the node devices 12-14, 22-24 can be informed of the current state of each of the database instances 11, 21. The node devices 12-14, 22-24 of the respective database instance 10, 20 can be set up to confirm the transaction 4 to be confirmed when the status information about the status of the database instance 10, 20 compared to the status information about the status of the other database instances 10, 20 fulfills a certain condition.

For example, only the node devices 12-14, 22-24 of the database instance 10, 20 can confirm the transaction 4 to be confirmed which has the lowest load, the smallest transaction book size, the lowest transaction throughput or the like among the database instances 10, 20.

Automatic load balancing can thus advantageously be implemented in the database instances 10, 20 according to the first exemplary embodiment.

In particular, it can be achieved that transactions are confirmed promptly, regardless of whether individual database instances 10, 20 are temporarily overloaded. Furthermore, a database system 1 with high resilience can be implemented. Transactions can be confirmed by the database system 1, even if one of the database instances 10, 20 has failed.

Fig. 3 schematically illustrates a distributed database system 1 and aspects of its operation according to a second exemplary embodiment.

The second exemplary embodiment is a development of the first exemplary embodiment, so that differences and additional features and configurations are primarily dealt with below in order to avoid redundant descriptions. The distributed database system 1 according to the second exemplary embodiment comprises three database instances 10, 20, 30. The respective associated node devices (cf. node devices 12-14, 22-24 in FIG Fig. 1 ) are in Fig. 3 not shown. Insofar as functionality of one of the database instances 10, 20, 30 is described below, this is to be understood in particular in such a way that this functionality can be implemented by the respective node devices (not shown) of the respective database instance 10, 20, 30.

Fig. 3 further illustrates the transaction books 11, 12, 13 of the database instances 10, 20 and 30 along an imaginary time axis running from left to right.

The first database instance 10 is a main chain, and the transaction book 11 of the first database instance 10 is accordingly a main ledger. The second and the third database instance 20, 30 are a respective side chain, and the transaction books 21, 31 of the respective side chain 20, 30 are accordingly a respective side ledger. ).

The general ledger 11 in particular has a higher protection against manipulation, but a lower degree of block formation than the side ledgers 21, 31. For example, an elaborate proof-of-work can be used in the database instance 10 for the general ledger 11 within the framework of the consensus rule, while in the database instances 20, 30 for the side books 21, 31, a faster-to-generate, but less secure, proof value is preferably used. For example, a trust-based privileged ledger approach is conceivable here.

As in Fig. 3 indicated, the side books 21, 31 are cryptographically linked several times to the general ledger 11. In particular, at the time block 101 is confirmed in the general ledger 11, a state represented by the general ledger 11 corresponds - such as a set of switching states, Account balances and the like - a state represented by each of the page books 21, 31. This common state is referred to below as the initial state. The transactions confirmed at a later point in time in blocks 201-204 of the first page book 21 continue to update the initial state by the state transitions described by the confirmed transactions. In other words, the first block 201 of the first page book 21 is generated by a (in Fig. 3 not shown) chaining checksum with the block 101 of the general ledger 11 cryptographically linked or linked. Likewise, the state transitions described in blocks 301-304 of the second page book 31 update the initial state. From the second point, where a respective first block 201, 301 has been confirmed in the page book 21 and the page book 31, the first updated state described by the first page book 21 thus differs from the second updated state described by the second page book 31. From this point in time, a transaction 4 to be confirmed, which refers back to the first updated state defined by the block sequence 101, 201 of the first page book 21, can no longer be readily confirmed in the second page book 31. For this reason, in a conventional architecture with several transaction books, each transaction to be confirmed must clearly specify in advance in which of the transaction books it is to be specified. According to the proposed solution, however, the database system 1 has at least a certain freedom of decision as to which of the side books 21, 31 or the general ledger 11 confirms a transaction 4. This is explained in more detail below.

A pool 40 of several unconfirmed transactions 41-45 can be maintained in the distributed database system 1. The respective unconfirmed transaction 41-45 can be written by an application that uses the central database system 1 into a central retention device (not shown) of the database system 1 or to any of the ones not shown Node devices of the Dantebank system 1 are transmitted and from there to the other (not shown) node devices of the database system 1 in a peer-to-peer manner. In other words, the pool 40 can be implemented centrally by means of the provision device or decentrally by means of peer-to-peer communication or the like between the node devices of the database system 1.

The distributed database system 1 successively selects one of the unconfirmed transactions 41-45 from the pool 40 as the current transaction 4 to be confirmed and confirms the respective transaction 4 to be confirmed in one or more of the transaction books 11, 21, 31.

The decision in which of the transaction books 11, 21, 31 the transaction 4 to be confirmed is confirmed can be made in several possible ways.

In a variant, each of the node devices of each of the database instances 10, 20, 30 can begin to form an unconfirmed block (not shown) in which the transaction 4 to be confirmed is included. However, a consensus rule of each of the database instances 10, 20, 30 can provide, inter alia, that a transaction 4 to be confirmed can only be regarded as valid if it has not already been confirmed in any of the transaction books 11, 21, 31 of the distributed database system 1. In this way, that of database instances 10, 20, 30 that can confirm transaction 4 to be confirmed most quickly can prevail.

In a further variant, a number of database instances 10, 20, 30 can be specified in a respective unconfirmed transaction 41-45 of the pool 40, in which the unconfirmed transaction 41-45 is to be confirmed. If one of the database instances 10, 20, 30 selects and confirms the respective unconfirmed transaction 41-45 as transaction 4 to be confirmed, it can specify the specified number of database instances decrement by one. If the number is decremented to zero, the unconfirmed transaction 41-45, which has been selected as transaction 4 to be confirmed, can be removed from the pool 40. In this way, the selected unconfirmed transaction 41-45 is no longer confirmed by any of the database instances 10, 20, 30.

Such multiple confirmation of a transaction 4 to be confirmed by a number of database instances 10, 20, 30 has the advantage that a particularly high level of protection against manipulation is achieved. Manipulation of a transaction in only one of the database instances 10, 20, 30 can be identified by comparing the plurality of database instances 10, 20, 30. Another advantage of the multiple confirmation can be that a reference to the transaction confirmed in several of the database instances 10, 20, 30 by future, subsequent transactions (not shown) in these multiple database instances 10, 20, 30 is possible. This achieves greater flexibility in which of the several database instances 10, 20, 30 the subsequent unconfirmed transaction can be confirmed.

In a further variant, the consensus rule of the respective database instance 10, 20, 30 can provide that a remuneration for confirming the transaction 4 to be confirmed can only be granted a number of times, which is specified in the respective transaction 4 to be confirmed, or that the remuneration is decremented with each confirmation of the transaction 4 to be confirmed in one of the transaction books 11, 21, 31. If the remuneration drops to zero, there is no longer any incentive for the node devices of further database instances 10, 20, 30 to confirm transaction 4 to be confirmed in further transaction books 11, 21, 31, and such further confirmation can be omitted.

In a third variant, the database instances 10, 20, 30 can provide information about their respective load situation (processing load of the individual node devices of the respective Database instance 10, 20, 30; Exchange transaction load of the respective database instance 10, 20, 30 or memory size of the respective transaction book 11, 21, 31 and the like) and be set up in such a way that from the start only that database instance 10, 20, 30 selects the transaction 4 to be confirmed that is currently valid has the lowest load.

In all of the variants described, an automatic, decentralized consensus can be formed between the several database instances in which of the database instances 10, 20, 30 the transaction 4 to be confirmed is confirmed.

Confirmation of the unconfirmed transactions 41-45 will now be described in detail.

The first transaction 41 is an oracle transaction. The oracle transaction 41 is in particular free of references to past confirmed transactions, rather the oracle transaction contains information about the real world, such as a measured value, which is to be made known in the distributed database system 1.

The unconfirmed oracle transaction 41 is confirmed by the distributed database system 1 both as a confirmed oracle transaction 511 in the first page book 21 and as a confirmed oracle transaction 512 in the second page book 22. The information about the real world is thus made known to each of the side books 21, 31.

Such confirmation of a transaction 4 to be confirmed in each of the page books 21, 31 can be, for example, the default behavior of the distributed database network 1 in oracle transactions. Alternatively, the oracle transaction 41 can explicitly specify that it is to be confirmed in exactly two or at least two transaction books 11, 21, 31.

Transaction 42 is a first crypto token transaction that transfers a set of crypto tokens to an address (also called "output"), such as 0x4EAC, of a crypto wallet. The transaction 42 specifies by means of specification data (not shown) included therein that the transaction 42 is to be confirmed in exactly one of the page books 21, 31, in order in this way to achieve faster processing than in the general ledger 11.

The unconfirmed first crypto token transaction 42 is processed by the distributed database system 1 based on a current load distribution of the database instances 21 and 31, for example, as in FIG Fig. 3 shown, confirmed in the second block 302 of the second page book 31. Depending on the current load distribution, it could alternatively also be confirmed in one of the blocks of the first page book 21. However, the unconfirmed first crypto token transaction 42 is not confirmed in the ledger 11. That is, the distributed database system 1 only takes into account the database instances 20, 30 that are to be confirmed when deciding which of the plurality of database instances 10, 20, 30 to confirm the transaction 4 (the unconfirmed crypto token transaction 42) Transaction 42 are specified.

Unconfirmed transaction 43 is a second crypto token transaction that transfers the amount of crypto tokens from address 0x4EAC to a second address 0x81F2. The transaction 43 therefore contains a reference to the confirmed transaction 52, which serves as proof that the sender address 0x4AEC (also called "unspent output") actually contains the amount of crypto tokens and has not been issued otherwise since then. The unconfirmed second crypto token transaction 43 also specifies that the unconfirmed transaction 43 is to be confirmed in exactly one of the page books 21, 31.

This reference of the unconfirmed transaction 43 to the confirmed transaction 52 can only be resolved in the second page book 31, in which the confirmed transaction 52 is included in block 302. This back reference is taken into account by the distributed database system 1 when confirming the unconfirmed transaction 43, and the unconfirmed transaction 43 is confirmed as the confirmed transaction 53 in the block 304 of the second transaction book 31.

The unconfirmed transaction 44 is a third unconfirmed crypto token transaction that transfers the amount of crypto tokens from the second address 0x81F2 to a third address 0x99EA and thus contains a direct reference to the confirmed transaction 53, which contains the presence of the crypto tokens at the sender address (second Address) 0x81F "and an indirect reference to the confirmed transaction 52, to which the confirmed transaction 53 refers.

In principle, therefore, the third unconfirmed crypto token transaction 44 would also have to be confirmed in the second transaction book 31, in which the related, confirmed transaction 53 is confirmed in block 304.

However, in order to better exploit the advantage of automated load distribution, the distributed database system 1 synchronizes the transaction books 11, 21, 31 of the plurality of database instances 10, 20, 30 at predefined time intervals. The predefined time intervals are, for example, due to the time intervals between the formation of one blocks 101, 102 of the general ledger 11.

Specifically, the block 102 of the general ledger 11 comprises a summary transaction 56, which is the state updated from the first page book 21 (the result of the processing of all transactions that take place in the first page book 21 in the time between the confirmation of the first block 101 of the general ledger 11 and confirming the second block 102 of the General ledger 11 have been confirmed) and a summarizing transaction 57 which defines the state updated from the second side book 31. Thus, by confirming the second block 102 in the general ledger 11, which comprises the summarizing transactions 56 and 57, a new common starting state of the general ledger 11, the first page book 21 and the second page book 31 is created.

The next block 205 of the page book 21 is therefore not cryptographically linked to the previous block 204 of the page book 21, but to the second block 102 of the general book 11. The same applies to the next block 305 of the page book 31.

Accordingly, the third unconfirmed crypto token transaction 44, the confirmation of which begins only after the confirmation of the block 102 of the general ledger 11, despite its reference to the transaction 53 confirmed in the second transaction book 31, can be confirmed in each of the page books 21, 31 and will, for example, as in Fig. 3 shown, now confirmed as the confirmed transaction 54 of the sixth block 206 due to a changed load situation in the first page book 21.

Thus, even in the case of unconfirmed transactions 43, 44 with references to a specific one of the transaction books 11, 21, 31, the distributed database system 1 can automatically distribute the load by confirming in another of the transaction books 11, 21, 31 at predefined time intervals.

The unconfirmed transaction 45 finally specifies that it may only be confirmed in the general ledger 11, for example due to increased security requirements. This is taken into account by the distributed database system 1, and the unconfirmed transaction 45 is confirmed as confirmed transaction 55 immediately in the second block 102 of the general ledger 11. This can also be understood to mean that the Proposed solution to leave the decision on the confirming database instance 10, 20, 30 to the distributed database system 1 can be overridden for certain unconfirmed transactions 45, provided this appears appropriate in the individual case.

Although the present invention has been described using exemplary embodiments, it can be modified in many ways.

Using the second exemplary embodiment, it was described that the states described by the respective transaction books 11, 21, 31 are synchronized with one another at predefined time intervals. However, it is also possible that the database instances 10, 20, 30 are set up for cross-database instance communication when confirming the respective transaction 4 to be confirmed. In other words, each of the node devices (in Fig. 3 (not shown) each of the database instances 10, 20, 30 have at least read access to each of the transaction books 11, 21, 31. Thus, at all times, the entirety of the transaction books 11, 21, 31 can represent a common state, which can be checked by each of the database instances 10, 20, 30 when the respective transaction 4 to be confirmed is confirmed. In this case, it may be possible to confirm each back-referenced transaction, such as the unconfirmed transactions 43, 44 in each of the transaction books 11, 21, 31, without the need to synchronize the multiple database instances 10, 20, 30 at predefined time intervals.

A greatly simplified, distributed database system 1 was described on the basis of the exemplary embodiments, and only the basic principles of the functioning of the block chain technology were touched upon. It goes without saying that the concept of the invention defined by the claims also applies to any further developments of distributed database systems and block chain databases with several transaction books is applicable, in particular also to those as mentioned in references [1] to [8].

The invention can be generally understood to the effect that it is at least partially left to a distributed database system 1 in which a transaction 4 to be confirmed is confirmed by several transaction books 11, 21, 31 of the distributed database system 1.

credentials

• [1]
  Andreas M. Antonopoulos "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", O'Reilly Media, December 2014
• [2]
  Roger M. Needham, Michael D. Schroeder "Using encryption for authentication in large networks of computers" ACM: Communications of the ACM. Volume 21, No. 12 December 1978 .
• [3]
  Ross Anderson "Security Engineering. A Guide to Building Dependable Distributed Systems" Wiley, 2001
• [4]
  Henning Diedrich "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations", CreateSpace Independent Publishing Platform, 2016
• [5]
  " The Ethereum Book Project / Mastering Ethereum "https://github.com/ethereumbook/ethereumbook, as of October 5, 2017
• [6]
  Leemon Baird "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance", Swirlds Tech Report SWIRLDS-TR-2016-01, May 31, 2016
• [7]
  Leemon Baird "Overview of Swirlds Hashgraph", May 31, 2016
• [8th]
  Blockchain Oracle
  https://blockchainhub.net/blockchain-oracles/

Claims (15)

Distributed database system (1) with several database instances (10, 20),
wherein a respective one of the plurality of database instances (10, 20) is formed by a number of node devices (12, 13, 14; 22, 23, 24) which are set up to jointly consensus-based one of a plurality of transaction books (11, 21) of the distributed database system (1) manage
wherein the distributed database system (1) is set up to confirm a transaction (4) to be confirmed by including it in the transaction book (11, 21) of one or more of the plurality of database instances (10, 20),
the distributed database system (1) being set up to decide which of the plurality of database instances (10, 20) confirms the transaction (4) to be confirmed. Distributed database system according to claim 1,
characterized,
that the distributed database system (1) is set up to decide depending on a state of the respective database instance (10, 20), by which of the several database instances (10, 20) the transaction (4) to be confirmed is confirmed. Distributed database system according to claim 1 or 2
characterized,
that the distributed database system (1) is set up to determine a load for each of the database instances (10, 20) and to decide that the transaction (4) to be confirmed by the one or more of the database instances (10, 20) the lowest load is confirmed. Distributed database system according to one of claims 1 to 3,
characterized,
that the distributed database system (1) is set up to decide, depending on one or more references to the transaction (4) to be confirmed, by which of the plurality of database instances (10, 20, 30) the transaction (4) to be confirmed is confirmed. Distributed database system according to one of claims 1 to 4,
characterized,
that the distributed database system (1) is set up to only take into account a respective database instance (10, 20, 30) when deciding which of the several database instances to confirm the transaction (4) if the database instance (10, 20, 30) is specified by the transaction (4) to be confirmed. Distributed database system according to one of claims 1 to 5,
characterized,
that the distributed database system (1) is set up to decide, by means of an automatic, decentralized consensus formation between the several database instances (10, 20, 30), by which of the several database instances (10, 20, 30) confirms the transaction (4) to be confirmed becomes. Distributed database system according to one of claims 1 to 6,
characterized,
that the distributed database system (1) is set up to maintain a number (40) of unconfirmed transactions (41-45),
wherein a respective one of the plurality of database instances (10, 20, 30) is set up to select and confirm the transaction to be confirmed from the number (40) of unconfirmed transactions (41-45) held,
the distributed database system (1) being set up to remove the transaction (4) to be confirmed from the number (40) of unconfirmed transactions (41-45) held, as soon as a defined number of database instances (10, 20, 30) has confirmed the transaction (4) to be confirmed. Distributed database system according to claim 7,
characterized,
that the defined number of database instances (10, 20, 30) can be defined by the transaction (4) to be confirmed. Distributed database system according to one of claims 1 to 8,
characterized,
that a consensus rule of a respective one of the database instances (10, 20, 30) is set up in such a way that remuneration for confirming the transaction (4) to be confirmed is only given a number of times specified by the transaction (4) to be confirmed. Distributed database system according to one of claims 1 to 9,
characterized,
that the database system (1) is set up to synchronize the transaction books (11, 21, 31) of the plurality of database instances (10, 20, 30) with one another at predefined time intervals. Distributed database system according to one of claims 1 to 10,
characterized,
that the plurality of database instances (10, 20, 30) are set up to verify a back reference of the transaction (4) to be confirmed across database instances when the transaction to be confirmed is confirmed by one of the plurality of database instances (10, 20, 30). Distributed database system according to one of claims 1 to 11,
characterized,
that the transaction book (11) of one of the plurality of database instances 10) is a general ledger and the transaction book (21, 31) of a respective further one of the plurality of database instances (20, 30) is a respective side book (21, 31) cryptographically linked to the general ledger (11) is. Distributed database system according to claim 12,
characterized,
that the distributed database system (1) is set up to confirm the transaction (4) to be confirmed either in the general ledger (11) or in a number of the side books (21, 31). Method for operating a distributed database system (1) with several database instances (10, 20),
wherein a respective one of the plurality of database instances (10, 20) is formed by a number of node devices (12, 13, 14; 22, 23, 24) which are set up to jointly consensus-based one of a plurality of transaction books (11, 21) of the distributed database system (1) manage
with the steps: Confirming (S1) a transaction (4) to be confirmed by adding it to the transaction book (11, 21) of one or more of the several database instances (10, 20), The distributed database system (1) decides which of the plurality of database instances (11, 21) to confirm the transaction (4) to be confirmed. Computer program product which causes the execution of the method according to claim 14 on one or more program-controlled devices.

Images