Von: Joe Petrowski

Polkadot garantiert gültige Zustandsübergänge für seine Mitglieder Parachains. Unter der Oberfläche spielt ein Orchester von Nodes, von Validatoren und Kollatoren bis hin zu Fischern und Full Nodes, seine Rolle, um Parachain-Blöcke an die endgültige Relay Chain zu liefern.

Parachains sind souveräne Blockchains, die mit dem Polkadot-Netzwerk verbunden sind. Wie andere Blockchains sind Parachains deterministische Zustandsmaschinen, d.h. jede Parachain hat einen Zustand, führt eine Reihe von Zustandsübergängen, genannt Block, aus und erreicht einen neuen Zustand. Ein Zustand ist wie die Konfiguration eines Systems. Denken Sie an einen Lichtschalter. Er kann entweder "an" oder "aus" sein. Der Zustand eines Computers ist wie mehrere Milliarden Lichtschalter. Auf der grundlegendsten Ebene enthält ein Stapel von Zustandsübergängen eine Liste von Lichtschaltern, die umgeschaltet werden können. Eine Zustandsübergangsfunktion ist die Logik, die entscheidet, ob die Schalter umgeschaltet werden sollen.

Jede Parachain[1] innerhalb von Polkadot hat ihren eigenen Zustand. Die Relay Chain verknüpft alle diese Zustände zu einem Zustand - einem "Zustand der Zustände" - in einer Taktik, die "sharding" genannt wird. Jede Parachain ist ein Splitter von Polkadot, mit einzigartigen Regeln für den Zustandsübergang. Parachains haben eine eigene Wirtschaft, eigene Governance-Mechanismen und eigene Benutzer. Aufgrund der Schnittstelle, die Polkadot bietet, können die Validatoren der Relay Chain garantieren, dass jede Parachain ihre eigenen Regeln befolgt und Nachrichten zwischen den Shards in einer vertrauensfreien Umgebung weitergeben kann.

Dieser Artikel befasst sich mit der Reihe von Verfügbarkeits- und Gültigkeitsprüfungen, die Parachain-Blöcke durchlaufen, um ihren Weg in die Relay Chain zu finden, wo sie, sobald sie abgeschlossen sind, von der Sicherheit des gesamten Polkadot-Netzwerks profitieren.

I. Match Making

Der Prozess der Blockerstellung beginnt mit Parachain Kollatoren. Kollatoren sind ähnlich wie Validatoren auf jeder anderen Blockchain, aber sie müssen keine Sicherheitsgarantien bieten, da Polkadot diese bereitstellt. Kollatoren müssen nur Blöcke erstellen, die ihre abgeschlossene Chain verlängern.

Einheitliche Sicherheitsgarantien sorgen dafür, dass die an Polkadot angeschlossenen Chains vertrauensfrei interagieren können. Parachains können ohne Vertrauensgrenzen interagieren, ähnlich wie Smart Contracts auf Ethereum ohne Vertrauensgrenzen interagieren können - sie teilen den Status und die Validierungslogik mit dem größeren Netzwerk.

Da Polkadot die Sicherheits- und Gültigkeitsgarantien bietet, unterliegen Parachains nicht den üblichen Blockchain-Angriffsszenarien, wie z.B. einem 51%-Angriff. Die Validatoren von Polkadot weisen ungültige Blöcke zurück, so dass eine Parachain nur einen einzigen ehrlichen Kollator benötigt, um Blöcke einzureichen. Dieses Modell eröffnet einen neuen Bereich der Kryptoökonomie, der Parachains ohne Token, Proof-of-Stake-Parachains, die entweder einen nativen Parachain-Token oder Dot-Token verwenden, oder andere Mechanismen zur Auswahl von Kollatoren umfassen könnte. Die Information über den Blockautor ist normalerweise Teil des Blockheaders und lässt sich leicht überprüfen.

Jede Parachain in Polkadot wird über eine Reihe von Relay Chain Validatoren verfügen, die ihre Parachain-Blöcke akzeptieren und validieren und sie in Richtung Finalität bewegen. Aber diese Validatoren bleiben nicht lange, wie in anderen Sharded-Systemen, die Validatoren auf unbestimmte Zeit einem einzelnen Shard zuweisen. Bei jedem Block finden die Validatoren von Polkadot einen neuen Parachain in einem Kotillion, der sich im Takt des Metronoms von Polkadot dreht: dem BABE-Zufallsbaken.

Die Validatoren verwenden die von BABE erzeugten Zufallszahlen - dieselben, die die Slots für die Blockproduktion zuweisen -, um festzustellen, welche Parachain als nächstes zu validieren ist. Sobald ein Validator seine neue Parachain kennt, sucht er nach Kollatoren aus dieser Parachain, mit denen er Verbindungen herstellen kann. Jeder Validator, der einer Parachain zugewiesen ist, importiert die richtige Zustandsübergangsfunktion, um diese Parachain zu validieren. Da Kollatoren und Validatoren nun über eine gemeinsame Verbindung und eine gemeinsame Logik verfügen, kann ein Kollator einen Block an einen der Validatoren senden.

Um diese erste Phase aus der Sicht eines einzelnen Parachains zu rekapitulieren:

• Die Parachain wählt einen Kollator aus, um einen Block an die Relay Chain zu übermitteln,

• Polkadot weist dieser Parachain eine Reihe von Validatoren zu, und

• Die Kollatoren und Validatoren öffnen Verbindungen, um einen Block zu übermitteln.

II. Blockvorbereitung

Wenn ein Validator einen Block empfängt, prüft er zunächst, ob der Block den Zustandsübergangsregeln der Parachain folgt.

Der Zustand einer Parachain wird in einem Merkle-Baum gespeichert. Jeder Datenpunkt im Zustand besteht aus einem Schlüssel und einem Wert. Ein Schlüssel könnte zum Beispiel eine Konto-ID sein und ein Wert die Anzahl der Token, die sie kontrolliert. Jedes dieser Schlüssel-Wert-Paare wird mit einem Hash dargestellt und wird zu einem Blatt des Baums. Um die Verzweigungen zu bilden, werden benachbarte Blätter verkettet und erneut mit einem Hash versehen, so dass aus zwei Punkten einer wird. Der Prozess wird fortgesetzt, wobei die Gesamtzahl der Elemente jedes Mal um die Hälfte reduziert wird, bis der Baum nur noch einen einzigen Hash-Wert hat, der die gesamte Datenbank repräsentiert, die Statuswurzel.

Ein kleiner Merkle-Baum. Jedes Speicherelement wird gehasht, um das Blatt zu finden. Dann bildet jedes Blattpaar die nächste Ebene, bis ein Wert übrig bleibt: die Statuswurzel.

Merkle-Bäume haben eine praktische Eigenschaft: Wenn sich ein Wert ändert, kann man die Änderung überprüfen, indem man sich nur die neuen Werte und die Pfade im Baum ansieht, die davon betroffen sind.

Auf der Grundlage dieser Eigenschaft kann ein Validator einen Zustandsübergang überprüfen, ohne Zugriff auf den gesamten Zustand zu haben. Er braucht nur:

• Der Block (Liste der Zustandsübergänge),

• Die Werte in der Datenbank der Parachain, die durch den Block verändert werden, und

• Die Hashes der nicht beeinflussten Punkte im Merkle-Baum.

Dieser Satz von Informationen stellt einen Gültigkeitsnachweis dar. Hashes haben eine feste Länge. Es spielt keine Rolle, wie groß die unveränderten Werte sind; der Hash reicht aus, um sie darzustellen.

In diesem Beispiel hat Louise 50 Token an Ben geschickt und jemand hat ein neues Referendum erstellt. Polkadot kann einen Zustandsübergang mit dem Block plus dem reduzierten Merkle-Baum validieren.

Jetzt ist ein geeigneter Zeitpunkt, um eine wichtige Unterscheidung zu treffen: Polkadot garantiert nicht einen gültigen Zustand, sondern einen gültigen Zustandsübergang. Die Validatoren von Polkadot überprüfen nicht jeden Wert im Zustand einer Parachain, sondern nur die Werte, die geändert wurden, und stellen sicher, dass die Änderung gültig ist. Wenn eine Chain dem Polkadot-Netzwerk mit einem gültigen Zustand beitritt und alle ihre Übergänge unter dem Dach der Polkadot-Sicherheit ausführt, dann hat sie einen gültigen Zustand.[2]

Sobald ein Validator den Beweis der Gültigkeit hat, gibt er diese Information an die anderen Validatoren weiter, die dieser Parachain zugeordnet sind. Sobald mehr als die Hälfte von ihnen der Meinung ist, dass der Block einen gültigen Zustandsübergang darstellt, können sie mit den Vorbereitungen für die Bekanntgabe seiner Gültigkeit beginnen. Die Validatoren erstellen eine "Kandidatenbelege" - das ist das, was tatsächlich in den Relay Chain-Block eingeht - und eine Erasure Coding, die sie an alle Validatoren im Netzwerk senden.

Kandidatenbelege

Bei der Parachain-Validierung haben Validatoren und Kollatoren eine Menge Informationen ausgetauscht. Ein Gültigkeitsnachweis enthält einen ganzen Parachain-Block sowie große Teile seines Zustands. Damit Polkadot auf Hunderte von Parachains skalieren kann, benötigen die Gültigkeitsnachweise etwas Kleineres, um sie auf der Relay Chain zu repräsentieren: Kandidatenbelege.

Ein Validator erstellt eine Kandidatenquittung für einen Parachain-Block, indem er ihn signiert:

• Die Parachain ID

• Die ID und Signatur des Kollators

• Ein Hash des Empfangskandidaten des Elternblocks

• Eine Merkle-Wurzel der Erasure Coding des Blocks

• Eine Merkle-Wurzel aller ausgehenden Nachrichten

• Ein Hash des Blocks

• Die Zustandswurzel der Parachain vor der Ausführung des Blocks

• Die Zustandswurzel der Parachain nach der Ausführung des Blocks

Dies sieht zwar wie eine lange Liste von Informationen aus, ist aber tatsächlich viel kleiner als ein Gültigkeitsnachweis, da jedes Element eine feste Länge hat. Die Parachain- und Kollator-IDs sind nur Zahlen; alles andere ist ein Hash (eine Merkle-Wurzel ist ein Hash von einem Hash von einem Hash von einem ...). In der Informatik bietet jede Methode, mit der eine beliebige Menge an Informationen in einer konstanten Größe dargestellt werden kann, einen Skalierbarkeitsvorteil. Dieses System kann skalieren, indem es immer mehr Informationen an die Ränder weitergibt, während es nur Informationen in konstanter Größe durch die Relay Chain weitergibt.

Der Hash der Quittung des Elternblocks stellt sicher, dass die aktuelle Quittung auf der richtigen Chain aufbaut. Ebenso ermöglichen die Zustandswurzeln der Parachain und der Hash des Blocks jedem, diesen Zustandsübergang zu verifizieren, indem er den Beweis für die Gültigkeit erhält - den Block selbst plus die Aktualisierungen im Zustandsbaum.

Erasure Coding

Nun zur Erasure Coding. Bevor dieser Quittungskandidat an die Transaktionswarteschlange der Relay Chain gesendet wird, muss der Validator, der den Quittungskandidaten konstruiert, auch eine Erasure Coding des Parachain-Blocks konstruieren.

Eine Erasure Coding nimmt eine Nachricht - in diesem Fall ist die Nachricht der Parachain-Block und der Gültigkeitsnachweis - und erstellt eine Reihe kleinerer Nachrichten, so dass Sie die ursprüngliche Nachricht rekonstruieren können, indem Sie einen Bruchteil der kleineren Nachrichten erhalten. Im Falle von Polkadot ist die Anzahl der kleineren Nachrichten gleich der Gesamtzahl der Validatoren und der Bruchteil ist ein Drittel. Wenn Polkadot zum Beispiel 1.000 Validatoren hat und jeder von ihnen einen Chunk erhält (die kleinen Stücke werden "Chunks" genannt), dann könnten sie einen Block mit 334 von ihnen rekonstruieren.

Der Validator erstellt also all diese Erasure Coding Chunks, fügt diese Chunks in seinen eigenen Merkle-Baum ein und sendet jeden Chunk an einen entsprechenden Validator. Zusammen mit diesen Chunks sendet der Validator auch die Quittungsanwärter, die tatsächlich in einen Block der Relay Chain eingehen.

Die Validatoren, die eine Kandidatenquittung zusammen mit einem Erasure Coding Chunk erhalten, nehmen die Kandidatenquittung in die Transaktionswarteschlange der Relay Chain auf, wo ein Autor sie in einen Block aufnehmen kann.

Cool Story Bro

Erasure Coding mag zwar etwas trocken klingen, aber warum wir das Erasure Coding durchführen, ist viel interessanter als die Funktionsweise.

Stellen Sie sich vor, dass ein bösartiger Kollator einen gültigen Block an die Validatoren übermittelt und dann sofort offline geht. Der Angriff besteht hier nicht darin, eine ungültige Transaktion zu erzeugen, sondern die Parachain komplett lahmzulegen, was - grob gesagt - das Leben aller unglücklich machen würde.

Wenn die Validatoren diesen Block nur auf Gültigkeit prüfen und ihn dann in der Relay Chain abschließen würden, hätten die Kollatoren nur noch ihren vorherigen Zustand und ihren aktuellen Stammzustand, ohne zu wissen, welche Änderungen sie vornehmen müssen, um den aktuellen Stammzustand zu erzeugen. Da sie nicht mehr über ihren Status verfügen würden, könnten sie auch keine neuen Blöcke mehr erstellen.

Daher müssen Kollatoren in der Lage sein, einen Block für ihre Parachain abzurufen und zu rekonstruieren, bevor er endgültig wird.

III. Relay Chain Block Konstruktion

Kollatoren und Validatoren haben eine Menge Arbeit geleistet, um diesen Punkt zu erreichen. Jede Parachain bekam eine kleine Gruppe von Validatoren zufällig für einen Block zugewiesen. Diese Validatoren mussten eine Verbindung zu den Kollatoren der Parachains herstellen, Statuswurzeln berechnen, übergeordnete Blöcke nachschlagen und Erasure Coding Chunks erstellen und an jeden anderen Validator im Netzwerk verteilen. Sie haben all diese Aufgaben in einer Kandidatenquittung zusammengefasst, die all dies repräsentiert.

Die Kandidatenquittung wird in die Warteschlange für Relay Chain-Transaktionen gestellt und von den Validatoren wie andere Transaktionen im Netzwerk weitergegeben. Wenn ein Validator die Führung im BABE Slot gewinnt, wählt er die Kandidatenbelege aus, um einen Relay Chain Block zu erstellen.

Die Transaktionswarteschlange kann Hunderte von Parachain-Kandidaten enthalten. Wie entscheidet der Blockautor, welche er in einen Block aufnimmt?

Zunächst nimmt der Autor des Blocks nur Quittungskandidaten auf, die einen übergeordneten Quittungskandidaten in einem früheren Relay Chain-Block haben. Diese Prüfung stellt sicher, dass die Parachain einer gültigen Chain folgt.

Zweitens nimmt der Autor des Blocks nur Quittungskandidaten auf, für die er ein Erasure Coding Chunk hat. Ein Parachain-Validator sendet seine Chunks an alle anderen Validatoren im Netzwerk, so dass jeder Validator Chunks von jeder Parachain haben sollte. Indem er nur Quittungskandidaten aufnimmt, für die der Autor einen Chunk hat, stellt er sicher, dass das System die nächste Runde der Verfügbarkeits- und Gültigkeitsprüfungen durchführen kann.

Hermit Relay Chain

Der Autor hat bereits erwähnt, dass eine Strategie für Skalierbarkeit darin besteht, Informationen an den Rand des Systems zu verlagern. Eine unserer Ideen mit Polkadot ist es, Polkadot selbst zu einer Parachain zu machen. Das bedeutet, dass alle Transaktionen für Token-Transfers, Staking, Governance usw. in einer Parachain von Polkadot stattfinden würden, wobei die Quittungen der Kandidaten von der Relay Chain abgeschlossen werden. In diesem Fall würden die Blöcke der Relay Chain ausschließlich aus Quittungskandidaten bestehen.

IV. Finale

Die meisten Sharded Blockchain-Protokolle erfordern eine große Anzahl von Validatoren auf jedem Shard. Die Erasure Coding-Funktion von Polkadot und die zusätzlichen Überprüfungen, die als Nächstes erfolgen, sind der Vorteil, der es ermöglicht, die gleichen Gültigkeitsgarantien auf jedem Shard mit nur zehn Validatoren pro Shard zu bieten.

Die Verfügbarkeitsprüfung durch den Blockautor stellt sicher, dass Polkadot nur Blöcke aufnimmt, für die die Validatoren ihre Chunks verteilt haben, aber sie garantiert nicht deren Gültigkeit. Da die Anzahl der Validatoren auf jedem Parachain so gering ist, sind geheime Absprachen zu befürchten. Durch die Trennung der Blockproduktion (BABE) von der Finalität (GRANDPA) kann Polkadot zusätzliche Gültigkeitsprüfungen durchführen, nachdem ein Block produziert wurde, aber bevor er finalisiert wird.[3] Polkadot hat spezielle Akteure, die Fischer, die die Blöcke der Relay Chain auf ungültige Empfangskandidaten überprüfen.

Ein Fischer ist im Wesentlichen ein Parachain Full Node, der einige Dot-Token auf dem Spiel hat. Während Parachain-Kollatoren keine Dot-Token staken müssen [4] - sie brauchen nur Anreize aus ihrer eigenen Parachain, um Blöcke zu erstellen - müssen Fischer Dot-Token als Anti-Spam-Mechanismus staken. Ohne einen Wert auf dem Staking könnten Fischer gefälschte Ungültigkeitserklärungen einreichen.

Sobald ein Block zur Relay Chain hinzugefügt wird, beginnt eine Verifizierungsphase, in der zufällig ausgewählte Validatoren Sekundärprüfungen durchführen müssen, um die Verfügbarkeit und Gültigkeit der darin enthaltenen Empfangskandidaten zu testen. Eine sekundäre Prüfung besteht darin, genügend Erasure Coding Chunks anzufordern, um den verschlüsselten Block zu rekonstruieren und einen Gültigkeitsnachweis zu erbringen, um den Zustandsübergang zu validieren.

Wenn ein Validator einen neuen Block erstellt, sendet er den Block an seine Verbindungen im Netzwerk, die den neuen Block an ihre Verbindungen weiterleiten. Wenn ein Validator einen Block importiert, prüft er, ob er für jeden Empfangskandidaten im Block einen Erasure Coding Chunk hat. Fehlen Chunks, dann alarmiert der Validator die anderen. Wenn mehr als ein Drittel der Validatoren innerhalb einer bestimmten Zeitspanne Warnungen über fehlende Chunks senden, wird der Block verworfen.

Sobald der Block die Gnadenfrist überstanden hat, beginnen die sekundären Prüfungen. Die Anzahl der sekundären Prüfungen, die Polkadot benötigt, hängt von den Kollatoren und Fischern ab, die die Verfügbarkeit bzw. die Gültigkeit der Quittungsanwärter prüfen. Wenn ein Fischer einen Block entdeckt, den er für ungültig hält, reicht er eine Ungültigkeitserklärung zusammen mit einem Staking von Dot-Tokens ein. Ebenso reichen Kollatoren Nichtverfügbarkeitserklärungen ein. Blöcke mit mehr Ungültigkeits- oder Nichtverfügbarkeitserklärungen erfordern mehr sekundäre Überprüfungen durch Validatoren, bis hin zu der Anforderung, dass mehr als ein Drittel der Validatoren die Gültigkeit oder Ungültigkeit eines Blocks bestätigen müssen. Wenn mehr als ein Drittel der Validatoren einen Block als ungültig einstufen, wird der Block wie bei der Nichtverfügbarkeits-Frist verworfen[5].

Die Rolle der Kollatoren und Fischer, die zusätzliche Verfügbarkeits- und Gültigkeitsprüfungen durchführen, verlagert die Skalierbarkeit weiter an den Rand und weg von den Validatoren der Relay Chain. Wenn die Anzahl der Parachains steigt, steigt auch die Anzahl der Kollatoren und Fischer, die diese Prüfungen durchführen können, ohne die Validatoren weiter zu belasten. Die zusätzlichen Prüfungen halten die Arbeitsbelastung der Validatoren gering, da sie in erster Linie dazu dienen, Unstimmigkeiten zu beseitigen.

Nachdem genügend sekundäre Prüfungen für alle Quittungskandidaten innerhalb eines Blocks durchgeführt wurden, können die Validatoren schließlich für diesen Block (und damit für alle vorherigen Blöcke) in GRANDPA abstimmen. Sobald er mehr als zwei Drittel der Pre-Commits hat, befindet sich der Block in der finalisierten Chain.

Validatoren können erst dann über Blöcke abstimmen, wenn die Validatoren genügend Sekundärprüfungen durchgeführt haben. Mit dieser Funktion verfügt die Relay Chain über drei Zonen: die abgeschlossene Chain, die GRANDPA-Abstimmungszone mit gültigen Kandidaten für die Finalisierung und die Angelzone, in der Blöcke auf Verfügbarkeit und Gültigkeit geprüft werden müssen.

Alle Parachains in Polkadot folgen der Finalität der Relay Chain. Künftige Parachain-Blöcke müssen immer auf den Empfangskandidaten aufbauen, die sich in der abgeschlossenen Relay Chain befinden. Alle Verfügbarkeits- und Gültigkeitsprüfungen sollten in weniger als einer Minute stattfinden, vom Zeitpunkt der Erstellung eines Blocks bis zu seiner Fertigstellung.

Nach der Fertigstellung profitiert der Block von der gemeinsamen Sicherheitsumgebung, die es den Chains ermöglicht, auf vertrauenslose Weise miteinander zu interagieren, während eine Rückgängigmachung des Blocks die Rückgängigmachung von ganz Polkadot erfordern würde. Die Umkehrung des gesamten Netzwerks ist eine mühsame Aufgabe, die es zu vermeiden gilt. Deshalb müssen Validatoren, Kollatoren und Fishermen mit mozartscher Präzision für gültige Zustandsübergänge sorgen. Das Framework von Erasure Coding und unser BABE/GRANDPA-Konsens ermöglichen es Polkadot, diese Garantien schneller und skalierbarer als jedes andere Blockchain-Netzwerk zu bieten.

Coda

In diesem Artikel wurde nur die Validierung von Parachain-Blöcken besprochen, aber es wurde auf eine Umgebung für vertrauensfreie Nachrichten zwischen Parachains angespielt. Da die gleichen Validatoren alle Parachains absichern, haben Cross-Chain-Nachrichten die gleiche Integrität wie kontoübergreifende Nachrichten innerhalb einer einzigen Chain, zum Beispiel die Kommunikation zwischen Contracts auf Ethereum.

Im Cross-Chain-Message-Passing-Protokoll (XCMP) von Polkadot stellen Parachains direkte Kanäle zwischen sich her. Parachains, die sich volle Nodes teilen, können direkt Nachrichten austauschen, während Parachains, die sich keine vollen Nodes teilen, ihre Nachrichten von Validatoren anfordern. Nur Kanaloperationen, z.B. das Öffnen und Schließen, und Zustellungsnachweise gehen in die Relay Chain ein. XCMP ist nur eine weitere Möglichkeit, wie Polkadot skaliert, indem es Informationen an die Ränder verlagert und gleichzeitig die notwendigen Garantien für eine vertrauensfreie Interaktion bietet.

Weitere Informationen zur Cross-Chain-Kommunikation finden Sie in Polkadot's Messaging Scheme.

Weitere Informationen über BABE und GRANDPA finden Sie in der Polkadot Consensus Series.

Anmerkungen

1. In diesem Artikel wird immer "Parachains" verwendet, aber alles hier gilt auch für Parathreads, sofern nicht ausdrücklich darauf hingewiesen wird.
2. Natürlich müssen die Benutzer entscheiden, was "gültig" in Bezug auf den Status bedeutet.
3. Diese Trennung dient auch der Spamvermeidung. Validatoren prüfen nur die Quittungen, die sich in einem Block befinden, und nicht jede Quittung, die ein Parachain einreicht.
4. Während dies für Parachain-Kollatoren gilt, müssen Parathread-Kollatoren DOT-Token besitzen, um an Blockauktionen teilzunehmen und ihre Blockausführung zu planen. Da Parachain-Kollatoren jedoch in der Lage sind, als Fischer zu agieren, können sie problemlos beide Rollen übernehmen.
5. Es mag seltsam erscheinen, dass das Überschreiten der Ein-Drittel-Schwelle ausreicht, um einen Block zu akzeptieren oder abzulehnen, obwohl beide Teilmengen in einer Menge ohne Schnittpunkt existieren könnten. Byzantinische fehlertolerante Systeme erfordern jedoch, dass weniger als ein Drittel der Validatoren fehlerhaft sind. Wenn mehr als ein Drittel der Validatoren einen Block für gültig und mehr als ein Drittel der Validatoren einen Block für ungültig erklären, dann sind die Annahmen des Systems nicht mehr gültig.