Autor: Marco González

Redakteur: Randall Roland

Übersetzung: Markus Hinrichs

Seit der ersten Einführung von AntelopeIO (Leap 3.1) im September hat sich der Schwerpunkt von der Berichterstattung über die Einführung von Technologien der nächsten Generation auf die Identifizierung wichtiger Funktionen für die Weiterentwicklung verlagert. Wichtige Themen im Jahre 2022 waren mitunter:

Diese Ausgabe der zweimonatlichen Zusammenfassung des EOS Node Operator Roundtables umfasst den 04. Januar sowie den 11. und 18. Januar. Die ersten beiden Sitzungen des Jahres 2023 fanden in einem anderen Format statt; aus Sicherheitsgründen wurden keine Videos veröffentlicht.

Ein Hauptanliegen des runden Tisches vom 4. Januar war es, Feedback zu möglichen Änderungen des AntelopeIO-Ressourcenmodells einzuholen. In den vorangegangenen Wochen wurden Probleme mit der Überlastung von WAX als Bereiche identifiziert, die für die allgemeine Betriebsleistung verbessert werden könnten. Zu Beginn der Sitzung wurden die Probleme der Knotenbetreiber ermittelt.

Im Anschluss an die Diskussion über die RAM-Nutzung wurde über Low-Grade- und High-Grade-Hardware nachgedacht. Mögliche Knackpunkte sind die Limitierung (Low-Grade) und die wirtschaftliche Tragfähigkeit (High-Grade). Im Hinblick auf ein neues Ressourcenmodell besteht die Möglichkeit:

Die Idee ist, dass ein neues Ressourcenmodell sich auf eine kosteneffiziente Erhöhung des verfügbaren Netzwerkspeichers konzentrieren sollte.

Ein "Gas"-Ressourcenmodell (oder "Fueling"-Modell) wurde gegen die derzeitigen Optionen wie Rohressourcen, REX und Powering Up Services abgewogen. Es hat sich jedoch gezeigt, dass das fueling jeder Transaktion seine eigenen Probleme mit sich bringt. Mikrotransaktionen, ein Bereich, in dem sich EOS auszeichnet, sind für Gasmodelle typischerweise eine große Belastung. Außerdem gibt es einen psychologischen Faktor bei der Abkehr von den eingebauten Operationen von EOS.

Gas-freie Operationen kennzeichnen EOS als eine einfach zu bedienende Kette. Eines der frühen Konzepte, die die Entwicklung von EOS leiteten, war, dass dApps selbst ihre Dienste so modellieren, dass sie Ressourcenanbieter für ihre Nutzer sind. Sicherlich ein Nutzer-Plus. Die wirtschaftliche Tragfähigkeit und das Missbrauchspotenzial bedürfen jedoch weiterer Überlegungen.

Ein mögliches Ergebnis aus der Gas-Diskussion war die Kodifizierung nativer Lösungen. Durch die Evaluierung der Ressourcen-Nutzer (z. B. Anwender, Entwickler, Wallets und Knotenbetreiber) können Einschränkungen ermittelt werden. Das Ressourcenmodell wäre dann bereit, das Betriebsumfeld zu verbessern.

Das Ziel für die Entwicklung eines neuen Ressourcenmodells ist:

Ein Bereich, der mit relativ geringem Aufwand große Vorteile zu bieten scheint, ist der oft zweideutige PowerUp-Dienst. Nicht untersuchenswert war die Verbesserung der NET-Ressourcen.

Zu den Themen auf der Tagesordnung gehört die Fortsetzung der Diskussion über das AntelopeIO-Ressourcenmodell, insbesondere für Node-Dienste. Zu den bereits identifizierten Problembereichen gehören History und API.

Für den 11. und 18. Januar wurden unterschiedliche Sitzungsprotokolle veröffentlicht. Letztere begann mit einer Zusammenfassung der letzten beiden Gespräche. Danach lag der Schwerpunkt auf der Fortsetzung der Diskussion über das Ressourcenmodell.

Zu den wenigen erwähnten Software-Fortschritten gehörten:

Die Sitzung wurde mit dem Feedback der Entwickler eröffnet. Zunächst wurde die Mac-Entwicklung angesprochen, mehr dazu in einer späteren Gesprächsrunde. Obwohl Mac nicht offiziell unterstützt wird, können Entwickler selbst kompilieren. Zu den interessanten Themen gehörte die Kompilierung von CDT (Contract Developer Toolkit) als Option zu DUNE (Docker Utilities for Node Execution). GitHub-Aktionen (und Ubuntu) wurden ebenfalls als Option zur Kompilierung und damit zur Umgehung von CDT erwähnt.

An diesem Punkt der Diskussion fand ein neuer runder Tisch, speziell für Entwickler, Unterstützung.

Die Diskussion wurde darüber fortgesetzt, wie sich das AntelopeIO-Ressourcenmodell auf die Knotenbetreiber auswirkt. Der Status wurde aktualisiert:

Eine offene Diskussion darüber, wie das Feedback der Node Operators der ENF helfen kann, Lösungen zu liefern. Im Folgenden werden Themen genannt, die den Betrieb erleichtern (oder erleichtern) könnten.

Das EOS Nation Tooling wurde als hilfreicher Ausgangspunkt für die Einrichtung und den Betrieb eines Knotens erwähnt. Auch Animus wurde für die Verfolgung von Endpunkten genannt.

Das Ersetzen der Abhängigkeit von Drittanbietern durch nativere Lösungen (z. B. Wharf-Kit, bessere Wallets, Verbesserung des Powerups) soll die Nutzbarkeit der Kette verbessern. Diese Lösung wurde als wenig aufwändig und lohnend eingestuft. Andere effiziente Lösungen waren:

Komplexere Lösungen scheinen Peering und die Gewährleistung der Konnektivität zu sein. Bei WAX wurde ein großer Bedarf in diesem Bereich gesehen. Wenn ein öffentlicher Knotenpunkt voll wird, könnten Optionen für private Knotenpunkte und/oder bevorzugte Peers bestehen. Öffentliche Knoten würden weiterhin gepflegt werden.

Der letzte Punkt auf der Liste für das Treffen am 18. Januar waren Nodeos-Instanzen mit Lesezugriff und Blockpropagation. Das Zusammenführen von Blöcken nach Headers dürfte eine erhebliche Verbesserung darstellen. Die Blockweitergabe wird durch den bereits erwähnten 3.1-Patch und möglicherweise durch reine Relay-Knoten unterstützt.

Die Entlastung von Knoten, die schreiben und synchronisieren, kann durch Nur-Lese-Flags (aus Statusdateien) erreicht werden. Die Skalierung verbessert sich, wenn der Druck auf die Knoten verringert wird. Durch die Identifizierung von Knoten für einen bestimmten Zweck können mehr Peers einbezogen werden, während gleichzeitig der Arbeitsspeicher reduziert wird.

Zweckgebundene Knoten brachten die Diskussion über aufwendigere und interaktive Funktionen auf. Sollte nodeos beispielsweise eine umfassende Lösung sein oder bieten Microservices Vorteile? DFUSE und GRAPH wurden hier erwähnt.

Beachte auch, dass in Kürze ein schreibgeschütztes Design-Dokument veröffentlicht werden soll.

Aus terminlichen Gründen kann die nächste Sitzung leider nicht stattfinden.