DE102018004693A1

DE102018004693A1 - Blockchain-Netzwerk

Info

Publication number: DE102018004693A1
Application number: DE102018004693.2A
Authority: DE
Inventors: Leif-Nissen Lundbaek
Original assignee: Xain AG
Current assignee: Xain AG
Priority date: 2018-06-05
Filing date: 2018-06-05
Publication date: 2019-12-05

Abstract

Ein Blockchain-Netzwerk (28) oder anderes verteiltes Netzwerk (DLT) enthaltend eine Vielzahl von Clients mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken, ist dadurch gekennzeichnet, dass wenigstens einer der Clients (110) jederzeit die vollständige Blockchain speichert; und zumindest ein Teil der Clients (18) eine Teilmenge der Blockchain mit den jüngsten Blöcken (122, 124) speichert und den verbleibenden Teil (126, 128, 130, 132) der Blockchain in Form von mindestens einem Hashwert (136, 138) speichert.

Description

Technisches Gebiet
Die Erfindung betrifft ein Blockchain-Netzwerk oder anderes verteiltes Netzwerk (DLT) enthaltend eine Vielzahl von Clients mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken. Die Erfindung betrifft ferner ein Verfahren zum Speichern von Blockchains in einem Blockchain-Netzwerk oder anderen verteilten Netzwerk (DLT) mit einer Vielzahl von Clients, mit den Schritten:

(a) Erzeugen von nacheinander referenzierten Blöcken für eine Blockchain aus Informationen; und
(b) Speichern der Blöcke in der Blockchain.

Stand der Technik
Unter dem Begriff „Blockchain-Technologie“ wird eine Technologie verstanden, bei welcher viele Teilnehmer ein Netzwerk bilden. Die Blockchain ist eine kontinuierlich erweiterbare Liste von Datensätzen (Blöcken), welche mittels kryptographischer Verfahren miteinander verkettet sind. Da jeder Teilnehmer die komplette Kette kennt, ist eine Manipulation von Datensätzen in der Kette praktisch nicht möglich. Beim Mining werden Transaktionen propagiert, gesammelt, verschlüsselt und Blöcke gebildet, indem sie mit einem Header versehen werden. Dabei referenziert der aktuelle Block jeden vorhergehenden Block. Mining inzentiviert zudem die teilnehmenden Parteien, indem derjenige, der zuerst einen Header findet und dabei bestimmte Bedingungen im Netzwerk erfüllt einen meist monetären Bonus erhält. Beim Verifizieren werden syntaktische und semantische Bausteine einer Transaktionshistorie verglichen. Beispielsweise wird hierbei einerseits überprüft, ob ein Zahlungsgeber genügend Kapital für eine Zahlung besitzt und andererseits wird überprüft, ob Klartextinformationen zu den öffentlich zur Verfügung gestellten Hashwerten passen.
Bekannte Verwendungen der Blockchain-Technologie sind Kryptowährungen, wie etwa Bitcoin. Es ist ferner bekannt, die Blockchain-Technologie als Audit-Log für Auditing zu verwenden. Dabei werden sicherheitskritische Operationen von Softwareprozessen aufgezeichnet. Bekannte Auditing-Systeme sind für medizinische Informationen, Verträge, Geldtransaktionen, militärische Geheimnisse, Gesetzgebung, elektronische Stimmabgabe und das Sicherheitsmanagement kritischer Anlagen oder Daten bekannt.
WO 2017/060816 A1 offenbart ein Ressourcen Transfersystem im Finanzbereich. US 2017/0331635 A1 offenbart die Verwendung eines Zeitstempels in einer Blockchain. EP 3 236 401 A1 offenbart einen Authentifizierungsprozess zum Auslösen eines Prozesses. DE 102017 107 147 A1 offenbart eine betrugssichere Autorisierung und Authentifizierung für sichere Interaktionen mit Smartphones. GB 2548802A offenbart ein Verfahren zum Verifizieren einer elektronischen Nutzeridentität. DE 10 2016 007 472 A1 offenbart die Verwendung von Blockchain zur Registrierung von Fahrzeugdaten, wie den Kilometerstand, und Sicherung gegen nachträgliche Änderungen.
Typischerweise arbeiten alle Verfahren online, d.h. sie benötigen einen Netzwerkzugang zur Identifizierung. Jeder Teilnehmer (Client) muss nicht nur eine hohe Rechenleistung für das Bündeln und Verschlüsseln von Informationen zu einem Block aufweisen, sondern auch ausreichende Ressourcen für die Kommunikation mit dem Netzwerk haben. Mit der Zeit werden die Blockchains naturgemäß immer länger. Je mehr Transaktionen und Informationen in der Blockchain gespeichert werden, umso höher ist der Ressourcenbedarf bei den Clients. Entsprechend sind nur solche Clients für herkömmliche Blockchain-Netzwerke und andere verteilte Netzwerke (DLT) geeignet, die über ausreichende Rechenleistung verfügen. Besonders problematisch bei Blockchain-Netzwerken ist es, dass die steigende Blockchain - Länge mit einem steigenden Speicherplatzbedarf, bis in Bereiche im Tera- oder Petabytebereich verbunden ist. Es gibt Anwendungen, die durch diese hohen Anforderungen an die Rechen- und Speicherleistung der Teilnehmer nicht zugänglich sind.
Es gibt sogenannte Light Clients. Das sind Teilnehmer in einem Blockchain-Netzwerk, die nur die Blockchain benachbarter Teilnehmer verifizieren.
Offenbarung der Erfindung
Es ist Aufgabe der Erfindung, den Anwendungsbereich von Blockchain-Verfahren und Blockchain-Netzwerken zu vergrößern.
Erfindungsgemäß wird die Aufgabe bei einem Blockchain-Netzwerk oder anderen verteilten Netzwerk (DLT) der eingangs genannten Art, enthaltend eine Vielzahl von Clients mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken, dadurch gelöst, dass

(a) wenigstens einer der Clients jederzeit die vollständige Blockchain speichert; und
(b) zumindest ein Teil der Clients eine Teilmenge der Blockchain mit den jüngsten Blöcken speichert und den verbleibenden Teil der Blockchain in Form von mindestens einem Hashwert speichert.

Das erfindungsgemäße Netzwerk unterscheidet somit zwei verschiedene Clients: die „Full Clients“, welche die vollständige Blockchain speichern kann und einen entsprechend hohen Speicherplatz aufweist und die „Processor Clients“, welche einen erheblich geringeren Speicherplatzbedarf haben. Die Processor Clients speichern nicht die vollständige Blockchain, sondern lediglich die jüngsten Blöcke. Beispielsweise die letzten k Blöcke. Alle übrigen n Blöcke können in Form von einem oder mehreren wesentlich kürzeren Hashwerten gespeichert werden. Die ursprünglich erfassten und gebroadcasteten Informationen lassen sich den Hashwerten nicht mehr entnehmen. Diese liegen nur noch bei dem Full Client vor. Eine Manipulation der bei dem Full Client vorgenommenen Informationen führt aber mit sehr hoher Wahrscheinlichkeit zu einem geänderten Hashwert. Entsprechend kann der Processor Client mit Hilfe der Hashwerte weiterhin die Daten in den Blöcken verifizieren.
Der Processor Client hat auch offline Zugang zu den Informationen, die in den ersten Blöcken enthalten sind und ohne Bildung eines Hashwertes in üblicher Weise gespeichert sind. Der Processor Client hat aber online auch Zugang zu den Informationen, die in den übrigen Blöcken bei einem Full Client gespeichert sind. Der im Processor Client gespeicherte Hashwert dient der Überprüfung der Daten, die beim Full Client abgefragt und übertragen werden.
Die Anzahl der Blöcke in einer Blockchain steigt in der Regel an. Der Speicherplatz bei einem Processor Client hingegen bleibt gleich. Es kann daher vorgesehen sein, dass die Größe des verbleibenden Teils der Blockchain, die in Form von mindestens einem Hashwert gespeichert wird, in Abhängigkeit von dem zur Verfügung stehenden Speicherplatz zum Speichern der Blockchain ausgewählt ist. Auf diese Weise wird eine maximale Anzahl an Blocks in ursprünglicher Form gespeichert und alle älteren Blöcke deren Speicherplatzbedarf den vorgesehenen Speicherplatz überschreitet, in gehashter Form gespeichert. Es müssen also nicht mehr Blöcke als nötig in gehashter Form gespeichert werden.
Bei einer besonders bevorzugten Ausgestaltung der Erfindung ist vorgesehen, dass der Teil der Blockchain, der in Form von mindestens einem Hashwert gespeichert wird, eine Vielzahl von Blöcken umfasst und die Blöcke gruppenweise zu mehreren Hashwerten gehasht werden und die so jeweils für eine Gruppe von Blöcken erzeugten Hashwerte gespeichert werden. So wird einzelnen Blöcken oder Gruppen von Blöcken ein eigener Hashwert zugeordnet. Auf diese Weise lässt sich bei einer Manipulation der vom Full Client gespeicherten Blöcke lokalisieren, welcher der Blöcke bzw. welche Gruppe von Blöcken manipuliert wurde. Beispielsweise werden die ersten, d.h. jüngsten, k Blöcke normal und ohne Hashwert-Bildung gespeichert. Diese können in üblicher Form entschlüsselt werden und der Inhalt ist normal verfügbar. Die nächsten n-k Blöcke können als Gruppe gebündelt werden und es wird ein Hashwert für diese ersten n-k Blöcke gebildet. Die nächsten m-(n+k) Blöcke werden in einer weiteren Gruppe gebündelt und es wird ein Hashwert für diese nächste Gruppe gebildet usw. bis alle Blöcke in einem Hashwert repräsentiert sind. Mit dem Hashwert kann jeder Processor Client die Echtheit der Daten verifizieren.
Die Anzahl der Gruppen und die Anzahl der Blöcke in den Gruppen kann so gewählt werden, dass eine hinreichende Genauigkeit bei der Lokalisierung einer Änderung der Blöcke bei dem Full Client vorliegt. Diese hängt u.a. auch von der Länge der Blockchain, d.h. der Anzahl und Größe der Blöcke in der gesamten Blockchain ab. Die Anzahl der vollständig gespeicherten, jüngeren Blöcke richtet sich u.a. nach dem verfügbaren Speicherplatz. Je mehr Speicherplatz zur Verfügung steht, umso mehr Blöcke können im Original gespeichert werden. Die Art der Gruppierung kann insbesondere flexibel gestaltet sein und kann, muss aber nicht von vorneherein festgelegt werden. So können immer mehr Blöcke in einer Gruppe zu einem Hashwert gehasht werden, je älter die Blockchain ist und je mehr Blöcke die Blockchain umfasst. Die jüngsten Blöcke bleiben immer offline verfügbar. Es ist auch nicht erforderlich, dass alle Gruppen die gleiche Größe werden. Auch diese kann variabel gestaltet sein.
Bei einer weiteren Ausgestaltung der Erfindung umfassen ein oder mehrere Blöcke Smart Contracts. Es ist je nach Anwendung wünschenswert, dass die Smart Contracts oder auch andere Informationen und Datensätze jederzeit, insbesondere auch offline, zur Verfügung stehen. Der Zugriff des Processor Clients auf die Smart Contracts in dem Genesis - Block oder einem der Blöcke, für welche bei ihm nur ein Hashwert gespeichert ist, erfordert eine Online Verbindung zum Full Client und ist offline ansonsten nicht möglich. Eine bevorzugte Ausgestaltung der Erfindung sieht daher vor, dass einzelne Informationen, die ständig verfügbar sein sollen, insbesondere ein Smart Contract, welcher im Genesis-Block oder einem der Blöcke enthalten ist, für den nur ein Hashwert gespeichert ist, unverändert in einem Checkpoint speicherbar ist, welcher nicht gehasht wird. Der Checkpoint ist ein Speicherplatz, in dem alle Smart Contracts und ständig erforderliche Informationen und Datensätze als vollständiger Datensatz gespeichert sind. Die Daten dürfen in üblicher Weise verschlüsselt abgelegt sein, sind aber nicht gehasht. Entsprechend liegen sie vollständig bei dem Processor Client vor und sind auch offline verfügbar.
Der Full Client übernimmt vorwiegend die Aufgabe ausreichend Speicherplatz zur Verfügung zu stellen. Der wenigstens eine Full Client muss daher zwar Teil des Netzwerks sein, aber nicht unbedingt selber Transaktionen sammeln, verschlüsseln und Blöcke bilden (Mining). Entsprechend ist es vorzugsweise vorgesehen, dass wenigstens einer der Clients der die vollständige Blockchain speichert, kein Miner ist. Der Full Client kann kostengünstiger ausgeführt werden und braucht zusätzlich zu der hohen Speicherkapazität nur eine im Vergleich zu den Processor Clients geringe Rechenleistung.
Die erfindungsgemäße Aufgabe wird auch gelöst durch ein Verfahren zum Speichern von Blockchains in einem Blockchain-Netzwerk oder anderen verteilten Netzwerk (DLT) mit einer Vielzahl von Clients, mit den Schritten:

Das Verfahren ist dadurch gekennzeichnet, dass

(c) die vollständige Blockchain von wenigstens einem der Clients jederzeit gespeichert wird; und
(d) eine Teilmenge der Blockchain mit den jüngsten Blöcken und der verbleibende Teil der Blockchain in Form von mindestens einem Hashwert von wenigstens einem anderen Client gespeichert wird.

Das Verfahren kann insbesondere mit einer geeigneten Software auf Rechnern durchgeführt werden, welche Teil eines Blockchain - Netzwerks oder anderen verteilten Systems (DLT) sind.
Die erfindungsgemäße Aufgabe wird schließlich auch gelöst durch einen Client für ein Blockchain-Netzwerk oder anderes verteiltes Netzwerk mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken, der dadurch gekennzeichnet ist, dass

(a) nur eine Teilmenge der Blockchain mit den jüngsten Blöcken gespeichert wird; und
(b) der verbleibende Teil der Blockchain in Form von mindestens einem Hashwert zum Verifizieren der Blöcke der an anderer Stelle vollständig gespeicherten Blockchain gespeichert wird.

Bevorzugte Processor Clients, welche einen Teil der Blöcke einer Blockchain in Form eines oder mehrerer Hashwerte speichern, weisen insbesondere Mittel auf, mit welchen die Anzahl der vollständig gespeicherten Blöcke und die Anzahl der Blöcke oder Gruppen von Blöcken bestimmt werden, für welche nur ein Hashwert bzw. mehrere Hashwerte gespeichert werden. Dabei kann insbesondere die Speicherkapazität oder Restspeicherkapazität berücksichtigt werden.
Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Ein Ausführungsbeispiel ist nachstehend unter Bezugnahme auf die beigefügten Zeichnungen näher erläutert.
Definitionen
In dieser Beschreibung und in den beigefügten Ansprüchen haben alle Begriffe eine dem Fachmann geläufige Bedeutung, welche der Fachliteratur, Normen und den einschlägigen Internetseiten und Publikationen, insbesondere lexikalischer Art, beispielsweise www.Wikipedia.de, www.wissen.de oder

• „Blockchain Basics, A Non-Technical Introduction in 25 Steps" von Daniel Drescher, erschienen 2017 bei Apress Frankfurt am Main, ISBN-13(pbk): 978-1-4848-2603-2,
• „Bitcoin, Blockchain und Kryptoassets, Eine umfassende Einführung" von Aleksander Berentsen und Fabian Schär, Erschienen 2017 bei BoD Norderstedt, Universität Basel, ISBN: 978-3-7386-5392-2

Weiterhin werden hier folgende Bedeutungen für die verwendeten Begriffe zugrunde gelegt:

Block: Datensatz, welcher mittels kryptographischer Verfahren verschlüsselt ist und Teil einer Blockchain bildet.
Blockchain: kontinuierlich erweiterbare Liste von Datensätzen (Blöcken), welche mittels kryptographischer Verfahren miteinander verkettet sind.
Client: Computerprogramm (mit oder ohne Hardware), das auf dem Endgerät eines Netzwerks ausgeführt wird.
Entschlüsseln: Überführung eines verschlüsselten Datensatzes in einen lesbaren Datensatz mit Hilfe eines Schlüssels
Full Client: Client, mit hoher Speicherplatzkapazität.
hashen: Bildung eines Hashwertes
Hashwert: Wert, welcher einen Schlüssel oder einen anderen Wert repräsentiert. Der Hashwert kann aus dem Schlüssel oder Wert, aber der Schlüssel nicht aus dem Hashwert hergeleitet werden. Hashwerte, die nach herkömmlichen Hashverfahren erzeugt werden, können auch gekürzt werden. Diese gekürzten Hashwerte werden hier als Adresse oder ebenfalls als Hashwert bezeichnet. Statt Hashwert wird gelegentlich auch der Begriff „Hash“ verwendet.
Mining: Transaktionen propagieren, sammeln, verschlüsseln und durch versehen mit einem Header Blöcke bilden. Dabei referenziert der aktuelle Block jeden vorhergehenden Block.
Processor Client: Client mit geringerer Speicherkapazität, der zum Mining vorgesehen ist und mit Hilfe effizienter Speichermechanismen einen Full Client verifizieren kann.
Smart Contract: Computerprotokoll, das einen Vertrag abbildet oder überprüft. Ein Beispiel für einen Smart Contract ist ein Key Value Store.
Verifizieren: Vergleichen syntaktischer und semantischer Bausteine einer Transaktionshistorie.
Verschlüsseln: Überführen eines Datensatzes in einen verschlüsselten Datensatz mit Hilfe eines Schlüssels
verteiltes System: basiert auf der Distributed Ledger Technology (DLT) und ist eine Technologie für vernetzte Computer, die zu einer Übereinkunft (Konsensus) über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Das verteilte System dient zur Verwaltung von Daten insbesondere im Internet ohne proprietäre Plattform. Ein Beispiel für eine DLT Technologie ist Blockchain.

Figurenliste

1 illustriert den Aufbau und die Funktionsweise eines Full Clients und eines Processor Clients.
2 illustriert den Aufbau eines Blockchain-Netzwerks mit Hersteller und den Kraftfahrzeugen einer Kraftfahrzeugflotte als Teilnehmer.

Beschreibung der Ausführungsbeispiele
2 zeigt ein Ausführungsbeispiel, bei dem ein Smartphone 10 zum Auf- und Zuschließen eines Kraftfahrzeugs einer Kraftfahrzeugflotte verwendet wird. Das Kraftfahrzeug weist einem Single-Board Computer (SBC) 12 auf. Der Single Board Computer 12 besteht im Wesentlichen aus einer Platine, die in einer elektronischen Steuereinheit vorgesehen ist. Neben dem Single Board Computer 12 weist die elektronische Steuereinheit einen CAN Bus 16 auf, der die Verbindung zu den Fahrzeugsystemen, d.h. den Aktuatoren und Sensoren des Fahrzeugs herstellt. Zu den Fahrzeugsystemen gehört auch das im vorliegenden Ausführungsbeispiel anzusteuernde Türschloss. Es versteht sich, dass jedes beliebige Fahrzeugsystem über den CAN Bus 16 oder einen anderen Bus ansteuerbar ist und die Erfindung nicht auf den Einsatz mit Türschlössern beschränkt ist.
Auf dem Single Board Computer 12 ist ein nachstehend näher erläuterter Processor Client 18 vorgesehen. Der Processor Client 18 ist für die Verarbeitung von Daten, insbesondere zum Mining und zum Speichern von Informationen vorgesehen. Der Single Board Computer 12 speichert ferner ein Fahrzeug-Wallet 20 mit verschlüsselten Private Keys zum Signieren von Transaktionen und zum Verschlüsseln von Kommunikation.
Für die Kommunikation ist ein Bluetooth Low Energy (BLE) Modul 22 auf dem Single Board Computer 12 vorgesehen. Das BLE-Modul 22 dient der Implementierung eines Transaktionsprotokolls für die Kommunikation mit dem Smartphone 10. Dies ist durch einen Pfeil 24 repräsentiert.
Der Processor Client 18 kommuniziert mit einem Blockchain-Netzwerk 28 mit einer Vielzahl von Nodes 46. Dies ist durch Pfeile 30 und 31 repräsentiert. Ein CAN Bus Modul 32 dient als Interface zwischen dem Single Board Computer 12 und dem CAN Bus 16 und den daran angeschlossenen Fahrzeugsystemen. Es versteht sich, dass statt eines CAN Bus-Systems auch jeder andere BUS verwendet werden kann.
Auf dem Smartphone 10 ist eine Applikation 40 installiert, welche ein digitales Wallet in Form eines HD Wallets 36 aufweist.
Die Applikation 40 umfasst ferner ein BLE Modul 42 für die Kommunikation mit dem BLE Modul 22 im Fahrzeug. Es kann ein Modul für die Kommunikation der Applikation 40 mit weiteren Clients, etwa Prozessoren oder Datenloggern, etwa für Smart Contracts vorgesehen sein. Das Blockchain-Netzwerk 28 umfasst eine Vielzahl von Nodes 46. Die Nodes 46 haben unterschiedliche Eigenschaften und können auf unterschiedlichen Wegen miteinander kommunizieren.
Das Smartphone 10 bildet einen ersten Teilnehmer (Node) des Netzwerks. Die Steuereinheit des Single Board Computers 12 bildet einen zweiten Teilnehmer (Node) des Netzwerks 28. Beide Teilnehmer haben eine drahtlose Verbindung 24, die auch ohne Verbindung zum Internet, Telefonnetz oder einem anderen Netzwerk hergestellt werden kann. Im vorliegenden Ausführungsbeispiel wurde eine BLE-Verbindung verwendet. Es versteht sich, dass auch andere Verbindungen möglich sind.
Im vorliegenden Ausführungsbeispiel wurden mehrere Smart Contracts 50, 52 verwendet. Zu den Smart Contracts zählen beispielsweise ein User Register 50 und Vehicle State 52, in dem der Fahrzeugzustand aufgeführt ist. Im vorliegenden Ausführungsbeispiel wurden mehrere Smart Contracts verwendet. Die Verwendung weiterer Smart Contracts ist möglich und hängt von der konkreten Anwendung ab. Es ist aber auch möglich, alle Zusammenhänge in weniger Smart Contracts, insbesondere auch in nur einem einzigen Smart Contract festzulegen.
Das UserRegister 50 listet alle Nutzer des Systems auf. Es erlaubt Anfragen ob eine Adresse einen Nutzer repräsentiert und schafft die Möglichkeit Nutzer aus dem System auszuschließen. Das UserRegister 50 ist somit eine sogenannte Whitelist, von der Nutzer gestrichen werden können.
Der VehicleState 52 ist ein Smart Contract und repräsentiert den Fahrzeugzustand. Dazu gehören die Auflistung der möglichen mit einem Befehl verbundenen Rechte, eine Zuordnung zu einem Nutzer und das Zuordnen von Adressen, z.B. zu Rechten. Die Rechte bestimmen, für welche Nutzer welche Rechte an dem jeweiligen Fahrzeug bestehen. Beispiele für solche Rechte sind das Öffnen der Türen, des Kofferraums oder das Recht das Fahrzeug zu starten.
Für die Zugangskontrolle werden asymmetrische Verschlüsselungsverfahren verwendet, die bekannt sind und hier daher nicht im Detail beschrieben werden.
Die Fahrzeugflotte bildet ein quasi offenes Blockchain-Netzwerk 28. Jeder, der ein Fahrzeug mit einem Processor Client 18 hat, ist Teil des Netzwerks. Die Processor Clients 18 des Netzwerks 28 sammeln Informationen und Daten über Transaktionen und dergleichen und broadcasten diese in dem Blockchain-Netzwerk 28. Entsprechend liegen alle Daten in Form einer Blockchain bei allen Clients. Die Datenmenge der Blockchain übersteigt - von einem Anfangsstadium abgesehen - die Speicherkapazität der Processor Clients 18. Der Processor Client 18 speichert daher nicht mehr die vollständige Blockchain, sondern die jüngsten Blöcke der Blockchain. Die übrigen Blöcke der Blockchain werden in Form von Hashwerten gespeichert. Zusätzlich sind ein oder mehrere Full Clients 110 vorgesehen.
1 zeigt einen Ausschnitt aus dem Blockchain-Netzwerk 28 mit zwei verschiedenen Teilnehmern: einem Full Client 110 und einem Processor Client 18. Typischerweise sind einige wenige weitere Full Clients in dem Blockchain-Netzwerk 28 vorgesehen und eine große Vielzahl weiterer Processor Clients 18. Das Verhältnis zwischen Full Client 110 und Processor Client 18 ist 1:n, wobei n eine Zahl größer als 2, typischerweise die Anzahl der Fahrzeuge der Fahrzeugflotte, ist.
Im vorliegenden Ausführungsbeispiel werden die Processor Clients 18 auf Boardcomputern in Kraftfahrzeugen einer Kraftfahrzeugflotte gebildet. Ein Boardcomputer hat eine Speicherkapazität im Bereich von einigen 10 Mbyte, zum Beispiel 32 Mbyte. Es versteht sich, dass die Speicherkapazität mit zunehmender Komplexität der Anwendungen und gespeicherten Daten zunimmt. Der Full Client 110 oder mehrere Full Clients 110 sind im vorliegenden Ausführungsbeispiel auf einem Zentralrechner bei einem Hersteller der Kraftfahrzeuge installiert. Hier sind große Speicherkapazitäten im Bereich von Tera- oder Petabyte vorhanden. Es versteht sich, dass die Erfindung auch auf andere Beispiele angewendet werden kann und selbstverständlich nicht nur auf Kraftfahrzeuge beschränkt ist.
Alle Clients 110, 18 des Blockchain-Netzwerks 28 haben Kommunikationsmittel zum Kommunizieren untereinander. Derartige Kommunikationsmittel können ganz oder teilweise drahtlose Verbindungen aufbauen. Dies ist durch Pfeile 114, 116, 118 und 120 illustriert.
Die vollständige Blockchain des Blockchain-Netzwerks 28 ist bei dem Full Client 110 gespeichert. Mit „k“ ist die Anzahl der Blöcke einer Gruppe mit den jüngsten Blöcken bezeichnet. Block 122 ist der jüngste Block der Gruppe und Block 124 der zuerst gespeicherte Block der Gruppe. Dazwischen liegen weitere k-2 Blöcke.
An den k-ten Block 124 der Blockchain schließen sich weitere n-k Blöcke an. Der erste Block dieser zweiten Gruppe ist in 1 mit 126 bezeichnet und der letzte Block dieser zweiten Gruppe ist in 1 mit 128 bezeichnet.
Der erste Block der dritten Gruppe ist in 1 mit 130 bezeichnet. Der letzte Block dieser dritten Gruppe ist in 1 mit 132 bezeichnet. Die Blockchain umfasst, wie graphisch angedeutet, weitere solche Gruppen. Der letzte Block der Blockchain, d.h. der älteste Block 134, ist der Genesis Block. Typischerweise umfasst der Genesis Block 134 Smart Contracts 50 und andere Daten, welche alle Nodes des Netzwerks regelmäßig für ihre Transaktionen, Verifikationen und sonstigen Handlungen benötigen. Es ist ferner ein zweiter Smart Contract 52 beispielhaft in einem der Blöcke der dritten Gruppe mit m-(n+k) Blöcken gespeichert.
Die Blockchain liegt wird auch von allen anderen Full Clients 110 in vollständiger Form gespeichert. Dabei entsteht ein ein hoher Speicherplatzbedarf, der von den Bord Computern 12 in den Fahrzeugen nicht gedeckt werden kann. Die Processor Clients 18 sehen dafür vor, dass nur die ersten k Blöcke 122 bis 124 vollständig gespeichert werden. Die übrigen Blöcke der Blockchain werden nicht gespeichert. Um dennoch jederzeit eine Verifizierung der nicht-gespeicherten Blöcke vornehmen zu können, wird für diese Blöcke 126 bis 134 ein Hashwerte 136 gebildet. Beispielsweise kann ein einziger Hashwert für alle Blöcke 126 bis 134 gespeichert werden. Wird an einem der Blöcke 126 bis 134 eine Änderung vorgenommen, stimmt der Hashwert 136 nicht mehr mit dem Hashwert für die geänderten Blöcke überein. Der Processor Client 18 detektiert beim Verifizieren, repräsentiert durch Pfeil 118, mit hoher Wahrscheinlichkeit praktisch jede Änderung.
Bei nur einem einzigen Hashwert 136 ist es schwierig die Änderung zu lokalisieren. Es kann nicht angegeben werden, in welchem Block genau die Änderung vorgenommen wurde. Es ist daher bei dem vorliegenden Ausführungsbeispiel vorgesehen, dass die nicht-gespeicherten Blöcke 126 bis 134 der Blockchain in Gruppen aufgeteilt werden. Die n-k Blöcke 126 bis 128 bilden beispielsweise eine Gruppe. Die m-(n+k) nächsten Blöcke 130 bis 132 bilden eine weitere Gruppe usw. Für jede Gruppe wird ein eigener Hashwert 136 bzw. 138 gebildet. Mit diesen Hashwerten 136 und 138 können die Gruppen von Blöcken verifiziert werden. Die Hashwerte 136 und 138 erfordern erheblich weniger Speicherplatz als die Blöcke der Blockchain. Dadurch kann erreicht werden, dass auch kleine Processor Clients 18 mit nur geringer Speicherkapazität Teilnehmer in dem Blockchain-Netzwerk 28 sein können.
Die Daten und Informationen der gehashten Blöcke liegen in den Processor Clients 18 nicht mehr vor. Wenn der Processor Client diese Daten oder Informationen benötigt, kann er auf die Daten und Informationen im Full Client 110 zugreifen. Hierfür ist eine Kommunikationsverbindung erforderlich, d.h. der Processor Client 18 muss hierfür online sein. Die wesentlich häufiger verwendeten, jüngeren Daten der ersten k Blöcke 122' bis 124', die identisch mit den k Blöcken 122 bis 124 beim Full Client 110 sind, hingegen sind jederzeit verfügbar und auch ohne Kommunikationsverbindung zugänglich.
Im vorliegenden Ausführungsbeispiel ist vorgesehen, dass der Full Client 110 keine Mining-Funktion hat. Diese wird von den Processor Clients 18 übernommen. Die Processor Clients 18 sammeln alle Transaktionen und erzeugen einen neuen Block 140'. Dieser Block 140' wird in üblicher Weise gebroadcastet, d.h. im Blockchain-Netzwerk 28 kommuniziert. Dies ist durch einen Pfeil 114 repräsentiert. Der Full Client 110 fügt diesen neuen Block als Block 140 zu seiner Blockchain hinzu.
Je nach Auslastung des Speichers durch die Blockchain des Processor Clients 18 kann sich die Notwendigkeit ergeben, die Gruppierung der Blöcke zu ändern. Wenn mehr „alte“ Blöcke in einer Gruppe gruppiert werden, werden weniger Hashwerte gespeichert und/oder die Anzahl k der vollständig gespeicherten ersten Blöcke sinkt. Dadurch wird wieder weniger Speicherplatz belegt.
Es gibt Anwendungen, welche wie im vorliegenden Ausführungsbeispiel, Smart Contracts 50, 52 verwenden. Der Inhalt der Smart Contracts ist nur online verfügbar, wenn diese in Blöcken 126 bis 134 liegen, die nur beim Full Client 110 gespeichert sind. Einem Hashwert 138 oder 138 kann der Inhalt eines Smart Contracts 50, 52 nicht entnommen werden. Es ist jedoch oft erforderlich, den Inhalt der Smart Contracts 50 und 52 auch offline verfügbar zu machen, wenn keine Kommunikationsverbindung zu einem der Full Clients 110 besteht. Es ist daher ein Checkpoint 142 für Smart Contracts vorgesehen. Der Checkpoint 142 umfasst einen Speicherplatz sowohl in der Blockchain beim Full Client 110, als auch in der Blockchain beim Processor Client 18, in dem die Smart Contracts vollständig gespeichert sind. Diese sind jederzeit, also auch offline verfügbar.
Mit der oben beschriebenen Anordnung wird eine quasi offene Blockchain verwirklicht. Der Hersteller verbaut die Blockchain in den Fahrzeugen seiner Fahrzeugflotte. Dabei können auch weitere Fahrzeuge Teil der Blockchain sein. Der Hersteller hat aber keinen Zugriff auf die Daten, weil diese verschlüsselt sind. Funktionalitäten und Transaktionen, die offline erfolgen, können auch im Nachhinein unter Mitwirkung des Full Clients geloggt werden. Dabei ist es nicht erforderlich, dass der Full Client selber ein Mining durchführt. Der Processor Client ist in jedem Fahrzeug vorhanden und übernimmt die Funktion des Mining. Dabei kann er selbstständig alle Daten verifizieren. Blöcke, die offline gebildet werden, werden gebroadcastet, sobald der Processor Client wieder online ist.
Die vorstehende Erfindung wurde hier anhand eines konkreten Ausführungsbeispiels beschrieben. Die Beschreibung dient jedoch nur zur Illustration der Erfindung. Der Umfang der Erfindung lässt eine Vielzahl von Variationen zu, die ausschließlich vom Schutzbereich der beigefügten Ansprüche bestimmt werden. So sind bestimmte Merkmale hinsichtlich Anordnung und Aufbau des Ausführungsbeispiels, Verwendung von Funktionen und Operatoren, Bildung von Hashwerten und Übertragungsprotokollen lediglich sinnvolle Ausgestaltungen. Statt der Hashwerte können auch die zugehörigen Schlüssel verwendet werden. Statt eines Bordcomputers können beliebige andere Rechner verwendet werden. Auch kann die Erfindung bei anderen Arten von Teilnehmern, etwa anderen Fahrzeugen und Maschinen verwirklicht werden. Dies gilt für alle Merkmale und deren Kombinationen, solange in den Ansprüchen nicht eine bestimmte Kombination von Merkmalen als erfindungswesentlich offenbart ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 2017/060816 A1 [0004]
US 2017/0331635 A1 [0004]
EP 3236401 A1 [0004]
DE 102017107147 A1 [0004]
GB 2548802 A [0004]
DE 102016007472 A1 [0004]

Zitierte Nicht-Patentliteratur

„Blockchain Basics, A Non-Technical Introduction in 25 Steps“ von Daniel Drescher, erschienen 2017 bei Apress Frankfurt am Main, ISBN-13(pbk): 978-1-4848-2603-2 [0022]
„Bitcoin, Blockchain und Kryptoassets, Eine umfassende Einführung“ von Aleksander Berentsen und Fabian Schär, Erschienen 2017 [0022]

Claims

Blockchain-Netzwerk (28) oder anderes verteiltes Netzwerk (DLT) enthaltend eine Vielzahl von Clients mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken, dadurch gekennzeichnet, dass (a) wenigstens einer der Clients (110) jederzeit die vollständige Blockchain speichert; und (b) zumindest ein Teil der Clients (18) eine Teilmenge der Blockchain mit den jüngsten Blöcken (122, 124) speichert und den verbleibenden Teil (126, 128, 130, 132) der Blockchain in Form von mindestens einem Hashwert (136, 138) speichert.
Blockchain-Netzwerk oder anderes verteiltes Netzwerk nach Anspruch 1, dadurch gekennzeichnet, dass die Größe des verbleibenden Teils der Blockchain, die in Form von mindestens einem Hashwert gespeichert wird, in Abhängigkeit von dem zur Verfügung stehenden Speicherplatz zum Speichern der Blockchain ausgewählt ist.
Blockchain-Netzwerk oder anderes verteiltes Netzwerk nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Teil der Blockchain, der in Form von mindestens einem Hashwert gespeichert wird, eine Vielzahl von Blöcken (126, 128, 130, 132) umfasst und die Blöcke gruppenweise zu mehreren Hashwerten (136, 138) gehasht werden und die so jeweils für eine Gruppe von Blöcken erzeugten Hashwerte gespeichert werden.
Blockchain-Netzwerk oder anderes verteiltes Netzwerk nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass ein Smart Contract (50, 52), welcher im Genesis-Block oder einem der Blöcke enthalten ist, für den nur ein Hashwert gespeichert ist, unverändert in einem Checkpoint (142) speicherbar ist, welcher nicht gehasht wird.
Blockchain-Netzwerk oder anderes verteiltes Netzwerk nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass wenigstens einer der Clients (110) der die vollständige Blockchain speichert, kein Miner ist.
Verfahren zum Speichern von Blockchains in einem Blockchain-Netzwerk oder anderen verteilten Netzwerk (DLT) mit einer Vielzahl von Clients, mit den Schritten: (a) Erzeugen von nacheinander referenzierten Blöcken für eine Blockchain aus Informationen; und (b) Speichern der Blöcke in der Blockchain; dadurch gekennzeichnet, dass (c) die vollständige Blockchain von wenigstens einem der Clients (110) jederzeit gespeichert wird; und (d) eine Teilmenge der Blockchain mit den jüngsten Blöcken und der verbleibende Teil der Blockchain in Form von mindestens einem Hashwert von wenigstens einem anderen Client (18) gespeichert wird.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Größe des verbleibenden Teils der Blockchain, die in Form von mindestens einem Hashwert gespeichert wird, in Abhängigkeit von dem zur Verfügung stehenden Speicherplatz zum Speichern der Blockchain bestimmt wird.
Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass der Teil der Blockchain, der in Form von mindestens einem Hashwert gespeichert wird, eine Vielzahl von Blöcken umfasst und die Blöcke gruppenweise zu mehreren Hashwerten gehasht werden und die so jeweils für eine Gruppe von Blöcken erzeugten Hashwerte gespeichert werden.
Verfahren nach einem der vorgehenden Ansprüche 6 bis 8, dadurch gekennzeichnet, dass ein Smart Contract (50, 52), welcher im Genesis-Block oder einem der Blöcke enthalten ist, für den nur ein Hashwert gespeichert wird, unverändert in einem Checkpoint (142) gespeichert wird, welcher nicht gehasht wird.
Verfahren nach einem der vorgehenden Ansprüche 6 bis 9, dadurch gekennzeichnet, dass wenigstens einer der Clients (110) der die vollständige Blockchain speichert, kein Miner ist.
Client (18) für ein Blockchain-Netzwerk (28) oder anderes verteiltes Netzwerk mit einem Speicher zum Speichern von Blockchains oder anderen Informationen in Form von nacheinander referenzierten Blöcken, dadurch gekennzeichnet, dass (a) nur eine Teilmenge der Blockchain mit den jüngsten Blöcken gespeichert wird; und (b) der verbleibende Teil der Blockchain in Form von mindestens einem Hashwert zum Verifizieren der Blöcke der an anderer Stelle vollständig gespeicherten Blockchain gespeichert wird.
Client nach Anspruch 11, gekennzeichnet durch Mittel zum Erzeugen und Broadcasten von neuen Blöcken.
Client nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass Mittel zum Speichern von Smart Contracts (50, 52), welche in den gehashten Blöcken enthalten sind, außerhalb der gehashten Blöcke in der Blockchain vorgesehen sind.