Autor: Marco González

Redakteur: Randall Roland

Übersetzung: Markus Hinrichs

Node-Operators treffen sich jede Woche mit den Kernentwicklern von Antelope und Mitgliedern der Community. Das übergeordnete Ziel des „Node Operator Roundtable“ ist:

Die Treffen finden mittwochs um 14 Uhr UTC statt und dauern eine Stunde.

Der Runde Tisch am 1. Februar befasste sich mit aktuellen (Leap v3.2) und zukünftigen Konfigurationsparametern. In der Mitte der Diskussion wurde deutlich, dass die Knotenkonfiguration ein Thema ist, dem weitere Aufmerksamkeit gewidmet werden muss.

Mit der kürzlichen Veröffentlichung von DUNE v1.1 macht Leap einen weiteren Schritt nach vorne, in Richtung Erleichterung der Entwicklung und des Betrieb von Nodes. Beachte, dass die Unterstützung für Ubuntu 18.04 vor dem Test von Leap v4.0 im März eingestellt wird. Entwickler, die Ubuntu verwenden möchten, müssen ein Upgrade durchführen. Die Ubuntu-Versionen 20.04 und 22.04 werden offiziell unterstützt.

Beachte auch, dass die Tests im März kein Konsens-Upgrade beinhalten werden. Stattdessen wurde (während des Runden Tisches am 8. Februar) der September als mögliches Konsens-Zieldatum genannt.

Die Konfiguration von Knoten für spezielle Zwecke erweist sich als komplexes Thema. Eine neue Dokumentation wird dringend benötigt. Die Leap 3.2-Dokumentation soll verbessert werden, um Konfigurationen vor dem Upgrade zu berücksichtigen.

Die HTTP-response times (Antwortzeiten) nahmen einen großen Teil des Treffens in Anspruch. Es besteht Einigkeit darüber, dass die response time mindestens der max serialization time (maximalen Serialisierungszeit) entsprechen muss. Die response times können höher angesetzt werden, um ein Gleichgewicht zwischen eingehenden und ausgehenden Anfragen zu gewährleisten. Zum Beispiel schlägt eine HTTP-Anfrage fehl, die bei großen Blöcken eine Zeitüberschreitung verursacht. Atomic Hub wurde zur Veranschaulichung verwendet.

Darüber hinaus müssen übermäßige call data und die Gesamteffizienz in Zukunft berücksichtigt werden. Schon früh in der Diskussion wurde erwähnt, dass man Hilfe bei „Boost-Bibliotheken“ und strategischen Änderungen erwarten kann.

Sieh dir hierzu auch die Aufzeichnung auf dem YouTube-Kanal der EOS Network Foundation an.

Die Notizen zu potenziellen Knotenkonfigurationen und Anwendungen nahmen einen großen Teil dieser Sitzung ein. Das Diskussionsthema der nächsten Woche lautet: „Special Purpose Nodes“.

Die Frage, wie man Knoten am besten für spezifische Bedürfnisse konfiguriert, wird voraussichtlich sogar über die Diskussion der nächsten Woche hinausgehen. Zu den wichtigsten Bereichen, die als verbesserungsbedürftig identifiziert wurden, gehören:

Beachte, dass die Punkte (z. B. Druckverringerung und Effizienz) oft miteinander verbunden sind. Spezielle Knoten und deren Klassifizierung befassen sich mit abstrakten Konzepten. Die Diskussion dient vor allem auch dazu, Klarheit zu schaffen.

Der Runde Tisch am 8. Februar begann mit der Klassifizierung der verschiedenen Arten, wie Knoten konfiguriert und verwendet werden. Ein in der Entwicklung befindliches Antelope-Knoten-Taxonomiedokument wird im Vorfeld von Leap v4.0 (Zieldatum ist Ende März im Jungle-Testnetz) veröffentlicht. Bereits im September wird ein konsensfähiges Leap-Upgrade erwartet.

Zusätzlich zu den Zieldaten März und September erwarten wir eine Ankündigung bezüglich eines Code-Freeze für Leap 4.0.

Special Purpose Nodes (Knoten für Spezialzwecke) sind ein konzeptionelles Modell für alle möglichen Anwendungsfälle. Die Organisation der Knotenverwendung und -konfiguration ist ein Thema, das die EOS-Entwickler schon seit einiger Zeit umtreibt. Mit der Version 4.0 werden die Betreiber von Knoten einen großen Sprung bei der Rationalisierung der täglichen Verwaltung erleben.

Brian Hazzard verglich den Brainstorming-Prozess für Knoten mit „Legosteinen“. Wie man sich denken kann, sind die Eigenschaften und späteren Rollen der Antelope-Knoten oft abstrakt. Rückmeldungen aus der Community sind willkommen. Die aktuelle Liste der Knoteneigenschaften oder lose Klassifizierungen findest du im Leitdokument: Entwurf einer Taxonomie der Rollen, die verschiedene Antilopen-Knoten spielen.

Die vorläufigen Klassifizierungen sind im Entwurfsdokument aufgeführt. In dieser Gesprächsrunde wurden folgende Klassifizierungen geprüft:

Im Folgenden findest du eine Übersicht über die in dieser Sitzung besprochenen Knotentypen. Weitere Details findest du auf GitHub (siehe Issues der Woche) und im Taxonomie-Entwurfsdokument.

Zu den identifizierten Merkmalen konsenspflichtiger Knoten, die Blöcke zu einer Kette hinzufügen, gehören:

Zu den bewährten Konfigurationsverfahren gehören:

Siehe den Taxonomie-Entwurf für zukünftige Überlegungen.

Die grundlegendste Klassifizierung ist der Block-Relay-Knoten. Die Definition sagt schon alles. Das Relaying umfasst die Aufrechterhaltung von Verbindungen mit Peers und die Validierung von Block-Headern. Wir danken Stephen Diesel für seinen Kommentar:

„Gute Blöcke gehen rein, gute Blöcke gehen raus.“

Der Vorteil eines Relay-Knotens ist, dass er mit mehr Peers (10-15) arbeiten kann als ein BP-Knoten. Beachte auch, dass ein Block-Relay-Knoten zwar öffentlich sein kann, aber nicht beworben werden sollte (z. B. in bp.json).

Stephens Kommentar verdeutlicht die Notwendigkeit, eine Peer-Gruppe aufrechtzuerhalten, die in der Lage ist, konstant Blöcke bereitzustellen, die weitergegeben werden können. Zur Aufrechterhaltung einer offenen Pipe gehören nicht nur synchronisierte Transaktionen, sondern auch die Bereitschaft, neue Blöcke zu akzeptieren. Das Versäumnis, diese Bereitschaft aufrechtzuerhalten, wurde als eine Ursache für leere Blöcke identifiziert.

Wie Block-Relay-Knoten kann auch ein Transaktions-Relay-Knoten nur dazu dienen, Blöcke nach der Validierung eines Headers weiterzuleiten. Der Transaktions-Relay-Knoten zeichnet sich dadurch aus, dass er auch Transaktionen annehmen kann:

Kevin Heifner stellte einen Link zu einer in Arbeit befindlichen Lösung zur Verbesserung der Blockweiterleitung nach der Header-Validierung zur Verfügung. EOSUSA Michael teilte ein Diagramm seines Knotenaufbaus (siehe Runder Tisch vom 8. Februar).

Bewährte Praktiken werden erforscht und in Zukunft detailliert beschrieben. Bei den Knotentypen scheint es drei Grundkonfigurationen zu geben:

Sieh dir auch diese Aufzeichnung der EOS Network Foundation an.

Die nächsten fünf Knotenklassifizierungen im Dokumententwurf sind:

Die Diskussionsreihe über Special Purpose Nodes wird voraussichtlich nächste Woche fortgesetzt, wobei der Schwerpunkt auf den oben genannten (API-)Klassifizierungen, bewährten Verfahren und der zugehörigen Dokumentation liegen wird.