-
Die vorliegende Erfindung betrifft ein Verfahren zum Validieren eines neuen Blockes einer Blockkette. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Als dezentrales Transaktionssystem, Transaktionsdatenbank oder verteiltes Hauptbuch (distributed ledger) wird jegliches Protokoll in Rechnernetzen bezeichnet, das eine Übereinkunft (consensus) hinsichtlich der Abfolge bestimmter Transaktionen herbeiführt. Eine häufige Ausprägung eines solchen Systems bedient sich einer Blockkette (blockchain). Hierunter wird in der Kryptologie eine Datenbank verstanden, deren Integrität durch die Speicherung eines Streuwertes (hash) oder digitalen Fingerabdrucks (fingerprint) des vorangehenden Datensatzes im jeweils nachfolgenden Datensatz gesichert wird. Diese kryptografische Verkettung bildet nach dem Stand der Technik die Grundlage vieler Digitalwährungen, darunter Kryptowährungen wie z.B. Bitcoin und digitaler Landes- und Zentralbankwährungen wie z.B. dem digitalen Yuan, kann jedoch auch in anderweitigen verteilten Systemen zur Erhöhung der Transaktionssicherheit beitragen. Das in Blockketten am häufigsten benutzte Konsensverfahren sieht einen Arbeitsnachweis (proof of work, PoW) für die Erzeugung neuer gültiger Blöcke vor.
-
DE102018213301A1 offenbart ein Verfahren zum Einholen eines Arbeitsnachweises in einem Rechnernetz, bei welchem abhängig von der Rechenleistung des Netzes eine Allokationsaufgabe einer mehrdimensionalen Auktion mit vorgegebener Zeitkomplexität gestellt, einem Dienstnutzer im Rechnernetz übertragen und die vom Dienstnutzer gefundene Lösung der Allokationsaufgabe rechnerisch überprüft wird.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Validieren eines neuen Blockes einer Blockkette, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug der erfindungsgemäß aufgebauten Blockkette (im Folgenden: „PoT-Blockchain“) ist darin zu sehen, dass ihr Transaktionsdurchsatz jenen herkömmlicher Blockketten um ein Vielfaches übersteigt. Zudem können die Kosten für eine einzelne Transaktion durch das eingesetzte Konsensverfahren stark gesenkt werden, wobei sämtliche Transaktionen stets öffentlich einsehbar und nachprüfbar bleiben.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass die PoT-Blockchain zur Verwaltung einer Digitalwährung dient, die durch eine zweite, gleichsam als Wirt fungierende Blockkette (im Folgenden: „Host-Blockchain“) abgesichert wird. Die auf diese Weise geschaffene Digitalwährung erweist sich als besonders widerstandsfähig gegen Angriffe durch Mehrfachausgaben (double spending) und gestattet die wirtschaftliche Überweisung selbst von geringeren oder Kleinstbeträgen (micropayment).
-
In Fortsetzung dieses Gedankens wird auch die Nutzung des Verfahrens in Anwendungsfällen abseits des Zahlungsverkehrs, beispielsweise der Eintrag eines Dokumentenhashs in einer PoT-Blockchain mittels einer „Pseudotransaktion“, durch die geringen Kosten begünstigt.
-
Gemäß einem weiteren Aspekt kann eine herkömmliche Blockkette wie Bitcoin, Ethereum oder Bitcoin Cash als Host-Blockchain Anwendung finden. Die bereits vorhandene Infrastruktur derart etablierter Blockketten kann mit nur geringen Anpassungen auch zum Betrieb von PoT-Blockchains herangezogen werden. Zu denken ist etwa an Soft- und Hardware-Wallets, Geldautomaten, mobile Endgeräte wie Smartphones, Fahrzeuge mit Bezahlfunktion oder unterschiedlichste Rechenknoten (nodes). Die laufenden Investitionen für deren Betrieb fallen moderat aus, da jeder Knoten nur eine einzige der PoT-Blockchains zusammen mit der Host-Blockchain speichern muss. Auf diese Weise ließe sich durch wenige tausend PoT-Blockchains der weltweite Zahlungsverkehr abwickeln.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigen:
- 1 beispielhaft einen Zustand einer PoT-Blockchain und einer Host-Blockchain.
- 2 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
- 3 eine beispielhafte Host-Empfangsadressenberechnung für eine Bitcoin-Blockchain.
- 4 bis 7 weitere exemplarische Zustände von PoT- und Host-Blockchains.
- 8 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.
-
Ausführungsformen der Erfindung
-
1 illustriert den grundlegenden Ablauf eines erfindungsgemäßen Verfahrens (10), welcher nunmehr anhand des Anwendungsszenarios gemäß 2 erläutert sei. In letzterer Abbildung ist links die Host-Blockchain mit den Blöcken HB13 bis HB15 und rechts die PoT-Blockchain mit den Blöcken AB8 bis AB10 abgebildet.
-
In einem ersten Schritt (Prozess 11 - 1) wird über den Dateninhalt von Block AB8 der PoT-Hash AH8 gebildet. Daraus wiederum wird in einem zweiten Schritt (Prozess 12 - 1) eine Host-Transaktionsadresse berechnet. Diese wird schließlich in einem dritten Schritt (Prozess 13 - 1) in Block HB13 der Host-Blockchain eingetragen, indem eine minimale Summe an diese Adresse überwiesen wird.
-
3 verdeutlicht eine beispielhafte Host-Empfangsadressenberechnung für eine Bitcoin-Blockchain. Anstelle eines öffentlichen Schlüssels wird der Inhalt eines PoT-Blocks AB gemäß SHA256 und RIPEMD160 auf einen Fingerprint AH abgebildet. Für die Berechnung der Checksumme CS kann dieser Fingerprint anschließend zweimal erneut unter SHA256 abgebildet und 4 Bytes davon als Checksumme CS verwendet werden. Ein Präfix von 0x00, der Hash AH und die Checksumme CS können schließlich gemäß Base58 zu einer Host-Überweisungsadresse umgerechnet werden.
-
Bei der Host-Blockchain können beliebige Teilnehmer (miner) Host-Transaktionen entgegennehmen, zu einem Block zusammenfassen und mit Proof-of-Work zur Blockchain hinzufügen. Mit jeder Transaktion wird ein höherer Betrag von den Sendeadressen abgebucht, als den Empfangsadressen gutgeschrieben wird. Die Differenz erhält der Miner als Vergütung dafür, dass er die Transaktion in den Block aufnimmt. Insbesondere wenn mehr Transaktionen ausgeführt werden sollen, als in einen Block aufgenommen werden können, nehmen die Miner bevorzugt diejenigen Transaktionen auf, bei denen die Differenz am größten ist.
-
In einer der Host-Blockchain entsprechenden Weise können auch seitens der PoT-Blockchain beliebige Teilnehmer als Miner auftreten, die hier allerdings die Differenz von PoT-Transaktionen gutgeschrieben bekommen und davon ihrerseits die Host-Transaktionskosten entrichten.
-
Wie sich unmittelbar erschließt, ist diese Validierung für den PoT-Miner nur dann ein lohnendes Geschäft, wenn die Summe der Differenzen aller PoT-Transaktionen die für die zu deren Absicherung erforderliche Host-Transaktion entstehenden Kosten übersteigt. Bis diese Gewinnschwelle überschritten ist, warten die PoT-Miner ab und „sammeln“ weitere PoT-Transaktionen, bis eine hinreichend große Summe erreicht ist. So kann es dazu kommen, dass in einem oder mehreren aufeinanderfolgenden Host-Blöcken kein PoT-Block eingetragen wird. 4 veranschaulicht ein solches Szenario: Block HB17 enthält hier keine Transaktionsadresse, die einem PoT-Block zugeordnet wäre.
-
Es können auch konkurrierende PoT-Blöcke von mehreren PoT-Minern im gleichen Host-Block eintragen werden. Darum muss definiert sein, welcher der in einem gegebenen Host-Block eingetragenen PoT-Blöcke als gültig zu erachten ist: beispielsweise jener, für den die höchste Host-Transaktionsgebühr bezahlt wurde. Alternativ oder wenn mehrere PoT-Miner die gleiche Host-Transaktionsgebühr bezahlt haben, kann derjenige PoT-Block als gültig betrachtet werden, dessen Host-Transaktionsgebühr von derjenigen Adresse mit dem höchsten Guthaben versendet wurde. Alternativ oder zusätzlich kann auch derjenige PoT-Block als gültig erklärt werden, dessen Varianz zwischen einem Teil der Ziffern der Host-Transaktionsadresse und einem Teil der Ziffern des Hashwerts des Host-Blocks am kleinsten ist. Da der variable Teil des Host-Hashes schwerlich vorhergesagt werden kann, ist auf diesem Wege eine zufällige Priorisierung möglich.
-
Alternativ oder zusätzlich kann derjenigen Host-Transaktionsadresse mit dem geringsten Guthaben die höchste Priorität eingeräumt werden. In diesem Fall kann ein Zufallswert innerhalb des PoT-Blockes iterativ verändert und damit so lange eine neue Host-Transaktionsadresse berechnet werden, bis diese einen besonders kleinen Wert aufweist. Da dieses Vorgehen mit hohem Rechenaufwand verbunden sein kann, wird somit zugleich ein Arbeitsnachweis erbracht. Alternativ oder zusätzlich kann auch derjenige PoT-Block als gültig erklärt werden, dessen Host-Transaktion im Host-Block an vorderster Stelle vermerkt ist. Für den Fall, dass einer der PoT-Blöcke nicht allen Teilnehmern bekannt ist, wird außerdem der Hash des vorhergehenden PoT-Blocks in den aktuellen PoT-Block mit aufgenommen. Dadurch haben alle Teilnehmer ein übereinstimmendes Verständnis davon, welche der konkurrierenden PoT-Blöcke zu einem Strang gehören.
-
Im Szenario gemäß 5 beispielsweise sind sowohl Block AB9 als auch Block BB9 im Host-Block HB14 eingetragen. Block AB9 kommt gemäß dem verwendeten Protokoll der Vorrang zu, weshalb er vom „nachfolgenden“ Block AB10 referenziert wird.
-
Wie auch in herkömmlichen Blockketten könnte ein Angreifer versuchen, zwei unterschiedliche PoT-Blöcke oder Blockstränge zu schaffen und sein Guthaben in jedem der beiden Stränge unabhängig voneinander auszugeben. Dazu müsste den Opfern der jeweils andere Strang verborgen bleiben, was generell ein ernstzunehmendes Angriffsszenario für Blockchains darstellt. 6 beleuchtet einen derartigen Angriff anhand des Versuchs, mit den PoT-Blöcken BB9 und BB10 einen parallelen Strang zu den Blöcken AB9 und AB10 aufzubauen. Aus Sicht eines potenziellen Opfers könnte in der dargestellten Konfiguration prinzipiell jede der in den Blöcken HB14 und HB15 markierten Host-Transaktionen gültig erscheinen.
-
Dieses Problem kann gelöst werden, indem die Host-Transaktionsadresse, die einem PoT-Block zugeordnet ist, mit einer für alle PoT-Blöcke einheitlichen Zeichenfolge beginnt, wobei die Zeichenfolge so lange gewählt wird, dass es sehr unwahrscheinlich ist, dass diese Zeichenfolge zufällig in Überweisungsadressen der Host-Blöcke auftritt. Die einheitliche Zeichenfolge kann z. B. die ersten Bytes des Fingerprints (AH - 3) ersetzen, was allerdings den Schutz vor einer Manipulation der PoT-Blöcke schwächt. Aus diesem Grund kann der Fingerprint aufgeteilt und zusammen mit der einheitlichen Zeichenfolge in zwei Empfangsadressen eingefügt werden. Idealerweise wird an beide Empfangsadresse innerhalb einer Transaktion der kleinstmögliche Betrag überwiesen. Alternativ oder zusätzlich kann die einheitliche Zeichenfolge auch der Empfangsadresse für das Restguthaben zugewiesen werden, die ebenso Teil der Transaktion ist. Dies wiederum kann gelingen, indem so lange zufällige neue Empfangsadressen basierend auf einem oder unterschiedlichen geheimen Schlüsseln generiert werden, bis die gewünschte einheitliche Zeichenfolge in der Adresse resultiert. Die zuvor beschriebene Gültigkeitsprüfung konkurrierender Blöcke kann dadurch auf Basis der Informationen des Host-Blocks durchgeführt werden, ohne dass den Teilnehmern alle zugeordneten konkurrierenden PoT-Blöcke bekannt sein müssen. Lediglich derjenige Block, der die vorgenannten Gültigkeitskriterien erfüllt, muss bekannt sein.
-
Es mag vorkommen, dass zwar der Hash eines PoT-Blockes durch eine Host-Transaktion in der Host-Blockchain eingetragen und als vorrangig behandelt wird, dass aber der PoT-Block nicht von allen Teilnehmern empfangen werden kann. Diejenigen Teilnehmer, die diesen Block nicht empfangen haben, setzen den Strang mit dem PoT-Block der zweithöchsten Priorität fort. Es entstehen dadurch zwei Stränge, sodass es zu verhindern gilt, dass ein Angreifer heimlich einen zweiten „Billig-Strang“ mit zunächst nachrangigen Blöcken aufbauen und diesen Strang durch einen nachfolgenden vorrangigen Block als gültig erscheinen lassen kann.
-
Vor dem Hintergrund dieser Gefahr können zur Priorisierung der Blöcke auch die Prioritäten aller Blöcke eines Strangs summiert werden. Bei der Priorisierung von Strängen ist es außerdem von Vorteil, Lücken im Strang (vergleiche 4) mit einer besonders niedrigen Priorität gleichsam zu bestrafen. So mag es günstig sein, keine Parallelstränge mit mehr als sechs aufeinanderfolgenden Lücken zuzulassen. Sind einem Teilnehmer alle konkurrierenden PoT-Blöcke der letzten sechs Host-Blöcke bekannt, so könnten die davor getätigten Transaktionen beispielsweise als gültig bestätigt werden.
-
Wie 7 erkennen lässt, können mehrere PoT-Blockchains parallel mit derselben Host-Blockchain abgesichert werden. In den Blöcken HB13, HB14 und HB15 der mittig abgebildeten Host-Blockchain beispielsweise sind die Blöcke AB34, AB35 bzw. AB36 der abbildungsgemäß linken PoT-Blockchain sowie die Blöcke BB8, BB9 bzw. BB10 der abbildungsgemäß rechten PoT-Blockchain eingetragen.
-
Wenn alle Host-Transaktionen nach diesem Schema für die Absicherung von PoT-Blöcken verwendet werden, lassen sich mit jedem Host-Block ca. 2.500 PoT-Blöcke abzusichern. Dadurch können mit rund 360.000 Host-Transaktionen rund 2.500-mal mehr PoT-Transaktionen und somit in Summe 900.000.000 PoT-Transaktionen pro Tag abgewickelt werden.
-
Zur weiteren Verbesserung der Skalierbarkeit kann auch eine PoT-Blockchain ihrerseits als Host-Blockchain zum Einsatz kommen. Auf diesem Wege lassen sich die Überweisungskosten erneut drastisch reduzieren und die Anzahl der möglichen Blockchains nochmals deutlich erhöhen.
-
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (20) implementiert sein, wie die schematische Darstellung der 8 verdeutlicht.
-
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
-
- DE 102018213301 A1 [0003]
