Autor: Marco González

Redakteur: Randall Roland

Übersetzung: Markus Hinrichs

Jede Woche treffen sich Node-Operatoren, Antelope-Kernentwickler und Community-Mitglieder, um die spannenden Fragen des Tages zu diskutieren. Das Hauptziel jedes Node Operator Roundtable ist:

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

Die Treffen finden jeden Mittwoch von 14 UTC bis 15 UTC (13 UTC bis 14 UTC während der Sommerzeit) statt. Für diejenigen, die die Grundlagen des Betriebs von EOS-Knoten erlernen möchten, stellt die EOS Network Foundation Tutorials und Dokumentationen zur Verfügung.

Bei den Rundtischgesprächen am 19. und 26. April ging es um die Entwicklung von Leap. Am 19. April wurde ein Ausblick auf die Leap-Version 5.0 gegeben. Am 26. April war Version 4.0.0 in Betrieb genommen worden. Beim letzten Roundtable im April wurden Rückmeldungen eingeholt und ein neuer Vorschlag erörtert.

In der Diskussion wurde das zukünftige Potenzial des EOS Netzwerks erkundet. Die Sitzungsnotizen vom 16. April findest du auf EOS Nation GitHub. Siehe die Aufzeichnung des Rundtischgesprächs auf dem YouTube-Kanal der ENF an.

Antelope Version 5 ist noch Monate entfernt. Die Gestaltung der Entwicklung geschieht jetzt. Das Feedback der Community ist sehr willkommen. Sieh dir die Kommentare der Teilnehmer an und schreibe deine eigenen. Doch zunächst ein paar Aktualisierungen:

Unter der Leitung des Antelope-Teams wurden beim Rundtischgespräch am 19. April die Hoffnungen, Bestrebungen und Wünsche für Version 5.0 und darüber hinaus erörtert.

Die folgende Zusammenfassung gibt die von Brian Hazzard vorgetragenen Notizen wieder. Antelope Leap Version 5.0 wird voraussichtlich im Herbst 2023 veröffentlicht. Halte Ausschau nach Updates und einer möglichen Veröffentlichung bereits im September.

Version 5.0 des EOS-Hauptnetzes stellt die Zukunft und die Vision der Community dar. Die Teilnehmer wurden gebeten, ihre Wunschliste (Gedanken und Wünsche) zu äußern. Zu den Unterthemen der Diskussion gehörten:

Die oben genannten Unterthemen haben dazu beigetragen, Wünsche für die Entwicklung von 5.0 (und darüber hinaus) zu äußern. Im Folgenden findest du kurze Zusammenfassungen von jedem der neun Teilnehmer:

Ross: dynamische Peer-Erkennung, Automatisierung der besten Peers und einfache Anzeige des letzten Blocks

Das Feedback der Community ist für die aktuelle Entwicklung von zentraler Bedeutung. Man könnte meinen, dass ein frühes Feedback während der Entwicklung von 5.0 am wertvollsten wäre.

Nachdem Leap v4.0.0 nun live ist, liegt der Schwerpunkt auf der Festlegung eines Kurses für die Entwicklung von 5.0 in den kommenden Monaten. Die Sitzungsnotizen vom 26. April sind auf EOS Nation GitHub zu finden. Der Vorschlag, (aktualisierte) API/Serialisierungszeitbeschränkungen für nodeos 5.0, ist auf einem ENF hackmd.io Link zu finden. Eine Aufzeichnung finden Sie auf dem YouTube-Kanal der ENF.

Auch hier lag der Schwerpunkt auf dem Feedback der Community. Die Diskussion hatte eher den Charakter einer Frage-Antwort-Runde. Die Aktualisierungen umfassen:

Im Folgenden findest du einen kurzen Überblick über den Vorschlag. Die beiden wichtigsten Änderungen, die demnächst in 5.0 eingeführt werden, sind:

Bei den meisten ABI-Anfragen (Application Binary Interface) wurde die Deserialisierung in den HTTP-Thread-Pool verlegt. Das Ergebnis ist eine verbesserte Reaktionsfähigkeit von Nodeos auf dem Hauptthread.

Infolgedessen gibt es Beschränkungen für die Anzahl der zurückgegebenen Elemente für nicht-atomare APIs. Insbesondere müssen Anfragen für http_max_response_time einen Bereich und eine maximale Zeit angeben. Es ist zu beachten, dass gültige Anfragen immer mindestens ein Objekt zurückgeben, mit einer Standardhöchstzahl von 1.000 Elementen.

Die Diskussion verlief ungebundener als sonst. Die aufgelisteten Themen wurden nach dem ausgewählt, was besonders auffiel und die meisten Diskussionen auslöste.

Geschwindigkeit, Effizienz und das Vermeiden des Einfrierens des Haupt-Threads schienen die Verlagerung von get_block auf den HTTP-Thread zu begründen.

Prometheus wird gegenüber einer History-Lösung empfohlen. Prometheus sollte auch bei der Überwachung eine große Hilfe sein. Auf der Wunschliste steht eine leichtgewichtige, breit verfügbare Lösung.

Die Möglichkeit für Entwickler, ein Plugin zu verwenden, wurde kurz diskutiert. Auch die Weiterentwicklung des Plugins, die Erwähnung des trace_api_plugin und das Misstrauen einiger Entwickler (insbesondere im Finanzbereich) gegenüber Layer-2-Lösungen wurden kurz angesprochen.

Zu den anderen Themen, die ausführlich diskutiert wurden, gehörten:

Leap 5.0 wird sicherlich hitzige Debatten und weitere Vorschläge mit sich bringen. Wenn dieser leistungsorientierte Vorschlag richtig umgesetzt wird, dürfte dies einen wichtigen Beitrag zu einem reibungslosen Ablauf von Leap 5.0 leisten. Die Teilnehmer scheinen ähnlich zu denken und legen den Schwerpunkt auf Qualität statt auf die schnelle Veröffentlichung einer Lösung.