PeerDAS

Das Ethereum-Protokoll durchläuft sein bedeutendstes Skalierungs-Upgrade seit der Einführung von Blob-Transaktionen mit EIP-4844. Als Teil des Fusaka-Upgrades führt PeerDAS eine neue Methode zur Handhabung von Blob-Daten ein, die eine etwa zehnfache Erhöhung der Kapazität für Datenverfügbarkeit (DA) für Layer 2s (L2s) liefert.

Mehr zur Blob-Skalierungs-Roadmap (opens in a new tab)

Skalierbarkeit

Ethereums Vision ist es, eine neutrale, sichere und dezentrale Plattform zu sein, die für jeden auf der Welt verfügbar ist. Da die Netzwerknutzung wächst, erfordert dies ein Ausbalancieren des Trilemmas aus Skalierung, Sicherheit und Dezentralisierung des Netzwerks. Wenn Ethereum die vom Netzwerk verarbeiteten Daten in seinem aktuellen Design einfach erhöhen würde, bestünde die Gefahr, die Knoten zu überlasten, auf die sich Ethereum für seine Dezentralisierung verlässt. Skalierbarkeit erfordert ein rigoroses Mechanismus-Design, das Kompromisse minimiert.

Eine der Strategien zur Erreichung dieses Ziels besteht darin, ein vielfältiges Ökosystem von Layer-2-Skalierungslösungen zu ermöglichen, anstatt alle Transaktionen auf dem Mainnet zu verarbeiten. oder Rollups verarbeiten Transaktionen auf ihren eigenen separaten Chains und nutzen Ethereum für Verifizierung und Sicherheit. Durch die Veröffentlichung nur sicherheitskritischer Commitments und die Komprimierung von Payloads können L2s die DA-Kapazität von Ethereum effizienter nutzen. Im Gegenzug trägt L1 weniger Daten, ohne Sicherheitsgarantien zu beeinträchtigen, während L2s mehr Nutzer bei niedrigeren Gas-Kosten aufnehmen. Anfänglich veröffentlichten L2s Daten als calldata in gewöhnlichen Transaktionen, was mit L1-Transaktionen um Gas konkurrierte und für die massenhafte Datenverfügbarkeit unpraktisch war.

Proto-Danksharding

Der erste große Schritt zur Skalierung von L2 war das Dencun-Upgrade, das Proto-Danksharding (EIP-4844) einführte. Dieses Upgrade schuf einen neuen, spezialisierten Datentyp für Rollups namens Blobs. Blobs (Binary Large Objects) sind flüchtige Stücke beliebiger Daten, die keine EVM-Ausführung benötigen und von Knoten nur für eine begrenzte Zeit gespeichert werden. Diese effizientere Verarbeitung ermöglichte es L2s, mehr Daten auf Ethereum zu veröffentlichen und noch weiter zu skalieren.

Obwohl die Verwendung von Blobs bereits starke Vorteile für die Skalierung bietet, ist sie nur ein Teil des Endziels. Im aktuellen Protokoll muss jeder Knoten im Netzwerk immer noch jeden Blob herunterladen. Der Flaschenhals wird die von einzelnen Knoten benötigte Bandbreite, wobei die Datenmenge, die heruntergeladen werden muss, direkt mit höheren Blob-Anzahlen steigt.

Ethereum geht bei der Dezentralisierung keine Kompromisse ein, und die Bandbreite ist einer der empfindlichsten Stellhebel. Selbst wenn leistungsstarke Computer für jeden, der sie sich leisten kann, weithin verfügbar sind, könnten Einschränkungen der Upload-Bandbreite (opens in a new tab) selbst in stark urbanisierten Städten in Industrienationen (wie Deutschland (opens in a new tab), Belgien (opens in a new tab), Australien (opens in a new tab) oder den Vereinigten Staaten (opens in a new tab)) Knoten darauf beschränken, nur aus Rechenzentren betrieben werden zu können, wenn die Bandbreitenanforderungen nicht sorgfältig abgestimmt werden.

Knotenbetreiber haben mit zunehmenden Blobs immer höhere Anforderungen an Bandbreite und Speicherplatz. Die Größe und Menge der Blobs sind durch diese Einschränkungen begrenzt. Jeder Blob kann bis zu 128 KB Daten tragen, mit durchschnittlich 6 Blobs pro Block. Dies war nur der erste Schritt in Richtung eines zukünftigen Designs, das Blobs auf noch effizientere Weise nutzt.

Data Availability Sampling

Datenverfügbarkeit ist die Garantie, dass alle Daten, die zur unabhängigen Validierung der Chain benötigt werden, für alle Netzwerkteilnehmer zugänglich sind. Sie stellt sicher, dass die Daten vollständig veröffentlicht wurden und verwendet werden können, um den neuen Zustand der Chain oder eingehende Transaktionen vertrauenslos zu verifizieren.

Ethereum-Blobs bieten eine starke Datenverfügbarkeitsgarantie, die die Sicherheit von L2s gewährleistet. Um dies zu tun, müssen Ethereum-Knoten Blobs in ihrer Gesamtheit herunterladen und speichern. Aber was wäre, wenn wir Blobs im Netzwerk effizienter verteilen und diese Einschränkung vermeiden könnten?

Ein anderer Ansatz zur Speicherung der Daten und Sicherstellung ihrer Verfügbarkeit ist das Data Availability Sampling (DAS). Anstatt dass jeder Computer, auf dem Ethereum läuft, jeden einzelnen Blob vollständig speichert, führt DAS eine dezentrale Arbeitsteilung ein. Es verringert die Last der Datenverarbeitung, indem es kleinere, überschaubare Aufgaben über das gesamte Netzwerk von Knoten verteilt. Blobs werden in Stücke unterteilt und jeder Knoten lädt nur wenige Stücke herunter, wobei ein Mechanismus zur gleichmäßigen zufälligen Verteilung über alle Knoten verwendet wird.

Dies führt zu einem neuen Problem – dem Nachweis der Verfügbarkeit und Integrität der Daten. Wie kann das Netzwerk garantieren, dass die Daten verfügbar und alle korrekt sind, wenn einzelne Knoten nur kleine Stücke halten? Ein bösartiger Knoten könnte gefälschte Daten liefern und starke Datenverfügbarkeitsgarantien leicht brechen! Hier kommt die Kryptographie zur Hilfe.

Um die Integrität der Daten sicherzustellen, wurde EIP-4844 bereits mit KZG-Commitments implementiert. Dies sind kryptographische Beweise, die erstellt werden, wenn ein neuer Blob zum Netzwerk hinzugefügt wird. Ein kleiner Beweis ist in jedem Block enthalten, und Knoten können verifizieren, dass empfangene Blobs dem KZG-Commitment des Blocks entsprechen.

DAS ist ein Mechanismus, der darauf aufbaut und sicherstellt, dass die Daten sowohl korrekt als auch verfügbar sind. Sampling ist ein Prozess, bei dem ein Knoten nur einen kleinen Teil der Daten abfragt und ihn gegen das Commitment verifiziert. KZG ist ein polynomielles Commitment-Schema, was bedeutet, dass jeder einzelne Punkt auf der Polynomkurve verifiziert werden kann. Durch die Überprüfung von nur ein paar Punkten auf dem Polynom kann der Client, der das Sampling durchführt, eine starke probabilistische Garantie haben, dass die Daten verfügbar sind.

PeerDAS (EIP-7594) (opens in a new tab) ist ein spezifischer Vorschlag, der den DAS-Mechanismus in Ethereum implementiert und wahrscheinlich das größte Upgrade seit dem Merge markiert. PeerDAS ist darauf ausgelegt, Blob-Daten zu erweitern, sie in Spalten zu unterteilen und eine Teilmenge an Knoten zu verteilen.

Ethereum leiht sich dafür etwas clevere Mathematik: Es wendet Löschcodierung im Reed-Solomon-Stil auf Blob-Daten an. Blob-Daten werden als Polynom dargestellt, dessen Koeffizienten die Daten kodieren. Dann wird dieses Polynom an zusätzlichen Punkten ausgewertet, um einen erweiterten Blob zu erstellen, was die Anzahl der Auswertungen verdoppelt. Diese hinzugefügte Redundanz ermöglicht die Wiederherstellung nach Löschung: Selbst wenn einige Auswertungen fehlen, kann der ursprüngliche Blob rekonstruiert werden, solange mindestens die Hälfte der gesamten Daten, einschließlich der erweiterten Stücke, verfügbar ist.

In der Realität hat dieses Polynom Tausende von Koeffizienten. KZG-Commitments sind Werte von wenigen Bytes, ähnlich wie ein Hash, die allen Knoten bekannt sind. Jeder Knoten, der genügend Datenpunkte hält, kann effizient einen vollständigen Satz von Blob-Daten rekonstruieren (opens in a new tab).

Fun Fact: Dieselbe Codierungstechnik wurde bei DVDs verwendet. Wenn man eine DVD zerkratzte, konnte der Player sie dank der Reed-Solomon-Codierung, die fehlende Stücke des Polynoms hinzufügt, immer noch lesen.

Historisch gesehen wurden Daten in Blockchains, ob Blöcke oder Blobs, an alle Knoten gesendet. Mit dem Split-and-Sample-Ansatz von PeerDAS ist es nicht mehr notwendig, alles an jeden zu senden. Nach Fusaka ist das Netzwerk der Konsensschicht in Gossip-Themen/Subnetze organisiert: Blob-Spalten werden bestimmten Subnetzen zugewiesen, und jeder Knoten abonniert eine vorbestimmte Teilmenge und verwahrt nur diese Stücke.

Mit PeerDAS werden erweiterte Blob-Daten in 128 Stücke, sogenannte Spalten, unterteilt. Daten werden über ein dediziertes Gossip-Protokoll auf bestimmten Subnetzen, die sie abonnieren, an diese Knoten verteilt. Jeder reguläre Knoten im Netzwerk nimmt an mindestens 8 zufällig ausgewählten Spalten-Subnetzen teil. Der Empfang von Daten aus nur 8 von 128 Subnetzen bedeutet, dass dieser Standardknoten nur 1/16 aller Daten erhält, aber da die Daten erweitert wurden, entspricht dies 1/8 der ursprünglichen Daten.

Dies ermöglicht ein neues theoretisches Skalierungslimit, das 8-mal so hoch ist wie das aktuelle „Jeder lädt alles herunter“-Schema. Da Knoten verschiedene zufällige Subnetze abonnieren, die Blob-Spalten bedienen, ist die Wahrscheinlichkeit sehr hoch, dass sie gleichmäßig verteilt sind und daher jedes Datenstück irgendwo im Netzwerk existiert. Knoten, die Validatoren betreiben, müssen mit jedem Validator, den sie betreiben, mehr Subnetze abonnieren.

Jeder Knoten hat eine eindeutige, zufällig generierte ID, die normalerweise als seine öffentliche Identität für Verbindungen dient. In PeerDAS wird diese Nummer verwendet, um zufällige Subnetze zu bestimmen, die er abonnieren muss, was zu einer gleichmäßigen zufälligen Verteilung aller Blob-Daten führt.

Sobald ein Knoten die ursprünglichen Daten erfolgreich rekonstruiert hat, verteilt er die wiederhergestellten Spalten zurück in das Netzwerk, heilt aktiv alle Datenlücken und verbessert die allgemeine Systemresilienz. Knoten, die mit Validatoren mit einem kombinierten Guthaben von ≥4096 ETH verbunden sind, müssen ein Superknoten sein und daher alle Datenspalten-Subnetze abonnieren und alle Spalten verwahren. Diese Superknoten werden kontinuierlich Datenlücken heilen. Die probabilistisch selbstheilende Natur des Protokolls ermöglicht starke Verfügbarkeitsgarantien, ohne Heimanwender einzuschränken, die nur Teile der Daten halten.

Die Datenverfügbarkeit kann von jedem Knoten bestätigt werden, der nur eine kleine Teilmenge der Blob-Daten hält, dank des oben beschriebenen Sampling-Mechanismus. Diese Verfügbarkeit wird erzwungen: Validatoren müssen neuen Fork-Choice-Regeln folgen, was bedeutet, dass sie Blöcke nur akzeptieren und für sie stimmen, nachdem sie die Verfügbarkeit der Daten verifiziert haben.

Die direkte Auswirkung auf Nutzer (insbesondere L2-Nutzer) sind niedrigere Gebühren. Mit 8-mal mehr Platz für Rollup-Daten werden Nutzeroperationen auf ihrer Chain mit der Zeit noch günstiger. Aber niedrigere Gebühren nach Fusaka werden Zeit brauchen und von BPOs abhängen.

Blob-Parameter-Only (BPOs)

Das Netzwerk wird theoretisch in der Lage sein, 8-mal mehr Blobs zu verarbeiten, aber Blob-Erhöhungen sind eine Änderung, die ordnungsgemäß getestet und sicher schrittweise ausgeführt werden muss. Testnets bieten genug Vertrauen, um die Funktionen im Mainnet bereitzustellen, aber wir müssen die Stabilität des P2P-Netzwerks sicherstellen, bevor wir eine deutlich höhere Anzahl von Blobs aktivieren.

Um die Zielanzahl von Blobs pro Block schrittweise zu erhöhen, ohne das Netzwerk zu überlasten, führt Fusaka Blob-Parameter-Only (BPO) (opens in a new tab)-Forks ein. Im Gegensatz zu regulären Forks, die eine breite Koordination im Ökosystem, Zustimmung und Software-Updates erfordern, sind BPOs (EIP-7892) (opens in a new tab) vorprogrammierte Upgrades, die die maximale Anzahl von Blobs im Laufe der Zeit ohne Eingreifen erhöhen.

Das bedeutet, dass unmittelbar nach der Aktivierung von Fusaka und dem Livegang von PeerDAS die Anzahl der Blobs unverändert bleibt. Die Anzahl der Blobs wird sich alle paar Wochen verdoppeln, bis sie ein Maximum von 48 erreicht, während Entwickler überwachen, um sicherzustellen, dass der Mechanismus wie erwartet funktioniert und keine nachteiligen Auswirkungen auf die Knoten hat, die das Netzwerk betreiben.

Zukünftige Richtungen

PeerDAS ist nur ein Schritt in Richtung einer größeren Skalierungsvision von FullDAS (opens in a new tab) oder Danksharding. Während PeerDAS 1D-Löschcodierung für jeden Blob einzeln verwendet, wird vollständiges Danksharding ein umfassenderes 2D-Löschcodierungsschema über die gesamte Matrix der Blob-Daten verwenden. Die Erweiterung von Daten in zwei Dimensionen schafft noch stärkere Redundanzeigenschaften und eine effizientere Rekonstruktion und Verifizierung. Die Realisierung von FullDAS wird erhebliche Netzwerk- und Protokolloptimierungen sowie zusätzliche Forschung erfordern.

Weiterführende Literatur

Letzte Aktualisierung der Seite: 6. Juni 2026