Teil 2: Konsens & Netzwerk — Blockchain, Mining, P2P, BFT
Verteilte Systeme — Vorlesung 5
Prof. Dr. Alexandra Mikityuk · HTW Berlin · Sommersemester 2026
Letzte Woche haben wir die kryptografische Toolbox aufgebaut. Die brauchen wir heute überall.
Mit den Bausteinen können wir einzelne Transaktionen sicher konstruieren — aber wir wissen nicht, wer entscheidet, in welcher Reihenfolge Transaktionen aufgeschrieben werden.
Das löst Teil 2.
Heute setzen wir die Bausteine zusammen — und sehen, wie das Bitcoin-Netzwerk dezentralen Konsens erreicht.
Bitcoin baut auf SHA-256 — überall. Block-Hashes, Merkle-Roots, Adressen. Ohne diese Eigenschaften würde nichts funktionieren.
Gleicher Input → immer gleicher 256-Bit-Output. Modernes CPU schafft 100+ Mio. Hashes/Sekunde.
1 Bit am Input ändern → ca. 50% der Output-Bits ändern sich. Vorhersagbarkeit = 0.
Gegeben ein Hash h — es ist praktisch unmöglich, ein x mit SHA-256(x) = h zu finden.
Es ist praktisch unmöglich, zwei verschiedene Inputs zu finden, die denselben Hash erzeugen.
SHA-256("Hallo Welt") = d6e3...8f2b
SHA-256("Hallo welt") = 9c4a...e1d7 // nur "W" → "w"Komplett anderer Hash. Niemand kann aus dem Hash raten, dass nur ein Buchstaben anders war.
Ein Block ist ein „Bündel" von Transaktionen + Meta-Daten. Etwa alle 10 Minuten entsteht ein neuer.
Block {
prev_hash: Hash des Vorgänger-Blocks // die Verkettung!
merkle_root: Hash aller Transaktionen // kompakte Zusammenfassung
timestamp: 2026-05-10 14:23:01 UTC
difficulty: aktuelle Schwierigkeit
nonce: irgendeine Zahl // dazu gleich mehr (PoW)
transactions: [ Tx1, Tx2, Tx3, ..., Tx2847 ]
}prev_hash-Eintrag verweist auf den vorherigen Block. Daher der Name „Blockchain" — eine Kette.
Der Header ist das, was beim Mining wirklich gehasht wird. Sechs Felder, exakt 80 Bytes — egal wie viele Transaktionen im Block stehen.
| Feld | Größe | Bedeutung |
|---|---|---|
version | 4 B | Protokoll-Version, signalisiert unterstützte Features |
prev_block_hash | 32 B | SHA-256-Hash des vorherigen Block-Headers → die Verkettung |
merkle_root | 32 B | SHA-256-Wurzel aller Transaktionen in diesem Block |
timestamp | 4 B | Unix-Timestamp, gesetzt vom Miner (mit Plausibilitäts-Toleranz) |
bits | 4 B | Komprimiertes Target — definiert die aktuelle Schwierigkeit |
nonce | 4 B | Die freie Variable, die der Miner durchprobiert (32 Bit = ~4 Mrd. Werte) |
merkle_root referenziert. Daher: PoW-Verifikation braucht nur 80 Bytes, nicht den ganzen Block. Das ist die Grundlage für Light Clients (gleich mehr).
Jeder Block enthält den Hash des vorhergehenden. Daraus entsteht eine kryptografisch verkettete Sequenz:
prev_hash im nächsten Block nicht mehr → er muss auch geändert werden. Und der nächste. Und der nächste.
Euer Smartphone-Wallet hat keine 600 GB Blockchain. Wie kann es trotzdem prüfen, ob eine Zahlung an euch in einem Block enthalten ist?
Block runterladen (~ 1-4 MB pro Block) und alle Transaktionen durchsuchen. Bei 895 000 Blöcken → unrealistisch fürs Handy.
Das Wallet braucht nur:
ROOT ← im Block-Header gespeichert
/ \
H(AB) H(CD) ← nur H(CD) bekommt das Wallet
/ \ (Proof)
H(A) H(B) ← nur H(A) wird mitgeschickt
(Proof) ↑
Tx B (meine Transaktion)Das Wallet rechnet selbst: H(B) → mit dem mitgelieferten H(A) kombiniert → H(AB) → mit gelieferten H(CD) → ROOT. Stimmt der ROOT? → Tx B war im Block.
log₂(4096) = 12 Hashes — also ~ 384 Bytes. Eleganter geht's kaum.
Wer darf einen neuen Block hinzufügen? Im Bitcoin-Netzwerk: wer ein mathematisches Rätsel als Erster löst. Schauen wir erst die Bausteine an.
„Nonce" = englisch für „number used once" — eine Zahl, die der Miner einfach frei wählen darf.
Sie hat keine Bedeutung für die Transaktionen im Block. Sie ist nur eine Stellschraube, die der Miner durchprobiert.
Der Block-Hash hängt von allem im Block ab — also auch von der Nonce. Verändert sich die Nonce um 1, ändert sich der Hash komplett (Avalanche-Effekt aus Teil 1).
Ein SHA-256-Hash ist eine 256-Bit-Zahl (64 Hexzeichen). Bitcoin definiert ein Ziel-Maximum — der Block-Hash muss kleiner sein als dieses Maximum.
target = 000000000fffffffffffffffff…
Heißt: der Hash muss mit vielen Nullen anfangen, sonst ist er größer als das Target.
Wer setzt das Target? Niemand zentral — das Protokoll selbst. Startwert von Satoshi 2009, danach passt es jeder Knoten automatisch alle 2.016 Blöcke (~ 2 Wochen) an, damit ein Block im Schnitt 10 Min braucht. Alle Knoten rechnen mit derselben Formel → alle kommen aufs gleiche Target.
while True:
candidate = SHA256(block_inhalt + nonce)
if candidate < target: // Hash klein genug?
return nonce // → wir haben den Block!
nonce = nonce + 1 // nein → nächste Zahl probieren
So sieht das in der Praxis aus — Milliarden Versuche pro Sekunde. Hier vereinfacht für „Hash muss mit 0000 anfangen":
8.472.114" ist nur ein Beispiel. In echt liegt der gefundene Nonce-Wert irgendwo zwischen 0 und 4 Milliarden (32-Bit-Feld) — und manchmal reicht der nicht, dann ändert der Miner andere Felder im Block, um den Suchraum zu erweitern.
Wie viele Versuche braucht man? Bei aktueller Bitcoin-Schwierigkeit (Mai 2026):
| Größe | Wert |
|---|---|
| Versuche pro Block (weltweit) | ~ 6 × 10²³ Hashes |
| Hash-Rate weltweit | ~ 600 EH/s (Exa-Hashes pro Sekunde) |
| Ziel-Block-Zeit | 10 Minuten (im Schnitt) |
| Schwierigkeits-Anpassung | alle 2.016 Blöcke (~ 2 Wochen) |
Werden Blöcke zu schnell gefunden → Schwierigkeit steigt. Zu langsam → fällt. Ziel: konstant 10 Min.
Aktuell 3,125 BTC pro Block + Transaktionsgebühren. Halbiert sich alle ~4 Jahre („Halving") — Inflations-Bremse.
Häufige Frage: „Wer setzt eigentlich fest, wie viele Nullen der Hash haben muss?" — Antwort: das macht das Protokoll selbst, deterministisch, ohne zentrale Instanz.
Satoshi hat 2009 ein Start-Target in den Bitcoin-Code geschrieben (Genesis-Difficulty = 1).
Jeder Knoten der Welt führt dieselbe Software aus — also dieselbe Formel für die Anpassung.
Es gibt keinen zentralen Server, der „das neue Target" verkündet. Jeder Knoten rechnet es selbst aus und kommt zum gleichen Ergebnis.
Alle 2.016 Blöcke (~ 2 Wochen) prüft jeder Knoten:
Ziel: konstante 10 Min/Block, egal ob die weltweite Hash-Rate wächst oder schrumpft.
neues_target = altes_target × (echte_Zeit / soll_Zeit)
↑ ↑
wie lange brauchten 2 Wochen
die letzten 2.016? (Soll-Wert)Wir haben gesagt, das Target passt sich alle 2 016 Blöcke an. Hier ist die Formel — und ein konkreter Schritt.
neues_target = altes_target × (tatsächliche_Zeit / soll_Zeit)
wobei:
soll_Zeit = 2016 × 10 min = 20 160 min = 14 Tage
tatsächliche_Zeit = Zeitspanne der letzten 2016 BlöckeDie letzten 2 016 Blöcke wurden in 12 Tagen gefunden — statt in 14. Miner waren also zu schnell.
Faktor = 12 / 14 ≈ 0,857
neues_target = altes_target × 0,857
= ca. 14% kleiner → Hash muss noch kleiner sein
→ schwieriger, im Schnitt wieder 10 Min/BlockDie Anpassung ist auf maximal 4× (Erleichterung) bzw. 1/4× (Verschärfung) gedeckelt — falls die Hash-Rate extrem springt (Stromausfall in China, Halving-Shock).
Die Formel nutzt 2 015 statt 2 016 Intervalle (klassischer Fencepost-Fehler in Bitcoin Core). Seit 2009 unverändert — würde ein Fix auch nur Mikrosekunden verschieben, hard fork.
Bitcoin hat keinen Server. Alle Knoten sind gleichberechtigt — sie verbinden sich untereinander und tauschen Nachrichten direkt aus.
Speichert die komplette Blockchain (~ 600 GB). Verifiziert jede Transaktion eigenständig. ~ 17.000 weltweit.
Wie ein Full Node + macht aktiv Mining. Heute meist in Mining Pools organisiert.
Wallet auf Handy/PC. Speichert nur Block-Header, fragt Full Nodes nach Bestätigungen. Für Endnutzer.
Jeder Knoten ist mit mehreren anderen verbunden — keine zentrale Schaltstelle.
Wenn ein Miner einen Block findet — wie schnell wissen die anderen 17 000 Knoten weltweit davon?
Miner findet Block.
Schritt 1 — Ankündigung (klein, schnell):
Miner → Nachbarn: INV(hash_des_neuen_blocks) // ~ 40 Bytes
Schritt 2 — Nachbar entscheidet:
Nachbar prüft: kenne ich den Hash schon?
ja → ignorieren
nein → GETDATA(hash) // "schick mir den Block"
Schritt 3 — Block-Übertragung:
Miner → Nachbar: BLOCK(...full data...) // 1-4 MB
Schritt 4 — Validierung + Weitergabe:
Nachbar prüft Block (Hash, PoW, Transaktionen)
→ bei OK: weitergeben an seine eigenen Nachbarn (INV ...)~ 2 Sekunden bis 90% des Netzwerks den Block kennen. ~ 6 Sekunden für 99%. Das sorgt für viele „Beinahe-Forks".
Optimierung: statt den Block voll zu senden, nur eine kurze ID-Liste der Transaktionen. Empfänger rekonstruiert aus dem Mempool.
Was passiert, wenn zwei Miner gleichzeitig einen Block finden? Die Kette gabelt sich kurz — und die Regel lautet: die Kette mit der meisten kumulativen Arbeit gewinnt.
Vor der Gabel: ... → 994 → 995 → 996 → 997
Gleichzeitig finden zwei Miner Block 998:
→ 998a ← Miner A
... → 994 → 995 → 996 → 997 ─┤
→ 998b ← Miner B
Wer als nächstes Block 999 findet, baut auf einer der zwei auf.
Sagen wir, Block 999 baut auf 998b → diese Kette ist jetzt länger.
→ 994 → 995 → 996 → 997 → 998b → 999 (akzeptiert)
└→ 998a (verworfen)Bisher: Forks durch zufällig gleichzeitige Blöcke. Es gibt aber auch absichtliche Forks — wenn die Regeln geändert werden.
Inkompatible Regeländerung. Alte Knoten lehnen neue Blöcke ab.
Konsequenz: wenn nicht alle Knoten upgraden → die Chain spaltet sich in zwei separate Netzwerke.
Beispiele: Bitcoin Cash (2017, größere Blöcke), Ethereum Classic (2016, DAO-Rollback).
Strengere Regeländerung. Alte Knoten akzeptieren die neuen Blöcke weiterhin (verstehen sie nur nicht voll).
Konsequenz: kein Split nötig — die Chain bleibt zusammen, solange die Mehrheit mit-upgradet.
Beispiele: SegWit (2017), Taproot (2021) — beide bei Bitcoin ohne Split.
Wer mehr als 50% der weltweiten Hash-Rate kontrolliert, kann theoretisch:
Aber: alte Blöcke vor seiner Übernahme umzuschreiben — das geht nicht, weil dafür müsste er die kumulative Arbeit aller bisherigen Miner überholen.
Schätzungen: 10-20 Mrd. € Hardware + Millionen €/Tag Strom. Plus: jeder Angriff entwertet Bitcoin selbst → der Angreifer schießt sich ins eigene Bein.
Bitcoin läuft seit Januar 2009 — über 16 Jahre. Kein erfolgreicher 51%-Angriff. Bei kleineren Krypto-Währungen mit weniger Hash-Power: schon vorgekommen.
Bitcoin löst eines der härtesten Probleme der Verteilten Systeme — und tut es seit über 16 Jahren ohne zentrale Autorität.
Mehrere byzantinische Generäle, weit auseinander, müssen sich auf einen gemeinsamen Schlachtplan einigen. Aber: einige sind Verräter und schicken absichtlich falsche Nachrichten. Wie kommen die ehrlichen trotzdem zum Konsens?
PBFT, Raft mit Modifikationen — funktionieren nur, wenn die Anzahl der Knoten klein und bekannt ist (z.B. ein Konsortium).
Erste Lösung für offene Netzwerke mit unbekannten, anonymen Teilnehmern — durch ökonomische Anreize (PoW + Reward) statt purer Algorithmen.
| Metrik | Wert | Vergleich |
|---|---|---|
| Marktkapitalisierung | ~ 2 Bio. USD | = ~ Apple-Aktie |
| Gesamt-Hash-Rate | ~ 600 EH/s | = 600 × 10¹⁸ Hashes/Sek. |
| Stromverbrauch (geschätzt) | ~ 150 TWh/Jahr | = ~ Argentinien |
| Aktive Adressen / Tag | ~ 1 Mio. | |
| Transaktionen / Sekunde | ~ 7 | Visa: ~ 24.000 |
| Full Nodes weltweit | ~ 17.000 | |
| Maximale Coin-Anzahl | 21 Mio. (hardcoded) | ~ 19,7 Mio. existieren bereits |
| Letzter Block (genau jetzt) | ~ 895.000 |
Ehrliche Einordnung — Bitcoin ist nicht die Lösung für alles.
7 TPS sind lächerlich wenig für globale Zahlungen. Visa schafft 24.000. Bitcoin als „Massen-Zahlungsmittel" funktioniert nicht direkt.
150 TWh/Jahr ist real. Sinnvoll nur, wenn Sicherheit der Blockchain wirklich diesen Wert hat — kontroverse Debatte.
10 Min pro Block, 60 Min für „endgültig". Für Online-Käufe zu langsam, für Spar-Transfers OK.
Wir hatten Lightning kurz erwähnt — hier die Idee im Detail. Es löst das Throughput-Problem ohne die Bitcoin-Sicherheit zu opfern.
Zwei Parteien (z.B. Alice und Bob) eröffnen einen Kanal, indem sie einmal on-chain eine gemeinsame Multi-Sig-Adresse füllen — z.B. mit 1 BTC.
1. Open: on-chain 1 BTC in Channel(Alice, Bob) sperren
2. Off-chain Transaktionen (so viele wie sie wollen):
Alice → Bob: Saldo nun (0.8 / 0.2)
Alice → Bob: Saldo nun (0.6 / 0.4)
Bob → Alice: Saldo nun (0.7 / 0.3)
... 1 Million Mal ... // 0 Gebühren, instant
3. Close: on-chain finaler Saldo (0.7 / 0.3) wird publiziertDu musst keinen Kanal zu jeder Person der Welt aufmachen. Lightning routet über bestehende Kanäle: A → B → C → D, jeder Hop in 1 ms.
Wenn Bob betrügen will (alten Saldo on-chain publizieren), kann Alice das in einer Toleranz-Zeit anfechten — sie kassiert alle Kanal-Mittel.
Bitcoin hat ein Rennen um bessere Konsens-Verfahren gestartet. Drei wichtige Ableger:
Ethereum (seit 2022). Statt Rechenarbeit: Miner („Validators") hinterlegen Coin-Pfänder. Wer betrügt, verliert sein Pfand.
Energieverbrauch: ~ 99,95% niedriger als PoW.
Statt linearer Kette: Directed Acyclic Graph (z.B. IOTA, Hedera). Mehrere Transaktionen können parallel bestätigt werden.
Für Konsortien (Banken, Lieferketten): klassische BFT-Algorithmen mit bekannten Knoten. Z.B. Hyperledger Fabric.
Drei Minuten, für euch — schreibt für euch:
Bitcoin selbst werdet ihr nicht nachbauen. Aber ihr könnt mehrere Konzepte daraus in euren Projekten einsetzen:
Versteht ihr, warum dezentrale Systeme schwer sind, könnt ihr in eurem Projekt bessere Architektur-Entscheidungen treffen — auch wenn ihr keine Blockchain baut.
Fragen?
Prof. Dr. Alexandra Mikityuk
HTW Berlin · Büro Raum 308
Tel +49 30 5019-2664
Nächste Woche: Smart Contracts & Konsens im Vergleich