Sharding

Die Idee hinter Sharding stammt aus der klassischen Datenbanktechnik, bei der ein großer Datensatz in kleinere Teile aufgeteilt wird, damit nicht eine einzige Maschine alles vorhalten oder verarbeiten muss. Auf Blockchains übertragen erlaubt Sharding einem Netzwerk, seine Validatoren, den State und die Transaktionshistorie auf separate Shards zu verteilen, die weitgehend parallel arbeiten, sodass der Durchsatz mit der Anzahl der Shards mitwächst, statt durch das begrenzt zu sein, was eine einzelne Maschine verifizieren kann.

Umsetzungen unterscheiden sich darin, wie weit sie dieses Prinzip treiben. Manche Netzwerke sharden nur den State und lassen Validatoren sich auf einen Teil davon spezialisieren, während sie sich weiterhin auf eine einzige kanonische Chain einigen; andere weisen ganze Untergruppen von Validatoren unabhängigen Shard-Chains zu, die sich periodisch bei einer zentralen Chain rückmelden. Cross-Shard-Transaktionen sind der schwierigste Teil: Eine Überweisung, die zwei Shards betrifft, muss meist in zwei Schritte aufgeteilt werden, wobei eine Nachricht oder ein "Receipt" zwischen den Shards weitergereicht wird, sobald die erste Hälfte bestätigt ist, was Latenz und Komplexität gegenüber einer Transaktion innerhalb eines einzelnen Shards hinzufügt.

Die Roadmap von Ethereum entfernte sich vom klassischen Execution-Sharding, sobald Layer 2-Rollups bewiesen, dass sie den Transaktionsdurchsatz schneller skalieren konnten; das aktuelle "Danksharding"-Design shardet die Datenverfügbarkeit für Rollups statt die eigentliche Ausführung. NEARs Nightshade und Zilliqa bleiben die klarsten Beispiele für Sharding, das direkt auf die Transaktionsverarbeitung angewendet wird.

Sharding bringt einen eigenen Sicherheitskompromiss mit sich: Ein Shard mit zu wenigen Validatoren lässt sich leichter angreifen, weshalb Protokolle Validatoren regelmäßig zwischen Shards neu mischen, damit keine einzelne Gruppe unbemerkt die Kontrolle über einen Shard erlangt.