Schritt 16: Schützen des Datenspeichers

Die Macht der Unveränderlichkeit​

Am Ende von Schritt 15 haben wir festgestellt, dass die Blockchain-Datenstruktur Daten veränderungssensitiv speichert. Jede Änderung der in der Blockchain-Datenstruktur gespeicherten Daten wird offensichtlich und muss über einen aufwendigen Prozess in die bestehende Struktur eingepflegt werden. In diesem Schritt wird erläutert, wie dieses Merkmal genutzt werden kann, um die Transaktionsdatenhistorie für die Freigabe und Verteilung in einer nicht vertrauenswürdigen Umgebung vorzubereiten, ohne dass zu befürchten ist, unehrliche Mitglieder eines Peer-to-Peer-Systems könnten deren Inhalt zu ihrem eigenen Vorteil manipulieren.

Die Metapher​

Angenommen, ich möchte mich als Mitglied einer ehrwürdigen Adelsfamilie​ ausgeben. Wie würde ich das tun? Zum Beispiel durch das Fälschen eines Stammbaums. Ich könnte einen adligen Großvater erfinden und in diesem gefälschten Familienstammbaum eine Verbindung zwischen ihm und mir herstellen. Aber überzeugt das andere von meiner (falschen) adligen Herkunft? Dieser Betrug dürfte recht schnell aufgedeckt werden, denn Stammbäume stehen selten für sich allein – sie sind über Verwandtschaftsbeziehungen mit anderen Stammbäumen verbunden und verwoben. Wenn also keiner der Stammbäume der etablierten Adelsfamilien einen Verweis auf oder eine verwandtschaftliche Beziehung mit meinem erfundenen Großvater enthält, ist meine fiktive Familiengeschichte schnell als Betrug entlarvt. Damit meine erfundene Familie anerkannt wird, muss ich auch die Aufzeichnungen einiger der etablierten Adelshäuser fälschen, indem ich Verweise auf meinen ausgedachten Stammbaum in deren Geschichte einfüge. Doch selbst das ist vielleicht noch nicht genug, schließlich leben echte Menschen echte Leben und hinterlassen dabei Spuren in der Weltgeschichte. Mein erfundener Großvater hat allerdings niemals gelebt. Ich muss also einen Lebenslauf für ihn erfinden, damit die Fälschung real erscheint – und zwar für sein gesamtes Leben, von der Kindheit über seine Ausbildung bis zu seinem späteren beruflichen Werdegang. Auch Dokumente, die diesen Lebenslauf belegen, müssen gefälscht werden: Geburtsurkunde, Einschulungsunterlagen, Zeugnisse, Diplome, Ausbildungsbescheinigungen, Meisterbriefe, Mitgliedschaften usw. Schulen, Universitäten und Arbeitgeber haben Unterlagen über die Schüler, Studenten und Mitarbeiter, veröffentlichen Jahrbücher oder Fotografien von gesellschaftlichen Veranstaltungen. Diese Nachweise müsste ich ebenfalls fälschen, damit mein fiktiver Großvater als ehemaliges Mitglied der entsprechenden Einrichtungen durchgeht. Allerdings ist das Manipulieren all dieser Unterlagen nicht nur kompliziert, sondern auch kostspielig, deshalb denke ich, ich würde letztlich doch bei meiner echten, nicht adligen Familiengeschichte bleiben ...

Dieses Gedankenspiel zeigt, dass es zwar möglich ist, die Vergangenheit »zurechtzubiegen«, aber eben auch extrem aufwendig, denn es sind umfassende Änderungen und Fälschungen erforderlich, um die vorzutäuschenden Angaben glaubhaft in die vielen Unterlagen und Querverweise der echten Historie einzubetten. Der hierfür zu betreibende Aufwand ist außerordentlich hoch – im Verhältnis dazu ist es viel einfacher, die Wahrheit zu sagen. In diesem Schritt wird erklärt, inwiefern die Blockchain diese Erkenntnis nutzt, um die Transaktionsdatenhistorie vor Fälschungen zu schützen.

Das Ziel

​Es ist wichtig, dass die gesamte Transaktionsdatenhistorie in der Blockchain stets die Wahrheit abbildet, damit sie als vertrauenswürdige Quelle zum Abklären von Eigentumsangelegenheiten dienen kann.

Die Herausforderung

​Die Blockchain ist ein für alle zugängliches, rein verteiltes Peer-to-Peer-System. Daher besteht die Gefahr, dass unehrliche Peers die Transaktionsdatenhistorie zu ihrem eigenen Vorteil manipulieren oder fälschen. Die Herausforderung besteht in diesem Fall darin, das System für alle zu öffnen und gleichzeitig die Transaktionsdatenhistorie vor Fälschungen und Manipulationen zu schützen.

Die Idee

​In einem offenen verteilten System ist es kaum oder gar nicht möglich, die »ehrlichen Knoten«​ im Vorfeld von den unehrlichen zu unterscheiden. Um die Transaktionshistorie vor Manipulationen durch »unehrliche Knoten«​ zu schützen, können wir radikal jede Manipulation der Historie unterbinden, unabhängig davon, wer Änderungen vornehmen will. Wenn niemand die Transaktionsdatenhistorie ändern kann (ob ehrlich oder unehrlich), müssen wir uns um mögliche Manipulationen keine Gedanken mehr machen. Ist die Transaktionsdatenhistorie also von Anfang an unveränderlich, haben wir das Problem gelöst. Das System kann in der Folge für alle offen bleiben und niemand muss Angst davor haben, dass unehrliche Knoten die Transaktionshistorie manipulieren.

Ein kleiner Abstecher in die Unveränderlichkeit

Unveränderlichkeit​ bedeutet, dass etwas nicht geändert werden kann. Unveränderliche Daten können nach dem Erzeugen oder Schreiben nicht geändert werden. Daher bezeichnet man diese Daten auch als Nur-Lese-Daten​ oder schreibgeschützte Daten. Sie dienen einzig dazu, Informationen ausschließlich zum Lesen oder Darstellen zu liefern – das ist besonders wünschenswert, wenn diese Daten weitergegeben werden und somit keine Kontrolle mehr über ihre weitere Verwendung besteht. Die Weitergabe unveränderlicher Daten ist eine wirkungsvolle Möglichkeit, Änderungen oder Manipulationen an den Dateninhalten zu verhindern. Führerscheine, Ausweispapiere und Zeugnisse sind Beispiele für unveränderliche Dateninhalte im echten Leben. Sie werden von Behörden erstellt, um eine Tatsache zu dokumentieren – und ihr einzig beabsichtigter Zweck besteht darin, vorgezeigt und gelesen zu werden.

Funktionsweise: Das große Ganze

Die Grundidee einer unveränderlichen Transaktionshistorie​ für die Blockchain besteht darin, Änderungen unverhältnismäßig aufwendig zu machen, sodass jegliche Manipulationsbestrebungen bereits im Keim erstickt werden. Eine unveränderliche Transaktionsdatenhistorie besteht aus drei Komponenten:

  1. dem Speichern der Transaktionsdatenhistorie in einer Weise, dass selbst kleinste Manipulationen klar erkennbar und offensichtlich sind,

  2. dem Erfordernis, dass das Einbetten einer Manipulation in die Transaktionshistorie ein Neuschreiben großer Teile derselben erfordert,

  3. dem Konstruieren einer Historie, in der das Hinzufügen, Schreiben oder Neuschreiben von Daten rechenintensiv ist.

Klar erkennbare Manipulationen

​Die Blockchain-Datenstruktur, in der die Daten veränderungssensitiv gespeichert sind, erfüllt die erste Anforderung. Auf diese Weise können Daten, die Teil der Blockchain-Datenstruktur sind, nicht heimlich und in der Hoffnung geändert werden, dass niemand diese Manipulation bemerkt. Jegliche Änderung ist ganz deutlich sichtbar, denn sie zerstört die Hashreferenzen, die infolge von Modifikationen in den Verweiszielen ungültig​ werden.

Erzwungenes Neuschreiben der Historie beim Einbetten von Änderungen

Auch die zweite Anforderung wird von der Blockchain-Datenstruktur erfüllt, denn sie verfolgt bei Änderungen an ihren Daten einen radikalen Alles-oder-nichts-Ansatz​​: Entweder wird die Datenstruktur ab dem Punkt, der die Änderung verursacht, bis zum Kopf der gesamten Kette geändert, oder man sieht von vornherein besser von Änderungen ab.

Rechenintensives Hinzufügen von Daten

Die dritte Anforderung oder Komponente ist für jene gedacht, die sich nicht scheuen, große Teile der Blockchain-Datenstruktur neu zu schreiben, um eine Manipulation in die Transaktionshistorie einzubetten. Denn sobald das Schreiben oder Neuschreiben der Blockchain-Datenstruktur hohen Rechenaufwand​ und dadurch hohe (monetäre) Kosten verursacht, überlegen es sich die meisten zweimal, ob das Ändern überhaupt eine gute Idee war.

Das Blockchain-Technologiepaket​​ stellt einen unveränderlichen Inhalt der Blockchain-Datenstruktur sicher, indem das Schreiben, Neu-Schreiben oder Hinzufügen von Blöcken zur Blockchain-Datenstruktur erheblichen Rechenaufwand fordert. Der Rechenaufwand wird durch Hashpuzzles erzeugt, die für jeden Block-Header eindeutig sind und einzeln gelöst werden müssen.[1] Somit kann man entweder den Gesamtaufwand für eine Änderung der Datenstruktur ab dem Punkt, der die Modifikation verursacht hat, bis zum Kopf der Kette (dem Listenkopf) akzeptieren, indem man für jeden beteiligten Block-Header ein Hashpuzzle löst, oder man unterlässt den Manipulationsversuch von vornherein.

Funktionsweise: Die Details

Das Verfahren zum Anfügen eines neuen Blocks an die Blockchain-Datenstruktur selbst (vgl. Schritt 15) ist nicht rechenintensiv, da nur die Hashreferenz, die auf den aktuellen Listenkopf verweist, zum neuen Block-Header hinzugefügt und ein neuer ​Listenkopf definiert werden muss. Die Herausforderung​ einer unveränderlichen Blockchain-Datenstruktur besteht darin, das Hinzufügen eines neuen Blocks (künstlich) zu einer rechenintensiven Aufgabe zu machen. Zu diesem Zweck müssen die folgenden Aspekte betrachtet werden:

Obligatorische Daten

​​Jeder Block-Header in der Blockchain-Datenstruktur muss mindestens folgende Daten enthalten:[2]

  • Die Wurzel eines Hashbaums, der Transaktionsdaten enthält

  • Eine Hashreferenz auf den Header des vorhergehenden Blocks

  • Den Schwierigkeitsgrad des Hashpuzzles

  • Den Zeitpunkt, zu dem mit der Lösung des Hashpuzzles begonnen wurde

  • Die Nonce, die das Hashpuzzle löst

Verfahren zum Erstellen eine neuen Block-Headers

Das Erstellen​ eines neuen Blocks umfasst die folgenden Schritte:

  1. Erzeugen der Wurzel des Hashbaums, der die einzutragenden Transaktionsdaten enthält

  2. Erzeugen einer Hashreferenz auf den Header​ des Blocks, der zum Vorgänger des neuen Blocks wird

  3. Ermitteln des erforderlichen Schwierigkeitsgrades

  4. Ermitteln der aktuellen Uhrzeit

  5. Erzeugen eines vorläufigen Block-Headers, der die in den Punkten 1 bis 4 aufgeführten Daten enthält

  6. Lösen des Hashpuzzles für den vorläufigen Block-Header

  7. Fertigstellen des neuen Blocks durch Hinzufügen der Nonce, die das Hashpuzzle für den vorläufigen Header löst

Abbildung 16.1 stellt das Hashpuzzle dar, das beim Eintragen eines neuen Blocks in die Blockchain-Datenstruktur gelöst werden muss. Die Grafik zeigt die Daten des Block-Headers, dessen Hashwert die vorgegebenen Beschränkungen bzw. den Schwierigkeitsgrad erfüllen muss. Beachten Sie, dass der Schwierigkeitsgrad Teil des Block-Headers ist und somit auch in den Hashwert des Blocks einfließt. Auf diese Weise ist sichergestellt, dass niemand den Rechenaufwand​ eines Hashpuzzles durch mutwilliges Reduzieren des Schwierigkeitsgrades umgehen kann.

Abb. 16.1: Schematische Darstellung des Hashpuzzles, das beim Eintragen eines neuen Blocks in die Blockchain-Datenstruktur gelöst werden muss

Validierungsregeln

​​​​Jeder Block-Header muss die folgenden Regeln oder Vorschriften erfüllen:

  1. Er muss eine Hashreferenz auf einen vorhergehenden Block enthalten.

  2. Er muss eine gültige Wurzel eines Hashbaums enthalten, der Transaktionsdaten aufweist.

  3. Er muss einen korrekten Schwierigkeitsgrad enthalten.

  4. Sein Zeitstempel muss nach dem Zeitstempel des vorhergehenden Block-Headers liegen.

  5. Er muss eine Nonce enthalten.

  6. Der Hashwert aller fünf kombinierten Datenwerte muss den Schwierigkeitsgrad erfüllen.

Die Validierungsregeln stellen sicher, dass nur solche Blöcke in die Blockchain-Datenstruktur eingetragen werden, für die das Hashpuzzle gelöst und der Rechenaufwand geleistet wurden. Regel 4 stellt sicher, dass die Blöcke und Transaktionsdaten tatsächlich in der Reihenfolge der Zeitpunkte der Eintragungen sortiert sind.

Hinweis

Das Eintragen eines neuen Blocks in die Blockchain-Datenstruktur durch das Lösen eines Hashpuzzles wird auch als Mining oder Block-Mining (vom englischen to mine = schürfen) bezeichnet.

Warum das funktioniert

In der Blockchain-Datenstruktur sind beliebige Änderungen infolge der Zerbrechlichkeit der Hashreferenzen klar erkennbar, denn diese Referenzen werden bei Modifikationen der Verweisziele beschädigt. Das führt dazu, dass alle von einer Manipulation betroffenen Blöcke neu geschrieben werden müssen. Die Hashpuzzles verursachen Kosten für jeden Block, der zum Einbetten einer Manipulation neu geschrieben werden muss. Und die kumulierten Kosten für das Neuschreiben der Blockchain-Datenstruktur beim Einbetten einer Manipulation machen es unvorteilhaft, die Transaktionshistorie überhaupt zu manipulieren. Damit wird die Blockchain-Datenstruktur zu einem unveränderlichen Nur-Hinzufüge-Datenspeicher.

Die Kosten für das Manipulieren der Blockchain-Datenstruktur

​Einmal angenommen, wir möchten einen bestimmten Transaktionsdatenwert manipulieren, der Teil eines Hashbaums ist, dessen Wurzel zu einem Block-Header gehört, der sich wiederum 20 Blöcke vom aktuellen Kopf der Blockchain-Datenstruktur entfernt befindet. In diesem Fall müssen wir die folgenden Arbeiten ausführen, um die manipulierten Transaktionsdaten einzubetten:

  1. Neuschreiben des Hashbaums, zu dem die manipulierte Transaktion gehört

  2. Neuschreiben des Block-Headers, zu dem die Wurzel des neu geschriebenen Hashbaums gehört

  3. Neuschreiben aller nachfolgenden Block-Header bis zum Kopf der Blockchain-Datenstruktur

Für Punkt 2 müssen wir ein Hashpuzzle lösen, denn beim Ändern der Wurzel des Hashbaums ändert sich auch der Hashwert des Block-Headers und somit die Lösung des zugehörigen Hashpuzzles. Für Punkt 3 müssen wir 20 Hashpuzzles lösen, da sich die Hashreferenzen auf die jeweils vorhergehenden Block-Header allesamt ändern. Davon ausgehend, dass wir ein Hashpuzzle im Schnitt in 10 Minuten lösen können, benötigen wir also insgesamt 210 Minuten, um eine Manipulation einer Transaktion einzubetten, die zu einem Block-Header gehört, der 20 Blöcke vom aktuellen Kopf entfernt ist. Diese gewaltigen Kosten halten Knoten davon ab, die Blockchain-Datenstruktur zu ändern.

Der unveränderliche Datenspeicher in der Realität

​Die Unveränderlichkeit der Blockchain-Datenstruktur ist abhängig vom Rechenaufwand​, die durch das Hashpuzzle verursacht werden. Die Schwierigkeit des Hashpuzzles entscheidet, wie groß der Rechenaufwand ist und wie viel Zeit für dessen Lösung benötigt wird – und das wiederum entscheidet über die Unveränderlichkeit der Blockchain-Datenstruktur. Ist der Schwierigkeitsgrad​ zu niedrig, sinken der Rechenaufwand für Änderungen der Blockchain-Datenstruktur und kann in Folge dessen nicht mehr als unverhältnismäßig hoch betrachtet werden, wodurch sich einige Knoten möglicherweise dazu ermuntert fühlen, die Transaktionsdatenhistorie zu manipulieren. Ist der Schwierigkeitsgrad allerdings zu hoch, wird möglicherweise selbst der Rechenaufwand für das Anfügen eines neuen Blocks als unangemessen hoch betrachtet, sodass Knoten davon abgehalten werden, neue Transaktionsdaten hinzuzufügen. Eine der Herausforderungen beim Entwerfen einer Blockchain besteht also darin, das passende Maß für die Schwierigkeit der Hashpuzzles zu finden. Und diese Herausforderung​ wird mit einer entsprechend des technischen Fortschritts veränderten Rechenleistung​ der Computer sogar noch anspruchsvoller. Es kann also erforderlich sein, den Schwierigkeitsgrad dynamisch anzupassen.

Blockchain-Anwendungen in der Realität setzen nur selten auf einen gleichbleibenden Schwierigkeitsgrad für sämtliche Blöcke. Stattdessen wird normalerweise ein dynamischer Schwierigkeitsgrad gew��hlt, der sich danach richtet, wie schnell neue Blöcke hinzugefügt werden. [3] Auf diese Weise ist sichergestellt, dass die für das Lösen der Hashpuzzles erforderliche Zeit so gewählt ist, dass Knoten von Manipulationen der Transaktionsdatenhistorie abgehalten werden, während der tatsächliche Rechenaufwand ansteigt.

Ausblick

Dieser Schritt hat gezeigt, dass die Blockchain Manipulationen oder Fälschungen der Transaktionsdatenhistorie verhindert, indem die Blockchain-Datenstruktur als unveränderlicher Nur-Hinzufüge-Datenspeicher verwendet wird. Der nächste Schritt konzentriert sich darauf, diesen Datenspeicher allen Knoten in einem verteilten Peer-to-Peer-System zugänglich zu machen.

Zusammenfassung

[1] Nakamoto, Satoshi. Bitcoin: A peer-to-peer electronic cash system. 2008. https://bitcoin.org/bitcoin.pdf.

[2] Okupski, Krzysztof. Bitcoin developer reference. Arbeitspapier. 2014.

[3] Okupski, Krzysztof. Bitcoin developer reference. Arbeitspapier. 2014; Wood, Gavin. Ethereum: A secure decentralized generalized transaction ledger. 2014. http://gavwood.com/paper.pdf.