Wir haben das Kusama-Netzwerk nach den ersten 5 Parachain-Auktionen auf Stabilität überwacht. Zu diesem Zeitpunkt befanden sich 6 Parachains im Netzwerk.

Unser Interesse galt 4 Schwerpunkten:

1. Produktionsstabilität der Kandidaten

2. Statistiken zur Stimmabgabe

3. Netzwerk-Konnektivität

4. Load

Wir haben eine Stichprobe von Metriken aus Opt-in Validatoren genommen, um die Informationen in Prometheus und Grafana zu sammeln, die in den folgenden Diagrammen angezeigt werden.

Kandidat Produktionsstabilität

Unter idealen Umständen produziert jede Parachain in der aktuellen Iteration des Protokolls einen Block für jeweils 2 Relay-Chain-Blöcke. Wir können die Blockproduktionsrate für jede Parachain bestimmen, indem wir die Anzahl der Relay-Chain-Blöcke, die während der Zeit, in der die Parachain online sein kann, produziert wurden, durch die Anzahl der Parachain-Blöcke, die in diesem Zeitraum produziert wurden, teilen.

Die folgende Tabelle zeigt die Werte für die 6 aktuellen Parachains ab einer aktuellen Blocknummer (#).

Da alle diese Parachains durch denselben Validatorensatz gesichert sind und von zufälligen Validatoren validiert werden, sollte es keine größeren Diskrepanzen in der Leistung geben, die die Validatoren den Parachains bieten.

Die Auswirkung des Netzwerkrauschens ist zu diesem Zeitpunkt nicht erwägenswert, da die Parachains in den letzten Tagen nicht genug Zeit hatten, um wiederholt jeder möglichen Kombination von unterstützenden Validatoren ausgesetzt zu werden. Aber das Rauschen erklärt sicherlich nicht die große Diskrepanz zwischen Shiden (und in geringerem Maße auch Khala) und den übrigen Parachains, die meist im Bereich zwischen 5 und 10 % vom Idealwert liegen. Es ist erwähnenswert, dass Statemine in den ersten Wochen nach dem Start eine holprige Phase hatte, die dazu führte, dass es nur einmal pro Minute Blöcke produzierte, und die aktuellen Daten sind durch dieses anfängliche Problem verzerrt.

Es gibt zwei mögliche Erklärungen für diese Diskrepanz. Der wahre Grund kann eine oder eine Kombination aus beiden sein:

1. Starke Ausführung von Parachains oder Daten

2. Schlechte Verbindung zwischen Kollator und Validatoren

Im Moment ist das Zeitfenster, das Kollatoren und Validatoren für die Erstellung eines Parachain-Blocks zur Verfügung steht, sehr kurz, was das System anfällig macht und zu kurzen Verzögerungen bei der Kommunikation führt. Für beide Probleme besteht die langfristige Lösung darin, das Parachain-Protokoll zu verbessern, um ein längeres Zeitfenster für die Erstellung des nächsten Parachain-Blocks zu ermöglichen. Eine kurzfristige Lösung bestünde darin, die Kollatoren geografisch näher am Großteil der Validator Nodes zu positionieren. Dadurch entsteht jedoch ein vorübergehendes regionales Zentralisierungsrisiko - ein Risiko, das durch die langfristige Lösung gemildert würde.

Genehmigungsabstimmungs

Das Genehmigungsabstimmungsprotokoll ist für den größten Teil der Sicherheit von Parachains verantwortlich. Es ist eng mit dem GRANDPA Finalitätsprotokoll verknüpft. Grob gesagt, werden Nodes nach dem Zufallsprinzip ausgewählt, um die Gültigkeit von Parachain-Blöcken zu überprüfen. Eine bestimmte Anzahl von Nodes ist erforderlich, um den Block der Relay-Chain, der den Kandidaten enthält, abzuschließen, und 'No-Shows', die ihre Absicht zur Überprüfung ankündigen, aber nicht nachkommen, werden automatisch ersetzt. Streitigkeiten über die Gültigkeit werden an die gesamte Gruppe der Validatoren weitergegeben, was dazu führt, dass mindestens ein Validator gestrichen wird.

Um das Abstimmungsverhalten zu vergleichen, können wir Folgendes beobachten:

1. GRANDPA Finalitätsverzögerung der Meinungen der Validatoren

2. Durchschnittliche 'Tranche' von Zuweisungen durch Validatoren (idealerweise = 0)

3. Anzahl der Zuweisungen und Genehmigungen durch die Validatoren

Finalität Verzögerung

Die Grafik oben zeigt auf einer logarithmischen Skala die maximale und durchschnittliche Meinung darüber, wie viele Blöcke hinter der Finalität des Kopfes der Relay-Chain zurückbleiben sollten. Jeder Validator hat seine eigene Meinung, die darauf beruht, wie er den Genehmigungsstatus der einzelnen Parachain-Blöcke einschätzt, auf die die Relay Chain verweist.

Meistens liegt dieser Wert zwischen 2 und 5. Gelegentlich springt er jedoch auf 50 an. Diese Vorfälle sind etwas beunruhigend - es gibt einen Failsafe-Wert von 50 Blöcken, der offensichtlich nur sehr selten erreicht wird, einmal alle paar Wochen.

Diese Endgültigkeit Stand Vorfälle werden derzeit untersucht. Wir werden der Governance eine Lösung vorschlagen, um das Problem noch vor dem Start von Polkadot Parachains zu beheben.

Durchschnittliche Tranche

Jeder Validator ist technisch dazu bestimmt, jeden Parachain-Block zu prüfen. Die Frage ist nur, wann. In der Regel werden nur die Validatoren der Tranche 0 zur Überprüfung herangezogen, und spätere Tranchen kommen nur dann ins Spiel, wenn die Validatoren der Tranche 0 nicht auftauchen.

Die Grafik oben zeigt, dass die Tranchen der 50- und 95-Perzentil-Zuweisungen außerhalb der Finality-Stall-Zwischenfälle in der Regel 0 sind.

Aufträge und Genehmigungen

Diese Grafik veranschaulicht, wie die Zuweisungen der Validatoren im Netzwerk in die entsprechenden Genehmigungsstimmen umgewandelt werden. Wir können sehen, dass alle Zuweisungen in Genehmigungen umgewandelt werden, obwohl die meisten von ihnen als veraltet gemeldet werden. Diese Daten stehen im Widerspruch zu der gemeldeten Verzögerung bei der Endgültigkeit, da "veraltete" Genehmigungen diejenigen sind, die nach der Endgültigkeit irrelevant werden.

Fast per Definition sollte die Mehrheit der Genehmigungen nicht veraltet sein, da sie überhaupt erst für die Endgültigkeit erforderlich sind. Es besteht die Möglichkeit, dass diese Kategorie vom Node oder von Grafana falsch gemeldet oder falsch dargestellt wird. Bei Rococo zeigt das entsprechende Diagramm eine fast 1:1-Zuordnung von Zuweisungen und erfolgreichen Genehmigungen.

Netzwerk-Konnektivität

Auf Kusama gibt es 900 Validatoren, von denen in jeder Sitzung 200 zufällig ausgewählt werden, um am Parachain-Konsens teilzunehmen. Jeder aktuelle Validator soll sich mit den Validatoren des aktuellen Validatorensets sowie der letzten 6 Sitzungen verbinden.

Es gibt eine Reihe von Validatoren, die etwa 200 Verbindungen haben, was darauf zurückzuführen ist, dass sie Teil eines älteren Validatorensets sind. Bei Validatoren, die Teil des aktuellen Validatorensets sind, sollte die Konnektivität in Spitzenzeiten höher sein. Wir sehen, dass die von uns untersuchten Validatoren im Netzwerk größtenteils zu viele Verbindungen haben und mit den meisten der anderen 899 Validatoren des Validierungs-Peer-Sets verbunden sind. Dies stellt kein Problem für die Korrektheit dar, bietet aber eine Chance für die Effizienz.

Einige Validatoren haben zu wenig Verbindungen und sind nicht so gut in das Gossip-Netzwerk eingebunden, wie sie es sein sollten. Trotzdem hat keiner der Validatoren weniger als 100 Verbindungen. Daher sollten die Informationen an die Validatoren geklatscht werden, wenn auch über mehr Sprünge.

Bestimmte Anfragen erfordern eine Punkt-zu-Punkt-Kommunikation, und aus diesem Grund müssen alle Validatoren über eine veröffentlichte Node-Adresse öffentlich erreichbar sein. Die Node-Software übernimmt diese Funktion automatisch, aber der Betreiber des Nodes ist dafür verantwortlich, dass der Node erreichbar ist.

Diese Grafik zeigt die Anzahl der Chunk-Anfragen pro Sekunde und die Anzahl der Fehlschläge verschiedener Typen. Die Art der Anfrage ist hier unwichtig. Das Wichtigste ist, dass die Fehler bei der Einwahl (die gelbe Linie im unteren Diagramm) fast genau 10 % der gestellten Anfragen ausmachen. Das bedeutet, dass 10 % der Validatoren unter ihrer veröffentlichten Adresse nicht erreichbar sind.

Load (CPU und Netzwerk)

Dieses Diagramm zeigt die CPU-Auslastung in Kernen durch die Validatoren an. Die meisten Validatoren bewegen sich im Bereich von 1,5-2 Kernen. Wir empfehlen derzeit, dass die Validatoren mit 4 CPU-Kernen arbeiten, so dass die CPU-Auslastung im Rahmen der Erwartungen liegt.

Diese Grafik zeigt die Aufschlüsselung der CPU-Nutzung nach Aufgaben. Die 3 wichtigsten Aufgaben dominieren die CPU-Auslastung, und zwar in absteigender Reihenfolge die Aufgaben 'libp2p-node', 'network-worker' und 'grandpa-voter'. Diese Aufgaben sind in erster Linie netzwerkbezogen, was darauf hindeutet, dass Optimierungen bei der Netzwerkauslastung die CPU-Auslastung des Nodes erheblich reduzieren werden.

Der Großteil des von den Nodes genutzten Klatschverkehrs findet über das Netzwerkprotokoll /polkadot/validation/1 statt. Dieses Protokoll bündelt den gesamten Klatsch und Tratsch zwischen den Knoten und macht einen großen Teil des Netzwerkverkehrs aus. Aus dieser Grafik geht hervor, dass die durchschnittliche Netzwerkbandbreite über alle Validatoren hinweg im Allgemeinen sehr stabil bei 400-500 KB/s liegt, wobei die Bandbreite der eingehenden Verbindungen etwas größer ist als die der ausgehenden Verbindungen.

Der größte Teil der von den Nodes genutzten Anfrage-/Antwort-Bandbreite entfällt auf das Chunk-Distributionsprotokoll. Bei 200 Validatoren und einer maximalen PoV-Größe von 1 MB liegen die Chunks in der Spitze bei 15 KB. Bei diesen durchschnittlichen Anfrage-/Antwortraten bedeutet dies eine Bandbreite von etwa 307KB/s nach innen und 138KB/s nach außen. Im Moment sind die PoVs jedoch viel, viel kleiner, da die Parachains nicht in der Nähe des maximalen Transaktionsvolumens liegen.

Empfehlungen

Insgesamt läuft das Netzwerk flüssig. Obwohl die durchschnittliche Anzahl der Peers und die Netzwerkbandbreite im gesamten Netzwerk konsistent zu sein scheinen, gibt es Ausreißer-Nodes, die übermäßig stark angebunden sind und eine höhere Netzwerkbandbreite aufweisen.

Es scheint, dass in der aktuellen Umgebung die ständige Empfehlung einer starken 4-Kern-CPU und 64 GB Speicher zusammen mit einer schnellen Internetverbindung mehr als ausreichend ist. Die aktuelle Bandbreitennutzung scheint im Bereich von 8-16 Mbps zu liegen, so dass eine typische Rechenzentrumsverbindung von 100 Mbps ausreicht, um die letzten 5 zu erhalten.

Das einzige größere Problem sind die gelegentlichen Verzögerungen bei der Übertragung, die das Netzwerk aufweist. Diese Blockierungen werden durch eine Ausfallsicherung abgefangen und haben daher keinen großen Schaden angerichtet. Die zugrunde liegende Ursache wird jedoch untersucht und eine Lösung zur Behebung dieses Problems wird noch vor dem Start der Parachains auf Polkadot vorgeschlagen.

This Article is written in association with WagMedia using Kusama Treasury Fund under WagMedia’s Bounty Proposal#12.

Come Join us and Create your own DotSama Contents or Lurk in WagMedia Discord.

What is WagMedia?

WagMedia Discord.

WagMedia Twitter