Erinnerst du dich noch an die großen Versprechen von Ethereum Sharding? Jahrelang war es das Heilige Gral-Thema in der Blockchain-Community. Die Idee klang revolutionär: Zerlege die gesamte Ethereum-Blockchain in 64 kleinere Ketten, sogenannte Shards, und lasse sie Transaktionen parallel verarbeiten. Das Ziel? Von lächerlichen 15 bis 30 Transaktionen pro Sekunde (TPS) auf satte 100.000 TPS springen. Gasgebühren? Ein Ding der Vergangenheit. Aber hier ist die harte Realität im November 2026: Das ursprüngliche Konzept des vollständigen State-Shardings wurde weitgehend verworfen oder zumindest massiv umstrukturiert. Stattdessen hat sich Ethereum auf einen anderen Weg konzentriert - eine Strategie, die viele Entwickler als pragmatischer, aber auch komplexer empfinden.
Warum diese Änderung? Und was bedeutet "Danksharding" eigentlich für dich als Nutzer oder Entwickler? Wenn du erwartet hast, dass Ethereum plötzlich zu einer einzigen, monolithischen Super-Maschine wird, musst du deine Vorstellung anpassen. Die Zukunft der Skalierung liegt nicht allein in der Basis-Schicht (Layer 1), sondern in einem Zusammenspiel aus optimierten Datenverfügbarkeits-Sampling-Techniken und der massiven Auslagerung von Berechnungen auf Layer-2-Lösungen wie Rollups. Lass uns tief in die technische Architektur eintauchen, verstehen, warum der alte Plan gescheitert wäre, und schauen, was stattdessen implementiert wurde.
Was ist Sharding eigentlich - und warum war es so verlockend?
Um zu verstehen, warum Ethereum diesen Kurswechsel vollzogen hat, müssen wir kurz zurückspulen. Sharding ist eine Datenbank-Partitionierungstechnik, bei der eine große Datenbank in kleinere, verwaltbare Segmente unterteilt wird. In der Blockchain-Welt bedeutet das, dass nicht jeder Knoten jede Transaktion sehen und validieren muss. Stattdessen speichert jeder Shard nur einen Teil der Gesamtzustandsdaten.
Im ursprünglichen Ethereum 2.0 Roadmap-Design sah das so aus:
- Anzahl der Shards: Geplant waren exakt 64 separate Shard-Ketten.
- Unabhängiger Zustand: Jeder Shard hätte seinen eigenen Kontostand, Smart Contract Code und Transaktionshistorie gehabt.
- Validatoren-Zuweisung: Mindestens 128 Validatoren sollten pro Shard arbeiten, zufällig zugewiesen über die Beacon Chain.
- Durchsatz-Projektion: Theoretisch bis zu 100.000 TPS durch parallele Verarbeitung.
Klingt fantastisch, oder? Aber die Komplexität war enorm. Die größte Herausforderung war die "Cross-Shard Communication". Wie kommunizieren zwei Smart Contracts auf verschiedenen Shards miteinander? Wenn Alice auf Shard A Geld an Bob auf Shard B sendet, braucht man einen sicheren Mechanismus, um sicherzustellen, dass die Transaktion atomar ist - also entweder ganz oder gar nicht stattfindet. Ohne perfekte Synchronisation drohten Race Conditions und Sicherheitslücken.
Der Pivot: Vom State-Sharding zu Data-Sharding (Danksharding)
Hier kommt der entscheidende Wendepunkt ins Spiel. Die Ethereum-Core-Entwickler erkannten ein fundamentales Problem: Vollständiges State-Sharding ist extrem schwer zu implementieren, ohne die Dezentralisierung zu opfern. Wenn Knoten nur noch einen kleinen Teil der Daten halten, wird es schwieriger, neue Nodes schnell zu synchronisieren oder Light-Clients sicher zu betreiben. Außerdem verschob sich der Fokus der Community weg von "Alles in Layer 1 lösen" hin zu "Nutze Layer 2 für Berechnungen".
Anstatt die Blockchain in 64 unabhängige Rechenketten zu spalten, fokussierte man sich auf Danksharding - benannt nach dem Ethereum-Forscher Vitalik Buterin, dessen Spitzname "Dankrad" ist. Danksharding ist eine vereinfachte Form des Shardings, die sich primär auf die Skalierung der Datenverfügbarkeit konzentriert, nicht auf die parallele Ausführung von Smart Contracts in der Layer 1.
Die Logik dahinter ist clever:
- Berechnungen auslagern: Die eigentliche Arbeit (Transaktionsausführung, Zustandsänderungen) passiert auf Layer-2-Rollups (wie Arbitrum, Optimism oder zkSync).
- Daten sichern: Die Layer 1 (Ethereum Mainnet) dient hauptsächlich dazu, die komprimierten Daten dieser Rollups verfügbar zu machen und zu sichern.
- Verfügbarkeits-Sampling: Anstatt dass jeder Node alle Daten herunterladen muss, können Nodes stichprobenartig prüfen, ob die Daten vorhanden sind. Das reduziert den Bandbreitenbedarf drastisch.
Dieser Ansatz nennt sich oft "Data Sharding" im Gegensatz zum früheren "State Sharding". Er ist technisch einfacher zu erreichen und nutzt die Stärken von Zero-Knowledge Proofs und Optimistic Rollups besser aus.
Vergleich: Ursprüngliches Sharding vs. Aktuelle Strategie
Um die Unterschiede klar zu machen, hilft ein direkter Vergleich. Hier siehst du, wie sich die Anforderungen an die Netzwerkarchitektur verändert haben:
| Merkmale | Ursprüngliches Full Sharding (Alt) | Danksharding / L2 Centric (Aktuell) |
|---|---|---|
| Fokus | Parallele Ausführung von Smart Contracts | Skalierung der Datenverfügbarkeit |
| Architektur | 64 unabhängige Ketten mit eigenem State | Eine Hauptkette + viele Layer-2-Rollups |
| Cross-Shard Comms | Komplexe Protokolle nötig | Vereinfacht durch Sequencer in L2 |
| Node-Anforderungen | Niedriger Speicherbedarf pro Node | Mittlerer Bedarf, dank Sampling optimiert |
| Sicherheitsmodell | Abhängig von Validator-Verteilung je Shard | Gesamte Sicherheitsgarantie der L1 |
| Implementierungsstatus | Nie vollständig aktiviert | Teilweise aktiv (Proto-Danksharding/EIP-4844) |
Wie du siehst, ist der aktuelle Ansatz weniger "revolutionär" im Sinne einer kompletten Neuarchitektur, aber deutlich praktikabler. Die Einführung von EIP-4844 (auch bekannt als Proto-Danksharding) war ein großer Schritt in diese Richtung. Es führte "Blobs" ein - spezielle Datentypen, die günstiger gespeichert werden können als normale Kalldaten, aber nur temporär verfügbar sind. Das senkte die Kosten für Layer-2-Netzwerke erheblich.
Die Rolle der Beacon Chain und Validatoren
Auch wenn die ursprüngliche Vision von 64 voll funktionsfähigen Shards nicht eins zu eins umgesetzt wurde, bleibt die Beacon Chain das Herzstück der Konsensmechanik. Sie koordiniert die Validatoren und sorgt für die Sicherheit des gesamten Systems. Im aktuellen Modell gibt es keine separaten "Shard-Validatoren", die isoliert Blöcke produzieren. Stattdessen validieren alle aktiven ETH-Staker gemeinsam die Integrität der Daten, die von den Layer-2-Sequencern gepostet werden.
Das Sicherheitsmodell basiert weiterhin auf Zufälligkeit und wirtschaftlichen Anreizen:
- Zufällige Zuweisung: Validatoren werden pseudozufällig Aufgaben zugewiesen, um Manipulationen zu erschweren.
- Staking-Belohnungen: Wer korrekt validiert, erhält Belohnungen; wer Fehler macht, riskiert Slashing.
- Resilienz: Selbst wenn einige Nodes ausfallen, kann das Netzwerk dank der redundanten Datenhaltung auf L1 stabil bleiben.
Ein wichtiger Aspekt, den viele ignorieren: Die Sicherheit von Layer-2-Lösungen hängt direkt von der Verfügbarkeit der Daten auf Layer 1 ab. Wenn die Blob-Daten nicht verfügbar sind, können die Rollups ihre Zustände nicht rekonstruieren. Deshalb ist die Robustheit der Ethereum-Layer-1 immer noch kritisch, auch wenn die Berechnungen woanders stattfinden.
Warum NEAR Protocol anders tickt
Es lohnt sich, einen Blick auf andere Blockchains zu werfen, die Sharding tatsächlich implementiert haben. NEAR Protocol nutzt einen Ansatz namens Nightshade. Anders als beim alten Ethereum-Plan sind die Shards bei NEAR nicht völlig getrennte Universen. Jeder Block enthält Informationen über Transaktionen aus allen Shards, und jeder Validatorknoten trackt alle Shards. Das klingt ineffizienter, bietet aber eine viel einfachere Entwicklererfahrung, da Cross-Shard-Kommunikation fast nahtlos funktioniert.
Der Unterschied ist subtil, aber wichtig:
- Ethereum (L2-centric): Trennung von Berechnung (L2) und Datensicherung (L1). Höhere Skalierbarkeit, aber komplexere Benutzerbrücken.
- NEAR (Nightshade): Parallele Verarbeitung innerhalb einer einheitlichen Struktur. Einfachere Interoperabilität, aber potenziell höhere Hardware-Anforderungen für volle Nodes.
Keiner der Ansätze ist per se "besser". Ethereum setzt auf Modularität und Spezialisierung, NEAR auf integrierte Parallelität. Für Entwickler, die komplexe DeFi-Protokolle bauen, die stark voneinander abhängen, könnte NEARs Modell attraktiv sein. Für Anwendungen, die maximale Durchsätze brauchen und bereit sind, L2-Routing zu handhaben, gewinnt Ethereum.
Was kommt als Nächstes? Der Weg zur vollen Skalierung
Ist das Thema damit abgeschlossen? Nein. "Full Danksharding" ist immer noch in Entwicklung. Die nächste Phase sieht vor, die Anzahl der verfügbaren Blobs pro Block dynamisch anzupassen und die Sampling-Techniken weiter zu optimieren. Ziel ist es, die Kapazität für Datenverfügbarkeit exponentiell zu steigern, während die Kosten für die Speicherung sinken.
Für dich als Nutzer bedeutet das konkret:
- Gasgebühren auf L1 bleiben hoch, weil L1 knapp bemessene Ressourcen für Sicherheit und Datenspeicherung nutzt.
- Interaktionen finden auf L2 statt. Du wirst immer öfter Wallets nutzen, die automatisch zwischen L1 und L2 switchen.
- Entwickler müssen modular denken. Monolithische Apps weichen Microservices, die über verschiedene Rollups verteilt sind.
Die Ära des "alles auf einer Chain" ist vorbei. Willkommen in der Ära der modularen Blockchain-Architektur.
Wurde Ethereum Sharding jemals vollständig implementiert?
Nein, das ursprüngliche Konzept des "State-Shardings" mit 64 unabhängigen Ketten wurde nie vollständig aktiviert. Stattdessen hat Ethereum auf einen datenzentrierten Ansatz (Danksharding) umgeschwenkt, der sich auf die Skalierung der Datenverfügbarkeit für Layer-2-Lösungen konzentriert.
Was ist der Unterschied zwischen State-Sharding und Data-Sharding?
State-Sharding teilt die Blockchain in Segmente auf, die jeweils eigene Kontostände und Smart Contracts verwalten. Data-Sharding (wie bei Danksharding) teilt nur die Rohdatenspeicherung auf, während die eigentliche Berechnung und Zustandsverwaltung auf Layer-2-Ebene stattfindet.
Hat Sharding die Gasgebühren auf Ethereum gesenkt?
Indirekt ja, aber nicht direkt auf der Layer 1. Durch die Einführung von Proto-Danksharding (EIP-4844) wurden die Kosten für Layer-2-Netzwerke (Rollups) drastisch gesenkt. Da die meisten Nutzer heute auf L2 interagieren, sind ihre tatsächlichen Gebühren viel niedriger, auch wenn die L1-Gebühren selbst volatil bleiben.
Ist Ethereum Sharding sicher?
Ja, das aktuelle Modell gilt als sehr sicher. Da die gesamte Sicherheitsgarantie der Ethereum-Layer-1 genutzt wird, um die Daten der Layer-2-Lösungen zu sichern, erben diese die hohe Resilienz des Proof-of-Stake-Konsenses. Angriffe auf einzelne Shards sind im neuen Modell weniger relevant, da die Validatoren global agieren.
Warum hat Ethereum die Sharding-Pläne geändert?
Die Implementierung von vollem State-Sharding war technisch extrem komplex und riskant. Gleichzeitig entwickelten sich Layer-2-Lösungen (Rollups) schneller als erwartet. Die Community entschied, dass es effizienter ist, L2 zu skalieren und L1 als sichere Datensicherungsschicht zu nutzen, statt alles in L1 zu versuchen.
