Hallo, ich bin einer der Entwickler des Sharded Blockchain Near Protocol und möchte in diesem Artikel darüber sprechen, was Blockchain Sharding ist, wie es implementiert wird und welche Probleme bei Blockchain Sharding-Designs bestehen.
Es ist bekannt, dass Ethereum, die zum Zeitpunkt dieses Schreibens am häufigsten verwendete Blockchain für allgemeine Zwecke, nur weniger als 20 Transaktionen pro Sekunde in der Hauptkette verarbeiten kann. Diese Einschränkung führt zusammen mit der Beliebtheit des Netzwerks zu hohen Gaspreisen (den Kosten für die Ausführung einer Transaktion im Netzwerk) und langen Bestätigungszeiten. Trotz der Tatsache, dass zum Zeitpunkt dieses Schreibens ungefähr alle 10 bis 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-Tankstelle 1,2 Minuten. Niedriger Durchsatz, hohe Preise und hohe Latenz machen Ethereum nicht für die Ausführung von Diensten geeignet, die mit der Einführung skaliert werden müssen.
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 können größtenteils in diejenigen unterteilt werden, die die gesamte Berechnung an eine kleine Gruppe leistungsfähiger Knoten delegieren, und diejenigen, bei denen jeder Knoten im Netzwerk nur einen Teil des Gesamtaufwands erledigt. Ein Extremfall des ersteren Ansatzes ist Thunder , bei dem ein einziger Knoten alle Transaktionen und Ansprüche verarbeitet, um 1200 tx / s zu erreichen, eine 100-fache Verbesserung gegenüber Ethereum (ich unterstütze Thunder jedoch nicht oder bestätige die Gültigkeit ihrer Ansprüche ) Algorand , SpaceMesh und Solana passen alle in die erstere Kategorie und bauen verschiedene Verbesserungen im Konsens und in der Struktur der Blockchain selbst auf, um deutlich mehr Transaktionen auszuführen, aber immer noch begrenzt durch das, was eine einzelne (wenn auch sehr leistungsfähige) Maschine verarbeiten kann.
Der letztere Ansatz, bei dem die Arbeit auf alle beteiligten Knoten aufgeteilt wird, wird als Sharding bezeichnet. So plant die Ethereum Foundation derzeit, Ethereum zu skalieren. Zum Zeitpunkt dieses Schreibens ist die vollständige Spezifikation noch nicht veröffentlicht. Hier finden Sie Links zu einer detaillierten Übersicht über Ethereum-Shardketten und die Beacon-Kette .
In diesem Beitrag fasse ich die Kernideen des Blockchain-Sharding zusammen, auf denen sowohl Near als auch die Mehrheit anderer Sharded-Protokolle basieren. Der folgende Beitrag beschreibt fortgeschrittenere Themen im Sharding.
Die einfachste Scherbe, auch bekannt als Bohnenstange
Beginnen wir mit dem einfachsten Ansatz zum Sharding, den wir in diesem Artikel als Beanstalk bezeichnen. Dies nennt Vitalik in dieser Präsentation auch „Skalieren um tausend Altmünzen“.
Bei diesem Ansatz werden anstelle einer Blockchain mehrere ausgeführt, und jede dieser Blockchain wird als "Shard" bezeichnet. Jeder Shard hat seine eigenen Validatoren. Hier und unten verwenden wir einen allgemeinen Begriff „Validator“, um sich auf Teilnehmer zu beziehen, die Transaktionen verifizieren und Blöcke erzeugen, entweder durch Mining, wie in Proof of Work oder über einen abstimmungsbasierten Mechanismus. Nehmen wir zunächst an, dass die Scherben niemals miteinander kommunizieren.
Das Beanstalk-Design ist zwar einfach, reicht jedoch aus, um einige wichtige Herausforderungen beim Sharding zu skizzieren.
Validator-Partitionierung und Beacon-Ketten
Die erste Herausforderung besteht darin, dass jeder Shard mit seinen eigenen Validatoren jetzt zehnmal weniger sicher ist als die gesamte Kette. Wenn sich also eine nicht-Sharded-Kette mit X-Validatoren dazu entschließt, sich in eine Sharded-Kette zu teilen und X-Validatoren auf 10 Shards aufteilt, verfügt jeder Shard nur noch über X / 10-Validatoren, und für die Beschädigung eines Shards müssen nur 5,1% (51%) beschädigt werden / 10) der Gesamtzahl der Validatoren.
Was uns zum zweiten Punkt bringt: Wer wählt Validatoren für jeden Shard aus? Die Kontrolle von 5,1% der Validatoren ist nur dann schädlich, wenn sich alle 5,1% der Validatoren in derselben Scherbe befinden. Wenn Validatoren nicht auswählen können, in welchem Shard sie validieren sollen, ist es sehr unwahrscheinlich, dass ein Teilnehmer, der 5,1% der Validatoren kontrolliert, alle Validatoren in denselben Shard bringt, was seine Fähigkeit, das System zu gefährden, stark verringert.
Fast alle Sharding-Designs basieren heutzutage auf einer Zufallsquelle, um Shards Validatoren zuzuweisen. Zufälligkeit in Blockchain an sich ist ein sehr herausforderndes Thema und würde zu einem späteren Zeitpunkt einen separaten Blog-Beitrag verdienen, aber nehmen wir jetzt an, dass es eine Quelle für Zufälligkeit gibt, die wir verwenden können.
Sowohl die Zufälligkeit als auch die Validatorzuweisung 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 die für die Wartung des gesamten Netzwerks erforderlichen Vorgänge ausführen soll. Neben dem Generieren von Zufallszahlen und dem Zuweisen von Validatoren zu den Shards umfassen diese Vorgänge häufig auch das Empfangen von Aktualisierungen von Shards und das Erstellen von Snapshots davon, das Verarbeiten von Einsätzen und Schrägstrichen in Proof-of-Stake-Systemen sowie das Neuausgleichen von Shards, wenn diese Funktion unterstützt wird. Eine solche Kette wird in Ethereum und Near als Beacon-Kette, in PolkaDot als Relay-Kette und im Cosmos als Cosmos Hub bezeichnet.
In diesem Beitrag werden wir eine solche Kette als Beacon-Kette bezeichnen . Die Existenz der Beacon-Kette bringt uns zum nächsten interessanten Thema, dem quadratischen Sharding.
Quadratisches Splittern
Sharding wird häufig als Lösung beworben, die sich unendlich mit der Anzahl der am Netzwerkbetrieb beteiligten Knoten skalieren lässt. Während es theoretisch möglich ist, eine solche Sharding-Lösung zu entwerfen, weist jede Lösung, die das Konzept einer Beacon-Kette hat, keine unendliche Skalierbarkeit auf. Um zu verstehen, warum, beachten Sie, dass die Beacon-Kette einige Buchhaltungsberechnungen durchführen muss, z. B. das Zuweisen von Validatoren zu Shards oder das Snapshotting von Shard-Kettenblöcken, die proportional zur Anzahl der Shards im System sind. Da die Beacon-Kette selbst eine einzelne Blockchain ist und die Berechnung durch die Rechenfähigkeiten der Knoten, die sie betreiben, begrenzt ist, ist die Anzahl der Shards natürlich begrenzt.
Die Struktur eines Sharded-Netzwerks wirkt sich jedoch multiplikativ auf Verbesserungen seiner Knoten aus. Betrachten Sie den Fall, in dem die Effizienz der Knoten im Netzwerk willkürlich verbessert wird, wodurch sie schnellere Transaktionsverarbeitungszeiten erhalten.
Wenn die Knoten, die das Netzwerk betreiben, einschließlich der Knoten in der Beacon-Kette, viermal schneller werden, kann jeder Shard viermal mehr Transaktionen verarbeiten, und die Beacon-Kette 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, eine genaue Messung für die Anzahl der heute realisierbaren Shards bereitzustellen, aber es ist unwahrscheinlich, dass in absehbarer Zukunft die Durchsatzanforderungen von Blockchain-Benutzern über die Einschränkungen des quadratischen Shards hinauswachsen. Die schiere Anzahl von Knoten, die erforderlich sind, um ein solches Volumen von Shards sicher zu betreiben, ist um Größenordnungen höher als die Anzahl von Knoten, die alle Blockchains heute zusammen betreiben.
Wenn wir jedoch zukunftssichere Protokolle erstellen möchten, könnte es sich lohnen, 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 Eltern-Shard eine Reihe von Child-Shards orchestriert, während er selbst ein Kind eines anderen Shards sein kann.
Es ist bekannt, dass Vlad Zamfir von der Ethereum Foundation an einem Sharding-Design arbeitet, bei dem es sich nicht um eine Beacon-Kette handelt. Ich habe mit ihm an einem der Prototypen gearbeitet, dessen detaillierte Übersicht hier zu finden ist .
Staatliche Scherbe
Bisher haben wir nicht genau definiert, was genau ist und was nicht, wenn ein Netzwerk in Shards unterteilt ist. Insbesondere führen Knoten in der Blockchain drei wichtige Aufgaben aus: Sie verarbeiten nicht nur 1) Transaktionen, sondern leiten 2) validierte Transaktionen und abgeschlossene Blöcke an andere Knoten weiter und 3) speichern den Status und den Verlauf des gesamten Netzwerkbuchs. Jede dieser drei Aufgaben stellt eine wachsende Anforderung an die Knoten, die das Netzwerk betreiben:
- Die Notwendigkeit, Transaktionen zu verarbeiten, erfordert mehr Rechenleistung mit der erhöhten Anzahl von Transaktionen, die verarbeitet werden.
- Die Notwendigkeit, Transaktionen und Blöcke weiterzuleiten, erfordert mehr Netzwerkbandbreite, da mehr Transaktionen weitergeleitet werden.
- Die Notwendigkeit, Daten zu speichern, erfordert mehr Speicher, wenn der Zustand wächst. Im Gegensatz zur Verarbeitungsleistung und zum Netzwerk steigt der Speicherbedarf auch dann, wenn die Transaktionsrate (Anzahl der pro Sekunde verarbeiteten Transaktionen) konstant bleibt.
Aus der obigen Liste geht hervor, dass die Speicheranforderung am dringendsten ist, da sie die einzige ist, die im Laufe der Zeit erhöht wird, selbst wenn sich die Anzahl der Transaktionen pro Sekunde nicht ändert, in der Praxis jedoch heute die dringendste Anforderung ist die Rechenleistung. Der gesamte Status von Ethereum beträgt zum jetzigen Zeitpunkt 100 GB und kann von den meisten Knoten problemlos verwaltet werden. Die Anzahl der Transaktionen, die Ethereum verarbeiten kann, liegt bei etwa 20, um Größenordnungen weniger als für viele praktische Anwendungsfälle erforderlich.
Zilliqa ist das bekannteste Projekt, das die Verarbeitung, aber nicht die Speicherung beeinträchtigt. Das Sharding der Verarbeitung ist ein einfacheres Problem, da jeder Knoten den gesamten Status hat, was bedeutet, dass Verträge andere Verträge frei aufrufen und alle Daten aus der Blockchain lesen können. Es ist eine sorgfältige Entwicklung erforderlich, um sicherzustellen, dass Aktualisierungen von mehreren Shards, die dieselben Teile des Status aktualisieren, nicht in Konflikt geraten. In dieser Hinsicht verfolgt Zilliqa einen sehr simplen Ansatz, dessen Kritik in diesem Beitrag zu finden ist .
Während das Sharding von Speicher ohne Sharding von Verarbeitung vorgeschlagen wurde, ist mir kein Projekt bekannt, das daran arbeitet. In der Praxis impliziert das Sharding von Speicher oder State Sharding fast immer das Sharding der Verarbeitung und das Sharding des Netzwerks.
In der Praxis erstellen die Knoten in jedem Shard unter 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 Validatoren im Shard nur ihren lokalen Teil des globalen Status speichern und nur Transaktionen ausführen und als solche nur weiterleiten, die ihren Teil des Status betreffen. Diese Partition reduziert linear die Anforderungen an Rechenleistung, Speicher und Netzwerkbandbreite, führt jedoch zu neuen Problemen wie Datenverfügbarkeit und Cross-Shard-Transaktionen, die im Folgenden behandelt werden.
Cross-Shard-Transaktionen
Beanstalk als Modell ist kein sehr nützlicher Ansatz für das Sharding, denn wenn einzelne Shards nicht miteinander kommunizieren können, sind sie nicht besser als mehrere unabhängige Blockchains. Selbst heute, wenn kein Sharding verfügbar ist, besteht ein großer Bedarf an Interoperabilität zwischen verschiedenen Blockchains.
Betrachten wir zunächst nur einfache Zahlungsvorgänge, bei denen jeder Teilnehmer ein Konto auf genau einem Shard hat. Wenn jemand innerhalb desselben Shards Geld von einem Konto auf ein anderes überweisen möchte, kann die Transaktion vollständig von den Validatoren in diesem Shard verarbeitet werden. Wenn jedoch Alice, die auf Shard Nr. 1 wohnt, Geld an Bob senden möchte, der auf Shard Nr. 2 wohnt, weder Validatoren auf Shard Nr. 1 (sie können Bobs Konto nicht gutschreiben) noch die Validatoren auf Shard Nr. 2 ( Sie können Alices Konto nicht belasten. Sie können die gesamte Transaktion verarbeiten.
Es gibt zwei Arten von Ansätzen für Cross-Shard-Transaktionen:
- Synchron : Immer wenn eine Shard-übergreifende Transaktion ausgeführt werden muss, werden alle Blöcke in mehreren Shards, die einen mit der Transaktion verbundenen Statusübergang enthalten, gleichzeitig erstellt, und die Validatoren mehrerer Shards arbeiten bei der Ausführung solcher Transaktionen zusammen. Der detaillierteste mir bekannte Vorschlag ist Merge Blocks, hier beschrieben.
- Asynchron : Eine Cross-Shard-Transaktion, die mehrere Shards betrifft, wird in diesen Shards asynchron ausgeführt. Der Shard "Credit" führt seine Hälfte aus, sobald ausreichende Beweise dafür vorliegen, dass der Shard "Debit" seinen Teil ausgeführt hat. Dieser Ansatz ist aufgrund seiner Einfachheit und einfachen Koordinierung 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 bei einer unabhängigen Erstellung von Blöcken die Wahrscheinlichkeit ungleich Null besteht, dass einer der mehreren Blöcke verwaist ist, sodass die Transaktion nur teilweise angewendet wird. Betrachten Sie die folgende Abbildung, die zwei Shards zeigt, die beide auf eine Abzweigung gestoßen sind, und eine Cross-Shard-Transaktion, die in den Blöcken A und X 'entsprechend aufgezeichnet wurde. Wenn die Ketten AB und V'-X'-Y'-Z 'in den entsprechenden Shards kanonisch sind, ist die Transaktion vollständig abgeschlossen. Wenn A'-B'-C'-D 'und VX kanonisch werden, wird die Transaktion vollständig abgebrochen, was akzeptabel ist. Wenn beispielsweise AB und VX kanonisch werden, wird ein Teil der Transaktion abgeschlossen und einer abgebrochen, was zu einem Atomfehler führt. Wir werden im zweiten Teil darauf eingehen, wie dieses Problem in den vorgeschlagenen Protokollen angegangen wird, wenn Änderungen an den Regeln für die Gabelauswahl und den Konsensalgorithmen behandelt werden, die für Sharded-Protokolle vorgeschlagen wurden.
Beachten Sie, dass die Kommunikation zwischen Ketten auch außerhalb von Sharded-Blockchains nützlich ist. Die Interoperabilität zwischen Ketten ist ein komplexes Problem, das viele Projekte zu lösen versuchen. In Sharded-Blockchains ist das Problem etwas einfacher, da die Blockstruktur und der Konsens über Shards hinweg gleich sind und es eine Beacon-Kette gibt, die für die Koordination verwendet werden kann. In einer Sharded-Blockchain sind jedoch alle Shard-Ketten gleich, während es im globalen Blockchains-Ökosystem viele verschiedene Blockchains mit unterschiedlichen Zielanwendungsfällen, Dezentralisierung und Datenschutzgarantien gibt.
Der Aufbau eines Systems, in dem eine Reihe von Ketten unterschiedliche Eigenschaften aufweist, jedoch eine ausreichend ähnliche Konsens- und Blockstruktur verwendet und eine gemeinsame Beacon-Kette aufweist, könnte ein Ökosystem heterogener Blockketten mit einem funktionierenden Interoperabilitäts-Subsystem ermöglichen. Es ist unwahrscheinlich, dass ein solches System eine Validatorrotation aufweist. Daher müssen einige zusätzliche Maßnahmen ergriffen werden, um die Sicherheit zu gewährleisten. Sowohl Cosmos als auch PolkaDot sind effektiv solche Systeme. Dieser Artikel von Zaki Manian von Cosmos bietet einen detaillierten Überblick und Vergleich der wichtigsten Aspekte der beiden Projekte.
Bösartiges Verhalten
Sie haben jetzt ein gutes Verständnis dafür, wie Sharding implementiert wird, einschließlich der Konzepte der Beacon-Kette, der Validator-Rotationen und der Cross-Shard-Transaktionen.
Bei all diesen Informationen ist noch eine letzte wichtige Sache zu beachten. Welches gegnerische Verhalten können böswillige Prüfer ausüben?
Bösartige Gabeln
Eine Reihe böswilliger Prüfer versucht möglicherweise, eine Abzweigung zu erstellen. Beachten Sie, dass es keine Rolle spielt, ob der zugrunde liegende Konsens BFT ist oder nicht. Wenn Sie eine ausreichende Anzahl von Validatoren beschädigen, können Sie immer eine Abzweigung erstellen.
Es ist wesentlich wahrscheinlicher, dass mehr als 50% eines einzelnen Shards beschädigt werden, als dass mehr als 50% des gesamten Netzwerks beschädigt werden (wir werden im zweiten Teil näher auf diese Wahrscheinlichkeiten eingehen). Wie oben erläutert, beinhalten Cross-Shard-Transaktionen bestimmte Statusänderungen in mehreren Shards, und die entsprechenden Blöcke in solchen Shards, die solche Statusänderungen anwenden, müssen entweder alle abgeschlossen sein (dh in den ausgewählten Ketten auf ihren entsprechenden Shards erscheinen) oder alle verwaist sein (dh nicht in den ausgewählten Ketten auf den entsprechenden Scherben erscheinen). Da die Wahrscheinlichkeit, dass Shards beschädigt werden, im Allgemeinen nicht vernachlässigbar ist, können wir nicht davon ausgehen, dass die Gabeln auch dann nicht auftreten, wenn unter den Shard-Validatoren ein byzantinischer Konsens erzielt wurde oder mit der Zustandsänderung viele Blöcke über dem Block erzeugt wurden .
Dieses Problem hat mehrere Lösungen, wobei die häufigste die gelegentliche Vernetzung des neuesten Shard-Kettenblocks mit der Beacon-Kette ist. Die Gabelauswahlregel in den Shardketten wird dann geändert, um immer die vernetzte Kette zu bevorzugen, und es wird nur die Shard-spezifische Gabelauswahlregel für Blöcke angewendet, die seit der letzten Vernetzung veröffentlicht wurden.
Ungültige Blöcke genehmigen
Eine Reihe von Validatoren versucht möglicherweise, einen Block zu erstellen, der die Zustandsübergangsfunktion falsch anwendet. Beginnend mit einem Status, 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 Status, in dem Alice 0 Token und Bob 1000 Token hat Token.
In einer klassischen nicht-Sharded-Blockchain ist ein solcher Angriff nicht möglich, da alle Teilnehmer im Netzwerk alle Blöcke validieren und der Block mit einem solchen ungültigen Zustandsübergang sowohl von anderen Blockherstellern als auch von den Teilnehmern des Netzwerks abgelehnt wird das schafft keine Blöcke. Selbst wenn die böswilligen Prüfer weiterhin Blöcke auf einem solchen ungültigen Block schneller erstellen als ehrliche Prüfer, bauen sie die richtige Kette auf, sodass die Kette mit dem ungültigen Block länger ist, spielt dies keine Rolle, da jeder Teilnehmer, für den die Blockkette verwendet wird Jeder Zweck überprüft alle Blöcke und verwirft alle Blöcke, die auf dem ungültigen Block aufgebaut sind.
In der obigen Abbildung sind fünf Prüfer dargestellt, von denen drei böswillig sind. Sie erstellten einen ungültigen Block A 'und bauten darauf weitere neue Blöcke. Zwei ehrliche Prüfer verwarfen A 'als ungültig und bauten auf dem letzten ihnen bekannten gültigen Block auf, wodurch eine Gabelung entstand. Da die ehrliche Gabel weniger Prüfer enthält, ist ihre Kette kürzer. In der klassischen Blockchain ohne Sharded ist jedoch jeder Teilnehmer, der 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 Interesse an der Blockchain hat, feststellen, dass A 'ungültig ist, und somit auch sofort B', C 'und D' verwerfen, wobei die Kette AB als die derzeit längste gültige Kette genommen wird.
In einer Sharded-Blockchain kann jedoch kein Teilnehmer alle Transaktionen auf allen Shards validieren. Daher muss er eine Möglichkeit haben, um zu bestätigen, dass zu keinem Zeitpunkt in der Geschichte eines Shards der Blockchain kein ungültiger Block enthalten war.
Beachten Sie, dass im Gegensatz zu Gabeln die Vernetzung mit der Beacon-Kette keine ausreichende Lösung ist, da die Beacon-Kette nicht in der Lage ist, die Blöcke zu validieren. Es kann nur validiert werden, dass eine ausreichende Anzahl von Validatoren in diesem Shard den Block signiert hat (und als solcher seine Richtigkeit bestätigt hat).
Mir sind nur zwei Lösungen für dieses Problem bekannt, von denen keine heute wirklich zufriedenstellend ist:
- Haben Sie einen vernünftigen Mechanismus, der das System alarmiert, wenn versucht wird, den Statusübergang falsch anzuwenden. Angenommen, jeder Shard führt einen BFT-Konsens durch, solange die Anzahl der böswilligen Validatoren in einem bestimmten Shard weniger als ⅔ beträgt, müsste mindestens ein ehrlicher Validator einen Block bestätigen und überprüfen, ob die Statusübergangsfunktion erfüllt ist richtig angewendet. 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, der es solchen Knoten ermöglicht, zu überwachen, welche Blöcke erzeugt werden, und ausreichend Zeit hat, um Knoten mit ungültigem Zustandsübergang herauszufordern.
- Haben Sie einige Informationen in den Blöcken, die ausreichen, um zu beweisen, dass der Zustandsübergang korrekt angewendet wird, aber die Validierung erheblich billiger ist als die tatsächliche Anwendung der Zustandsübergangsfunktion. Der nächstgelegene Mechanismus, um dies zu erreichen, sind zk-SNARKs (obwohl wir den Teil „zk“ oder Nullwissen nicht wirklich benötigen, würde ein Nicht-zk-SNARK ausreichen), aber zk-SNARKs sind notorisch langsam zu berechnen dieser Punkt.
Viele Protokolle gehen heute davon aus, dass bei ordnungsgemäßer Validatorrotation und einem byzantinischen fehlertoleranten Konsens weder Gabeln noch ungültige Zustandsübergänge möglich sind. Der Grund, warum diese Annahme nicht zumutbar ist, ist ein Thema für einen separaten Artikel.
Outro
Ich schreibe viel über Blockchains und Sharding und wir haben auch eine Videoserie, in der wir mit Gründern skalierbarer Protokolle wie Cosmos und Solana über Tech Deep Dives sprechen. Du kannst mir hier auf Twitter folgen.