Danksharding ist das Endziel der rollup-zentrierten Skalierungs-Roadmap von Ethereum: eine Neugestaltung der Datenschicht, die Data Availability Sampling nutzt, damit das Netzwerk deutlich mehr Blob-Daten für Layer 2 Rollups sicher veröffentlichen kann und L2-Gebühren schließlich um eine Größenordnung oder mehr sinken. Der erste Schritt, EIP-4844 "proto-danksharding", ist bereits live. Full danksharding mit Millionen von Blobs pro Slot liegt noch Jahre entfernt und ist nicht garantiert.
Auf einen Blick
- Danksharding ersetzt das traditionelle Shard-Chain-Modell von Ethereum durch eine einzige, einheitliche Schicht, in der Daten über viele Nodes verteilt und per Sampling verifiziert werden, nicht durch vollständiges Herunterladen.
- Proto-danksharding (EIP-4844) ist bereits live und fügt einen Blob-Gebührenmarkt hinzu. Full danksharding mit Data Availability Sampling ist darüber hinaus ein mehrjähriges Engineering-Projekt.
- Der für Nutzer sichtbare Nutzen sind günstige Gebühren auf Layer 2 Rollups, aber nur, wenn die neue Datenschicht tatsächlich skaliert und Rollups die Einsparungen weitergeben.
- Zu den realen Risiken gehören steigende Hardwareanforderungen für Validatoren, Zentralisierungsdruck auf große Staking-Betreiber und die schlichte Tatsache, dass sich die Roadmap verzögern oder neu zugeschnitten werden könnte.
Warum Ethereum überhaupt eine neue Datenschicht braucht
Der Blockspace von Ethereum ist absichtlich klein. Jeder Full Node im Netzwerk muss jede Transaktion herunterladen, speichern und verifizieren, und das Protokoll ist so abgestimmt, dass ein Verbraucher-Laptop mit Solid-State-Laufwerk mithalten kann. Genau diese Entscheidung macht Ethereum glaubwürdig neutral: Jede Person kann überall einen Node betreiben, die Chain selbst prüfen und sich weigern, einer zensierten oder ungültigen Historie zu folgen.
Das Problem ist der Durchsatz. Mit etwa 15 Millionen Gas pro Block und einem 12-Sekunden-Slot passt auf L1 selbst nur eine geringe Menge an Aktivität. Seit Jahren setzt die Community darauf, dass die meisten Nutzertransaktionen auf Layer 2 Rollups stattfinden, die Transaktionen von Nutzern bündeln und eine komprimierte Zusammenfassung zurück an Ethereum posten, wobei L1 als Settlement- und Data-Availability-Schicht dient.
Diese Wette geht nur auf, wenn das Posten von Daten auf L1 günstig ist. Im Jahr 2023, vor EIP-4844, wurden Rollup-Gebühren von Calldata-Kosten dominiert, und ein einzelner Swap auf einem beliebten L2 konnte in ausgelasteten Zeiten mehrere Dollar kosten. Um eine Kostenstruktur von Cents pro Swap zu erreichen, muss die Datenschicht selbst ungefähr um zwei Größenordnungen wachsen. Genau dafür ist danksharding gedacht: dieses Wachstum zu ermöglichen, ohne die Eigenschaft zu zerstören, dass ein Node auf einem Laptop laufen kann.
Wie sich danksharding von der alten Idee der "Shard Chains" unterscheidet
Während des größten Teils der Geschichte von Ethereum bestand der Konsens darin, dass Skalierung den Aufbau von 64 separaten Shard Chains bedeutet, von denen jede ihre eigenen Transaktionen parallel verarbeitet und die über Cross-Shard-Kommunikation miteinander verbunden werden. Dieser Plan hatte ernste Probleme: Er war komplex umzusetzen, für Anwendungsentwickler schwer zu durchdenken und ließ den größten Teil der Sicherheit und Komponierbarkeit ohnehin auf einer einzigen Chain.
Danksharding, benannt nach dem Forscher Dankrad Feist, verwirft den größten Teil davon. Statt 64 Execution Chains beizubehalten, behält Ethereum eine Execution Layer und macht die Consensus Layer zu einer Datenschicht mit hohem Durchsatz. Shards im ursprünglichen Sinn gibt es nicht. Stattdessen hängt das System große binäre Objekte, sogenannte Blobs, an jeden Block an, und ein separater Mechanismus namens Data Availability Sampling ermöglicht es Light Clients zu bestätigen, dass die Daten tatsächlich veröffentlicht wurden, ohne alles herunterzuladen.
Mit anderen Worten: "Sharding" in der Welt des danksharding bedeutet nicht, Execution aufzuteilen. Es bedeutet, die Aufgabe des Speicherns und Verifizierens von Blob-Daten auf viele Nodes zu verteilen, während die Chain selbst ein einziges, einheitliches Objekt bleibt. Das klingt nach einer kleinen Umbenennung, aber die technischen Folgen sind groß. Das Validator-Set muss nur eine Chain verifizieren, die Kommunikation zwischen Rollups bleibt einfach, und die Datenschicht kann mit derselben Mechanik nach oben oder unten skaliert werden.
Data Availability Sampling, ohne Mathematik erklärt
Der zentrale Trick hinter danksharding ist Data Availability Sampling (DAS). Die Grundidee stammt aus der Erasure Coding genannten Fehlerkorrektur, derselben Art von Mathematik, mit der ein Streaming-Video Paketverluste ausgleichen kann.
Hier ist die vereinfachte Version. Ein Block Producer nimmt die Blob-Daten für einen Slot und erweitert sie um redundante mathematische Teilstücke, sodass jede beliebige Hälfte der Teilstücke ausreicht, um das Ganze zu rekonstruieren. Diese erweiterten Daten werden dann über eine große Menge von Nodes verteilt. Jeder Light Client lädt nicht den vollständigen Blob herunter, sondern fordert zufällig einige kleine Teilstücke von zufälligen Peers an. Wenn jede Anfrage mit einem gültigen Teilstück beantwortet wird, kann der Client statistisch sehr sicher sein, dass die vollständigen Daten tatsächlich veröffentlicht wurden. Wenn ein böswilliger Block Producer versuchen würde, auch nur ein kleines Stück der Daten zu verbergen, würde das zufällige Sampling die Lücke mit sehr hoher Wahrscheinlichkeit entdecken.
Genau dieser Teil ermöglicht es Ethereum, Daten zu skalieren, ohne zugleich das zu skalieren, was jeder Node speichern muss. Ein Light Node mit begrenzter Bandbreite kann die Verfügbarkeit eines großen Blobs bestätigen, indem er zum Beispiel 16 Samples anfordert, während das Netzwerk als Ganzes die vollständigen Daten über viele Maschinen hinweg hält. Wenn die Datenmenge pro Block wächst, verlangt man nicht von jedem Node, mehr zu speichern, sondern vom Netzwerk, die Daten breiter zu verteilen und die Verifikation dem Sampling zu überlassen.
Der Haken ist, dass DAS nur funktioniert, wenn ein Peer-to-Peer-Netzwerk all diese Samples tatsächlich zuverlässig abrufen, per Gossip verbreiten und bereitstellen kann, und wenn die Kryptografie hinter dem Erasure Coding korrekt implementiert ist. PeerDAS, ein Übergangsdesign, das von der Ethereum Foundation erforscht wird, schwächt die Annahme ab: Es sampelt von Peers statt aus einem vollständig verteilten Datensatz. Das ist leichter bereitzustellen, bietet aber etwas schwächere Garantien. DAS auf dem Niveau von Full danksharding ist der spätere, schwierigere Schritt.
Von wenigen Blobs zu Millionen: die Durchsatzgeschichte
Zahlen helfen, das einzuordnen. Nach EIP-4844 wird das Proto-danksharding-Design mit einem Ziel von ungefähr 3 Blobs pro Block ausgeliefert, wobei jeder Blob etwa 125 Kilobyte groß ist. Das ergibt einige Hundert Kilobyte Blob-Daten pro Slot, was bereits eine deutliche Verbesserung gegenüber dem alten, ausschließlich auf Calldata basierenden Regime ist und der Hauptgrund dafür war, dass L2-Swap-Gebühren 2024 stark gefallen sind.
Full danksharding sieht ein deutlich aggressiveres Ziel vor. Die Roadmap weist derzeit auf 16 Megabyte Blob-Daten pro Slot hin, wobei 32 Blobs von jeweils ungefähr 500 Kilobyte ein häufig genannter Designpunkt sind. Hochgerechnet auf den Slot-Rhythmus von Ethereum liegt das in der Größenordnung von einer Million Blobs pro Tag, verglichen mit einigen Zehntausend heute. Layer 2 Rollups hätten theoretisch so viel günstigen Datenplatz zur Verfügung, dass ihre Gebühren auf nahezu die Kosten fallen würden, die tatsächlich für das Ausführen und Nachweisen der Transaktionen selbst anfallen.
Diese Zahlen sind keine Versprechen. Sie sind Designziele innerhalb einer Forschungsagenda. Das Team hat ausdrücklich gesagt, dass das Ziel für Full danksharding ein „Nordstern“ ist und dass Zwischenstufen, insbesondere PeerDAS, zuerst ausgeliefert werden und zeigen werden, ob die endgültigen Zahlen realistisch sind. Die ehrliche Einordnung lautet, dass der Blob-Durchsatz schrittweise steigen dürfte, wobei die größten Sprünge erst nach Jahren des Testens kommen.
Was das für Layer 2 Gebühren und Rollup-Ökonomie bedeutet
Der gesamte Zweck von danksharding besteht darin, L2-Gebühren zu senken, daher lohnt es sich, den Mechanismus konkret zu beschreiben. Ein Rollup wie Arbitrum, Optimism, Base oder zkSync veröffentlicht einen komprimierten Batch von Nutzertransaktionen auf Ethereum zusammen mit einem Proof. Vor 4844 lag dieser Batch in Calldata, das mit allen anderen L1-Transaktionen um Platz konkurrierte. Nach 4844 liegt er in Blobs, die einen separaten Gebührenmarkt haben und darauf ausgelegt wurden, günstig zu sein.
Bislang sind die Einsparungen real, aber ungleichmäßig. Bei ruhigen Netzwerkbedingungen kann ein L2-Swap bereits nur wenige Cent kosten. Bei Spitzennachfrage steigen die Gebühren weiterhin stark an, weil der Blob-Markt ein Ziel von 3 Blobs pro Block und ein Maximum von 6 hat, und die Nachfrage dieses kleine Angebot übersteigen kann. Full danksharding vergrößert dieses Angebot um Größenordnungen, was die Gebührenspitzen im schlechtesten Fall dämpfen und Rollups ermöglichen sollte, den Großteil der Einsparungen entweder als niedrigere Nutzergebühren oder als höhere Margen weiterzugeben.
Zwei Einschränkungen sind hier wichtig. Erstens sind Rollup-Gebühren eine Funktion des L1-Datenpreises, der eigenen Ausführungs- und Proving-Kosten des Rollups sowie des Gebührenmodells des Rollups. Ein Rollup kann sich dafür entscheiden, Gebühren stabil zu halten und die Dateneinsparungen als Gewinn mitzunehmen. Zweitens sind die Proof-Systeme für zk-rollups noch immer teuer im Betrieb, und bis diese Kosten sinken, wird die Untergrenze für L2-Gebühren durch das Proving bestimmt, nicht durch Data Availability. Danksharding verschiebt den dominierenden Kostenfaktor, aber es beseitigt nicht jeden Kostenfaktor.
Risiken: Hardware, Zentralisierung und Verzögerungen der Roadmap
Die Skalierung der Datenschicht ist nicht kostenlos, und die Kosten zeigen sich an drei unbequemen Stellen.
Die erste ist Validator-Hardware. Um an Full danksharding teilzunehmen, muss ein Validator größere Blöcke, mehr Netzwerkverkehr und in einigen Designs einen nicht trivialen Anteil an Blob-Daten verarbeiten. Die Ethereum-Community sagt ausdrücklich, dass dies ein bewusster Trade-off ist: Full Nodes können durch Sampling schlank bleiben, aber von Consensus Validatoren wird erwartet, dass ihre Anforderungen steigen. Das Risiko besteht darin, dass die Schwelle von „bequem auf einem Mittelklasse-Server“ zu „du willst wirklich eine dedizierte Maschine“ überschritten wird, wodurch Hobby-Staker nach und nach verdrängt werden.
Die zweite ist Zentralisierung. Die effizienteste Art, Blob-Speicherung und Sampling in großem Maßstab zu betreiben, ist ein professionelles Staking- und Datendienstleistungsunternehmen, was das Validator-Set in Richtung einer kleinen Zahl großer Betreiber wie Lido, Coinbase, Binance und einiger gut kapitalisierter Staking-Pools verschiebt. Wenn eine Mehrheit des Stakes in die Hände weniger Entitäten gelangt, werden die Eigenschaften der Zensurresistenz und glaubwürdigen Neutralität schwächer, die den Skalierungsplan ursprünglich motiviert haben. Danksharding verursacht diese Zentralisierung nicht allein, aber es verstärkt alle Zentralisierungsdrücke, die bereits bestehen.
Die dritte ist die einfachste: Die Roadmap könnte sich verzögern oder neu zugeschnitten werden. The 2022 Merge, das 2024er Dencun-Upgrade, das EIP-4844 ausgeliefert hat, und der Wechsel zu proof-of-stake lagen jeweils hinter frühen Zeitplänen zurück. Full danksharding ist nach der eigenen Beschreibung der Ethereum Foundation ein mehrjähriger Forschungs- und Engineering-Aufwand ohne festen Veröffentlichungstermin. PeerDAS ist der konkretere kurzfristige Schritt, und selbst dieser wird in Phasen eingeführt. Wer ein Produkt oder eine Investmentthese auf der Annahme aufbaut, dass „Full danksharding in 18 Monaten live sein wird“, stellt eine Vermutung an.
Zeitplan, Meilensteine und worauf man achten sollte
Die aktuelle Abfolge sieht nach den jüngsten Diskussionen zu Devnet und Protokoll-Roadmap so aus. Der erste Proto-Danksharding-Schritt, EIP-4844 mit einem kleinen Blob-Markt, ist bereits im Mainnet live. Der nächste Meilenstein ist eine Erhöhung des Blob-Durchsatzes, manchmal als "Blob-Parameter-Tuning" bezeichnet, bei der die Zielanzahl und die maximale Anzahl von Blobs pro Block erhöht werden, ohne die zugrunde liegende Kryptografie zu ändern. Danach arbeitet das Team auf PeerDAS hin, ein Design für teilweises Data Availability Sampling, das Validatoren ermöglicht, nur einen Bruchteil der Blob-Daten zu speichern und den Rest von Peers zu rekonstruieren.
Vollständiges DAS auf Danksharding-Niveau, mit 16-Megabyte-Blobs, dem vollständigen Sampling-Netzwerk und der dazugehörigen Neugestaltung des Peer-to-Peer-Systems, liegt weiter in der Zukunft. Realistische Schätzungen von Core-Forschern verorten es auf einem Zeithorizont von mehreren Jahren, wobei die Möglichkeit besteht, dass Zwischenstufen für einige Zeit die praktische Obergrenze darstellen.
Für alle, die diesen Bereich verfolgen, sind die wichtigen Signale nicht Kursbewegungen, sondern die übliche Mischung aus Spezifikationsdokumenten auf ethereum.org und in den Ethereum-Forschungsforen, die Aufnahme neuer EIPs in Devnets, die im Mainnet beobachteten Blob-Zahlen und das Gebührenverhalten sowie der Rhythmus von Hard Forks. Wenn Blob-Gebühren beim aktuellen Ziel häufig zu steigen beginnen, ist das ein Signal, dass ein Angebotsausbau überfällig ist. Wenn PeerDAS in ein öffentliches Testnet kommt, ist das ein Signal, dass die Sampling-Schicht konkret wird.
Wie man die Danksharding-Roadmap klug verfolgt
Danksharding wird in Teilen kommen, nicht als einzelner Schalter, und der häufigste Fehler besteht darin, jeden Schritt so zu behandeln, als wäre er bereits das Ganze. Das richtige Denkmodell ist, dass Proto-Danksharding das Datenebenen-Upgrade ist, für das man bereits bezahlt hat, PeerDAS das Datenebenen-Upgrade ist, das man wahrscheinlich als Nächstes bekommt, und vollständiges Danksharding ein Forschungsziel ist, dessen endgültige Form von den heute kursierenden Diagrammen abweichen kann. Zippfeed verfolgt Ethereum-Scaling-Nachrichten mit Sentiment-Bewertung (bullish, neutral oder bearish) und einer Wichtigkeitseinstufung, damit man echten Protokollfortschritt von Spekulation und Hype unterscheiden kann, während sich die Roadmap entfaltet.