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:

GitHub EOSIO Pull-Anfragen:

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

EOS Nation ist einer der Top 21 Blockproduzenten im öffentlichen EOS-Netzwerk. Wir verdienen Inflationsprämien basierend auf dem Prozentsatz der Token, die auf uns gesetzt werden. Diese Belohnungen werden über unsere an Token-Inhaber zurückgegeben Proxy4Nation Reward Proxy und auch in EOSIO-Community, Tools und Infrastruktur reinvestiert. Helfen Sie mit, das Ökosystem zu vergrößern, indem Sie Ihre Stimme abgeben eosnationftw oder Proxy zu Proxy4Nation

2 Gedanken zu “EOS Mainnet Update: New Node Architecture Greatly Improves EOS Reliability”

  1. Diese Updates für EOSNation sind fantastisch und helfen mir zu glauben, dass meine Investition in EOS in guten Händen ist. Es wäre großartig, wenn alle BPs regelmäßig einen ähnlichen Bericht aus jeder ihrer Perspektiven veröffentlichen würden. Einer der größten Brennstoffe für FUD ist der Weltraum (abgesehen von einfachen alten Lügen) die Stille. Vielen Dank für Ihre großartige Arbeit und bitte ermutigen Sie andere BPs, Ihrem Beispiel in großartiger Kommunikation zu folgen.

    • Vielen Dank fürs Lesen und für den wunderbaren Kommentar! Wie bei anderen BPs, die ähnliche Berichte veröffentlichen, besteht unseres Erachtens kein so großer Bedarf. Wir freuen uns, diese Rolle als „führender Kommunikator“ innerhalb der Top21 zu übernehmen.

Kommentare sind geschlossen.

Daniel Keyes

Chief Operating Officer (COO)
Zu den Aufgaben gehören: Produktmanagement, Betrieb, Community
Ort: Toronto, Kanada

Vor der Gründung der ersten EOS-Community in Toronto und der Mitbegründung von EOS Nation war Daniel ein Jahrzehnt lang in der Finanztechnologie tätig und arbeitete in verschiedenen Funktionen. Seine langjährige Erfahrung in den Bereichen Kundenservice, Vertrieb, Vertriebscoaching, Agententraining, digitales Marketing, digitales Prozessmanagement (Lean Green Belt) und Produktmanagement (zertifizierter Scrum Master, zertifizierter Product Owner) führte ihn schließlich zur Beratung für einen Blockchain-Entwickler.

Daniel erwarb 2009 einen Bachelor of Journalism an der Ryerson University und arbeitete als Praktikant im Bereich Chase Producer bei Global TV.

Daniel lebt nach den Prinzipien von Wahrheit, Liebe und Freiheit.