“Wir haben ausgerechnet, was passiert, wenn wir immer größere Blöcke haben. Ab einem bestimmten Wert kommt es zu Problemen.”

Christian Decker ist wohl der erste Wissenschaftler weltweit, der eine Doktorarbeit über Bitcoin geschrieben hat. Sein Thema ist die Skalierbarkeit. Im Interview erklärt er, welche Flaschenhälse es gibt und wie man die Bitcoin-Blockchain dennoch skalieren kann.

Es gibt Fälle, in denen sich ein Hobby bezahlt macht. Etwa bei Christian Decker. Der Schweizer hat schon vor einigen Jahren begonnen, sich mit Bitcoin auseinanderzusetzen. Während seines Masters in “Verteiltes Rechnen” an der ETH Zürich hat er sich mit Konsensprotokollen beschäftigt, ist auf den Bitcoin gestoßen und hat schon 2009 mit Mining begonnen. Das hat ihm eine Stange Bitcoins eingebracht, die bis heute anhält.

Wertvoller ist für ihn aber, dass er sich schon sehr früh wissenschaftlich mit Bitcoin auseinandergesetzt hat. Nun, einige Jahre später, ist er wohl der weltweit erste Forscher, der eine Doktorarbeit über Bitcoin geschrieben hat. Auf dem Arbeitsmarkt macht sich das gut. “Einen Job suchen musste ich nicht. Zwischendurch hatte ich 13 oder 14 Firmen, die in Frage kamen, und wurde von weiteren Firmen gefragt, ob ich auf ihre Kosten zu ihnen fliege, damit sie sich vorstellen. Ich habe denen dann gesagt, dass sie sich das Geld und die Zeit sparen sollen.”

Mittlerweile hat sich Christian Decker entschieden. Sein künftiger Arbeitgeber ist ein internationales Unternehmen, so viel verrät er, und er kann direkt mit dem Thema weitermachen, mit dem er sich die vergangenen Jahre beschäftigt hat: der Skalierbarkeit von Blockchains. Über dieses Thema, das die Bitcoin-Szene seit gut einem Jahr heftig bewegt, haben wir uns im Interview intensiv unterhalten.

Natürliche Grenzen

Du hast mit anderen Wissenschaftlern weltweit ein Paper zur Skalierbarkeit geschrieben. Wie kam das?

Mit Skalierbarkeit habe ich mich schon früh beschäftigt. Nachdem ich angefangen habe, Bitcoin zu erforschen, und das Protokoll verstanden habe, stellte sich mir die Frage: jeder speichert alles und verifiziert alles – das skaliert doch nicht, oder?

Als es dann drum ging, ein Thema für Doktorarbeit zu finden, dachte ich mir, ok, ich frage einfach, ob und wie wir Bitcoin skalieren können. In den letzten Jahren habe ich daher mehrere Paper über Skalierbarkeit geschrieben. Ich habe mich auch mit anderen Themen beschäftigt, aber die Skalierbarkeit finde ich am spannendsten.

Du schreibst, “Bitcoin skaliert nicht”. Kann man nicht einfach die Größe der Blöcke erhöhen, um mehr Transaktionen durchzulassen?

Das geht schon, aber nur bis zu einer bestimmten Größe. Man stößt dabei relativ flott an Grenzen, und zwar Grenzen, die Naturgesetze sind. Ab einer bestimmten Blockgröße bekommt man die Daten nicht mehr durchs Netz gepumpt.

Mit skalieren meint man im Allgemeinen, dass man keine solche Grenze vor Augen hat. Die perfekte Skalierbarkeit ist, dass man grenzenlos neue Nutzer aufnehmen und diese Menge an Daten verarbeiten kann.

Die Blockgröße ist also schon ein Parameter, an dem man drehen kann. Es wurde lange diskutiert, wie man das macht, ohne dass wir zu einer Lösung gekommen sind, was für viel Frust gesorgt hat. Aber im Endeffekt stößt man damit an natürliche Grenzen.

Wo liegen diese natürlichen Grenzen?

Mein allererstes Paper ging darum, wie sich Informationen im Bitcoin-Netzwerk ausbreiten. Wir haben ausgerechnet, was passiert, wenn wir immer größere Blöcke haben. Ab einem bestimmten Wert kommt es zu Problemen.

Um das zu verstehen, muss man sich überlegen, was passiert, wenn ein Miner einen Block findet: Er beginnt, diesen Block im Netzwerk zu verteilen. Während sich der Block verbreitet, von Knoten zu Knoten, gibt es zwei Gruppe im Netzwerk: In der einen weiß man, dass es es diesen Block gibt, und in der anderen weiß man das nicht.

Ein Miner, der im unwissenden Teil des Netzwerks sitzt, wird weiter an einem Block rechnen, obwohl dieser von einem anderen schon gefunden und verteilt wurde. Während ein Block durchs Netzwerk wandert, wird der unwissende Teil immer kleiner, weil wir ja den gefundenen Block weiter verteilen, und der Teil des Netzwerks, der ihn kennt, wird größer.

Je größer ein Block ist, desto länger braucht er aber, um alle im Netzwerk zu erreichen. Ab einer bestimmten Größe schrumpft der Teil, der den Block noch nicht kennt, so langsam, dass die Konkurrenz schon einen neuen Block gefunden hat, bevor die Miner im unwissenden Teil von dem alten Block erfahren haben. In so einer Situation kommt es zu vielen Forks, die das Netzwerk in viele kleine Inseln verteilen.

Ab welcher Blockgröße würde das passieren?

Als wir das 2012 ausgerechnet haben, lag diese Grenze bei 13,5 MB. Heute liegt sie vermutlich höher, weil das Netzwerk effizienter wurde. Wir haben das Relay-Netzwerk, die Mining-Pools arbeiten effizienter, und die Anzahl der Knoten wurde geringer. Man müsste die konkrete Größe neu schätzen.

Das ist aber keine Schwarz-Weiß-Frage. Als Miner muss man annehmen, dass, wenn man einen Block findet, ein konkurrierender Miner diesen Block mit einer bestimmten Wahrscheinlichkeit schon gefunden hat. Der Erwartungswert sagt, wieviele konkurrierende Blöcke vermutlich in Umlauf sind. Derzeit ist er 0,015. Als wir das damals ausgerechnet haben, ist er bei 13,5 MB auf über 1 gestiegen, was für uns bedeutet, dass das Netzwerk zerteilt wird. Bei Blöcken mit 1 GB wäre der Erwartungswert etwa 50, das heißt, ein Miner müsste annehmen, dass der Block, den er eben gefunden hat, schon 50-Mal im Netzwerk unterwegs ist.

Flaschenhälse & Hops

Das ist aber nur einer der Flaschenhälse. In eurem Paper habt ihr weitere Faktoren, an denen die Skalierung hängt, beschrieben. Welche sind das?

Es ging hier vor allem um die Kapazität der Knoten. Die CPU validiert Transaktionen, die Festplatten speichern die Blockchain, die Bandbreite leitet Blöcke weiter. Wir sind dabei von ganz normalen Laptops ausgegangen, um auszurechnen, wie weit man die Blockgröße erhöhen kann, ohne dass ein Durchschnitts-Knoten rausgeworfen wird.

Diese knotenspezifischen Limits sind aber gar nicht so wichtig. Viel wichtiger ist, was sich durch die Verbindung der Knoten ergibt. Und da stoßen wir auf Limits, die zeigen, dass die effiziente Durchsatzrate des Netzwerks wesentlich geringer ist als das, was der einzelne Knoten leisten kann. Denn wir müssen über mehrere Hops kommunizieren.

Stell dir vor, ich sage zu dir, hei, ich habe einen Block, und du schaust, ob du den Block schon kennst, und wenn du ihn nicht kennst, sagst du zu mir, hallo, ich habe Interesse. Ich schicke dir den Block dann, aber bis es soweit ist, haben wir schon zweimal kommuniziert. Dann beginnst du, den Block zu verifizieren, dafür brauchst du Festplatte und CPU, und erst danach kannst du ihn an deine Nachbarn weitergeben. All das führt zu Latenzen.

Wir haben das für ein anderes Paper nochmal genau ausgerechnet, und kamen dazu, dass man bei etwa 27 Transaktionen je Sekunden an ein Limit stößt.

Hört sich an, als sei die Anzahl der Hops der entscheidende Faktor bei der Skalierbarkeit. Weißt du, wieviele das gewöhnlich sind?

Ja, das kann man so sagen. Ich habe eine Webseite, bitcoinstats.com, auf der ich zeige, wie lange die Blöcke und Transaktionen brauchen. Da kann man vielleicht auch die Hops erkennen.

Auf bitcoinstats.com verbinden wir uns mit jeder Menge Knoten im Netzwerk und messen, wie lange wir brauchen, um 50 oder 90 Prozent des Netzwerks zu erreichen. Wie lange dauert es, bis sie uns sagen, hei, wir haben diesen Block, wollt ihr ihn auch haben? So sehen wir die allgemeine Latenz des Netzwerks. Bei 50% ist das super, aber bei 90% dauert es oft länger. Wir haben eine lange tail.

Wie viele Hops es sind, lässt sich schwer schätzen. Bei einer Abdeckung von 100 % kann es eine Kette von bis zu 20 Hops geben, aber ich denke, 90% sind in vier bis fünf Hops erreichbar.

Das heißt, mit dem Netzwerk, das wir jetzt haben, werden wir nie die Kapazität erreichen, die wir uns wünschen …

Ja, wir können zwar noch ein wenig an der Blocksize herumschrauben, ich denke, 2, 4, vielleicht sogar 8 MB sollten machbar sein, auch wenn das vermutlich mit Abstrichen im Sicherheitsgrad von Bestätigungen einhergeht, da größere Blöcke zu mehr Forks führen. Aber selbst damit sind wir noch bei einer zweistelligen Anazhl von Transaktionen je Sekunde. Momentan haben wir 3-7, wenn wir das mal acht rechnen, ist das immer noch relativ wenig im Vergleich mit Visa oder PayPal. Das Potenzial, das man sich heute ausrechnet, kann man damit nicht verwirklichen, etwa ein Micorpayment, um für Inhalte zahlen. Das funktioniert onchain nicht.

Du meinst, nicht auf der Bitcoin Blockchain, oder generell onchain? Ihr habt ja Vorschläge gemacht, wie man das Netzwerk verbessern könnte …

Ja, Emin Gur Sürer, von der Universität Cornell, hat Bitcoin NG vorgeschlagen. Damit kann man sicherlich einiges machen, und wir an der ETH haben unser eigenes Protokoll entwickelt, peersensus. Die beiden Systeme sorgen dafür, dass man Blöcke nicht mehr benutzt, um Transaktionen zu bestätigen, sondern nur noch, um den Einfluss der einzelnen Teilnehmer im Netzwerk zu beschränken. Dadurch kann man die Kapazität etwa um den Faktor 10 steigern, aber diese beiden Systeme basieren weiterhin darauf, dass man den globalen Zustand erhält – dass also alle Knoten alle Transaktionen speichern müssen. Hier stößt man weiterhin recht schnell an eine Grenze.

Duplex und Lightning

Gibt es auch Möglichkeiten, Blockchains so aufzubauen, dass nicht jeder alles speichern und validieren muss?

Es gibt verschiedene Ideen, aber noch keine, die reif genug ist. Sie leiden alle darunter, dass sich einzelne Teilnehmer womöglich isolieren können und dann den Teil, den sie exklusiv bearbeiten, manipuliert ans Netzwerk zurückgeben. Man sucht derzeit noch nach Methoden, das so aufzubauen, dass sich ein Teilnehmer nicht mehr so positionieren kann. Aber bisher hat jeder Vorschlag noch Probleme. Man weiß noch nicht mal, ob es überhaupt machbar ist.

Daher geht der trend dahin, es offchain zu versuchen. Du hast ja auch ein Modell gebaut, die Duplex-Microchannel …

Ja, unsere Duplex-Microchannel funktioniert ähnlich wie Lightning. Das war etwas ungünstig, weil Lightning nicht durchs wissenschaftliche peer review musste, war das schneller öffentlich als die Duplex-Microchannel.

Das Konzept der Microchannel ist, dass wir Geld beseite legen, die Transaktionen offchain übertragen und sie danach auf der Chain settlen. Die ganze Idee basiert darauf, dass wir diese Verhandlungen, die wir onchain machen, so strukturieren, dass automatisch verhindert wird, dass jemand betrügen kann.

Wenn ich jetzt sage, ich schicke dir 0,1 Bitcoin, dann gebe ich dir die Werkzeuge, um diese Entscheidung auf der Bitcoinblockchain durchzusetzen, auch wenn ich mich weigere oder verschwinde.

Was ist der Unterschied zum Lightning Network?

Wir haben dieselben Ziele und ein ähnliches Setup, aber es gibt kleine, strukturelle Unterschiede. Die beiden Systeme sind auch kompatibel, man kann wohl ein Netzwerk aufbauen, das beide verbindet. Da sowohl Lightning als auch Duplex Hashed Timelock Contracts verwenden, sollten die Transaktionen des einen Systems auch vom anderen erkannt werden.

Was meinst du, wie lange es noch dauern wird, bis es diese Netzwerke gibt?

Es gibt schon ein paar Prototypen, und neben den Lightning-Leuten arbeiten Rusty Russel von Blockstream und ich an Implementierungen. Ich habe auch schon einen halbfertigen Microchannel Prototypen, der am Laufen ist. Die Protokolle sind kompliziert, aber Leute arbeiten daran, sie umzusetzen. Das ist nicht das Problem.

Wichtiger ist derzeit, dass wir die Grundarbeit machen. Etwa dass wir Segregated Witness bekommen. Das brauchen beide Netzwerke, weil sie darauf beruhen, dass sie offchain Transaktionen verketten, und dafür müssen wir die Transaction Malleability lösen. Das ist das, was Segregated Witness macht.