Hash-Ketten und Blockverknüpfung

Eine Hash-Kette verknüpft Datenblöcke so, dass jeder Block den Hash des vorherigen Blocks enthält. Wird ein Block verändert, ändert sich sein Hash, wodurch alle nachfolgenden Blöcke ungültig werden. Dadurch entsteht ein manipulationsnachweisbares, nur erweiterbares Ledger.

Jeder Block enthält: (1) Dateninhalt (Transaktionen), (2) Hash des vorherigen Blocks (Verweis auf den vorherigen Block), (3) Zeitstempel, (4) Nonce (für PoW), (5) Merkle-Root der Transaktionen. Der erste Block (Genesis) hat previous_hash = "0"*64.

import hashlib, json class Block: def __init__(self, data, prev_hash): self.data = data self.prev_hash = prev_hash self.hash = hashlib.sha256( json.dumps({'data':data,'prev':prev_hash}).encode() ).hexdigest()

Wenn ein Angreifer die Daten von Block 3 verändert, ändert sich der Hash von Block 3. Block 4 verweist auf den alten Hash von Block 3 – die Kette bricht bei Block 4. Der Angreifer muss die Hashes für die Blöcke 3, 4, 5, ... bis zur Spitze neu berechnen. Mit PoW ist dies rechenpraktisch nicht machbar.

Hash-Ketten liefern für sich genommen einen Manipulationsnachweis, keine Unveränderlichkeit. Ohne zusätzliche Mechanismen (PoW, digitale Signaturen, Verteilung) kann ein Angreifer, der die Kontrolle über die Kette hat, diese umschreiben. Verteilter Konsens macht die Blockchain in der Praxis manipulationsresistent.

Die Regel der längsten Kette von Bitcoin: Die gültige Kette mit dem meisten angesammelten Proof of Work ist maßgeblich. Wenn ein Angreifer die Kette forkt, bauen ehrliche Miner die ehrliche Kette schneller aus (51-%-Annahme). Die Abzweigung des Angreifers ist kürzer und wird verworfen.

Bitcoins SPV-Clients (Simple Payment Verification) laden nur 80-Byte-Blockheader herunter (die vorherigen Hash, Merkle-Root, Nonce, Zeitstempel und Bits enthalten). Full Nodes speichern alle Transaktionen. SPV-Clients verifizieren eine Transaktion anhand eines Merkle-Beweises gegen die Merkle-Root im Header.

Bitcoins Genesis-Block (Block 0, 3. Jan. 2009) hat prev_hash = 0x000...0. Satoshi bettete die Schlagzeile „The Times 03/Jan/2009 Chancellor on brink of second bailout for banks“ als Nachweis des Zeitstempels in die Coinbase-Transaktion ein.

Hash-Ketten gibt es schon vor der Blockchain. Einsatzgebiete: Zertifikats-Sperrlisten (durch Hashes verknüpft), Protokollintegrität (Hash des vorherigen Protokolleintrags), DNSSEC-Vertrauenskette. Das Konzept lässt sich verallgemeinern: jede nur erweiterbare Struktur, in der sich jeder Eintrag auf alle vorherigen Einträge festlegt.

Um die anfängliche Synchronisierung zu beschleunigen, hardcodiert Bitcoin Core Checkpoints: bekannte gültige Block-Hashes bei bestimmten Höhen. Ein Client, der die Synchronisierung startet, kann die PoW-Verifizierung für Blöcke vor dem Checkpoint überspringen und dem hardcodierten Hash vertrauen. Kompromiss: Die Vertrauensminimierung nimmt ab.

Git verwendet dasselbe Prinzip: Jeder Commit wird durch den SHA-1/SHA-256-Hash seines Inhalts + den Hash des übergeordneten Commits identifiziert. Das Auschecken eines bestimmten Commit-Hashes liefert genau diesen Zustand. Die gesamte Historie von Git ist ein per Hash verknüpfter Objektbaum.

Warum muss ein Angreifer nach der Änderung eines Blocks alle nachfolgenden Block-Hashes neu berechnen?

Hash-Ketten verknüpfen Blöcke über kryptografische Zeiger. Änderungen setzen sich bis zu allen nachfolgenden Blöcken fort. In Kombination mit PoW und verteiltem Konsens macht dies die Blockchain in der Praxis unveränderlich. Als Nächstes: Merkle-Bäume für eine effiziente Transaktionsintegrität.