EP3617978A1 - Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement - Google Patents

Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement Download PDF

Info

Publication number
EP3617978A1
EP3617978A1 EP18191983.8A EP18191983A EP3617978A1 EP 3617978 A1 EP3617978 A1 EP 3617978A1 EP 18191983 A EP18191983 A EP 18191983A EP 3617978 A1 EP3617978 A1 EP 3617978A1
Authority
EP
European Patent Office
Prior art keywords
transaction
confirmed
database system
distributed database
instances
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP18191983.8A
Other languages
German (de)
English (en)
Inventor
Rainer Falk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to EP18191983.8A priority Critical patent/EP3617978A1/fr
Publication of EP3617978A1 publication Critical patent/EP3617978A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce

Definitions

  • the present invention relates to the field of distributed database systems, and more particularly, to a distributed database system with multiple database instances.
  • 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.
  • 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.
  • the distributed database system is set up to decide which of the several database instances is used to confirm the transaction to be confirmed.
  • 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.
  • 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.
  • the respective database instance can be a block chain or a block chain, such as a main chain or a side chain.
  • 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.
  • the respective means can be implemented in a decentralized or distributed manner.
  • the respective means can be implemented by functionality of one or more of the multiple database instances.
  • 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.
  • the transaction book comprises a chain of confirmed blocks, each confirmed block comprising a number of confirmed transactions.
  • 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.
  • 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.
  • a plurality and preferably all of the number of node devices can check the unconfirmed block provided in the database.
  • 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.
  • “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.
  • the distributed database system makes the decision as to which of the several database instances the transaction to be confirmed is confirmed.
  • 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.
  • 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.
  • 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.
  • 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.
  • the multiple database instances can regularly exchange load information with one another.
  • 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.
  • 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.
  • an explicit decision can advantageously be made which balances the load in the distributed database system.
  • 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").
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the defined number of database instances can be defined by the transaction to be confirmed.
  • 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.
  • 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.
  • an incentive to confirm a transaction may be lost once the transaction has been assigned the specified number of times.
  • 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.
  • the database system is set up to synchronize the transaction books of the plurality of database instances with one another at predefined time intervals.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a computer program product such as a computer program means
  • 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 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.
  • 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.
  • “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.
  • 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.
  • 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
  • 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.
  • RAM random access memory
  • permanent storage such as a hard disk or a data carrier.
  • a “module” can be understood to mean, for example, a processor and / or a storage unit for storing program instructions.
  • 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.
  • 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 e.g. a network interface
  • WLAN interface e.g. a network interface
  • an evaluation unit e.g. a processor
  • storage unit e.g. a storage unit.
  • data can be exchanged using the interfaces (e.g. received, transmitted, sent or made available).
  • the evaluation unit data can be compared, checked, processed, assigned or calculated, for example in a computer-assisted and / or automated manner.
  • storage unit data can be stored, accessed or made available, for example, in a computer-assisted and / or automated manner.
  • “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.
  • 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.
  • UID unique identifier
  • provisioning 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).
  • 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.
  • “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).
  • 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 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ].
  • a corresponding chaining checksum is formed, in particular for the corresponding previous data block.
  • a transaction checksum or the data block checksum of a data block 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.
  • a checksum 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.
  • 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.
  • a corresponding chaining checksum is also possible for a corresponding chaining checksum to be formed only over part of the corresponding data block (for example, previous data block).
  • 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.
  • 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.
  • the data e.g. B.
  • User data such as measurement data, measurement values, control values, or data / ownership relationships to assets
  • 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.
  • 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).
  • this data is made available via another communication channel (eg via another database and / or a cryptographically secured communication channel).
  • 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.
  • 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.
  • security-protected in connection with the invention can also be understood to mean “cryptographically protected” and / or “manipulation-protected”.
  • Tamer-proof can also be referred to as "integrity-protected”.
  • 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].
  • information for example, chaining checksum
  • “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).
  • a trustworthy node for example a mining node, a block chain oracle or a block chain platform.
  • a block chain platform can be understood to mean a block chain as a service, as is proposed in particular by Microsoft or IBM.
  • 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.
  • 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.
  • transaction or “transactions” can also be understood to mean, for example, the data of a transaction in a data block of a block chain.
  • a transaction can include a program code that, for example, implements a smart contract.
  • a transaction can also be understood to mean a tax transaction and / or confirmation transaction.
  • a transaction can be, for example, a data structure that stores data (e.g.
  • storing transactions in data blocks 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).
  • these checksums can be validated, for example, as is explained, for example, under "inserting into the distributed database system".
  • 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.
  • 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.
  • 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].
  • a computationally intensive task is also referred to as a cryptographic puzzle, for example.
  • 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.
  • DLT distributed ledger technology
  • DLTS distributed ledger technology
  • An audit-proof database system a cloud, a cloud service, a block chain in a cloud or a peer-to-peer database.
  • DAG Directed Acylic Graph
  • 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].
  • 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.
  • 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.
  • DAG Directed Acylic Graph
  • IOTA Directed Acylic Graph
  • Tangle Transaction or blocks or nodes of the graph are connected to one another via directed edges.
  • 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).
  • a public distributed database system e.g. a public block chain
  • a closed (or private) distributed database system e.g. a private block chain
  • 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.
  • 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.
  • 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.
  • DLTS DLT-based system
  • 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.
  • ITC IoT Chain
  • IOTA IOTA
  • Byteball Byteball
  • 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).
  • 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.
  • a data block can also include one or more transactions, for example, in the simplest case a data block corresponding to a transaction.
  • nonce can be understood to mean, for example, a cryptographic nonce (abbreviation for: “used only once” [2] or “number used once” [3]).
  • 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.
  • "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.
  • 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.
  • nodes e.g. field devices, mobile telephones
  • computers e.g. smart phones
  • clients or participants 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.
  • 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.
  • 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
  • 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.
  • 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).
  • 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).
  • a computer in particular can also be understood to mean a node of the distributed database system.
  • 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.
  • 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.
  • 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.
  • 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.
  • node devices 12, 13, 14, 22, 23, 24 are communicatively networked with one another in order to jointly implement the functionality described above.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • smart contracts data and / or program code
  • the state described by the transaction book 11 can be transparently understood at every current and past point in time.
  • 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.
  • 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.
  • 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. Any 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.
  • proof-of-work a quantity of computing power used by the block-forming node device 12-14
  • Proof-of-Stake a quantity of crypto tokens held for a certain duration
  • 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 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.
  • 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.
  • program code of a smart contract included or referenced by the transaction 4 to be confirmed can be executed.
  • 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.
  • 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 confirmation of the transaction 4 to be confirmed can be a computationally expensive process.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a trust-based privileged ledger approach is conceivable here.
  • the side books 21, 31 are cryptographically linked several times to 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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)
  • a summarizing transaction 57 which defines the state updated from the second side book 31.
  • 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.
  • 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.
  • 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.
  • the states described by the respective transaction books 11, 21, 31 are synchronized with one another at predefined time intervals.
  • the database instances 10, 20, 30 are set up for cross-database instance communication when confirming the respective transaction 4 to be confirmed.
  • 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.
  • 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.
  • 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.
EP18191983.8A 2018-08-31 2018-08-31 Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement Withdrawn EP3617978A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP18191983.8A EP3617978A1 (fr) 2018-08-31 2018-08-31 Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18191983.8A EP3617978A1 (fr) 2018-08-31 2018-08-31 Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement

Publications (1)

Publication Number Publication Date
EP3617978A1 true EP3617978A1 (fr) 2020-03-04

Family

ID=63578944

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18191983.8A Withdrawn EP3617978A1 (fr) 2018-08-31 2018-08-31 Système distribué de base de données avec une pluralité d'instances de base de données et son procédé de fonctionnement

Country Status (1)

Country Link
EP (1) EP3617978A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US9875510B1 (en) * 2015-02-03 2018-01-23 Lance Kasper Consensus system for tracking peer-to-peer digital records
US20180123882A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation Changing an existing blockchain trust configuration
US20180121909A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation System and method to dynamically setup a private sub-blockchain based on agility of transaction processing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9875510B1 (en) * 2015-02-03 2018-01-23 Lance Kasper Consensus system for tracking peer-to-peer digital records
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US20180123882A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation Changing an existing blockchain trust configuration
US20180121909A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation System and method to dynamically setup a private sub-blockchain based on agility of transaction processing

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
"Mastering bitcoin : [unlocking digital cryptocurrencies]", 20 December 2014, O'REILLY MEDIA, Beijing Cambridge Farnham Köln Sebastopol Tokyo, ISBN: 978-1-4493-7404-4, article ANDREAS M. ANTONOPOULOS: "Mastering Bitcoin - Unlocking Digital Cryptocurrencies", XP055306939 *
"The Ethereum Book Project/Mastering Ethereum", 5 October 2017
ANDREAS M. ANTONOPOULOS: "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", December 2014, O'REILLY MEDIA
BLOCKCHAIN ORACLES, Retrieved from the Internet <URL:https://blockchainhub.net/blockchain-oracles>
HENNING DIEDRICH: "CreateSpace Independent Publishing Platform", 2016, article "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations"
LEEMON BAIRD, OVERVIEW OF SWIRLDS HASHGRAPH, 31 May 2016 (2016-05-31)
LEEMON BAIRD: "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance", SWIRLDS TECH REPORT SWIRLDS-TR-2016-01, 31 May 2016 (2016-05-31)
ROGER M. NEEDHAM; MICHAEL D. SCHROEDER: "Using encryption for authentication in large networks of computers", ACM: COMMUNICATIONS OF THE ACM, vol. 21, no. 12, December 1978 (1978-12-01), XP058231706, DOI: doi:10.1145/359657.359659
ROSS ANDERSON: "Security Engineering. A Guide to Building Dependable Distributed Systems", 2001, WILEY

Similar Documents

Publication Publication Date Title
EP3652656B1 (fr) Dispositifs destinés à fournir une quantité d&#39;enregistrements unitaires de transactions, protégés de manière cryptographique et filtrés ainsi que triés, d&#39;un maillon d&#39;une chaîne de blocs
EP3669497B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
EP3673623B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
EP3388994A1 (fr) Procédé et dispositif destinés au test assisté par ordinateur d&#39;une chaîne galle
EP3595267B1 (fr) Procédé, dispositifs et système d&#39;échange de données entre un système de banque de données distribué et appareils
EP3637345A1 (fr) Mise en relation d&#39;identités dans une base de données distribuée
EP3763089B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
EP3669285B1 (fr) Procédé et système de commande et/ou de surveillance de dispositifs
EP3777088B1 (fr) Procédé et système de commande d&#39;une libération d&#39;une ressource
EP3718263B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
WO2020043581A1 (fr) Dispositif et procédé de formation de bloc, dispositif nœud et procédé de confirmation de bloc
EP3723007B1 (fr) Procédé et système de commande permettant de commander l&#39;exécution des transactions
EP3714575B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
WO2020043588A1 (fr) Dispositif et procédé pour déterminer une version de consensus d&#39;un livre de transaction et dispositif et procédé pour surveiller un système de base de données réparties
EP3599740A1 (fr) Commande d&#39;un réseau de données concernant une utilisation d&#39;une banque de données distribuée
EP3618348B1 (fr) Procédé de fonctionnement d&#39;un système de banques de données distribuée, système de banques de données distribuée et système d&#39;automatisation industrielle
EP3617978A1 (fr) Système distribué de base de données avec une pluralité d&#39;instances de base de données et son procédé de fonctionnement
EP3617976A1 (fr) Procédé de fonctionnement d&#39;un système de base de données distribuée, système de base de données distribuée et système d&#39;automatisation industrielle
EP3617974A1 (fr) Dispositif et procédé de fourniture d&#39;une transaction oracle dans un système de banques de données distribuée
EP3671599A1 (fr) Procédé de fonctionnement d&#39;un système de banques de données distribuée, système de banques de données distribuée et système d&#39;automatisation industrielle
EP3958501A1 (fr) Procédé, dispositifs et système d&#39;échange de données entre un système de banque de données distribué et appareils
DE102020120945A1 (de) Verfahren zum Kommunizieren, basierend auf einer Distributed-Ledger-Technologie, zwischen einer Vielzahl von Ladestationen für Elektrofahrzeuge
EP3945702A1 (fr) Communication basée sur les canaux dans un réseau iot
EP3713189A1 (fr) Détection d&#39;intrusion dans des systèmes informatiques
EP3627755A1 (fr) Procédé pour une communication sécurisée dans un réseau de communication pourvu d&#39;une pluralité d&#39;unités à différents niveaux de sécurité

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20190104

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200609