Block formation device and block formation method, node device and block confirmation method

Abstract

A block forming device and a node device for a distributed database system are proposed, wherein the block forming device and the node device respectively have a unit for receiving a timing cycle from a time source and determining a time slice of a predetermined length according to the timing cycle. The block forming device is configured to: select a transaction to be confirmed exactly once from unconfirmed transactions provided in the database system within a corresponding time slice; form an unconfirmed block from the selected unconfirmed transaction; and provide the unconfirmed block in the database system. The node device is configured to: store a chain of confirmed blocks, wherein the confirmed blocks represent a transaction ledger of the database system; and within a corresponding time slice, confirm exactly one block exactly once from the unconfirmed blocks provided in the database system in the time slice, and attach the exactly one block to the chain of confirmed blocks. Accordingly, a distributed database system for controlling industrial automation equipment with real-time requirements can be realized. In addition, a block forming method, a block confirmation method, a distributed database system, and an industrial automation system are proposed.

Description

Technical Field

[0001] The present invention relates to the field of industrial automation technology, and in particular to a block forming device, a block forming method, a node device and a block confirmation method for a distributed database system with timing. Background Art

[0002] Industrial applications, such as industrial automation systems, place particular demands on the information technology used for control or regulation with regard to functional safety, availability and real-time capability.

[0003] In a distributed database system implemented using blockchain technology, transactions without a clearing house or a special trust relationship between the transaction parties can be realized in a way that prevents manipulation (manipulationsgeschuetzt) ​​based on consensus between the transaction parties. It is conceivable that in a transaction data record protected by blockchain technology, measurement / control values ​​and control instructions for industrial automation systems (for example, as so-called smart contracts) are stored. However, the known blockchain technology lacks the real-time capabilities required for industrial control. In particular, a blockchain based on proof of work can only confirm transactions at certain intervals on average, but cannot accurately predetermine at which points in time the transaction is to be confirmed or the smart contract is to be executed.

[0004] Elli Androulaki et al.'s "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" (Proceedings of the Thirteenth Eurosys Conference on Eurosys '18, April 23-26, 2018, Porto, Portugal) discloses Fabric for the operation of a blockchain database system with restricted access. The Fabric works with an Execute-Order-Validate architecture, in which checking transactions, ordering transactions into blocks, and validating blocks are separated from each other. Only the ordering of transactions into blocks is performed in a timed manner. Summary of the invention

[0005] Against this background, the object of the present invention is to improve a distributed database system.

[0006] According to a first aspect, a block formation device for a distributed database system is proposed, wherein the distributed database system includes a plurality of node devices. The block formation device has: a first unit for selecting a plurality of transactions to be confirmed from a plurality of unconfirmed transactions provided in the distributed database system; a second unit for forming an unconfirmed block from the selected plurality of unconfirmed transactions, and for providing the unconfirmed block in the distributed database system, wherein the validity of the corresponding selected unconfirmed transaction is checked, and the corresponding selected unconfirmed transaction is discarded if the check fails, otherwise the corresponding selected unconfirmed transaction is included in the unconfirmed block; and a third unit for receiving a timing cycle from a time source, and for determining a time slice of a predetermined length based on the timing cycle. The first unit and the second unit are configured to perform selection, formation and provision exactly once within the corresponding time slice.

[0007] The distributed database system can implement a transaction ledger ("ledger") that is protected against manipulation, which is represented by a chain of confirmed blocks stored in each of the node devices. The chain can be formed by means of a checksum. In particular, the distributed database system can be a blockchain network or a blockchain.

[0008] The proposed block forming device may be a mining device. The block forming device may in particular be a component of a node device of a distributed database system.

[0009] The proposed block formation device can advantageously form corresponding unconfirmed blocks from unconfirmed transactions provided in the distributed database system in a predetermined timing cycle. Thus, it is possible to achieve timed block formation or mining, and thus it is possible to confirm unconfirmed transactions in a timed manner. Therefore, the proposed block formation device can give the distributed database system the following qualification: the qualification is a qualification for use for controlling industrial automation equipment with real-time requirements.

[0010] "Plurality" is to be understood as a number of one or more.

[0011] The devices of the distributed database system (the plurality of node devices therein and in particular the proposed block forming device) can be communicative or networked with each other.

[0012] “Providing” an unconfirmed transaction or an unconfirmed block in a distributed database system may be understood as transmitting the unconfirmed transaction or the unconfirmed block to at least one of the devices in the distributed database system. The unconfirmed transaction to be provided or the unconfirmed block to be provided may be transmitted directly, indirectly, or in a peer-to-peer manner to the remaining devices in the distributed database system.

[0013] The distributed database system may be configured such that the time required to provide or transmit an unconfirmed block or an unconfirmed transaction to most or all devices of the distributed database system is shorter than the length of the corresponding time slice in the time slice.

[0014] The first unit may be configured to select a plurality of transactions to be confirmed from the provided plurality of unconfirmed transactions in the following order: the respective unconfirmed transactions are provided in the said order. Alternatively, it is also conceivable that during the selection, the transactions are prioritized according to the characteristics of the respective unconfirmed transactions.

[0015] The second unit may be configured to form an unconfirmed block from the selected plurality of unconfirmed transactions in accordance with the requirements of the consensus rule of the distributed database system.

[0016] In particular, the second unit can be configured to: check the validity of the corresponding selected unconfirmed transaction according to the consensus rule; if the check fails, discard the unconfirmed transaction; and otherwise include the unconfirmed transaction in the unconfirmed block. Within the scope of the check, the following smart contract can be executed: the smart contract is included in the unconfirmed transaction and / or the smart contract is stored in the transaction ledger of the distributed database system and is referenced by the transaction. In this way, the program code with control instructions can be executed, which is stored in the smart contract.

[0017] In particular, the second unit can be designed to protect unconfirmed blocks and / or corresponding transactions included in unconfirmed transactions in the block from manipulation using a checksum (such as, for example, a hash value) or a root checksum of a hash tree (such as a Merkle tree or a Patricia tree).

[0018] In particular, the second unit can be designed to link the unconfirmed block to the transaction ledger of the distributed database system. For this purpose, the second unit can, for example, include a splicing checksum (such as the checksum of a directly preceding or indirectly preceding block of the chain of confirmed blocks) in the unconfirmed block. Such splicing can provide additional protection against manipulation.

[0019] In this case, the second unit may be allowed to access a local copy of a representation of the transaction ledger of the distributed database system. The local copy may be stored in a node device of the distributed database system, for example, in a node device that is part of a block forming device, or in a node device with which the block forming device can communicate.

[0020] In particular, the second unit may include a proof value in the unconfirmed block to be formed. The proof value may be interpreted as proof of the legitimate interest of the block forming unit in the smooth operation of the distributed database system.

[0021] Conceivable are "relative" solutions such as proof of stake, digital signatures (so-called "permissioned ledgers"), or adapted "proof of work", such as, for example, cryptographic puzzles or "best effort proof of work", wherein the digital signature indicates a special authority or trust position of the block generator, which can be provided with certainty within the corresponding time slice.

[0022] In particular, the second unit may include a coinbase transaction into an unconfirmed block to be formed, which allows the block forming device or a node device assigned to the block forming device to be paid for forming the block.

[0023] By providing, on the one hand, the existence of a proof value in a block to be confirmed and on the other hand permitting the existence of coin-based transactions, the consensus rules of the distributed database make the formation of blocks difficult and thus the manipulation of blocks difficult, while on the other hand providing incentives for the formation of rule-compliant blocks. In this way, a distributed database system can be advantageously implemented with an excellent position of trust without the need for a central clearing house.

[0024] In response to providing the unconfirmed block thus formed by the second unit, the node device of the distributed database system can check the provided unconfirmed block, for example according to the consensus rules of the distributed database system, and can accept the checked unconfirmed block as the latest confirmed block into the transaction ledger of the distributed database system. In this way, the unconfirmed transactions contained in the unconfirmed block can be confirmed. Since the unconfirmed blocks are provided by the proposed block forming device in a timed manner, in this way, the unconfirmed transactions can be confirmed in a timed manner by the distributed database system, and the unconfirmed transactions can be inserted into the distributed database system, which includes the proposed block forming device.

[0025] The time source may be a local time source of the block forming device and / or the node device to which the block forming device is assigned, such as a chip scale atomic clock, a distributed time source of a distributed database system, such as a time synchronization protocol such as NTP (Network Time Protocol) or PTP (Precision Time Protocol) of a distributed database system, or a time source external to and remote from the block forming device and the distributed database system, such as a timer of a satellite navigation system (GNSS, such as GPS, Galileo, Beidou, Glonass), a DCF77 time transmitter or a host node, which predetermines an industrial timing cycle (such as, for example, IEEE Time Sensitive Networking, synchronized Profinet or a time frame for program execution of a programmable controller). The timing cycle received from the time source may be an absolute or relative timing cycle. A timing cycle can be understood as a sequence of absolute or relative time parameters.

[0026] The timing cycle may be received repeatedly or periodically.

[0027] The same timing cycle or the timing cycle respectively synchronized with the timing cycle of the block forming device can be provided to multiple devices or each device in the devices of the distributed database system. Therefore, the proposed block forming device can be operated according to the timing cycle of the distributed database system in time synchronization with other devices of the distributed database system.

[0028] The timing cycle may be a constant timing cycle, that is, the corresponding time slices may be of equal length.

[0029] The predetermined length of the time slice can be predetermined by the timing cycle. For example, the time slice can correspond to the period between two clock signals (or the transmitted time parameters) of the timing cycle. The predetermined length can also be an integer multiple of the period between two clock signals or the transmitted time parameters.

[0030] The third unit may be configured to time the operation of the first unit and the second unit according to the determined time slice. For example, the third unit may start the operation of the first unit at the beginning of the corresponding time slice, start the operation of the second unit after the selection by the first unit is terminated, and transmit the following signal at a predetermined time before the end of the time slice of the second unit: the signal requests the second unit to terminate the formation of unconfirmed blocks and provide the unconfirmed blocks that have been formed as well as possible up to that time in the distributed database system.

[0031] In this way, the first unit and the second unit can be designed to carry out the selection, formation and provision exactly once within the respective time slice.

[0032] Such timing can advantageously enable the use of distributed database systems for storing measurement and control values ​​and for executing program codes with control instructions implemented as smart contracts to control industrial automation devices with real-time requirements.

[0033] It should be noted that the concept of "performed exactly once" can also be understood as either not performing the selection, formation and provision during the corresponding time slice, or performing the selection, formation and provision exactly once. In other words, once started, the selection, formation and provision can be terminated during the corresponding time slice. It may also not be started, for example, if the block forming device is not activated within a given time slice.

[0034] According to one embodiment, the first unit is configured to select, during a corresponding time slice, all unconfirmed transactions provided in the distributed database system as transactions to be confirmed: the unconfirmed transactions correspond to a predefined condition.

[0035] Therefore, the proposed block forming device can advantageously ensure that all unconfirmed transactions provided corresponding to predetermined conditions are confirmed by the node devices of the distributed database system in the corresponding time slice.

[0036] The predetermined condition may be that all unconfirmed transactions provided are to be included.

[0037] The predetermined condition may contain that at least those transactions characterized as time-critical are to be included among the offered unconfirmed transactions.

[0038] The predetermined condition may contain at least those transactions that are included in the provided unconfirmed transactions: the transactions are transactions with measured values, control values ​​and / or smart contracts with control instructions for the industrial automation system.

[0039] The predetermined condition may consist in that at least those of the provided unconfirmed transactions are to be confirmed, which transactions allow a predefined minimum reward to the block forming device for their confirmation.

[0040] It is thus advantageously possible to ensure that all transactions provided, all time-critical or all unconfirmed transactions with a high reward are included in the formed block in the corresponding time slice.

[0041] According to one embodiment, the proposed block forming device has a fourth unit for receiving an activation signal. The first unit and the second unit are configured to perform the selection, forming and providing exactly once within the corresponding time slice only if the fourth unit receives the activation signal in the corresponding time slice.

[0042] The activation signal may be transmitted by a scheduling device of the distributed database system.

[0043] Accordingly, it is possible to use more than one of the proposed block forming devices in a distributed database system. Even if blocks are formed in the proposed block forming device in a predetermined timing cycle, unsolvable competition situations can be advantageously avoided in the following manner: the scheduling device activates only one of the block forming devices in the corresponding time slice with an activation signal. In this case, in view of the trust balance in the case of majority consensus in the distributed database system, it may be advantageous to use multiple block forming devices alternately. In this way, different block forming devices can be alternately allowed to receive rewards, such as rewards for successfully forming blocks, and thus a balance of cryptographic token credits can be maintained in the distributed database system. This can be advantageous in the following case: for example, when blocks are formed using proof of stake as a proof value, the distribution of cryptographic tokens between node devices is important for the manipulation security of the network.

[0044] According to other embodiments, the second unit is designed to include in the formed block the best cryptographic proof of work that can be determined by the second unit within the respective time slice.

[0045] In other words, a modified proof of work is proposed based on best efforts. For example, a cryptographic puzzle may not be completely solved, but only in the best possible way. For example, the second unit can include a freely selected value or a one-time random number (Nonce) into the formed block, and the one-time random number can be measured so that the checksum of the entire formed block including the one-time random number is as extreme as possible, such as, for example, as small as possible. If it involves a cryptographic checksum, such as a hash value, such a measurement can only be possible through trial and error. Once the block to be formed is formed in addition to the one-time random number to be measured, the trial and error can be started, and the trial and error can be ended at a predetermined time point within the corresponding time slice. In this way, the best possible proof of work within the available time can be provided within the corresponding time slice with certainty.

[0046] Accordingly, it is advantageously possible to use more than one of the proposed block forming devices simultaneously in the distributed database system. Even if blocks are formed at a predetermined timing cycle in the proposed block forming device, the resulting competition situation can be advantageously resolved in the following manner: for example, the consensus rule setting of the distributed database system, the node devices of the distributed database system confirm those blocks containing the best proof of work among a plurality of unconfirmed blocks.

[0047] Thus, even if the formation of blocks according to the proposed block formation device takes place in a timed manner, the advantages of mining (forming blocks by means of proof of work) can be achieved.

[0048] According to other embodiments, the second unit is designed to include a time stamp identifying the respective time slice in the formed block.

[0049] Correspondingly, the consensus rules of the distributed database system can be set to confirm only such unconfirmed blocks: the unconfirmed blocks contain a timestamp that matches the time slice that is current at the time of confirmation. In this way, delayed blocks or early (perhaps manipulated) blocks can be discarded advantageously.

[0050] According to the second aspect, a node device for a distributed database system is proposed, and the distributed database system includes a plurality of node devices. The node device has: a fifth unit for storing a chain of confirmed blocks, wherein the confirmed blocks represent at least one segment (Abschnitt) of a transaction ledger of the distributed database system; a sixth unit for confirming exactly one block from a plurality of unconfirmed blocks provided in the distributed database system in the corresponding time slice, so that the confirmed block is attached to the chain of confirmed blocks, wherein confirming exactly one block from a plurality of unconfirmed blocks includes: checking one, more or all of the unconfirmed blocks, selecting one of the unconfirmed blocks that successfully passes the check, and attaching the selected block as a confirmed block to the chain of confirmed blocks; and a third unit for receiving a timing cycle from a time source and determining a time slice of a predetermined length based on the timing cycle. The sixth unit is configured to perform the confirmation exactly once within the corresponding time slice.

[0051] Where appropriate, the features, definitions and advantages described when describing the proposed block forming device apply correspondingly to the proposed node device.

[0052] It can be said that the proposed node device forms a complementary counterpart to the proposed block forming device.

[0053] The proposed node device can advantageously confirm unconfirmed blocks in a predetermined timing cycle. For example, the proposed node device can use the same timing cycle to confirm unconfirmed blocks formed by the proposed block forming device in a timed manner. Thus, it can be possible to confirm unconfirmed transactions in a timed manner. Therefore, the proposed node device can give the following qualifications to the distributed database system: the qualification is for the use of industrial automation equipment with real-time requirements, and the distributed database system includes the proposed node device.

[0054] The chain of confirmed blocks stored in the fifth unit can be interpreted as a local copy of the following version of the transaction ledger: about the version, the consensus between multiple node devices is dominant or gradually formed over time. Consensus can be reached in this case in the following way: when selecting and confirming exactly one block to be confirmed, the sixth unit proceeds according to the consensus rules specified by the distributed database system. Similarly, when forming unconfirmed blocks, the block forming device of the distributed database system (such as the proposed block forming device) can preferably proceed according to the same prescribed consensus rules. Consensus rules can be established so that the behavior of the node device that complies with the rules is rewarded, and the behavior that does not comply with the rules is not worth doing, or the node device that behaves as non-compliant with the rules is automatically prohibited from further participating in consensus establishment over time. In this way, it can be guaranteed that the consensus is constructed so that the same representation of the transaction ledger is stored in the majority of the node devices in the distributed database system and preferably in all the node devices, and unauthorized manipulation is difficult or prevented.

[0055] The sixth unit can be configured to check multiple unconfirmed blocks provided in the distributed database system during the corresponding time slice according to the consensus rules, discard the unconfirmed blocks that do not meet the consensus rules, and select the block to be confirmed from the remaining unconfirmed blocks according to the consensus rules, and add the selected block to the chain of confirmed blocks and thereby confirm the selected block.

[0056] Therefore, “confirming a block from multiple unconfirmed blocks” can be understood as: checking one, multiple, or all of the unconfirmed blocks; selecting one of the unconfirmed blocks that successfully passes the check; and appending the selected block to the chain of confirmed blocks.

[0057] "Append" can be understood as appending to the last confirmed block in the chain of confirmed blocks, and as creating a copy or fork of the chain of confirmed blocks by appending at another location, that is, at a block earlier than the last confirmed block in the chain of confirmed blocks. In particular, the block to be appended can be appended according to the consensus rules to that block from the chain of confirmed blocks whose checksum corresponds to the concatenation checksum contained in the block to be appended.

[0058] The consensus rules may predetermine which of the copies or forks of the chain of confirmed blocks is considered in this case to be a valid representation of the transaction ledger of the distributed database. For example, the longest of these chains may be considered a valid representation.

[0059] Unconfirmed transactions provided in the distributed database system can be included in unconfirmed blocks by the proposed block forming device, and the unconfirmed blocks are provided in the distributed database system. The unconfirmed blocks provided in the distributed database system can be checked by the corresponding node devices in the node devices (as described above) and confirmed by attaching to the transaction ledger of the distributed database (the corresponding local copy of the transaction ledger). Thereby, the transactions contained in the corresponding blocks can be confirmed. According to the proposed solution, according to a predetermined, preferably cyclic timing cycle, both the formation of unconfirmed blocks and the confirmation of unconfirmed blocks are carried out in a time-synchronous manner, and thus the confirmation of unconfirmed transactions is carried out.

[0060] In particular, the sixth unit may be configured to wait in corresponding time slices until the formation and provision of blocks by one or more block forming devices of the distributed database system is terminated, and then select and confirm one of the formed and provided unconfirmed blocks.

[0061] In the proposed timing, the corresponding time slice can be subdivided into a time section for providing unconfirmed transactions, a section for forming unconfirmed blocks, a section for providing unconfirmed blocks, and a section for confirming the provided unconfirmed blocks. Alternatively, it is possible to alternately form and provide blocks in a time slice, and select and confirm blocks in the next time slice.

[0062] According to other specific embodiments, the sixth unit is designed to select exactly one block for validation as a function of at least one criterion.

[0063] If a plurality of block generators are provided in the network, it is conceivable that more than one unconfirmed block is provided during a corresponding time slice. In such a competition situation, the consensus rule can predetermine one or more criteria according to which the provided unconfirmed blocks are to be confirmed.

[0064] In one variant, the criterion content is "the number and type of transactions included in the block".

[0065] For example, a block having the most unconfirmed transactions among a plurality of unconfirmed blocks may be selected. Thus, it is advantageously possible to ensure a high transaction throughput of the distributed database system.

[0066] For example, a block of a plurality of unconfirmed blocks may be selected that has the most transactions of a certain type. Thus, it is advantageously possible to prioritize certain transactions, such as, for example, time-critical transactions.

[0067] In one variant, the criterion is “the quality of the cryptographic proof of work included by the block”.

[0068] For example, the following block among a plurality of unconfirmed blocks can be preferred: the block that solves the cryptographic puzzle with higher quality, for example, the block with the smallest one-time random value as proof of work. The quality of the cryptographic proof of work may be essentially unpredictable or random. Therefore, it is advantageously possible to ensure that the following blocks are preferred in different time slices: the blocks originate from different node devices or block forming devices. As long as the confirmation of the block is used to set the reward for the node device that has formed the block, the balance of the cryptographic token credit can be ensured in this way in the distributed database system.

[0069] In one variant, the criterion content is "the quality and / or computational complexity of the corresponding transactions included in the block".

[0070] The computational complexity of the corresponding transaction can in particular relate to the following computational load: the block forming device that has formed the block has applied the computational load in order to check the validity of the transaction. As long as the transaction contains or references a smart contract, the computational load can be considerable. Therefore, the block forming device that checks such a transaction may reserve less computing capacity within the corresponding time slice for determining the best possible proof of work. Therefore, if only the criterion "quality of the proof of work" is applied, it may be unlikely that the relevant block is selected for confirmation by the node device. In addition, however, if the criterion "quality of the corresponding transaction" is also applied, this effect can be compensated and it can be advantageously prevented that unconfirmed blocks with complex transactions are disadvantageous when selected for confirmation.

[0071] Other examples of transaction quality include the number or amount of crypto tokens (the larger the amount, the higher the quality of the transaction), the type of transaction (the more time-critical the transaction, the higher the quality of the transaction), the amount of data contained in the transaction, etc.

[0072] In one variant, the content of the criterion is “the consistency of the timestamp contained in the block with the corresponding time slice”.

[0073] By means of the standard, it is advantageously possible to establish a correspondence between the sequence of confirmed transactions and the sequence of unconfirmed transactions in the transaction ledger of the distributed database system. In other words, it is possible to avoid the delayed inclusion of blocks that are delayed in time or the premature confirmation of blocks with future timestamps (such as, for example, manipulated blocks). The reliability and real-time capability of the distributed database system can thus be improved.

[0074] It should be noted that, in addition to the case where the timestamp included in the block indicates the corresponding time slice, "consistency" can also be understood as the case where the timestamp included in the block indicates the time slice directly or indirectly before the corresponding time slice.

[0075] In one variant, the content of the criterion is “whether the block forming device which has provided the block is a block forming device for which an activation signal transmitted in the distributed database system during the corresponding time slice is determined”.

[0076] According to this standard, it is advantageously possible to prevent a block-forming device which is not explicitly activated (and thus can act maliciously) from sneaking blocks into the distributed database system.

[0077] According to other embodiments, the sixth unit is configured to select exactly one block for confirmation based on the following criterion: whether the block includes all unconfirmed transactions provided in the distributed database system during the corresponding time slice: the unconfirmed transactions correspond to predefined conditions.

[0078] The above description regarding the “predefined conditions” in the embodiment of the block forming device applies correspondingly.

[0079] If such a criterion is part of the consensus rules of a distributed database system, each block-forming device of the distributed database system is interested in including all unconfirmed transactions corresponding to predefined conditions that are provided in the distributed database system in the corresponding time slice into an unconfirmed block formed by the block-forming device, since the block would otherwise not be confirmed and the block-forming device would not receive any reward accordingly.

[0080] Therefore, the present standard can advantageously ensure that, in each time slice, all unconfirmed transactions corresponding to predefined conditions provided in the relevant time slice are included in unconfirmed blocks by the block forming device of the distributed database system during the same time slice, and are confirmed by the node device of the distributed database system by confirming the unconfirmed blocks during the same time slice or the following time slice.

[0081] The criteria for selecting blocks for validation according to the above variants and embodiments can be combined in any desired manner.

[0082] According to other implementation forms, the proposed node device has the proposed block forming device.

[0083] In other words, not only the timed block formation function implemented by the proposed block formation device but also the timed confirmation function implemented by the proposed node device described above can be combined in the proposed node device. It should be understood that in this case, for the node device including the block formation device, the third unit of the node device and the third unit of the integrated block formation device can be the same. In other words, only one third unit can be provided.

[0084] Preferably, one node device (particularly preferably each node device) among the node devices of the distributed database system can both form unconfirmed blocks in a timed manner and confirm unconfirmed blocks provided by another node device in a timed manner in a timed manner.

[0085] According to other implementation forms, a distributed database system is proposed, the distributed database system comprising a plurality of proposed node devices. The proposed node devices are configured to jointly manage a transaction ledger of the distributed database system. At least one of the node devices comprises the proposed block forming device. The node devices may operate in a time-synchronized manner according to a timing cycle of the distributed database system.

[0086] Since the node devices of the proposed distributed database system can be operated in a time-synchronized manner, it is possible to ensure particularly reliably that unconfirmed transactions can be confirmed within a time slice derived from the timing cycle.

[0087] A plurality of node devices can be operated in a time-synchronous manner in the following manner: the timing cycle to be received by the respective node device is synchronized with the timing cycle of the distributed database system. Alternatively, the respective node devices may be configured to receive the same timing cycle of the distributed database system.

[0088] Therefore, the timing cycle to be received by the corresponding node device or the timing cycle to be received by the corresponding node device is time synchronized with the timing cycle of the distributed database system.

[0089] The operation of the time synchronization of the node devices of the distributed database system can be understood in particular as follows:

[0090] The timing or corresponding time slices of the timed block formation function (of the first to third units) and the timed confirmation function (of the fifth, sixth and third units) of the node device of the distributed database system are preferably synchronized. The timing can be understood as using the same timing, or the corresponding time slices are superimposed, or the timing of the timed block formation function and the timing of the timed confirmation function or the corresponding time slices are shifted by a fixed time offset. However, it is also possible that the timing of the timed block formation function is performed in a timing manner independent of the timing of the timed confirmation function. Other variations of timing can be conceived. For example, the timing cycle of the timed confirmation function can be formed by dividing the timing cycle of the timed block formation function. For example, through the timed confirmation function, the corresponding blocks can be formed after multiple (for example, two or four) timing cycles of the timed block formation function. It is also conceivable that the timing cycle is not fixed, but is adaptively adapted according to the number and / or type of unconfirmed transactions provided.

[0091] In particular, more than one of the node devices may comprise a corresponding block forming device as proposed. The distributed database system may have a scheduling device which is designed to transmit an activation signal to each of the block forming devices in a corresponding time slice.

[0092] In this case, the scheduling device can be set up to determine which of the node devices (block forming devices) to transmit the activation signal in the corresponding time slice according to a predetermined sequence, randomly or based on the characteristics of the corresponding node devices (such as, for example, some encrypted tokens maintained by the corresponding node devices).

[0093] According to other implementation forms, the distributed database system comprises a central time source, wherein the following time source is the central time source: the third unit of the respective node device receives the timing cycle from said time source.

[0094] The central time source may be a DCF77 time transmitter, a GNSS timer, an NTP / PTP server or a master node, etc., which predefines the industrial timing cycle.

[0095] By using a central time source, the structure of the corresponding node devices can be simplified, since only the timing cycle needs to be received and in the case of the node devices, no local timer is required.

[0096] According to other implementation forms, an industrial automation system is proposed, which includes the proposed distributed database system and a plurality of automation components that can be operated according to a timing cycle. The distributed database system can be operated to adjust and / or control the plurality of automation components. The timing cycle of the distributed database system is synchronized with the timing cycle of the plurality of automation components, or is synchronized with an integer multiple of the timing cycle of the plurality of automation components.

[0097] Examples of automation components are: sensors, which are designed to measure physical states in industrial equipment; actuators, which are designed to influence physical states in industrial equipment; control units, which implement control logic for determining control values ​​for the actuators based on the measured values ​​of the sensors; and so on.

[0098] The distributed database system may be operable, for example, in the following manner for controlling a plurality of automation components: a section of the control logic of the automation system is stored in the form of a smart contract confirmed in the transaction ledger of the distributed database system. Similarly, the measured values ​​supplied by the plurality of automation components and / or the control values ​​to be transmitted to the plurality of automation components can be confirmed in the form of a transaction in the transaction ledger of the distributed database system. Through this, transparency, prevention of manipulation and traceability (Nachvollziehbarkeit) of the operation of the automation system can be advantageously achieved. Through the timed operation of the proposed database system, the timed operation of the proposed database system can in particular enable confirmation of unconfirmed transactions in a timed manner and thus execute smart contracts in a timed manner, even if high real-time requirements are imposed on the control logic of the automation system, these and other advantages of the distributed database system based on the blockchain can be achieved. In particular, by synchronizing the timing cycle of the distributed database system with the timing cycle of the automation system, the individual control steps of the automation system can be executed in a traceable manner and recorded in a manner that prevents manipulation by the distributed database system.

[0099] In a variant of the proposed industrial automation system and / or the proposed distributed database system, it is conceivable that the distributed database system stores multiple transaction ledgers, each of which is represented by a chain of confirmed blocks, wherein one chain from the multiple chains represents a primary transaction ledger and the remaining chains from the multiple chains represent corresponding secondary transaction ledgers of the distributed database system.

[0100] Chains representing secondary transaction ledgers (“sidechains”) can run using time slices that are integer factors of the time slices used to run the chain representing the primary transaction ledger (“main chain”).

[0101] The main chain and the side chain can run according to different consensus rules. In this way, a lower level of cryptographic protection may be implemented in the side chain, but the operation of the side chain can be achieved with lower resource overhead. In contrast, a high level of cryptographic protection may be implemented in the main chain.

[0102] In this case, “operation of a chain” may be understood to mean the operation of those of the node devices which store the corresponding chain in their fifth unit.

[0103] In this way, a load distribution on the chains can advantageously be achieved, wherein transactions of lower importance are confirmed in the side chain and transactions of higher importance are confirmed in the main chain.

[0104] Via the hash value stored in the main transaction ledger, etc., the corresponding secondary transaction ledger can be linked to the main transaction ledger at regular block intervals by the selected blocks of the secondary transaction ledger. Thus, the high level of protection provided by the main chain can be at least partially extended to the side chain.

[0105] The corresponding units (e.g., the corresponding units in the first to sixth units) can be implemented in hardware technology and / or in software technology. In the hardware technology implementation, the corresponding unit can be configured as a device or as a part of a device, for example, as a computer or as a microprocessor or as a control computer of a vehicle. In the software technology implementation, the corresponding unit can be configured as a computer program product, as a function, as a routine, as a part of a program code or as an executable object.

[0106] According to a third aspect, a block formation method for a distributed database system including a plurality of node devices is proposed. The block formation method comprises: selecting a plurality of transactions to be confirmed from a plurality of unconfirmed transactions provided in the distributed database system; forming an unconfirmed block from the selected plurality of unconfirmed transactions, wherein the validity of the corresponding selected unconfirmed transactions is checked, and the corresponding selected unconfirmed transactions are discarded if the check fails, or the corresponding selected unconfirmed transactions are included in the unconfirmed block, and the unconfirmed block is provided in the distributed database system; and receiving a timing cycle from a time source, and determining a time slice of a predetermined length based on the timing cycle. In this case, the selection, formation and provision are performed exactly once within the corresponding time slice.

[0107] The embodiments and features described for the proposed block forming device according to the first aspect apply correspondingly to the proposed block forming method according to the third aspect.

[0108] According to a fourth aspect, a block confirmation method for a distributed database system is proposed, wherein the distributed database system includes a plurality of node devices. The block confirmation method includes: storing a chain of confirmed blocks, wherein the confirmed blocks represent the main ledger of the distributed database; confirming exactly one block from a plurality of unconfirmed blocks provided in a corresponding time slice in the distributed database system, wherein the confirmed block is attached to the chain of confirmed blocks, wherein confirming exactly one block from a plurality of unconfirmed blocks includes: checking one, a plurality of or all of the unconfirmed blocks, selecting one of the unconfirmed blocks that successfully passes the check and attaching the selected block as a confirmed block to the chain of confirmed blocks; and receiving a timing cycle from a time source, and determining a time slice of a predetermined length based on the timing cycle. In this case, confirmation is performed exactly once within the corresponding time slice.

[0109] The implementation forms and features described for the proposed node device according to the second aspect are correspondingly applicable to the proposed block confirmation method according to the fourth aspect.

[0110] Furthermore, a computer program product is proposed which causes one of the methods explained above to be carried out on a program-controlled device.

[0111] The computer program product (such as, for example, a computer program means) can be provided or supplied, for example, as a program medium, such as, for example, a memory card, a USB stick, a CD-ROM, a DVD, or also in the form of a downloadable file by a server in the network. For example, in a wireless communication network, this can be done by transmitting a corresponding file with the computer program product or the computer program means.

[0112] More detailed details and other variants of a distributed database system based on blockchain technology are explained below, and the proposed block forming device, the proposed node device and the proposed method can be applied to the distributed database system.

[0113] Unless otherwise indicated in the following description, the terms "execute", "calculate", "in a computer-aided manner", "calculate", "ascertain", "generate", "configure", "reconstruct" and the like preferably relate to actions and / or processes and / or processing steps that change data and / or generate data and / or transform data into further data, wherein the data can in particular be presented as physical variables or can exist as physical variables, for example as electrical impulses or can exist as electrical impulses. In particular, the expression "computer" should be interpreted as broadly as possible in order to cover in particular all electronic devices with data processing properties. Computers can therefore be, for example, personal computers, servers, programmable logic controllers (SPS), handheld computer systems, pocket PC devices, mobile radio devices and other communication devices that can process data in a computer-aided manner, processors and other electronic devices for data processing.

[0114] In connection with the present invention, “in a computer-assisted manner” may be understood to mean, for example, the implementation of a method in which, in particular, a processor carries out at least one method step of the method.

[0115] In connection with the present invention, a processor can be understood as, for example, a machine or an electronic circuit. The processor can be, in particular, a main processor (Central Processing Unit, CPU), a microprocessor or a microcontroller (e.g., an application-specific integrated circuit) or a digital signal processor, possibly combined with a storage unit for storing program instructions, etc. The 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 (Graphics Processing Unit). The processor can also be understood as a virtualized processor, a virtual machine or a soft CPU. For example, it can also be a programmable processor that is equipped with a configuration step for executing the method according to the present invention, or is configured by a configuration step so that: the programmable processor implements the method, component, module or other aspects and / or sub-aspects of the present invention according to the present invention.

[0116] In connection with the present invention, a “storage unit”, “storage module” etc. may be understood as a volatile memory, for example in the form of a working memory (RAM) or as a permanent memory, such as a hard disk or a data carrier.

[0117] In connection with the present invention, a "module" can be understood as, for example, a processor and / or a storage unit for storing program instructions. For example, the processor is specifically set up to execute program instructions so that the processor performs functions in order to implement or realize the method according to the present invention or the steps of the method according to the present invention. A module can also be, for example, a node of a distributed database system, which implements, for example, specific functions / features of the corresponding module. The corresponding module can also be constructed as a separate or independent module, for example. For this purpose, the corresponding module can include other elements, for example. These elements are, for example, one or more interfaces (for example, database interfaces, communication interfaces—for example, network interfaces, WLAN interfaces) and / or evaluation units (for example, processors) and / or storage units. With these interfaces, for example, data can be exchanged (for example, received, transmitted, sent or provided). With the help of the evaluation unit, for example, data can be compared, checked, processed, distributed or calculated in a computer-aided manner and / or automatically. With the help of the storage unit, for example, data can be stored, retrieved (abgerufen) or provided in a computer-aided manner and / or automatically.

[0118] In connection with the present invention, “comprising” (especially with regard to data and / or information) may be understood to mean, for example, that corresponding information or corresponding data are stored (in a computer-aided manner) in a data structure / data record (which in turn is stored, for example, in a memory unit).

[0119] In connection with the present invention, "assignment", in particular with respect to data and / or information, may be understood to mean, for example, the assignment of data and / or information in a computer-aided manner. For example, for this purpose, second data may be assigned to first data by means of a storage address or a unique identifier (English: unique identifier (UID)), for example, in that the first data are stored together with the storage address or the unique identifier of the second data in a data record.

[0120] In connection with the present invention, "providing" (especially with respect to data and / or information) may be understood to mean providing, for example, in a computer-aided manner. The provision is performed, for example, via an interface (for example a database interface, a network interface, an interface to a storage unit). Via the interface, for example, the corresponding data and / or information may be transmitted and / or sent and / or retrieved and / or received during the provision.

[0121] In connection with the present invention, "providing" can also be understood as, for example, loading or storing a transaction with corresponding data. This can be performed, for example, on a storage module or by a storage module. "Providing" can also be understood as, for example, transmitting (or sending or transferring) corresponding data from one node of a blockchain or distributed database system (or its infrastructure) to another node.

[0122] In connection with the present invention, a “smart contract process” may be understood in particular to mean the execution of program code (eg control instructions) by a distributed database system or its infrastructure during the process.

[0123] In connection with the present invention, a "checksum" (e.g., a data block checksum, a data checksum, a node checksum, a transaction checksum, a splicing checksum, etc.) can be understood as, for example, a cryptographic checksum or a cryptographic hash (kryptographischerHash) or a hash value, which is formed or calculated, in particular, by means of a cryptographic hash function, via a data record and / or a sub-region of one or more transactions and / or data blocks in a data and / or transaction (e.g., a block header of a block of a blockchain, or a data block header of a data block of a distributed database system, or only a part of a transaction of a data block). The checksum can be, in particular, a checksum / multiple checksums or hash values / multiple hash values ​​of a hash tree (e.g., a Merkle tree, a Patricia tree). In addition, a "checksum" can also be understood, in particular, as a digital signature or a cryptographic message authentication code (ein kryptographischer Nachrichtenauthentisierungscode). With the help of the checksum, for example, cryptographic protection / prevention of manipulation for transactions and the data (records) stored therein can be implemented at different levels of the database system. For example, if high security is required, the checksum is generated and checked, for example, at the transaction level. If less high security is required, the checksum is generated and checked, for example, at the block level (e.g., on the entire data block or only on parts of the data block and / or parts of the transaction).

[0124] In connection with the present invention, a "data block checksum" can be understood as a checksum that is calculated, for example, via part or all of the transactions of a data block. The node can then, for example, use the data block checksum to check / ascertain the integrity / authenticity of the corresponding part of the data block. Additionally or alternatively, in particular, the data block checksum can also be formed via the transactions of the preceding data block / predecessor (Vorgaenger) data block of the data block. The data block checksum can also be implemented here, in particular, with the help of a hash tree (for example, a Merkle tree [1] or a Patricia tree), wherein the data block checksum is in particular the root checksum of a Merkle tree or a Patricia tree or a binary hash tree. In particular, transactions are protected (for example, when using transaction checksums) with the help of other checksums from a Merkle tree or a Patricia tree, wherein in particular these other checksums are leaves in a Merkle tree or a Patricia tree. The data block checksum can thus, for example, protect transactions in the following manner: a root checksum is formed from these other checksums. The data block checksum can be calculated in particular for the transaction of a certain data block in the data blocks. In particular, such a data block checksum can be entered into the data blocks following the certain data block, in order to splice these following data blocks, for example, with the preceding data block, and thereby make the integrity of the distributed database system, in particular, verifiable. In this way, the data block checksum can, for example, assume the function of a splicing checksum or enter the splicing checksum. The header of a data block, for example a new data block or a data block for which a data block checksum has been formed, can, for example, include the data block checksum.

[0125] In connection with the present invention, a "transaction checksum" may be understood as a checksum that is formed, in particular, via a transaction of data blocks. In addition, for example, the calculation of a data block checksum for a corresponding data block may be accelerated, since, for example, an already calculated transaction checksum may be immediately used, for example, as a leaf of a Merkle tree.

[0126] In connection with the present invention, a “joint checksum” may be understood to mean a checksum which, in particular, describes or refers to a corresponding data block of a distributed database system or to a previous data block of a distributed database system (often referred to in the specialist literature as a “previous block hash”) [1]. For this purpose, a corresponding joint checksum is formed, in particular for the corresponding previous data block. As a joint check, for example, a data block checksum or a transaction checksum of a data block (that is to say an existing data block of a distributed database system) may be used in order to join a new data block to an (existing) data block of a distributed database system. However, it is also possible, for example, to form a checksum via the header of a previous data block or via the entire previous data block and to use this checksum as a joint checksum. This can also be calculated, for example, for a plurality of or all previous data blocks. It is also possible, for example, to form a joint checksum via the header of a data block and a data block checksum. However, the corresponding data blocks of the distributed database system preferably respectively include the following splicing checksums: the splicing checksum has been calculated for the previous data block (especially more preferably the directly previous data block) of the corresponding data block, or the splicing checksum relates to the previous data block (especially more preferably the directly previous data block) of the corresponding data block. For example, it is also possible that the corresponding splicing checksum is also formed only via a part of the corresponding data block (for example the previous data block). Through this, for example, the following data block can be realized: the data block includes an integrity-protected part and an unprotected part. In this way, for example, the following data block can be realized: the integrity-protected part of the data block is unchanged, while the unprotected part of the data block can still be changed later. Integrity protection is to be understood here in particular as that changes in integrity-protected data can be detected with the help of the checksum.

[0127] For example, the data stored in the transaction of data blocks can be provided in different ways. Instead of data, such as user data such as measurement data, measurement values, control values ​​or data / ownership relationships for assets, the transaction of data blocks can, for example, only include a checksum for these data. The corresponding checksum can be implemented in different ways. This can be, for example: a corresponding data block checksum of a data block (with corresponding data) of another database or a distributed database system, a transaction checksum of a data block with corresponding data (of a distributed database system or another database) or a data checksum already formed from the data.

[0128] In addition, the corresponding transaction may also include a reference or specification of a storage location (e.g. the address of a file server and a specification of where the corresponding data are to be found on the file server; or the address of a further distributed database containing the data). The corresponding data may then also be provided, for example, in other transactions of other data blocks of the distributed database system (e.g. if the corresponding data and the associated checksum are contained in different data blocks). However, it is also conceivable, for example, that these data are provided via another communication channel (e.g. via another database and / or a cryptographically protected communication channel).

[0129] For example, in addition to the checksum, an additional data record (e.g. a reference or description of a storage location) can also be stored in the corresponding transaction, which in particular describes the storage location at which the data can be retrieved. This is particularly advantageous in order to keep the data size of the blockchain or distributed database system as small as possible.

[0130] In connection with the present invention, "securely protected" may be understood, for example, as protection that is achieved, in particular, by cryptographic methods. This can be achieved, for example, by using a distributed database system to provide or transmit or send the corresponding data / transactions. This is preferably achieved by combining different (cryptographic) checksums in such a way that these (cryptographic) checksums act together, in particular synergistically, in order, for example, to improve the security or cryptographic security of the data for the transaction. In other words, in connection with the present invention, "securely protected" may also be understood, in particular, as "cryptographically protected" and / or "protected against manipulation". In this context, "protected against manipulation" may also be referred to as "integrity protected".

[0131] In relation to the present invention, "the data block / data block of the spliced ​​distributed database system" can be understood, for example, that the data blocks respectively include the following information (such as a splicing checksum): the information refers to one or more other data blocks of the distributed database system or references the one or more other data blocks [1][4][5].

[0132] In connection with the present invention, "insertion into a distributed database system" etc. can be understood, for example, to transmit one or more transactions or data blocks with transactions to one or more nodes of the distributed database system. If these transactions (for example by the one / more nodes) are successfully verified, for example, these transactions are joined as new data blocks to at least one existing data block of the distributed database system [1][4][5]. For this purpose, the corresponding transactions are stored, for example, in the new data block. In particular, the verification and / or joining can be carried out by a trusted node (for example a mining node, a blockchain oracle or a blockchain platform). In particular, a blockchain platform can be understood here as a blockchain as a service (in English: Blockkette als Service), as is particularly suggested by Microsoft or IBM. In particular, the trusted nodes and / or nodes can respectively store the node checksum (for example a digital signature) in the data block (for example in the data block verified and generated by them, which is then joined), so as to particularly enable the identification of the creator of the data block and / or the identification of the node. In this case, the node checksum indicates which node has, for example, joined the corresponding data block to at least one other data block of the distributed database system.

[0133] In connection with the present invention, a "transaction" or "multiple transactions" may be understood as, for example, a smart contract [4][5], a data structure or a transaction data record, wherein the transaction data record in particular comprises one of the transactions or comprises multiple transactions respectively. In connection with the present invention, a "transaction" or "multiple transactions" may also be understood as data of a transaction, for example, a data block of a blockchain (Blockchain in English). A transaction may in particular include, for example, a program code for implementing a smart contract. For example, in connection with the present invention, a transaction may also be understood as a control transaction and / or a confirmation transaction. Alternatively, a transaction may be, for example, a data structure that stores data (for example, control instructions and / or contract data and / or other data, such as video data, user data, measurement data, etc.).

[0134] In particular, "storing transactions in a data block", "storing transactions" etc. are to be understood as direct storage or indirect storage. Direct storage can be understood here, for example, that the corresponding data block (of a distributed database system) or the corresponding transaction (of a distributed database system) includes the corresponding data. Indirect storage can be understood here, for example, that the corresponding data block or the corresponding transaction includes a checksum for the corresponding data and optionally an additional data record for the corresponding data (for example a reference or description of a storage location), and the corresponding data is therefore not directly stored in the data block (or transaction) (that is, instead of this, only a checksum for these data is stored). In particular, when storing transactions in data blocks, the checksum can be verified, for example, as explained, for example, in the section "Insertion into a Distributed Database System".

[0135] In connection with the present invention, a "program code" (e.g. a smart contract) may be understood as, for example, a program instruction or a plurality of program instructions, which are in particular stored in one or more transactions. The program code is in particular executable and is executed, for example, by a distributed database system. This can be achieved, for example, with the aid of an execution environment (e.g. a virtual machine), wherein the execution environment or the program code is preferably Turing-complete. The program code is preferably executed by the infrastructure of a distributed database system [4] [5]. In this case, for example, the virtual machine is implemented by the infrastructure of the distributed database system.

[0136] In connection with the present invention, a "smart contract" may be understood as, for example, an executable program code [4] [5] (see in particular the definition of "program code"). The smart contract is preferably stored in a transaction of a distributed database system (e.g., a blockchain), for example in a data block of the distributed database system. For example, the smart contract may be executed in the same manner as described in the definition of "program code" (in particular in connection with the present invention).

[0137] In connection with the present invention, "proof of work" or "Proof-of-Work" may be understood, for example, as solving a computationally intensive task, which in particular has to be solved depending on the content / content of a data block of a certain transaction [1][4][5]. Such computationally intensive tasks are also known as cryptographic puzzles, for example.

[0138] In connection with the present invention, a “distributed database system” (which may also be referred to as a distributed database) may be understood to mean, for example, a decentralized distributed database, a blockchain, a distributed ledger, a distributed storage system, a system based on distributed ledger technology (DLT) (DLTS), a revision-resistant database system, a cloud, a cloud service, a blockchain in the cloud or a peer-to-peer database. For example, different implementations of a blockchain or a DLTS may also be used, such as a blockchain or a DLTS implemented, for example, with the aid of a directed acyclic graph (DAG), a cryptographic puzzle, a hash graph or a combination of the aforementioned implementation variants [6][7]. For example, different consensus rules or consensus methods (consensus algorithms) may also be implemented. For example, this can be a consensus method using cryptographic puzzles, a gossip algorithm, virtual voting or a combination of the methods mentioned (e.g. a gossip algorithm combined with virtual voting) [6][7]. For example, if a blockchain is used, this can be implemented in particular using a Bitcoin-based implementation or an Ethereum-based implementation [1][4][5]. A "distributed database system" can also be understood, for example, as a distributed database system in which at least part of its nodes and / or devices and / or infrastructure is implemented via the cloud. For example, the corresponding components are implemented as nodes / devices in the cloud (e.g. as virtual nodes in a virtual machine). For example, this can be done with the help of VMWare, Amazon Web Services or Microsoft Azure. Due to the high flexibility of the described implementation variants, in particular, sub-aspects of the implementation variants mentioned can also be combined with each other, for example by using a hash map as a blockchain, wherein the blockchain itself can also be non-blockchained, for example.

[0139] If, for example, a directed acyclic graph (DAG) is used (e.g. IOTA or Tangle), in particular the transactions or blocks or nodes of the graph are connected to one another via directed edges. This means in particular that (all) edges (always) have the same direction, similar to, for example, time. In other words, it is in particular not possible to start running or jump to transactions or blocks or nodes of the graph in reverse (that is to say in opposition to the common same direction). Acyclicity here means in particular that when traversing the graph, there are no cycles.

[0140] The distributed database system may be, for example, a public distributed database system (eg, a public blockchain), or a closed (or private) distributed database system (eg, a private blockchain).

[0141] For example, if a public distributed database system is involved, this means that new nodes and / or devices can join the distributed database system or be accepted by the distributed database system without requiring proof of authority or verification or registration information or credentials. In particular, in this case, the operators of the nodes and / or devices can remain anonymous.

[0142] If the distributed database system is, for example, a closed distributed database system, new nodes and / or devices require, for example, valid proof of authority and / or valid verification information and / or valid credentials and / or valid registration information in order to be able to join the distributed database system or in order to be accepted by the distributed database system.

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

[0144] In connection with the present invention, a "data block", which may also be referred to as a "session" or "block" depending on the context and the implementation, may be understood to be, for example, a data block of a distributed database system (e.g., a blockchain or a peer-to-peer database), which is implemented in particular as a data structure and preferably comprises one or more of the transactions. In one embodiment, for example, the database (or database system) may be a DLT-based system (DLTs) or a blockchain, and the data block may be a block of the blockchain or DLTs. The data block may include, for example, a specification of the size of the data block (data size in bytes), a data block header (block header in English), a transaction counter and one or more transactions [1]. The data block header may include, for example, a version, a concatenation checksum, a data block checksum, a timestamp, a proof of work and a one-time random number (one-time value, random value or counter for proof of work) [1] [4] [5]. For example, a data block may also be just a specific storage area or address area of ​​the total data stored in the distributed database system. In this way, for example, non-blocked (in English, blockless) distributed database systems such as, for example, IoT Chain (ITC), IOTA and Byteball can be realized. In this case, in particular, the functions of the blocks of the blockchain and the functions of the transactions are combined with each other, so that, for example, the transaction itself protects (that is, is stored in a secure manner in particular) the sequence or chain of transactions (of the distributed database system). For this purpose, for example, the transactions themselves can be spliced ​​with each other using a splicing checksum, in which case the individual checksums or transaction checksums of one or more transactions are preferably used as the following splicing checksum: the splicing checksum is stored together in the corresponding new transaction when the new transaction is stored in the distributed database system. In this embodiment, a data block can also include, for example, one or more transactions, wherein in the simplest case, for example, a data block corresponds to a transaction.

[0145] In connection with the present invention, a "one-time random number" may be understood to mean, for example, a cryptographic one-time random number (eine kryptographische Nonce) (an abbreviation for "used only once" [2] or "number used once"). In particular, a one-time random number designates a single number or a letter combination that is preferably used only once in the corresponding context (e.g. transaction, data transmission).

[0146] In connection with the present invention, a “previous data block of a (determined) data block of a distributed database system” can be understood as, for example, a data block of a distributed database system, in particular directly preceding a (determined) data block. Alternatively, a “previous data block of a (determined) data block of a distributed database system” can also be understood as, in particular, all data blocks of a distributed database system preceding a determined data block. In this way, a splicing checksum or a transaction checksum can be formed, in particular only via the data block (or its transactions) directly preceding a determined data block, or via all data blocks (or its transactions) preceding the first data block.

[0147] In connection with the present invention, a "blockchain node", "node", "node of a distributed database system", "node device" etc. may be understood as, for example, a device (e.g. a field device, a mobile phone), a computer, a smartphone, a client or a user, which performs operations (using) a distributed database system (e.g. a blockchain) [1][4][5]. Such a node may, for example, execute transactions of a distributed database system or its data blocks, or insert or splice new data blocks with new transactions into a distributed database system with the aid of new data blocks. In particular, the verification and / or splicing may be performed by a trusted node (e.g. a mining node) or only by a trusted node. For example, a trusted node is a node that has additional security measures (e.g. firewalls, access restrictions to the node, etc.) in order to prevent manipulation of the node. Alternatively or additionally, for example, when splicing a new data block with a distributed database system, the trusted node may store a node checksum (e.g. a digital signature or a certificate) in the new data block. In this way, in particular, a proof may be provided that the corresponding data block has been inserted by a certain node or that it originates. Devices (e.g. corresponding devices) are, for example, devices of technical systems and / or industrial equipment and / or automation networks and / or production plants, which are in particular also nodes of a distributed database system. In this case, these devices can be, for example, field devices or devices in the Internet of Things, which are in particular also nodes of a distributed database system. The nodes can also include, for example, at least one processor in order to, for example, execute their computer-implemented functions.

[0148] In connection with the present invention, a "blockchain oracle" or the like may be understood, for example, as a node, device or computer having a security module, which is implemented, for example, by means of a software protection mechanism (e.g. cryptographic methods), a mechanical protection device (e.g. a lockable housing) or an electrical protection device (e.g. a tamper-proof or protection system that deletes the data of the security module without allowing the use / disposal of the blockchain oracle). The security module may include, for example, a cryptographic key, which is necessary for calculating a checksum (e.g. a transaction checksum or a node checksum).

[0149] In connection with the present invention, a "computer" or "device" can be understood as, for example, a computer (system), a client, a smartphone, a device or a server, which are respectively arranged outside the blockchain or are not users of a distributed database system (e.g., a blockchain) (that is, they do not perform operations with the distributed database system, or only query it, but do not perform transactions, insert data blocks or calculate proof of work). Alternatively, a computer can also be understood as a node of a distributed database system. In other words, a device can also be understood as a node of a distributed database system, or can also be understood as a device outside the blockchain or distributed database system. Devices outside the distributed database system can, for example, access data of the distributed database system (e.g., transactions or control transactions), and / or be controlled (angesteuert) by a node (e.g., by means of a smart contract and / or a blockchain oracle). If, for example, a control device or a control device of a device (e.g., a device constructed as a node or a device outside the distributed database system) is implemented by a node, this can be done, for example, by means of a smart contract, which is stored in particular in a transaction of the distributed database system.

[0150] Other possible embodiments of the present invention also include the combination of features or embodiments described above or below with respect to the embodiments that are not explicitly mentioned. Here, those skilled in the art also add individual aspects as improvements or supplements to the corresponding basic forms of the present invention.

[0151] Further advantageous embodiments and aspects of the invention are the subject matter of the dependent claims and of the exemplary embodiments of the invention described below. The invention is further explained in more detail with reference to the attached figures, based on preferred embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0152] Figure 1 Schematically illustrates a block forming device according to a first embodiment;

[0153] Figure 2A flow chart showing a block forming method according to a first embodiment;

[0154] Figure 3 schematically illustrates a node device according to a second embodiment;

[0155] Figure 4 A flowchart of a block confirmation method according to a second embodiment is shown;

[0156] Figure 5 Schematically illustrates a node device according to an improved solution of the first and second embodiments;

[0157] Figure 6 illustrates a distributed database system according to a third embodiment;

[0158] Figure 7 The diagram illustrates a timing cycle of a distributed database system according to a variation of the third embodiment;

[0159] Figure 8 schematically illustrates an unconfirmed block according to an embodiment;

[0160] Fig. 9 illustrates a transaction ledger of a distributed database system according to a variation of the third embodiment; and

[0161] Fig.10 A distributed database system according to a fourth embodiment is illustrated.

[0162] In the figures, identical or functionally identical elements have been provided with the same reference symbols, unless stated otherwise. DETAILED DESCRIPTION

[0163] According to the first embodiment, Figure 1 The block forming device 10 is schematically illustrated, and Figure 2 The block forming apparatus 10 and the block forming method according to the first embodiment are now based on Figure 1 and Figure 2 to describe.

[0164] The block forming device 10 has a first unit 1, a second unit 2, and a third unit 3. In a distributed database system (not shown) to which the block forming device 10 belongs, a plurality of unconfirmed transactions 41, 42, 43 are provided. Therefore, the block forming device 10 is also provided with the number of unconfirmed transactions 41, 42, 43.

[0165] The block forming device 10 is configured to form a corresponding unconfirmed block 61 from selected transactions among the unconfirmed transactions 41, 42, and 43 in a timed manner, and by incorporating the unconfirmed block 61 into the transaction ledger of the distributed database system according to the consensus rules of the distributed database system, the unconfirmed block 61 can be confirmed by a node device (not shown) of the distributed database system (not shown).

[0166] In particular, the third unit 3 is a time receiver. In step S30, the third unit 3 repeatedly or periodically receives a timing cycle from a time source (not shown). The time source may be an internal time source of the block forming device 1, or may be an external time source. The timing cycle may be a sequence of time pulses or a sequence of time parameters. Based on the received timing cycle, the third unit 3 determines a time slice of a predetermined length.

[0167] During a corresponding time slice in the time slices, the first unit 1 and the second unit 2 of the block forming device 10 complete the following steps exactly once:

[0168] In step S10 , the first unit 1 selects a plurality of transactions to be confirmed from the provided unconfirmed transactions 41 , 42 , 43 .

[0169] In step S20 , the second unit 2 forms an unconfirmed block 61 from the selected transactions to be confirmed.

[0170] In particular, the second unit 2 can check the validity of the selected transactions 41, 42, 43 to be confirmed, and discard invalid transactions. In particular, the second unit 2 can form an unconfirmed block 61 according to the consensus rules agreed upon in the distributed database system. In particular, the second unit 2 can insert the proof value required by the consensus rules (such as, for example, proof of work) into the unconfirmed block 61 to be formed.

[0171] The second unit 2 stops forming the unconfirmed block 61 within the corresponding time slice in a guaranteed manner, and provides the formed unconfirmed block 61 in the distributed database system (not shown). For example, the second unit 2 can transmit the formed unconfirmed block 61 to at least one other node device (not shown) of the distributed database system.

[0172] The block forming device 10 is advantageously capable of forming exactly one unconfirmed block within each time slice.

[0173] According to a preferred improvement, the first unit 1 selects all unconfirmed transactions 41-43 provided in the distributed database system in the corresponding time slice. Accordingly, it is possible to ensure that within each time slice, all provided unconfirmed transactions are included in exactly one unconfirmed block.

[0174] According to other preferred improvements, the first unit 1 selects all unconfirmed transactions 41-43 provided in the distributed database system in the corresponding time slice: the unconfirmed transactions 41-43 correspond to the predetermined conditions. Accordingly, it is possible to ensure that, within each time slice, at least all the unconfirmed transactions provided that correspond to the predetermined conditions are included in exactly one unconfirmed block. For example, all unconfirmed transactions are selected: the transactions are marked as time-critical, the transactions are marked as sensor value transactions or measurement value transactions or control instruction smart contracts, etc.

[0175] According to the second embodiment, Figure 3 The node device 20 is schematically illustrated, and Figure 4 A flowchart of the block confirmation method is shown. Figure 3 and Figure 4 .

[0176] The node device 20 has a third unit 3, a fifth unit 5, and a sixth unit 6. In the fifth unit 5, a chain of previously confirmed blocks 71, 72 is stored, and the chain of previously confirmed blocks 71, 72 represents a transaction ledger of a distributed database system (not shown). In the distributed database system (not shown) to which the node device 20 belongs, a plurality of unconfirmed blocks 61, 62 are provided. For example, by Figure 1 A plurality of block forming devices 10 are provided.

[0177] The node device 20 is configured to select a block to be confirmed from the unconfirmed blocks 61, 62 provided in the distributed database system in a timed manner, and confirm the selected block to be confirmed so that the confirmed block 73 is attached to the chain of confirmed blocks 71, 72, 73.

[0178] In particular, the third unit 3 is a time receiver. In step S30, the third unit 3 repeatedly or periodically receives a timing cycle from a time source (not shown). Based on the received timing cycle, the third unit 3 determines a time slice of a predetermined length.

[0179] During a corresponding one of the time slices, the sixth unit 6 performs the following steps exactly once:

[0180] In step S60, the sixth unit 6 selects exactly one block from the unconfirmed blocks 61, 62 and confirms the selected block. In this case, the selected block is attached to the chain of previously confirmed blocks 71, 72 as a confirmed block 73, so that the confirmed block 73 is attached to the chain of confirmed blocks 71, 72, 73.

[0181] In particular, according to the consensus rules of the distributed database, the sixth unit 6 can select a block to be confirmed among the unconfirmed blocks 61, 62 provided in the corresponding time slice.

[0182] In particular, the sixth unit 6 can in this case check, according to the consensus rules, each of the unconfirmed blocks 61, 62 provided in the corresponding time slice that can be attached to the chain of previously confirmed blocks 71, 72. If more than one of the unconfirmed blocks 61, 62 is successfully verified, the consensus rules can in this case predetermine a criterion for selecting one of the verified unconfirmed blocks 61, 62.

[0183] The block to be confirmed among the unconfirmed blocks 61 and 62 is attached to the chain of previously confirmed blocks 71 and 72 by the sixth unit 6, and thus becomes another confirmed block 73 of the chain of confirmed blocks 71, 72 and 73. In this way, in particular, the unconfirmed transaction of the block to be confirmed becomes a confirmed transaction of the confirmed block 73 in the transaction ledger.

[0184] The sixth unit 6 terminates step S60 in a guaranteed manner within the corresponding time slice.

[0185] The node device 20 advantageously enables that within each time slice, exactly one confirmed block is appended to the chain of confirmed blocks.

[0186] Figure 5 A node device 30 according to a modification of the first and second embodiments is schematically illustrated.

[0187] The node device 30 includes the Figure 1 The block forming device 10 in the embodiment, and the node device ( Figure 320) in the block formation device. Only one third unit 3 is provided here, and according to the present improvement, the operation of the first unit 1 and the second unit 2 of the block formation device 10 is timed, and the operation of the sixth unit 6 of the node device 30 is timed. In other words, the node device 30 has both the function of forming unconfirmed blocks (such as mining function) and the function of confirming unconfirmed blocks, and the unconfirmed blocks are provided by a block formation device different from the block formation device 10 of the same distributed database system.

[0188] Figure 6 A distributed database system 100 according to a third embodiment is illustrated.

[0189] The distributed database system 100 includes a plurality of node devices 20, 30, 31, 32, which are connected to a network 101. The node device 20 is a node device 20 according to the second embodiment, and the node device only has a function for confirming unconfirmed blocks. The node devices 30, 31 and 32 are node devices according to an improved solution, and the node devices additionally include corresponding block forming devices 3010, 3110, 3210 ( Figure 1 An example of a block forming device 10 in FIG. 1 ).

[0190] Each of the node devices 20, 30, 31, 32 has a corresponding third unit 203, 303, 313, 323. The other units of the node devices 20, 30, 31, 32 correspond to the units of the first or second embodiment, but are not shown for simplicity.

[0191] Each of the node devices 20, 30, 31, 32 receives the timing cycle using its corresponding third unit 203, 303, 313, 323. The respectively received timing cycles are synchronized.

[0192] Therefore, the distributed database system 100 advantageously operates in a time-synchronized manner according to a common timing cycle of the distributed database system 100; during respectively identical time slices, the corresponding first, second and sixth units of the corresponding node devices 20, 30, 31, 32 synchronously execute steps S20, S30, S60 respectively assigned to these units.

[0193] Figure 7 The diagram illustrates the timing cycle of the distributed database system 100 according to a variation of the third embodiment. Figure 1 , Figure 3 and Figure 6 In the case of Figure 7 .

[0194] At time point T0, a time slice of a corresponding node device among the node devices 20, 30, 31, 32 starts.

[0195] The first time section of the time slice starts at time T0 . During the first time section, each of the node devices 20 , 30 , 31 , 32 may provide unconfirmed transactions 41 , 42 , 43 in the distributed database system 100 .

[0196] For example, the node device 20 can be connected to the automation component of the industrial automation system and can create an unconfirmed transaction, which represents the sensor value measured at the beginning of the time slice. The node device 32 can have a user interface and can, for example, provide an unconfirmed transaction, which includes a smart contract programmed by the user, and the smart contract has control instructions for the industrial automation system.

[0197] The distributed database system 100 is designed to ensure that each provided unconfirmed transaction has reached all node devices 20 , 30 , 31 , 32 in a timely manner before the time t1 of the time slice.

[0198] Each of the block forming devices 3010, 3110, 3210 receives the provided unconfirmed transactions 41, 42, 43 and selects a plurality of transactions to be confirmed. For example, at least all time-critical unconfirmed transactions may be selected. Unselected unconfirmed transactions 41, 42, 43 may be stored and may be retained for a later time slice, or may be discarded.

[0199] The first time segment, during which the unconfirmed transactions 41 , 42 , 43 were offered and selected, ends at the time t1 .

[0200] At time point t1, the second time segment of the time slice begins. The node device 20 remains inactive during the second time segment. During the second time segment, the node devices 30, 31, 32 form unconfirmed blocks 60, 61 from the selected unconfirmed transactions 41, 42, 43, respectively, as described above according to the first embodiment. Even if the formation of blocks in a distributed database that operates, for example, according to blockchain technology, may be a time-consuming process, the consensus rules and the node devices 20, 30, 31, 32 of the distributed database system 100 are however also established so that the formation of unconfirmed blocks 60, 61 is terminated in a guaranteed manner until time point t2, at which time point t2, the second time segment ends.

[0201] At time point t2, the third time section of the time slice begins. During the third time section, the block forming devices 3010, 3110, 3210 provide the unconfirmed blocks 61, 62 formed by the block forming devices 3010, 3110, 3210 in the distributed database system 100, and the other node devices of the node devices 20, 30, 31, 32 receive the provided unconfirmed blocks 61, 62. The provision and reception of the provided unconfirmed blocks end at time point t3. At time point t3, the third time section ends.

[0202] At time t3, the fourth time segment of the time slice begins. During the fourth segment, the node devices 20, 30, 31, 32 respectively confirm exactly one of the unconfirmed blocks 60, 62 provided in the third time segment, wherein these node devices 20, 30, 31, 32 append the confirmed block 73 to the chain of confirmed blocks, which is stored in the fifth unit 6 of the corresponding node device 20, 30, 31, 32, as described above for the second embodiment. At time T0+ΔT, the fourth time segment ends, and the time slice also ends with this.

[0203] In this way, the distributed database system 100 operates in a timed and time-synchronized manner, so that it can be ensured that within a predetermined period ΔT (length of the time slice), the provided unconfirmed transactions 41, 42, 43 are accepted as confirmed transactions in the representation of the transaction ledger of the distributed database system 100 of the corresponding node devices 20, 30, 31, 32.

[0204] Figure 8 The structure of an unconfirmed block 61 according to an embodiment is schematically illustrated. It should be noted that the illustrated structure of the unconfirmed block 61 is also applicable to the corresponding confirmed blocks 71, 72, 73 ( Figure 3 ), and thus does not re-describe the latter. Figure 8 And in the return reference Figure 1 , Figure 3 and Figure 6 In the case of , describe.

[0205] The unconfirmed block 61 is, for example, a block that has been formed by the block forming device 10 ( Figure 1 ) formed by unconfirmed block 61, and is established as follows:

[0206] The unconfirmed block 61 includes a plurality of unconfirmed transactions 41 , 42 , 43 and a hash value 611 , which is, for example, a Merkle root (root value of a cryptographic hash tree) and protects the unconfirmed transactions 41 , 42 , 43 from subsequent manipulation.

[0207] In addition, as long as the consensus rules of the distributed database system 100 set this point, the unconfirmed block 61 can include an unconfirmed coinbase transaction 40. The coinbase transaction 40 is generated by the block forming device 10 itself, and the block forming device 10 or the node device 30 including the block forming device 10 ( Figure 5 ) may allow for a predetermined reward for forming a block.

[0208] The unconfirmed block 61 optionally further comprises a timestamp 612 which identifies the time slice in which the unconfirmed block 61 was formed.

[0209] The unconfirmed block 61 includes a concatenated hash value 613 , which may be a cryptographic hash value of the last confirmed block of the following representation of the transaction ledger of the distributed database system 100 , the representation of which is known to the block forming device 10 .

[0210] Furthermore, the unconfirmed block 61 includes a proof value 614, which is, according to one example, a one-time random value that represents a so-called best-effort proof of work. In particular, after the block forming device 10 has formed the unconfirmed block 61, the block forming device 10 can be used until the second time period ends at the second time point t2 ( Figure 7 ) in order to determine the one-time random value by repeated trials so that the hash value of the entire unconfirmed block 61 is as extreme as possible, such as as small as possible.

[0211] In this way, the block forming device 10 can record in a traceable manner its legal interest in including the block in the transaction ledger of the distributed database system 100. The proof of work (also called best effort proof of work) can be provided within the second time period t2 with certainty.

[0212] Based on the unconfirmed block 61, the consensus rules of the distributed database system 100 will now be described more precisely. The criteria described below of the consensus rules can be combined in an appropriate manner. The criteria described below can be used by the corresponding node devices 20, 30, 31, 32 of the distributed database system 100 to in the fourth time section ( t3 to T0+ΔT) of the corresponding time slice. Figure 7 ) during the period of checking the corresponding unconfirmed blocks 61, 62, and selecting exactly one block to be confirmed among all the unconfirmed blocks 61, 62 that have successfully passed the check. The consensus rule is exemplarily based on Figure 3 The node device 20 and Figure 8 It should be understood that the other node devices 30, 31, 32 work according to the same consensus rules.

[0213] In particular, a standard content of the consensus rules is that the Merkle root 611 must correspond to the root value of the Merkle tree established by the unconfirmed transactions 41, 42, 43 of the unconfirmed block. In this way, it is possible to ensure that the unconfirmed block 61 has not been modified without authorization during provision.

[0214] In particular, a standard content of the consensus rules is that the concatenated hash value 611 must be a valid hash value of the last or preceding block of the chain of confirmed blocks 71, 72, 73, which is stored in the fifth unit 5 of the node device 20. In this way, it is possible to determine whether and at which position the unconfirmed block 61 can be added to the chain of confirmed blocks 71, 72, 73, or whether and at which position the unconfirmed block 61 is to be discarded.

[0215] In particular, a standard content of the consensus rule is that each of the unconfirmed transactions 41, 42, 43 must be a valid transaction. A valid transaction can be understood as a transaction that transforms the current state into a new valid state, the current state being obtained by a sequence of confirmed transactions represented by the transaction ledger of the distributed database system 100, the representation of which is stored in the fifth unit 5. For example, when a smart contract included in or referenced by a transaction is executed without error, one of the unconfirmed transactions 41, 42, 43 can then be regarded as a valid transaction 41, 42, 43.

[0216] In particular, one criterion of the consensus rule may be that the timestamp 612 of the unconfirmed block 61 indicates a timeslot that is consistent with the current timeslot. This makes it possible to monitor whether the timing of the distributed database system 100 works without interference.

[0217] In particular, one criterion of the consensus rule may be that the unconfirmed block 61 must include all unconfirmed transactions 41, 42, 43 that were in the first time segment ( Figure 7 ) period and corresponds to a predetermined condition. In other words, the node device 20 can also receive and maintain unconfirmed transactions 41, 42, 43 provided in the distributed network 100 during the corresponding time slice, so that it can be checked later during the same time slice whether all unconfirmed transactions corresponding to the condition have been correctly included in the unconfirmed block 61. The predetermined condition can, for example, be that all unconfirmed transactions 40, 41, 42 are to be included, and all unconfirmed transactions 40, 41, 42 are marked as time-critical and / or related to control instructions, measurement values ​​or control values ​​of industrial automation systems. Therefore, the real-time capability of the distributed database system 100 can be guaranteed.

[0218] The above-mentioned criteria can be applied by the corresponding node devices 20, 30, 31, 32 to discard the unconfirmed blocks 61 that do not meet at least one of the above-mentioned criteria as invalid. Other criteria mentioned below can be used to select the confirmed block among multiple valid, checked unconfirmed blocks 61, 62.

[0219] In particular, one criterion of the consensus rule may be to select the unconfirmed block 61, 62 that includes as many unconfirmed transactions 41, 42, 43 as possible or unconfirmed transactions 41, 42, 43 of a certain type. In this way, an incentive for improving the transaction throughput and / or real-time capabilities of the distributed database 100 can be provided.

[0220] In particular, one criterion of the consensus rule may include the selection of the unconfirmed block 61, 62 with the best proof value 614. Thus, for example, the unconfirmed block 61, 62 may be selected whose hash value is particularly extreme (e.g., the lowest, the highest) or has the largest possible number of leading binary zeros or leading binary ones, and whose hash value also includes the proof value 614. In this way, race conditions between a plurality of unconfirmed blocks 61, 62 may be advantageously resolved, and an incentive may be provided for the block formation device 10 of the distributed network 100 to provide the best possible best-effort proof of work.

[0221] The criteria described above can be modified in particular such that, in addition to the quality of the proof values ​​614, the quality or computational complexity of the unconfirmed transactions 41, 42, 43 contained by the unconfirmed blocks 61, 62 is also taken into account. Thus, even if an unconfirmed block 61 contains fewer valuable proof values ​​614 than other unconfirmed blocks 62 (even if the hash value of the unconfirmed block 61 is less extreme than the hash values ​​of other unconfirmed blocks 62), an unconfirmed block 61, for example, can nevertheless be preferred over other unconfirmed blocks 62 if the unconfirmed block 61 contains a correspondingly higher number of computationally complex unconfirmed transactions 41, 42, 43. Computationally complex unconfirmed transactions 41, 42, 43 can be understood as transactions whose verification, within the scope of forming the unconfirmed block 61, generates a high computational load on the relevant block forming device 10 or takes up a lot of computing time of the relevant block forming device 10. In this way, it is advantageously possible to prevent the block forming device 10 from becoming disadvantageous by including many computationally complex transactions 41, 42, 43 in an unconfirmed block 61 and by causing the block forming device 10 to fail in the second time period ( Figure 7 ) only a short computing time is maintained for determining the proof value 614 before the end of the second time segment.

[0222] Fig. 9 The diagram illustrates a transaction ledger of a distributed database system 100 according to a preferred variant of the third embodiment.

[0223] Fig. 9 A chain of confirmed blocks 71, 72, 73 is shown, such as the chain can be stored in the distributed database network 100 ( Figure 6 ) of the corresponding node devices 20, 30, 31, 32 ( Figure 6 ) of Unit 5 ( Figure 3 ). The chain of confirmed blocks 71, 72, 73 here represents the distributed database network 100 ( Figure 6 ) transaction ledger. Refer to the following Fig. 9 and Figure 6 .

[0224] Each of the confirmed blocks 71, 72, 73 includes: a proof value 714, 724, 734, a concatenated hash value 713, 723, 733, a timestamp 712, 722, 732, a Merkle root 711, 721, 731 and corresponding unconfirmed transactions 50-53, 54-56, 57-59. The mentioned elements correspond to the corresponding elements of the unconfirmed block 61, which have been Figure 8is described.

[0225] As in Fig. 9 As shown in , blocks 71, 72, 73 are spliced ​​via splicing hash values ​​713, 723, 733 so that the subsequent blocks 72, 73 respectively include the splicing hash values ​​713, 723, 733 of the previous blocks 71, 72 respectively. In this way, the blockchain can be protected from manipulation.

[0226] also, Fig. 9 A time axis is shown, which indicates the starting time points T0, T0+ΔT, T0+2ΔT of the corresponding time slices. Confirmed block 71 has been formed and confirmed in the time slice associated with time point T0. Confirmed block 72 has been formed in the time slice starting from T0+ΔT. Confirmed block 73 has been formed in the time slice starting from T0+2ΔT. Correspondingly, timestamp 712 of confirmed block 71 contains the value "T0", timestamp 722 contains the value "T0+ΔT", and timestamp 732 contains the value "T0+2ΔT".

[0227] As in Fig. 9 As can be seen in FIG. 1 , in the distributed database network 100 , exactly one confirmed block is appended to the transaction ledger at predetermined time intervals ΔT.

[0228] Fig.10 The diagram illustrates a distributed database system 100 according to a fourth embodiment. Figure 1 , Figure 3 and Figure 6 In the case of Fig.10 Description. Fig.10 The distributed database system 100 according to the fourth embodiment shown in Figure 6 The distributed database system 100 according to the third embodiment shown in FIG. 1 is described below, and the same elements are not described again. Fig.10 , Figure 6 , Figure 3 and Figure 1 Only the differences of the fourth embodiment will be examined in depth.

[0229] The distributed database system 100 according to the fourth embodiment has a central time source 7 provided in the network 101. The corresponding third units 203, 303, 313, 323 are set up to receive timing cycles from the central time source 7. The time source 7 can be a DCF77 time transmitter, an NTP or PTP server or a timer of an industrial automation system. In this way, the corresponding timing cycles of the node devices 20, 30, 31, 32 can be kept synchronized particularly simply.

[0230] Furthermore, the distributed database system 100 according to the fourth embodiment has a scheduling device 8 provided in the network 101. The scheduling device 8 receives a timing cycle from the central time source 7 in the same manner as the third units 303, 313, 323 and determines a corresponding time slice of a predetermined length based on the timing cycle.

[0231] In addition to the respective first unit 1 and the respective second unit 2 , the respective block-forming device 3010 , 3110 , 3210 furthermore has a fourth unit 304 , 314 , 324 .

[0232] At the beginning of the corresponding time slice, the scheduling device 8 sends a scheduling signal to exactly one fourth unit 304, 314, 324 of exactly one of the block forming devices 3010, 3110, 3210. The scheduling device 8 can select exactly one block forming device 3010, 3110, 3210 in turn, randomly or according to another schedule.

[0233] The block forming devices 3010, 3110, 3210 according to the fourth embodiment are configured such that only when the fourth units 304, 314, 324 of the relevant block forming devices 3010, 3110, 3210 receive an activation signal from the scheduling device 8, the corresponding first units 1 and second units 2 of these block forming devices 3010, 3110, 3210 perform steps S10 and S20 described according to the first embodiment in the corresponding time slices ( Figure 2 Otherwise, the first unit 1 and the second unit 2 remain inactive during the corresponding time slices in which they have not received the activation signal.

[0234] Accordingly, advantageously only one unconfirmed block 61 is formed for each time slice, and when the unconfirmed blocks 61, 62 are confirmed by the corresponding node devices 20, 30, 31, 32, a competition situation between multiple unconfirmed blocks 61, 62 can be avoided, and the best effort proof of work can be omitted. Alternatively, for example, proof of stake can be used as a proof value, or a permissioned ledger can be used.

[0235] In order to increase security, in this case, the corresponding node devices 20, 30, 31, 32 can apply the following additional criteria to the consensus rules: an unconfirmed block 61 can only be successfully checked and confirmed if it has been provided by a block forming device 3010, 3110, 3210 activated in the relevant time slice.

[0236] Although the present invention has been described based on the embodiment, the present invention can be modified in various ways.

[0237] For the sake of simplicity, only the basic principles of a distributed database system based on blockchain have been described, which has a transaction ledger and a spliced ​​block, each of which includes multiple transactions. However, the teaching disclosed herein of the timed formation and confirmation of blocks can also be applied to other distributed database systems and improvements of blockchain-based database systems, such as, for example, distributed database systems with multiple transaction ledgers (such as a primary ledger and a secondary ledger), to other types of splicing, such as, for example, directed graphs or non-blocked transaction chains, etc.

[0238] In the distributed database network 100 of the third embodiment, a central time source 7 may be provided. In the distributed database network 100 of the fourth embodiment, no central time source 7 may be provided.

[0239] As long as the proof value 614 can be generated by the block forming device 10 within the time period set for this purpose in the corresponding time slice with certainty, consensus forming technologies such as best-effort proof of work, proof of stake, permissioned ledger, etc. can be combined in any way.

[0240] in accordance with Figure 6 A Merkle root has been described, however Patricia roots and other types of hash values, hash trees and other types of cryptography are also conceivable to protect blocks and / or individual transactions from manipulation.

[0241] in accordance with Figure 7 The conceivable subdivisions of the time slices have been described, and it has been described that all node devices 20, 30, 31, 32 are timed in a time-synchronized manner, so that the corresponding time slices start at the same time on all node devices 20, 30, 31, 32. However, embodiments are also conceivable in which the corresponding timing cycles of the node devices 20, 30, 31, 32 are time-synchronized in another way and / or the corresponding time slices are subdivided differently. For example, the timing cycles of different node devices can be offset from one another by a fraction of a predetermined length ΔT; in this way, for example, a high degree of parallelism can be achieved without an inactive phase of the individual node devices 20.

[0242] The proposed solution can be understood as a block forming device and a node device for a distributed database system, which respectively have a unit for receiving a timing cycle from a time source and determining a time slice of a predetermined length based on the timing cycle, wherein the block forming device selects a transaction to be confirmed from the unconfirmed transactions provided in the database system exactly once within the corresponding time slice, forms an unconfirmed block from the selected unconfirmed transaction and provides the unconfirmed block in the database system, and the node device stores a chain of confirmed blocks, wherein the confirmed blocks represent the transaction ledger of the database system, and within the corresponding time slice, confirms exactly one block from the unconfirmed blocks provided in the database system in the time slice exactly once, and appends the block to the chain of confirmed blocks.

[0243] Particularly advantageously, the proposed solution can be applied to industrial automation systems, which include a plurality of automation components that can be operated according to a timing cycle. The proposed distributed database system (such as, for example, the distributed database system 100 according to one of the embodiments) can be set up to control and / or regulate the plurality of automation components with the aid of smart contracts and interface devices, etc., wherein the smart contracts implement the control logic and the interface devices form an interface between the node devices of the distributed database system and the automation components of the automation system. The corresponding interface devices can be set up to: cause the measured values ​​of the corresponding automation components to be provided to the database system 100 as unconfirmed transactions, or to cause the control values ​​from the transactions confirmed in the distributed database system 100 to be provided to the corresponding automation components. In this case, the timer of the automation system can serve as a central time source of the distributed database system ( Fig.10 7) in . Therefore, the following timing cycle of the distributed database system can be realized: the timing cycle is synchronized with the timing cycle of multiple automation components, or is synchronized with an integer multiple of the timing cycle of multiple automation components. Therefore, the measured values ​​and / or control values ​​may be confirmed in the distributed database system in the form of transaction data records in the same cycle, wherein the transaction data records are supplied by the automation components or are to be output to the automation components. Therefore, with the help of a distributed database based on blockchain technology, real-time control of industrial automation systems can be achieved.

[0244] References

[0245] [1] "Mastering Bitcoin: Unlocking Digital Cryptocurrencies" by Andreas M. Antonopoulos (O'Reilly Media, December 2014)

[0246] [2] Roger M. Needham and Michael D. Schroeder, “Using encryption for authentication in large networks of computers” (ACM: Communications of theACM, Vol. 21, No. 12, December 1978)

[0247] [3] "Security Engineering. A Guide to BuildingDependable Distributed Systems" by Ross Anderson (Wiley, 2001)

[0248] [4] "Ethereum: Blockchains, Digital Assets, SmartContracts, Decentralized Autonomous Organizations" by Henning Diedrich (CreateSpace IndependentPublishing Platform, 2016)

[0249] [5]"The Ethereum Book Project / Mastering Ethereum"

[0250] https: / / github.com / ethereumbook / ethereumbook, as of October 5, 2017

[0251] [6] "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance" by Leemon Baird (Swirlds Tech Report SWIRLDS-TR-2016-01, May 31, 2016)

[0252] [7] Leemon Baird, “Overview of Swirlds Hashgraph” (May 31, 2016)

[0253] [8]Blockchain Oracles

[0254] https: / / blockchainhub.net / blockchain-oracles /

Claims

1. A block forming device (10) for a distributed database system (100), the distributed database system (100) comprising a plurality of node devices (20, 30-32), the block forming device (10) having: A first unit (1) is used to select a plurality of transactions to be confirmed from a plurality of unconfirmed transactions (41-43) provided in the distributed database system; A second unit (2) is used to form an unconfirmed block (61, 62) from the selected multiple unconfirmed transactions (41-43), wherein the validity of the corresponding selected unconfirmed transactions (41-43) is checked, and when the check fails, the corresponding selected unconfirmed transactions (41-43) are discarded, otherwise the corresponding selected unconfirmed transactions (41-43) are included in the unconfirmed block (61, 62), and the second unit (2) is used to provide the unconfirmed block (61, 62) in the distributed database system (100); and A third unit (3) for receiving a timing cycle from a time source (7) and for determining a time slice of a predetermined length (ΔT) based on the timing cycle; The first unit (1) is configured to perform the selecting exactly once within a corresponding time slice, and the second unit (2) is configured to perform the forming and providing exactly once within a corresponding time slice.

2. The block forming device according to claim 1, It is characterized in that The first unit (1) is configured to select, during the corresponding time slice, all the following unconfirmed transactions (41-43) provided in the distributed database system (100) as transactions to be confirmed: the unconfirmed transactions (41-43) correspond to predefined conditions.

3. The block forming device according to claim 1 or 2, Features a fourth unit (304, 314, 324) for receiving an activation signal, The first unit (1) and the second unit (2) are configured to perform the selection, the formation and the provision exactly once within the corresponding time slice only when the fourth unit (304, 314, 324) receives the activation signal in the corresponding time slice.

4. The block forming device according to claim 1 or 2, It is characterized in that The second unit (2) is configured to include the following cryptographic proof of work (614) into the formed block (61): the cryptographic proof of work (614) is the best cryptographic proof of work (614) that can be determined by the second unit (2) within the corresponding time slice.

5. The block forming device according to claim 4, It is characterized in that The second unit (2) is configured to include a time stamp (612) identifying the corresponding time slice in the formed block (61).

6. A node device (20, 30-32) for a distributed database system (100), the distributed database system (100) comprising a plurality of node devices (20, 30-32), the node devices (20, 30-32) having: a fifth unit (5) for storing a chain of confirmed blocks (71-72), the confirmed blocks (71-72) representing at least one segment of a transaction ledger of the distributed database system (100); A sixth unit (6) for confirming exactly one block from a plurality of unconfirmed blocks (61, 62) provided in a corresponding time slice in the distributed database system (100), so that the confirmed block (73) is attached to the chain of the confirmed blocks (71-73), wherein confirming exactly one block from a plurality of unconfirmed blocks comprises: checking one, more than one or all of the unconfirmed blocks (61, 62), selecting one of the unconfirmed blocks (61, 62) that successfully passes the check and attaching the selected block as the confirmed block (73) to the chain of the confirmed blocks (71-73); and A third unit (3) is used to receive a timing cycle from a time source (7) and determine a time slice of a predetermined length based on the timing cycle; The sixth unit (6) is designed to carry out the confirmation and the addition exactly once within the corresponding time slice.

7. The node device according to claim 6, It is characterized in that The sixth unit (6) is configured to select the exactly one block (61, 62) for confirmation according to at least one of the following criteria: - the number and type of transactions (41, 42, 43) included in said block (61, 62); - the quality of the cryptographic proof of work (614) included by the block; - the quality and / or computational complexity of the corresponding transactions (41, 42, 43) included by said blocks (61, 62); - the consistency of the timestamp comprised by said block (61, 62) with said corresponding time slice; and / or - whether the block forming device (10) that has provided the block is the following block forming device (10): for which the activation signal transmitted in the distributed database system (100) during the corresponding time slice is determined.

8. The node device according to claim 6 or 7, It is characterized in that The sixth unit (6) is configured to select the exactly one block (61, 62) for confirmation based on the following criteria: whether the block (61, 62) includes all of the following unconfirmed transactions (41, 42, 43) provided in the distributed database system (100) during the corresponding time slice: the unconfirmed transactions (41, 42, 43) correspond to predefined conditions.

9. The node device according to claim 7, It is characterized in that The node device (30, 31, 32) has a block forming device (10) according to any one of claims 1 to 5.

10. A distributed database system (100), comprising a plurality of node devices (20, 30-32) according to any one of claims 6 to 9, wherein the plurality of node devices (20, 30-32) are configured to jointly manage a transaction ledger of the distributed database system (100), wherein at least one of the node devices (30-32) comprises a block forming device (10) according to any one of claims 1 to 5, and can operate the plurality of node devices (20, 30-32) in a time-synchronized manner according to a timing cycle of the distributed database system.

11. The distributed database system according to claim 10, It is characterized in that The distributed database system (100) further comprises a central time source (7), wherein the following time source (7) is the central time source (7): the third unit (3, 203, 303, 313, 323) of the corresponding node device (20, 30-32) receives the timing cycle from the time source (7).

12. An industrial automation system, comprising the distributed database system (100) according to claim 10 or 11 and a plurality of automation components operable according to a timing cycle, wherein the distributed database system (100) is operable to regulate and / or control the plurality of automation components, The timing cycle of the distributed database system (100) is synchronized with the timing cycles of the plurality of automation components, or is synchronized with integer multiples of the timing cycles of the plurality of automation components.

13. A block formation method for a distributed database system (100), the distributed database system (100) comprising a plurality of node devices (20, 30-32), the block formation method comprising: Selecting (S10) a plurality of transactions to be confirmed from a plurality of unconfirmed transactions (41, 42, 43) provided in the distributed database system (100); An unconfirmed block (61) is formed (S21) from the selected plurality of unconfirmed transactions (41, 42, 43), wherein the validity of the corresponding selected unconfirmed transactions (41-43) is checked, and the corresponding selected unconfirmed transactions (41-43) are discarded when the check fails, or the corresponding selected unconfirmed transactions (41-43) are included in the unconfirmed block (61), and the unconfirmed block (61) is provided (S22) in the distributed database system (100); and Receiving (S30) a timing cycle from a time source (7) and determining a time slice of a predetermined length (ΔT) based on the timing cycle; In this case, the selecting ( S10 ), the forming ( S21 ) and the providing ( S22 ) are performed exactly once within the corresponding time slice.

14. A block confirmation method for a distributed database system (100), the distributed database system (100) comprising a plurality of node devices (20, 30-32), the block confirmation method comprising: Storing (S50) a chain of confirmed blocks (71-72), the confirmed blocks (71-72) representing a main ledger of a distributed database (100); Confirming (S60) exactly one block from a plurality of unconfirmed blocks (61, 62) provided in a corresponding time slice in the distributed database system (100), wherein the confirmed block (73) is attached to the chain of the confirmed blocks (71-73), wherein confirming exactly one block from the plurality of unconfirmed blocks comprises: Checking one, more or all of the unconfirmed blocks (61, 62), selecting one of the unconfirmed blocks (61, 62) that has successfully passed the check and appending the selected block as the confirmed block (73) to the chain of the confirmed blocks (71-73); and Receiving (S30) a timing cycle from a time source (7) and determining a time slice of a predetermined length based on the timing cycle; The confirmation (S60) is performed exactly once within the corresponding time slice.

15. A computer program product which causes the method according to claim 13 or 14 to be performed on a program-controlled device.

Images