Alle Kollektionen
EOS Support News
EOS Node Operator Roundtable: Halbmonatlicher Überblick [July 2023 #2]
EOS Node Operator Roundtable: Halbmonatlicher Überblick [July 2023 #2]

Veröffentlicht am 4. August 2023

Markus Hinrichs avatar
Verfasst von Markus Hinrichs
Vor über einer Woche aktualisiert

Autor: Marco González

Redakteur: Randall Roland

Übersetzer: Markus Hinrichs

Node-Betreiber, Antelope-Core-Entwickler und Community-Mitglieder treffen sich jede Woche, um die fesselnden Fragen des Tages zu besprechen. Das Hauptziel jeder Node Operator Roundtable ist:

"... Verbesserung des Antelope-Protokolls (speziell) für Node-Betreiber".

Die Treffen finden jeden Mittwoch von 14 Uhr UTC bis 15 Uhr UTC (während der Sommerzeit von 13 Uhr UTC bis 14 Uhr UTC) statt. Die EOS Network Foundation bietet Tutorials und Dokumentationen für diejenigen, die die Grundlagen des Betriebs eines EOS-Nodes (und mehr) lernen möchten.

Unten findest du eine Liste der Roundtables, die in dieser zweimonatlichen Zusammenfassung enthalten sind:

  • Juli: ENF Empfohlene Konfigurationsänderungen für Version 5.0

  • Juli Nr. 2: Abgesagt

Weitere Besprechungsnotizen und Kommentare finden Sie auf GitHub. Videos befinden sich auf dem YT-Kanal der ENF.

Juli: ENF Empfohlene Konfigurationsänderungen für Version 5.0

Der Roundtable am 19. Juli könnte sich als Wendepunkt für die Node-Betreiber-Community erweisen, wenn der Fokus von Antelope v4.0 auf v5.0 verschoben wird. Die Maßnahmen zur Vorbereitung der Einführung von Version 5.0 beginnen wahrscheinlich mit den in der heutigen Sitzung diskutierten Konfigurationsänderungen der ENF.

ÜBERSICHT

Eric Passmore veröffentlichte Notizen auf Telegram, die die Empfehlungen der ENF für nodeos-Konfigurationsänderungen skizzieren. Die Hauptpunkte aus den Notizen sind im folgenden Abschnitt aufgeführt.

Eric begann damit, aufmerksam zu machen, wie viel sich seit der Veröffentlichung der Version 2.0 durch B1 verändert hat. Die Änderung der Konfiguration macht auf so vielen Ebenen Sinn. Dennoch basieren die Empfehlungen der ENF sowohl auf Leistungstests als auch auf empirischen Daten.

THEMA: Veröffentlichte Empfehlungen aus dem Node Operators Telegram-Channel vom 18. Juli

Der erste identifizierte Punkt sind Transaktionen innerhalb der Produktionsumgebung, die 30 ms überschreiten. Hier sticht das Update für read_only-Transaktionen aus Leap 4.0 hervor. Eine Erhöhung der Grenzen kommt sowohl read_only- als auch allgemeinen Produktionsumgebungstransaktionen sofort zugute.

Die empfohlenen Konfigurationsänderungen der ENF für Juli 2023 (wie von Eric Passmore veröffentlicht) lauten wie folgt:

1. Für Änderungen an der read-only-Konfiguration sind nur Leap-Versionen 4.0 und später betroffen:

  • “(165ms) read-only-read-window-time-us to 165,000”

  • “(151ms) max-transaction-time to 151”

2. Für Änderungen an multisig ist nur das Jungle-Testnetz (derzeit) betroffen. Für das Hauptnetz sind noch keine Änderungen erforderlich.

  • “(150ms) max_transaction_cpu_usage to 150,000”

  • “(200ms) max_block_cpu_usage to 200,000”

Erwarte, dass die vorgeschlagenen Änderungen weiterhin auf das Jungle-TestNetz ausgerichtet sind, bis ein Einführungsplan mit dem wöchentlichen Node Operator-Meeting abgestimmt wird.

Die vorgeschlagenen Änderungen gehen der standardmäßigen Konfiguration voraus, die mit der Veröffentlichung von Version 5.0 bereitgestellt werden soll. Erics Beitrag schließt mit dem Hinweis, dass die Konfigurationseinstellungen zu den Punkten gehören, die verfolgt werden, um sicherzustellen, dass sowohl Produzenten als auch Chains die gleichen Einstellungen haben, um eine koordinierte Einführung von Version 5.0 zu gewährleisten.

Diskussion der Sitzung

Eric nahm am Roundtable-Meeting teil, um die empfohlenen Änderungen zu erörtern. Die Community musste sich nicht intensiv mit der Diskussion befassen, um die Absicht der ENF zu verstehen. Es gab auch keine Einwände.

Kurz diskutierte Themen umfassen:

  • Zeitklarstellungen

  • Erhöhung von 30 auf 151 Millisekunden bietet ausreichend Spielraum

  • erwarten Sie ein paar Wochen Testzeit im Jungle für neue Änderungen

  • Schwerpunkt auf reibungsloser Koordination beginnt mit Konfigurationsänderungen

  • ausreichende subjektive Abrechnung für Transaktionsfehler

Subjective billing (Subjektive Abrechnung) hilft, fehlgeschlagene Transaktionen aufgrund der Kosten für CPU und Konfigurationsänderungen zu verhindern.

Beachte, dass es unmöglich ist, die Aktivitäten im EOS-Netzwerk perfekt zu simulieren. Geplante Änderungen müssen möglicherweise angepasst werden. Weitere Überlegungen sollten angestellt werden, was schief gehen könnte (insbesondere bei Blockproduzenten).

An diesem Punkt wurde vorgeschlagen, einen neuen Blog-Beitrag zu verfassen. Node-Betreiber werden mehrmals im Blog-Beitrag vom 24. Mai, "An Introduction to Subjective Billing and Lost Transactions", erwähnt.

Andere bemerkenswerte Erwähnungen in Bezug auf Konfigurationsänderungen umfassen Leistungs-/Benchmark-Tests. Es besteht Zuversicht, dass die Konfigurationen standhalten werden.

Version 5.0, Subjective Billing und schnellere Blockausgabe

Wie wird Antelope Leap Version 5.0 Blöcke schneller ausgeben? Der Beitrag vom 24. Mai (oben erwähnt) führt Updates für die subjektive Abrechnung ein:

"Neue Funktionen in Mandel 3.1 ermöglichen es Node-Betreibern, den Zeitparameter für den subjektiven Abrechnungsrückgang ihres Nodes bei der Initialisierung festzulegen. Diese Option wird die Zeit anpassen, die benötigt wird, um die subjektive Abrechnung eines Kontos auf Null zu setzen."

Die Ankündigung vom 8. August, "Leap v3.1 Release Features & Additional Tools", skizziert neue Tools für den Transaktionslebenszyklus:

"Frühere Artikel haben untersucht, wie das subjektive Abrechnungssystem zu verlorenen Transaktionen führen kann, und vorhandene Lösungen für häufig auftretende Probleme im Transaktionslebenszyklus wie verlorene Transaktionen beschrieben. Das Leap v3.1 Release führt neue Tools ein, um diese Probleme und andere Hürden in der Benutzererfahrung zu beheben."

Tiefgreifende Verbesserungen stehen bevor, da das subjektive Abrechnungssystem mit v5.0 reift. Anstelle von nicht angewendeten, wartenden Transaktionen kann der nächste Block sofort beginnen. Es wurde sogar vorgeschlagen, dass 12 Blöcke in einer einzigen Runde abgeschlossen werden können. Es wurde jedoch darauf hingewiesen, dass die Kontrolle über den letzten Block berücksichtigt werden sollte.

Das Meeting endete frühzeitig, da die Community sich darauf freut, sich für Version 5.0 abzustimmen.


Quellen & Referenzen

Hat dies Ihre Frage beantwortet?