Dies ist ein Artikel über Grundlagen der Blockchain Technologie!
Es geht dabei ausdrücklich nicht um Investment Tips, sondern den Versuch zu verstehen, was an der Blockchain Technologie so anders ist und warum diese in manchen Bereichen sehr nützlich sein kann.
Da das doch ein recht grosses Thema ist, werde ich mehrere Artikel dazu schreiben.
Die Blockchain Technologie ist dezentral und sie ist verteilt (siehe auch Zentrale, dezentrale und verteilte Systeme).
Um so ein dezentrales, verteiltes System besser zu verstehen, müssen wir es zunächst einordnen.
Web 1.0
Im Web 1.0 hat man es normalerweise mit „traditionellen“ zentralisierten Systemen zu tun. Das System Website besteht aus zwei Teilen, dem Browser (Client), der die Seite anzeigt und dem Server, der sie auf Anforderung an den Client liefert.
In der einfachsten Konfiguration ist der Client derjenige, der eine Anforderung zum Erledigen einer Aufgabe („schicke mir die Daten der Website!“) stellt, und ein Server ist derjenige, der sie erledigt („schickt Daten!“). Wenn mehrere dieser Server vorhanden sind, spricht man von einem dezentralen System, da es es viele „Zentralen“ gibt.
So funktioniert das Web 1.0
Web 2.0
Im Web 2.0 geht es mehr um die Kommunikation unter Menschen. Hier wollen zwei Clients miteinander kommunizieren. Auch sie brauchen einen Server „in der Mitte“, der ihre Anfragen jeweils ausführt. Wenn die Messenger App auf dem Smartphone eine Nachricht an ein anderes Smartphone verschickt, wird diese Nachricht zunächst an den Messenger Server übermittelt. Der Messenger Server benachrichtigt die Empfänger App. Schaut sich der Empfänger die Nachricht an, sendet dessen App eine Bestätigung über den Server an die Sende-App.
Beide Varianten funktionieren gut. Die beteiligten Server liegen allerdings ausserhalb der Kontrolle der Clients (Facebook, WhatsApp, Google, gehostete Websites, etc). Hinter einem Server kann sich eine gute oder eine böse Firma befinden. Es könnte auch die Mafia sein, eine NGO oder die Regierung. Der Client kann das nicht unterscheiden und muss sich auf Domain Namen und Zertifikate verlassen um Vertrauen zu einem Server aufzubauen.
Web 3.0
Im Web 3.0 wird nun versucht, diesen „Fehler“ zu beheben. Unter Web 3.0 versteht man Peer-to-Peer-Networking, also die Kommunikation von Client zu Client, ohne einen Server dazwischen. Das Bittorent Protokoll hat eindrucksvoll bewiesen, dass die Kommunikation im Peer-to-Peer-Networking funktioniert. Aus Client und Server wurde eine Entität, die gleichzeitig Client und Server ist. Aus dieser Tatsache ergibt sich aber ein sogleich ein neues Problem. Wie baue ich Vertrauen zum jeweils anderen Peer auf? Auch hier könnte sich ja „jeder“ befinden!
An dieser Stelle beginnt die Blockchain Technologie und an dieser Stelle geht es nun um Herausforderungen, wie byzantinischen Generälen und das CAP-Theorem!
Byzantinische Generäle
Der Legende nach hatten byzantinische Generäle im Jahr 1453 bei der Belagerung von Konstantinopel ein Kommunikationsproblem. Wegen der Stärke Konstantinopels war es notwendig, die Stadt von mehreren Stellen aus gleichzeitig anzugreifen. Die Generäle konnten durch Boten kommunizieren. Es wurde aber vermutet, dass ein paar der Generäle Verräter waren und mit dem Sultan in Konstantinopel zusammenarbeiteten. Eine gemeinsame Absprache über die genaue Uhrzeit des Angriffs war daher schwierig, weil die Verräter falsche Informationen über die Boten verbreiten könnten. Wenn aber nicht gleichzeitig angegriffen wird, kann Konstantinopel nicht erobert werden. Das Problem ist tatsächlich schwer lösbar.
Es gibt eine mathematische Lösung, die funktioniert, solange nicht mehr als ein Drittel der Generäle Verräter sind. Die lasse ich jetzt mal aussen vor.
Eine bessere Lösung, die unabhängig von der Menge der Verräter funktioniert, ist die Blockchain Technologie.
Nehmen wir mal an, der Angriff soll am Mittwoch um 17 Uhr erfolgen. Jeder General kann der Verräter sein. Der Bote transportiert die Nachricht in einem Umschlag, kennt sie aber nicht.
Erfolglose Strategie
General 1 schickt seinen Boten mit einer Nachricht zu General 2. General 2 liest und bestätigt die Nachricht (ok, wir greifen Montag um 17 Uhr an) und schickt ihn weiter zu General 3. General 3 ist der Verräter. Er schreibt einen neuen Zettel mit einer anderen Uhrzeit, ohne dass der Bote das sieht (ok, wir greifen Montag um 19 Uhr an). Alle weiteren Generäle erhalten die falsche Uhrzeit. Der Angriff wird scheitern!
Erfolgreiche Strategie
Jetzt werden Regeln festgelegt.
- Jeder General muss 10 Minuten etwas vorbereiten, damit seine Bestätigung gültig ist
- Jeder General muss die bisher erhaltenen Bestätigungen seiner Bestätigung hinzufügen (Historie)
Wenn unter diesen Bedingungen der Bote von General 1 geschickt wird, so arbeitet General 2 genau 10 Minuten an seiner Bestätigung und fügt sie der erste Nachricht hinzu. Im Umschlag des Boten liegen jetzt zwei Papiere, die sich aufeinander beziehen („verkettet“). Wenn der dritte General nun eine andere Uhrzeit auf seiner Bestätigung schreibt, dauert das zunächst 10 Minuten. Die anderen Nachricht zu fälschen, würde nochmal 10 Minuten dauern. Das würde allerdings der Bote merken, dem gesagt wurde, dass eine Antwort etwa 10 Minuten dauert. Und vor allem würde es der erste General merken wenn der Bote später als erwartet zurück kommt.
Mit dieser Variante wird sichergestellt, dass keiner in der Kette betrügt!
So eine Nachrichtenkette ist vergleichbar mit einer Kette von Informationsblöcken (Blockchain).
Das CAP Theorem
Die Abkürzung CAP steht für Consistency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz).
Das CAP-Theorem besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig die drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz zu garantieren.
Hört sich erstmal kompliziert an, ist aber einfach nachvollziehbar.
Nehmen wir an, ich verkaufe Gebrauchtwagen.
Die Autos stehen auf meinem Hof und ich habe eine Liste aller Fahrzeuge. Wenn ich ein Auto verkaufe, streiche ich es auf der Liste. Mein Geschäft läuft prima und ich eröffne in der benachbarten Stadt ebenfalls einen Gebrauchtwagenhandel. Mein Freund Holger verwaltet den und hat ebenfalls eine Liste. Wir verabreden, alle Autos, die wir an den zwei Standorten haben auf die Liste zu schreiben. Wenn einer von uns ein Auto verkauft, ruft er den anderen an, dass das Auto nicht mehr zur Verfügung steht. Wir haben auch nur eine Telefonnummer, die an beide Telefone weitergeleitet wird. Alles läuft prima!
- Consistent: Wir sind konsistent weil wir unsere Verkaufsliste immer auf einem Stand haben.
- Available: Wir sind immer verfügbar, weil wir unter einer Telefonnummer erreichbar sind. Entweder nimmt Holger ab oder ich. Es ist immer jemand da.
- Partition Tolerance: Wir sind Ausfalltolerant weil das System auch dann funktioniert wenn einer von uns mal krank wird.
Eines Tages passiert etwas und Holger ist sauer auf mich (ich weiss nicht mehr genau was es war). Er hat keine Lust mehr und geht nach Hause, sagt mir aber nichts und sagt mir auch nicht, dass er heute zwei Autos verkauft hat. Wie es der Zufall will, taucht jemand mit Bargeld auf meinem Hof auf und kauft ein Auto, das Holger bereits verkauft hat. Er zahlt bei mir bar (Vorkasse) und macht sich auf den Weg, das Auto von Holgers Hof abzuholen … das Unheil nimmt seinen Lauf!
Das CAP Theorem besagt nun, dass es nicht möglich ist, alle drei Eigenschaften gleichzeitig zu garantieren. Hierzu ein paar Beispiele:
Verfügbar und Ausfalltolerant (AP)
Facebook und Twitter sind immer verfügbar (A) und Ausfalltolerant (P). Sie sind aber nicht konsistent (C). Die Nachrichten, Kommentare, Likes und was es sonst noch so gibt, kommen nicht sofort bei allen Teilnehmern an, sondern verteilen sich so nach und nach im gesamten System.
Cloud Computing und das Domain Name System im Internet fallen auch in diese Kategorie.
Konsistent und verfügbar (CA)
Ein relationales Datenbanksysten soll in erster Line konsistent und wenn irgendwie möglich auch immer verfügbar sein. Ausfalltoleranz ist nicht gegeben.
Konsistent und Ausfalltolerant (CP)
Eine Bank, die Geldautomaten betreibt, muss sicherstellen, dass der beim Automaten abgeholte Betrag zuverlässig beim Konto abgebucht wird. Die Verfügbarkeit ist in diesem Fall nicht so wichtig.
Konsens
Da man in verteilten Systemen eben keine Gleichzeitigkeit der Anforderungen garantieren kann muss man einen Konsens über den „Stand der Dinge“ finden.
Bei den byzantinischen Generälen konnte mit einfachen Regeln dafür gesorgt werden, eine wahre Nachricht von einer gefälschten Nachricht zu unterscheiden. Erreicht wurde dies über den Zwang 10 Minuten lang etwas zu tun. Konsens spielt bei der Blockchain Technologie eine sehr grosse Rolle. Es gibt unterschiedliche Ansätze. Die beiden bekanntesten Ansätze sind der Nachweis einer geleisteten Arbeit (Proof of Work – wie bei den Generälen) und der Nachweis der Beteiligung (Proof of Stake). Hier wird es aber gleich wieder technisch, so dass ich an dieser Stelle erstmal aufhöre.
Links
- Teil 1: Blockchain: Byzantinische Generäle und das CAP Theorem
- Teil 2: Blockchain: Hash Funktionen und Merkle Bäume
- Teil 3: Blockchain: So unterscheiden sich Bitcoin und Ethereum
Schreibe einen Kommentar