DE102019109560A1

DE102019109560A1 - Vertrauensanker-Blockketten-Verifizierung

Info

Publication number: DE102019109560A1
Application number: DE102019109560.3A
Authority: DE
Inventors: Vinodkumar Gangal
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2019-04-11
Filing date: 2019-04-11
Publication date: 2020-10-15
Also published as: US11736294B2; US20200328892A1

Abstract

Hier wird eine Vertrauensanker-Vorrichtung offenbart, die einen oder mehrere Prozessoren umfasst, die zu Folgendem ausgelegt sind: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; und in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung erfüllt, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronisches Buchs entsprechen.

Description

Technisches Gebiet
Verschiedene Ausführungsformen beziehen sich auf Blockketten-Schürfen.
Hintergrund
Blockketten können einen Konsensalgorithmus verwenden, der ein strukturiertes Mittel zur weitverbreiteten Akzeptanz eines neu hinzugefügten Blocks schafft und gleichzeitig zur Verbesserung der Sicherheit und zur Verhinderung von Betrug beiträgt. Zwei aktuelle Konsensalgorithmen für das Blockketten-Schürfen umfassen Arbeitsnachweis (Proof of Work, PoW) und Anteilsnachweis (Proof of Stake, PoS).
Bei PoW basiert die Fähigkeit, Blöcke zu schürfen, auf der Fähigkeit, ein komplexes mathematisches Problem zu lösen. Die Probleme werden im Allgemeinen so gewählt, dass sie mathematisch rigoros sind und erhebliche Betriebsmittel erforderlich sind, um das Problem auf konkurrenzfähige Weise zu lösen. Potenzielle Schürfer konkurrieren darum, als Erster das Problem zu lösen. Der erste Schürfer, der das Problem löst, sendet die Lösung an das Netz, darf einen Block schürfen und erhält im Allgemeinen eine Belohnung. PoW erhöht theoretisch die Sicherheit und verringert Betrug, indem die Kosten betrügerischer Schürfversuche aufgrund der erheblichen Rechenmittel, die für die Konkurrenzfähigkeit in dem PoW-System erforderlich sind, erheblich gesteigert werden. Viele Blockkettensysteme wie beispielsweise Bitcoin verwenden derzeit den Arbeitsnachweis.
PoW bringt jedoch Nachteile hinsichtlich des Energieverbrauchs mit sich. Da die mathematischen Probleme für PoW sehr rechenintensiv sind, benötigen potenzielle Schürfer große Mengen elektrischer Energie, um in einem PoW-System konkurrenzfähig zu sein. Angesichts der großen Anzahl potenzieller Schürfer, die in einem PoW-System konkurrieren können, kann der Energiebedarf für PoW sehr hoch sein. Es ist zu erwarten, dass der Energiebedarf für das PoW-System von Bitcoin bald mit dem Energieverbrauch bestimmter kleiner Industrienationen vergleichbar sein wird. Es ist wünschenswert, eine weniger energieintensive Alternative für das Sicherheitsproblem zu schaffen, das PoW löst.
Ein weiterer Konsensalgorithmus ist PoS. Bei PoS wird der Schürfer eines neuen Blocks deterministisch basierend auf dem Vermögen ausgewählt, wobei das Vermögen als Anteil bezeichnet wird. PoS kann ausgeführt werden, ohne das komplexe mathematische Problem zu lösen, das möglicherweise bei PoW verwendet wird, und daher werden die für PoW erforderlichen Rechenmittel erheblich reduziert. Daher benötigt PoS weniger Energie und ist daher möglicherweise effizienter als PoW. Dementsprechend haben bestimmte Blockkettensysteme ein Interesse an der Umstellung von einem PoW-basierten System auf ein PoS-basiertes System gezeigt.
Ein möglicher Nachteil der Umstellung von PoW auf PoS ist eine zumindest theoretische Verringerung der Sicherheit. Aus den oben genannten Gründen müssen Schürfer in einem PoW-System möglicherweise erhebliche finanzielle Investitionen tätigen, um konkurrenzfähig zu werden, und daher sind sie in hohem Maße motiviert, fair zu schürfen und betrügerische Transaktionen zu vermeiden. Theoretisch müssen PoS-Schürfer (die auch als „Schmiede“ bezeichnet werden können) einen Anteil an der Kryptowährung halten und sind daher die Hüter ihres eigenen Vermögens. Theoretisch kann dies ein gewisses Maß an Sicherheit bieten. Es wird jedoch angenommen, dass PoS-Systeme zumindest aufgrund der anderen erfinderischen Struktur eher versuchten betrügerischen Transaktionen ausgesetzt sein können als PoW-Systeme.
Eine Art einer solchen betrügerischen Transaktion ist als „doppelte Ausgaben“ bekannt. Bei einer Transaktion mit doppelten Ausgaben schließt ein Schmied eine Transaktion ab, in der eine Währung gesendet wird. Der Schmied erstellt dann eine Gabelung in der Transaktionskette und kann eine Transaktion erstellen, bei der der Schmied der Empfänger des Währungsbetrags ist. Unter Verwendung verschiedener Verfahren, wobei beispielsweise darauf gebaut wird, dass die betrügerische Gabelung basierend darauf akzeptiert wird, dass sie die längste Kette ist, kann die gegabelte Kette mit der betrügerischen Transaktion letztendlich innerhalb des Blocks akzeptiert und dem Blockketten-Register hinzugefügt werden. Es ist erwünscht, das Risiko von doppelten Ausgaben in einem POS-System zu verringern.
Figurenliste
Es sollte beachtet werden, dass in den Zeichnungen gleiche Bezugszeichen verwendet werden, um dieselben oder ähnliche Elemente, Merkmale und Strukturen darzustellen. Die Zeichnungen sind nicht notwendigerweise maßstabsgetreu, sondern es wird allgemein der Fokus darauf gelegt, Aspekte der Offenbarung zu veranschaulichen. In der folgenden Beschreibung werden einige Aspekte der Offenbarung unter Bezugnahme auf die folgenden Zeichnungen beschrieben, wobei:

1 eine Art zeigt, einen Angriff mit doppelten Ausgaben durchzuführen;
2 die Zurückweisung eines Angriffs mit doppelten Ausgaben unter Verwendung eines Hardware-Vertrauensankers zeigt;
3 eine Vertrauensanker-Vorrichtung zeigt, die einen oder mehrere Prozessoren umfasst;
4 einen Hardware-Vertrauensanker gemäß einem Aspekt der Offenbarung zeigt, der als Smartcard ausgebildet ist; und
5 zeigt ein Verfahren zur Vertrauensanker-Blockketten-Verifizierung.

Beschreibung
Die folgende genaue Beschreibung bezieht sich auf die beigefügten Zeichnungen, die zur Veranschaulichung spezifische Einzelheiten und Aspekte zeigen, mit denen die Offenbarung praktiziert werden kann. Diese Aspekte werden ausreichend genau beschrieben, um es Fachleuten zu ermöglichen, die Offenbarung zu praktizieren. Andere Aspekte können genutzt werden und strukturelle, logische und elektrische Änderungen können vorgenommen werden, ohne vom Umfang der Offenbarung abzuweichen. Die verschiedenen Aspekte schließen sich nicht unbedingt gegenseitig aus, da einige Aspekte mit einem oder mehreren anderen Aspekten kombiniert werden können, um neue Aspekte zu bilden. Verschiedene Aspekte werden im Zusammenhang mit Verfahren beschrieben und verschiedene Aspekte werden im Zusammenhang mit Vorrichtungen beschrieben. Es versteht sich jedoch, dass Aspekte, die im Zusammenhang mit Verfahren beschrieben wurden, in ähnlicher Weise auf Vorrichtungen angewendet werden können und umgekehrt.
Das Wort „beispielhaft“ wird hier verwendet, um „als Beispiel, Fall oder Veranschaulichung dienend“ zu bedeuten. Jede hierin als „beispielhaft“ beschriebene Ausführungsform oder Ausgestaltung ist nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsformen oder Ausgestaltungen zu interpretieren.
Es ist zu beachten, dass in den Zeichnungen gleiche Bezugszeichen verwendet werden, um dieselben oder ähnliche Elemente, Merkmale und Strukturen darzustellen.
Unter den Begriffen „mindestens ein/e/r“ und „ein/e/r oder mehr“ kann eine numerischer Wert verstanden werden, der größer oder gleich eins ist (z. B. eins, zwei, drei, vier, [...] usw.). Unter dem Begriff „mehrere“ kann ein numerischer Wert verstanden werden, der größer oder gleich zwei ist (z. B. zwei, drei, vier, fünf, [...] usw.).
Der Ausdruck „mindestens eine/r/s von“ in Bezug auf eine Gruppe von Elementen kann hierin verwendet werden, um mindestens ein Element aus der Gruppe, die aus den Elementen besteht, zu bezeichnen. Beispielsweise kann der Ausdruck „mindestens eine/r/s von“ in Bezug auf eine Gruppe von Elementen hierin verwendet werden, um eine der folgenden Auswahlen zu bezeichnen: eines der aufgelisteten Elemente, mehrere von einem der aufgelisteten Elemente, mehrere von einzelnen aufgelisteten Elementen oder mehrere von einer Vielzahl aufgelisteter Elemente.
Die Wörter „eine Vielzahl von“ und „mehrere“ in der Beschreibung und den Ansprüchen beziehen sich ausdrücklich auf eine Menge, die größer als eins ist. Dementsprechend beziehen sich alle Phrasen, die die vorgenannten Wörter (z. B. „mehrere [Objekte]“, „eine Vielzahl von [Objekten]“), die sich auf eine Menge von Objekten beziehen, ausdrücklich verwenden, ausdrücklich auf mehr als eines der genannten Objekte. Die Begriffe „Gruppe (von)“, „Menge [von]“, „Sammlung (von)“, „Serie (von)“, „Sequenz (von)“, „Gruppierung (von)“ usw. und dergleichen in der Beschreibung und in den Ansprüchen beziehen sich, falls vorhanden, auf eine Menge, die größer oder gleich eins ist, d. h. eins oder mehr. Die Begriffe „echte Teilmenge“, „reduzierte Teilmenge“ und „kleinere Teilmenge“ beziehen sich auf eine Teilmenge einer Menge, die nicht gleich der Menge ist, d. h. eine Teilmenge einer Menge, die weniger Elemente als die Menge enthält.
Unter dem Begriff „Daten“, wie er hier verwendet wird, können Informationen in jeder geeigneten analogen oder digitalen Form verstanden werden, z. B. bereitgestellt als Datei, Teil einer Datei, Menge von Dateien, Signal oder Strom, Teil eines Signals oder Stroms, Menge von Signalen oder Strömen und dergleichen. Ferner kann der Begriff „Daten“ auch verwendet werden, um einen Verweis auf Informationen zu bezeichnen, z. B. in Form eines Zeigers. Der Begriff Daten ist jedoch nicht auf die vorgenannten Beispiele beschränkt und kann verschiedene Formen annehmen und beliebige Informationen repräsentieren, wie sie im Stand der Technik verstanden werden.
Der Begriff „Prozessor“ oder „Steuerung“, wie er beispielsweise hierin verwendet wird, kann als eine beliebige Art von Entität verstanden werden, die die Verarbeitung von Daten, Signalen usw. ermöglicht. Die Daten, Signale usw. können gemäß einer oder mehreren spezifischen Funktionen behandelt werden, die von dem Prozessor oder der Steuerung ausgeführt werden.
Ein Prozessor oder eine Steuerung kann somit eine analoge Schaltung, eine digitale Schaltung, eine Mischsignal-Schaltung, eine Logikschaltung, ein Prozessor, ein Mikroprozessor, eine Zentralverarbeitungseinheit (CPU), eine Grafikverarbeitungseinheit (GPU), ein Digitalsignalprozessor (DSP), eine feldprogrammierbare Gatteranordnung (FPGA), eine integrierte Schaltung, eine anwendungsspezifische integrierte Schaltung (ASIC) usw. oder eine beliebige Kombination davon sein oder diese umfassen. Eine beliebige andere Art der Implementierung der jeweiligen Funktionen, die nachstehend ausführlicher beschrieben sind, kann auch als Prozessor, Steuerung oder Logikschaltung verstanden werden. Es versteht sich, dass zwei (oder mehr) der hier beschriebenen Prozessoren, Steuerungen oder Logikschaltungen als eine einzelne Entität mit äquivalenter Funktionalität oder dergleichen realisiert werden können, und umgekehrt, dass jeder einzelne Prozessor, jede einzelne Steuerung oder jede einzelne Logikschaltung, die hierin beschrieben ist, als zwei (oder mehr) getrennte Entitäten mit äquivalenter Funktionalität oder dergleichen realisiert werden kann.
Der hier beschriebene Begriff „System“ (z.B. ein Antriebssystem, ein Positionsdetektionssystem usw.) kann als eine Menge interagierender Elemente verstanden werden, wobei die Elemente beispielhaft und nicht einschränkend eine oder mehrere mechanische Komponenten, eine oder mehrere elektrische Komponenten, ein oder mehrere Befehle (z. B. in Speichermedien codiert), eine oder mehrere Steuerungen usw. sein können
Unter einer „Schaltung“ wird als Anwender hierin jede Art von logikimplementierender Entität verstanden, die Spezialhardware oder einen Prozessor, der Software ausführt, umfassen kann. Eine Schaltung kann somit eine analoge Schaltung, eine digitale Schaltung, eine Mischsignalschaltung, eine Logikschaltung, ein Prozessor, ein Mikroprozessor, eine Zentralverarbeitungseinheit („CPU“), eine Grafikverarbeitungseinheit („GPU“), ein Digitalsignalprozessor („DSP“), eine feldprogrammierbare Gatteranordnung (FPGA), eine integrierte Schaltung, eine anwendungsspezifische integrierte Schaltung (ASIC) usw. oder eine beliebige Kombination davon sein oder diese umfassen. Eine beliebige andere Art der Implementierung der jeweiligen Funktionen, die nachstehend ausführlicher beschrieben sind, kann auch als „Schaltung“ verstanden werden. Es versteht sich, dass zwei (oder mehr) der hier beschriebenen Schaltungen als eine einzelne Schaltung mit im Wesentlichen äquivalenter Funktionalität realisiert werden können, und umgekehrt, dass jede hierin beschriebene einzelne Schaltung als zwei (oder mehr) separate Schaltungen mit im Wesentlichen äquivalenter Funktionalität realisiert werden kann. Zudem können sich Verweise auf eine „Schaltung“ auf zwei oder mehr Schaltungen beziehen, die zusammen eine einzelne Schaltung bilden.
Wie hierin verwendet kann „Speicher“ als ein nicht transitorisches computerlesbares Medium verstanden werden, in dem Daten oder Informationen zum Abrufen gespeichert werden können. Verweise auf „Speicher“, die hierin enthalten sind, können daher als Bezugnahmen auf flüchtigen oder nichtflüchtigen Speicher einschließlich Direktzugriffsspeicher („RAM“), Nur-Lese-Speicher („ROM“), Flash-Speicher, Festkörperspeicher, Magnetband, Festplattenlaufwerk, optisches Laufwerk usw. oder eine beliebige Kombination davon verstanden werden. Darüber hinaus versteht es sich, dass Register, Schieberegister, Prozessorregister, Datenpuffer usw. hier ebenfalls von dem Begriff Speicher abgedeckt werden. Es versteht sich, dass eine einzelne Komponente, die als „Speicher“ oder „ein Speicher“ bezeichnet wird, aus mehr als einem unterschiedlichen Speichertyp bestehen kann und sich somit auf eine kollektive Komponente beziehen kann, die einen oder mehrere Speichertypen umfasst. Es ist leicht zu verstehen, dass jede einzelne Speicherkomponente in mehrere kollektiv äquivalente Speicherkomponenten aufgeteilt werden kann und umgekehrt. Obwohl der Speicher als von einer oder mehreren anderen Komponenten getrennt (wie in den Zeichnungen) dargestellt werden kann, versteht es sich ferner, dass der Speicher in eine andere Komponente integriert sein kann, beispielsweise auf einem gemeinsamen integrierten Chip.
In dem PoW-Kontext ist der Prozess des Verifizierens eines Blocks und des Hinzufügens des verifizierten Blocks zu der Blockkette allgemein als Blockschürfen bekannt, und die Personen, die das Blockschürfen durchführen, werden allgemein als Schürfer bezeichnet. In dem PoS-Kontext kann der Prozess des Verifizierens eines Blocks und des Hinzufügens des Blocks zu der Blockkette manchmal als Schmieden bezeichnet werden und die Personen, die diese Aktivitäten ausführen, können als Schmiede bezeichnet werden. Um die Terminologie zu vereinfachen, wird hier der Begriff „Schürfen“ verwendet, um den Prozess des Verifizierens eines Blocks und des Hinzufügens des verifizierten Blocks zu der Blockkette zu beschreiben, unabhängig vom verwendeten Konsensalgorithmus, ob PoW, PoS oder anderer Art.
Ein Blockketten-Konsensalgorithmus kann so ausgelegt sein, dass ein Hardware-Vertrauensanker für das Blockschürfen erforderlich ist.
Dieser Hardware-Vertrauensanker kann verwendet werden, um Transaktionen zu validieren und somit das Risiko eines erfolgreichen Angriffs mit doppelten Ausgaben zu verringern. Der Hardware-Vertrauensanker kann einen oder mehrere Schlüssel und mindestens eine zuletzt verifizierte Blocknummer speichern.
Der Konsensalgorithmus kann erfordern, dass der Hardware-Vertrauensanker für die Verifizierung von Transaktionen und/oder Blöcken obligatorisch ist. Der Hardware-Vertrauensanker kann ein asymmetrisches Schlüsselpaar aufweisen, das zur Blockverifizierung verwendet wird. Zusammen mit den Blockdaten kann der Schürfer die öffentlichen Schlüsselinformationen des Schürfers zu dem Block hinzufügen. Der Schürfer kann den Block an den Hardware-Vertrauensanker senden und der Hardware-Vertrauensanker kann die Transaktion verifizieren. Nur wenn die Transaktionen ein oder mehrere Sicherheitskriterien erfüllen, verifiziert der Hardware-Vertrauensanker die Daten und gibt sie zur Aufnahme in die Blockkette zurück. Für den Fall, dass der Hardware-Vertrauensanker die Daten verifiziert und zurückgibt, können die Verifizierungsinformationen zu dem Block hinzugefügt werden, der Hash kann berechnet werden und der Block kann der Blockkette hinzugefügt werden.
Gemäß einem Aspekt der Offenbarung kann der Blockketten-Konsensalgorithmus erfordern, dass ein Schürfer einen Hardware-Vertrauensanker besitzt, um eine Transaktion und/oder einen Block zu verifizieren. Durch das Erfordernis des Hardware-Vertrauensankers können potenzielle Schürfer aufgrund beliebiger gewünschter Faktoren oder der Risikobewertung Schürfprivilegien erhalten oder vom Schürfen ausgeschlossen werden.
1 zeigt eine Art und Weise, einen Angriff 100 mit doppelten Ausgaben auszuführen. In dieser Figur werden die Blöcke 150-152 erstellt. Schürfer A nimmt eine Transaktion vor, bei der Schürfer A Währung an Anwender B überweist, wie es im unteren Block 153 aufgezeichnet ist und als Element 102 gezeigt ist. Anwender B erhält eine Benachrichtigung über die Überweisung und kann als Antwort eine Transaktion ausführen, z. B. eine Ware an Schürfer A senden. Zusätzliche Blöcke können basierend auf dem unteren Block 152, dargestellt als Element 102, erstellt werden. Auf diese Weise setzt sich der untere Block 152 in einer Kette fort, die den unteren Block 154 und den unteren Block 155 enthält. Nach dem Aufzeichnen der Überweisung der Gelder an Anwender B kann Schürfer A eine Gabelung in der Kette erstellen, indem ein neuer Block mit einer identischen Blocknummer wie in dem oberen Block 153 erstellt wird, der als Element 104 dargestellt ist. Schürfer A kann eine böswillige Transaktion in dem gegabelten Block aufzeichnen, z. B. die an Schürfer A 104 überwiesene Währung Aufzeichnen. Auf diese Weise wird versucht, doppelte Ausgaben zu tätigen.
Schürfer A möchte möglicherweise, dass der gegabelte Block 104 letztendlich von dem Konsensalgorithmus akzeptiert wird. Eine Strategie zur Erhöhung der Akzeptanzwahrscheinlichkeit besteht darin, die Länge der gegabelten Kette, die mit 104 beginnt, zu erhöhen, da der Konsensalgorithmus so ausgelegt sein kann, dass er die längste Kette akzeptiert. Schürfer A kann mehrere fortlaufende Blöcke mit dem Ziel aufzeichnen, die gegabelte Kette zu verlängern, die sich wie in 104 dargestellt aus dem oberen Block 153 erstreckt. Wenn die längere gegabelte Kette 104 letztendlich akzeptiert wird, wird die Überweisung der Währung an Anwender B nicht aufgezeichnet obwohl Schürfer A möglicherweise bereits den Vorteil aus der nicht aufgezeichneten Überweisung durch den Erhalt der entsprechenden Ware oder Dienstleistung gezogen hat. Da dies das Vertrauen der Anwender in die Blockkette beeinträchtigt, ist dies zu vermeiden.
2 zeigt die Zurückweisung eines Angriffs mit doppelten Ausgaben unter Verwendung eines Hardware-Vertrauensankers. In dieser Figur erfordert der Konsensalgorithmus einen Hardware-Vertrauensanker 202, um Blöcke zu schürfen. Wie hierin beschrieben kann der Hardware-Vertrauensanker von einer ausstellenden Dienststelle nach beliebigen Kriterien an einen potenziellen Schürfer ausgegeben werden. Bei einem Versuch, einen Block zu schürfen, werden bestimmte Blockinformationen, die mindestens die zu schürfende Blocknummer oder Informationen, die die zu schürfende Blocknummer repräsentieren, 108 an den Hardware-Vertrauensanker 202 übertragen. Der Hardware-Vertrauensanker 202 kann einen Speicher zum Speichern mindestens einer zuletzt verifizierten Blocknummer umfassen. Wenn der Hardware-Vertrauensanker 202 eine Blocknummer oder Informationen, die eine zu schürfende Blocknummer 108 repräsentieren, empfängt, vergleicht der Hardware- Vertrauensanker 202 die Blocknummer oder die Informationen, die die Blocknummer repräsentieren, mindestens mit einer Blocknummer des letzten verifizierten Blocks. Für den Fall, dass die zu schürfende Blocknummer weder dupliziert noch früher als die zuletzt gespeicherte Blocknummer ist, und unter anderen Kriterien, die in Bezug auf den Hardware-Vertrauensanker 202 implementiert sind, kann der Hardware-Vertrauensanker 202 den vorgeschlagenen Block verifizieren. Für den Fall, dass der Hardware-Vertrauensanker 202 bestimmt, dass die vorgeschlagene Blocknummer für das Schürfen die gespeicherte Blocknummer des zuletzt verifizierten Blocks dupliziert oder früher als diese ist, kann der Hardware-Vertrauensanker 202 den Block zurückweisen. Beispielsweise erzeugt Schürfer A bei dem oben beschriebenen Doppelausgabenversuch nach Verifizierung des unteren Blocks 153 in Element 112 eine Gabelung mit einem neuen Block 153, wie sie in Element 104 dargestellt ist. Schürfer A versucht, den gegabelten Block 153, Element 104, durch Übertragen mindestens der Blocknummer oder Informationen, die die Blocknummer 110 repräsentieren, an den Hardware-Vertrauensanker 202 zu verifizieren. Der Hardware-Vertrauensanker 202 vergleicht die empfangene Blocknummer oder Informationen, die die Blocknummer repräsentieren, mindestens mit der gespeicherten zuletzt verifizierten Blocknummer. Auf diese Weise bestimmt der Hardware-Vertrauensanker 202, dass der neue Block 153, Element 104, eine duplizierte Blocknummer hat, was angibt, dass eine Gabelung aufgetreten ist. Der Hardware-Vertrauensanker 202 kann eine Zurückweisung 112 des neu gegabelten Blocks 153, Element 104, senden.
Gemäß einem Aspekt der Offenbarung speichert das sichere Element eine Blocknummer mindestens des letzten Blocks, der geschürft wurde. Für den Fall, dass der Hardware-Vertrauensanker einen Versuch detektiert, einen Block mit einer Blocknummer, die einem zuletzt geschürften Block entspricht, oder einer Blocknummer, die vor dem zuletzt geschürften Block liegt, zu schürfen, kann der Hardware-Vertrauensanker die Signierung einer solchen Transaktion verhindern. Auf diese Weise stellt der Hardware-Vertrauensanker sicher, dass ein Schürfer nicht zweimal die gleiche Blocknummer mit demselben Hardware-Vertrauensanker schürfen kann.
Gemäß einem weiteren Aspekt der Offenbarung kann der Hardware-Vertrauensanker auch die Anzahl zurückgewiesener Transaktionen und/oder detektierter Doppelausgabenversuche protokollieren. Der Hardware-Vertrauensanker kann mit einer vorbestimmten Schwelle für diese Anzahl zurückgewiesener Transaktionen und/oder detektierter Doppelausgabenversuche konfiguriert sein. Die vorbestimmte Schwelle kann eine vorbestimmte Anzahl oder eine Anzahl, die auf einer vorbestimmten Formel oder einem vorbestimmten Algorithmus basiert, sein. Wenn der Hardware-Vertrauensanker die vorgegebenen Schwelle erreicht, wird der Hardware-Vertrauensanker möglicherweise blockiert oder deautorisiert, so dass der Hardware- Vertrauensanker keine Schürffunktionen mehr ausführen kann. Alternativ oder zusätzlich kann die ausstellende Dienststelle für den Hardware-Vertrauensanker die Schürfberechtigungen des Schürfers widerrufen, z. B. durch Sperren oder Deaktivieren des Hardware-Vertrauensankers. In diesem Fall kann der Schürfer, der der Besitzer oder Eigentümer des Hardware-Vertrauensankers ist, nicht mehr schürfen.
Gemäß einem weiteren Aspekt der Offenbarung kann der Hardware-Vertrauensanker dazu ausgelegt sein, die Blockverifizierung gemäß einer vorbestimmten Dauer zu verzögern oder nur Blöcke gemäß einem vorbestimmten Zeitplan zu verifizieren. Beispielsweise kann der Hardware-Vertrauensanker dazu ausgelegt sein, die Blockverifizierung bis zu einer vorbestimmten Dauer seit Ablauf der letzten Blockverifizierung zu verbieten. Diese Dauer kann alle n Minuten sein, beispielsweise alle 5 Minuten, alle 10 Minuten oder anderweitig. Diese Dauer kann ohne Einschränkung auf einen beliebigen Zeitraum ausgelegt werden. Durch das Erfordernis, eine vorbestimmte Dauer verstreichen zu lassen, können doppelte Ausgaben weiter verhindert werden, da die resultierende Verzögerung ein schnelles Schürfen fortlaufender Blöcke ausschließt. Bei einem Doppelausgabenangriff führt ein Schürfer eine Gabelung in die Blockkette ein, wobei diese Gabelung häufig eine Transaktion wie etwa eine Überweisung der Währung an den Schürfer oder eine Stornierung einer Zahlung umfasst. Der Schürfer wünscht, dass die gegabelte Reihe von Blöcken in die Blockkette aufgenommen und verifiziert wird. Eine Möglichkeit, die Wahrscheinlichkeit zu erhöhen, dass die gegabelten Reihen von Blöcken akzeptiert und verifiziert werden, besteht darin, mehrere fortlaufende Blöcke zu schürfen, wodurch die Gabel länger als die ursprüngliche Reihe (die nicht gegabelte Reihe) wird. Da Konsensalgorithmen häufig die längste Kette bevorzugen, kann eine Gabelung, die länger als nicht gegabelte Blockreihen gemacht wurde, eine größere Akzeptanzchance haben. Daher kann es wünschenswert sein, die Häufigkeit zu begrenzen, mit der ein Schürfer fortlaufende Blöcke schürfen kann, da diese optionale Implementierung einer vorbestimmten Verzögerung zwischen dem Schürfen die Fähigkeit eines Schürfers, fortlaufende Blöcke schnell zu schürfen, stark einschränkt und somit das Risiko der Akzeptanz einer gegabelten Reihe von Blöcken bei einem Doppelausgabenangriff verringert.
Gemäß einem weiteren Aspekt der Offenbarung kann zusätzliche Sicherheit gegen doppelte Ausgaben erhalten werden, indem verlangt wird, dass der Anteil des Schmieds auf dem Hardware-Vertrauensanker gespeichert wird. Unter der Annahme einer PoS-Implementierung muss der Schmied im Allgemeinen einen Anteil nachweisen, bevor er die Möglichkeit erhält, einen Block zu schürfen. Es wird allgemein angenommen, dass diese Anforderung, einen Anteil zu besitzen, im Vergleich dazu, denjenigen ohne Anteil das Schürfen zu ermöglichen, zusätzliche Sicherheit bietet, da diejenigen mit einem Anteil motiviert sind, das System zu schützen, aus dem sich der Wert ihres Anteils ableitet. Die Sicherheit kann jedoch weiter verbessert werden, indem gefordert wird, dass der Anteil in dem Hardware- Vertrauensanker gespeichert wird. In diesem Fall kann der mutmaßliche Doppelspender dann, wenn ein Doppelausgabenangriff detektiert wird, den Zugriff auf den Anteil verlieren. Es wird angenommen, dass die Gefahr des Verlusts des eigenen Anteils eine stärkere Abschreckung gegen doppelte Ausgaben darstellt als die Gefahr einer potenziellen Wertminderung des Anteils. Eine Mindestanzahl von Münzen oder ein Mindestanteil zum Erhalten des Hardware-Vertrauensankers kann für weitere Abschreckung gegen doppelte Ausgaben angepasst werden. Zum Beispiel kann der Mindestanteil so angepasst werden, dass er hoch ist, wodurch sichergestellt wird, dass diejenigen, die andernfalls die Möglichkeit haben könnten, einen Doppelausgabenangriff zu versuchen, auch am meisten zu verlieren haben, wenn sie nicht erfolgreich sind. Wenn bestimmt wird, dass angesichts des hohen Anteils zu wenige Schürfer für den Hardware-Vertrauensanker qualifiziert sind, kann der Anteil reduziert werden.
3 zeigt eine Vertrauensanker-Vorrichtung, die einen oder mehrere Prozessoren 302 umfasst, die zu Folgendem ausgelegt sind: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer neuesten Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; und in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung erfüllt, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronisches Buchs entsprechen. Der Vergleich der Kandidatenblockkennung mit der gespeicherten Blockkennung kann auf verschiedene Arten durchgeführt werden, beispielsweise durch Vergleichen der Kandidatenblockkennung mit einer neuesten verifizierten Blockkennung, einer größten oder höchsten Blockkennung oder auf andere Weise.
Die Hardware-Vertrauensanker kann als ein nichtflüchtiges computerlesbares Medium ausgebildet sein, das Befehle enthält, die, wenn sie ausgeführt werden, einen oder mehrere Prozessoren dazu veranlassen, die hierin offenbarten Verfahren und/oder Funktionen auszuführen. Diese Befehle können optional Befehle gemäß Java Card sein und als Java-Card-Applet gespeichert sein. Der Hardware-Vertrauensanker kann eine Karte oder Smartcard sein, wobei die Karte oder Smartcard mindestens einen oder mehrere Prozessoren umfasst, die dazu ausgelegt sind, die hierin beschriebenen Verfahren und/oder Funktionen gemäß den befehle auszuführen.
4 zeigt eine solche Smartcard. Die Smartcard kann umfassen: einen Träger 402, der gemäß einer beliebigen gewünschten Form oder Norm bemessen ist; eine optionale Antenne 404, die dazu ausgelegt ist, induktiv oder kapazitiv mit einem Kartenleser zu koppeln; optionale elektrische Kontakte, die dazu ausgelegt sind, eine galvanische Kopplung mit einem Kartenleser herzustellen; und einen oder mehrere Prozessoren 408, die dazu ausgelegt sind, eine Kandidatenblockkennung zu empfangen, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer neuesten Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; und in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung erfüllt, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen.
5 zeigt ein Verfahren zur Vertrauensanker-Blockketten-Verifizierung, das umfasst: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht 502; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen 504; Vergleichen der empfangenen Kandidatenblockkennung mit einer neuesten Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind 506; Nichtverifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist 508; und Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen, in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung erfüllt 510. Die vorbestimmte Bedingung kann umfassen, dass mindestens eine der Kandidatenblockkennungen größer als die eine oder die mehreren verifizierten Blockkennungen, die gespeichert sind, ist, der Kandidatenblock neuer als die eine oder die mehreren verifizierten Blockkennungen, die gespeichert sind, ist und/oder die Kandidatenblockkennung kein Duplikat einer der einen oder der mehreren verifizierten Blockkennungen ist, die gespeichert sind.
Der Hardware-Vertrauensanker kann ein Applet umfassen, das dazu ausgelegt sein kann, ferner ein asymmetrisches Schlüsselpaar zur Blockverifizierung zu speichern. Beispielsweise kann das asymmetrische Schlüsselpaar ein Schlüsselpaar gemäß Rivest-Shamir-Adleman (RSA), Kryptographie mit elliptischen Kurven (ECC) oder einem anderen geeigneten Kryptographiesystem sein.
Der Hardware-Vertrauensanker kann einen großen dauerhaften Nummernzähler umfassen, um eine oder mehrere Blocknummern zu speichern. Der Hardware-Vertrauensanker kann dazu ausgelegt sein, nur eine Blocknummer, die einem zuletzt verifizierten Block entspricht, oder Informationen, die eine Blocknummer repräsentieren, die einem zuletzt verifizierten Block entspricht, zu speichern. Auf diese Weise werden alle Versuche, einen Block mit einer bereits geschürften Blocknummer zu schürfen, zurückgewiesen, da das Schürfen von zwei verschiedenen Blöcken mit einer identischen Blocknummer oder identischen entsprechenden Informationen auf eine Abzweigung in der Blockkette und möglicherweise auf einen Doppelausgabenangriff hinweisen kann. Das heißt, die Gabelung erfordert, dass zwei Blöcke dieselbe Nummer haben, was von dem Hardware-Vertrauensanker nicht zugelassen wird, da die Blocknummern identisch sein müssen, wenn die Kette gegabelt wird. In einem solchen Fall kann die Blocknummer nicht dieselbe sein, da sie bereits nach Verifizierung der Transaktion erhöht worden wäre. Alternativ kann der Hardware-Vertrauensanker dazu ausgelegt sein, mehrere geschürfte Blocknummern zu speichern. Dies kann eine beliebige Anzahl zuvor geschürften Blöcken umfassen, die sich möglicherweise bis zum Beginn der Blockkette erstrecken.
Der Hardware-Vertrauensanker kann einen Zähler umfassen, der dazu ausgelegt ist, eine Blocknummer inkrementieren. Das heißt, der Zähler kann bei jedem verifizierten Block inkrementiert werden, wodurch eine laufende Zählung gepflegt wird, die der Anzahl der verifizierten Blöcke in der Blockkette entspricht. Die Zählernummer kann zur Verwendung bei der Blockverifizierung, wie sie hierin beschrieben ist, auf dem Hardware-Vertrauensanker gespeichert werden.
Gemäß einem weiteren Aspekt der Offenbarung kann der Hardware-Vertrauensanker dazu ausgelegt sein, eine oder mehrere Formen sicherer Codierung zu verwenden, um eine Manipulation der Blocknummer zu verhindern. Auf diese Weise können jegliche identifizierten und nicht autorisierten Versuche, die Blocknummer zu manipulieren, markiert oder auf andere Weise identifiziert werden. Eine solche Manipulation der Blocknummer kann zur Deaktivierung des Blocks führen oder es kann auf andere Weise verhindert werden, dass der Block in die Blockkette aufgenommen wird.
Der Hardware-Vertrauensanker kann gemäß beliebigen Kriterien zum Sichern der Blockketteausgegeben werden. Es ist vorgesehen, dass eine oder mehrere Institutionen, Konsortien oder andere Dienststellen dafür verantwortlich sind, die Hardware-Vertrauensanker an potenziellen Schürfer auszugeben. Dies kann nach beliebigen Kriterien erfolgen. Beispielsweise kann die Dienststelle den Hardware-Vertrauensanker basierend auf dem Anteil des Schürfers an einen Schürfer ausgeben. Die Dienststelle kann berechtigt sein, einen Hardware-Vertrauensanker zu deaktivieren oder zu widerrufen, um die Sicherheit der Blockkette zu erhalten.
Im Folgenden werden verschiedene Beispiele unter Bezugnahme auf die oben beschriebenen Aspekte bereitgestellt.
In Beispiel 1 ist eine Vertrauensanker-Vorrichtung offenbart, die einen oder mehrere Prozessoren umfasst, die zu Folgendem ausgelegt sind: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer größten Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; und in dem Fall, in dem die Kandidatenblockkennung größer ist als die größte Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen.
In Beispiel 2 ist die Vertrauensanker-Vorrichtung von Beispiel 1 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Verifizierung des Kandidatenblocks, der der Kandidatenblockkennung entspricht, zurückzuweisen.
In Beispiel 3 ist die Vertrauensanker-Vorrichtung von Beispiel 1 oder 2 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung größer ist als die größte Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, einen Blocknummernzähler auf eine Kennung, die größer als die Kandidatenblockkennung ist, zu inkrementieren.
In Beispiel 4 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 3 offenbart, wobei die Vertrauensanker-Vorrichtung ferner einen Speicher umfasst, der dazu ausgelegt ist, die eine oder die mehreren verifizierten Blockkennungen zu speichern, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entspricht.
In Beispiel 5 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 3 offenbart, wobei die Vertrauensanker-Vorrichtung ferner einen Speicher umfasst, der dazu ausgelegt ist, eine verifizierte Blockkennung zu speichern, die einer zuletzt verifizierten Blocknummer eines oder mehrerer verifizierter Blöcke entspricht.
In Beispiel 6 ist die Vertrauensanker-Vorrichtung von Beispiel 4 oder 5 offenbart, wobei der Speicher ferner dazu ausgelegt ist, einen öffentlichen Schlüssel, einen privaten Schlüssel oder ein asymmetrisches Schlüsselpaar zu speichern.
In Beispiel 7 ist die Vertrauensanker-Vorrichtung von Beispiel 6 offenbart, wobei der öffentliche Schlüssel, der private Schlüssel oder das asymmetrische Schlüsselpaar ein Rivest-Shamir-Adleman-Schlüssel oder -Schlüsselpaar ist.
In Beispiel 8 ist die Vertrauensanker-Vorrichtung von Beispiel 6 offenbart, wobei der öffentliche Schlüssel, der private Schlüssel oder das asymmetrische Schlüsselpaar ein Schlüssel oder Schlüsselpaar für Kryptografie mit elliptischen Kurven ist.
In Beispiel 9 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 8 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen öffentlichen Authentifizierungsschlüssel in den Kandidatenblock einzufügen, wenn der eine oder die mehreren Prozessoren den Kandidatenblock verifizieren.
In Beispiel 10 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 9 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, eine Blocknummer des verifizierten Blocks in einem Speicher zu speichern.
In Beispiel 11 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 10 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, eine Blocknummer des Kandidatenblocks durch Inkrementieren einer Blocknummer eines zuletzt verifizierten Blocks zu bestimmen.
In Beispiel 12 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 11 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Anwenderkennung zu protokollieren, die einem Anwender entspricht, der den Kandidatenblock zur Verifizierung übermittelt hat.
In Beispiel 13 ist die Vertrauensanker-Vorrichtung von Beispiel 12 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Kandidatenblock nicht zu verifizieren, der der Anwenderkennung entspricht, für die eine vorbestimmte Anzahl von Kandidatenblöcken basierend darauf, dass ihre Kandidatenblockkennung mit einer der einen oder mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, nicht verifiziert wurde.
In Beispiel 14 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 13 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, die Verifizierung eines Kandidatenblocks bis zum Abschluss einer vorbestimmten Zeitdauer zu verzögern.
In Beispiel 15 ist die Vertrauensanker-Vorrichtung von Beispiel 14 offenbart, wobei die vorbestimmte Zeitdauer beispielsweise 5 Minuten beträgt.
In Beispiel 16 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 15 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Anwenderanteil in einem Speicher zu speichern.
In Beispiel 17 ist die Vertrauensanker-Vorrichtung von Beispiel 16 offenbart, wobei der Anwenderanteil ein Anwenderanteil gemäß einem Anteilsnachweis-Algorithmus ist.
In Beispiel 18 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 17 offenbart, wobei das Verifizieren des Kandidatenblocks ein Verifizieren einer Blocksignatur des Kandidatenblocks und ein Signieren des Blocks gemäß einem oder mehreren digitalen Schlüsseln umfasst.
In Beispiel 19 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 18 offenbart, wobei das Verifizieren des Kandidatenblocks ein Verifizieren eines Hash-Werts des Kandidatenblocks durch Neuberechnung des Hash-Werts umfasst.
In Beispiel 20 ist die Vertrauensanker-Vorrichtung nach Beispiel 18 oder 19 offenbart, wobei das Verifizieren des Kandidatenblocks ein Signieren des Blocks gemäß einem oder mehreren digitalen Schlüsseln umfasst.
In Beispiel 21 ist die Vertrauensanker-Vorrichtung nach einem der Beispiele 1 bis 20 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Anwenderanteil zu bestimmen und den bestimmten Anwenderanteil mit einer vorbestimmten Anwenderanteilschwelle zu vergleichen und in dem Fall, in dem der Anwenderanteil kleiner als die vorbestimmte Anwenderanteilschwelle ist, eine Verifizierung des Kandidatenblocks zu deaktivieren.
In Beispiel 22 wird ein Verfahren zur Vertrauensanker-Blockketten-Verifizierung offenbart, das Folgendes umfasst: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer größten Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; Nichtverifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der
mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist; und Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen, in dem Fall, in dem die Kandidatenblockkennung größer ist als die größte Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind.
In Beispiel 23 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach Beispiel 22 offenbart, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Verifizierung des Kandidatenblocks, der der Kandidatenblockkennung entspricht, zurückzuweisen.
In Beispiel 24 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 23 offenbart, das ferner umfasst: in dem Fall, in dem die Kandidatenblockkennung größer ist als die größte Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, Inkrementieren eines Blocknummernzählers auf eine Kennung, die größer als die Kandidatenblockkennung ist.
In Beispiel 25 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 24 offenbart, das ferner ein Speichern der einen oder der mehreren verifizierten Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen, in einem Speicher umfasst.
In Beispiel 26 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 24 offenbart, das ferner ein Speichern einer verifizierten Blockkennung, die einer zuletzt verifizierten Blocknummer einer oder mehrerer verifizierten Blöcke entspricht, in einem Speicher umfasst.
In Beispiel 27 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 25 bis 26 offenbart, das ferner ein Speichern eines öffentlichen Schlüssels, eines privaten Schlüssels oder eines asymmetrischen Schlüsselpaars in dem Speicher umfasst.
In Beispiel 28 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 27 offenbart, wobei der öffentliche Schlüssel, der private Schlüssel oder das asymmetrische Schlüsselpaar ein Rivest-Shamir-Adleman-Schlüssel oder -Schlüsselpaar ist.
In Beispiel 29 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 27 offenbart, wobei der öffentliche Schlüssel, der private Schlüssel oder das asymmetrische Schlüsselpaar ein Schlüssel oder Schlüsselpaar für Kryptografie mit elliptischen Kurven ist.
In Beispiel 30 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 29 offenbart, das ferner ein Einfügen eines öffentlichen Authentifizierungsschlüssels in den Kandidatenblock umfasst, wenn der eine oder die mehreren Prozessoren den Kandidatenblock verifizieren.
In Beispiel 31 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 30 offenbart, das ferner ein Speichern einer Blocknummer des verifizierten Blocks in einem Speicher umfasst.
In Beispiel 32 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 23 bis 31 offenbart, das ferner ein Bestimmen einer Blocknummer des Kandidatenblocks durch Inkrementieren einer Blocknummer eines zuletzt verifizierten Blocks umfasst.
In Beispiel 33 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 32 offenbart, das ferner umfasst: in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Protokollieren einer Anwenderkennung, die einem Anwender entspricht, der den Kandidatenblock zur Verifizierung eingereicht hat.
In Beispiel 34 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 33 offenbart, das ferner ein Deaktivieren einer Verifizierung eines Kandidatenblocks, der der Anwenderkennung entspricht, für die eine vorbestimmte Anzahl von Kandidatenblöcken basierend darauf nicht verifiziert wurde, dass ihre Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, umfasst.
In Beispiel 35 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 34 offenbart, das ferner ein Verzögern einer Verifizierung eines Kandidatenblocks bis zum Abschluss einer vorbestimmten Zeitdauer umfasst.
In Beispiel 36 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 35 offenbart, wobei die vorbestimmte Zeitdauer ungefähr 5 Minuten beträgt.
In Beispiel 37 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 36 offenbart, das ferner ein Speichern eines Anwenderanteils in einem Speicher umfasst.
In Beispiel 38 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 37 offenbart, wobei der Anwenderanteil ein Anwenderanteil gemäß einem Anteilsnachweis-Algorithmus ist.
In Beispiel 39 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 38 offenbart, wobei das Verifizieren des Kandidatenblocks ein Verifizieren einer Blocksignatur des Kandidatenblocks und ein Signieren des Blocks gemäß einem oder mehreren digitalen Schlüsseln umfasst.
In Beispiel 40 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 39 offenbart, wobei das Verifizieren des Kandidatenblocks ein Verifizieren eines Hash-Werts des Kandidatenblocks durch Neuberechnung des Hash-Werts umfasst.
In Beispiel 41 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung von Beispiel 39 oder 40 offenbart, wobei das Verifizieren des Kandidatenblocks ein Signieren des Blocks gemäß einem oder mehreren digitalen Schlüsseln umfasst.
In Beispiel 42 ist das Verfahren zur Vertrauensanker-Blockketten-Verifizierung eines der Beispiele 22 bis 41 offenbart, das ferner ein Bestimmen eines Anwenderanteils und ein Vergleichen des bestimmten Anwenderanteils mit einer vorbestimmten Anwenderanteilschwelle und in dem Fall, in dem der Anwenderanteil unter der vorbestimmten Anwenderanteilschwelle liegt, ein Deaktivieren einer Verifizierung des Kandidatenblocks umfasst.
In Beispiel 43 ist ein nichtflüchtiges computerlesbares Medium offenbart, das dazu ausgelegt ist, einen oder mehrere Prozessoren dazu zu veranlassen, das Verfahren nach einem der Beispiele 22 bis 42 durchzuführen.
In Beispiel 44 ist ein Mittel zur Blockketten-Verifizierung auf Vertrauensanker-Basis offenbart, das Folgendes umfasst: ein oder mehrere Verarbeitungsmittel zum: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Nichtverifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht; und in dem Fall, in dem die Kandidatenblockkennung nicht mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen.
In Beispiel 45 ist eine Vertrauensanker-Vorrichtung offenbart, die Folgendes umfasst: einen oder mehrere Prozessoren, die zu Folgendem ausgelegt sind: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Zurückweisen einer Verifizierung des Kandidatenblocks, der der Kandidatenblockkennung entspricht; und in dem Fall, in dem die Kandidatenblockkennung nicht mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen.
Obwohl die Offenbarung insbesondere unter Bezugnahme auf spezifische Aspekte gezeigt und beschrieben wurde, sollten Fachleute verstehen, dass daran verschiedene Änderungen in Form und Detail vorgenommen werden können, ohne vom Gedanken und Umfang der Offenbarung abzuweichen, wie sie durch die beigefügten Ansprüche definiert ist. Der Umfang der Offenbarung wird somit durch die beigefügten Ansprüche angegeben und alle Änderungen, die in die Bedeutung und den Äquivalenzbereich der Ansprüche fallen, sollen daher beinhaltet sein.

Claims

Vertrauensanker-Vorrichtung, die umfasst: einen oder mehrere Prozessoren, die zu Folgendem ausgelegt sind: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; und in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung erfüllt, Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronisches Buchs entsprechen.
Vertrauensanker-Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Verifizierung des Kandidatenblocks, der der Kandidatenblockkennung entspricht, zurückzuweisen.
Vertrauensanker-Vorrichtung nach Anspruch 1 oder 2, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, die vorbestimmte Bedingung erfüllt, einen Blocknummernzähler auf eine Kennung, die größer ist, zu inkrementieren.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 3, wobei die Vertrauensanker-Vorrichtung ferner einen Speicher umfasst, der dazu ausgelegt ist, eine verifizierte Blockkennung zu speichern, die mindestens einer letzten verifizierten Blocknummer eines oder mehrerer verifizierter Blöcke entspricht.
Vertrauensanker-Vorrichtung nach Anspruch 4, wobei der Speicher ferner dazu ausgelegt ist, einen öffentlichen Schlüssel, einen privaten Schlüssel und/oder ein asymmetrisches Schlüsselpaar zu speichern.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 5, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen öffentlichen Authentifizierungsschlüssel in den Kandidatenblock einzufügen, wenn der eine oder die mehreren Prozessoren den Kandidatenblock verifizieren.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 6, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, eine Blocknummer des Kandidatenblocks durch Inkrementieren einer Blocknummer eines zuletzt verifizierten Blocks zu bestimmen.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 7, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Anwenderkennung zu protokollieren, die einem Anwender entspricht, der den Kandidatenblock zur Verifizierung eingereicht hat.
Vertrauensanker-Vorrichtung nach Anspruch 8, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Kandidatenblock nicht zu verifizieren, der der Anwenderkennung entspricht, für die eine vorbestimmte Anzahl von Kandidatenblöcken basierend darauf, dass ihre Kandidatenbtockkennung mit einer der einen oder mehreren verifizierten Blockkennungen, die gespeichert. sind, identisch ist, nicht verifiziert wurde.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 9, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, die Verifizierung eines Kandidatenblocks bis zum Abschluss einer vorbestimmten Zeitdauer zu verzögern.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 10, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Anwenderanteil in einem Speicher zu speichern.
Vertrauensanker-Vorrichtung nach Anspruch 11, wobei der Anwenderanteil ein Anwenderanteil gemäß einem Anteilsnachweis-Algorithmus ist.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 12, wobei das Verifizieren des Kandidatenblocks ein Verifizieren einer Blocksignatur des Kandidatenblocks und ein Signieren des Blocks gemäß einem oder mehreren digitalen Schlüsseln umfasst.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 13, wobei das Verifizieren des Kandidatenblocks ein Verifizieren eines Hash-Werts des Kandidatenblocks durch Neuberechnung des Hash-Werts umfasst.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 14, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, einen Anwenderanteil zu bestimmen und den bestimmten Anwenderanteil mit einer vorbestimmten Anwenderanteilschwelle zu vergleichen und in dem Fall, in dem der Anwenderanteil kleiner als die vorbestimmte Anwenderanteilschwelle ist eine Verifizierung des Kandidatenblocks zu deaktivieren.
Vertrauensanker-Vorrichtung nach einem der Ansprüche 1 bis 15, wobei die vorbestimmte Bedingung ist, dass mindestens eine der Kandidatenblockkennungen größer ist als die eine oder die mehreren verifizierten Blockkennungen, die gespeichert sind, der Kandidatenblock neuer ist als der eine oder die mehreren verifizierten Blöcke, die gespeichert sind, und/oder die Kandidatenblockkennung kein Duplikat einer der einen oder der mehreren Blockkennungen, die gespeichert sind, ist.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung, das Folgendes umfasst: Empfangen einer Kandidatenblockkennung, die einer Blocknummer eines Kandidatenblocks eines verteilten elektronischen Buchs entspricht; Empfangen einer oder mehrerer verifizierter Blockkennungen, die jeweils einer Blocknummer eines oder mehrerer verifizierter Blöcke entsprechen; Vergleichen der empfangenen Kandidatenblockkennung mit einer Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind; Nichtverifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, in dem Fall, in dem der Vergleich der empfangenen Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, eine vorbestimmte Bedingung nicht erfüllt; und Verifizieren des Kandidatenblocks, der der Kandidatenblockkennung entspricht, und Senden von Daten, die einem verifizierten Block des verteilten elektronischen Buchs entsprechen, in dem Fall, in dem der Vergleich der empfangenen Kandidatenblockkennung mit der Blockkennung unter der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, die vorbestimmte Bedingung erfüllt.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach Anspruch 17, wobei der eine oder die mehreren Prozessoren ferner dazu ausgelegt sind, in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, eine Verifizierung des Kandidatenblocks, der der Kandidatenblockkennung entspricht, zurückzuweisen.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach einem der Ansprüche 17 bis 18, das ferner umfasst: in dem Fall, in dem der Vergleich der Kandidatenblockkennung mit der einen oder den mehreren verifizierten Blockkennungen, die gespeichert sind, die vorbestimmte Bedingung erfüllt, Inkrementieren eines Blocknummernzählers.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach einem der Ansprüche 17 bis 19, das ferner ein Speichern einer verifizierten Blockkennung, die einer zuletzt verifizierten Blocknummer einer oder mehrerer verifizierten Blöcke entspricht, in einem Speicher umfasst.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach einem der Ansprüche 17 bis 20, das ferner umfasst: in dem Fall, in dem die Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, Protokollieren einer Anwenderkennung, die einem Anwender entspricht, der den Kandidatenblock zur Verifizierung eingereicht hat.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach Anspruch 21, das ferner ein Deaktivieren einer Verifizierung eines Kandidatenblocks, der der Anwenderkennung entspricht, für die eine vorbestimmte Anzahl von Kandidatenblöcken basierend darauf nicht verifiziert wurde, dass ihre Kandidatenblockkennung mit einer der einen oder der mehreren verifizierten Blockkennungen, die gespeichert sind, identisch ist, umfasst.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach einem der Ansprüche 17 bis 22, das ferner ein Verzögern einer Verifizierung eines Kandidatenblocks bis zum Abschluss einer vorbestimmten Zeitdauer umfasst.
Verfahren zur Vertrauensanker-Blockketten-Verifizierung nach einem der Ansprüche 17 bis 23, wobei die vorbestimmte Bedingung ist, dass mindestens eine der Kandidatenblockkennungen größer ist als die eine oder die mehreren verifizierten Blockkennungen, die gespeichert sind, der Kandidatenblock neuer ist als der eine oder die mehreren verifizierten Blöcke, die gespeichert sind, und/oder die Kandidatenblockkennung kein Duplikat einer der einen oder der mehreren Blockkennungen, die gespeichert sind, ist.
Nichtflüchtiges computerlesbares Medium, das dazu ausgelegt ist, einen oder mehrere Prozessoren dazu zu veranlassen, das Verfahren nach einem der Ansprüche 17 bis 24 durchzuführen.