Was ist Danksharding und Data Availability Sampling?

Warum Ethereum nicht einfach „Blöcke größer machen“ kann

Das Argument für Danksharding ergibt nur Sinn, wenn man zuerst die Einschränkung versteht, die es löst. Jeder Node auf einer Blockchain muss jeden Block herunterladen, verifizieren und speichern. Wenn man die Blockgröße einfach von beispielsweise einigen Hundert Kilobyte auf mehrere Megabyte erhöht, erhält man nicht mehr Durchsatz. Man erhält höhere Mindestanforderungen an die Hardware, weil selbst der günstigste Verbraucher-Laptop weiterhin mit der Chain Schritt halten muss.

Das ist die Spannung hinter dem bekannten Blockchain-Trilemma: Ein Netzwerk möchte dezentral sein (viele unabhängige Nodes), sicher sein (keine einfache Möglichkeit, die Historie zu fälschen) und skalierbar sein (viele günstige Transaktionen). Eine Erhöhung der Blockgröße verbessert eine Eigenschaft auf Kosten der anderen, weil die Anforderungen an Nodes steigen und die Zahl der Betreiber sinkt.

Ethereums Rollup-zentrierte Roadmap ist eine teilweise Antwort darauf. Statt alles auf Layer 1 zu erledigen, lässt man Layer-2-Rollups Tausende von Transaktionen ausführen und anschließend eine komprimierte Zusammenfassung zurück an Ethereum senden. Ethereum wird zu einer Settlement- und Datenschicht, nicht zu einem Weltcomputer. Das funktioniert, hat aber einen Engpass: Die Rollups brauchen einen günstigen und verifizierbaren Ort, um ihre Daten zu veröffentlichen, und dieser Ort ist derzeit Ethereums Call Data, die teuer ist und mit jeder anderen Nutzung von Blockspace konkurriert.

Danksharding ist der Plan, diesen Engpass zu beseitigen, indem Rollups ein dedizierter, reichlich vorhandener Datenkanal bereitgestellt wird, ohne jeden Node dazu zu zwingen, alles davon herunterzuladen.

EIP-4844: der erste Schritt, den du bereits gesehen hast

Bevor Danksharding existieren kann, hat Ethereum Proto-Danksharding ausgeliefert, formalisiert als EIP-4844, im März 2024. Das ist der Teil, den du vielleicht schon unter dem Namen Blobs kennst.

Ein Blob ist ein Datenblock, der an eine Transaktion angehängt ist, in einem separaten Gebührenmarkt lebt (oft Blob-Gas-Markt genannt) und nach etwa 18 Tagen automatisch aus der Chain entfernt wird. Nodes müssen Blob-Inhalte nicht ausführen; sie müssen sie nur vorübergehend speichern und nachweisen, dass sie veröffentlicht wurden. Rollups wie Arbitrum, Optimism und Base wechselten von der Veröffentlichung komprimierter Daten als Calldata zur Veröffentlichung als Blobs, wodurch Rollup-Transaktionen sofort um ein Mehrfaches günstiger wurden.

EIP-4844 ist der technische Kompromiss. Es ändert nicht, wie Ethereum Datenverfügbarkeit verifiziert. Es verlangt weiterhin, dass jeder Node jeden Blob vollständig herunterlädt, um zu bestätigen, dass der Block gültig ist. Das funktioniert bei wenigen Blobs pro Block, skaliert aber nicht auf die Volumina, die Danksharding vorsieht.

Betrachte Proto-Danksharding also als Auffahrt. Es führt das Blob-Transaktionsformat, den separaten Gebührenmarkt und die Konsensregeln ein, die künftiges Danksharding wiederverwenden wird. Vollständiges Danksharding entsteht, wenn Ethereum aufhört, jeden Node zum Herunterladen jedes Blobs zu zwingen, und stattdessen mit Sampling beginnt.

Was „data availability“ tatsächlich bedeutet

Die Formulierung „Daten sind verfügbar“ klingt selbstverständlich, hat in der Konsensforschung aber eine präzise Bedeutung. Ein Block ist datenverfügbar, wenn jeder ehrliche Node die zugrunde liegenden Daten tatsächlich abrufen kann, nicht nur den Header oder eine Verpflichtung darauf. Ohne diese Garantie könnte ein böswilliger Blockproduzent einen Block-Header veröffentlichen, der gültig aussieht, die dahinterliegenden Daten aber zurückhalten, und Full Nodes hätten keine Möglichkeit, Betrug zu erkennen oder die Chain zu rekonstruieren.

Das ist das Problem der data availability, und es gehört zu den schwierigeren Problemen bei der Skalierung von Blockchains. Deshalb können Light Clients bei Bitcoin die Chain nicht vollständig verifizieren: Sie laden Block-Header herunter, vertrauen aber darauf, dass jemand anderes die Blockkörper speichert. Wenn ein Miner jemals die Transaktionen eines Blocks zurückhält, kann ein Light Client das nicht erkennen.

Ethereum möchte Light Clients echte Verifikation statt Vertrauen geben. Dafür braucht es ein primitives Verfahren, mit dem ein Node bestätigen kann, dass ein großer Datensatz veröffentlicht wurde, ohne den Datensatz herunterzuladen. Data availability sampling ist dieses primitive Verfahren, und danksharding ist das Ethereum-spezifische Design, das es auf Konsensebene einsetzt.

Erasure Coding: die Mathematik, durch die Stichproben auf das Ganze schließen lassen

DAS funktioniert nur wegen Erasure Coding, einer Technik aus der Speicher- und Kommunikationstheorie. Das einfachste Denkmodell ist, sich vorzustellen, eine 1-MB-Datei in eine Tabelle zu schreiben und dann 1 MB redundanter Zeilen hinzuzufügen, die lineare Kombinationen der ursprünglichen Zellen sind. Nun hat man 2 MB, kann aber das ursprüngliche 1 MB aus beliebigen 1 MB der 2 MB rekonstruieren.

Beim danksharding machen Blockproduzenten mit Blob-Daten grob dasselbe. Sie erweitern die zugrunde liegenden Daten jedes Blobs um zusätzliche Paritäts-Chunks, die mit einem Code im Stil von Reed-Solomon berechnet werden. Dadurch verdoppelt sich die On-Chain-Größe im Austausch für eine starke Garantie: Wenn die Daten auch nur teilweise verfügbar sind, kann ein ehrlicher Node alles rekonstruieren.

Warum ist das für Sampling wichtig? Angenommen, ein Blockproduzent versucht, ein Viertel der erweiterten Daten zurückzuhalten, damit niemand sie rekonstruieren kann. Das lässt sich statistisch nicht verbergen, weil die Stichproben gleichmäßig zufällig über den erweiterten Datensatz ausgewählt werden. Ein Light Node, der zum Beispiel 30 zufällige Chunks erfolgreich herunterlädt und bestätigt, dass sie alle übereinstimmen, kann mathematisch sicher sein, mit einstellbarer Wahrscheinlichkeit, dass der vollständige Datensatz von jemandem rekonstruierbar ist.

Die zentrale Erkenntnis ist, dass Erasure Coding ein Problem des vollständigen Herunterladens in ein Problem zufälliger Stichprobenprüfungen verwandelt. Ohne Erasure Coding wäre Sampling nutzlos, weil ein böswilliger Produzent ein einzelnes gezielt ausgewähltes Byte zurückhalten könnte und keine Stichprobe es entdecken würde.

Wie data availability sampling auf einem Node tatsächlich abläuft

Im danksharding-Design werden die Daten der Chain konzeptionell als zweidimensionales Raster angeordnet. Jede Zeile entspricht den Blob-Daten eines Slots, und jede Spalte ist ein Streifen erweiterter Chunks. Ein Blockproduzent verpflichtet sich auf das gesamte Raster mithilfe von Polynomial Commitments, im aktuellen Plan KZG commitments, die wie ein kryptografischer Fingerabdruck wirken, der klein genug ist, um in einen Block-Header zu passen.

Light Nodes tun dann für jeden Slot Folgendes:

• Sie empfangen den Block-Header und die KZG commitments für die erweiterten Daten.
• Sie laden eine Handvoll zufälliger Zellen aus dem Raster herunter und fragen verschiedene Peers nach verschiedenen Positionen.
• Sie verifizieren jede heruntergeladene Zelle gegen ihr Commitment. Eine fehlerhafte Zelle fällt sofort durch die Prüfung.
• Mit jeder erfolgreichen Stichprobe erhöhen sie ihr Vertrauen, dass das vollständige Raster verfügbar ist.

Nach genügend erfolgreichen Stichproben behandelt der Light Node die Daten als verfügbar. Wenn der Blockproduzent versucht hätte, auch nur einen kleinen Teil des Rasters zurückzuhalten, schrumpft die Wahrscheinlichkeit, dass alle zufälligen Stichproben im ehrlichen Teil landen, exponentiell. Bei einigen Dutzend Stichproben wird die Ausfallwahrscheinlichkeit vernachlässigbar.

Das ist der Teil, der die Hardware-Anforderungen verändert. Ein Light Node muss kein leistungsstarker Server mit schneller SSD mehr sein. Er muss pro Slot nur etwas in der Größenordnung weniger Kilobyte herunterladen und diese Stichproben dann im Netzwerk weiterverbreiten. Dadurch bleiben Solo Stakers und Heim-Validatoren wettbewerbsfähig, was die Dezentralisierung bewahrt.

Die Risiken, über die niemand ehrlich spricht

Danksharding ist technisch elegant, bringt aber reale Fehlermodi mit sich. Eine ehrliche Darstellung muss sie ansprechen.

Das erste Risiko ist der Angriff durch Zurückhalten der data availability. Ein Blockproduzent könnte weiterhin versuchen, einen Header zu veröffentlichen und dann genug Zellen zurückzuhalten, sodass ehrliche Light Nodes keine erfolgreichen Stichproben ziehen. Wenn das Netzwerk nicht genügend Light Nodes hat, die redundant sampeln, kann ein Angreifer die Zufälligkeit so lange ausnutzen, bis genug Light Clients die verfügbaren Daten verpassen und den Block ablehnen, was zu einem Liveness-Fehler führt, bei dem die Chain ins Stocken gerät. Zu den Forschungsansätzen zur Minderung gehören mehrere Blockproduzenten pro Slot und die Pflicht für Light Nodes, zu warten, bis das Netzwerk Zeit hatte, Stichproben per Gossip zu verbreiten. Beides erhöht jedoch die Latenz.

Das zweite Risiko ist der Fehlermodus des Erasure Coding selbst. Wenn ein Bug oder Implementierungsfehler dazu führt, dass die Codierung zwischen Clients inkonsistent ist, könnten ehrliche Light Nodes gültige Blöcke ablehnen oder unverfügbare akzeptieren. Das ist ein Grund, warum das Design auf KZG commitments setzt, die nachweisen können, dass einzelne Zellen mit dem Header konsistent sind, und warum vor dem Mainnet-Einsatz umfangreiche Testnets betrieben werden, etwa Devnets wie das von Celestia inspirierte da-dedi und Arbeiten an EIP-7591.

Das dritte Risiko ist Zentralisierung rund um Infrastruktur. Selbst wenn die Anforderungen für einen Light Node auf dem Papier winzig sind, steigen die realen Anforderungen an einen Full Validator, also an diejenigen, die tatsächlich Blöcke vorschlagen und attestieren, weiter an. Wenn Solo Stakers aussteigen, weil Attestierungspflichten anspruchsvolle Hardware erfordern, wird das Netzwerk zentralisierter, unabhängig davon, wie günstig Light Clients sind.

Schließlich gibt es das soziale Risiko der Übertreibung. Die Formulierung „unbegrenzte Skalierbarkeit“ wird häufig mit DAS verbunden, und sie ist falsch. Erasure Coding verdoppelt den Daten-Footprint ungefähr, es gibt also echte Kosten. Sampling verifiziert nur Verfügbarkeit; es lässt das Netzwerk nicht auf magische Weise mehr Ausführung verarbeiten. Rollups bezahlen Ausführung weiterhin anderswo, und Durchsatzgrenzen bleiben bestehen, nur auf einem deutlich höheren Niveau als heute.

Warum Celestia, EigenDA und Avail ähnlich wirken

Ethereum ist nicht das einzige Team, das auf Data Availability Sampling setzt. Celestia startete Ende 2023 als eigenständige Blockchain, deren einzige Aufgabe es ist, eine Data-Availability-Schicht zu sein. Es nutzt dasselbe Rezept aus DAS und Erasure Coding: Daten werden in ein 2D-Raster codiert, Light Nodes prüfen zufällige Zellen per Stichprobe, und ein Commitment im KZG-Stil verankert das gesamte Raster.

Das Versprechen lautet, dass Rollups und App-Chains überhaupt nicht auf Ethereum leben müssen. Sie können ihre Daten an Celestia senden, Celestia-Gebühren zahlen und Ethereum oder jede andere Settlement-Schicht nur für Fraud Proofs oder Validity Proofs nutzen. Celestia positioniert sich eher als modularer Blockchain-Baustein denn als Smart-Contract-Plattform.

EigenDA hat eine andere Form. Es ist ein Data-Availability-Dienst, der auf EigenLayer aufbaut. EigenLayer ermöglicht es ETH-Stakern, sich freiwillig an der Absicherung zusätzlicher Dienste zu beteiligen, indem sie ihre Sicherheiten restaken. Der Anspruch von EigenDA ist, dass es die wirtschaftliche Sicherheit von Ethereum erbt, weil die Betreiber seines Speichernetzwerks auch Ethereum-Validatoren mit realem Slashing-Risiko sind.

Avail, ursprünglich aus Polygon hervorgegangen, geht einen dritten Weg: Es positioniert sich als Data-Availability-Schicht, die viele Chains bedienen kann, einschließlich Nicht-Ethereum-Chains, und nutzt ein anderes Polynomial-Commitment-Schema. Kate Commitments können ersetzt oder durch andere Designs ergänzt werden, um flexibel zu bleiben. Polygon selbst hat eine Polygon POS Chain ausgeliefert, die historisch einen anderen Ansatz nutzte, während neuere "Polygon CDK"-Rollups frei jede beliebige DA-Schicht wählen können.

Warum macht sich Ethereum die Mühe, eine eigene Lösung zu bauen? Aus zwei Gründen. Erstens möchte die Ethereum-Community DA-Sicherheit, die von ETH-Stakern getragen wird und nicht von einem separaten Token. Dadurch bleiben die Vertrauensannahmen eines Ethereum-Rollups innerhalb des Ethereum-Ökosystems. Zweitens ist Wettbewerb gesund. Dass Celestia existiert, zwingt die Ethereum-Forscher zur Auslieferung, und umgekehrt.

Was das für dich als Nutzer oder Builder bedeutet

Wenn du nur Transaktionen auf Ethereum oder auf einem Rollup ausführst, zeigt sich Danksharding vor allem in niedrigeren Gebühren. Sobald Blobs reichlich vorhanden und günstig sind, können Rollups größere Batches veröffentlichen und die Gas-Kosten weiter senken. Die genauen Zahlen hängen von der Dynamik des Blob-Gebührenmarkts und Verbesserungen bei der Rollup-Kompression ab, aber die Richtung ist klar: Rollup-Transaktionen, die bereits nur wenige Cent kosten, können bei hohen Blob-Zahlen auf Bruchteile eines Cents fallen.

Wenn du als Entwickler einen Rollup-Stack auswählst, ist die neue Entscheidung, welche DA-Schicht du nutzt. Zur Auswahl stehen jetzt Ethereum-nativ nach vollständigem Danksharding, Celestia, EigenDA und Avail, jeweils mit unterschiedlichen Annahmen zu Kosten, Sicherheit und Bridges. Ein Rollup auf Celestia ist nicht so eng an ETH-Staker gebunden, kann aber günstiger und flexibler sein. Ein Rollup auf EigenDA erbt die Sicherheit von restaked ETH, ist aber nur so dezentral wie das Operator-Set von EigenLayer. Nichts ist umsonst.

Wenn du Staker oder Home Validator bist, ist die praktische Botschaft eher beruhigend als alarmierend. Die Anforderungen an Light Clients bleiben niedrig, sodass die tägliche Hardware-Untergrenze nicht so sprunghaft steigt, wie sie es bei naiven Blockgrößenerhöhungen tun würde. Die Anforderungen an Attestations können dennoch steigen, aber in kontrollierterem Tempo, und Verbesserungen wie enshrined proposer-builder separation sollen die betriebliche Last reduzieren.

Was du nicht tun solltest, ist anzunehmen, Danksharding sei "fertig". Anfang 2026 befindet es sich noch auf Testnets, wobei EIP-7591, PeerDAS als Zwischenschritt, die kurzfristige Einführung darstellt und vollständiges Danksharding später folgt. Jeden Zeitplan als garantiert zu behandeln, ist ein Rezept für Enttäuschung.

Bleib der Ethereum-Scaling-Roadmap voraus

Danksharding, DAS, Blob-Gebühren und konkurrierende Data-Availability-Schichten entwickeln sich schnell, und glaubwürdige Berichterstattung ist über Research-Foren, EIP-Entwürfe und Core-Developer-Calls verstreut. Zippfeed bündelt Ethereum-Scaling-Schlagzeilen mit Sentiment-Scoring (bullish, neutral oder bearish) und einer Wichtigkeitsbewertung, damit du erkennen kannst, welche Protokoll-Meilensteine wirklich etwas bewegen und welche nur Reposts sind.