Wie man das Äthereum skaliert: Erklärtes Scherben

AKTUALISIERT, um die neuesten Forschungsänderungen für Ethereum 2.0 widerzuspiegeln!

Die Skalierbarkeitsdebatte steht im Mittelpunkt der Krypto-Community. Es ist allgemein bekannt, dass die größten öffentlichen Blockchains in ihrem gegenwärtigen Zustand nicht skaliert werden können, da wichtige Ereignisse wie das Cryptokitties-Debakel das gesamte Ethereum-Netzwerk innerhalb weniger Tage verstopfen.

Welche Ansätze hat die Community gewählt? Die Lösung ist zweifach. Der erste Ansatz besteht darin, die Skalierung durch Off-Chain-Lösungen zu verbessern, die auch als Layer-2-Skalierung bezeichnet werden. Dabei werden einige Transaktionen außerhalb der Blockchain abgewickelt und interagieren nur sparsam mit dieser. Der andere Ansatz besteht darin, den Entwurf des Protokolls insgesamt zu modifizieren, um die grundlegenden Probleme mit der Parallelisierbarkeit der Blockchain-Flächen zu beheben. Leider sehen sich viele von uns Protokollentwicklern diese Probleme oft an und fühlen sich sofort von der enormen Schwierigkeit, die sie darstellen, abgeschreckt.

Obwohl wir uns noch im Anfangsstadium von Ethereum befinden, ist die Community mit einigen der klügsten Köpfe der Technik besetzt, da so viele Innovationen mit rasender Geschwindigkeit stattfinden. Es ist leicht zu spüren, dass es intelligentere Entwickler gibt, die wahrscheinlich besser dafür geeignet sind, monumentale Probleme wie die Skalierbarkeit zu lösen, aber dieses Gefühl hält uns zurück. In Wahrheit ist die Community bereit und willens, allen zu helfen, die sich engagieren möchten, und das schließt auch SIE ein! In diesem Beitrag wird der aktuelle Ansatz des Ethereum-Kernteams zum Scherben aufgeschlüsselt und die aktuellen Einschränkungen und Verbesserungspfade aufgezeigt. Am Ende dieses Beitrags werden Sie genug wissen, um dieses Problem selbst zu untersuchen, und wer weiß, vielleicht sind Sie derjenige, der den ersten Sharding-Client erstellt!

Da die Anzahl der Transaktionen auf Ethereum ständig steigt, haben wir keine Zeit zu verlieren. Lass uns anfangen.

Was ist Scherben?

Derzeit muss jeder einzelne Knoten, auf dem das Ethereum-Netzwerk ausgeführt wird, jede einzelne Transaktion verarbeiten, die über das Netzwerk läuft. Dies gibt der Blockchain ein hohes Maß an Sicherheit, da jeder Block viel Validierung enthält. Gleichzeitig bedeutet dies, dass eine gesamte Blockchain nur so schnell ist wie ihre einzelnen Knoten und nicht die Summe ihrer Teile. Derzeit sind Transaktionen auf dem EVM nicht parallelisierbar und jede Transaktion wird der Reihe nach global ausgeführt. Das Skalierbarkeitsproblem hat dann mit der Idee zu tun, dass eine Blockchain höchstens zwei dieser drei Eigenschaften haben kann:

  • Dezentralisierung
  • Skalierbarkeit
  • Sicherheit

Wenn wir Skalierbarkeit und Sicherheit haben, würde dies bedeuten, dass unsere Blockchain zentralisiert ist und einen schnelleren Durchsatz ermöglicht. Richtig nicht, Ethereum ist dezentralisiert und sicher.

Wie können wir dieses Trilemma durchbrechen, um Skalierbarkeit in das aktuelle Modell aufzunehmen? Können wir nicht einfach die Blockgröße oder im Falle von Ethereum die GAS_LIMIT erhöhen, um den Durchsatz zu erhöhen? Während dies theoretisch ein richtiger Ansatz sein kann, wird das Mining umso mehr auf Knoten konzentriert sein, die auf Supercomputern laufen und eine höhere Barriere für den Zugang zum System darstellen.

Ein intelligenterer Ansatz ist die Idee des Blockchain-Shardings, bei dem wir den gesamten Status des Netzwerks in eine Reihe von Partitionen aufteilen, die als Shards bezeichnet werden und ihre eigenen unabhängigen Status- und Transaktionsprotokolle enthalten. In diesem System würden bestimmte Knoten Transaktionen nur für bestimmte Shards verarbeiten, sodass der Durchsatz der insgesamt verarbeiteten Transaktionen auf allen Shards viel höher ist als bei einem einzigen Shard, der die gesamte Arbeit wie jetzt in der Hauptkette erledigt.

Bevor wir uns mit der Funktionsweise einer Blockchain befassen, gehen wir zunächst einige wichtige Vokabeln durch:

  • Status: Der gesamte Informationssatz, der ein System zu einem beliebigen Zeitpunkt beschreibt. In Ethereum ist dies der aktuelle Kontosatz, der zu einem bestimmten Zeitpunkt die aktuellen Salden, den Smart Contract Code und die Nonces enthält. Jede Transaktion ändert diesen Zustand in einen völlig neuen Zustand.
  • Transaktion: Eine von einem Benutzer ausgegebene Operation, die den Status eines Systems ändert
  • Merkle Tree: Eine Datenstruktur, die eine große Datenmenge über kryptografische Hashes speichern kann. Merkle-Bäume machen es einfach, in kürzester Zeit und mit geringem Rechenaufwand zu überprüfen, ob ein Datenelement Teil der Struktur ist.
  • Empfang: Ein Nebeneffekt einer Transaktion, die nicht im Status des Systems gespeichert ist, sondern in einem Merkle-Baum gespeichert ist, damit ihre Existenz für einen Knoten leicht verifiziert werden kann. Intelligente Vertragsprotokolle in Ethereum werden beispielsweise als Belege in Merkle Trees aufbewahrt.

Schauen wir uns vor diesem Hintergrund an, wie Ethereum 2.0 funktionieren würde. Wir werden eine Sidechain erstellen, die als zufällige Beacon-Kette bekannt ist und Hashes zu Hauptkettenblöcken in eigenen Blöcken speichert. Diese Sidechain wird ein vollständiges Proof-of-Stake-System sein, das Casper FFG implementiert, und eine Quelle verteilter Zufälligkeit bieten, mit der wir ein Sharding-System aufbauen können.

Die Probleme mit Sharded Blockchains werden offensichtlicher, wenn wir mögliche Angriffe auf das Netzwerk berücksichtigen. Ein Hauptproblem ist die Idee eines Single-Shard-Übernahmeangriffs, bei dem ein Angreifer die Mehrheit der Kollatierer in einem einzigen Shard übernimmt, um einen böswilligen Shard zu erstellen, der ungültige Kollatierungen senden kann. Wie lösen wir dieses Problem?

Credits Hsiao-Wei Wang

In den Sharding-FAQ des Ethereum-Wikis wird eine zufällige Auswahl von Prüfern für jeden Shard vorgeschlagen. Das Ziel ist, dass diese Prüfer nicht wissen, welche Scherbe sie im Voraus erhalten. Jeder Scherbe wird eine Reihe von Validatoren zugewiesen, und diejenigen, die tatsächlich validiert werden, werden nach dem Zufallsprinzip aus diesem Satz ausgewählt.

Zu Beginn werden wir einen Vertrag in der Hauptkette, den Validator-Registrierungsvertrag, bereitstellen, bei dem die Leute 32ETH verbrennen, um ein Validator in dieser Nebenkette zu werden. Die Beacon-Kette sucht regelmäßig nach registrierten Validatoren und reiht diejenigen ein, die ETH in den Vertrag eingebrannt haben. Diese Leuchtfeuerkette wird als Koordinierungsvorrichtung für ein Sharding-System dienen, da sie eine verteilte Pseudozufälligkeit zulässt, die für die Auswahl von Komitees von Validatoren auf Shards von entscheidender Bedeutung ist. Die Quelle der Zufälligkeit muss gemeinsam sein, um sicherzustellen, dass diese Stichprobe vollständig vorgeschrieben ist und von den betreffenden Validatoren nicht erfasst werden kann.

Auf jedem Shard hätten wir Knoten, sogenannte Antragsteller, die die Aufgabe hätten, ein Querverbindungsglied in der Beacon-Kette zu erstellen. Dies ist eine spezifische Struktur, die wichtige Informationen über den fraglichen Shard enthält.

Diese Querverbindungen sind wie Mini-Beschreibungen des Staates und der Transaktionen auf einer bestimmten Scherbe. Ein typischer Querverweis würde uns folgende Informationen mitteilen:

  • Informationen darüber, welcher Scherbe die Kollatierung entspricht (sagen wir Scherbe 10)
  • Informationen zum aktuellen Status des Shards, bevor alle Transaktionen angewendet werden
  • Informationen zum Status des Shards, nachdem alle Transaktionen angewendet wurden
  • Unterschriften von mindestens 2/3 aller Kollaborateure auf dem Splitter, die Splitterblöcke bestätigten, waren legitim

Was ist, wenn eine Transaktion über mehrere Shards hinweg stattfindet? Was passiert zum Beispiel, wenn ich Geld von einer Adresse in Shard 1 an eine Adresse in Shard 10 sende? Einer der wichtigsten Teile dieses Systems ist die Fähigkeit, über Scherben hinweg zu kommunizieren, ansonsten haben wir nichts Neues erreicht.

Eine erste Idee ist, das Konzept der Belege zu verwenden, damit dieses System funktioniert.

Raul (Adresse auf Shard 1) will 100 ETH an Jim senden (Adresse auf Shard 10)

  1. Eine Transaktion wird an Shard 1 gesendet, die Rauls Kontostand um 100 ETH verringert und das System wartet, bis die Transaktion abgeschlossen ist
  2. Für die Transaktion wird dann eine Quittung erstellt, die nicht in dem Zustand gespeichert ist, sondern in einer Merkle-Wurzel, die leicht verifiziert werden kann
  3. Eine Transaktion wird mit der Merkle-Quittung als Daten an Shard 10 gesendet. Shard 10 überprüft, ob diese Quittung noch nicht ausgegeben wurde
  4. Shard 10 verarbeitet die Transaktion und erhöht den Kontostand von Jim um 100 ETH. Es wird dann auch die Tatsache gespeichert, dass die Quittung von Shard 1 ausgegeben wurde
  5. Shard 10 erstellt eine neue Quittung, die dann in nachfolgenden Transaktionen verwendet werden kann

Dies klingt für Solidity Devs und Ethereum-Benutzer so komplex, dass sie es verstehen! Wie werden wir sie zum Scherben erziehen?

Das brauchen sie nicht. Sharding wird ausschließlich auf der Protokollebene vorhanden sein und wird Entwicklern nicht zugänglich gemacht. Das Ethereum-Statussystem sieht weiterhin so aus wie bisher, das Protokoll verfügt jedoch über ein integriertes System, das Shards erstellt, den Status über Shards verteilt, zu kleine Shards entfernt und vieles mehr. Dies wird alles hinter den Kulissen geschehen, sodass Entwickler ihren aktuellen Workflow auf Ethereum fortsetzen können.

Jenseits des Skalierens: Superquadratische Scherben und unglaubliche Geschwindigkeitsgewinne

Um darüber hinauszugehen, ist es möglich, dass Ethereum ein überquadratisches Splitterschema anwendet (was im einfachen Englisch ein System bedeutet, das aus Splitterscherben aufgebaut ist). Eine solche Komplexität ist derzeit kaum vorstellbar, aber das Potenzial für Skalierbarkeit wäre enorm. Darüber hinaus bietet eine überquadratisch gestückelte Blockchain enorme Vorteile für die Benutzer, senkt die Transaktionsgebühren auf vernachlässigbare Mengen und dient als allgemeine Infrastruktur für eine Vielzahl neuer Anwendungen.

Ressourcen und erste Schritte

Ok, jetzt wollen Sie mit dem Codieren einer Blockchain beginnen! Wie fängst du an? Auf der einfachsten Ebene funktioniert die vorgeschlagene anfängliche Implementierung nicht über eine harte Gabelung, sondern über eine Sidechain, die als zufällige Beacon-Kette bezeichnet wird und als Beweis für das System aus Einsatz und Splittern dient.

Diese Beacon-Kette verwaltet Validatoren und deren Stichproben aus einem globalen Validator-Set und übernimmt die Verantwortung für die globale Abstimmung aller Shard-Zustände. Vitalik hat hier ein fantastisches Referenzdokument für die Implementierung von Sharding beschrieben: https://ethresear.ch/t/convenience-link-to-full-casper-chain-v2-spec/2332/4

Weitere Informationen zu dieser Beacon-Kettenarchitektur und zur Funktionsweise des Systems finden Sie in den folgenden Ressourcen:

  • Sharding-FAQ: https://github.com/ethereum/wiki/wiki/Sharding-FAQ
  • Sharding in Go: https://github.com/prysmaticlabs/geth-sharding
  • Beacon Chain Research - Inhaltsangabe: https://docs.google.com/document/d/19KyosgCFdsv_UzVdaApmIr0zh37Va0Tck1cca5uEtss/edit#

Willst du meinem Team beitreten?

Kennen Sie die Funktionsweise des Ethereum-Protokolls? Sind Sie ein Golang-Entwickler? Möchten Sie mit mir und einem Entwicklerteam zusammenarbeiten, um den ersten Sharding-Client für Ethereum 2.0 zu erstellen? Schauen Sie sich Prysmatic Labs an, ein Team, das von der Ethereum Foundation zur Implementierung von Sharding finanziert wird.

Lesen Sie unsere Richtlinien und unsere offenen Projekte zu Github. Jede Aufgabe und jedes Problem wird zusammen mit einem bestimmten Projekt, zu dem es gehört (Beacon-Kette, Validator-Knoten-Aufgaben usw.), in den Meilenstein der Phase 1 eingeteilt.

Folgen Sie uns wie immer auf Twitter, schreiben Sie uns hier oder in unserem Gitter-Chat und teilen Sie uns mit, womit Sie helfen möchten - wir brauchen jede erdenkliche Zusammenarbeit