EOS Mainnet Update: Neue Knotenarchitektur verbessert die EOS-Zuverlässigkeit erheblich

In unserem vorherigen Blogeintrag und zuletzt Ausgaben der EOS Hot Sauce, Wir haben einen Blick hinter die Kulissen der Zusammenarbeit geworfen, die in den letzten Wochen zwischen Block.one und den wichtigsten Blockherstellern des EOS Mainnet stattgefunden hat. Heute möchten wir einen technischeren Blick auf die Details der Architekturänderungen werfen, die kürzlich von Blockherstellern vorgenommen wurden. 

Fehlerbehebung

Mitte Januar verzeichnete das EOS Mainnet ein viel größeres Volumen eingehender Transaktionen, was zu einem anschließenden Anstieg der Mikroforks führte. Die erste Hypothese war, dass die hohe Anzahl von Transaktionen die signierenden Knoten (auch als produzierende Knoten bezeichnet) überwältigte. 

Die Hersteller von Schlüsselblöcken versuchten zunächst, die CPU-Geschwindigkeit beim Signieren von Knoten zu erhöhen, um das große Transaktionsvolumen zu kompensieren, was zwar hilfreich war, das Problem jedoch nicht behebte. Die Signaturknoten produzierten jetzt größere Blöcke, waren jedoch beim Versuch, eingehende Transaktionen zu verarbeiten, immer noch überlastet. Darüber hinaus waren die Blöcke zu langsam, um sich zum nächsten Blockhersteller zu verbreiten, und die Mikroforks blieben zu hoch.

Nach eingehenden Untersuchungen identifizierten Block.one und die Hersteller von Schlüsselblöcken die Ursache des Problems: Die hohe Anzahl von Transaktionen, die über mehrere Verbindungen auf den signierenden Knoten treffen, führte dazu, dass der Knoten nicht effizient arbeiten konnte. Die Lösung erforderte eine Reduzierung der Anzahl der Verbindungen auf dem Signaturknoten. Letztendlich bedeutete das, nur 2 Verbindungen zu haben.

Dies ist eine bedeutende Änderung, da Blockhersteller möglicherweise mehrere Verbindungen zu öffentlichen P2P-Clustern, mehrere Verbindungen zu API-Knoten und andere verschiedene Verbindungen hatten. Alle diese mussten durch nur 2 Verbindungen ersetzt werden.

Erste Verbindung: Nur Blöcke

Blockproduzenten, die so organisiert sind, dass sie ein P2P-Netzwerk nur für Blöcke erstellen, um schnell Blöcke untereinander zu liefern. Das Ermöglichen, dass Blockproduzenten Transaktionen ignorieren, bedeutet eine geringere Verarbeitungslast - und wenn Blöcke pünktlich eintreffen, kommt es nicht zu Mikroforks.

Ein neu produzierter Block muss also von Produzent 1 -> Block Peer 1 -> Block Peer 2 -> Produzent 2 gehen.

Damit dies ordnungsgemäß funktioniert, waren in EOSIO einige Änderungen von Block.one erforderlich:

1. Möglichkeit, bidirektionale Nur-Block-Verbindungen herzustellen (nur in EOSIO 2.0.2 hinzugefügt)
2. Möglichkeit zur Begrenzung der CPU, die zum Erstellen von Blöcken im Signaturknoten verwendet wird (hinzugefügt in EOSIO 1.8.11 und 2.0.2).

Als diese Änderungen verfügbar gemacht wurden, stellten Blockhersteller sie schnell bereit und wiesen einen CPU-Aufwand von 50% zu. Dies reduzierte die Anzahl der verworfenen Blöcke dramatisch.

Diese Architektur funktioniert zum Zeitpunkt der Veröffentlichung sehr gut, es sind jedoch einige weitere Anpassungen erforderlich, um die verbleibenden verworfenen Blöcke weiter zu reduzieren. Block.one, um zukünftige Änderungen zu steuern schrieb eine ausführliche Erklärung Informationen zum Konfigurieren von Einstellungen, um sicherzustellen, dass Blöcke pünktlich eintreffen.

Zweite Verbindung: Transaktionen

In dieser neuen Knotenarchitektur mussten Blockproduzenten auch ein Transaktionsnetzwerk erstellen. Hinweis: Das Transaktionsnetzwerk enthält auch Blöcke.

Alle eingehenden Transaktionen, unabhängig davon, woher sie kommen, müssen zu einem einzigen "Transaktions-Peer" -Knoten zusammengefasst werden, der eine Verbindung zum Signaturknoten herstellt. Dieser Knoten muss so viele Transaktionen wie möglich verarbeiten, darf aber auch den Signaturknoten nicht mit zu vielen Transaktionen überfordern, damit der Signaturknoten weiterhin effizient Blöcke produzieren kann.

Um das eingehende Transaktionsvolumen zu verarbeiten, möchten Blockhersteller möglicherweise EOSIO 2.0 mit aktivierter EOS-VM verwenden. Die Verwendung von EOS-VM würde jedoch einen Blocksignaturknoten mit Version 1.8 überfordern. In diesem Fall wird ein zusätzlicher „Barrier“ 1.8-Knoten benötigt, um die Transaktionen zu verlangsamen und dem Signaturknoten ein effizientes Funktionieren zu ermöglichen.

Während Blockhersteller den Nur-Block-Zustellungsmechanismus optimierten, wurde die Fähigkeit zur Verarbeitung von Transaktionen vorübergehend eingeschränkt. Dies wirkte sich negativ auf einige Dapps aus, da Transaktionen verloren gingen. Dies sollte kein Problem mehr sein.

Fazit

Das Problem herauszufinden und eine Lösung zu finden, war eine sehr gemeinsame Anstrengung zwischen den Top 21 und Block.one. Dies erforderte eine enorme Menge an Arbeit und Koordination seitens vieler Teams auf der ganzen Welt. Beispielsweise haben an einem Punkt mehrere benachbarte Blockproduzenten ihre Protokolle an Block.one gesendet, damit Probleme von einem Blockproduzenten zum nächsten zurückverfolgt werden können. Es ist normal, dass einige Teams stärker involviert waren als andere, aber alle Teams haben beigetragen, was sie mussten. Wir möchten auch WhaleEx einen besonderen Gruß aussprechen, der mit der Entwicklung der Lösung eine hervorragende Führungsrolle übernommen und viel Hilfe bei der Implementierung angeboten hat.

Abschließend ist zu beachten, dass nicht alle Blockhersteller genau dieselbe Konfiguration haben. Knotentopologie, CPU-Geschwindigkeit, Transaktionslast und EOSIO-Versionen variieren, da verschiedene Blockhersteller unterschiedliche Anforderungen und Anforderungen haben. EOS Nation arbeitet weiterhin mit Block.one zusammen, um mehr als zwei Verbindungen zum Block-Signaturknoten herzustellen, damit dieser effizient und redundant arbeitet.

Diese Zusammenfassung sollte sowohl für andere Blockhersteller unter EOS als auch für andere EOSIO-Netzwerkblockhersteller hilfreich sein, die möglicherweise ein ähnliches Design entwickeln möchten, um eine Überlastung zu vermeiden.

Probleme, die bei der Fehlerbehebung helfen würden:

• Debugging-Informationen zu Blöcken, die #8477 erzeugt haben
• Anzahl der Transaktionen in der Warteschlange #8539 verfügbar machen
  

GitHub EOSIO Pull-Anfragen:

• Neue Benachrichtigungsfunktion für Block-ID entfernen - 2.0 #8471
• Bericht Block Header Diff, wenn Digests nicht übereinstimmen - 2.0 #8472
• Späte Blöcke fallen lassen - 1.8 #8495
• Späte Blöcke fallen lassen - 2.0 #8496
• CPU-Blockaufwand - 1,8 #8507
• Konsolidierte Sicherheitskorrekturen für 2.0.1 #8514
• Konsolidierte Sicherheitskorrekturen für 1.8.10 #8516
• Schließen Sie den Socket vor dem asynchronen Rückruf - 2.0 #8526
• Net Plugin Versand - 2.0 #8546
• Sendepriorität des Netz-Plugins - 1.8 #8547
• Nicht verbindbare Net Plugin-Blöcke - 2.0 #8552
• Spätscheck fallen lassen - 2.0 #8555
• Schreibgeschützt mit Drop-Late-Block - 2.0 #8557
• Net Plugin Post - 2.0 #8561
• Verzögerte Produktionszeit - 2.0 #8564
• CPU-Blockaufwand - 2.0 #8571
• Net Plugin nicht verbindbar - 1.8 #8572
• CPU-Aufwand letzter Block - 1.8 #8574
• CPU-Aufwand letzter Block - 2.0 #8578
• P2P schreibgeschützt - 2.0 #8583
• Producer Plugin Log - 2.0 #8589
• Init net_plugin Mitgliedsvariablen - 1.8 #8616
• Init net_plugin Mitgliedsvariablen - 2.0 - #8617
• Beenden Sie die Transaktion vorzeitig, wenn die CPU des Kontos nicht ausreicht - 2.0 #8638
• Block erzeugen, wenn max_block_cpu_usage #8649 erreicht hat
• Bei Erschöpfung sofort Block produzieren - 2.0 #8651

Diagrammdetails

Hier sind die technischen Details der Konfiguration:

• Produzenten-Knoten
  1.8.x oder 2.0.x, wabt, spekulativ, CPU-Aufwand-Prozent = 50 - 80
• Blockiert den Peer-Knoten
  2.0.x, eos-vm-jit, schreibgeschützt, vollständige Validierung
• Transaktionssperrknoten
  1.8.x, wabt, spekulativ, Lichtvalidierung
• Peer-Knoten für Transaktionen
  2.0.x, eos-vm-jit, spekulativ, vollständige Validierung