Der rätselhafte Full Node von Ethereum

Ethereum kann verwirrend sein. Schon die Frage, wie groß die Blockchain ist – 100 Gigabyte oder ein Terabyte – stellt viele vor eine Herausforderung. Ebenso schwierig ist es, zu definieren, was ein Full Node ist, und zu erklären, wie man die Blockchain ausliest. Wir versuchen, mithilfe von Afri Schoedon von Parity ein wenig Licht ins Dunkel zu bringen.

Ethereum ist anders als Bitcoin und überfordert oft auch Leute, die man eigentlich für Experten halten sollte. Nichts zeigt dies so deutlich wie eine kurze Episode im Dauer-Propagandakrieg der Kryptoszene.

Und zwar hat jemand mit dem Pseudonym „StopAndDecrypt“ einen Artikel über Ethereum veröffentlicht, der den Titel trägt, dass die Blockchain mittlerweile größer als ein Terabyte sei. „StopAndDecrypt“ ist, muss man wissen, Moderator von r/Bitcoin – manche sagen dazu „Zensor“ – und tritt in vielen weiteren sozialen Medien als vehementer Streiter für die Sache Bitcoin Core auf. Sein Artikel läuft, wenig überraschend, darauf hinaus, dass Ethereum wegen der großen Blockchain dem Untergang geweiht und keine andere Währung als Bitcoin Core überlebensfähig ist. Oh, Wunder.

Die meisten in der Ethereum-Szene haben den Artikel relativ höflich kommentiert: Er sei im Detail absurd falsch, treffe aber den einen oder anderen Punkt. Die Blockchain sei mitnichten ein Terabyte groß – doch die hohe Datenlast mache Ethereum durchaus zu schaffen.

Das Thema hat einen Rattenschwanz an Fragen: Wie groß ist die Blockchain wirklich? Wie kommt man dazu, zu denken, sie sei ein Terabyte groß? Warum haben Ethereum-Nodes so viele verschiedene Modi, zu synchronisieren? Und wie sehr belastet die Datenmenge das Netzwerk tatsächlich? Afri Schoedon, Release-Manager von Parity, einer Ethereum-Node-Software, hat mir diese und andere Fragen beantwortet. Heraus kam eine Odysee in fünf Etappen.

I. Die Blockchain von Ethereum ist nicht mal halb so groß wie die von Bitcoin

Die Größe einer Blockchain ist einfach zu bestimmen: Sie ist die Summe aller Blöcke. Das ist ziemlich unkompliziert.

„Die Blockchain von Ethereum enthält alle Transaktionen. Das sind derzeit etwa 70 bis 80 Gigabyte. Wenn man sie heruntergeladen hat, kann man alles berechnen, was jemals passiert ist,“ erklärt Afri. Die Ethereum-Blockchain ist damit nicht – wie von StopAndDecrypt behauptet – größer als ein Terabyte, sondern in Wahrheit nicht mal halb so groß wie die von Bitcoin, die derzeit gut 170 Gigabyte auf die Waage bringt.

Laut den Statistiken von Etherstats.io gibt es etwa alle 15 Sekunden einen neuen Block, der maximal 25 Kilobyte groß ist. Damit wächst die Blockchain alle zehn Minuten um etwa ein Megabyte – also mit derselben Rate wie Bitcoin.

Soweit ist alles überschaubar.

II. Einen Node synchronisieren

Auch die erste Synchronisierung eines Nodes ist relativ einfach erklärt: Sowohl bei Bitcoin wie bei Ethereum lädt der Node die Blockchain herunter, Block für Block, und errechnet daraus einen Zustand. Bei Bitcoin heißt dieser UTXO-Set, bei Ethereum State.

Das UTXO-Set ist lediglich eine Art Liste mit Münzen, die noch nicht ausgegeben sind. Um es aufzubauen, muss der Node es Block für Block ausrechnen: Jede Transaktion vernichtet eine Münze und schafft eine neue. Auf diese Weise aktualisiert ein Node das UTXO-Set vom Genesis-Block bis in die Gegenwart.

Der State von Ethereum ist anders. Komplizierter. „Er enthält die Balance oder den Zustand von unter anderem jedem Smart Contract,“ erklärt Afri. Smart Contracts sind wie Algorithmen in einem Computerprogramm, und ihr State das jeweilige Ergebnis. Bei einem Token-Contract kann es eine Liste mit Guthaben der Accounts sein, bei der DAO die Ergebnisse von Abstimmungen. Und so weiter.

Aufgebaut wird der State aber auf diesselbe Weise wie ein UTXO-Set: Block für Block, bis man in der Gegenwart angekommen ist. Wenn ein Ethereum-Node synchronisiert, kalkuliert er den State mit jedem Block neu. Die Zwischenergebnisse – die historischen States – „sind nur wichtig, um den neuen State zu berechnen. Gewöhnlich wirft man die weg. Es gibt kaum Anwendungsfälle, bei denen man einen alten State braucht.“

Genau das macht ein “ganz normaler” Ethereum-Node: Er lädt die Blockchain herunter, kalkuliert im Arbeitsspeicher für jeden Block einen State, aber speichert nur den aktuellen. Je nach System dauert es 12 Stunden bis eine Woche, bis er damit fertig ist. Das Performance-Geheimnis für das Synchronisieren ist, so Afri, „ein möglichst großer Cache und möglichst viel Arbeitspeicher.“

III. Woher kennt der Node die Geschichte einer Adresse?

Da ein Node sowohl bei Bitcoin als auch bei Ethereum nur die Blockchain und den Endzustand speichert, ist es nicht ganz trivial, die Historie zu erfahren: Woher weiß der Node, welche Transaktionen mit oder zu einer Adresse ausgeführt wurden, wenn sie nicht mehr Teil des aktuellen Zustandes sind?

Die einfachste Variante ist, wenn der Node es „miterlebt“: wenn er die Adresse schon kennt und eine Zustandsänderung durch einen neuen Block erfährt. Dann weiß er, wonach er schauen muss, und speichert die relevanten Informationen in der Wallet-Datei. Aber was, wenn man die Adressen noch nicht hat, sondern später importiert? Bei dieser Frage zeigen sich die Unterschiede zwischen einem Node bei Bitcoin und Ethereum.

Bei Bitcoin gibt es zwei Möglichkeiten: Erstens, der Node reindiziert die Datenbank. Dies passiert, wenn man etwa einen privaten Schlüssel einspielt. Das Programm sucht dann in der Blockchain nach den entsprechenden Transaktionen. Einige Minuten später hat es die Historie der Adresse. Zweitens kann man den Node mit der Flagge „–txindex=1“ starten. Dann schreibt er während der Synchronisierung eine Liste mit Transaktionen. Das braucht einige Gigabyte zusätzlichen Speicher.

Bei Ethereum ist beides möglich – theoretisch. Praktisch wird es dadurch erschwert, dass es kein UTXO-Set gibt, sondern nur „Accounts“. Sie können sich das so vorstellen, dass ein Guthaben bei Bitcoin ein Eimer voller Münzen ist, die jeweils ihre Herkunft eingeprägt haben, während es bei Ethereum ein Eimer Wasser ist, von dem man lediglich den Pegel erkennt. Dieser Pegel kann durch normale Transaktionen verändert werden, aber auch durch die Ausführung von Smart Contracts. Dies macht es schwieriger, die vergangenen Ereignisse in der Blockchain zu finden.

Theoretisch ist es möglich, die Historie von Accounts auf Abruf zu rekonstruieren. Aber da kein Ethereum-Client diese Option hat, muss man es von Hand durch die APIs machen. Es geht aber auch einfacher: „Man kann auch alte Transaktions-Pfade sehen, indem man beim Synchronisieren die Option ‚–tracing on‘ aktiviert,“ sagt Afri, „dann speichert der Node die Ausführungsergebnisse der Transaktionen, was etwa 30-50% mehr Speicher braucht.“

IV. Warum es so schwierig ist, die Historie eines Smart Contracts nachzuzeichnen

Mit Tracing kann ein Ethereum-Node die Ergebnisse historischer Transaktionen nachschlagen. Würden wir von Bitcoin reden, wäre damit fast alles gesagt. Aber wir reden von Ethereum.

Afri erklärt, dass man mit Tracing nicht jeden Zustand von Smart Contracts rekonstruieren kann. Welchen State hatte ein ICO-Contract, nachdem 1.200 Leute teilgenommen haben? Welchen Zustand hatten Contracts wie von CryptoKitties bei einem bestimmten Block? Dies individuell nachzuprüfen ist sehr schwierig, vor allem, wenn mehrere Smart Contracts miteinander interagieren. „Um hier den State herauszufinden, reicht es nicht, einfach auf die Transaktionen zu schauen.“

Natürlich könnte man selektiv die States bilden, die man braucht. Aber das hat, so Afri, noch kein Client implementiert, und es ist sehr schwierig. Stattdessen kann man einen Node als „Full Archival Node“ (FAN) synchronisieren: der Node wirft die alten States nicht weg, sondern speichert sie auf der Festplatte. Das dauert ziemlich lang und braucht enorm viel Speicher. Man kann es sich so vorstellen, als würde ein Unternehmen nach jeder Transaktion – jeder verkauften Ware, jeder ausgeführten Gehaltszahlung – die komplette Bilanz neu ausrechnen und ausdrucken.

Für normale User, meint Afri, ist das unnötig. „Man braucht es nur, um rückwirkend den Zustand von Smart Contracts nachzuvollziehen. Ich sage immer, das brauchen nur Wissenschaftler, Strafermittler und Blockexplorer.“ Wer einen solchen FAN hat, kann in Echtzeit jede historische Zustandsänderung aller Smart Contracts abfragen.

V. Ein Terabyte fressender Monsternode

Ein FAN braucht mittlerweile mehr als ein Terabyte an Speicher. Afri schätzt, dass der Bedarf bis Ende des Jahres auf knapp zwei Terabyte anschwellen wird, und wenn Ethereum weiterhin so wächst wie derzeit, wird ein FAN in absehbarer Zukunft acht oder 16 Terabyte brauchen.

Für Hobby-User ist ein FAN schon jetzt zuviel. Erstens, weil es ewig und zwei Tage braucht, um ihn zu laden, und zweitens, weil eine SSD-Festplatte in der notwendigen Größe ziemlich teuer ist. Da ein FAN extrem viele Lese- und Schreiboperationen ausführt, ist der Verschleiß groß. Die Festplatte sollte mindestens einmal im Jahr gewechselt werden.

Sorgen, dass die FANs aussterben, macht sich Afri aber nicht. „Das Worst-Case-Szenario ist, dass es für Blockexplorer eben teurer wird. Es wird aber immer jemanden geben, der genügend Ressourcen hat, um so ein Ding laufen zu lassen.“ Was sind schon zwei 16-Terabyte-Festplatten im Jahr für ein lukratives Unternehmen? Die ersten 30-Terabyte-Platten sind bereits marktreif, 100-Terabyte-SSD-Festplatten stehen kurz vor dem Markteintritt. Die Anforderungen sind hoch, aber machbar.

Sorgen macht sich Afri daher auch eher um die normalen Full Nodes ohne das Archiv der historischen States.

VI. Dezentralität

Ein Full Node braucht bei Ethereum derzeit etwa 100 Gigabyte an Speicher. Das ist deutlicher weniger als ein Bitcoin Full Node. Allerdings frisst ein Full Node bei Ethereum viel mehr CPU-Leistung und Arbeitsspeicher als ein Bitcoin-Node und braucht länger, um zu synchronisieren. Der State ist eben komplexer als das UTXO-Set.

Aber derzeit ist noch alles in Ordnung. Ein Schwund an Nodes ist nicht feststellbar. Mit rund 17.000 Nodes mit offenen Ports hat Ethereum fast doppelt so viele Knoten wie Bitcoin. Einen Anlass, sich Sorgen zu machen, gibt es also noch nicht.

Wenn Ethereum jedoch weiterhin so wachsen wird wie bisher, wird die Größe eines Full Nodes in absehbarer Zukunft auf mehr als 500 Gigabyte anwachsen. Dies könnte, so Afri, eine Schmerzgrenze sein, ab der viele Hobbyisten ihren Full Node aufgeben. Die Schmerzen entstehen nicht nur durch den Speicherbedarf, sondern auch durch die anderen Faktoren, wie das Synchronisieren, die CPU-Belastung oder die Festplattenoperationen. Ein Full Node bremst schon heute viele Computer spürbar aus.

Die Alternative können für User „Warp-Nodes“ sein. Diese synchronisiert man bei Parity mit der Option „–warp“. Ein Warp-Node lädt sich von den anderen Nodes lediglich den State sowie eine bestimmte Anzahl der nachfolgenden Blöcke, standardmäßig 30.000, herunter. „Dank State-Trie-Root Hash im Block Header kann man nicht einfach einen falschen State bekommen. Es ist nahezu unmöglich, den zu faken.“ Für die Beträge, die Normalsterbliche empfangen und versenden, ist ein solcher Node mehr als ausreichend sicher. Zudem kann man durch einen Wechsel der Peers und die Anfrage bei verschiedenen Blockexplorern die Sicherheit weiter erhöhen.

Wie bei Bitcoin erfüllen Full Nodes in privater Hand bei Ethereum die Funktion eines Kontrollorgans. Wenn sie wegfallen, droht die Dezentralität von Ethereum zu zerbrechen, und die Kryptowährung könnte zum Spielball von Kartell-Interessen werden. Ab wann dies passiert, und wie schlimm es wirklich ist, ist jedoch eine Frage, über die man lange streiten kann. Besser wäre es jedoch, wenn es nicht nötig wäre, weil private Full Nodes weiterhin bestehen.

VII. Zukunft

Das Ziel der Ethereum-Entwickler ist es daher, die Full Nodes klein genug zu halten, dass sie von Hobby-Usern betrieben werden können, aber genügend Kapazität zu schaffen, um kein Wachstum abzublocken. Das ist sozusagen die Quadratur des Kreises, oder, wie Afri sagt, „der heilige Gral der Blockchain.“

Es ist „ein technisches Problem, auf das es viele theoretische und einige praktische Lösungsansätze gibt“: Erstens Sidechains, also dass man über Bridges andere Chains anbindet. Das gibt es schon, mit Loom und dem POA Network, steckt aber noch in den Kinderschuhen. Zweitens State Channels wie bei Raiden, was bedeutet, dass Transaktionen off-chain ausgeführt werden. Das gibt es schon als Prototyp, aber ist noch nicht so weit wie das Lightning-Netzwerk bei Bitcoin. Drittens wird an Sharding gearbeitet, was bedeutet, dass man die Chain aufsplittet.

All diese Lösungen sind noch einige Jahre entfernt, meint Afri. Er ist optimistisch, dass Ethereum so lange fortbesteht, findet aber auch, dass es knapp werden könnte. „Wir wollen ja nicht, dass nur große Firmen einen Knoten betreiben können. Es gibt derzeit noch keine Engpässe, aber es könnte in den nächsten Jahren kritisch werden.“