Data Availability Sampling erklärt: Wie DAS Blockchains skaliert

Warum Blockchains an einer Skalierungsgrenze scheitern

Jede Blockchain hat einen versteckten Engpass, der nichts mit Transaktionen pro Sekunde zu tun hat. Bevor ein Block als vertrauenswürdig gelten kann, muss jeder Knoten, dem Sicherheit wichtig ist, sichergehen, dass die darin enthaltenen Daten tatsächlich existieren und herunterladbar sind. Wenn ein Blockproduzent nur einen Block-Header veröffentlicht und die zugrunde liegenden Transaktionen verbirgt, kann niemand die Chain verifizieren, und ein bösartiger Proposer könnte theoretisch Gelder stehlen oder die Geschichte umschreiben.

Den größten Teil der Krypto-Geschichte galt eine einfache Regel: Um die Chain zu verifizieren, lade die Chain herunter. Bitcoin- und frühe Ethereum-Nutzer betrieben Full Nodes, die jedes Byte verarbeiteten. Das funktionierte in kleinem Maßstab, aber als die Blockgrößen wuchsen, um mehr Nutzer aufzunehmen, stiegen die Kosten für den Betrieb eines Knotens auf Hunderte von Gigabyte und schließlich Terabytes an Speicher und Bandbreite. Die Dezentralisierung erodierte still und leise, da nur noch gut ausgestattete Betreiber mithalten konnten.

Das Datenverfügbarkeitsproblem ist der formale Name für dieses Spannungsfeld. Eine Blockchain muss genügend Daten veröffentlichen, damit jeder sie verifizieren kann, aber zu viele Daten veröffentlichen schließt normale Nutzer von der Verifizierung aus. Skalierungslösungen wie Rollups verschärfen das Problem, statt es zu lösen, da sie komprimierte Transaktionsdaten zurück auf eine Parent Chain posten. Mehr Rollups, mehr Daten, und plötzlich erstickt die Parent Chain am eigenen Erfolg.

Das ist die Mauer, die DAS einreißen soll. Das Ziel ist nicht, jeden Knoten im trivialen Sinne weniger Daten herunterladen zu lassen, indem Transaktionen komprimiert werden. Das Ziel ist, Verifizierung so günstig zu machen, dass Light Clients, also Wallet-auf-dem-Laptop-Niveau, große Blöcke mit Zuversicht bestätigen können, während das Netzwerk als Ganzes weiterhin auf Zehntausende von Transaktionen pro Sekunde skalieren kann.

Was Light Clients vor DAS konnten und was nicht

Bevor es Sampling gab, führten Light Clients ein prekäres Dasein. Ein Light Client ist jeder Knoten, der nicht die vollständige Chain herunterlädt, sondern stattdessen Block-Header prüft und Full Nodes nach Beweisen für bestimmte Transaktionen fragt. Mobile Wallets, Browser-Erweiterungen und eingebettete Geräte verhalten sich in der Praxis alle wie Light Clients.

Der Haken ist, dass ein Light Client belogen werden kann. Eine kleine Gruppe von Full Nodes kann einem Light Client einen Header liefern, der gültig aussieht, sowie Beweise, die korrekt wirken, während die zugrunde liegenden Blockdaten dem Rest des Netzwerks tatsächlich vorenthalten werden. Der Light Client hat keine Möglichkeit, das zu erkennen, da er nie nach den vollständigen Daten gefragt hat. Dies ist der klassische Data Availability Attack, und genau deshalb wurden Light Clients jahrelang als Bürger zweiter Klasse behandelt, nützlich für Zahlungen, aber nicht für sicherheitskritische Entscheidungen.

Um dies zu beheben, brauchten Entwickler eine Möglichkeit, wie ein Light Client einen Beweis dafür verlangen kann, dass die Daten hinter einem Header tatsächlich irgendwo im Netzwerk existieren, ohne die Daten selbst herunterzuladen. Full Nodes zu fragen reicht nicht aus, da Full Nodes sich verschwören können. Jeden Full Node zu fragen kommt dem Herunterladen der Daten gleich. Es musste etwas Statistisches erfunden werden.

Die Grundidee: Zufallsstichproben als probabilistische Garantie

Data Availability Sampling beruht auf einer einzigen Intuition, die fast zu einfach klingt, um zu funktionieren. Wenn ein Block in viele kleine Stücke zerlegt wird und ein Light Client zufällig einige dieser Stücke überprüft, wird die Wahrscheinlichkeit, dass ein Angreifer auch nur ein einziges Stück versteckt, immer kleiner, je mehr Light Clients Stichproben ziehen.

Stellen Sie sich einen Block vor, der in 1.000 Teile zerlegt wurde. Ein Light Client wählt 10 zufällige Teile aus und fragt das Netzwerk danach. Wenn alle 10 zurückkommen, ist der Client noch nicht fertig. Er weiß nur, dass 10 Teile existieren. Aber multipliziert man das mit Millionen von Light Clients, die jeweils ihre eigenen zufälligen Teile auswählen, sinkt die Chance, dass ein verstecktes Teilstück all diese Anfragen überlebt, gegen null. Nach genügend unabhängigen Stichproben kann das Netzwerk den Block mit mathematischer Quasi-Gewissheit als verfügbar behandeln, obwohl kein einzelner Knoten das Ganze heruntergeladen hat.

Das ist die probabilistische Garantie, die im Kern von DAS steckt. Es ist kein Versprechen, dass jeder Knoten jedes Byte gesehen hat. Es ist ein Versprechen, dass die Daten existieren, über das Netzwerk verteilt sind und dass jeder Versuch, ein Stück zu verbergen, so viele zufällige Stichproben täuschen müsste, dass die Wahrscheinlichkeit, damit durchzukommen, praktisch null ist.

Erasure Coding: der Trick, der Sampling funktionieren lässt

Zufallsstichproben allein wären nicht genug. Wenn ein Block einfach in 1.000 rohe Teile zerlegt wird, muss ein Angreifer nur einen davon verbergen, um die Kette zu brechen, und die Chance, dass ein einzelner Light Client genau auf das versteckte Teilstück trifft, ist gering. Damit die Mathematik aufgeht, fügen Blockchains absichtlich Redundanz hinzu, mithilfe einer Technik namens Erasure Coding.

Das gängigste Verfahren ist die Reed-Solomon-Codierung, eine jahrzehntealte Fehlerkorrekturmethode, die ursprünglich für CDs und die Kommunikation im Weltraum entwickelt wurde. Die Idee besteht darin, die ursprünglichen Blockdaten als Polynom zu betrachten und dieses Polynom so zu erweitern, dass dieselben Informationen über mehr Datenpunkte codiert werden als ursprünglich. Bei einer Reed-Solomon-Codierung, die die Daten verdoppelt, wird aus einem Block mit 1.000 ursprünglichen Teilen ein erweiterter Block mit 2.000 Teilen, von denen beliebige 1.000 ausreichen, um das Ganze wiederherzustellen.

Warum das wichtig ist: Ein Angreifer, der Daten zurückhalten will, muss nun mindestens die Hälfte des erweiterten Blocks zurückhalten, nicht nur ein einziges Teilstück. Die Light Clients ziehen derweil weiterhin zufällig Stichproben aus dem erweiterten Satz. Die Wahrscheinlichkeit, ein verstecktes Teilstück zu übersehen, sinkt dramatisch, weil der Angreifer einen viel größeren Anteil verbergen muss. Die Kombination aus Erasure Coding und Zufallsstichproben verwandelt eine schwache Garantie in eine starke, und sie ist das technische Herzstück jedes DAS-Designs, das im Einsatz oder in ernsthafter Erprobung ist.

PeerDAS: Ethereens Peer-to-Peer-Weiterentwicklung von DAS

Der aktuelle Ansatz von Ethereum für DAS trägt den Namen PeerDAS, und der Name verweist auf den architektonischen Wandel. In einem naiven DAS-Design speichert jeder Full Node weiterhin den gesamten erweiterten Block. Sampling ist nur für Light Clients gedacht, und die Full Nodes tragen die Speicherlast. PeerDAS dreht das um. Bei PeerDAS werden die erweiterten Daten zusätzlich über das Peer-to-Peer-Netzwerk verteilt, sodass jeder Full Node nur einen Teil des gesamten Blob-Speicherplatzes speichert und die Daten bei Bedarf rekonstruiert werden, indem Peers nach ihren Anteilen gefragt werden.

Für Ethereum sind die relevanten Daten das, was es Blobs nennt, also die temporären Datenpakete, die Rollups kostengünstig einreichen. PeerDAS ermöglicht es Validators, nur einige wenige Spalten einer erasure-codierten Blob-Matrix zu speichern und trotzdem jede zufällige Stichprobe für das Netzwerk bereitstellen zu können. Die mathematische Garantie ist dieselbe wie beim klassischen DAS, aber der Ressourcenaufwand wird verteilt, sodass das Netzwerk die gesamte Blob-Kapazität erweitern kann, ohne die Anforderungen pro Knoten im selben Maße zu erhöhen.

Andere Ökosysteme nutzen dieselbe Idee unter anderen Namen. Celestia, oft über sein Ticker-Symbol TIA referenziert, war das erste produktive Netzwerk, das von Anfang an um DAS herum konzipiert war und sich selbst als modulare Data-Availability-Schicht versteht, auf der Rollups veröffentlichen können. NEAR hat DAS-ähnliche Designs im Rahmen seiner Sharding-Roadmap untersucht. In all diesen Fällen taucht dasselbe Muster auf: Daten per Erasure Coding codieren, zufällig Stichproben ziehen und der Wahrscheinlichkeit die Sicherheitsarbeit überlassen, die früher vollständige Replikation erfordert hätte.

Was das praktisch bedeutet: Zehntausende TPS

Sobald Data Availability günstig und beweisbar ist, wird der Rest der Skalierungsgeschichte möglich. Rollups, das vorherrschende Skalierungsmuster auf Ethereum und zunehmend auch auf anderen Chains, werden durch die Menge an Daten ausgebremst, die sie auf ihre Parent-Chain posten können. Wenn die Datenschicht der Parent-Chain wachsen kann, weil DAS die Überprüfung günstig macht, können Rollups mehr komprimierte Transaktionen pro Block posten, und der effektive Durchsatz steigt.

Die von Ethereum-Forschern genannten Zahlen, oft im Bereich von Zehntausenden Transaktionen pro Sekunde auf L2, hängen von dieser Art der Datenskalierung ab. Dieselbe Dynamik gilt für Celestia und für jede Chain, die eine modulare Architektur übernimmt, bei der Ausführung und Data Availability getrennt und unabhängig voneinander optimiert werden. Ohne DAS würden diese Durchsatzbehauptungen entweder eine Zentralisierung der Full Nodes oder das Vertrauen in ein kleines Data-Availability-Komitee erfordern, beides schlechte Kompromisse.

Es gibt auch einen leiseren Sekundäreffekt. Wenn Light Clients vertrauenswürdig werden, erweitert sich der Kreis der Geräte, die die Chain verifizieren können. Telefone, Browser und sogar eingebettete Hardware können an der Sicherheit teilnehmen. Das ist langfristig gut für die Dezentralisierung, weil es den Hebel großer Node-Betreiber verringert und das Netzwerk schwerer zu zensieren oder zu übernehmen macht.

Die ehrlichen Kompromisse, die du kennen solltest

DAS ist leistungsstark, aber es ist keine Magie, und seine Grenzen zu verstehen ist wichtiger, als sich seine Vorteile einzuprägen. Die probabilistische Garantie ist real, aber sie bleibt eine Wahrscheinlichkeit. Ein Light Client, der nur wenige Stichproben durchgeführt hat, ist nicht vollständig geschützt. Client-Implementierungen müssen die Anzahl der Stichproben sorgfältig wählen, und das Netzwerk muss davon ausgehen, dass jederzeit genügend unabhängige Light Clients online sind, damit die Mathematik aufgeht.

PeerDAS führt insbesondere neue Peer-to-Peer-Annahmen ein. Das System funktioniert nur, wenn ein ausreichend großer Anteil der Knoten online ist, um die zugewiesenen Slices bereitzustellen. Lange Netzwerkpartitionen, gezielte Denial-of-Service-Angriffe auf Peers oder schlicht eine schlechte Peer-Discovery können die Garantie schwächen. Es existieren Gegenmaßnahmen, darunter Peer-Scoring, Daten-Custody-Proofs und Fallback-Modi, aber sie sind aktive Forschungsbereiche und keine gelösten Probleme.

Es gibt auch wirtschaftliche Überlegungen. Mit wachsender Datenkapazität wird die Frage, wer für Speicher und Bandbreite bezahlt, drängender. Ethereum begegnet diesem Thema mit Blob-Gebühren, die mit der Zeit verbrannt werden, und Celestia verwendet ein ähnliches Modell. Keiner dieser Mechanismen ist perfekt, und sie entwickeln sich gemeinsam mit dem technischen Design weiter. Wer eine Chain bewertet, die DAS nutzt, sollte dem Gebührenmarkt und der Anreizstruktur genauso viel Aufmerksamkeit widmen wie den kryptografischen Behauptungen.

Wie du Data Availability Sampling auf smarte Weise verfolgst

Data Availability Sampling wandert von Forschungsarbeiten hin zu live betriebenen Netzwerken, und die Nachrichten rund um das Thema ändern sich wöchentlich. Ethereum-PeerDAS-Testnets, Celestia-Upgrades und konkurrierende Designs von NEAR und anderen erzeugen einen stetigen Strom an Ankündigungen, von denen viele in Hype verpackt sind. Herauszufinden, welche Änderungen real und welche Marketing sind, erfordert mehr als einen beiläufigen Twitter-Scroll. Zippfeed präsentiert Schlagzeilen zu Data Availability und Skalierung mit Sentiment-Scoring (bullish, neutral oder bearish) und einer Wichtigkeitsbewertung, damit du die technischen Meilensteine vom Rauschen unterscheiden kannst, ohne jeden Thread selbst lesen zu müssen.