In diesem Beitrag geht es um die Technologie, die Polkadot antreibt. Polkadot ist eine Sharded Blockchain mit heterogenen Shards. Sharding bedeutet in diesem Zusammenhang, dass die anfallende Arbeit auf mehrere Sub-Blockchains, die sogenannten Parachains, aufgeteilt wird. Heterogen bedeutet in diesem Zusammenhang, dass jede Blockchain ihre eigene Zustandsübergangsfunktion hat, die speziell für einen bestimmten Anwendungsfall entwickelt wurde. Unterschiedliche Arten von Transaktionen werden unterschiedliche Häuser haben, so dass spezialisierte Chains ihren Nutzern am effizientesten dienen können. Polkadot bietet Sicherheits- und Messaging-Funktionen für alle angeschlossenen Parachains.

Dieser Beitrag ist in erster Linie für ein technisches Publikum mit einigen Kenntnissen über Blockchain-Konsens geschrieben. Der Autor hofft, dass er auch für Menschen außerhalb dieses Publikums nützlich ist und einen Einblick in die Probleme und Herausforderungen gibt, mit denen Basis-Blockchains konfrontiert sind, und wie Polkadot diese Probleme angeht. Der Autor wird nicht auf jede Nuance ihrer Lösungen eingehen, aber er wird eine ausführliche Beschreibung der Dinge geben, die sie berücksichtigen und wie sie die Garantien bieten, die sie anstreben.

Die Chains vor der Chain

Ein vereinfachtes Verständnis der Blockchain beinhaltet nur eine einzige Chain, die sich von der Entstehung bis zum Kopf der Chain erstreckt. Für viele Menschen ist dies das einzige Konzept der Chain, das von Bedeutung ist - sie repräsentiert alle Zustandsübergänge, die stattgefunden haben und auf die sich das Netzwerk geeinigt hat. Das Endziel eines jeden Blockchain-Konsenssystems ist es, den Beobachtern diese Quelle der Wahrheit zur Verfügung zu stellen. Diese einzelne Chain, die wir als die endgültige oder kanonische Chain bezeichnen können, ist jedoch nur der letzte Überlebende von vielen möglichen konkurrierenden Chains, die es hätte geben können. Die Rolle des Konsensalgorithmus der Blockchain besteht darin, mit vielen möglichen Chains zu beginnen und letztendlich nur eine von ihnen zu finalisieren.

Die Autoren der Blöcke konkurrieren um das Recht, den nächsten Block zu erstellen, aber es kann mehr als einen Gewinner geben. Beim Proof of Work verdienen sich Miner das Recht, einen bestimmten Block zu erstellen, indem sie einen Weg finden, einen neuen Block zu produzieren, dessen Hashwert einer eindeutigen Zufallszahl entspricht, die unter eine schwierige Vorgabe fällt. Es kann eine große Anzahl von Versuchen erfordern, bevor ein Miner einen Block findet, der diese Bedingung in einem ausreichend kompetitiven Umfeld erfüllt. Zum Vergleich: Die kumulative Hashrate des Bitcoin-Netzwerks beträgt zum Zeitpunkt der Erstellung dieses Artikels 162 Exahashes pro Sekunde, was bedeutet, dass Bitcoin-Miner insgesamt 162 Trillionen Mal pro Sekunde versuchen, sich das Recht zu verdienen, den nächsten Block beizusteuern, und das Schwierigkeitsziel ist so festgelegt, dass im Durchschnitt nur ein Hash alle 10 Minuten unter dem Zielwert liegt. Beachten Sie, dass es möglich ist, dass mehrere Miner ungefähr gleichzeitig eine Lösung finden, was zu einer kleinen Gabelung in der Blockchain führt. Künftige Miner müssen sich entscheiden, auf welchen dieser Blöcke sie minen wollen, was dazu führen kann, dass sich die Forks verlängern. Die Regel ist, der längsten Chain zu folgen, und es wird für einen Angreifer, der von einem vergangenen Block ausgeht, immer schwieriger, eine längere Chain einzuholen und zu überwältigen. Daher kann ein Block, der tief genug in die längste Chain eindringt, mit hoher Wahrscheinlichkeit als endgültig angesehen werden.

Die Ouroboros-Familie von Proof-of-Stake-Protokollen verwendet eine kryptografische Technologie, die als Verifiable Random Functions (VRFs) bekannt ist, um Proof of Work zu simulieren, indem sie die Zeit in diskrete Slots unterteilt und jedem Validator aus einer registrierten und gestaketen Gruppe von Validatoren (der Validatorensatz) die Möglichkeit gibt, einen verifizierbaren Zufallswert pro Zeitslot zu erzeugen, der, wenn er unter einem Schwellenwert liegt, als Berechtigungsnachweis dient, um dem Validator zu erlauben, einen neuen Block zu erstellen. Wie beim Proof of Work können mehrere Validatoren mit ihren VRFs einen Wert erzeugen, der unter den Schwellenwert fällt, und gleichzeitig Blöcke erstellen, was zu Forks führt. Validatoren werden davon abgehalten, absichtlich Forks zu erstellen, d.h. ihre Berechtigungsnachweise zu verwenden, um mehrere Blöcke innerhalb desselben Slots zu erstellen, indem ihr Staking auf der Kette reduziert wird. Diese Protokolle bieten auch eine probabilistische Endgültigkeit unter der Wahl der längsten Chain-Fork-Regel.

Im Gegensatz zu Minern in Proof-of-Work-Prozessen müssen Validatoren in einem Netzwerk im Ouroboros-Stil nur eine einzige Berechnung durchführen, um einen Block zu erstellen, im Gegensatz zu den absurd vielen Hashes, die Miner durchführen müssen. Auf diese Weise können Validatoren die meiste Zeit darauf verwenden, einen Block mit Transaktionen zu erstellen, und die Blockchain kann in der Folge mehr wertvolle Berechnungen enthalten.

Die Relay Chain von Polkadot verwendet ein Protokoll namens BABE, das eine Weiterentwicklung von Ouroboros Praos ist. Die besondere Verbesserung von BABE gegenüber Praos besteht darin, dass BABE die Abhängigkeit von zentralisierten NTP-Servern vermeidet, damit die Validatoren die aktuelle Zeit kennen.

BABE Papier

BABE Erklärungsbeitrag

BABE ist forkvoll, mit probabilistischer Endgültigkeit

Während probabilistische Endgültigkeit in Ordnung ist, ist das Warten darauf, dass ein Block eine bestimmte Tiefe in der längsten Chain erreicht, ein ineffizienter Mechanismus, da er für einen vorweggenommenen Worst-Case ausgelegt ist, bei dem das Netzwerk einem gewissen Grad an Belastung und Angriffen ausgesetzt ist. Es kann sein, dass sich die Mehrheit des Netzwerks bereits darüber einig ist, welche Blöcke Teil der kanonischen Chain sind. Tatsächlich wird sich das Netzwerk in fast allen Fällen darauf einigen können, dass ein Block kanonisch ist, lange bevor er die minimale Tiefe in der längsten Chain erreicht. Zu diesem Zweck führen wir die Konzepte eines Finalitätsgadgets und der absoluten Finalität ein. Ein Finality Gadget ist ein sekundäres Konsensprotokoll, das auf einer probabilistisch finalen Blockchain läuft und eine schnellere Einigung darüber beweist, welche Blöcke das Netzwerk als final betrachtet. Diese Konsensprotokolle führen eine weitere wirtschaftliche Sicherheitseigenschaft ein: Das Finalitätsprotokoll wird niemals zwei konkurrierende Blöcke finalisieren, ohne mindestens 1/3+ des Gesamt-Stakes des Validatorsets zu streichen.

Die Relay Chain von Polkadot verwendet eine Finalitätshilfe namens GRANDPA. Es kann eine nahezu sofortige Finalität für Sub-Chains beliebiger Länge erreichen und funktioniert in etwa so, dass die Validatoren wiederholt über die Blöcke abstimmen, die ihrer Meinung nach an der Spitze der längsten Chain stehen. GRANDPA funktioniert derzeit in den Netzwerken Polkadot und Kusama. In Kusama, das zum Zeitpunkt der Erstellung dieses Artikels 900 Validatoren hat, kann es neue Blöcke innerhalb von 3 Sekunden abschließen.

GRANDPA Papier

GRANDPA Erklärungsbeitrag

Validatoren stimmen über die Chain ab, die sie für die beste halten, und der Algorithmus lässt sie sich auf einen gemeinsamen Block einigen, der finalisiert wird.

Die Kombination von BABE und GRANDPA ermöglicht es Polkadot, die Chain optimistisch mit dem Input von nur einem einzigen Validator wachsen zu lassen, was schnell ist, und diese im Hintergrund abzuschließen, indem es die Zustimmung einer Supermajorität von Validatoren erhält. Diese Kombination von Eigenschaften bedeutet, dass Polkadot unter guten Netzwerkbedingungen einen hohen Durchsatz und eine niedrige Latenzzeit erreicht. Unter schlechten Netzwerkbedingungen erreicht die Relay Chain einen hohen Durchsatz und eine hohe Latenzzeit, da GRANDPA die probabilistische Finalität von BABE verfolgt.

Sharding: Skalierung durch Teilmengenauswahl

Kehren wir zum Sharding zurück. Das Ziel des Sharding ist es, den Durchsatz zu verbessern, indem die Arbeit in Form von Transaktionen auf viele Chains, die sogenannten Shards, aufgeteilt wird. Die Shards werden von einer Top-Level-Blockchain referenziert und gesichert. In Polkadot wird die Top-Level-Blockchain Relay Chain genannt und die Shards sind Parachains. Die meisten Daten, die in der Relay Chain erscheinen, sind Transaktionen, die Verweise auf neue Parachain-Blöcke enthalten, was die Verarbeitung jeder Abspaltung der Relay Chain selbst billig macht. Beachten Sie, dass ich hier einen Unterschied zwischen beliebigen Abzweigungen der Relay Chain und der fertigen Relay Chain mache. Der größte Teil unserer Arbeit hier besteht darin, sicherzustellen, dass der abgeschlossene Teil der Relay Chain, den die Benutzer als die kanonische Chain betrachten, nur Verweise auf gültige Parachain-Blöcke enthält.

Dieses Diagramm oder ähnliche Diagramme sind im Internet weit verbreitet. Sie zeigen, wie Validatoren in Gruppen aufgeteilt und Parachains zugewiesen werden und von Kollatoren Vorschläge für Parachain-Blöcke erhalten. In diesem Beitrag habe ich visuelle Erklärungen für viele der nuancierteren Konzepte erstellt.

Sharding ist nur dann eine Verbesserung der Skalierbarkeit, wenn jeder Validator nur einen Teil der eingereichten Parachain-Blöcke prüfen muss, und nicht alle. Wenn es 10 Parachains gäbe und jeder Validator alle Blöcke von allen 10 Chains prüfen müsste, könnten wir genauso gut alle Transaktionen auf eine Blockchain packen und Feierabend machen. Der Trick besteht darin, einen Weg zu finden, wie jeder Validator so wenig Verifizierungsarbeit wie möglich leisten muss, ohne die wirtschaftliche Sicherheit zu gefährden: dass Validatoren, die für schlechte Parachain-Blöcke eintreten, wirtschaftlich davon abgehalten werden, dies zu tun. Konkret bedeutet dies, dass es für eine gegnerische Gruppe von Validatoren unmöglich sein sollte, sich abzusprechen, um einen schlechten Parachain-Block in die endgültige Relay Chain aufzunehmen, bevor sie ihren gesamten Stake durch Slashing verlieren. Validatoren und sogar kleine Untergruppen von Validatoren können sich absprechen, um schlechte Parachain-Blöcke zu erhalten, die von nicht finalisierten Abzweigungen der Relay Chain referenziert werden, aber wir garantieren, dass diese Abzweigungen vor der Finalität ignoriert werden und die Übeltäter zerschlagen werden.

Parachain-Blöcke werden finalisiert, wenn ein Relay Chain-Block, der auf sie verweist, finalisiert wird

Parachain-Blöcke werden abgeschlossen, wenn ein Relay Chain-Block, der auf sie verweist, abgeschlossen ist.

Lassen Sie uns einige konkrete Annahmen über den Angreifer, gegen den wir uns verteidigen, aufstellen:

Der Angreifer kann bis zu 1/3 aller Validatoren kontrollieren und kann alle diese Validatoren so steuern, dass sie sich genau wie gewünscht verhalten.
Der Angreifer kann alle Netzwerknachrichten zwischen ehrlichen Validatoren und den von ihm kontrollierten Validatoren einsehen.
Der Angreifer kann jederzeit bis zu X% der Validatoren angreifen und sie daran hindern, Nachrichten zu senden oder zu empfangen.
Es dauert eine feste Verzögerung, bevor der Angreifer mit dem DoS eines Validators beginnen kann.

Der Autor wird in diesem Beitrag keinen formalen Sicherheitsbeweis für das Protokoll erbringen, aber diese Einschränkungen sollten einen Einblick in die Arten von Angriffen geben, gegen die sie sich schützen wollen.

Die Basiseinheit für den Parachain-Konsens ist nicht wirklich ein Parachain, sondern etwas, das sie als Verfügbarkeitskern oder kurz Core bezeichnen. Diese sind so etwas wie CPU-Kerne: Sie arbeiten parallel und sind in diskreten Slots mit Arbeit belegt. Jeder Parachain hat seinen eigenen Kern, d.h. er wird immer auf einem bestimmten Kern eingeplant. Wir können jedoch auch mehrere Chains auf einen einzigen Kern verteilen. Der einzige Unterschied ist der Planungsalgorithmus.

Cores dienen als effektive Beschreibung des Durchsatzes der Relay Chain. Die Kerne entsprechen direkt dem Arbeitsaufwand, den die Validatoren leisten müssen. Jeder Kern kann in der Spitze bis zu einem Parachain-Block pro Relay Chain-Block verarbeiten.

In jedem Sharded Blockchain-System, in dem nur einige Validatoren jeden Parachain-Block prüfen, ist die Datenverfügbarkeit eine entscheidende Komponente, um sicherzustellen, dass die für die Prüfung eines Parachain-Blocks erforderlichen Daten zum Zweck der Betrugserkennung wiederhergestellt werden können. Verfügbarkeitskerne werden von der Relay Chain verwaltet und verfolgen, welche Parachain-Blöcke zur Datenverfügbarkeit anstehen. Der Hauptzweck von Verfügbarkeitskernen ist eine primitive Planungsfunktion und die Bereitstellung von Gegendruck, wenn die Datenverfügbarkeit langsamer als gewöhnlich ist.

Die Logik eines Verfügbarkeitskerns sieht folgendermaßen aus. Die Kerne sind leer, wenn sie bereit sind, einen neuen Parachain-Block aufzunehmen, und werden dann belegt. Dann werden die Daten entweder verfügbar oder der Verfügbarkeitsprozess läuft aus. Zu diesem Zeitpunkt wird der Kern wieder leer.

Es ist hilfreich, die Parachain-Konsensierung in 5 verschiedene Protokolle aufzuteilen, die in der Relay-Chain-Konsensierung miteinander verwoben sind.

1. Collation (Kollationierung)

2. Backing (Sicherung)

3. Availability (Verfügbarkeit)

4. Approval Checking (Prüfung der Genehmigung)

5. Disputes (Rechtsstreitigkeiten)

Collation ist der Prozess, durch den Parachain-Blöcke erstellt werden. Kollatoren erstellen einen Parachain-Block und senden ihn an Validatoren.

Backing ist der Prozess, bei dem Parachain-Blöcke zunächst von einer kleinen Gruppe von Relay Chain-Validatoren geprüft und in der Relay Chain registriert werden. Der Hauptnebeneffekt des Backing ist, dass die Validatoren sich selbst einem Risiko aussetzen müssen, wenn die späteren Protokolle versagen.

Availability ist der Prozess, bei dem die Backing Validatoren Teile der Daten verteilen, die für die Prüfung des Parachain-Blocks erforderlich sind, und sicherstellen, dass diese für eine spätere Prüfung verfügbar sind.

Approval Checking ist der Prozess, bei dem zufällige Validatoren die Daten wiederherstellen und den Parachain-Block ausführen. Je nachdem, ob sie den Parachain-Block für gültig halten, genehmigen sie ihn oder lösen einen Streitfall aus.

Disputes sind der Prozess, durch den widersprüchliche Meinungen von Validatoren zu einem Parachain-Block aufgelöst und schlechte Parachain-Blöcke ignoriert und Übeltäter bestraft werden. Streitfälle sind nur als Ausfallsicherung gedacht und werden voraussichtlich nicht oft ausgelöst.

Beachten Sie, dass die Validatoren wahrscheinlich jedes dieser Protokolle gleichzeitig anwenden, oft sogar in mehreren Instanzen. So kann ein Validator beispielsweise an der Abstimmung über einen Parachain-Block teilnehmen, der sich weiter unten in der Pipeline befindet, während er gleichzeitig an der Unterstützung eines neueren Blocks und an Streitigkeiten für einen noch älteren Block beteiligt ist.

Diese interne Parallelität spiegelt auch die Architektur der Implementierung wider: Jedes dieser Protokolle ist als unabhängiges Subsystem implementiert, und alle Subsysteme laufen parallel. Jeder Node macht immer ein bisschen von allem.

Blöcke einreichen und Parachains anbauen

In diesem Abschnitt erfahren Sie, wie Parachains in Verbindung mit der Relay Chain wachsen.

Die Aufnahme eines potenziellen Parachain-Blocks in eine Parachain erfolgt in 2 Schritten. Der erste besteht darin, dass der Parachain-Block von einem Relay Chain-Block referenziert wird, zusammen mit Bestätigungen über seine Gültigkeit. Der nächste Schritt besteht darin, dass die entsprechenden Daten, die zur Überprüfung des Parachain-Blocks erforderlich sind, in einem nachfolgenden Relay Chain-Block als verfügbar bestätigt werden.

Da die Relay Chain kurzfristige Abzweigungen haben kann, kann auch jede Parachain kurzfristige Abzweigungen haben. Wenn es zwei konkurrierende Relay Chain-Blöcke A und B auf einer bestimmten Höhe gibt und A den Parachain-Block P und B den Parachain-Block P' enthält, dann stellt dies ebenfalls eine Gabelung in der Parachain dar.

Für die Zwecke dieses Beitrags betrachten wir eine vereinfachte Version des Relay Chain-Zustandsautomaten von Polkadot. Zur Erinnerung: Jeder Block in einem Zweig der Relay Chain stellt einen Übergang vom vorherigen Zustand zum nächsten Zustand dar.

Jeder Block steht für eine atomare Einheit der Veränderung vom vorherigen Zustand der Blockchain zu einem neuen Zustand. Kontostände, Verfügbarkeitskerne, Governance-Vorschläge und Smart Contracts sind alles Beispiele für Dinge, die Teil des Zustands einer Blockchain sind. Blöcke aktualisieren den Zustand entweder durch inhärente Logik oder durch Transaktionen. Inhärente Logik bezieht sich auf Zustandsaktualisierungen, die auch ohne Transaktionen stattfinden müssen, weil die Zeit vergeht oder die Blocknummer fortschreitet.

Beim Aufbau einer Blockchain besteht das typische Design-Muster darin, dass Nodes Informationen sammeln und Arbeiten außerhalb der Chain ausführen und dann eine Aufzeichnung der Arbeit auf der Chain platzieren. Als Beispiel können Sie die Aufnahme von Transaktionen durch das gleiche Objektiv betrachten. Nodes nehmen an einem Off-Chain-Klatschprotokoll teil, um neue Transaktionen zu sammeln, und der Autor des Blocks bündelt dann seine Auswahl an Transaktionen zu einem Block. Parachains funktionieren auf die gleiche Weise: Der größte Teil der Arbeit findet außerhalb der Chain statt, aber die Aufzeichnungen der Arbeit werden in der Relay Chain aufbewahrt, um einen kanonischen Hinweis auf den Konsens zu liefern.

Die Arbeit, die die Nodes außerhalb der Kette leisten, um Parachains wachsen zu lassen, umfasst Kollation, Sicherung und Verfügbarkeit.

Die Nodes überwachen die letzten Blöcke der Relay Chain, um festzustellen, welche Arbeiten sie durchführen sollten.

Ein Kollator besteht aus einem Parachain-Kopf und einem PoV oder Gültigkeitsnachweis, der alle Daten enthält, die benötigt werden, um den Übergang vom vorherigen Parachain-Kopf zum aktuellen Kopf zu überprüfen. Nur die Köpfe wandern auf der Chain, aber die PoVs müssen verfügbar gemacht werden. Wir verwenden die Löschkodierung, um sicherzustellen, dass die PoVs verfügbar sind: Die Daten werden in Teile, so genannte Chunks, aufgeteilt, einen für jeden Validator, und jede ausreichend große Teilmenge der Chunks kann die vollständigen Daten wiederherstellen. Dies bietet Schutz vor Nodes, die offline gehen oder lügen, wenn sie behaupten, ihren Teil der Daten zu besitzen.

In diesem Beispiel sind die Daten in 9 Teile aufgeteilt und jede Teilmenge von 4 oder mehr kann die vollständigen Daten wiederherstellen

Wenn ein Validator feststellt, dass ein Verfügbarkeitskern leer ist und die auf diesem Kern geplante Parachain eine ist, der der Node zugewiesen ist, versucht er, eine Kollation von einem Kollator zu erhalten und am Backing-Prozess teilzunehmen. Neue potenzielle Parachain-Blöcke werden zusammen mit ihren Bestätigungen durch Validatoren über ein Gossip-System verbreitet. Das bedeutet, dass jeder gut vernetzte Node über jeden nächsten potenziellen Parachain-Block informiert ist. Der nächste Autor eines Relay Chain-Blocks überwacht den Zustand des Netzwerks und wählt eine Reihe neuer Parachain-Blöcke aus, die in dem von ihm erstellten Relay Chain-Block unterstützt werden.

Das folgende Flussdiagramm beschreibt grob die Logik, die Validatoren für den Backing-Prozess ausführen. Sie führen diese Logik immer dann aus, wenn der Verfügbarkeitskern für die Parachain leer ist.

Dieses Diagramm zeigt, wie Validatoren frische Parachain-Blöcke von Kollatoren erhalten und mit anderen Validatoren zusammenarbeiten, um genügend Unterstützung von den zugewiesenen Validatoren zu erhalten. Validatoren, die der Parachain nicht zugewiesen sind, hören trotzdem auf die Bescheinigungen, denn der Validator, der am Ende der Autor des Relay Chain-Blocks ist, muss die bescheinigten Parachain-Blöcke für mehrere Parachains bündeln und in den Relay Chain-Block einfügen.

Sobald ein Parachain-Block in der Chain unterstützt wird (d.h. sein Header ist in einem Relay-Chain-Block zusammen mit Bestätigungen ausgewählter Validatoren erschienen und er hat verschiedene Unbedenklichkeitsprüfungen bestanden), beginnt er, den Verfügbarkeitskern zu belegen.

Wenn ein Validator feststellt, dass ein Verfügbarkeitskern belegt ist, versucht er, seinen Teil des löschungscodierten PoV abzuholen, wenn er nicht zu der Gruppe von Validatoren gehört, die den Block ursprünglich bescheinigt haben. Andernfalls ist der Validator für die Verteilung der Chunks an die entsprechenden Validatoren verantwortlich.

Verteilung der Verfügbarkeit: Validatoren ohne Rückendeckung fordern ihre Chunks von den Validatoren mit Rückendeckung an. Einige der nicht-unterstützenden Validatoren sind möglicherweise nicht in der Lage, eine direkte Verbindung herzustellen, aber das ist in Ordnung, solange es genügend sind.

Validatoren fordern ihre Datenpakete von den Backing Validators an, die sie verteilen müssen.

Jeder Validator unterschreibt Aussagen darüber, für welche Parachain-Blöcke er seine Chunks hat und gibt diese Aussagen weiter. Der Autor des Relay-Chain-Blocks nimmt diese Aussagen in die Relay Chain auf. Sobald 2/3+ der Validatoren angegeben haben, dass sie ihren Chunk für den Parachain-Block haben, der einen Kern belegt, gilt der Parachain-Block als verfügbar und wird offiziell als Teil der Parachain aufgenommen und der Kern wird wieder frei gemacht.

Wenn die Verfügbarkeit nicht innerhalb einer bestimmten Anzahl von Blöcken erreicht wird, wird der Kern als frei betrachtet und der Parachain-Block, der den Kern belegt, wird aufgegeben.

Verfügbarkeit Core Logic als Wiederholung

Zusammenfassend lässt sich sagen, dass die Backing- und Availability-Protokolle sicherstellen, dass ein Parachain-Block zum Zeitpunkt seiner Aufnahme von einer kleinen Handvoll Validatoren bestätigt wurde und dass die Verfügbarkeit des PoV, der zur Überprüfung des Parachain-Blocks benötigt wird, von mindestens 2/3 der Validatoren bestätigt wurde. Anders ausgedrückt, geht es bei der Unterstützung und der Verfügbarkeit darum, die Verantwortung für das Spiel zu übernehmen und durchzusetzen. In den nächsten Abschnitten wird erörtert, wie Polkadot sicherstellt, dass kein Parachain-Block finalisiert wird, ohne gründlich geprüft zu werden.

Approval Checking und Finalität

Approval Checking ist ein Mechanismus, mit dem Validatoren nach dem Zufallsprinzip selbständig verfügbare Parachain-Blöcke prüfen und die Absicht und die Ergebnisse ihrer Prüfungen dem Rest des Netzwerks mitteilen.

Lassen wir den eigentlichen Prozess der Genehmigungsprüfung erst einmal als Blackbox stehen. Wir beginnen damit, einige Hintergrundinformationen darüber zu geben, was dieses Protokoll tun soll, damit später klar wird, warum es so funktioniert, wie es funktioniert.

Wie wir bereits festgestellt haben, nimmt jeder Validator Node an GRANDPA, dem Finalitätsgadget, teil. GRANDPA läuft in Runden ab, und wir können eine stark vereinfachte Version der Arbeit, die jeder Validator in jeder GRANDPA-Runde leistet, als die Wiederholung dieser Schritte betrachten:

Die nächste Runde beginnt
Wählen Sie einen Finalitätszielblock: den besten Block, den wir gerne finalisieren würden
Geben Sie eine Stimme für das Finalitätsziel ab
Warten Sie auf die Stimmen der anderen Validatoren
Finden Sie den höchsten gemeinsamen Block, der in mindestens 2/3 der von den Validatoren abgestimmten Chains vorkommt
Schließen Sie diesen Block ab
Runde endet

Die einzige Flexibilität, die ein Validator in diesem Prozess hat, ist Schritt 2: die Wahl des Blocks, über den er als Ziel für die Endgültigkeit abstimmt. Diese Wahl wird als Abstimmungsregel bezeichnet. Bei GRANDPA wählt jeder Validator einfach den längsten Zweig der Relay Chain, den er kennt, und gibt den Kopf dieser Chain als Stimmziel an. Für den Parachain-Konsens führen wir jedoch eine neue Abstimmungsregel ein.

Die GRANDPA-Abstimmungsregel für die Zustimmungsprüfung besagt, dass jeder Validator seine Stimme abgeben sollte:

1. Wählen Sie den längsten Zweig der Relay Chain

2. Finden Sie den höchsten Block B in der Chain, so dass jeder Block zwischen dem aktuellen abgeschlossenen Block und bis zu B nur Parachain-Blöcke einschließt, die nach Beobachtung des Validators von genügend Validatoren genehmigt worden sind.

Lassen Sie uns das näher erläutern. Denken Sie daran, dass ein Hauptziel darin besteht, dass das Netzwerk nur Parachain-Blöcke finalisiert, die tatsächlich gut sind, und dass jeder Validator so wenig Arbeit wie möglich hat, damit das Netzwerk skalieren kann. Also in Teilen:

Finden Sie den höchsten Block B in der Chain: Wir wollen, dass jeder Node über den höchstmöglichen Block abstimmt, der die anderen Kriterien erfüllt, damit die Finalität so schnell wie möglich voranschreitet.
so dass jeder Block zwischen dem aktuellen finalen Block und bis zu B: Die Abstimmungsregel benötigt Validatoren, um über eine Chain abzustimmen, die nur gute Parachain-Blöcke enthält. In GRANDPA zählt eine Abstimmung über einen Block als eine Abstimmung über alle seine Vorgänger. Selbst wenn Block 100 also nur gute Parachain-Blöcke enthält, sind die Blöcke 99 und 98 möglicherweise nicht gut. Deshalb muss die Abstimmungsregel die höchste zusammenhängende Chain von Relay Chain-Blöcken finden, die die anderen Kriterien erfüllt.
löst nur die Einbeziehung von Parachain-Blöcken aus: Wie im Abschnitt über die Parachain-Erweiterung beschrieben, geht es hier darum, dass die Parachain-Blöcke aufgrund der Verfügbarkeitsbescheinigungen im Relay Chain-Block verfügbar geworden sind und dass die Parachain-Blöcke der Parachain hinzugefügt worden sind. Parachain-Blöcke, die noch nicht verfügbar sind, zählen noch nicht als Teil der Parachain.
dass der Validator festgestellt hat, dass er von genügend Validatoren genehmigt wurde: Damit ist der unten beschriebene Mechanismus zur Überprüfung der Zustimmung gemeint, mit dem Validatoren ein hohes Maß an Vertrauen haben können, dass ein Parachain-Block gut ist, ohne ihn unbedingt selbst zu überprüfen, indem sie sich auf die Überprüfung durch andere verlassen.

Nachfolgend finden Sie 3 Beispiele dafür, wie die Abstimmungsregel angewendet wird, um die Blöcke auszuwählen, die in die Endabstimmung gehen sollen.

Im ersten Beispiel zeigt dies die Eigenschaft der Kontiguität sowie die Tatsache, dass wir einen Vorfahren der besten Chain wählen.

Im zweiten Beispiel stimmen wir über den finalisierten Block ab, da keine der beiden Chains finalisierbar ist.

Im dritten Beispiel ist die gesamte beste Chain finalisierbar, so dass wir uns für diese entscheiden.

Zu guter Letzt sei darauf hingewiesen, dass diese Abstimmungsregel ein Prozess ist, der bei jedem Validator abläuft und dass alle Validatoren auf der Grundlage der Relay Chain-Blöcke und der Genehmigungsnachrichten, die sie gesehen haben, unterschiedliche Meinungen über das Finalitätsziel haben können. Aber das passt gut zu GRANDPA: Wenn alle ehrlichen Validatoren diese Abstimmungsregel anwenden, kann kein Relay Chain-Block abgeschlossen werden, wenn er nicht von 2/3 der Nodes als abschließbar anerkannt wird.

Die Zustimmungsprüfung verlangsamt die Finalität ein wenig, aber nur ein wenig. Parachains dürfen etwa 3 Sekunden Ausführungszeit haben, und es dauert etwa 1 Sekunde, um die Daten wiederherzustellen und ein paar zusätzliche Sekunden, um die Nachrichten zu verbreiten. Im optimistischen Fall bedeutet dies, dass die Finalität um etwa 5 Sekunden verlängert wird. Und das ist echte Endgültigkeit, mit dem ganzen Gewicht des Polkadot dahinter.

Sehen wir uns also den Prozess der Genehmigungsprüfung an und was die Nodes tatsächlich tun, um eine Vorstellung davon zu bekommen, welche Parachain-Blöcke gut sind und von genügend Validatoren geprüft wurden.

Approval Checking von Eigenschaften und Sicherheit

Approval Checking ist ein Unterprotokoll, das die Validatoren für jeden einzelnen Parachain-Block ausführen.

Jeder Validator Node führt für jeden Parachain-Block in jeder Relay Chain einen Genehmigungsprüfungsprozess durch. Dieser Prozess hat ein paar Eigenschaften:

Der Prozess auf einem bestimmten Node gibt entweder "gut" aus oder bleibt stehen.
Wenn der Parachain-Block gültig ist (d.h. die Prüfungen besteht), wird er auf ehrlichen Nodes "gut" ausgeben.
Wenn der Parachain-Block ungültig ist, wird er nur auf ehrlichen Nodes mit geringer Wahrscheinlichkeit "gut" ausgeben.

Beachten Sie, dass die "geringe Wahrscheinlichkeit" im ungültigen Fall bei etwa 1 zu mehreren Milliarden liegt, abhängig von Variablen wie der Anzahl der Validatoren und der Anzahl der Mindestprüfer. Das ist nicht die kryptographische Version der geringen Wahrscheinlichkeit, aber sie ist für die Kryptoökonomie geeignet.

Das Sicherheitsargument für Polkadot basiert auf Gambler's Ruin. Es ist zwar richtig, dass ein Angreifer, der Milliarden von Versuchen unternehmen kann, um den Prozess zu erzwingen, letztendlich erfolgreich sein würde, aber wir kombinieren diesen Prozess mit einem Slashing-System, das sicherstellt, dass jeder fehlgeschlagene Versuch mit einem Slash des gesamten Einsatzes der angreifenden Validatoren einhergeht. Polkadot ist ein Proof-of-Stake-Netzwerk, und zum Zeitpunkt der Erstellung dieses Artikels ist jeder Validator mit etwa 2 Millionen DOT an Stakes ausgestattet. Höchstwahrscheinlich würde jeder fehlgeschlagene Versuch zum Slash von 10 oder 20 Validatoren führen. Aber selbst wenn nur 1 Validator zerstört wird, ist es offensichtlich, dass die Mittel eines Angreifers schnell versiegen würden, bevor ein Erfolg wahrscheinlich ist.

Wir erreichen dies mit einigen anderen Eigenschaften der Genehmigungsprüfung:

Die Zuweisungen der Validatoren zur Prüfung eines Parachain-Blocks sind geheim, bis sie selbst offengelegt werden.
Die Zuweisungen der Validatoren werden deterministisch generiert.
Die Validatoren teilen ihre Absicht mit, einen Parachain-Block zu prüfen, bevor sie die für die Prüfung erforderlichen Daten erhalten.
Wenn Validatoren ihre Absicht, einen Parachain-Block zu prüfen, bekannt geben und dann verschwinden, veranlasst dies weitere ehrliche Validatoren, mit der Prüfung zu beginnen.

Eigenschaft 1 stellt sicher, dass ein Angreifer nicht weiß, wen er angreifen muss, um ihn an der Überprüfung eines Blocks zu hindern.

Eigenschaft 2 stellt sicher, dass selbst wenn der Angreifer ein glückliches Los gezogen hat und über genügend böswillige Nodes verfügt, um ehrliche Nodes davon zu überzeugen, dass etwas geprüft wurde, es höchstwahrscheinlich ehrliche Nodes gibt, die die Prüfungen neben ihm durchführen, und dass diese ehrlichen Nodes einen Alarm auslösen werden.

Eigenschaft 3 stellt sicher, dass sich ehrliche Knoten nicht versehentlich als Prüfer zu erkennen geben, indem sie Daten von böswilligen Knoten anfordern und dann vom Angreifer unbemerkt vom Netz genommen werden, d.h. wenn der Angreifer versucht, Prüfer zum Schweigen zu bringen, wird dies von anderen bemerkt.

Eigenschaft 4 stellt sicher, dass Nodes, die scheinbar DoSed wurden, durch noch mehr Nodes ersetzt werden. Die Genehmigungsprüfung soll wie die Hydra sein: Wenn Sie einen Kopf abschlagen, erscheinen 2 weitere Köpfe.

In den nächsten Abschnitten wird genauer beschrieben, wie die Genehmigungsprüfung tatsächlich funktioniert.

Was prüfen die Validatoren?

Das Ziel der Validatoren ist es hier, zu entscheiden, ob die unterstützenden Validatoren an einem Fehlverhalten beteiligt waren. Dies geschieht in 3 Schritten:

Laden Sie die PoV-Daten herunter, um den Block zu überprüfen. Dazu holen Sie sich 1/3 der Chunks und fügen sie zu den vollständigen Daten zusammen.
Stellen Sie sicher, dass die PoV-Daten einem gültigen Parachain-Zustandsübergang entsprechen.
Vergewissern Sie sich, dass alle Ausgaben, zu denen sich der Kopf des Parachain-Blocks verpflichtet hat, tatsächlich mit den Ausgaben der Parachain-Blockausführung übereinstimmen.

Die Wiederherstellung der Verfügbarkeit sollte niemals scheitern, wenn man davon ausgeht, dass >2/3 der Nodes ehrlich sind und sich verpflichtet haben, ihren Teil der Daten zu erhalten. Aus diesem Grund wird die Freigabeprüfung nur für verfügbare Parachain-Blöcke durchgeführt.

Die Schritte (2) und (3) können jedoch beide fehlschlagen. Wenn Schritt (2) fehlschlägt, bedeutet dies, dass der Zustandsübergang selbst fehlerhaft ist. Wenn Schritt (3) fehlschlägt, bedeutet dies, dass der Zustandsübergang erfolgreich war, aber die in der Relay Chain gespeicherten Informationen über die Ausgänge des Zustandsübergangs falsch waren.

Ein wichtiger Fall, den Sie bei Schritt (3) beachten sollten, ist, dass der Parachain-Block-Header eine Verpflichtung für alle Chunks der Löschkodierung enthält. Wir lassen die Validatoren nach der Wiederherstellung der PoV-Daten eine zusätzliche Prüfung durchführen, die darin besteht, das PoV wieder in seine löschungscodierte Form umzuwandeln und sicherzustellen, dass die Verpflichtung im Header mit allen Chunks übereinstimmt. Wenn es keine Übereinstimmung gibt, verhindert dies eine Art von Angriff, bei dem ein Angreifer selektiv auswählen kann, welche Validatoren die Daten wiederherstellen können. Der Angriff funktioniert folgendermaßen: Ein Angreifer teilt die Daten in Chunks auf und ersetzt alle bis auf 1/3 der Chunks durch Müll. Er verteilt 1 gültigen Chunk an einen ehrlichen Validator und gibt einem weiteren 1/3 der Validatoren Mülldaten. Das böswillige 1/3 der Validatoren behält den Rest der Chunks mit gültigen Daten zurück. Das bedeutet, dass es genug Validatoren (2/3 + 1) gibt, um die Daten als verfügbar zu betrachten, aber wenn die böswilligen Validatoren sich weigern, Anfragen über ihr 1/3 der guten Chunks zu beantworten, dann wird nur Müll verfügbar sein. Die Überprüfung, ob die Neukodierung der Daten tatsächlich mit der Zusage übereinstimmt, vereitelt diesen Angriff gründlich.

Wenn einer der Schritte (2) oder (3) fehlschlägt, löst der Prüfer einen Disput aus und fordert alle Validatoren auf, die gleichen Prüfungen durchzuführen. Wir werden später auf Streitfälle zurückkommen, um zu erörtern, was das genau bedeutet.

Wann zu prüfen

Eine der wichtigsten Erkenntnisse zum Verständnis des Systems der Genehmigungsprüfung ist, dass jeder Validator die Aufgabe hat, jeden Parachain-Block zu prüfen, aber es kommt darauf an, wann er prüft. Wenn ein Validator einen Parachain-Block als genehmigt ansieht, bevor es an der Zeit ist, ihn zu prüfen, dann prüft er ihn einfach nicht und geht weiter.

Die Zeit wird in diskrete Ticks von 0,5 Sekunden eingeteilt, beginnend mit der Unix-Epoche. Die Wahl von 0,5 Sekunden basiert auf der erwarteten Zeit, die kleine Nachrichten benötigen, um sich im Gossip-Netzwerk zu verbreiten.

Der Zeitpunkt, zu dem ein Validator einen Parachain-Block prüfen soll, wird in einer Verzögerungstranche ausgedrückt, die sich auf den Parachain-Block bezieht. Die Verzögerungstranchen reichen von 0 bis MAX_TRANCHES und entsprechen der Anzahl der Ticks, nachdem ein Node erfährt, dass der Parachain-Block verfügbar ist. Die Nodes haben leicht unterschiedliche Ansichten darüber, welcher Tick-Tranche 0 entspricht. MAX_TRANCHES ist ein Protokollparameter, der bestimmt, wie lange es dauert, jeden Parachain-Block zu prüfen. Wenn Sie ihn zu klein wählen, kann es sein, dass wir mehr Prüfer auswählen, als wir brauchen, und damit unnötig viel Zeit verlieren. Wenn er zu groß eingestellt ist, dauert die Prüfung der Parachain-Blöcke zu lange. Zum Vergleich: Dieser Parameter ist bei Polkadot und Kusama zum Zeitpunkt der Erstellung dieses Artikels auf 89 eingestellt.

Ticks sind eine diskrete Messung der Zeit, basierend auf Schritten von einer halben Sekunde, ausgehend von der Unix-Epoche.

Die Tranchen der Verzögerung sind Offsets relativ zu dem Tick, bei dem ein Relay Chain Block erzeugt wurde.

Tranche 0 ist insofern etwas Besonderes, als die erwartete Anzahl der Prüfer in Tranche 0 in etwa der Anzahl der MIN_CHECKERS entspricht. MIN_CHECKERS ist ein Protokollparameter, der die Mindestanzahl der Prüfungen festlegt, die erforderlich sind, bevor ein Parachain-Block im Rahmen des Genehmigungsprüfverfahrens als genehmigt gelten kann.

Validatoren, die Teil der Unterstützungsgruppe für den Parachain-Block waren, dürfen nicht an der Genehmigungsprüfung teilnehmen, da ihre Prüfungen überflüssig wären. Alle anderen Validatoren führen lokal eine VRF-Berechnung durch, um festzustellen, in welcher Verzögerungstranche sie prüfen sollen.

Assignments, Approvals, und No-Shows

Es gibt zwei Arten von Nachrichten, die Validatoren bei der Prüfung von Approval-Checking senden: Assignments(Zuweisung) und Approvals(Genehmigung). Zuweisung werden verwendet, um die Absicht und die Berechtigung zur Prüfung eines Parachain-Blocks mitzuteilen, und eine Genehmigungsnachricht zeigt an, dass ein Parachain-Block alle Prüfungen bestanden hat.

Jeder Validator generiert sofort eine Zuweisung zur Überprüfung des Parachain-Blocks, indem er eine VRF und die Parachain-ID und den Relay Chain-Block BABE als Eingabe verwendet. Die Validatoren halten ihre Zuweisung geheim, bis sie benötigt wird. Jede Zuweisung ist eindeutig und deterministisch mit einer Verzögerungstranche verbunden, die die Verzögerungstranche angibt, wenn der Validator mit der Prüfung des Parachain-Blocks beauftragt wird.

Die VRF ist wichtig, denn sie bedeutet, dass die Zuweisung von den Empfängern überprüfbar ist und dass der zugewiesene Validator keinen Einfluss auf die Verzögerungstranche hat, der er zugewiesen ist. Validatoren haben einen gewissen indirekten Einfluss über ausgefeiltere Angriffe, bei denen die Relay Chain absichtlich geforkt wird, wenn die BABE-Zufälligkeit günstig ist, aber das hebe ich mir für einen anderen Artikel auf.

Eine Genehmigung ist eine einfache, vom ausstellenden Validator unterzeichnete Nachricht, die anzeigt, dass ein Parachain-Block die Prüfungen bestanden hat.

Wenn ein Validator mit der Prüfung eines Parachain-Blocks beginnt, teilt er den anderen Validatoren als erstes seine Zuweisung mit. Dadurch werden die anderen Validatoren darüber informiert, dass sie auf eine entsprechende Genehmigungsnachricht warten sollen. Sobald der Validator die Prüfung abgeschlossen hat, sendet er eine Genehmigungsnachricht. Wenn die Genehmigungsnachricht nicht innerhalb von NO_SHOW_DURATION eintrifft, betrachten die anderen Nodes den ursprünglichen Validator als No-Show. No-Shows sollen anzeigen, dass ein Gegner die Absicht des Validators, den Parachain-Block zu prüfen, beobachtet und versucht hat, ihn zum Schweigen zu bringen. NO_SHOW_DURATION ist ein Protokollparameter, der bei Polkadot derzeit auf 12 Sekunden eingestellt ist.

Hier ist ein Diagramm, das 3 Fälle zeigt: eine No-Show, eine erfüllte Zuweisung und eine verspätete Erfüllung. Der letzte Fall ist besonders wichtig, denn er zeigt, wie Validatoren "von den Toten auferstehen" können und ihre Zustimmung auch dann noch zählt, wenn sie als "No-Show" eingestuft werden.

Ja zu sagen: Scheduling und die Approval-State-Machine

In diesem letzten Abschnitt über das Protokoll der Genehmigungsprüfung wird die State-Machine für die Genehmigung eines Parachain-Blocks beschrieben.

Jeder Validator Node verwaltet einen Genehmigungsstatus für jeden enthaltenen (verfügbaren) Parachain-Block. Die Versionen des Zustands bei den Validatoren können sich aufgrund von Timing und Asynchronität im Netzwerk unterscheiden. Anhand des Status können wir Fragen beantworten wie:

Ist der Parachain-Block genehmigt?
Ist eine Zuordnung mit Tranche T relevant?
Was ist der nächste Zeitpunkt, an dem sich die Antworten auf die Fragen (1) oder (2) geändert haben könnten, wenn keine anderen Eingaben vorliegen?

Der Genehmigungsstatus kann auf 3 Arten aktualisiert werden: durch den Erhalt eines neuen Auftrags, durch den Erhalt einer neuen Genehmigung oder durch das Fortschreiten der Zeit.

Validatoren lassen den Zustandsautomaten laufen, bis die Antwort auf Frage (1) 'ja' lautet. Nach jeder Eingabe verwenden sie Frage (2), um festzustellen, ob sie selbst mit der Überprüfung des Parachain-Blocks beginnen sollten, indem sie sehen, ob ihr Auftrag relevant ist. Frage (3) wird nur zu Optimierungszwecken benötigt: Nodes führen in der Regel Tausende dieser Zustandsautomaten parallel aus (einen für jeden unvollendeten Parachain-Block) und es ist ineffizient, sie alle bei jedem Tick abzufragen.

Das ist die Logik, die jeder Validator ausführt, bis die Parachain-Blöcke genehmigt sind

Der Status besteht aus 2 Teilen:

Alle eingegangenen Zuteilungen, geordnet nach Tranchen und vermerkt mit dem Tick, an dem sie zum ersten Mal beobachtet wurden.
Alle erhaltenen Genehmigungen.

Ein Validator nimmt seinen eigenen Auftrag erst dann in den Status auf, wenn er mit der Prüfung beginnt. Sobald ein Validator eine Genehmigung erteilt, nimmt er diese in den Status auf.

Hier sehen Sie eine visuelle Darstellung des Status. Es handelt sich um ein neutrales Objekt, das Fragen dazu beantworten kann, welche Aufgaben eingegangen sind, wie viel Zeit vergangen ist und welche Genehmigungen eingegangen sind.

Eine der wichtigsten Operationen beim Genehmigungsstatus ist die Bestimmung der zu berücksichtigenden Abtretungen. Wir nehmen die Verzögerungstranchen in ihrer Gesamtheit. Zuteilungen werden immer mit allen anderen Zuteilungen aus derselben Verzögerungstranche gebündelt. Ein Node wird niemals einen Auftrag aus einer Verzögerungstranche zählen, ohne alle anderen Aufträge aus derselben Verzögerungstranche zu zählen, die ihm bekannt sind.

Ein Auftrag befindet sich in einem von 3 Zuständen:

Ausstehend: Für den Auftrag gibt es keine entsprechende Genehmigung, aber er wurde vor kurzem erteilt.
Erledigt: Für den Auftrag liegt eine entsprechende Genehmigung vor.
No-show: Für die Zuteilung liegt keine entsprechende Genehmigung vor, und sie wurde nicht vor kurzem ausgestellt.

No-Show-Aufträge müssen durch mindestens eine nicht leere Tranche abgedeckt sein. Das heißt, dass jede No-Show durch mindestens eine Zuweisung abgedeckt sein muss, in der Regel aber durch mehr als eine (je nach Parametrisierung).

Um zu bestimmen, wie viele Tranchen zu nehmen sind, gehen Sie wie folgt vor:

Nehmen Sie Tranchen, beginnend mit Tranche 0, bis sie mindestens MIN_CHECKERS-Zuweisungen enthalten.
Nehmen Sie nicht leere Tranchen, eine für jede No-Show. Wenn es in diesen nicht leeren Tranchen mehr No-Shows gibt, wiederholen Sie Schritt 2.
Wenn alle Nicht-No-Show-Zuweisungen erfüllt sind, wird der Parachain-Block genehmigt. Mit anderen Worten: Wenn eine der Zuweisungen noch aussteht, wird der Parachain-Block nicht genehmigt.

Wenn Sie zu irgendeinem Zeitpunkt keine Tranchen mehr nehmen können (das Maximum ist ein Protokollparameter), wird der Block nicht genehmigt. In der realen Version dieses Protokolls gibt es noch einige weitere Einschränkungen in Bezug darauf, dass keine Tranchen genommen werden dürfen, die "in der Zukunft" liegen, sowie eine Zeitdrift, die auf jeder Iteration von Schritt 2 basiert.

Dieses Flussdiagramm zeigt die Logik, die jeder Validator durchläuft, um festzustellen, ob ein Parachain-Block genehmigt wird. Es ist wichtig zu beachten, dass dies nur auf den Zuweisungen und Genehmigungen basiert, die der Validator tatsächlich gesehen hat. Es kann Zuweisungen geben, die das Ergebnis des Zählverfahrens ändern, aber wenn der Validator, der das Verfahren durchführt, sie nicht erhalten hat, können sie nicht berücksichtigt werden.

Wie Sie erhaltene Zuweisungen und Genehmigungen zählen und interpretieren

Die wichtigsten Erkenntnisse aus diesem Verfahren sind, dass Zuweisungen für spätere Tranchen überhaupt nicht gezählt werden, wenn es genügend frühe Zuweisungen gibt, und dass Knoten, die unter mysteriösen Umständen verschwinden, ersetzt werden.

Hier sind 4 Beispiele für die Ergebnisse des Genehmigungsverfahrens:

Immer wenn ein Validator dieses Zählverfahren durchführt und feststellt, dass weitere Zuweisungen erforderlich sind, prüft er, ob er seine eigene Zuweisung auslösen und mit der Prüfung beginnen soll. Der Validator stößt seine Zuteilung an, wenn:

Der Validator hat seine Zuteilung noch nicht ausgelöst.
Die Tranche der Zuteilung ist für den Staat relevant: entweder ist sie Teil einer Tranche, die der Staat bereits abrechnet, oder das Zählverfahren hat keine Tranchen mehr und die Zuteilung liegt nicht in der Zukunft.

Zusammenfassend

Das Genehmigungsprüfungsprotokoll ist der wichtigste Mechanismus zur Aufdeckung von Betrug bei Polkadot. Bevor irgendetwas diese Stufe erreicht, haben wir sichergestellt, dass die für die Prüfung erforderlichen Daten verfügbar sind. Dieser Mechanismus führt entweder zur Genehmigung oder zur Eskalation jedes Parachain-Blocks und wurde so konzipiert, dass ein DoS-Angreifer, der versucht, Validatoren, die prüfen, zu eliminieren, durch noch mehr Prüfer ersetzt wird. Die Genehmigungsprüfung ist die Hydra. Sie ist so konzipiert, dass sie Angreifer verschlingt und sie am anderen Ende wieder ausspuckt. Wohin sie sie schickt, ist ein System, das wir Disputes(Streitigkeiten) nennen: Polkadot's Consensus Court of Law.

Disputes(Streitigkeiten) : Streiten um Geld

Ein Dispute(Streitigkeit) tritt auf, wenn 2 oder mehr Validatoren sich über die Gültigkeit eines Parachain-Blocks uneinig sind. Während sich der Großteil des bisherigen Inhalts dieses Artikels auf den glücklichen Pfad konzentriert, d.h. den Fall, dass ein Parachain-Block tatsächlich gut ist, geht es bei Streitfällen um den Fehlerpfad, bei dem ein Prüfer tatsächlich feststellt, dass ein ungültiger Parachain-Block verfügbar geworden ist.

Der Disputes-Prozess ist relativ einfach. Er wurde entwickelt, um die folgenden Ziele zu erreichen:

Stellen Sie fest, ob der Parachain-Block gut oder schlecht ist, indem Sie ihn allen Validatoren zur Abstimmung vorlegen.
Wenn der Parachain-Block schlecht ist, stellen Sie sicher, dass Sie keinen Relay Chain-Block abschließen oder darauf aufbauen, der ihn verfügbar macht.
Sorgen Sie dafür, dass die Verlierer des Streits entsprechend bestraft werden.

In erster Linie geht es bei Disputen darum, eines der übergeordneten Ziele von Polkadot zu erreichen: sicherzustellen, dass nichts Schlechtes jemals finalisiert wird.

Validatoren, die an einem Disput teilnehmen, geben ihre Stimme entweder in der Kategorie 'dafür' oder 'dagegen' ab. Die Teilnahme erfolgt entweder automatisch oder explizit.

Die Teilnahme erfolgt automatisch durch die Überprüfung der Befürwortung und Zustimmung. Wenn ein Validator für einen Parachain-Block eine Unterstützungsbescheinigung oder eine Genehmigungsnachricht ausgestellt hat, zählt er automatisch als Teilnehmer in der Kategorie 'dafür'. Ehrliche Validatoren führen sogar Buch über alle Nachrichten, die sie in letzter Zeit erhalten haben, um später Beweise gegen ihre Mitbewerber vorlegen zu können.

Die große Mehrheit der Validatoren nimmt nicht automatisch teil. Diese Validatoren nehmen explizit teil, d.h. sie unterschreiben eine Abstimmung für die Kategorie 'dafür' oder 'dagegen'. Sie tun dies, nachdem sie die gleichen Prüfungen vorgenommen haben wie ein Prüfer, der die Zustimmung prüft, nämlich,

Herunterladen der PoV-Daten.
Validierung des Zustandsübergangs
Validierung der Verpflichtungen gegenüber den Ausgängen des Zustandsübergangs

Die Teilnahme ist nicht verpflichtend, aber ein Streit kann erst beigelegt werden, wenn mindestens 2/3 der Validatoren für eine Seite gestimmt haben. Validatoren werden für ihre Teilnahme belohnt und erhalten eine Belohnung, wenn sie auf der Seite der Mehrheit sind.

Streitigkeiten enden entweder mit einem Für oder Wider, da die Validierung deterministisch ist. Vorherige Backing- und Approval-Anweisungen (gekennzeichnet als (B) bzw. (A)) werden automatisch in der 'for'-Spalte gezählt.

Es gibt empfindliche Strafen für die Verlierer einer Streitigkeit. Die Anfechtung eines Parachain-Blocks, der eigentlich gültig ist, ist reine Zeit- und Bandbreitenverschwendung, also gibt es eine kleine Strafe dafür. Das Einreichen eines ungültigen Parachain-Blocks ist ein Angriff auf Polkadot, so dass die Strafe 100% beträgt.

Remote(Entfernte) und Local(Lokale) Disputes(Streitigkeiten)

Streitigkeiten sind in erster Linie ein Prozess außerhalb der Chain. Das heißt, sie finden auf der Ebene der "Ketten" und nicht auf der Ebene der "Chain" statt. Die Abzweigung der Relay Chain, die schließlich abgeschlossen wird, sollte jedoch eine Aufzeichnung der Streitigkeiten enthalten. Das liegt daran, dass das Slashing ein Prozess innerhalb der Chain ist.

Wenn eine Streitigkeit auftritt, werden alle Stimmen auf jeder Gabelung der Chain aufgezeichnet, um das Slashing auszulösen und eine dauerhafte Aufzeichnung der Streitigkeit zu erstellen.

Eine Remote (Entfernte) Streitigkeit in Bezug auf eine Abzweigung der Relay Chain ist eine, die sich auf einen Parachain-Block bezieht, der nicht in dieser Abzweigung der Relay Chain enthalten war.

Eine Local(Lokale) Streitigkeit in Bezug auf eine Abzweigung der Relay Chain ist eine, die sich auf einen Parachain-Block bezieht, der in dieser Abzweigung der Relay Chain enthalten war.

Der Grund für diese Entscheidung ist, dass sie uns darüber informiert, welche Abzweigungen der Relay Chain aufgegeben werden müssen. Jede Abzweigung der Relay Chain, die eine lokale Streitigkeit aufzeichnet, die sich gegen den Parachain-Block richtet, sollte von ehrlichen Validatoren vermieden und nicht aufbewahrt werden. Mit anderen Worten: Ehrliche Validatoren, die feststellen, dass ein Parachain-Block schlecht ist, werden automatisch einen 51%-Angriff gegen die Abzweigungen der Relay Chain starten, die den schlechten Parachain-Block enthalten.

Das Endergebnis ist, dass die endgültige Abzweigung der Relay Chain keine Parachain-Blöcke enthält, die Streitigkeiten verloren haben. Wenn jedoch ehrliche Validatoren die neue Chain aufbauen und den schlechten Parachain-Block auslassen, spielen sie die Streitigkeit auf der neuen Abzweigung als Remote-Streitigkeit erneut ab. Die Bestrafung bleibt erhalten, aber die Auswirkungen des Verbrechens werden aus der Geschichte gelöscht.

Dieses Diagramm zeigt, wie ein umstrittener Parachain-Block entweder entfernt oder lokal ist, je nachdem, welche Abzweigung der Relay Chain Sie betrachten:

Eine Dispute(Streitigkeit) ist entweder lokal oder entfernt in Bezug auf einen Relay Chain-Block

Disputes(Streitigkeiten) und Konsensregeln

Wie bei der Zustimmungsprüfung werden auch bei Streitigkeiten die Regeln für die Konsensbeteiligung für ehrliche Validatoren geändert. Diese Änderungen haben 2 Hauptziele:

Um zu vermeiden, dass eine Abzweigung der Relay Chain abgeschlossen wird, die auf einen fehlerhaften Parachain-Block verweist.
Um zu vermeiden, dass Sie auf eine Abzweigung der Relay Chain aufbauen, die auf einen fehlerhaften Parachain-Block verweist.

Diese Ziele entsprechen den Änderungen im Verhalten von GRANDPA bzw. BABE.

Die GRANDPA-Abstimmungsregel ist eine Abwandlung der zustimmungsprüfenden GRANDPA-Abstimmungsregel. Sie besagt:

Wählen Sie einen Block gemäß der Abstimmungsregel zur Überprüfung der Zustimmung
Finden Sie den höchsten Block B in dieser Chain, so dass alle Blöcke ab dem letzten abgeschlossenen Block und bis zu B nur Parachain-Blöcke einschließen, die keine laufenden Streitigkeiten haben oder Streitigkeiten verloren haben.

Dies ist ähnlich aufgebaut wie die Abstimmungsregel für die Zustimmungsprüfung, aber lassen Sie uns die wichtigsten Teile auspacken, die dafür sorgen, dass Validatoren Relay Chain-Blöcke ignorieren, die die Einbeziehung von Parachain-Blöcken auslösen:

die keine laufenden Streitigkeiten haben: Dies weist die Validatoren an, Parachain-Blöcke, die umstritten sind, erst dann abzuschließen, wenn sich genügend Validatoren beteiligt haben. Mit anderen Worten: 'better safe than sorry'.
die Streitigkeiten verloren haben: Wenn ein Validator sieht, dass 2/3 der Stimmen gegen einen Parachain-Block sind, wird dieser Validator niemals für die Finalisierung eines Relay Chain-Blocks stimmen, der die Einbeziehung dieses Parachain-Blocks auslöst.

In diesem Diagramm zeigen wir einige Beispiele dafür, wie die Abstimmungsregel Streitigkeiten GRANDPA auf eine Chain angewandt werden würde:

Es gibt auch eine BABE-Chain-Auswahlregel (Blockautorschaft), die dem zweiten Ziel dient. Normalerweise weist BABE die Validatoren an, die Relay Chain zu verlängern, indem sie auf dem Relay Chain-Block mit dem höchsten Gewicht aufbauen, was analog zur Höhe ist. Die modifizierte BABE-Regel für die Auswahl der Chain lautet wie folgt:

Relay-Chain-Blöcke gelten als lebensfähig, wenn sie entweder abgeschlossen sind oder wenn ihr übergeordneter Block lebensfähig ist und jeder Parachain-Block, für den der Relay-Chain-Block die Einbeziehung auslöst, unbestritten ist oder eine Streitigkeit gewonnen hat.
Ein Relay-Chain-Block ist ein lebensfähiges Blatt, wenn er keine lebensfähigen Kinder hat.
Validatoren sollten auf dem lebensfähigen Blatt mit dem höchsten Gewicht, das ihnen bekannt ist, aufbauen.

Die BABE-Regel für die Chain-Auswahl hat zur Folge, dass ehrliche Validatoren Abzweigungen der Relay Chain, die die Einbeziehung von Parachain-Blöcken auslösen, die sich als ungültig erweisen, aufgeben, selbst wenn dies bedeutet, dass sie vorübergehend auf eine kürzere Chain aufbauen.

Das folgende Diagramm zeigt anhand von Beispielen, wie die BABE-Chain-Auswahlregel von Validatoren verlangt, dass sie Ketten, die Parachain-Blöcke enthalten, die Streitigkeiten verloren haben, aufgeben und nicht weiter aufbauen. Dies führt dazu, dass sie zu 51% den schlechten Zweig der Relay Chain angreifen.

In der Praxis sieht das so aus, dass die Relay Chain kurz und automatisch zurückgesetzt wird. Hier ist ein Beispiel:

In Block 1a ist ein Parachain-Block P enthalten.
Zu dem Zeitpunkt, an dem Block 3a gebildet wird, ist der Parachain-Block P umstritten und wird für ungültig befunden.
Ehrliche Validatoren beginnen damit, den Block 1a und alle Unterblöcke von 1a zu ignorieren. Stattdessen bauen sie eine neue Chain auf, die mit einem alternativen Block 1b beginnt, der den ungültigen Parachain-Block P nicht enthält.
Diese ehrlichen Validatoren senden die Streitigkeiten in Bezug auf den Parachain-Block P an die neue Abzweigung der Relay Chain, wodurch sichergestellt wird, dass die Hintermänner von P zerschlagen werden. Sobald 4b aufgebaut ist, übertrifft sie die ursprüngliche Chain und 1b ist abgeschlossen.

Der Rollback ist möglich, weil ehrliche Validatoren 1a nicht abschließen, bevor es nicht genehmigt wurde, und der Genehmigungsprozess hat die Streitigkeit ausgelöst. Sobald P eine Streitigkeit hat, legen die Validatoren die Fertigstellung von 1a auf Eis. Wenn P die Streitigkeit verliert, werden sich die Validatoren weigern, 1a unter allen Umständen abzuschließen.

Illustriertes Beispiel für eine 'reversion (Umkehrung)', bei der ein schlechter Parachain-Block ignoriert wird

Zusammenfassend lässt sich sagen, dass die Logik der Streitigkeiten dafür sorgt, dass erkanntes Fehlverhalten angemessen bestraft wird und dass die Relay Chain sich neu organisiert, um den schlechten Parachain-Block vollständig zu vermeiden. Streitigkeiten und die damit verbundenen Regeln für die Auswahl der Chain sind die wichtigsten Dinge, die Polkadot von einem normalen optimistischen Rollup unterscheiden. Optimistische Rollups laufen auf einer Chain, auf die sie keinen Einfluss auf die Finalität oder die Wahl des Forks haben. Das bedeutet, dass sie extrem konservativ sein müssen, was das Risiko angeht, einen schlechten Block zu finalisieren, und daher lange Betrugsperioden und Rückzugszeiten (Tage oder Wochen) vorschreiben.

Bei Polkadot bedeuten das Streitigkeiten-Protokoll und die Regeln für die Auswahl der Chain, dass die Finalität einfach um ein paar Sekunden verzögert wird, wenn eine Streitigkeit im Gange ist und die Chain um den schlechten Block herum aufgebaut werden kann. Die Endgültigkeit ist immer noch schnell und die Endgültigkeit ist immer noch sicher.

Alle zusammen

Dieser Beitrag war ein tiefer Einblick in den Blockchain-Konsens und wie wir diese Konzepte angewandt haben, um Polkadot zu entwickeln. Ein großer Teil unserer Design-Methodik drehte sich darum, sicherzustellen, dass die Dinge schnell funktionieren, wenn die Netzwerkbedingungen gut sind, aber korrekt, wenn die Netzwerkbedingungen schlecht sind. Die meiste Zeit über wird es keine angreifenden Validatoren geben. Die Latenzzeiten im Netzwerk sind niedrig und die Bandbreite ist hoch. Unter diesen Bedingungen können Genehmigung und Abschluss in wenigen Sekunden erfolgen. Wenn es jedoch angreifende Validatoren gibt oder die Netzwerkbedingungen schlecht sind, verlangsamt sich der Abschluss entsprechend und die Relay Chain hat die Möglichkeit, sich um schlechte Parachain-Blöcke herum neu zu organisieren.

Wir arbeiten an dieser Reihe von Protokollen in der einen oder anderen Form seit dem Sommer 2016. Es ist unglaublich befriedigend zu sehen, wie diese Dinge implementiert werden und in lebenden, stark dezentralisierten Netzwerken laufen.

Das Problem der Skalierung der Blockchain hat sich nur verschlimmert, seit wir uns vor einigen Jahren auf diese Reise begeben haben. Wir haben eine Reihe von Ansätzen gesehen, aber vielen von ihnen mangelt es entweder an Sicherheit oder Dezentralisierung. Polkadot ist mit seinen Systemen zur Sicherung, Verfügbarkeit, Überprüfung von Genehmigungen und Streitigkeiten eine praktische Lösung, die Skalierbarkeit, Dezentralisierung und Sicherheit bietet.

Zur Protokollentwicklung

(Persönliche Meinungen des Autors folgen)

Die Entwicklung von Softwaresystemen ist ein ständiges Ringen zwischen Idealen, Pragmatismus, Ästhetik und Zeit. Die Realität entspricht nie ganz dem Ideal. Nichts ist jemals perfekt, aber die Dinge können gut sein.

Es gibt eine Diskrepanz zwischen der idealisierten Version eines Protokolls und den Implementierungen, die schließlich auf Computern laufen. Es ist ähnlich wie der Unterschied zwischen einer Figur in einem Theaterstück und der Verkörperung dieser Figur durch einen Schauspieler. Server auf der ganzen Welt werden das Kostüm unserer Validatoren tragen, aber sie werden nie die Validatoren unseres Protokolls werden, egal wie sehr sie sich bemühen.

Die Entwicklung des Protokolls ist ein großes Unterfangen. Sie erfordert viel Zeit, Energie und Konzentration. Sie erfordert die Bereitschaft, die große Mehrheit der Dinge, die am Rande passieren, zu ignorieren. Diese Opfer sind archetypisch - ein Werk kann nur geschaffen werden, indem man all das opfert, was es nicht ist. Beim Aufbau von etwas geht es darum, Symbole in Beziehung zueinander zu setzen. Vor allem aber erfordert der Aufbau die Bereitschaft, dabei zu scheitern. Als Protokollentwickler haben wir keine andere Wahl als zu scheitern. Aber dabei stoßen wir auf das Absurde und finden einen Sinn.

Die Massenmedien des Internets fördern die Botschaft, dass Bauen in erster Linie ein Mittel zum Zweck ist. Wir werden ermutigt, als Teil von etwas Größerem zu bauen: Unternehmen, Finanzsysteme, soziale Bewegungen und politische Erklärungen. Es ist wichtig, diese Ziele mit handwerklichem Geschick und der einfachen Freude darüber zu verbinden, dass man etwas gebaut hat, das nicht nur funktional ist, sondern auch mit Sorgfalt und Eleganz. Die Mühe, jedes Teil eines Systems so zu konstruieren, dass es mit den anderen in Einklang steht, ist eine Quelle des Stolzes und lohnt sich selbst auf Kosten anderer materieller Belohnungen.

Wir arbeiten seit über 5 Jahren an den hier beschriebenen Protokollen und ich habe mich entschieden, diesen Beitrag auf diese Weise zu beenden, um die Frage zu beantworten, die sich viele Leser stellen werden: "Warum sollte jemand 5 Jahre lang so etwas tun?". Dies ist eine Botschaft an alle Neueinsteiger im Kryptobereich. Dies ist eine Botschaft an alle, die seit dem Aufschwung von 2020 auf den Wellen reiten. Wenn Sie einen Zufluchtsort vor der Gier und dem Tumult suchen, gibt es ihn, und er war die ganze Zeit da.

Polkadot v1.0: Sharding und wirtschaftliche Sicherheit