Ein Leitfaden zum Blockchain-Sharding, Teil 1
Dieser Blog-Beitrag ist der erste in einer Serie von zwei Beiträgen zum Blockchain Sharding. Nachdem Du diesen Blog-Beitrag gelesen hast, weißt Du, warum Sharding der Weg zu zukunftssicheren Blockchain-Protokollen ist, wie Sharding heute aufgebaut wird, welchen Herausforderungen alle geshardeten Protokolle gegenüberstehen und wie solche Herausforderungen angegangen werden können. Der zweite Beitrag befasst sich mit fortgeschrittenen Themen wie Datenverfügbarkeit, Datengültigkeit und der Manipulation von Shards. “Shard” heißt auf Deutsch “Scherbe”.
Um im Einklang mit den englischen Begriffen im Blockchain-Bereich zu bleiben und seltsam klingende Übersetzungen zu vermeiden, werden wir im Folgenden teilweise englische Namen ins Deutsche übernehmen. Wir sprechen zum Beispiel von “Shards”, anstatt von “Scherben” und von “Chain” anstatt von der “Kette”.
Es ist bekannt, dass Ethereum, die zum Zeitpunkt des Schreibens am häufigsten verwendete Blockchain für allgemeine Zwecke, nur weniger als 20 Transaktionen pro Sekunde in der Haupt-Blockchain verarbeiten kann. Diese Einschränkung führt zusammen mit der Popularität des Netzwerks zu hohen Gaspreisen und langen Bestätigungszeiten (Als “Gas”, zu Deutsch “Treibstoff”, werden die Kosten für die Ausführung einer Transaktion im Netzwerk bezeichnet) . Trotz der Tatsache, dass zum Zeitpunkt dieses Schreibens ungefähr alle 10–20 Sekunden ein neuer Block erstellt wird, beträgt die durchschnittliche Zeit, die tatsächlich benötigt wird, um eine Transaktion zur Blockchain hinzuzufügen, laut ETH Gas Station 1,2 Minuten. Aufgrund des geringen Durchsatzes, der hohen Preise und der hohen Latenz ist Ethereum nicht für die Ausführung von Diensten geeignet, die mit der Mainstream-Adoption des Blockchain Bereichs skalieren werden.
Was ist der Hauptgrund für den geringen Durchsatz von Ethereum? Der Grund ist, dass jeder Knoten im Netzwerk jede einzelne Transaktion verarbeiten muss. Entwickler haben viele Lösungen vorgeschlagen, um das Problem des Durchsatzes auf Protokollebene anzugehen. Diese Lösungen lassen sich größtenteils in Lösungen unterteilen, bei denen die gesamte Berechnung an eine kleine Gruppe leistungsstarker Knoten delegiert wird, und Lösungen, bei denen jeder Knoten im Netzwerk nur einen Teil des gesamten Arbeitsaufwands erledigt. Ein Extremfall des ersten Ansatzes ist Thunder, bei dem ein einziger Knoten alle Transaktionen verarbeitet, um 1200 tx/sec (Transaktionen pro Sekunde) zu erreichen, was eine 100-fache Verbesserung gegenüber Ethereum darstellt (ich unterstütze Thunder jedoch nicht und bestätige nicht die Gültigkeit ihrer Behauptungen). Algorand, SpaceMesh und Solana lassen sich alle in die erste Kategorie einordnen und verbessern den Konsens und die Struktur der Blockchain selbst, um deutlich mehr Transaktionen auszuführen. Sie sind jedoch weiterhin an die Leistungsfähigkeit einer einzelnen (wenn auch sehr leistungsstarken) Maschine gebunden.
Der letztere Ansatz, bei dem die Arbeit auf alle beteiligten Knoten aufgeteilt wird, wird als Sharding bezeichnet. Auf diese Weise plant die Ethereum Foundation derzeit die Skalierung von Ethereum. Zum Zeitpunkt des Schreibens dieses Artikels ist die vollständige Spezifikation noch nicht veröffentlicht. Ich habe einen detaillierten Überblick über Ethereum-Shard-Chains und einen Vergleich ihres “Beacon-Chain-Konsenses” (zu Deutsch etwa Leuchtfeuer-Ketten-Konsens”) mit Nears geschrieben.
Das Near Protocol baut auf der Sharding-Technologie auf. Das Near-Team besteht aus drei ehemaligen MemSQL-Ingenieuren, die für den Aufbau von Sharding-, Cross-Shard-Transaktionen und verteilten JOINs verantwortlich sind, sowie fünf ehemaligen Googlern und verfügt über umfassende Branchenkenntnisse beim Aufbau verteilter Systeme.
In diesem Beitrag fasse ich die Kernideen des Blockchain-Shardings zusammen, auf denen Near und die Mehrheit der anderen geshardeten Protokolle basieren. Der zweite Beitrag dieser Serie beschreibt fortgeschrittenere Themen im Bereich des Shardings.
Das einfachste Sharding, auch bekannt als beanstalk (“Bohnenstangen-Sharding”)
Beginnen wir mit dem einfachsten Ansatz zum Sharding, den wir in diesem Artikel als Beanstalk bezeichnen. Diesen Ansatz nennt Vitalik in dieser Präsentation auch “scaling by a thousand altcoins” (“Skalieren mit 1000 Altcoins”. Als Altcoins werden alle Krypto-Münzen außer Bitcoin bezeichnet)
Bei diesem Ansatz führen wir statt einer Blockchain mehrere aus und bezeichnen jede einzelne Blockchain als “Shard” (Deutsch “Scherbe”). Jeder Shard hat einen eigenen Satz von Validierern. Hier und im Folgenden wird der allgemeine Begriff „Validierer“ verwendet, um Teilnehmer zu bezeichnen, die Transaktionen überprüfen und Blöcke erstellen. Entweder durch Mining, z. B. im “Proof of Work”-Konsens-Algorithmus, oder über einen abstimmungsbasierten Mechanismus. Nehmen wir zunächst an, dass die Shards niemals miteinander kommunizieren.
Das Beanstalk-Design ist zwar einfach, reicht jedoch aus, um einige große Herausforderungen beim Sharding aufzuzeigen.
Das Aufteilen von Validierern und Beacon-Chains
Die erste Herausforderung besteht darin, dass jeder Shard mit seinen eigenen Validierern zehnmal weniger sicher ist als die gesamte Blockchain. Wenn sich also eine Blockchain mit X-Validierern dazu entschließt, eine geshardete Blockchain zu bilden, und X-Validierer auf 10 Shards aufteilt, verfügt jeder Shard jetzt nur über X/10-Validierer, und für die Manipulation eines Shards sind nur 5,1% (51% /10) der Gesamtzahl der Validierer erforderlich.
Was uns zum zweiten Punkt bringt: Wer wählt die Validierer für jeden Shard aus? Die Kontrolle von 5,1% der Validierer ist nur dann schädlich, wenn sich alle diese 5,1% der Validierer im selben Shard befinden. Wenn Validierer nicht auswählen können, in welchem Shard sie validieren, ist es sehr unwahrscheinlich, dass ein Teilnehmer, der 5,1% der Validierer kontrolliert, alle seiner Validierer in demselben Shard hat. Das schränkt die Fähigkeit, das System zu gefährden, stark ein.
Fast alle heutigen Sharding-Konzepte beruhen auf einer Zufallsquelle, um den Shards Validierer zuzuweisen. Zufälle im Zusammenhang mit Blockchains ist an sich ein sehr herausforderndes Thema und würde zu einem späteren Zeitpunkt einen separaten Blog-Beitrag verdienen. Nehmen wir vorerst an, dass es eine Quelle für Zufälle gibt, die wir nutzen können.
Sowohl die Zufälligkeit als auch die Zuweisung der Prüfer erfordern eine Berechnung, die für keinen bestimmten Shard spezifisch ist. Für diese Berechnung verfügen praktisch alle vorhandenen Entwürfe über eine separate Blockchain, die für die Durchführung der für die Wartung des gesamten Netzwerks erforderlichen Vorgänge zuständig ist. Neben der Generierung von Zufallszahlen und der Zuweisung von Validierern zu den Shards gehören zu diesen Vorgängen häufig auch das Empfangen von Aktualisierungen von Shards und das Erstellen von Momentaufnahmen. Außerdem das Verarbeiten von Einsätzen der Validierer (den “stakes”, also deren hinterlegtem Pfand), das Aufteilen in Proof-of-Stake-Systeme sowie die regelmäßige Umverteilung von Validierern in die Shards, wenn diese Funktion unterstützt wird. Eine solche Blockchain wird in Ethereum und Near als Beacon-Chain (Deutsch “Leuchtfeuer-Kette”), in PolkaDot als “Relay-Kette” und in Cosmos als “Cosmos Hub” bezeichnet.
In diesem Beitrag werden wir solche Chains als Beacon-Chain bezeichnen. Die Existenz der Beacon-Chain bringt uns zum nächsten interessanten Thema, dem quadratischen Sharding.
Quadratisches Sharding
Sharding wird häufig als eine Lösung beworben, die sich unbegrenzt an die Anzahl der am Netzwerkbetrieb beteiligten Knoten anpasst. Obwohl es theoretisch möglich ist, eine solche Sharding-Lösung zu entwerfen, ist jede Lösung mit dem Konzept einer Beacon-Chain nicht unendlich skalierbar. Um zu verstehen warum, muss beachtet werden, dass die Beacon-Chain einige Buchhaltungsaufgaben ausführen muss, z. B. das Zuweisen von Validierern zu Shards oder das Erstellen von Momentaufnahmen von Blöcken der geshardeten Chains, die proportional zur Anzahl der Shards im System sind. Da die Beacon-Chain selbst eine einzelne Blockchain ist, deren Berechnung durch die Rechenleistung der Knoten, die sie betreiben, begrenzt ist, ist die Anzahl der Shards natürlich begrenzt.
Die Struktur eines geshardeten Netzwerks bewirkt jedoch einen multiplikativen Effekt der Verbesserungen seiner Knoten. Betrachten wir einmal einen Fall, in dem die Effizienz der Knoten im Netzwerk aus irgendeinem Grund verbessert wird.
Wenn die Knoten, die das Netzwerk betreiben, einschließlich der Knoten in der Beacon-Chain, viermal schneller werden, kann jeder Shard viermal mehr Transaktionen verarbeiten, und die Beacon-Chain kann viermal mehr Shards verwalten. Der Durchsatz im gesamten System erhöht sich um den Faktor 4 x 4 = 16 — daher der Name “quadratisches Sharding”.
Es ist schwierig, genau zu messen, wie viele Shards heute realisierbar sind, aber es ist unwahrscheinlich, dass die Anforderungen an den Durchsatz von Blockchains in absehbarer Zukunft über die Grenzen des quadratischen Shardings hinausgehen werden. Die bloße Anzahl von Knoten, die erforderlich wäre, um eine Beacon-Chain zu überfordern, ist um Größenordnungen höher als die Anzahl an Knoten, die alle Blockchains heutzutage zusammen betreiben.
Wenn wir jedoch zukunftssichere Protokolle erstellen möchten, lohnt es sich möglicherweise, bereits heute nach Lösungen für dieses Problem zu suchen. Der derzeit am weitesten entwickelte Vorschlag ist das exponentielle Sharding, bei dem Shards selbst einen Baum bilden und jeder übergeordnete Shard eine Reihe von untergeordneten Shards orchestriert, während er selbst ein Kind eines anderen Shards sein kann.
Es ist bekannt, dass Vlad Zamfir an einem Sharding-Konzept arbeitet, bei dem es sich nicht um eine Beacon-Chain handelt. Ich habe mit ihm an einem der Prototypen gearbeitet, dessen detaillierte Übersicht hier zu finden ist.
State Sharding
Bisher haben wir nicht genau definiert, was aufgeteilt ist und was nicht, wenn ein Netzwerk in Shards unterteilt ist. Insbesondere führen Knoten in der Blockchain drei wichtige Aufgaben aus: Erstens verarbeiten sie nicht nur Transaktionen, sondern leiten zweitens auch validierte Transaktionen und abgeschlossene Blöcke an andere Knoten weiter und drittens, sie speichern den Status und den Verlauf des gesamten Netzwerks. Jede dieser drei Aufgaben stellt wachsende Anforderungen an die Knoten, die das Netzwerk betreiben:
- Die Notwendigkeit, Transaktionen zu verarbeiten, erfordert mehr Rechenleistung mit einer erhöhten Anzahl von Transaktionen, die verarbeitet werden.
- Die Notwendigkeit, Transaktionen und Blöcke weiterzuleiten, erfordert eine größere Netzwerkbandbreite, da mehr Transaktionen weitergeleitet werden.
- Die Notwendigkeit, Daten zu speichern, erfordert mehr Speicher, wenn die Blockchain und damit der Speicherbedarf (oder“state”, die gesamte Historie einer Blockchain) wächst. Im Gegensatz zur Rechenleistung und zum Netzwerk steigt der state auch dann, wenn die Transaktionsrate (Anzahl der pro Sekunde verarbeiteten Transaktionen) konstant bleibt.
Aus der obigen Liste geht möglicherweise hervor, dass der Speicherbedarf am dringendsten ist, da er als einziger im Laufe der Zeit erhöht wird, auch wenn sich die Anzahl der Transaktionen pro Sekunde nicht ändert. Der dringendste Bedarf jedoch ist heute in der Praxis allerdings die Rechenleistung. Der gesamte Speicherbedarf von Ethereum beträgt zum Zeitpunkt dieser Veröffentlichung etwas mehr als 100 GB und kann von den meisten Knoten problemlos verwaltet werden. Die Anzahl der Transaktionen, die Ethereum verarbeiten kann, liegt jedoch bei etwa 20, Größenordnungen weniger als für viele praktische Anwendungsfälle erforderlich.
Zilliqa ist das bekannteste Projekt, das die Verarbeitung, aber nicht die Speicherung aufteilt. Das Sharding der Verarbeitung ist ein einfacheres Problem, da jeder Knoten den gesamten state hat, was bedeutet, dass Verträge, die auf der Blockchain ablaufen, andere Verträge frei aufrufen und alle Daten aus der Blockchain lesen können. Sorgfältige Entwicklung ist erforderlich, um sicherzustellen, dass Aktualisierungen von mehreren Shards, die dieselben Teile des states aktualisieren, keine Konflikte verursachen. In dieser Hinsicht verfolgt Zilliqa einen sehr simplen Ansatz, den ich in diesem Beitrag analysiere.
Es wurde zwar vorgeschlagen, den Speicher ohne die Verarbeitung zu sharden, aber es ist mir kein Projekt bekannt, das daran arbeitet. In der Praxis bedeutet Sharding des Speichers oder “State Sharding” fast immer Sharding der Verarbeitung und Sharding des Netzwerks.
Praktischerweise erstellen die Knoten in jedem Shard beim State Sharding eine eigene Blockchain, die Transaktionen enthält, die nur den lokalen Teil des globalen Status betreffen, der diesem Shard zugewiesen ist. Daher müssen die Validierer im Shard nur ihren lokalen Teil des globalen Zustands speichern und nur Transaktionen ausführen und als solche nur weiterleiten, die sich auf ihren Teil des Zustands auswirken. Diese Partition reduziert linear den Bedarf an Rechenleistung, Speicher und Netzwerkbandbreite, bringt jedoch neue Probleme mit sich, wie z. B. Datenverfügbarkeit und Cross-Shard-Transaktionen (Shard übergreifende Transaktionen), auf die im Folgenden eingegangen wird.
Cross-Shard-Transaktionen
Beanstalk als Modell ist kein sehr nützlicher Ansatz für das Sharding, da einzelne Shards, die nicht miteinander kommunizieren können, nicht besser sind als mehrere unabhängige Blockchains. Selbst heute, wo Sharding noch nicht großflächig verfügbar ist, besteht eine enorme Nachfrage nach Interoperabilität zwischen verschiedenen Blockchains.
Betrachten wir vorerst nur einfache Zahlungsvorgänge, bei denen jeder Teilnehmer auf genau einem Shard ein Konto hat. Wenn Sie innerhalb eines Shards Geld von einem Konto auf ein anderes überweisen möchten, kann die Transaktion vollständig von den Validierern in diesem Shard verarbeitet werden. Wenn Alice, mit Konto auf Shard # 1, Geld an Bob senden möchte, der sein Konto auf Shard # 2 hat, können weder Validierer auf Shard # 1 (sie können Bobs Konto nicht gutschreiben) noch die Prüfer auf Shard # 2 ( Sie können nicht von Alice’s Konto abbuchen.) die gesamte Transaktion abwickeln.
Es gibt zwei Arten von Ansätzen für Cross-Shard- (oder Shard übergreifenden) Transaktionen:
- Synchron: Immer wenn eine Shard übergreifende Transaktion ausgeführt werden muss, werden die Blöcke in den Shards, die einen Statusübergang in Bezug auf die Transaktion enthalten, alle gleichzeitig erstellt, und die Validierer mehrerer Shards arbeiten bei der Ausführung solcher Transaktionen zusammen. Der detaillierteste mir bekannte Vorschlag ist Merge Blocks, der hier beschrieben wird.
- Asynchron: Eine Shard übergreifende Transaktion, die mehrere Shards betrifft, wird in diesen Shards asynchron ausgeführt, wobei der “Credit”-Shard (der Shard, der die Zahlung erhält) seine Hälfte ausführt, sobald ausreichend Beweise dafür vorliegen, dass der “Debit”-Shard (der Shard, von dem die Zahlung ausgeht) seinen Teil ausgeführt hat. Dieser Ansatz ist aufgrund seiner Einfachheit und einfachen Koordination tendenziell häufiger anzutreffen. Dieses System wird heute in Cosmos, Ethereum Serenity, Near, Kadena und anderen vorgeschlagen. Ein Problem bei diesem Ansatz besteht darin, dass die Wahrscheinlichkeit, dass einer der mehreren Blöcke verwaist wird, ungleich Null ist, wenn Blöcke unabhängig erstellt werden, sodass die Transaktion nur teilweise angewendet wird. Betrachten Sie die folgende Abbildung, in der zwei Shards dargestellt sind, die beide auf eine Verzweigung gestoßen sind, und eine Shard übergreifende Transaktion, die entsprechend in den Blöcken A und X’ aufgezeichnet wurde. Wenn die Chains A-B und V’-X’-Y’-Z’ in den entsprechenden Shards kanonisch sind, ist die Transaktion vollständig abgeschlossen. Wenn A’-B’-C’-D’ und V-X kanonisch werden, wird die Transaktion vollständig abgebrochen, was akzeptabel ist. Wenn jedoch beispielsweise A-B und V-X kanonisch werden, wird ein Teil der Transaktion abgeschlossen und einer abgebrochen, was zu einem Fehler (“atomicity failure”) führt. Wir werden im zweiten Teil dieser Serie darauf eingehen, wie dieses Problem in den vorgeschlagenen Protokollen angegangen wird, wenn Änderungen an den Gabelungs-Bedingungs-Regeln und den für geshardete Protokolle vorgeschlagenen Konsens-Algorithmen behandelt werden.
Dabei muss beachtet werden, dass die Kommunikation zwischen Chains auch außerhalb von Blockchains nützlich ist. Die Interoperabilität zwischen Chains ist ein komplexes Problem und viele Projekte versuchen, es zu lösen. Bei Blockchains mit Shards ist das Problem etwas einfacher, da die Struktur der Blöcke und der Konsens auf allen Shards gleich sind und es eine Beacon-Chain gibt, die zur Koordination verwendet werden kann. In einer geshardeten Blockchain sind jedoch alle Chains gleich, während es im globalen Blockchain-Ökosystem viele verschiedene Blockchains mit unterschiedlichen Anwendungsfällen, Dezentralisierungs- und Datenschutzgarantien gibt.
Der Aufbau eines Systems, in dem eine Reihe von Chains unterschiedliche Eigenschaften aufweisen, jedoch einen hinreichend ähnlichen Konsens und eine Blockstruktur verwenden und eine gemeinsame Beacon-Chain haben, könnte ein Ökosystem heterogener Blockchains mit einem funktionierenden Interoperabilitätssubsystem ermöglichen. Es ist unwahrscheinlich, dass ein solches System eine regelmäßige Umverteilung der Validierer aufweist, daher müssen einige zusätzliche Maßnahmen ergriffen werden, um die Sicherheit zu gewährleisten. Sowohl Cosmos als auch PolkaDot sind solche Systeme. Dieser Artikel von Zaki Manian von Cosmos bietet einen detaillierten Überblick und einen Vergleich der wichtigsten Aspekte der beiden Projekte.
Bösartiges Verhalten
Du hast jetzt ein gutes Verständnis dafür, wie Sharding implementiert wird, einschließlich der Konzepte der Beacon-Chain, Umverteilung der Validierer und Shard übergreifenden Transaktionen.
Bei all diesen Informationen ist noch eine letzte wichtige Sache zu beachten. Insbesondere, welches schädliche Verhalten böswillige Validierer an den Tag legen können.
Bösartige Forks (eine Fork ist die Gabelung einer Blockchain)
Möglicherweise versuchen mehrere böswillige Validierer, eine Gabelung zu erzwingen. Dabei spielt es keine Rolle spielt, ob der zugrunde liegende Konsens BFT (Byzantine Fault Tolerant) ist oder nicht. Wenn es eine ausreichende Anzahl von bösartigen Validierern gibt, ist es immer möglich, eine Fork zu erstellen.
Es ist signifikant wahrscheinlicher, dass mehr als 50% eines einzelnen Shards korrupt werden, als dass mehr als 50% des gesamten Netzwerks bösartig werden (wir werden uns im zweiten Teil eingehender mit diesen Wahrscheinlichkeiten befassen). Wie oben erläutert, beinhalten Shard übergreifende Transaktionen bestimmte Zustandsänderungen in mehreren Shards, und die entsprechenden Blöcke in solchen Shards, die solche Zustandsänderungen anwenden, müssen entweder alle abgeschlossen sein (d.h. in den ausgewählten Chains auf ihren entsprechenden Shards erscheinen) oder alle verwaist sein (d.h. nicht in den ausgewählten Chains auf den entsprechenden Shards erscheinen). Da die Wahrscheinlichkeit, dass ganze Shards durch böswillige Validierer übernommen werden, im Allgemeinen nicht zu vernachlässigen ist, können wir nicht davon ausgehen, dass die Forks auch dann nicht vorkommen, wenn unter den Validierern des Shards ein byzantinischer Konsens erzielt wurde oder beim Zustandswechsel viele Blöcke aufbauend auf dem Block erzeugt wurden.
Für dieses Problem gibt es mehrere Lösungen. Die am häufigsten angewendete ist das gelegentliche Vernetzen des neuesten Blocks der geshardeten Chains mit der Beacon-Chain. Die Regeln zur Gabelung in den geshardeten Chains wird dann dahingehend geändert, dass immer die Kette zu bevorzugen ist, die vernetzt ist, und die Shard-spezifischen Regeln zur Auswahl der Chain nach einer Gabelung nur für Blöcke anzuwenden, die seit der letzten Vernetzung veröffentlicht wurden. Wir werden mehr darüber sprechen, wie die Regeln zur Gabelung im Detail aussehen und im zweiten Teil eine eingehende Analyse der vorgeschlagenen Regeln zur Auswahl der Chain nach einer Gabelung für geshardete Blockchains bereitstellen.
Ungültige Blöcke genehmigen
Eine Reihe von Validierern versucht möglicherweise, einen Block zu erstellen, der die Übergangsfunktion zwischen mehreren states falsch anwendet. Beginnt der Block beispielsweise mit einem Zustand, in dem Alice 10 Token und Bob 0 Token hat, enthält der Block möglicherweise eine Transaktion, die 10 Token von Alice an Bob sendet, endet jedoch mit einem Zustand, in dem Alice 0 Token und Bob 1000 Token hat.
In einer klassischen Blockchain ohne Shards ist ein solcher Angriff nicht möglich, da alle Teilnehmer des Netzwerks alle Blöcke validieren und der Block mit einem so ungültigen Zustandsübergang sowohl von den anderen Minern (den Netzwerkteilnehmern, die neue Blöcke errechnen) als auch von den Teilnehmern des Netzwerks abgelehnt wird, die selbst keine neuen Blöcke errechnen. Es kann vorkommen, dass die böswilligen Validierer weiterhin schneller Blöcke auf einem solchen ungültigen Block erstellen als ehrliche Validierer die ehrliche Kette erstellen, sodass die Kette mit dem ungültigen Block länger ist. Dies spielt allerdings keine Rolle, da jeder andere Teilnehmer des Netzwerks die Blockchain verwirft, die aufbauend auf dem ungültigen Block erstellt wurde.
In der obigen Abbildung befinden sich fünf Validierer, von denen drei böswillig sind. Sie haben einen ungültigen Block A’ erstellt und dann neue Blöcke darauf gebaut. Zwei ehrliche Prüfer verwarfen A’ als ungültig und bauten auf dem letzten gültigen Block auf, der ihnen bekannt war, und erstellten eine Gabelung. Da es weniger Validierer in der ehrlichen Chain gibt, ist ihre Chain kürzer. In der klassischen Blockchain ohne Shards ist jedoch jeder Teilnehmer, der die Blockchain für einen beliebigen Zweck verwendet, dafür verantwortlich, alle empfangenen Blöcke zu validieren und den Status neu zu berechnen. Somit würde jede Person, die irgendein Interesse an der Blockchain hat, feststellen, dass A’ ungültig ist, und somit auch sofort B’, C’ und D’ als solche verwerfen, wobei die Kette A-B als die aktuell längste gültige Kette genommen wird.
In einer Blockchain mit Shards kann jedoch kein Teilnehmer alle Transaktionen auf allen Shards validieren. Daher muss er auf irgendeine Weise bestätigen können, dass zu keinem Zeitpunkt in der Historie eines Shards der Blockchain ein ungültiger Block enthalten war.
Es muss beachtet werden, dass im Gegensatz zu Gabelungen die Vernetzung mit der Beacon-Chain keine ausreichende Lösung ist, da die Beacon-Chain nicht die Kapazität hat, die Blöcke zu validieren. Es kann nur validiert werden, dass eine ausreichende Anzahl von Validierern in diesem Shard den Block signiert hat (und somit seine Richtigkeit bestätigt hat).
Ich kenne zur Zeit nur zwei Lösungen für dieses Problem, von denen keine wirklich zufriedenstellend ist:
- Sie verfügen über einen angemessenen Mechanismus, der das System warnt, wenn versucht wird, den State-Übergang falsch anzuwenden. Angenommen, auf jedem Shard läuft eine Art BFT (Byzantine Fault Tolerance)-Konsens. So lange weniger als ⅔ der Validierer in einem bestimmten Shard böswillig sind, müsste sich mindestens ein ehrlicher Validierer zu einem Block bekennen und sicherstellen, dass die State-Übergangsfunktion richtig angewendet worden ist. Wenn mehr als ⅔ der Knoten böswillig sind, können sie einen Block abschließen, ohne dass ein einziger ehrlicher Knoten teilnimmt. Unter der Annahme, dass mindestens ein Knoten im Shard nicht böswillig ist, ist ein Mechanismus erforderlich, mit dem solche Knoten überwachen können, welche Blöcke erzeugt werden, und über ausreichend Zeit verfügen, um Knoten mit ungültigem State-Übergang herauszufordern.
- Diese Lösungen verfügen in den Blöcken über einige Informationen, die ausreichen, um zu beweisen, dass der Zustandsübergang korrekt angewendet wird. Diese Informationen sind erheblich günstiger zu validieren, als tatsächlich die Zustandsübergangsfunktion anzuwenden. Der nächstliegende Mechanismus, um dies zu erreichen, sind zk-SNARKs (obwohl wir den Teil „zk“, für “zero-knowledge”, oder Null-Wissen nicht wirklich benötigen, ein Nicht-zk-SNARK würde ausreichen), aber zk-SNARKs sind bis heute notorisch langsam zu berechnen.
Viele Protokolle gehen heute davon aus, dass bei einer ordnungsgemäßen Umverteilung der Validierer und einem byzantinisch fehlertoleranten (BFT) Konsens weder Forks noch ungültige Zustandsübergänge möglich sind. Wir werden uns im folgenden, zweiten Beitrag, mit dem Sharding 201 beschäftigen, indem wir uns mit der Frage befassen, warum diese Annahme nicht vernünftig ist.
Outro
Mit den obigen Informationen kennst Du jetzt die meisten der wichtigen Aspekte des Shardings, z. B. das Konzept der Beacon-Chain, Sharding der Ausführung versus State-Sharding und Shard übergreifende Transaktionen. Sei gespannt auf den zweiten Teil mit Sharding 201, das sich eingehender mit der Prävention von Angriffen befasst.
In der Zwischenzeit kannst Du Dich unserem Discord-Kanal anschließen, in dem wir alle technischen und nichttechnischen Aspekte des Near-Protokolls wie Konsens, Wirtschaftlichkeit und Governance besprechen:
Wir haben unseren Code als Open-Source-Version veröffentlicht, lies hier mehr oder erkunde den Code auf GitHub.
Folge Near Protocol auf Twitter, um unsere zukünftigen Blog-Beiträge, einschließlich Sharding 201, und andere Ankündigungen nicht zu verpassen:
Zu guter Letzt, abonniere unseren Newsletter. Wir senden alle zwei Wochen Updates. Dies ist der beste Kanal, um mehr über unsere Fortschritte auf dem Weg zum Start des Mainnets zu erfahren.
.
Dieser Text wurde im Original im Englischen von Alex Skidanov verfasst und von Markus Koch ins Deutsche übersetzt.
NEAR Protocol Germany ist kein offizieller Account des NEAR Teams, sondern Teil des NEAR Ambassador Programms. Falls Du daran interessiert bist, selbst Teil dieses Programms zu werden, und zu erfahren, wie Du davon profitieren kannst, schreibe NEAR Protocol Germany oder Anaïs Urlichs hier auf Medium oder trete unserem NEAR Discord Kanal bei.
Außerdem findest Du hier alles was Du über das NEAR Ambassador Programm wissen solltest.
