EP3928492A1 - Procédé pour commander un système matériel au moyen d'une chaîne de blocs - Google Patents

Procédé pour commander un système matériel au moyen d'une chaîne de blocs

Info

Publication number
EP3928492A1
EP3928492A1 EP20703958.7A EP20703958A EP3928492A1 EP 3928492 A1 EP3928492 A1 EP 3928492A1 EP 20703958 A EP20703958 A EP 20703958A EP 3928492 A1 EP3928492 A1 EP 3928492A1
Authority
EP
European Patent Office
Prior art keywords
blockchain
logic
block
parameter definitions
new
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20703958.7A
Other languages
German (de)
English (en)
Inventor
Volker Goudschmidt
Oliver Penzel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bonebits GmbH
Original Assignee
Bonebits GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bonebits GmbH filed Critical Bonebits GmbH
Publication of EP3928492A1 publication Critical patent/EP3928492A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models

Definitions

  • the invention relates to a method for controlling a hardware system using a blockchain.
  • the invention is a method with which dynamic
  • Blockchains can either be forked or joined together by linking or referencing. They can be ended finally and
  • Data blocks can be deleted. This is made possible by de-clustering the procedural logic, declaring new block types and a proof-of-completion consensus.
  • the previous use of the blockchain as a continuous add-only memory becomes a dynamic, decentralized database through the invention and opens up many new areas of application that were previously only possible with native database applications.
  • the main feature of a blockchain is the tamper-proof storage of data, in the form of continuous, coherent logging of a hash calculated using an algorithm.
  • the blockchain has the
  • the main feature of a database-based application is the flexible handling of data. They can also be deleted or changed. As a consequence, this means that the properties of the blockchain and those of a database-based application are mutually exclusive. In its current form, the blockchain can only be used for very special areas of application in the form of permanent and continuous
  • consistent documentation e.g. can be used for account management, notary tasks, ledgers, etc.
  • the area of application of a blockchain in everyday life is therefore very limited.
  • the US 9 608 829 B2 shows a description of the well-known blockchain technology.
  • the font describes a concept in which a Blockchain can be forked and in which logics and parameters for block processing called “rules" are kept in the blockchain itself.
  • blockchain and slidechains can only ever be connected at one end, but never afterwards anywhere in the middle.
  • the connection can also be established by referencing in the present invention.
  • any chain can be linked to any block of the chain by referencing. Write access to the external chain is not required. Only then is the flexible use of mixed infrastructures possible at all.
  • Subheading “Background”) is therefore not possible at all, because a flexible database application requires not only writing data but also deleting and changing data. This is not possible without the new, individual block types and the proof-of-completion consensus.
  • Container structure which contains the logic and parameters for the
  • Blockchain infrastructures are monitored and ensured via a proof-of-completion consensus.
  • a data source posts a task as a transaction in the transaction pool. 5. She selects transaction: fork, merge, quit, delete, inform or save.
  • a node fetches a transaction from the transaction pool.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • the network is retained because the nodes no longer have to decide which blockchain (fork) they will process exclusively for in the future. You can opt for multiple blockchains at the same time because you have instant access to the logic and parameter definitions. For faster processing, the nodes can internally keep a library with the various logic and parameter definitions of the individual blockchains for immediate availability.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Blockchain the available computing power can be used optimally. Standstill or waiting times are avoided. Decisions can e.g.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Block processing priorities subject to ownership or authority.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Block processing priorities subject to ownership or authority.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • a data source posts a transaction to the transaction pool for termination.
  • a privileged node fetches a transaction from the
  • An end block can be added to the end of a blockchain. This prevents the addition of new blocks.
  • the chain is now closed.
  • the end block can contain information in a container. Processes can thus be finalized. Completed processes no longer have to be taken into account for ongoing processes. This saves memory and computing capacity.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Block processing priorities subject to ownership or authority.
  • a data source posts a transaction for deletion in the transaction pool.
  • a privileged node fetches a transaction for deletion from the
  • Blockchain outsourced This blockchain is marked as deletable in its limb block or an independent blockchain (library chain). After deletion, this data area can optionally be written again or finally closed by an end block before further writing.
  • the up-to-dateness and authenticity as well as compliance with all rules applicable at the time the order is placed are ensured by a proof-of-completion consensus. This enables, among other things, the "right to be forgotten” from the EU GDPR to be implemented.
  • An info file can explain the reason for the deletion (e.g. personal data on
  • a data source posts a transaction for forking into the transaction pool.
  • a privileged node fetches a transaction from the transaction pool for fork.
  • Tasks are outsourced in independent chains. Only the path from the historical beginning of the chain to the current most recent block is required for the task (Figure 10). All other tasks on the blockchain are not relevant to the outsourced task. This minimizes the storage space at the nodes. A full node feature with a task history is guaranteed.
  • a data source posts a transaction for forking into the transaction pool.
  • a privileged node fetches a transaction from the transaction pool for fork.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • a data source posts a transaction for forking into the transaction pool.
  • a privileged node fetches a transaction from the transaction pool for fork.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Sub-processes can optionally be transferred to external areas (black box) during block processing.
  • the results of the external processing can optionally be returned to the block processing process as processing parameters.
  • the processing process within the external area is not publicly visible (black box).
  • a data source posts a transaction for forking into the transaction pool.
  • a privileged node fetches a transaction from the transaction pool for fork.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • privileged nodes that e.g. can be owned by a data source, always process their own transactions first. If there is free capacity, they use their computing power, e.g. available to other blockchains for a fee. From an economic point of view, this can result in a cost-neutral node operation or even a further source of income.
  • a data source represents a transaction to be merged into the
  • a privileged node fetches a transaction from the transaction pool for merging.
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • a data source represents a transaction for a new procedure in the
  • a privileged node fetches the transaction for the new procedure from the
  • Nodes access new logic and parameter definitions directly from the blocks on the blockchain or from an independent blockchain (library chain).
  • the procedural logic is an integral part directly on the blockchain or in an independent blockchain (library chain). It belongs to the data of a genesis block, a limb block or a merge block or any data block on the blockchain itself or on an independent blockchain (library chain) and is used together with the start value for hash calculation of the
  • a privileged node fetches the transaction for the new procedure from the
  • the procedural logic is an integral part directly on the library chain or on the referencing blockchain itself. It contains a reference to any block of a backbone chain. Because the referencing blockchain does not have to make any changes with regard to the fork, the fork can also take place retrospectively on any block, i.e. also on blocks that already have subsequent blocks. This creates another property that otherwise only database-based applications have.
  • Opening up new areas of application using intelligent block types for immediate use is particularly important.
  • the unique selling point is the dynamization of the blockchain and its infrastructure.
  • the target group are all companies that have to store and manage data securely and decentrally.
  • the data can also be made available to the public in a tamper-proof manner for documentation purposes.
  • Manufacturing and supply chains can also be mapped transparently, quickly and securely. Possible partners can be found both in industry and in the form of service providers or manufacturers for everyday purposes. The range of uses is broad.
  • Algorithm check e.g. banknotes - the system checks the presence of the serial number and, by means of the algorithm, abnormalities such as average overuse
  • Participation and examination certificate e.g. online seminars - training courses - high school diploma
  • the nodes are statically linked to software.
  • This software contains the logic of how to edit each block.
  • Blockchains / sidechains create no dynamic. Solution: First declassifying the node software, classifying the blocks in
  • Types and the expansion of the blocks by a container structure which contains the logic and the parameters for the block processing method, enables a fast, individual block processing. They contain the entire processing logic and can have a consensus mechanism that is different from the data blocks. Proof-Of-Work, Proof-Of-Stake etc. can be used in parallel. The timeliness and authenticity as well as compliance with all the
  • Figure 2 Fork of a blockchain of the new, dynamic process
  • Figure 8 Practical example EU GDPR Art. 17 on the blockchain (focused), new, dynamic procedure,
  • Figure 10 Storage space requirements and grouping of the data in the new, dynamic process
  • Figure 11 Simplest definition of a blockchain (minimum requirement), new, dynamic process,
  • Figure 13 Possible structure of the container in the new, dynamic process
  • FIG. 14 Static blockchain of the method known from the prior art
  • FIG. 15 Fork of a static blockchain of the method known from the prior art
  • Figure 16 Storage space requirements and fragmentation of the data in the known, static method
  • Figure 17 Simplest definition of a blockchain (minimum requirement), known, static method,
  • FIG. 18 Possible block connections in the known, static method and FIG. 19: Referential fork of a blockchain of the new, dynamic method.
  • Figure 20 Use of the proof-of-completion consensus.
  • Figure 1 The nodes (2) of a network (3) fetch software (6) with the basic operating function (4) of a node from a central software memory (1).
  • the initial processing logic (5) for processing the data blocks (7) on a backbone chain (8) is obtained by the nodes (2) directly from a container (17, Figure 13) in the genesis block (9) of the backbone chain (8) from. It contains the entire
  • Processing logic (5) and can have a consensus mechanism that is differentiated from the data blocks (7). Proof-Of-Work, Proof-Of-Stake etc. can be used in parallel.
  • the nodes (2) fetch the transactions (29) from a transaction pool (28) for processing the new data block (11), which were delivered there from a data source (30).
  • the content of a new data block (11) is calculated with the aid of the processing logic (5) (FIG. 11).
  • the backbonechain (8) is created from a Genesis block (9) which is equipped with a container (17) for holding files, including, but not limited to, the processing logic (5) for processing data blocks (7) . Further data blocks (7) are added to this Genesis block (9).
  • the newest data block (11) is added to the last data block (10) added.
  • Written data blocks (7) cannot be changed and cannot be deleted.
  • the backbone chain (8) extends infinitely ( Figure 10).
  • a blockchain of the new procedure Figure 2 At a fork (16) from the backbone chain (8), a limbchain (13) is created.
  • a rights file (19) stored in the Genesis block (9) in the container (17, FIG. 13) can equip certain nodes (18) with special rights.
  • One of these rights can be the addition of a limb block (20) to the backbone chain (8). It contains the entire processing logic (5) and can have a consensus mechanism differentiated from the data blocks (7). Proof-Of-Work, Proof-Of-Stake etc. can be used in parallel.
  • the privileged node (18) fetches the transaction (29) from the transaction pool (28) to add a limb block (20), which was previously delivered there from a data source (30).
  • the limb block (20 like the genesis block (9), is equipped with a container (17) for files.
  • the limb block (20) receives the new processing logic (15) and a new rights file (21) from the privileged node (18) for the limbchain (13).
  • the nodes (2) get the processing logic (15) from the Limb block in addition to the already existing processing logic (5) and can now use both blocks of the original
  • Figure 3 At a fork (16, Figure 2) (fork) of the backbone chain (8) a limbchain (13) is created.
  • a rights file (19) stored in the Genesis block (9) in the container (17, FIG. 13) can equip certain nodes (18) with special rights.
  • one of these rights can also be the final option to terminate the addition of further blocks by setting an end block (22).
  • the privileged node (18) fetches the transaction (29) from the transaction pool (28) to add an end block (22) that was previously delivered there from a data source (30).
  • the end block (22) like the genesis block (9) or the limb block (20), is equipped with a container (17) for files.
  • An info file (23) can provide information about the reason for the termination or further procedures. No further data blocks (14) can be added to the limbchain (13) ( Figure 10).
  • a limbchain (13) is created at a fork (16, Figure 2) of the backbone chain (8).
  • a rights file (21) stored in the limb block (20) in the container (17, FIG. 13) can equip certain nodes (18) with special rights.
  • one of these rights can also be the possibility of deleting data blocks (14).
  • the privileged node (18) fetches the transaction (29) from the transaction pool (28) for deleting and adding an info block (24) that was previously delivered there from a data source (30). Deletion is only possible from the end of the limb chain (13), up to a maximum of before the limb block (20).
  • info block (24) there can also be the right to add an info block (24).
  • info block (24) like the limb block (20), is equipped with a container (17) for files.
  • An info file (23) can contain information about the reason for the deletion or further procedures. Further data blocks (14) can be added to an info block (24).
  • FIG. 5 The nodes (2) of a network (3) fetch software (6) with the basic operating function (4) for nodes (2) from a central software memory (1).
  • the initial processing logic (5) for processing the data blocks (7) on a backbone chain (8) is picked up by the nodes (2) directly from a container (17, FIG. 13) in the genesis block (9) of the backbone chain (8).
  • the nodes (2) fetch the transactions (29) from a transaction pool (28) for processing the new data block (11), which were delivered there from a data source (30).
  • the content of a new data block (11) is calculated with the aid of the processing logic (5).
  • the backbonechain (8) is made up of a Genesis block (9) with a container (17) for holding files, including, but not limited to, the
  • Processing logic (5) for processing data blocks (7) is equipped.
  • this container (17) there is also a rights file (19) the certain nodes (18) special rights, e.g. the insertion of a limb block (20) allows.
  • Further data blocks (7) are added to this Genesis block (9).
  • the latest data block (11) is added to the last data block (10) added.
  • the backbone chain (8) extends infinitely ( Figure 10).
  • the privileged node (18) fetches the transaction (29) to add a limb block (20) from the
  • Backbonechain (8) creates a limbchain (13).
  • the limb block (20 like the genesis block (9), is equipped with a container (17) for files.
  • the node (18) fills this container with a rights file (21) and a new processing logic (15).
  • the nodes (2) pick up the processing logic (15) on the limbchain (13) in addition to the already existing processing logic (5) of the backbone chain (8).
  • multilingual scripts can also access external systems (25) via an interface (26) during the block processing time, deliver data there and receive a result back. The result can influence the processing of the data block (14).
  • the processes of the external system (25) are not visible to the nodes (2) in the network (3).
  • FIG. 6 A privileged node (18) from the network (3) forks (27, Figure 2) from a backbone chain (8) a new blockchain for merging as a merge chain (32).
  • a blockchain becomes a merge chain (32).
  • a rights file (21) stored in the merge block (33) in the container (17, FIG. 13) can equip certain nodes (18) with special rights for the merge chain (32).
  • a parameter file (34) also stored there contains the identifier of the merged (31a-c) blockchains (13a-c) as well as the identifier of the limb block (20) or the data block (14b-c) from which the merge (3 la-c) has been referenced.
  • an info file (23) for the reason for the merging (31a) can be stored in its container (17). Referencing to data blocks (14b + c) from any blockchains (13b + c) and any architecture outside the network (3) is possible and does not require any special authorization for referencing.
  • the blockchains (13a-c) continue to run in accordance with their intended use regardless of the merge (3 la-c).
  • the privileged node (18) fetches the transaction (29) to create a merge block (33) from the transaction pool (28), which was previously delivered there from a data source (30).
  • the merge block (33) is equipped with a container (17) for files.
  • the merge block (33) from the node (18) for the new merge chain (32) contains the new processing logic (15), a new one
  • the nodes (2) also get the new processing logic (15) from the merge block (33). All nodes (2) can create new data blocks (11) for the new blockchain (32) with a new one
  • FIG 7 A backbone chain (8) is forked for a customer by an authorized node (18) from the network (3) (27, Figure 2).
  • the authorized node (18) adds a limb block (20a) for the fork (16a) of a blockchain (13a)
  • Authorization from the rights file (21a-21c) fill the blockchains (13a-13c) with data blocks (14a-c) according to the conditions from the processing logic (15a-15c) ( Figure 11).
  • Processing logic (15c) requires the data for the secret purpose to be transferred to an external system (25) via the interface (26).
  • the external system (25) sends a return value via the interface (26), which is taken into account when processing the data block (14c).
  • FIG 8 A backbone chain (8) is forked (27, Figure 2) for a customer by an authorized node (18) from the network (3).
  • the authorized node (18) adds a limb block (20a) for the fork (16a) of a blockchain (13a)
  • Authorization from the rights file (21a-21c) fill the blockchains (13a-13c) with data blocks (14a-c) according to the conditions from the processing logic (15a-15c) ( Figure 11).
  • the rights file (21a) allows authorized nodes (18) to delete data blocks (14a) and to add an end block (22) with information about the reason for the deletion in the info file (23).
  • the customer's personal data (14a) are permanently deleted.
  • Data of the account (14b) and the secret purpose (14c) are permanently retained (FIG. 10).
  • FIG. 9 A milk processing plant documents the production of
  • Milk supplier documents the individual milk deliveries on a continuous blockchain (13b, Figure 16).
  • the strawberry supplier documents the origin of his strawberries on a blockchain (13c, Figure 16).
  • Both suppliers use external, static documentation models (13b + c).
  • the published delivery of the packaging manufacturer is referenced in the merge block (33) (31a).
  • the milk batch and the strawberry batch are referenced directly to the ongoing production (14b + c) in the external documentation models (31b + c).
  • the completely filled and packaged yoghurt pots are continuously documented in data blocks (11) (FIG. 11). The entire production chains of the milk processing company and the suppliers can be viewed at any time.
  • FIG. 10 The backbone chain (8) grows by adding new data blocks (11) from the Genesis block (9) through the data blocks (7) to the last added data, limb, info or merge block ( 10) infinitely further. Transactions (29) of a task are processed via a limb block (20) in an independent limb chain (13). The task can finally be completed by an end block (22). Transactions (29) of a task are grouped and not fragmented. For complete documentation of a self-contained task, only the backbone chain (8) from the genesis block (9) to the limb block (20) and the limb chain (13) to the end block (22) need to be saved and held.
  • the backbone chain (8) can also be a limb chain (13) or a merge chain (32). Depending on which one, it starts with a Genesis block (9), a Limb block (20) or a Merge block (33).
  • the first block becomes any, free selectable start value (35) [here: 000000000000000000000000] assigned. From the start value (35) together with any data (36) [here: DATA1], together with a container (17, Figure 13) with possible scripts for
  • an end value (38) [here: 7906ded4f829316e0e4ea7b6e5dcad56] is calculated with an algorithm (37) [here: MD5].
  • the end value (38) of the Genesis block (9) is specified in a binding manner for the start value (35).
  • the final value (38) [here:
  • the final value (38) [here: c820465ddl80deff225939057ffb9915] is calculated using an algorithm (37). This process is continued with all further appendices of new data blocks (11).
  • the backbone chain (8) extends infinitely ( Figure 10).
  • the method (37) always remains the same. Subsequent changes to a start value (35), any data (36), the scripts (5/19/34) or an end value (38) make the ongoing structure of the backbone chain (8) inconsistent. A recalculation automatically leads to different final values. The content of the data blocks can therefore be recognized as not authentic. Scripts (5/19/34) are available from the beginning
  • Tampering is protected because they are a fixed, unchangeable part of the blockchain. Required changes are transparently documented in limb blocks (20) or merge blocks (33).
  • FIG. 12 The beginning (39, Figure 11) of a backbonechain (8) begins with a Genesis block (9). This contains a container (17, FIG. 13) for receiving files, for example the process logic (5) for calculating the end values (38). A new data block (11) is appended directly to the Genesis block (9) (FIG. 11).
  • the further sequence (40, Figure 11) is done by adding new data blocks (11) directly to the last added data block (10) on the backbone chain (8).
  • a limb block (20) is first added. This contains a container (17, Figure 13) for receiving
  • New data blocks (11) can be attached to the limb block
  • a limb block (20) is added to change the performance (42) of the running backbone chain (8).
  • An end block (22, FIG. 3) is added to the limb block (20).
  • a limb block (20) is attached to the blockchain (13) to be referenced.
  • a merge chain (32) is forked from a previously described fork process (27, FIG. 2).
  • the limbchain (13) continues unchanged as before.
  • the forked (27) merge chain (32) is operated from now on with reference to the reference (34) according to the processing logic (15).
  • a merge chain (32) is forked from a previously described forking process (27, FIG. 2).
  • the blockchain (13) continues to run unchanged as before.
  • the forked (27) merge chain (32) is operated from now on with reference to the reference (34) according to the processing logic (15).
  • a limb block (20) is attached to each of the (31) blockchains (13a + b) to be merged.
  • An end block (22, FIG. 3) is added to each of the limb blocks (20) to terminate the previous processing method.
  • Both end blocks contain a container (17) for holding files, here, for example, an info file (23) that provides information about the merging.
  • a merge chain (32) is forked from a previously described fork process (27, FIG. 2). This contains a merge block (33) with a container (17) for holding files, here for example the new one
  • the forked (27) merge chain (32) will henceforth be operated with reference to the references (34) to the blockchains (13a + b) according to the processing logic (15).
  • an info block (24) is appended to the last data block (10) of a backbone chain (8).
  • an end block (22) is appended to the last data block (10) of a backbone chain (8).
  • Figure 13 The container (17) has a tree structure that is common today
  • the structure is that of a file system consisting of folders and files. Thanks to this structure, it can contain further containers. Content can be any files
  • Figure 14 From a central software memory (1), the nodes (2) of a network (3) fetch software (6) that binds the basic operating function (4) and processing logic (5) for processing the data blocks (7) on a blockchain (52 ). The content of a new data block (11) is calculated with the aid of the processing logic (5). The blockchain (52) is created from a Genesis block (9). Further data blocks (7) are added to this genes block (9). To the last appended
  • the newest data block (11) is added to data block (10).
  • a new blockchain (13) is created.
  • the nodes (2) have to decide for which blockchain they will process in the future. Such a decision-making process can take several months.
  • a new network is created (12).
  • the reduced, original network (3) continues to add new data blocks (11) according to the original processing logic (5) to the most recently added data block (10) of the original blockchain (52).
  • the nodes (2) in the new network (12) fetch new software (6) consisting of basic operating software (4) and modified processing logic (15) from a central storage location (1).
  • New data blocks (14) of the new blockchain (53) are processed according to the new processing logic (15).
  • the original blockchain (52) and the new blockchain (53) only have the shared computing power available exclusively. A dynamic distribution is not possible (see Figure 2).
  • Figure 16 The blockchain (52) continues to grow infinitely by adding new data blocks (11) from the Genesis block (9) via the data blocks (7) to the last added data block (10) ( Figure 17). It's an add-only store. Transactions (29) of one task are fragmented with other transactions (29) of other tasks over the entire blockchain (52). For complete documentation of a self-contained task, the entire blockchain (8) must be linked to each individual Data block (7) are always stored and kept up-to-date (compare FIG. 10).
  • FIG. 17 The blockchain (52) begins with a Genesis block (9). Since it is the first block in the blockchain (52), it receives any starting value (35) [here:
  • An end value (38) [here: 7906ded4f829316e0e4ea7b6e5dcad56] is calculated from the start value (35) together with any data (36) [here: DATA1] using an algorithm (37) [here: MD5].
  • the end value (38) of the Genesis block (9) is specified in a binding manner for the start value (35).
  • the final value (38) [here:
  • Method (37) always remains the same. Subsequent changes to a start value (35), any data (36) or an end value (38) make the ongoing structure of the blockchain (52) inconsistent. A recalculation automatically leads to different final values. The content of the data blocks can therefore be recognized as not authentic.
  • the processing logic (5) is not part of the blockchain (52) (see Figure 11).
  • Figure 18 The beginning (49) of a blockchain (52) begins with a Genesis block (9). A new data block (11) is attached directly to the Genesis block (9).
  • the further stringing (50) takes place by directly adding new data blocks (11) to the respectively most recently added data block (10) on the blockchain (52).
  • Figure 19 A fork (16) from the backbone chain (8) creates a new limbchain (13).
  • a rights file (19) stored in the library chain (54) in the limb block (20a) in the container (17) can equip certain nodes (18) with special rights. One of these rights can be the insertion of a limb block (20b) on the library chain (54).
  • the privileged node (18) fetches the transaction (29) for adding a limb block (20b) from the transaction pool (28), which was previously submitted there from a data source (30).
  • the limb block (20b like the limb block (20a), is equipped with a container (17) for files.
  • the limb block (20b) from the node (18) for the new limbchain (13) contains the new processing logic (15) and a new rights file (21).
  • the nodes (2) also fetch the new processing logic (15) from the limb block (20b) and can now use both the original backbone chain (8) and the new ones
  • FIG. 20 A data or order source (30) uses a software / app (6a) with which orders / data can be encrypted / decrypted.
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without these
  • Update is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) from the network (3) and ignored.
  • a node (2c) from the network (3) wants to read the current status of the data on the blockchain (8), it can compare the result with the status of the completion of all orders on the library chain (54) and thereby check the current status and the Ensure authenticity.
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use.
  • Figure 20 A person (30) uses a software / app (6a) with which
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the
  • Figure 20 An authority (e.g. residents' registration office), a bank or another institution (30) uses a software / app (6a) with which personal data (name, address, personal ID, etc.) is compared with the person (personal
  • Identification can be encrypted / decrypted as an identification result (Trusted Point) and instructs the attachment of the identification result (Trusted Point) to be added to the digital data record.
  • the software / app (6a) takes over the
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored. If a node (2c) from the network (3) wants to read the current status of the data on the blockchain (8), it can see the result with the status of the completion of all orders on the
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use.
  • the digital identity remains completely in self-administration. Only the person himself, for whom the data is provided, determines what information is provided and what is not. Trustee Points / Verifiable Claims (VC) can be added by authorized third parties. Data or
  • a person / institution / company (30) uses a software / app (6a) with which orders / data can be encrypted / decrypted. It identifies itself through a customized authentication process
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) asks the current one in the library chain (54)
  • Order status of the blockchain (8) If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) with information about the query can be attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored. If a node (2c) from the
  • Network (3) wants to read the current status of the data on the blockchain (8), he can compare the result with the status of the completion of all orders on the library chain (54) and thereby ensure that it is up-to-date and authentic.
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use.
  • Figure 20 A person or debt collection company / bank / institution / company (30) uses a software / app (6a) with which personal data (name, address, personal ID, credit entry, affidavit, etc.)
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, which complies with the rules of the EU GDPR are met accordingly.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the
  • Figure 20 A person (self-disclosure) or a bank / institution / company (30) uses a software / app (6a) with which orders / data can be encrypted / decrypted. It identifies itself through a purpose-adapted
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54).
  • the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) with information about the query is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the
  • FIG. 20 A smart household appliance refrigerator / SmartHome / machine / probe (30) uses a software / app (6a) with which personal data (name, address, stocks, orders, deliveries, status, etc.) can be encrypted / decrypted and orders the creation of a digital data record.
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without these
  • Update is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored.
  • the node (2c) wants to read the current status of the data on the blockchain (8) from the network (3), he can compare the result with the status of the completion of all orders on the library chain (54), thereby ensuring that it is up-to-date and authentic.
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use.
  • a household appliance can also be a node. Confirmations can also be made from node to node via a tangle process, similar to IOTA.
  • FIG. 20 A sender (30) uses a software / app (6a) with which
  • Deliveries, states etc. can be encrypted / decrypted and instructs the creation of a digital data record.
  • the software / app (6a) takes over the
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not match the orders from the library chain (54) the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored. If a node (2c) from the network (3) wants to read the current status of the data on the blockchain (8), it can see the result with the status of the completion of all orders on the
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use. After delivery and expiry of the objection period, all personal data on the blockchain will be deleted.
  • FIG. 20 An order source person / machine / probe (30) uses one
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) asks in the
  • Library chain (54) the current order status of the blockchain (8). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without this update, he is not allowed to continue working on the blockchain and is ignored in the network.
  • the new block (11) is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored. If a node (2c) is off the network (3) wants to read the current status of the data on the blockchain (8), he can see the result with the status of the completion of all orders on the
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use. This makes the blockchain self-managing (Seif Souverän, SS).
  • Blockchain based data management as a service (BDMaaS)
  • Figure 20 A person / machine / script (30) uses a software / app (6a) with which orders / data can be encrypted / decrypted. It identifies itself via a purpose-tailored authentication process (username / password, NFC, iris scan, DNA sequence, x-factor authentication).
  • the software / app (6a) handles the connection and authentication with the network (3).
  • a node (2a) queries the current order status of the blockchain (8) in the library chain (54). If the status of the blockchain (8) does not correspond to the orders from the library chain (54), the blockchain (8) is first updated. Without these
  • Update is not allowed to continue working on the blockchain and is ignored in the network. This ensures, among other things, that a deletion order is actually carried out, whereby the rules of the EU GDPR are met accordingly.
  • the new block (11) with information about the query is attached to the current blockchain (8).
  • Another node (2b) from the network (3) queries the new status of the blockchain (8) and compares it with the status of the orders from the library chain (54). If both match, the addition of the block (11) to the blockchain (8) is confirmed by the node (2b) in the network (3), otherwise the addition of block (11) to the blockchain (8) is confirmed by the network (3) rejected and ignored.
  • a node (2c) from the network (3) wants to read the current status of the data on the blockchain (8), it can compare the result with the status of the completion of all orders on the library chain (54) and thereby check the current status and the Ensure authenticity.
  • the node (2c) delivers the data to the software / app (6b) to a requesting point (55) for further use.
  • processing logic software that defines the process and type of processing
  • Last data block (block to which a subsequent block can be added)
  • New processing logic (method and type defines a privileged resource).
  • container (contains folders or files e.g. scripts, binary, text,
  • End block (ends a blockchain, is used by a privileged
  • Info file (contains information from a privileged node)
  • Info block (only informational, is inserted by a privileged node)
  • Transaction pool (contains transactions that must be processed)
  • Transaction (contains data or instructions, is processed by a
  • Data source an external system, a machine, sensors or other data generator
  • Mergechain (arises from the merging of blockchains)
  • Merge block (defines the merging, merging, generation by privileged nodes)
  • Parameter file (contains parameters for initiation, referencing, processing, etc.)
  • Start value output value, reference for calculating the end value
  • Data any data, e.g. scripts, binary, text, rights, parameters
  • Calculation any hash algorithms such as MD5, SHA128, SHA256, etc.
  • End value (calculated hash value from start value and data)
  • Blockchain chaining of data blocks, carrier of limbchains
  • New blockchain fork, fork of a blockchain

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé pour commander un système matériel au moyen d'une chaîne de blocs, caractérisé en ce qu'une dynamisation de la chaîne de blocs est prévue par déplacement de la logique et des paramètres dans les blocs sur la chaîne de blocs elle-même et/ou sur une chaîne de registre à part, une désagrégation du logiciel de nœud, une classification des blocs en types et un élargissement des blocs autour d'une structure de conteneur renfermant la logique et les paramètres pour le procédé de traitement des blocs étant mis en œuvre. Cet abrégé est publié sans figure.
EP20703958.7A 2019-02-19 2020-01-31 Procédé pour commander un système matériel au moyen d'une chaîne de blocs Withdrawn EP3928492A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019104092.2A DE102019104092A1 (de) 2019-02-19 2019-02-19 Verfahren zum Steuern eines Hardwaresystems unter Verwendung einer Blockchain
PCT/EP2020/052477 WO2020169323A1 (fr) 2019-02-19 2020-01-31 Procédé pour commander un système matériel au moyen d'une chaîne de blocs

Publications (1)

Publication Number Publication Date
EP3928492A1 true EP3928492A1 (fr) 2021-12-29

Family

ID=69500716

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20703958.7A Withdrawn EP3928492A1 (fr) 2019-02-19 2020-01-31 Procédé pour commander un système matériel au moyen d'une chaîne de blocs

Country Status (3)

Country Link
EP (1) EP3928492A1 (fr)
DE (1) DE102019104092A1 (fr)
WO (1) WO2020169323A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220272085A1 (en) * 2021-02-24 2022-08-25 International Business Machines Corporation Blockchain network identity management using ssi
CN113435786B (zh) * 2021-07-21 2022-11-11 杭州云象网络技术有限公司 用于节点管理的区块链运维监管方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9608829B2 (en) * 2014-07-25 2017-03-28 Blockchain Technologies Corporation System and method for creating a multi-branched blockchain with configurable protocol rules

Also Published As

Publication number Publication date
DE102019104092A1 (de) 2020-08-20
WO2020169323A1 (fr) 2020-08-27

Similar Documents

Publication Publication Date Title
DE102016110939B3 (de) Datenorganisationsverfahren und Entwicklungsumgebungssystem
EP1258812B1 (fr) Base de données virtuelle de structures de données hétérogènes
DE202011110377U1 (de) System eines hierarchischen Metadaten Managements und Anwendung
DE102019123253A1 (de) System und einrichtung für datenvertraulichkeit im distributed ledger
DE112011102129T5 (de) Sicherheitsmodell für Abläufe, die sichere Fremddienste zusammenführen
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
EP3928492A1 (fr) Procédé pour commander un système matériel au moyen d'une chaîne de blocs
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
Fridgen et al. Chancen und herausforderungen von dlt (blockchain) in mobilität und logistik
EP3688928A1 (fr) Structure de blocs de données et procédé de stockage de données protégé contre des manipulations
WO2019081071A1 (fr) Procédé et système de commande pour commander et/ou surveiller des appareils
DE102012001406A1 (de) Automatische Konfiguration eines Produktdatenmanagementsystems
DE112021004613T5 (de) Redigierbare blockchain
CN116205597A (zh) 一种合同管理系统的处理方法、装置以及合同管理系统
DE102019001100A1 (de) Verfahren zur Überwachung einer Funktionalität eines Fahrzeuginformationssystems eines Kraftfahrzeugs, sowie elektronische Recheneinrichtung, Computerprogramm und Datenträger
EP3407452A1 (fr) Commande d'un réseau de distribution
EP3966723B1 (fr) Procédé et système de fourniture de données d'un système d'automatisation industriel à un système externe
DE102021130811A1 (de) Blockchain-selektive world-state-datenbank
WO2016071196A1 (fr) Procédé de modification d'une structure de données enregistrée dans une carte à puce, dispositif de signature et système électronique
Baldominos Gómez et al. Editor’s Note. Towards Blockchain Intelligence
WO2023046317A1 (fr) Unité de gestion de pièces de monnaie et procédé dans une unité de gestion de pièces de monnaie
DE102021005040A1 (de) Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
DE102005017102A1 (de) System zur Verarbeitung von ausführbaren Anwendungen, um zur Distribution geeignet zu sein
DE102022002780A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102021130943A1 (de) Konsensalgorithmus für distributed-ledger-technologie

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210915

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20231017

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20231116