Autor: Marco González

Redakteur: Randall Roland

Übersetzer: Markus Hinrichs

Jede Woche treffen sich die Node Operators (EOS Knotenbetreiber), Antelope-Kernentwickler und Community-Mitglieder, um die spannenden Fragen des Tages zu diskutieren. Das Hauptziel jedes Node Operator Roundtables ist:

„...das Antelope-Protokoll (speziell) für Knotenbetreiber zu verbessern“.

Die Treffen finden jeden Mittwoch von 14 UTC bis 15 UTC statt.

Bei den ersten beiden Rundtischgesprächen im März wurde die Diskussion über special purpose nodes (Spezialknoten) fortgesetzt, insbesondere im Hinblick auf bewährte Verfahren. Der runde Tisch am 1. März befasste sich mit den Zielen von BP-Knoten und den best practices (bewährte Verfahren). Der 8. März endete mit reinen Block-Relay-Knoten. Wenn du dich über das bevorstehende „Code Freeze“ informieren möchtest, erwarte eine Ankündigung in den Tagen nach dem Rundtischgespräch am 8. März. Was die Veröffentlichung von Leap 4.0.0 im Testnetz betrifft, so bleibt das Entwicklungsteam im Zeitplan für das Ziel Ende März/Anfang April.

Der „Entwurf einer Taxonomie der Rollen, die die verschiedenen Antilope-Knoten spielen“ enthält umfassende Hinweise. Um den Beginn der Diskussion über die Spezialknoten zu erkunden, besuchen Sie den Abschnitt „Post Upgrade Meetings“ auf GitHub.

Sieh dir die Diskussionsrunde vom 1. März auf dem YouTube-Kanal der ENF an. Dazu gibt es Notizen von EOS Nation (Leap) auf GitHub.

Der runde Tisch vom 1. März ist der vierte in einer fortlaufenden Diskussion über Special Purpose Nodes. Dabei geht es unter anderem um effizientere Ressourcenmodelle im gesamten Ökosystem. Dazu gehört eine Three-Strikes-Regel gegenüber subjektiven Abrechnungsanforderungen.

Die Teilnehmer des Roundtables haben Notizen History providers aufgegriffen. Zu den primären Knotentypen, die im Entwurfsdokument ausdrücklich erwähnt werden, gehören:

Layer-2-Lösungen, die History erwähnen, sind

Bezüglich der „State History“ sind unter anderem folgende Punkte zu beachten:

Siehe auch die Folgevorschläge zur Historie.

Die Liste der Knotentypen endet mit dem Ressourcenanbieter-Knoten, der dritten Layer-2-Lösung auf der Liste. Sein Ziel ist es, die Benutzerfreundlichkeit zu verbessern. Während der Resource Provider Node derzeit nodejs ausführt, kann er letztendlich wie ein API-Plugin dezentralisiert werden. Der Entwurf des Taxonomiedokuments definiert den Resource Provider Node wie folgt:

Die Sitzung wurde mit Best Practices und dem Aufwand und den Anforderungen für eine optimale Konfiguration fortgesetzt. Ein Hauptziel der Best Practices ist die Ermittlung von Mindestanforderungen für alle Antelope-Netzwerke (z. B. WAX, Telos...).

Es wird wahrscheinlich Debatten über die besten Praktiken geben, insbesondere in Anbetracht der unterschiedlichen Anforderungen in den verschiedenen Netzen. Zum Beispiel variieren die folgenden Punkte je nach Nutzung des Blockchain-Netzwerks:

Die Diskussion über die besten Praktiken wurde von den Geräteanforderungen übernommen. Die Betreiber sollten die Gesamtkonfiguration von Nodeos überprüfen, wenn sie einen Knotentyp ändern. So sollte z. B. bei einem Betrieb mit Starts und Stopps im Gegensatz zu einem ununterbrochenen Betrieb eine CPU gemäß den Empfehlungen von AtticLabs neu eingestellt werden. Im Entwurf des Taxonomiedokuments findest du den AtticLabs-Link und andere Geräteanforderungen wie ECC-RAM, x86-Prozessoren und mehr.

Zum Abschluss des Rundtischgesprächs gab es Anmerkungen zu bewährten Sicherheitspraktiken und zur Nichtwiederverwendung von Hardwareschlüsseln.

Chain API Node erhielt einige abschließende Worte zu den Best Practices der Nodeos-Konfiguration für Block Producer Nodes. Die Empfehlungen umfassen:

Die Chain API Node-Diskussion schloss mit der Frage, was verfügbar werden sollte (z.B. die Vereinfachung mit nur Getinfo, obwohl Prometheus vielleicht eine andere Lösung bietet).

Beachte, dass bestimmte Knotentypen unterschiedliche Konfigurationen erfordern. Das Treffen schließt mit weiteren Punkten zur Nachbereitung (unter dem Abschnitt „Next Steps“ des Taxonomieentwurfs).

Sieh dir die Diskussionsrunde vom 8. März auf dem YouTube-Kanal der ENF an. Notizen von EOS Nation (Leap) gibt es dazu auf GitHub.

Das Antelope-Team berichtet, dass ein Release Candidate (Veröffentlichungskandidat) für Ende des Monats/Anfang April in Aussicht ist. Die auf die Zukunft ausgerichtete Entwicklung von Antelope Leap 4.0.0 ist vorerst abgeschlossen. Eine Ankündigung über einen 'Code Freeze' steht unmittelbar bevor. Die Veröffentlichung von Antelope Leap 4.0.0 wird voraussichtlich in einigen Wochen erfolgen.

In der anfänglichen Diskussion wurden die bewährten Praktiken der Konfiguration von nodeos für Blockproduktionsknoten wieder aufgegriffen. Peering ist fast immer intern. Der Schutz eines internen Knotennetzes mit einem WireGuard-Schlüssel (zum Beispiel) ist effektiv. WireGuard ist nur eine Möglichkeit. Solche Schlüssel verhindern unerwartete, störende Verbindungen.

Spezielle Anwendungsszenarien (z. B. resyncing = Neusynchronisierung) wurden unter dem Abschnitt "Next Steps" behandelt. Außerdem wurde empfohlen, die Effizienz zu erhöhen.

Der Rest des Rundtischgesprächs konzentrierte sich auf Block-only-Relay-Knoten und deren bewährte Konfigurationsverfahren. Die Gruppe ging ausführlich auf die Anzahl der Verbindungen ein. In einer früheren Sitzung wurden 10 bis 15 Verbindungen für die Konfigurationsdatei als angemessen erachtet. Dieser kleine Verbindungsbereich ist lediglich ein Ausgangspunkt.

In Bezug auf Leap 3.2 ist eine maximale Anzahl von 25-50 Verbindungen für reine Block-Relay-Knoten sicher. Es wurden mehrere Hinweise hinzugefügt:

Die erste Überlegung, die bei den Anforderungen für reine Block-Relais-Knoten angestellt wurde, war, dass mehr als ein Gerät benötigt wird, um einen Single Point of Failure zu vermeiden.

Der Rest der Diskussion konzentrierte sich auf Konnektivität und Geschwindigkeit. Eine zuverlässige Internetverbindung wurde hervorgehoben. Gleiches gilt für eine schnelle Festplatte mit Schwerpunkt auf Schreibzugriffen. Siehe andere Best Practices im Entwurf des Taxonomiedokuments für Kommentare zu vollständigen vs. partiellen Blockprotokollen. Beachte, dass Leap 4.0 eine automatische Knotenverbindungsfunktion haben soll.

Hier wird eine wichtige Unterscheidung bezüglich eines weit verbreiteten Missverständnisses getroffen. Bei Antelope-Ketten ist ein Snapshot nur der aktuelle Zustand. Das unterscheidet sich von der Definition von Ethereum. Für Antelope-Ketten benötigt ein Peer-Netzwerk also nur „genug“ eines vollständigen Block-Logs. Ein vollständiger Verlauf ist für interne Relais auf Antelope-Ketten nicht erforderlich.

In der Diskussion über den Entwurf der Taxonomie wurde immer wieder auf die Auswirkungen der Anpassung von Variablen außerhalb der Best Practices hingewiesen. Ein reiner Block-Only-Relais-Knoten akzeptiert zum Beispiel nur Blöcke. Beachte auch, dass Leap 4.0 möglicherweise keine reinen Block-Relais-Knoten erfordert.

In der nächsten Woche wird die Diskussion über bewährte Verfahren für die Nodeos-Konfiguration speziell für API-Knoten fortgesetzt.