WO2020043588A1 - Dispositif et procédé pour déterminer une version de consensus d'un livre de transaction et dispositif et procédé pour surveiller un système de base de données réparties - Google Patents

Dispositif et procédé pour déterminer une version de consensus d'un livre de transaction et dispositif et procédé pour surveiller un système de base de données réparties Download PDF

Info

Publication number
WO2020043588A1
WO2020043588A1 PCT/EP2019/072447 EP2019072447W WO2020043588A1 WO 2020043588 A1 WO2020043588 A1 WO 2020043588A1 EP 2019072447 W EP2019072447 W EP 2019072447W WO 2020043588 A1 WO2020043588 A1 WO 2020043588A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
transaction
quality
path
database system
Prior art date
Application number
PCT/EP2019/072447
Other languages
German (de)
English (en)
Inventor
Rainer Falk
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2020043588A1 publication Critical patent/WO2020043588A1/fr

Links

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 device and a method for determining a consensus version of a transaction book and a device and a method for monitoring a distributed database system.
  • transactions without a clearing point or a special relationship of trust between the transaction partners can be implemented in a transparent and manipulation-protected manner based on a consensus between the transaction partners.
  • a transaction data record can include or reference program code that is executed when the transaction is confirmed in the distributed database system (so-called "smart contract").
  • Such a transparent and manipulation-protected distributed database system is suitable as an IT infrastructure platform for controlling a critical industrial automation system and the like.
  • US 2018/0121909 A1 describes a peer-to-peer consensus system and method for establishing a consensus when managing transferable digital objects.
  • a consensus version of the transaction history is selected based on a metric of the highest stake, the respective stake being the sum of those of the
  • US 2018/0121909 A1 discloses the automatic creation of a private sub-block chain based on a main block chain.
  • a device for determining a consensus version of a transaction book of a distributed database system among a number of paths from chained blocks.
  • the device comprises a first unit for obtaining a number of paths, each path comprising a number of chained blocks; a second unit for determining a block quality of the respective block of the respective path; a third unit for determining a path quality of the respective path depending on the block qualities of the input number of chained blocks of the path; and a fourth unit for determining, from the number of paths, the path with the highest path quality and providing the determined path as the consensus version of the transaction book of the distributed database system.
  • the second unit is set up to determine a transaction quality for each of the number of transactions in the respective block and to determine the block quality of a respective block as a function of the determined transaction quality of the number of transactions in the block.
  • the second unit is also set up to determine the transaction quality of the respective transaction depending on a computational complexity of the transaction.
  • the distributed database system can be formed from a number of node devices.
  • a transaction book of the distributed database system can be represented as a chain or path of confirmed blocks.
  • the chaining can be formed by means of chaining checksums.
  • Each of the number of node devices can store a chain of confirmed blocks representing a consensus version of the transaction book.
  • the distributed database system can be a blockchain network or blockchain.
  • each block comprises a number of transactions.
  • a number of the node devices can be a respective block-forming node device which forms unconfirmed blocks from unconfirmed transactions provided in the distributed database system and provides the remaining node devices in the distributed database system.
  • the provision can take place by direct, indirect or peer-to-peer transmission. Due to temporal competition and / or delays in the provision, a situation can arise in which one of the node devices from the unconfirmed blocks provided to it by the number of block-forming node devices has more than one path can form from chained blocks. In other words, a chain of concatenated blocks stored in the node device can be branched into several paths.
  • a respective proposed device for determining a consensus version of the transaction book (hereinafter also referred to as “path determination device”) can in particular be assigned to a respective one of the node devices and in particular be part of it.
  • the respective node device can determine which of the several paths from chained blocks is the chain which is to represent the consensus version of the transaction book of the distributed database system.
  • Such use of the proposed path determination device can be part of a consensus rule or a consensual procedure of the distributed database system.
  • the longest path is advantageously not necessarily determined, but rather the path with the highest path quality is determined as the consensus version of the transaction book.
  • a path quality can be understood as a measure for the block qualities of the blocks encompassed by the path.
  • a block quality can be regarded as a measure of the quality of the block and / or as a measure of the effort required to form the block by a block-forming knot device.
  • This can advantageously prevent malicious block-forming node devices from forming a large number of blocks of inferior quality with comparatively little effort and thereby influencing or dominating the majority consensus of the distributed database system.
  • the security against manipulation of the distributed database system can thus be increased.
  • a high transaction throughput can be guaranteed in a stable manner even for high-quality or complex transactions.
  • the operation of the distributed database system can be improved.
  • a “number” means a number of one or more.
  • “receive” means in particular that the path determination device receives read access to the number of paths in such a way that the further functions of the proposed path determination device can be carried out. If the path determination device is part of a node device of the distributed database system, it can in particular enter the number of paths from a storage unit of the node device. If the path determination device is provided externally to the node device, it can receive the number of paths from it via a network transmission or the like.
  • “provide” in the present case means in particular that the path determination device transmits the determined path, which represents the consensus version of the transaction book of the distributed database system (hereinafter also “consensus path”), to the node device assigned to it, for example by writing to a memory area via network or the like.
  • the path determination device transmits the determined path, which represents the consensus version of the transaction book of the distributed database system (hereinafter also “consensus path”), to the node device assigned to it, for example by writing to a memory area via network or the like.
  • transaction refers in particular to an amount of information that can be stored or confirmed as a unit in the distributed database system.
  • a transaction can be understood in such a way that the data included in the transaction is distributed in one of the transaction books Transfer the state described in the database system into a new valid state.
  • a transaction can in particular include or reference program code - a so-called smart contract - which regulates the processing of the transaction and can be executed when the transaction is confirmed. "Confirming a transaction” can be understood to mean the insertion of the transaction into the distributed database system or its transaction book.
  • block refers in particular to a data block formed according to a consensus rule of the distributed database system.
  • a respective block can furthermore include in particular: a number of cryptographic transaction checksums which a respective transaction can protect against manipulation and / or a single data block checksum which can protect the total number of transactions against manipulation; a cryptographic concatenation checksum that represents a checksum of a preceding block in a respective path of blocks and can thus protect the preceding section of the path from manipulation; and a proof value that documents a legitimate interest of a node device that has formed the block in the smooth operation of the database system, such as a proof-of-work, a proof-of-stake, a signature of a member of a back bone from privileged ones Permitted ledger and the like.
  • Confirming a transaction in the transaction book of the distributed database system can be understood in particular to mean that a transaction is included by a block-forming node device in an unconfirmed block formed by it, the unconfirmed block is made available to the further node devices and a plurality, preferably all, of the further node devices confirm the unconfirmed block and the unconfirmed transaction contained therein by appending the unconfirmed block to the consensus path, ie to the path from confirmed Blocks, which is determined as the consensus version of the transaction book after the appending of the respective proposed path determination device of the respective node device.
  • the transaction book can be, for example, a main transaction book ("general ledger” or “main chain”) or a side transaction book (“side ledger” or “side chain”) of the distributed database system.
  • the path quality of the respective path can be determined, for example, as a sum, as an average, as a median or the like of the specific block quality of the number of chained blocks of the path.
  • a formula for determining the path quality on the basis of the determined block qualities can be predefined and / or confirmed in a parameterization transaction in the transaction book of the distributed database system.
  • the respective unit for example first unit, second unit, third unit, fourth unit, can be implemented in terms of hardware technology and / or also in terms of 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 of a vehicle.
  • 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.
  • the fourth unit is also set up to provide the determined path as the consensus version of the transaction book of the distributed database system, provided the path quality of the determined path is not below a minimum path quality.
  • the fourth unit can do not provide the determined path as the consensus version of the transaction book of the distributed database system, and / or provide an explicit message that no consensus version of the transaction book could be provided.
  • a node device to which the proposed path determination device is assigned cannot determine any of the paths that it has formed from the unconfirmed blocks provided to it as a new cons version of the transaction book.
  • the node facility can continue its operation with a previous consensus version of the transaction book.
  • the previous consensus version can in particular be a section of the chain of blocks stored in the node device before the branching.
  • the node device cannot confirm any of the unconfirmed blocks provided to it.
  • confirmation of one or more unconfirmed blocks can advantageously be delayed until it is possible to form a path from the provided unconfirmed blocks that has at least the minimum path quality.
  • the path determination device is provided with a single path (a number of one of paths) and the fourth unit cannot provide a consensus version of the transaction book because the path quality determined for the individual path lies below the minimum transaction quality .
  • the chain of blocks stored in the node device does not reach the required minimum path quality before branching.
  • the node device to which the path determination device is assigned can continue to operate without a consensus version of the transaction book.
  • requests to the node device for contents of the transaction book can be rejected with an error message for as long be decided until the node device again succeeds in forming a path which is provided by the fourth unit of the path determining device as the consensus version of the transaction book.
  • the minimum path quality can be a predetermined minimum path quality.
  • the minimum path quality can also be defined as a function of a waiting time since the consensus version of the transaction book was determined in the past, with a relationship between the waiting time and the minimum path quality being set up in such a way that the minimum path quality decreases with increasing waiting time.
  • the proposed path determination device furthermore has a fifth unit, which is set up to remove a path from the number of paths if a block of the number of blocks of the path has a block quality that is less than a first threshold, and / or if a path quality of the path is less than a second threshold.
  • Removal means in particular that it is arranged that the path to be removed is no longer considered as a candidate for determining a consensus path and is therefore excluded from the majority consensus.
  • the path determination device can delete the path to be removed by means of write access to a storage unit of the node device assigned to it, or transmit a delete command via network or the like to the node device assigned to it.
  • the respective threshold can be a predefined, absolute threshold.
  • the first threshold may be a predefined fraction of an average quality factor of all of the blocks of the path and / or all of the blocks of the number of paths
  • the second threshold may be a predefined fraction of an average path quality factor of all of the number of paths.
  • the second unit is set up to determine the block quality of the respective block as a function of the quality of a detection value included in the block.
  • the proof value can in particular be a proof of work or proof of work or proof of stake.
  • the proof of work or proof-of-work can, for example, be an optional value or nonce value, which is selected in such a way that it fulfills a specific requirement.
  • the requirement may be that a cryptographic checksum, such as a hash value, of the entire block exceeds or falls below a predefined threshold. Due to an irreversible property of cryptographic checksum functions, it can be difficult and only possible to try out such a work certificate.
  • the presence of such proof of work in a block can document the legitimate interest of the node device that formed the block in the smooth operation of the database system due to the computational effort required to provide it.
  • a block that does not contain a valid work record can be discarded and cannot be entered in the transaction book of the distributed database system.
  • a quality of the proof value can be understood as a measure of the extent to which the proof value fulfills and / or over-fulfills the requirements placed on it.
  • a quality of proof of work can be a measure of how low or how high the hash value of the entire block, including proof of work, is.
  • a block with proof of work of higher quality may be preferred over a block with proof of work of lower quality.
  • This embodiment is advantageous to be created for example in egg nem time clocked distributed database system in which in front of given fixed timings a block, for example, eitan horren to real-Z to perform, and can not wait indefinitely for the completion of a Hänachwei ses.
  • a fixed timing can be realized in that no rigid requirement is imposed on the proof of work, but rather, using the proposed path determination device, those blocks and paths are preferred in the consensus-building that comprise a proof of work of the highest possible quality, for example one as possible as possible result in low hash of the entire block.
  • Analogous considerations apply to proof of proof or proof of stake.
  • the amount of crypto tokens to be kept by the block-forming node for consensus-finding about the inclusion of the formed block can advantageously be designed flexibly instead of with a fixed threshold value.
  • the second unit is set up to determine the block quality of the respective block as a function of the number of transactions in the block.
  • a transaction throughput of the distributed Database system can be increased. This can be particularly advantageous if the inclusion of a transaction in a block to be formed is associated with a high computing load for checking the transaction.
  • the second unit is set up to determine a transaction quality for each of the number of transactions of the respective block and the block quality of a respective block as a function of the specific transaction quality of the number of transactions
  • a transaction quality of the respective transaction can be determined in particular depending on the type of transaction and / or the content of the transaction.
  • the quality of the respective block can be determined, for example, as the sum, the mean or the like of the determined transaction quality of the number of transactions in the block.
  • a formula for determining the block quality on the basis of the determined transaction quality can be predetermined and / or confirmed in a parameterization transaction in the transaction book of the distributed database system.
  • One or more criteria for determining the transaction quality can be set up depending on the application. For example, a transaction that includes control or measurement values for an industrial automation system can be awarded a higher quality than an administrative transaction, such as a crypto token transaction.
  • the second unit can be set up to determine the transaction quality of the respective transaction depending on a computational complexity of the transaction.
  • a "computational complexity" of the transaction can be understood to mean a computing load that a block-forming node device has applied when forming the block comprising the transaction in order to check the validity of the transaction. If, for example, the transaction contains or references a smart contract, this computing load can be considerable.
  • the second unit is set up to determine the transaction quality of the respective transaction as a function of a time difference between a time stamp of the transaction and a time stamp of the block comprising the transaction.
  • the second unit is also set up to increase the specific block quality of the respective block in accordance with a predetermined fairness criterion, the predetermined fairness criterion providing for an increase in the block quality depending on the extent to which that Block encompassed transactions are transactions of different transaction quality and / or transactions of different types.
  • the second unit can be set up in such a way that the higher the quality of the transactions encompassed, the more preferred a block is and the faster it is confirmed in the transaction book.
  • the fairness criterion according to the present embodiment can provide that a block quality is increased if, for example, a predetermined one Proportion of transactions included in the block has a low transaction quality. This can advantageously compensate to a certain extent for a disadvantage that a block-forming node device would suffer in the form of a lower probability of confirmation of the block formed by it if it accepts transactions of low transaction quality in the block.
  • transactions can be prioritized according to their transaction quality, but in particular some transaction data records of a respective block can be re-served for transactions with low transaction quality in order to be able to ensure their final confirmation by the transaction book.
  • low transaction quality is understood to mean a transaction quality that is, for example, lower than a predetermined threshold value, and / or a transaction quality. te that is lower than a predetermined fraction of a maximum or an average transaction goods of all transactions comprised by the respective block.
  • Analogous considerations apply to transactions of different types. It is true that what is advantageous from the point of view of real-time performance, blocks with measurement and control value transactions can be preferred by assigning a high block quality; With the proposed fairness criterion, however, it can advantageously be achieved that there is an incentive for block-forming node devices to also include some transactions of a different type in a respective block to be formed.
  • the third unit is set up to further determine the respective path quality as a function of a statistical parameter of a distribution of the determined block qualities of the chained blocks of the respective path.
  • the parameter can be, for example, an average, a standard deviation, a variance, a quartile range and the like.
  • abnormalities of a path relating to the path quality can advantageously be discovered, which can remain undetected when the sum of the block qualities is viewed in a purely summary manner.
  • the consensus can advantageously be disregarded.
  • the block quality of the respective block is determined as a function of the quality of a detection value comprised by the block and the detection value is a work value
  • the embodiment in which the second unit is set up to determine the block quality of the respective block is a function of the determined transaction quality of the number of transactions in the block
  • the embodiment in which the second unit is set up to determine the transaction quality of the respective transaction depending on a computational complexity of the transaction to be determined.
  • a balance between the computing effort for providing the proof of work of the block and the computing effort for checking the respective transactions of the block can be achieved particularly advantageously.
  • a block of proof of work may be reduced for a block with arithmetically complex transactions and for a block with arithmetically simple ones
  • Transactions require a proof of work to be raised. Whether a block in a competitive situation can prevail over another block as the next block of the consensus version of the transaction book can be advantageous from the combined computing effort to form the work record and to check the transactions of the block, such as for executing smart contracts and the like, be made dependent. This can ensure stable operation of a distributed database system even when there are many complex smart contracts.
  • Such a consensus method implemented by a combination of embodiments of the proposed path determination device, in which both the quality of the proof of work and the quality of the transactions are taken into account in the formation of the consensus, can also be referred to as "proof of quality”.
  • a node device which is set up to participate in a distributed database system which implements block chain technology, the node device being a Device according to one of the preceding embodiments.
  • the proposed path determination device can be part of the node device.
  • a distributed database system which implements block chain technology and comprises a plurality of interconnected node devices according to the above embodiment.
  • a method for determining a consensus version of a transaction book of a distributed database system under a number of paths from chained blocks.
  • the method includes: obtaining a number of paths, each path comprising a number of chained blocks; Determining a block quality of the respective block of the respective path; Determining the path quality of the respective path as a function of the block quality of the number of chained blocks of the path; and determining, from the number of paths, the path with the highest path quality and providing the determined path as the consensus version of the transaction book of the distributed database system.
  • the determination of the block quality of the respective block of the respective path comprises: determining, for each of the number of transactions of the respective block, a transaction quality, and determining the block quality of a respective block depending on the determined transaction quality of the number of transactions of the block, the transaction quality of the respective transaction is determined depending on a computational complexity of the transaction.
  • the proposed method mentioned can also be referred to as path averaging method.
  • a device for monitoring a distributed database system which implements a block chain technology.
  • the apparatus comprises: a first unit for obtaining a transaction book of the distributed database system, the transaction book comprising a number of linked blocks; a second unit for determining a block quality of the respective block of the transaction book; a third unit for determining a path quality of the transaction book depending on the block quality of the number of chained blocks of the transaction book; and a sixth unit for reporting that a node device of the distributed database system is operated improperly, depending on the determined block quality and / or the determined path quality of the transaction book.
  • the second unit is set up to determine a transaction quality for each of the number of transactions of the respective block and to determine the block quality of a respective block as a function of the determined transaction quality of the number of transactions in the block.
  • the second unit is also set up to determine the transaction quality of the respective transaction depending on a computational complexity of the transaction.
  • the "transaction book” can in particular include a path of linked blocks, which is treated by the distributed database system, in particular by a plurality of node devices of the distributed database system, as a representation of the consensus version of the transaction book.
  • the proposed path determination device can advantageously make it possible to prevent paths from being whose quality can be determined as a consensus version of the transaction book.
  • the proposed monitoring device can make it possible to subsequently recognize whether a path of inferior quality has been selected as a consensus version of the transaction book.
  • the "reporting" can in particular include the issuing of a warning message to an operator of the distributed database system, for example by sending a message or by displaying a visual indication.
  • the operator can initiate necessary inspection or maintenance measures, such as a security audit.
  • the "reporting” can also include, in particular, the transmission of a message to one or more program-controlled devices.
  • the monitoring device identifies those of the node devices of the distributed database system that are responsible for forming and / or confirming the transaction book, in particular blocks of inferior quality of the transaction book, and these node devices for the rest of the node devices of the distributed one Reports database system and / or at a central control device of the distributed database system.
  • the node devices reported in this way can be temporarily or permanently automatically excluded from participation in the distributed database system or in finding consensus of the distributed database system in response to such a message.
  • a method for monitoring a distributed database system that implements block chain technology.
  • the method comprises: obtaining a transaction book of the distributed database system, the transaction book comprising a number of linked blocks; Determining a block quality of the respective block of the transaction book; Determine a path quality of the Transaction book depending on the block quality of the number of linked blocks of the transaction book; and reporting that a node device of the distributed database system is operated improperly, depending on the determined block quality and / or the determined path quality of the transaction book.
  • the determination of the block quality of the respective block of the respective path comprises: determination, for each of the number of transactions of the respective block, of a transaction quality, and determination of the block quality of a respective block depending on the determined transaction quality of the number
  • the transaction quality of the respective transaction being determined as a function of a computational complexity of the transaction.
  • a computer program product such as a computer program means, for example as a storage medium, e.g.
  • Memory card USB stick, CD-ROM, DVD, or also in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communication network by transferring a corresponding file with the computer program product or the computer program means.
  • “computer-assisted” 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 in connection with the invention, for example, a machine or an electronic circuit device.
  • a processor can 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. act.
  • 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, Application-Specific Integrated Circuit), or a DSP (digital signal
  • 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 that is equipped with configuration steps for executing the aforementioned method according to the invention or is configured with configuration steps such that the programmable processor has the inventive features of the method, the component, the modules or other aspects and / or partial aspects of the invention.
  • a “storage unit”, a “storage module” and the like can be understood in connection with the invention, for example, as 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 set up to execute the program instructions so that the processor performs functions 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. B. received, transmitted, sent or provided who.
  • evaluation unit e.g. a processor
  • storage unit data can be stored, called up or made available, for example, computer-aided and / or automatically.
  • a first date is assigned a second date using a memory address or a unique identifier (UID), in which, for. B. the first date is stored together with the memory address or the unique identifier of the second date together in a data set.
  • UID unique identifier
  • Provision in particular with regard to data and / or information, can be understood in connection with the invention, for example, to be a computer-assisted provision.
  • the provision takes place, for example, via an interface (e.g. 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 in particular be understood to mean executing program code (for example the control commands) in a process through 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, which 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 part of the transactions of a data block) are formed or calculated.
  • a cryptographic checksum or cryptographic hash or hash value which 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
  • a checksum can in particular be a checksum or hash value (s) of a hash tree (e.g. Merkle tree, Patricia tree).
  • a digital signature or a cryptographic message authentication code can also be understood in particular.
  • a cryptographic one can be created on different levels of the database system
  • Protection / manipulation protection for the transactions and the data (records) stored therein can be implemented. If, for example, a high level of security is required, how the checksums are generated at the transaction level and checked. 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 a binary hash tree. In particular, be
  • 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 link this subsequent data block with its previous data blocks, for example, 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 on the function of the chaining checksum or be included in the chaining checksum.
  • the header of a data block (e.g. a new data ten blocks or the data block for which the data block check sum was formed) can, for example, comprise the data block check sum.
  • 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, since, for this purpose, transaction checksums that have already been calculated, for example, immediately as sheets z.
  • B. a Merkle tree can be used.
  • a “chaining checksum” can be understood to mean a checksum which, in particular, specifies or references a respective data block of the distributed database system to the previous data block of the distributed database system (in the specialist literature, in particular, frequently as "previous block hash") referred to) [1].
  • a corresponding chaining checksum is formed, in particular for the corresponding preceding data block.
  • 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, for example, 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, for example, also be calculated for several or all previous data blocks. 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, for a previous data block, in particular more preferably the directly preceding data block, of the respective data block was calculated or refer to it. It is also possible, for example, for a corresponding chaining checksum to be formed only over part of the corresponding data block (e.g. previous data block).
  • a data block can be realized which comprises an integrity-protected part and an unprotected part.
  • 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.
  • 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. ei ne 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 formed over the data has been.
  • the corresponding transaction can contain 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 contains the data ) include.
  • the corresponding data could then also be made available, for example, in a further transaction of a further data block of the distributed database system (e.g. if the corresponding data and the associated checksums in different data blocks are included). For example, it is also conceivable that 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 an indication of a storage location) can also be stored in the corresponding transaction, which in particular indicates a storage location where the data can be called up. 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 in connection with the invention, for example, protection that is implemented in particular by a cryptographic method. For example, this can be achieved 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 various (cryptographic) checksums, in particular by this usammenzier synergistically Z, in order to improve example, the security and 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”.
  • “Tamper-proof” can also be referred to as "integrity-protected”.
  • chaining / 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 to several other data blocks of the distributed database system or reference these [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 linked in particular as a new data block with at least one existing data block of the distributed database system [1] [4] [5].
  • a trustworthy node e.g. a mining node, a blockchain oracle or a blockchain platform
  • a block chain platform can be understood as a block chain as a service (block chain as a service), as is suggested 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.
  • 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 more transactions.
  • transaction or “transactions” can also be understood to mean, for example, the data of a transaction of a data block of a block chain.
  • a transaction can in particular comprise a program code which, for example, implements a smart contract.
  • a transaction can also be understood as a tax transaction and / or confirmation transaction.
  • 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.).
  • Direct storage can mean, for example, 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, for example, to mean that the corresponding data block or the corresponding transaction comprises a checksum and optionally an additional data record (e.g. a reference or an indication of a storage location) for corresponding data and thus the corresponding data are not stored directly in the data block (or the transaction) (ie 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, a program command or a number of program commands that are stored in particular in one or more transactions.
  • the program code is particularly executable and is carried out, for example, by the distributed database system.
  • This can be implemented, for example, by means of an execution environment (e.g. a virtual machine), the execution environment or the program code are preferably Turing-complete.
  • the program code is preferably executed by the infrastructure of the distributed database system [4] [5].
  • a virtual machine is implemented through the infrastructure of the distributed database system.
  • a "smart contract” in connection with the invention can be understood, for example, to be an executable program code [4] [5] (see in particular 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.
  • a distributed database system e.g. a block chain
  • proof-of-work or “proof-of-work — proof” can be understood, for example, to mean the solving of a computation-intensive task which, in particular, is to be solved 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.
  • DLTS distributed ledger technology based system
  • a vision-safe database system e.g. B.
  • DAG Directed Acylic Graph
  • 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 be implemented in particular by means of a Bitcoin-based implementation or an Ethereum-based implementation [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, partial aspects of the implementation variants mentioned can in particular 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
  • transactions 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).
  • the distributed database system is, for example, a closed, distributed database system
  • new nodes and / or devices require, for example, a valid proof of authorization and / or valid authentication information and / or valid credentials and / or valid login information in order to use the distributed one Database system can join or be accepted by this.
  • 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.
  • 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 (e.g. a block chain or a peer -to-peer database), which is implemented in particular as a data structure and preferably comprises one of the transactions or more of the transactions.
  • the database or the database system
  • a data block can be a block of the block chain or the DLTS.
  • a data For example, block can include information about the size (data size in bytes) of the data block, a data block header, a transaction counter and one or more
  • the data block header can contain 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 that is used for the proof of work proof ) include [1] [4] [5].
  • a data block can also be, for example, only a specific memory area or address area of the total data which are 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.
  • ITC IoT Chain
  • IOTA IOTA
  • Byteball Byteball
  • 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 serves 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 comprise 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 individual numbers or a combination of letters, which is preferably used once in the respective context (e.g. transaction, data transfer).
  • "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 the data blocks of the distributed database system that precede the specific data block.
  • the chaining checksum or the transaction checksum can in particular only be formed via the data block directly preceding the specific data block (or its transactions) or via all data blocks preceding the first data block (or its transactions).
  • nodes for example, devices (for example field devices, mobile telephones), computers, smartphones , Clients or subscribers are understood who carry out operations (with) the distributed database system (eg 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 (eg a mining node) or exclusively by trustworthy nodes.
  • a trustworthy node is, for example, a node that has additional security measures (e.g. firewalls, access restrictions to the node or similar) to prevent manipulation of the node.
  • a trustworthy node can chain a new data block with the distributed database system, a node checksum (e.g. a digital signature or a certificate) in the new data block.
  • a proof can be provided that indicates that the corresponding data block was inserted by a certain node or indicates its origin.
  • the devices e.g. the corresponding device
  • the devices can, for example, be field devices or devices in the Internet of Things, which in particular are also a node of the distributed database system.
  • Nodes can also include, for example, at least one processor in order to, for. B. Ren to implement 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, which 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 for example, a computer (system), a client, a smart phone, a device or a server, which are each arranged outside the block chain or not a participant of the distributed 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 performing transactions, inserting data blocks or proofing Calculate 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 the distributed database system can, for example, access the data (e.g. transactions or tax transactions) of the distributed database system and / or from nodes (e.g. by means of
  • Smart contracts and / or blockchain oracles who controlled. If, for example, a control or control of a device (for example a device designed as a node or a device outside the distributed database system) is implemented by a node, this can be done, for. B. by means of a smart contract, which is stored in particular in a transaction of the distributed database system.
  • a control or control of a device for example a device designed as a node or a device outside the distributed database system
  • FIG. 1 shows a path determination device and two paths formed from concatenated blocks according to a first exemplary embodiment
  • FIG. 2 shows a path determination method according to the first exemplary embodiment
  • Fig. 3 shows a distributed database system according to a further development of the first embodiment
  • FIG. 4 shows a node device of the distributed database system in accordance with a development of the first exemplary embodiment
  • FIG. 5 shows a monitoring device and a transaction book of a distributed database system according to a second exemplary embodiment
  • Fig. 6 shows a monitoring method according to the second exemplary embodiment
  • Fig. 7 shows details of a path from concatenated blocks according to preferred variants of the first and / or second exemplary embodiment.
  • Fig. 1 shows a device 10 for determining a consensus version of a transaction book (6 in Fig. 3) of a distributed database system (hereinafter: "Path determination device 10").
  • the path determination device 10 has a first unit 101, a second unit 102, a third unit 103 and a fourth unit 104.
  • the first path 4 is a sequence of the chained blocks 61, 62,
  • the second path 5 is a sequence of the blocks 61, 62, 66, 67 linked together.
  • Each of the blocks 61 to 67 comprises at least one transaction (71-79 in FIG. 7) of the transaction book (6 in Fig. 3).
  • FIG. 2 shows a method for determining the consensus version of the transaction book (6 in FIG. 3) of the distributed database system (1 in FIG. 3) according to the first exemplary embodiment. Reference is also made to FIG. 1.
  • step S101 the first unit 101 receives the paths 4, 5.
  • step S102 the second unit 102 determines a respective block quality for each of the blocks 61-67 of each of the paths 4, 5.
  • step S103 the third unit 103 determines the path quality of the path 4 based on the block qualities of the blocks 61-65 of the path 4, and determines the path quality of the path 5 based on the block qualities of the blocks 61, 62, 66, 67.
  • step S104 the fourth unit 104 determines, among the paths 4, 5, the path 4, 5 for which the highest block quality was determined, and sets the one determined path 4, 5 as the consensus version of the transaction book (6 in FIG. 3) of the distributed database system (1 in FIG. 3).
  • the fourth unit 104 can provide an identifier for the determined path 4, 5 or the determined path 4, 5 to the unit from which it detects the paths 4, 5
  • the longest path 4 may advantageously not necessarily, but that of the paths 4, 5 with the highest path quality can be selected. This can advantageously create an incentive for the rapid and stable confirmation of blocks 61-67 of high quality, and at the same time the manipulation-proof unit of the distributed database system (1 in FIG. 3).
  • FIG 3 shows a distributed database system 1 according to a development of the first exemplary embodiment.
  • the distributed database system 1 comprises a number of node devices 20-24 which are networked with one another by means of a network 2.
  • each of the node devices 20-24 can provide transactions and / or blocks in the distributed database system 1 such that several, preferably all, of the node devices 20-24 provide them directly, indirectly or by means of peer-to-peer communication receive.
  • the distributed database system 1 stores a transaction book 6 formed from a number of chained blocks 61-65.
  • a respective node device 20-24 stores a respective representation of the transaction book 6 which it regards as a consensus version, and a consensus rule of the distributed database system 1, which is implemented by the node devices 20-24, ensures that in a majority of and preferred The representation of the transaction book 6 is stored in all of the node devices 20-24.
  • FIG. 4 shows details of the node device 20 of the distributed database system 1. Furthermore, reference is also made to FIGS. 3 and 1.
  • the node device 20 has a storage unit 201.
  • the number of paths 3, 4 from the concatenated blocks 61-67 are stored in the storage unit 201.
  • the node device 20 also has a block formation unit 202.
  • the block formation unit 202 receives a number of unconfirmed transactions provided in the distributed database system 1, forms an unconfirmed block (not shown) therefrom in accordance with the consensus rule of the distributed database system 1, which block is the last block 62 of the consensus version of the stored in the storage unit 201 Transaction book 6 references, and provides this in the distributed database system 1.
  • the block formation unit 202 appends the unconfirmed block it has formed to the consensus version of the transaction book 6 stored in the storage unit 201, as a result of which it becomes the new last block 63 of the consensus version of the transaction book 6.
  • the node device 20 also has a block confirmation unit 203.
  • the block confirmation unit 203 receives an unconfirmed block provided by another node device 21-24 in the distributed database system 1.
  • the block confirmation unit 203 checks the received unconfirmed block according to the consensus rule of the distributed database system 1. In particular, the block confirmation unit 203 checks which of the blocks 61-63 the unconfirmed block references. If the unconfirmed block references none of the blocks 61-63, it is discarded. Otherwise, the received unconfirmed block is appended to block 61-63 it references. This may lead to a branching of the version of the transaction book 6 into a number of paths 4, 5.
  • the block confirmation unit 203 receives after the block formation unit 202 has added the block 63 to the instance of the transaction book 6, which is represented by the path section from the blocks 61, 62, 63 of the path 4, in this chronological order the others Blocks 64, 66, 65 and 67.
  • the block confirmation unit 203 appends the block 64, which references the block 63, to the block 63 of the path 4.
  • the block confirmation unit 203 then appends the block 66 to the block 62, the new path 5 being created.
  • the block confirmation unit 203 appends the block 65 to the path 4 and appends the block 67 to the path 5. It is now questionable which of paths 4 or 5 should now be treated as the consensus version of transaction book 6.
  • the block confirmation unit 203 comprises the path determination device 10 according to a development of the first exemplary embodiment, which in addition to the first unit 101, second unit 102, third unit 103 and fourth unit 104 can optionally have the fifth unit 105.
  • the block confirmation unit 203 uses the path determination device 10 to determine the path 4, 5 that it treats as the consensus version of the transaction book 6 from the number of paths 4, 5 stored in the storage unit 201.
  • the path determination device 10 can select the path 4, provided that all of the blocks 61-67 have the same quality, since in this case path 4 is the longer one of the paths 4, 5.
  • the path quality of a respective one of the paths 4, 5 determined by the path determination device 10 can depend on its length, that is to say on the number of blocks 61-65 or 61, 62, 66, 67 of the respective path 4, 5 .
  • the storage unit 201 outputs the retrieved section of that of the paths 4, 5, which has been determined and provided by the path determination device 10 as the consensus version of the transaction book.
  • the structure of the node devices 21-24 of the database system 1 can correspond to the structure of the node device 20 and is therefore not described again.
  • one of the node devices 20-24 can form blocks of low quality in faster succession than the other node devices 20-24 form blocks of higher quality than the low quality.
  • This can prevent one of the node devices 20-24 from manipulating the majority consensus in the distributed database system 1 in its favor.
  • the image of blocks with the higher quality can be rewarded by the fact that such blocks are more likely to become part of the consensus version of the transaction book 6.
  • the path determination device 10 of the block confirmation unit 203 from FIG. 4 can optionally have the fifth unit 105.
  • the fifth unit 105 is set up to delete a path 4, 5 from the number of paths 4, 5 stored in the storage unit 201 under one of the following conditions: at least one of the number of blocks 61-67 Paths 4, 5 have a quality factor that is lower than a first threshold, and / or at least one of the number of paths 4, 5 has a path quality factor that is lower than a second threshold.
  • 5 shows a device 30 for monitoring a distributed database system (hereinafter referred to as “monitoring device 30”) according to a second embodiment.
  • the monitoring device 30 comprises a first unit 301, a second unit 302, a third unit 303 and a sixth unit 306.
  • FIG. 5 also shows the transaction book 6, which comprises a sequence of linked blocks 61 to 65 and is thus structured in the same way as the respective path 4, 5 (FIG. 1), which was described for the first exemplary embodiment.
  • FIG. 6 shows a method for monitoring a distributed database system according to the second exemplary embodiment, and also with reference to FIG. 5.
  • step S301 the first unit 301 receives the transaction book 6.
  • step S302 the second unit 302 determines a block quality for each of the blocks 61-65.
  • step S303 the third unit 303 determines the path quality of the transaction book 6 on the basis of the block quality of the blocks 61-65.
  • first unit 301, the second unit 302 and the third unit 303 of the monitoring device 30 functionally the first unit 101, the second unit 301 and the third unit 103 of the path determination device 10 (FIG. 1) correspond to the first embodiment.
  • step S306 the sixth unit 306 determines depending on the determined block grades and / or the determined one Path quality of the transaction book 6, whether a node device (20-24 in FIG. 3) of the distributed database system (FIG. 1), in which the transaction book 6 is stored, is operated improperly. If this is the case, the sixth unit 306 issues a corresponding message.
  • the monitoring device 30 from FIG. 5 is combined with the distributed database system 1 from FIG. 3. 5 and 3 are referred to.
  • the monitoring device 30 can be provided as a separate unit, as part of the distributed database system 1, as an external unit and communicatively coupled to the distributed database system 1, or as part of one or more of the node devices 20-24.
  • the first unit 301 can receive the transaction book 6 by querying the storage unit (201 in FIG. 4) of one or more of the node devices 20-24.
  • the sixth unit 306 can determine that at least one of the node devices 20-24 is operated improperly if one of the block grades determined by the second unit 302 is below a threshold.
  • the threshold can be a predefined absolute threshold or a predefined fraction of an average value of the determined block qualities of the transaction book 6.
  • the sixth unit 306 can determine that at least one of the node devices 20-24 is operated improperly if the determined path quality of the transaction book 6 is below a predefined absolute threshold.
  • a predefined absolute threshold Each of the conditions mentioned suggests that at least that of the node devices 20-24 that has created the block (s) 61-65 with low block quality is operated improperly, and that possibly further ones of the node devices 20-24 that the questionable Block 61-65 confirmed and in their respective consensus sion of Transaction Book 6 have been misused and / or operated incorrectly.
  • the message of the monitoring device 30 that is output in this case can be used, for example, as part of an intrusion detection system (IDS) to automatically switch off the improperly operated node devices 20-24 and / or to operate an operator of the distributed device To inform database system 1 about a necessary audit of distributed database system 1.
  • IDS intrusion detection system
  • FIG. 7 shows details of a path 7 composed of concatenated blocks 61-63 according to preferred variants of the first and / or second exemplary embodiment. 7 is described with reference to FIGS. 3, 4 and 5.
  • the path 7 shown in FIG. 7 is formed from the blocks 61, 62 and 63.
  • the path 7 can be one of the paths stored in the storage unit 201 of a node 20 of the distributed database system 1 and / or the transaction book 6 received by the monitoring device 30.
  • the processes described below for determining a block and / or path quality can relate to functionality of the second unit 102 of the path determination device 10 according to the first exemplary embodiment and / or the second unit 302 of the monitoring device 30 according to the second exemplary embodiment.
  • a respective block 61, 62, 63 of path 7 comprises a user data section, which comprises a number of transactions 71-73, 74-76, 77-79, and a header data section, which in particular has a data block hash value 614, 624, 634 Concatenation hash value 612, 622, 632 and a verification value 611, 621, 631 and optionally a time stamp 613, 623, 633.
  • the transactions 71-79 each include user data of the distributed database system 1.
  • a respective transaction 71-79 can include data and / or program code (so-called smart contracts), which transition from one of the state of the distributed database system 1 to the Confirm the transaction 71-79 in a state of the distributed database system 1 after confirming the transaction 71-79.
  • smart contracts data and / or program code
  • the respective data block hash value 614, 624, 634 is a cryptographic hash value which protects the transactions 71-73, 74-76, 77-79 of the respective block 61, 62, 63 against manipulation.
  • the data block hash value 614, 624, 634 can be a root value of a Merkle or Patricia hash tree.
  • the respective time stamp 613, 623, 633 is an optional feature and can denote the time (date and time) at which the corresponding block 61, 62, 63 was formed.
  • the respective chaining hash value 612, 622, 632 is a hash value of the respectively preceding block 61, 62.
  • the chaining hash value 622 is a hash value of the entire block 61.
  • the chaining hash value 632 is a hash value of the entire block 62.
  • the respective concatenation hash value 612, 622, 632 can define the order in which the blocks 61, 62, 63 are concatenated and can secure the path 7 against manipulation. For example, if transaction 71 were subsequently manipulated, this would invalidate not only data block hash value 614, but also chaining hash values 622 and each subsequent chaining hash value 632.
  • the respective verification value 611, 621, 631 is a value that serves a legitimate interest of the node device 20-24, which has formed the respective block 61, 62, 63, in the inclusion of the block 61, 62, 63 in the transaction book 6 of the distributed database system 1.
  • the detection value 611, 621, 631 is in particular set up in such a way that it can be checked in a verifiable manner by the amount
  • Block formation device 202 (FIG. 4) of the relevant node 20-24 computing power (so-called proof-of-work), a quantity of cryptotoken (so-called proof-of-stake) held for a certain duration or one Documented the amount of other resources used.
  • the path determination device 10 can determine a block quality of the respective block 61-63 and the path quality of the path 7.
  • a path quality P of the path 7 is a function of the block qualities B of the blocks 61, 62, 63 of the path 7:
  • the path quality P is a sum of the block qualities B of blocks 61, 62, 63 of path 7:
  • a path quality can depend on the number of blocks of the path. If all block qualities Bi of two paths 7 are identical, the longer of the paths 7 is determined as a consensus version of the transaction book 6. However, a shorter path 7 can be determined as a consensus version of the transaction book 6 if the blocks 61-63 of the shorter path 7 have a higher block quality B on average.
  • the block quality is B of the respective one
  • Blocks 61, 62, 63 a function of a detection quality N of the detection value 611, 621, 631 of the respective block 61, 62, 63.
  • the respective verification value 611, 621, 631 can be a relative or best effort proof of work.
  • a request made to the verification value 611, 621, 631 may be that the verification value 611, 621, 631 is to be selected such that a hash value of the entire block 61,
  • 62, 63 is as small as possible. Due to an irreversibility property of cryptographic hash functions, a corresponding proof value 611, 621, 631 can only be determined by trial and error, and the more computing power is used, the better the requirement can be met.
  • Such a relative proof-of-work 611, 621, 631 can be advantageous, for example, when it is required to be able to form and confirm the respective block 61, 62, 63 within a predetermined period of time with a guarantee. In this case, trying it out to determine the proof value 611, 621,
  • the block quality is B of the respective one
  • Blocks 61, 62, 63 a function of a transaction quality T depending on that of the transactions 71-73, 74-76, 77-79 of the blocks 61, 62,
  • the transaction quality T of the respective transaction 71-79 can, for example, depend on a quantity of transferred crypto tokens, on the need for real-time transaction 71-79 and / or on a type of transaction (for example measured value / control value transaction, crypto token transaction, smart contract, parameterization transaction etc.) ⁇
  • a higher quality can be assigned to a block 61-63, which comprises transactions 71-79 which are to be confirmed with priority in the distributed database system 1.
  • the transaction quality T depends on the computational complexity of transaction 71-79.
  • a “computational complexity” of the respective transaction 71-79 can be understood to mean a computational load which the block-forming unit 202 had to apply when forming the block 61-63 comprising the transaction 71-79 in order to make the transaction 71-79 valid to consider. If, for example, the transaction contains or references a smart contract, this computing load can be considerable.
  • the computational complexity of the respective transaction 71-79 can be recorded, for example, by measuring the computing load or execution time that the block confirmation unit 203 uses to check the validity of the transaction 71-79.
  • the computational complexity of the respective transaction 71-79 can also be determined by code analysis.
  • the smart contracts referenced by the transaction can be determined, the execution times of which may be known from previous executions of the same smart contracts, and the known execution times of the referenced smart contracts can be added up to the total for checking the transaction 71-79 to determine valid computing load.
  • the block quality B of the respective block 61, 62, 63 can be particularly advantageous both from the detection quality N of the detection value 611, 621, 631 and from the computational complexity. transactions 71-73, 74-76, 77-79 of block 61,
  • a consensus rule of the distributed database system 1 can be designed in such a way that one for creating a valid, i.e. a predetermined minimum quality requirement corresponding blocks 61-63 computing load is constant.
  • Complex transaction 71-79 required computing load is at a disadvantage in competition with the other node devices 20-24 in that the block formed by it with the computationally complex transaction 71-79 is completed later because of the higher computing load.
  • the block-forming device 202 can apply the less computing load for determining the proof value 611, 621, 631 without the disadvantage of finding consensus, the more computing load it has for checking the transactions 71-73, 74-76, 77-79 of block 61-63 has spent.
  • Contracts include or reference, can confirm quickly and stable.
  • the transactions 71-79 each have a time stamp (not shown) which represents a point in time when transaction 71-79 was created and / or a point in time of providing transaction 71-79 to distributed database system 1.
  • the respective block 61-63 each has a time stamp 613, 623, 633, which indicates a point in time when the block 61-63 was formed.
  • the transaction quality T of the respective transaction 71-73, 74-76, 77-79 of the respective block 61-63 is dependent on a time difference between the time stamp of the transaction 71-79 and the time stamp 613, 623, 633 of the block 61-63. This time difference can also be referred to as time stamp quality C.
  • an incentive can be created to include a transaction 71-79 as soon as possible in a block 61-63 to be formed, and / or an incentive to record one long ago to include transaction 71-79 in a block 61-63 to be formed in block 61-63 to be formed.
  • Transactions 71-79 which are not computationally complex, can thus contribute to a high block quality B of block 61-63, provided that they have already been included in a formed block 61-63 in a short time after being made available to the distributed database system 1. This can create a balance between complex and simple but time-critical transactions 71-79.
  • a distribution of the transaction quality T of the transactions 71-79 can be analyzed.
  • the block quality B can be increased according to a fairness criterion if the block 61-63 comprises transactions of different transaction quality and / or transactions of different types.
  • the formation of blocks 61-63 can be rewarded with particularly high-quality block grades.
  • it can also be rewarded if a predefined number of transaction data records 71-73, 74-76, 77-79 of the respective block 61-63 for transactions 71-79 of min. whose transaction quality is used. It can thus be ensured that transactions 71-79 of lower quality can also be confirmed by the distributed database system 1.
  • the fairness criterion can therefore be used to achieve an adaptive partitioning of the transaction throughput of the distributed database system 1 on the one hand for high-priority or high-quality transactions and on the other hand for administrative, low-value transactions 71-79.
  • the block quality is B of the respective one
  • Blocks 61, 62, 63 depending on the number of transactions
  • the block quality B of the respective block 61, 62, 63 can be the sum of the transaction quality T of transactions 71-73, 74-76, 77-79 of the block 61, 62, 63 can be determined. This can create an incentive to include as many transactions 71-79 as possible in block 61, 62, 63.
  • the path quality P of the path 7 can be determined and / or adapted depending on a statistical parameter of a distribution of the certain block qualities B of the blocks 61-63 of the path 7.
  • a variance or the like of the block qualities B of the blocks 61, 62, 63 could be included in the determination of the path quality P.
  • This proposal is based on the idea that, in the case of a large, distributed database system 1 with a high and diverse transaction throughput, within the framework of the consensus finding using the proposed path determination device 10 with its block and path quality-dependent determination criteria, the transaction book 6 of the distributed database system can be found 1 should set a block quality B that is constant on average. If a path 7 shows excessive fluctuations in the block quality B of its blocks 61-63, this can be an indication of attempts at manipulation. Such a path 7 can be partially recognized as suspicious and excluded from finding a consensus or reported as a potential problem to an operator.
  • the described variants can be selected individually by the person skilled in the art and / or combined with one another as required.
  • a path quality P and the block qualities Bi of the path 7 can thus according to the formulas
  • the formulas and their parameters for determining the respective path quality P, block quality B, transaction quality T, time stamp quality C, detection quality N and the like (hereinafter referred to as "quality determination parameter") can be specified in the respective path determination device 10 and / or monitoring device 30 .
  • the quality determination parameters can be stored particularly advantageously in a parameterization transaction 71-79 of the consensus version of the transaction book 6 and can be called up from there in particular by the path determination device 10.
  • the distributed database system 1 can thus be given the ability to assess aspects of its consensus rule, in particular the quality determination parameters, on the basis of their properties of paths and blocks in finding a consensus. be shared, adaptively to adapt to changing usage patterns or other conditions occurring in the distributed database system 1 or in the distributed database system 1, for example via an oracle.
  • a path quality of a respective path from concatenated blocks of a distributed database system is determined on the basis of a block quality of the respective block.
  • the particular path quality is used to determine the consensus version of the transaction book from among several possible paths and / or to check the consensus version of the transaction book to identify abusive operation.
  • Nxt Wiki "Whitepaper: Nxt - Nxt Wiki"

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un dispositif et un procédé pour déterminer une version de consensus d'un livre de transaction et un dispositif et un procédé pour surveiller un système de base de données réparties. Un dispositif pour déterminer une version de consensus d'un livre de transaction d'un système de base de données réparties avec un certain nombre de chemins de blocs enchaînés comprend : une première unité destinée à obtenir un certain nombre de chemins, un chemin respectif comprenant un certain nombre de blocs enchaînés; une deuxième unité destinée à déterminer une qualité du bloc respectif du chemin respectif; une troisième unité destinée à déterminer une qualité du chemin respectif en fonction des qualités du nombre de blocs enchaînés du chemin, et une quatrième unité destinée à déterminer, à partir du nombre de chemins, le chemin présentant la qualité la plus élevée et à fournir le chemin déterminé en tant que version de consensus du livre de transaction du système de base de données réparties. En conséquence, un débit de transaction plus stable peut être obtenu et une utilisation non autorisée peut être empêchée avec une règle de consensus basée sur la qualité du chemin. L'invention concerne en outre un procédé pour déterminer la version de consensus ainsi qu'un dispositif et un procédé pour surveiller un système de base de données réparties.
PCT/EP2019/072447 2018-08-31 2019-08-22 Dispositif et procédé pour déterminer une version de consensus d'un livre de transaction et dispositif et procédé pour surveiller un système de base de données réparties WO2020043588A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18191977.0 2018-08-31
EP18191977.0A EP3617977A1 (fr) 2018-08-31 2018-08-31 Dispositif et procédé pour determiner un consensus sur la version de journal des transactions et dispositif et procédé pour la surveillance d'un système distribué de base de données

Publications (1)

Publication Number Publication Date
WO2020043588A1 true WO2020043588A1 (fr) 2020-03-05

Family

ID=63528515

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/072447 WO2020043588A1 (fr) 2018-08-31 2019-08-22 Dispositif et procédé pour déterminer une version de consensus d'un livre de transaction et dispositif et procédé pour surveiller un système de base de données réparties

Country Status (2)

Country Link
EP (1) EP3617977A1 (fr)
WO (1) WO2020043588A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220284423A1 (en) * 2021-03-05 2022-09-08 Capital One Services, Llc Architecture of Immutable Database for Bitemporal Analysis

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112507371B (zh) * 2021-02-05 2021-04-27 中航信移动科技有限公司 基于区块链的民航安检数据处理系统

Citations (3)

* 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
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
US20180123882A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation Changing an existing blockchain trust configuration

Patent Citations (3)

* 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
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
US20180123882A1 (en) * 2016-10-28 2018-05-03 International Business Machines Corporation Changing an existing blockchain trust configuration

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
ANDREAS M. ANTONOPOULOS: "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", December 2014, O'REILLY MEDIA
HENNING DIEDRICH: "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations", 2016, CREATESPACE INDEPENDENT PUBLISHING PLATFORM
LEEMON BAIRD, OVERVIEW OF SWIRLDS HASHGRAPH, 31 May 2016 (2016-05-31)
LEEMON BAIRD, THE SWIRLDS HASHGRAPH CONSENSUS ALGORITHM: FAIR, FAST, BYZANTINE FAULT TOLERANCE
NEM: "NEM Technical Reference", 23 February 2018 (2018-02-23), XP055518295, Retrieved from the Internet <URL:https://nem.io/wp-content/themes/nem/files/NEM_techRef.pdf> [retrieved on 20181023] *
NXT WIKI: "Whitepaper:Nxt - Nxt Wiki", 2 July 2018 (2018-07-02), XP055518168, Retrieved from the Internet <URL:https://nxtwiki.org/wiki/Whitepaper:Nxt> [retrieved on 20181023] *
ROGER M. NEEDHAMMICHAEL D. SCHROEDER: "Using encryption for authentication in large networks of computers", vol. 21, December 1978, ACM: COMMUNICATIONS OF THE ACM
ROSS ANDERSON: "Security Engineering. A Guide to Building Dependable Distributed Systems", 2001, WILEY
THE ETHEREUM BOOK PROJECT/MASTERING ETHEREUM, Retrieved from the Internet <URL:https://github.com/ethereumbook/ethereumbook>

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220284423A1 (en) * 2021-03-05 2022-09-08 Capital One Services, Llc Architecture of Immutable Database for Bitemporal Analysis

Also Published As

Publication number Publication date
EP3617977A1 (fr) 2020-03-04

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
EP3673623B1 (fr) Procédé et système de contrôle pour le contrôle et/ou la surveillance d&#39;appareils
EP3125492B1 (fr) Procede et systeme de fabrication d&#39;un canal de communication sur pour des terminaux
EP3683713B1 (fr) Procédé, dispositifs et système de fourniture sécurisée des ensembles de données
EP3637345A1 (fr) Mise en relation d&#39;identités dans une base de données distribuée
EP3777088B1 (fr) Procédé et système de commande d&#39;une libération d&#39;une ressource
EP3763089B1 (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
WO2020043581A1 (fr) Dispositif et procédé de formation de bloc, dispositif nœud et procédé de confirmation de bloc
EP4128656A1 (fr) Dispositifs, procédé mis en oeuvre par ordinateur et produit-programme informatique pour donner accès à une fonction de commande sur la base d&#39;un objet
WO2020193136A1 (fr) Détection d&#39;intrusion dans des systèmes informatiques
EP3723007B1 (fr) Procédé et système de commande permettant de commander l&#39;exécution des transactions
EP3599740A1 (fr) Commande d&#39;un réseau de données concernant une utilisation d&#39;une banque de données distribuée
EP4154070A1 (fr) Commande de processus basée sur un jumeau numérique dans un réseau ido
WO2020043430A1 (fr) Dispositif et procédé de fourniture d&#39;une transaction oracle dans un système de base de données réparties
EP3945702A1 (fr) Communication basée sur les canaux dans un réseau iot
EP3877935A1 (fr) Procédé pour faire fonctionner un système de base de données distribué, système de base de données distribué et système d&#39;automatisation industrielle
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
EP3618348A1 (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
EP3828798A1 (fr) Dispositif et procédé de formation de blocs de données
EP3786831A1 (fr) Procédé et dispositif de vérification d&#39;un ensemble de données
EP3918434A1 (fr) Procédé et système de commande pour la commande d&#39;une exécution de transactions
EP3902224A1 (fr) Dispositif et procédé de saisie des données d&#39;appareil dans un système de banque de données distribuées
EP3829103A1 (fr) Dispositif et procédé de formation de blocs de données

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19769014

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19769014

Country of ref document: EP

Kind code of ref document: A1