Autor: Markus Hinrichs
Editor: Randall Roland
Übersetzer: Markus Hinrichs
Node-Betreiber, Antelope-Kernentwickler und Community-Mitglieder treffen sich jede Woche, um über das Netzwerk und seine Entwicklung zu sprechen. Das Hauptziel jeder Node-Betreiber-Runde ist:
"…die Verbesserung des Antelope-Protokolls (speziell) für Node-Betreiber."
Die Runden finden jeden Mittwoch statt. Besuche den Telegram-Kanal für Informationen zur Teilnahme. Die EOS Network Foundation bietet Tutorials und Dokumentationen für diejenigen an, die die Grundlagen des Betriebs eines EOS-Nodes erlernen möchten.
Diese Roundtables werden in diesem Überblick behandelt:
9. November: Leap 5.0-Status, Migrationsplan, Diskussion zum OC-Auto-Modus, Potenzielles Risiko für nicht aktualisierte Nodes und mehr
15. November: EOS VM OC-Fixes abgeschlossen, Erwarteter RC3-Release Anfang bis Mitte Dezember, Diskussion über Probleme.
Zusätzliche Besprechungsnotizen und Kommentaren auf findest du auf GitHub. Videos sind auf dem YouTube-Kanal der ENF verfügbar.
9. November: Leap 5.0-Status, Migrationsplan, Diskussion zum OC-Auto-Modus, Potenzielles Risiko für nicht aktualisierte Nodes und mehr
Aktualisierung des Leap 5.0-Status:
Die Arbeiten an Leap 5.0 sind seit einigen Wochen größtenteils abgeschlossen.
Ein ausstehendes Problem im Zusammenhang mit BLS-Bibliotheken wird für den Release-Kandidaten 3 (RC3) behandelt.
Es werden keine wesentlichen neuen Änderungen in RC3 erwartet, verglichen mit früheren Diskussionen.
Migrationsplan für das Upgrade auf 5.0:
Die Standardeinstellung ist jetzt "ES VM OC enable equals AUTO", was den OC-Modus selektiv basierend auf dem Kontext ermöglicht.
Diskussion über den Umgang mit heterogenen Netzwerken, in denen einige Nodes auf 5.0 aktualisieren, während andere dies nicht tun.
"Es gibt einige Bedingungen, unter denen Bedenken aufkommen könnten; es hängt von hoher Netzwerklast (CPU) ab" Brian Hazzard
Empfehlung für Nodes, die frühere Versionen ausführen, "ES VM OC enable ON" zu setzen, um mit der höheren Durchsatzgeschwindigkeit von Leap 5.0 Nodes Schritt zu halten (effizientere Speichernutzung, effizientere CPU usw.).
Eine klare Kommunikation und Beteiligung der Community werden entscheidend sein, um mit auftretenden Problemen umzugehen und letztendlich den Community-Mitgliedern bei der Aktualisierung ihrer Nodes zu helfen.
Diskussion zum OC-Auto-Modus:
Klärung, dass der OC-Auto-Modus vom Maschinentyp abhängt (Produzent oder Nicht-Produzent) und von den Systemverträgen.
Produzenten verwenden OC für EOSIO-Systemverträge; Nicht-Produzenten verwenden OC für alle Verträge, es sei denn, es ist anders konfiguriert.
Potenzielle Risiken für nicht aktualisierte Nodes:
Wenn ein Produzent nicht auf 5.0 aktualisiert und im OC-Modus ist, werden Blöcke während hoher Lasten von Nicht-Systemverträgen möglicherweise nicht von anderen Produzenten überprüft.
Rückdruckdynamik könnte nicht aktualisierte Nodes zur Aktualisierung ermutigen.
"... Und sie sollten aktualisieren… Wenn es eine Last gibt, dann aktualisieren" Matthew Darwin
Zeitplan für die Veröffentlichung von Leap 5.0:
Stabile Veröffentlichung voraussichtlich in einigen Wochen, mit rc3 ungefähr eine Woche entfernt.
Ermutigung für Node-Betreiber, Release-Kandidaten auf Nicht-Produktionsnodes zu testen, beginnend mit Testnetzen.
Zeitnahe Upgrade-Empfehlungen für Nicht-Produktions- und Produktionsnodes in Hauptnetzen.
Problemberichte und Beiträge:
Anerkennung von Problemberichten, insbesondere von aktiven Beitragenden wie Matthew.
Die meisten kritischen Probleme wurden behoben, und rc3 enthält Fixes von rc2+.
Brian Hazzard drückt Dankbarkeit für wertvolles Feedback aus, die aktive Teilnahme am Antelope-Node-Betreiber-Roundtable und am Community-Kanal wird sehr geschätzt. Der Anruf endet mit einer Einladung zur Teilnahme an der Sitzung der nächsten Woche.
15. November: EOS VM OC-Fixes abgeschlossen, Erwarteter RC3-Release Anfang bis Mitte Dezember, Diskussion über Probleme.
Aktualisierung des Status für 5.0
EOS VM OC-Hostfunktionsfixes sind abgeschlossen.
Vergleich zwischen zwei Hostfunktionsversionen mit Leistungsunterschieden.
Anvisierter 5.0-RC3-Release zwischen dem 6. und 14. Dezember.
Bitte um Testen von RC3 in Testnetzen oder Nicht-BP-Nodes in Produktion.
Feedback und Diskussion zu eingereichten Problemen
Unterstützung für beliebige Labels bei P2P-Peers (Kevin Heifner)
Vorschlag: https://github.com/AntelopeIO/leap/pull/1768
Diskussion über die Notwendigkeit beliebiger Labels, da es die Komplexität erhöht und die Lesbarkeit verringert.
Laut Matthew Darwin wäre es wahrscheinlich am besten, eine JSON-Struktur für zusätzliche Peer-Informationen hinzuzufügen.
Überlegungen zur Umstrukturierung der Peering-Konfiguration vor der Implementierung.
"Es wird sowieso nicht in Leap 5 enthalten sein, daher macht es Sinn, auf diese Refactoring-Arbeit zu warten"
Vorschlag von Mathew Darwin: Zwangs-Flush-Statusdateien nicht auf Nodeos-Exit
Die Diskussion drehte sich um den Vorschlag und dessen Auswirkungen auf die Gesamtsystemleistung.
Kevin Heifner betrachtet das Flushen als entscheidend, erkennt jedoch verbundene Probleme, wie erhebliche Verzögerungen beim Neustart. Diese Herausforderung ergibt sich aus der Notwendigkeit, nicht nur die kleine Nodeos-Datei, sondern auch zahlreiche Dateien von anderen Chains zu flushen.
In diesem Zusammenhang teilte Ross einen Medium-Artikel, der potenzielle Verbesserungen mit ZFS diskutiert.
Kevin empfahl, das diskutierte Problem zu schließen und plädierte dafür, das Flushen mit Leap 5.0 zu testen. Er betonte die zahlreichen Leistungsverbesserungen in Leap 5.0, einschließlich des Features "mapped private node", das das Flushen erheblich beschleunigen kann.
Log Non-Default-Optionen, eine pro Zeile
Wenn nodeos startet, protokolliert es alle nicht standardmäßigen Optionen in einer langen Zeile.
Dies ist eine stilistische Entscheidung gemäß Brian Hazzard
Gründe für die Verwendung von Zeilenabgrenzung:
Implementiert, um die Durchsuchbarkeit zu verbessern und die Suche in Logdateien zu erleichtern.
Gründe für die Konsolidierung in einer einzelnen Zeile:
Wird als wertvoll für die Fehlerbehebung angesehen, erhöht die Wahrscheinlichkeit, in eine Logzeile eingefügt zu werden.
Verbessert die Praktikabilität und vereinfacht die Verwendung in Problembehandlungssituationen.
Neues Feature hinzufügen: Ist der Zustand kompatibel
Vorschlag für ein Service-Skript, das Kompatibilitätsprüfungen erleichtern soll, um Zeitverzögerungen zu reduzieren.
Erörterung über die Nutzung von Snapshots und Nodeos-Exit-Codes folgte.