ETH2: „Und einige Stunden später brach die Hölle aus.“

Bunte Glasscherben. Bild von Steve Snodgrass via flickr.com. Lizenz: Creative Commons

Am vergangenen Wochenende brach das erste ETH2-Testnetz zusammen. Es geht dabei um das Medalla-Testnet, auf dem die Beacon-Chain derzeit erprobt wird. Die Beacon-Chain ist das Herz des komplexen Gebildes, das ETH2 werden soll, und sie ist der erste Teil, der im Herbst dieses Jahres online gehen soll. Für viele ist der Crash des Medalle-Netzes ein Rückschlag, der den sorgenvoll erwarteten Start von ETH2 womöglich noch einmal verschiebt.

Ben Edgington von ConsenSys hat einen hervorragenden Artikel darüber geschrieben, was geschah. Das Medalla-Testnet ging am 4. August live. Auf ihm läuft eine Testversion der Beacon-Chain, die mehr oder weniger das Zentrum von ETH2 werden soll. Die ersten zehn Tage lief alles rund, auch wenn die Anzahl der Validatoren mit 70-80 Prozent eher enttäuschend war.

Am Freitag sank jedoch auf einen Schlag die Anzahl der aktiven Validatoren um etwa 80 Prozent. Sämtliche Prysm-Validatoren hatten heruntergefahren. Prysm ist der am häufigsten verwendete Beacon-Chain-Nodes, weshalb der Ausfall schwerwiegende Folgen hatte.

Der Grund für den Crash war rasch festgestellt: Es gab ein Problem mit der Synchronisierung der Uhrzeit. Die Prysm-Clients benutzen die Roughtime von Cloudflare, um die Zeit herauszufinden. Auf irgendeine Weise rutschte die Roughtime am Freitag etwa eine Stunde lang um etwa vier Stunden in die Zukunft. Da die Prysm-Clients also dachten, sie wären in der Zukunft, bildeten sie Blöcke und Attestations (Beglaubigungen) für eine Blockchain, die es noch gar nicht gab.

Das selbst war noch gar nicht das Problem. Die anderen Clients – vor allem Lighthouse – haben die Beacon-Chain erhalten und weitergeführt, auch wenn einige Blöcke fehlten. Sie ignorierten die Flut an Beglaubigungen aus der Zukunft, die die Prysm-Nodes gesendet hatten. Die Prysm-Knoten wiederum fanden die richtige Zeit wieder, passten sich an und nahmen wieder an der Block-Produktion teil. Vorerst konnten die Entwickler aufatmen.

Eine Stunden später zerbröckelte das Medalla-Netzwerk jedoch. Edgington schreibt, die Hölle brach aus. Zunächst wurden nämlich all die Beglaubigungen aus der Zukunft, die die Knoten im Netzwerk ignoriert, aber gespeichert hatten, plötzlich gültig. Weil die Prysm-Knoten sich weigerten, widersprüchliche Beglaubigungen auszustellen, stürzten sie erneut ab und verließen das Netzwerk. „Das Resultat aus beidem war Chaos. Die Baecon Chain explodierte in einen Wald aus Ästen, als die verbleibenden Clients darum kämpften, die verrückten Informationen zu verarbeiten, die sie erhielten.“

Eine Zeitlang konnten sich die Clients halten. Aber im Lauf der nächsten 24 Stunden stiegen die Anforderungen an Arbeitsspeicher und CPU drastisch, da die immer komplexer werdende Menge der Forks die Knoten überwältigten. „Ich sah einen Lighthouse Client, der 30 Gigabyte an Arbeitsspeicher benutzte, was etwa 100 Mal so viel ist, wie normal“, und jemand anderes hatte Probleme, mit 12 Gigabyte an Arbeitsspeicher und einem vollständig ausgelasteten Prozessor.

Derzeit erholt sich das Netzwerk langsam, und es gibt wohl auch Versionen von Prysm und Lighthouse, die einigermaßen effizient und stabil die richtige Chain finden und auf ihr aufbauen.

Natürlich ist ein Testnet dafür da, um Probleme zu finden. Daher könnte man einen solchen Vorfall auch als Erfolg sehen – besser es passiert jetzt als im Mainnet. Der Crash hat die Entwickler darauf gestoßen, wie angreifbar sich die Beacon-Chain macht, wenn sie von einer Uhrzeit abhängt, und er hat vorgeführt, was passiert, wenn das Netzwerk mit Beglaubigungen aus der Zukunft geflutet wird.

Auf der anderen Seite zeigt der Vorfall aber auch, wie komplex schon der erste Baustein von ETH2 ist, und wie fragil eine Blockchain sein kann. Der Ausfall eines Details führt dazu, dass alles einstürzt, dass die Knoten den Konsens verlieren, welche Chain die richtige ist, und dass sich die Blockchain zersplittert. Dafür, dass ETH2 pünktlich, sicher und erfolgreich ankommt, ist das nicht eben ein zuversichtliches Signal.

Hat Ihnen der Beitrag gefallen? Der Autor Christoph Bergmann hat ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Sie können es direkt auf der Webseite Bitcoin-Buch.org bestellen – natürlich auch mit Bitcoin – oder auch per Amazon. Das Bitcoinblog.de wird von Bitcoin.de gesponsert.

Über Christoph Bergmann (1850 Beiträge)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Christoph hat vor kurzem ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Ihr könnt es direkt auf der Webseite Bitcoin-Buch.org bestellen - natürlich auch mit Bitcoin - oder auch per Amazon. Natürlich freuen wir uns auch über Spenden in Bitcoin, Bitcoin Cash oder Bitcoin SV an die folgende Adresse: 1BergmanNpFqZwALMRe8GHJqGhtEFD3xMw. Wer will, kann uns auch Hier mit Lightning spenden. Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Wer dies privat machen möchte, sollte meinen PGP-Schlüssel verwenden.

4 Kommentare zu ETH2: „Und einige Stunden später brach die Hölle aus.“

  1. Paul Janowitz // 19. August 2020 um 8:42 // Antworten

    Der Crash hat die Entwickler darauf gestoßen, wie angreifbar sich die Beacon-Chain macht, wenn sie von einer Uhrzeit abhängt, und er hat vorgeführt, was passiert, wenn das Netzwerk mit Beglaubigungen aus der Zukunft geflutet wird.

    Für jede Blockchain sind externe Faktoren / Daten ein sehr kritischer Punkt und ich frage mich, wie man bei Prysm auf die Idee gekommen ist, auf einen einzigen NTP Server zu setzen, wo das Protokoll sehr verbreitet und dezentralisiert ist. Bei „Oracles“ in Ethereum oder von Chainlink ist die Sache schwieriger, denn es gibt eben kaum zuverlässige Datenquellen und somit sind alle Smart Contracts / DeFi, die auf diesen Daten aufbauen grundsätzlich bedroht, falsche Daten zu erhalten und entsprechend zu reagieren.

    Schwerwiegender für ETH2 dürfte sein, dass ein einziger Bug in einem der Clients das gesamte Netzwerk zum Erliegen bringen konnte, obwohl die zweite Implementierung eigentlich hätte funktionieren müssen. Bei PoW ist die Sache vergleichsweise trivial oder binär, entweder ist ein Block gültig oder nicht, gibt es eine längere Chain, wird diese gültig und es gibt jeweils den Beweis, wie viel Hashpower jeweils in etwa eingeflossen sein muss.

    Ich vermute ähnliche Unzulänglichkeiten bei anderen PoS Projekten, allerdings sind sie schlicht zu unbedeutend, dass sie jemand wirklich Stress-testet, denn was bringt es, irgendein Tron oder EOS Netzwerk für Stunden zum Erliegen zu bringen, wenn da eh nix läuft? Der einzige Anreiz wäre die Schaffung neuer Coins, aber bei all den zentralisierten Ansätzen ist auch klar, dass die Chain wahrscheinlich zurückgesetzt werden würde und der Angreifer leer ausgeht. Die Konsensfindung ohne PoW ist sehr komplex, schließlich war es der entscheidende Durchbruch für Bitcoin, den Konsens auf diese Weise zu dezentralisieren.

    • @Paul Janowitz: Ich glaube schon, dass falls andere PoS-Projekte, wie z.B. EOS oder TRON, auf ähnliche Weise zum kollabieren bringen könnte, die durchaus „bedeutend“ genug sind um einen solchen Angriff zu starten. Denn billig sind die ja auch nicht. Stell Dir einfach vor Du könntest jetzt auf Short setzen und dann eine ganze Blockchain in einen solchen Meltdown schicken…

      • Paul Janowitz // 19. August 2020 um 9:47 //

        Naja, die meiste „Aktivität“ dürfte die Spekulation sein und 90%+ der „User“ halten diese wahrscheinlich eh auf der Exchange. Bei Bitcoin und Ethereum dürfte die reale Nutzung deutlich höher sein und der Anteil der Coins auf Börsen niedriger und da würde ein entsprechender Short auch entsprechend mehr Profit bringen.

        Fazit: Wahrscheinlich würde kaum jemand bemerken, wenn EOS oder Tron mal eben für ein paar Stunden down sind…

  2. Ein Teil der Probleme liegt aber auch wohl am Testnet und würde so im Mainnet nicht passieren. Problematisch ist die Anzahl der Validator die einfach ihre Nodes nicht aktualisieren. Es geht halt um nichts. Aber wenn da 10000€ oder mehr drin stecken wird man da wohl auch besser drauf achten. Und so sollte es nicht zu diesem Problem von unter unter 66% Beteiligung kommen.

Schreiben Sie einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Wechseln )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Wechseln )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Wechseln )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Wechseln )

Verbinde mit %s