Einführung in die Blockchain

Du hast wahrscheinlich gehört, dass Blockchain als "digitales Geld" oder "die Zukunft des Internets" beschrieben wird. Diese Erklärungen verfehlen den Punkt völlig.

Blockchains sind verteilte Systeme: Netzwerke von Computern, die sich auf gemeinsame Daten einigen müssen, ohne einander zu vertrauen. Dieser Kurs lehrt Blockchain von den Grundprinzipien her: die Probleme verteilter Systeme, die sie löst, wie sie diese löst und warum die Kompromisse wichtig sind.

Beginnen wir damit zu verstehen, warum der Aufbau verteilter Systeme eines der schwierigsten Probleme in der Informatik ist.

Verteilte Systeme

Die meisten Menschen denken, dass die Skalierung von einem Computer auf viele nur "mehr vom Gleichen" ist. Das ist, als würde man denken, dass die Koordination einer Person dasselbe ist wie die Koordination von tausend Personen in verschiedenen Zeitzonen, die möglicherweise nicht immer erreichbar sind.

Wenn du Code auf einem einzelnen Computer schreibst, lebst du in einer vorhersehbaren Welt:

• Operationen sind entweder sofort erfolgreich oder schlagen fehl

• Daten ändern sich nicht mysteriös zwischen den Lesevorgängen

• Die Zeit schreitet konsequent voran

• Wenn du etwas speicherst, wird es tatsächlich gespeichert

Nehmen wir ein einfaches Banksystem. Die Überweisung von 100 $ von Alice an Bob ist in diesem Fall extrem einfach:

def transfer(from_account, to_account, amount):
    if from_account.balance >= amount:
        from_account.balance -= amount
        to_account.balance += amount
        return "Transfer successful"
    return "Insufficient funds"

Das funktioniert perfekt... bis du skalieren musst.

Deine Bank wächst über das hinaus, was ein Computer bewältigen kann, also teilst du die Konten gleichmäßig auf verschiedene Datenbanken auf:

• Server A: Konten 1 bis 1.000.000

• Server B: Konten 1.000.001 bis 2.000.000

• Server C: Konten 2.000.001 bis 3.000.000

Jetzt möchte Alice (auf Server A) 100 $ an Bob (auf Server B) senden. Diese einfache Überweisung wird zu:

def distributed_transfer(alice_server, bob_server, amount):
    # Check Alice's balance on Server A
    if alice_server.get_balance("alice") >= amount:
        alice_server.deduct("alice", amount)    # Step 1
        bob_server.add("bob", amount)           # Step 2
        return "Transfer successful"
    return "Insufficient funds"

Klingt das immer noch einfach? Hier ist, was schief gehen kann:

• Netzwerkpartition: Die Verbindung zwischen Servern bricht direkt nach Schritt 1, aber vor Schritt 2 ab. Alices 100 € verschwinden in der digitalen Leere.

• Serverabsturz: Server B stürzt ab, nachdem er den Befehl "Geld hinzufügen" erhalten hat, aber bevor er die Verarbeitung bestätigt. Hat Bob das Geld bekommen? Niemand weiß es.

• Race Conditions: Zwei Überweisungen von Alice finden gleichzeitig statt. Beide prüfen ihren Kontostand von 100 €, sehen, dass sie über ausreichende Mittel verfügt, und beide werden durchgeführt. Alice hat jetzt 100 € ausgegeben, die sie nicht hatte.

CAP-Theorem

1999 formulierte der Informatiker Eric Brewer das CAP-Theorem, das besagt, dass jedes verteilte System höchstens zwei dieser drei Eigenschaften garantieren kann:

• Konsistenz (C): Alle Server zeigen immer die gleichen Daten an. Wenn sich Alices Kontostand auf Server A ändert, spiegelt jeder andere Server dies sofort wider.

• Verfügbarkeit (A): Das System funktioniert weiter, auch wenn Server abstürzen. Wenn Server A ausfällt, können Benutzer immer noch über Server B und C auf Konten zugreifen.

• Partitionstoleranz (P): Das System überlebt Netzwerkausfälle, die Server in isolierte Gruppen aufteilen.

Wir müssen Partitionstoleranz garantieren, da Netzwerkpartitionen unvermeidlich sind: Kabel werden durchtrennt, Router fallen aus, Rechenzentren verlieren Strom. Das lässt uns nur die Wahl zwischen Konsistenz ODER Verfügbarkeit.

Traditionelle Bankensysteme wählen normalerweise Konsistenz + Partitionstoleranz (CP-Systeme). Sie würden lieber den Betrieb einstellen, als falsche Kontostände anzuzeigen.

Social-Media-Plattformen entscheiden sich oft für Verfügbarkeit + Partitionstoleranz (AP-Systeme). Sie lassen dich lieber posten (auch wenn Freunde es nicht sofort sehen können), als dich komplett am Posten zu hindern.

Das Byzantinische Generäle-Problem

Zusätzlich zum CAP-Theorem gehen die meisten verteilten Systeme davon aus, dass die Teilnehmer ehrlich sind: Sie können ausfallen oder die Verbindung verlieren, aber sie werden sich nicht aktiv gegenseitig täuschen. Diese Annahme bricht zusammen, wenn Teilnehmer böswillig sein können.

Das Byzantinische Generäle-Problem, das 1982 von Informatikern formuliert wurde, veranschaulicht diese Herausforderung:

Du bist ein byzantinischer General, der einen Angriff auf eine befestigte Stadt plant. Du hast mehrere verbündete Generäle, die um die Stadt herum positioniert sind, jeder mit seiner eigenen Armee. Um erfolgreich zu sein, musst du einen gleichzeitigen Angriff koordinieren. Wenn einige angreifen, während andere sich zurückziehen, werden die angreifenden Truppen niedergemetzelt.

Du kommunizierst nur durch Boten, und einige Generäle könnten Verräter sein, die wollen, dass der Angriff scheitert. Verräter können:

• "Angriff"-Nachrichten an einige Generäle und "Rückzug" an andere senden

• Nachrichten von loyalen Generälen verändern, während sie weitergeleitet werden

• Mit anderen Verrätern zusammenarbeiten, um die Verwirrung zu maximieren

Wie erreichst du einen Konsens über "Angriff" oder "Rückzug", wenn du loyale Generäle nicht von Verrätern unterscheiden kannst und den Kommunikationskanälen nicht vertrauen kannst?

Dies schien unmöglich. Jahrzehntelang glaubten Informatiker, dass man kein System bauen könnte, das gleichzeitig:

• Byzantinisch fehlertolerant ist (funktioniert trotz böswilliger Teilnehmer)

• Genehmigungsfrei ist (jeder kann ohne Zustimmung beitreten)

• Dezentralisiert ist (keine zentrale Autorität)

Dann bewies im Jahr 2008 jemand, der sich Satoshi Nakamoto nannte, dass sie falsch lagen.

Bitcoin: die erste Blockchain

Bitcoin war die erste praktische Implementierung der Blockchain-Technologie. Während die einzelnen Komponenten schon vorher existierten (kryptografisches Hashing, digitale Signaturen, Peer-to-Peer-Netzwerke), war Satoshi der erste, der sie kombinierte, um das Double-Spending-Problem für digitale Währungen zu lösen.

Blockchain, oder eine "Kette von Blöcken", wie sie im ursprünglichen Bitcoin Whitepaper genannt wurde, schuf endlich ein System, das gleichzeitig verteilt, byzantinisch fehlertolerant und genehmigungsfrei war.

Der Durchbruch bestand nicht darin, zu identifizieren, wem man vertrauen sollte; es ging darum, das Lügen wirtschaftlich teurer zu machen als die Wahrheit zu sagen. Proof of Work erreicht dies, indem Teilnehmer echte Rechenleistung aufwenden müssen, um Änderungen vorzuschlagen. Ein Angreifer müsste mehr für Strom ausgeben, als er durch einen Angriff gewinnen könnte.