Danksharding

Danksharding ist der Weg, wie Ethereum zu einer wirklich skalierbaren Blockchain wird, aber es sind mehrere Protokoll-Upgrades erforderlich, um dorthin zu gelangen. Proto-Danksharding ist ein Zwischenschritt auf diesem Weg. Beide zielen darauf ab, Transaktionen auf Layer 2 für Benutzer so kostengünstig wie möglich zu machen und sollten Ethereum auf mehr als >100.000 Transaktionen pro Sekunde skalieren.

Was ist Proto-Danksharding?

Proto-Danksharding, auch bekannt als EIP-4844(opens in a new tab), ist eine Möglichkeit für Rollups, kostengünstigere Daten zu Blöcken hinzuzufügen. Der Name stammt von den beiden Forschern, die die Idee vorgeschlagen haben: Protolambda und Dankrad Feist. Historisch gesehen unterlagen Rollups Beschränkungen, wie günstig sie Benutzertransaktionen machen konnten, da sie ihre Transaktionen in CALLDATA veröffentlichen.

Das ist kostspielig, da dies von allen Ethereum-Knoten verarbeitet wird und für immer auf der Chain gespeichert bleibt, obwohl Rollups die Daten nur für kurze Zeit benötigen. Proto-Danksharding führt Datenblobs ein, die versendet und an Blöcke angehängt werden können. Die Daten in diesen Blobs sind für die EVM nicht zugänglich und werden nach einer festgelegten Zeitspanne (zum Zeitpunkt der Erstellung dieses Dokuments 4.096 Epochen, also etwa 18 Tage) automatisch gelöscht. Das bedeutet, dass Rollups ihre Daten sehr viel kostengünstiger versenden und die Einsparungen in Form von günstigeren Transaktionen an die Endbenutzer weitergeben können.

Wie werden Blob-Daten überprüft?

Rollups posten die Transaktionen, die sie ausführen, in Datenblobs. Sie posten auch eine „Verpflichtung“ zu den Daten. Dies tun sie, indem sie eine Polynomfunktion an die Daten anpassen. Diese Funktion kann dann an verschiedenen Punkten ausgewertet werden. Wenn wir zum Beispiel eine extrem einfache Funktion f(x) = 2x-1 definieren, dann können wir diese Funktion für x = 1, x = 2, x = 3 auswerten und erhalten die Ergebnisse 1, 3, 5. Ein Prüfer wendet die gleiche Funktion auf die Daten an und wertet sie an den gleichen Punkten aus. Wenn die ursprünglichen Daten geändert werden, ist die Funktion nicht mehr identisch und daher auch nicht die an jedem Punkt ausgewerteten Werte. In Wirklichkeit sind die Verpflichtung und der Beweis komplizierter, da sie in kryptografische Funktionen eingebettet sind.

Was ist KZG?

KZG steht für Kate-Zaverucha-Goldberg – die Namen der drei ursprünglichen Autoren(opens in a new tab) eines Schemas, das einen Datenblob auf eine kleine kryptographische „Verpflichtung“(opens in a new tab) reduziert. Der von einem Rollup eingereichte Datenblob muss verifiziert werden, um sicherzustellen, dass der Rollup sich nicht falsch verhält. Dies beinhaltet, dass ein Prüfer die Transaktionen im Blob erneut ausführt, um zu überprüfen, ob das Commitment gültig war. Konzeptionell ist dies das gleiche Verfahren, mit dem Ausführungs-Clients die Gültigkeit von Ethereum-Transaktionen auf Layer 1 mithilfe von Merkle-Beweisen überprüfen. KZG ist ein alternativer Beweis, der eine Polynomgleichung an die Daten anpasst. Das Commitment bewertet das Polynom an einigen geheimen Datenpunkten. Ein Beweiser würde das gleiche Polynom über die Daten anpassen und es an denselben Werten auswerten, um zu überprüfen, ob das Ergebnis dasselbe ist. Dies ist eine Möglichkeit der Verifizierung der Daten, die mit den Null-Wissen-Techniken kompatibel sind, die von einigen Rollups und schließlich auch anderen Teilen des Ethereum-Protokolls verwendet werden.

Was war die KZG-Zeremonie?

Die KZG-Zeremonie war eine Möglichkeit für viele Menschen aus der Ethereum-Community, gemeinsam eine geheime zufällige Zeichenfolge zu generieren, mit der bestimmte Daten verifiziert werden können. Es ist sehr wichtig, dass diese Zeichenfolge nicht bekannt ist und von niemandem neu erstellt werden kann. Um dies zu gewährleisten, erhielt jede Person, die an der Zeremonie teilnahm, eine Zeichenfolge vom vorherigen Teilnehmer. Dann erstellten sie neue Zufallswerte (z. B. indem sie mit ihrem Browser die Bewegung ihrer Maus erfassten) und mischten sie mit dem vorherigen Wert. Dann schickten sie den Wert an den nächsten Teilnehmer weiter und löschten ihn von ihrem lokalem Rechner. Solange nur eine Person in der Zeremonie dies aufrichtig ausführt, kann ein Angreifer den endgültigen Wert nicht einsehen.

Die EIP-4844 KZG-Zeremonie war für die Öffentlichkeit zugänglich. Zehntausende Menschen nahmen daran teil und fügten ihre eigene Entropie (Zufälligkeit) hinzu. Insgesamt gab es über 140.000 Beiträge, wodurch sie zur weltweit größten Zeremonie dieser Art wurde. Damit die Zeremonie untergraben wird, müssten 100% dieser Teilnehmer aktiv unehrlich sein. Aus der Sicht der Teilnehmer besteht, sofern sie wissen, dass sie ehrlich waren, keine Notwendigkeit, jemand anderem zu vertrauen. Sie haben durch ihre Ehrlichkeit selbst die Sicherheit der Zeremonie gewährleistet und die Anforderung erfüllt, dass mindestens einer von N Teilnehmern ehrlich sein muss.

Was ist Danksharding?

Danksharding ist die vollständige Realisierung der Rollup-Skalierung, die mit Proto-Danksharding begann. Danksharding wird enorme Mengen an Speicherplatz auf Ethereum bereitstellen, damit Rollups ihre komprimierten Transaktionsdaten ablegen können. Das bedeutet, dass Ethereum problemlos Hunderte von individuellen Rollups unterstützen kann und Millionen von Transaktionen pro Sekunde zur Realität macht.

Dies funktioniert, indem die an die Blöcke angehängten Blobs von sechs (6) bei Proto-Danksharding auf 64 bei vollem Danksharding erweitert werden. Der Rest der benötigten Änderungen betrifft alle Updates in der Funktionsweise der Konsens-Clients, um sie in die Lage zu versetzen, die neuen großen Blobs zu verarbeiten. Mehrere dieser Änderungen sind bereits unabhängig von Danksharding aus anderen Gründen auf der Roadmap. Zum Beispiel erfordert Danksharding, dass die Trennung von Proposer und Builder implementiert wurde. Dies ist ein Upgrade, das die Aufgaben des Erstellens und Vorschlagens von Blöcken auf verschiedene Validierer verteilt. Ebenso ist Datenverfügbarkeitsstichproben für Danksharding erforderlich, aber sie sind auch für die Entwicklung von sehr leichtgewichtigen Clients erforderlich, die nicht viele historische Daten speichern ("zustandslose Clients").

Aktueller Fortschritt

Volles Danksharding ist noch einige Jahre entfernt. Inzwischen ist die KZG-Zeremonie mit über 140.000 Beiträgen abgeschlossen und das EIP(opens in a new tab) für Proto-Danksharding hat sich weiter entwickelt. Dieser Vorschlag wurde in allen Testnetzen vollständig implementiert und ging im März 2024 mit dem Netzwerk-Upgrade Cancun-Deneb („Dencun“) im Mainnet live.

Weiterführende Informationen

• Proto-Danksharding Notizen(opens in a new tab) - Vitalik Buterin
• Dankrad's Notizen zum Danksharing(opens in a new tab)
• Dankrad, Proto und Vitalik diskutieren Danksharding(opens in a new tab)
• Die KZG-Zeremonie(opens in a new tab)
• Carl Beekhuizens Devcon Vortrag über vertrauenswürdige Setups(opens in a new tab)
• Mehr zur Datenverfügbarkeitsabnahme für Blobs(opens in a new tab)
• Dankrad-Feist über KZG-Verpflichtungen und Beweise(opens in a new tab)
• Polynome Verpflichtungen KZG(opens in a new tab)