Wie Blockchains einen Konsens erreichen · Lektion 2 von 5
Blöcke, Hashes und die Blockchain
7 Min. Lesezeit
Von einzelnen Transaktionen zu Blöcken
Eine Blockchain verlangt normalerweise nicht von jedem Knoten, jeder Transaktion als völlig separatem, dauerhaftem Datensatz zuzustimmen. Stattdessen werden Transaktionen in sogenannten Blöcken zusammengefasst. Regeln legen fest, wie Blöcke vorgeschlagen, geprüft und miteinander verbunden werden. Ein Block ist nicht einfach eine Seite in einem elektronischen Hauptbuch. Er ist eine protokolldefinierte Datenstruktur, die Transaktionen enthält oder sich auf sie bezieht und Informationen mitführt, die den Block mit der vorangegangenen Historie verknüpfen. Die konkreten Felder unterscheiden sich je nach System. Manche Protokolle trennen Ausführungsdaten und Konsensdaten; andere verwenden einen vergleichsweise kompakten Block-Header, auf den die Transaktionen folgen.
Um die Blockchain zu verstehen, sollte man zwischen Transaktionsinhalt, einer zusammenfassenden Festlegung und einem Verweis auf die frühere Historie unterscheiden. Eine Transaktion beschreibt eine angeforderte Änderung des Ledger-Zustands. Ein kryptografischer Hash ist ein Ausgabewert fester Länge, der anhand eines definierten Algorithmus aus Eingabedaten erzeugt wird. Ein Block kann einen Hash oder eine ähnliche Festlegung auf die Transaktionsmenge enthalten; sein Header verweist im Allgemeinen mithilfe eines Hashes auf einen Vorgänger. Werden Datensätze auf diese Weise verknüpft, lässt sich eine nicht angekündigte Änderung mit überwältigender Wahrscheinlichkeit erkennen, da veränderte Daten die betreffende Festlegung ändern – unter den Sicherheitsannahmen der Hashfunktion.
Was ein kryptografischer Hash bewirkt
Eine kryptografische Hashfunktion wandelt Informationen beliebiger Länge in einen Digest fester Größe um. SHA-256 erzeugt beispielsweise einen 256-Bit-Digest. SHA-256 ist in FIPS 180-4, Secure Hash Standard, des National Institute of Standards and Technology spezifiziert. Der Digest ist keine Verschlüsselung: Er enthält kein Geheimnis, das entschlüsselt werden könnte, um die ursprüngliche Eingabe wiederherzustellen. Ein Hash bestätigt auch nicht, wer ein Dokument erstellt hat. Er eignet sich zum Vergleichen von Informationen und zum Erkennen von Änderungen, sofern er korrekt implementiert wird und ein geeigneter Algorithmus verwendet wird. Verschiedene Blockchains nutzen speziellere Algorithmen und Kombinationen.
Eine gute kryptografische Hashfunktion ist so ausgelegt, dass es rechnerisch nicht praktikabel ist, eine andere Nachricht zu finden, die denselben Digest erzeugt, oder vom Digest rückwärts auf eine ausgewählte ursprüngliche Nachricht zu schließen. Dies sind Sicherheitseigenschaften, keine absoluten mathematischen Unmöglichkeiten. Ändert sich die Eingabe auch nur geringfügig, sieht ihr Digest normalerweise völlig anders aus. Ein Knoten, der die korrekte Festlegung kennt, kann daher erkennen, wenn der Inhalt eines Blocks ersetzt oder bearbeitet wurde. Diese Erkennung identifiziert für sich genommen weder die für die Änderung verantwortliche Person noch beweist sie, dass der ursprüngliche Inhalt korrekt war.
Ein Hash-Verweis ist mehr als ein gewöhnlicher Link
Ein herkömmlicher Datenbankverweis gibt an, wo ein anderer Datensatz zu finden ist. Ein Hash-Verweis kombiniert den Verweis auf einen vorherigen Datensatz mit einem Wert, der dessen erwarteten Inhalt festlegt. Betrachten wir die Blöcke A, B und C. Block B enthält einen Hash-Verweis auf A; C verweist auf B. Bearbeitet jemand A, stimmt der von B erwartete Digest nicht mehr überein. Wird der Verweis in B korrigiert, ändert sich B, wodurch wiederum der Verweis in C ungültig wird. Diese Abhängigkeit setzt sich über nachfolgende Blöcke fort. In realen Protokollen muss ein Angreifer, der akzeptierte Historie ersetzen möchte, auch die geltenden Konsensregeln erfüllen und nicht nur die Hashes neu berechnen.
Header, Inhalte und Transaktionsfestlegungen
Viele Blockdesigns haben einen Header mit kompakten Metadaten und einen Inhaltsteil mit Transaktionen oder anderen Ausführungsinformationen. Bei Bitcoin umfasst der Header einen Hash des vorherigen Blocks, eine Merkle-Wurzel als Zusammenfassung der Transaktionen, einen Zeitstempel, eine Kodierung des Schwierigkeitsziels, eine Version und eine Nonce. Eine Nonce ist ein Feld, dessen Wert während der Suche nach einem gültigen Arbeitsnachweis variiert werden kann. Diese Feldliste ist ein Beispiel und keine universelle Anforderung an Blockchains. Moderne Systeme können andere Festlegungsbäume, Signaturen, Validator-Bestätigungen oder separate Nutzdatenstrukturen verwenden.
Ein Merkle-Baum fasst eine Sammlung von Datensätzen mithilfe einer Hierarchie von Hashes zusammen. Blattwerte legen einzelne Elemente fest; Zwischenwerte legen Kombinationen von Elementen fest; der oberste Wert wird Merkle-Wurzel genannt. Diese Struktur kann einen Inklusionsnachweis ermöglichen: eine kompakte Menge von Hashes, die belegt, dass ein bestimmtes Element zu der durch die Wurzel festgelegten Sammlung gehört. Inklusionsnachweise helfen, die für bestimmte Prüfungen benötigte Datenmenge zu verringern. Sie ersetzen jedoch nicht alle Prüfungen eines vollständigen Knotens, etwa die Prüfung, ob die Transaktion autorisiert wurde und ob eine widersprüchliche Ausgabe vorliegt.
Reihenfolge und Serialisierung sind Protokollregeln
Ein Knoten kann nicht eine vage Beschreibung wie „Alice hat Bob bezahlt“ hashen. Er muss eine präzise Bytefolge in einem festgelegten Format hashen. Das nennt man Serialisierung: die Darstellung strukturierter Informationen als Bytes gemäß veröffentlichten Regeln. Feldreihenfolge, Zahlencodierung und weitere Details sind wichtig. Serialisieren zwei Knoten denselben konzeptionellen Datensatz unterschiedlich, können sich ihre Hashes unterscheiden. Konsens hängt daher von mehr als starker Kryptografie ab; erforderlich sind auch deterministische Definitionen gültiger Kodierungen, gegebenenfalls der Transaktionsreihenfolge, der Blockgrenzen und der Zustandsänderungen, die jede Transaktion bewirkt.
Manipulationsnachweis versus Unveränderlichkeit
Blockchains werden häufig als unveränderlich beschrieben. In einem Einführungskurs sind „manipulationsnachweisbar“ und „manipulationsresistent“ präzisere Begriffe. Hash-Verknüpfungen machen unbefugte Änderungen an einer aufgezeichneten Blockchain sichtbar, während Konsensmechanismen die Ersetzung akzeptierter Historie unter den genannten Annahmen erschweren. Keine dieser Eigenschaften macht es metaphysisch unmöglich, die Historie zu ändern. Forks, Reorganisationen, Protokoll-Upgrades und das Versagen von Sicherheitsannahmen eines Netzwerks können sich darauf auswirken, welche Blockchain akzeptiert wird. Auch bei rechtlichen Aufzeichnungen können Änderungen erforderlich sein; ein System kann frühere Einträge bewahren und Korrektureinträge hinzufügen, ohne sie heimlich zu überschreiben.
Eine wichtige Designfrage ist, was on-chain gespeichert wird. Wird eine Hash-Festlegung für ein Off-Chain-Dokument gespeichert, können Prüfende später überprüfen, ob dasselbe Dokument vorgelegt wurde. Das bedeutet nicht, dass das Dokument selbst auf der Blockchain verfügbar ist. Ein Hash allein liefert möglicherweise auch keinen rechtlich ausreichenden Nachweis für Urheberschaft, Identität oder Einwilligung. Bei Anwendungen im öffentlichen Sektor können Aufbewahrungspflichten, sensible Daten und die Verfügbarkeit von Quelldatensätzen wichtiger sein als die Eleganz der Festlegungsstruktur. Hashes sind wertvolle Bausteine, aber das Records Management von Institutionen erfordert zusätzliche Kontrollen.
Wie Knoten einen vorgeschlagenen Block prüfen
Ein Knoten, der einen vorgeschlagenen Block empfängt, führt im Allgemeinen mehrere Prüfschritte aus. Er bewertet die grundlegende Datenstruktur und Kodierung, prüft den Vorgängerverweis, verifiziert das Vorhandensein der erforderlichen Konsensnachweise und prüft Transaktionen anhand der Zustandsübergangsregeln des Protokolls. In einem Netzwerk mit Proof of Work prüft er außerdem den Arbeitsnachweis des Headers anhand eines Zielwerts. In einem Proof-of-Stake-Netzwerk kann er die Berechtigung des Blockvorschlagenden sowie relevante Stimmen oder Bestätigungen prüfen. Diese Vorgänge sind in jedem Protokoll genau spezifiziert; ein scheinbar gültiger Hash allein reicht niemals aus, um einen Block als akzeptabel einzustufen.
Die Vorgängeranforderung erklärt auch, warum das Herunterladen eines isolierten Blocks nicht gleichbedeutend damit ist, einen vertrauenswürdigen Ledger-Zustand festzustellen. Die Validierung beruht auf Kontext: vorangegangenen Regeln, Kontoständen oder nicht ausgegebenen Outputs sowie der vom Netzwerk ausgewählten Blockchain. Ein Light Client kann Inklusionsnachweise erhalten, ohne alle Transaktionen selbst auszuführen; diese Vereinfachung kann mit anderen Vertrauensannahmen verbunden sein. Manager und Auditoren sollten die Aussage „Diese Transaktion erschien in einem Block“ von der Aussage „Eine vollständig validierte Netzwerkhistorie akzeptiert diese Übertragung“ unterscheiden. Letztere erfordert zusätzlichen Kontext und eine definierte Bestätigungspolitik.
Governance- und Offenlegungskontext
Die technische Struktur ist ein Teil einer umfassenderen Systemdokumentation. ISO 23257:2022 beschreibt funktionale Komponenten und Beziehungen für Distributed-Ledger-Systeme. Offenlegungsvorschriften in einigen Rechtsordnungen (zum Beispiel die Anforderungen der EU an Krypto-Asset-Whitepaper) verlangen von Emittenten, die zugrunde liegende Technologie zu beschreiben. Solche Pflichten schreiben jedoch keine universelle Blockstruktur vor und machen auch keinen bestimmten Hash-Algorithmus sicher. Dies veranschaulicht, weshalb eine technische Beschreibung und eine rechtliche Offenlegung unterschiedliche Fragen beantworten: Erstere erklärt, wie ein Protokoll funktioniert; Letztere legt fest, welche Informationen in einem regulierten Kontext mitgeteilt werden müssen.
Kurzübersicht
| Komponente | Hauptzweck |
|---|---|
| Transaktion | Beschreibt eine angeforderte Zustandsänderung |
| Hash- oder Wurzelfestlegung | Erkennt Änderungen an festgelegten Daten |
| Verweis auf den vorherigen Block | Verknüpft einen Block mit der früheren Historie |
| Konsensnachweis | Unterstützt die Akzeptanz gemäß den Protokollregeln |
Was Lernende mitnehmen sollten
Blöcke sind strukturierte Zusammenfassungen oder Festlegungen, die Protokollregeln unterliegen. Kryptografische Hashes erzeugen kompakte Fingerabdrücke und verknüpfen abhängige Historie; sie erkennen Änderungen, stellen aber weder Identität noch sachliche Wahrheit fest. Starke Hashfunktionen, deterministische Serialisierung, vollständige Validierung und ein Konsensmechanismus wirken zusammen. In der nächsten Lektion geht es um eine Methode, mit der ein Netzwerk die Änderung der akzeptierten Blockchain kostspielig macht: Proof of Work. Schlüssel und digitale Signaturen werden separat in Modul 3 behandelt.
Prüfungsschwerpunkt: Bestimmen Sie die Funktionen eines Block-Headers, eines kryptografischen Hashes, eines Vorgängerverweises und einer Transaktionsfestlegung; erklären Sie, weshalb Hash-Verknüpfungen Manipulationsnachweise und keine bedingungslose Unveränderlichkeit bieten.
Quellenhinweise
Relevante Quellen: NIST FIPS 180-4 (2015), Secure Hash Standard; NIST IR 8202 (2018), Blockchain Technology Overview; ISO 23257:2022, Referenzarchitektur.
Übungsfragen
Prüfen Sie Ihr Verständnis. Diese Fragen zählen nicht für die Prüfung.
Melden Sie sich an, um Ihren Fortschritt zu speichern und später weiterzumachen. Kostenlos. Anmelden