Autor: Marco González

Redakteur: Randall Roland
Übersetzer: 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.

Die Diskussion über spezielle Knoten wurde erneut vertagt. Stattdessen gaben die Kernentwickler von Antelope am 05. bzw. 12. April einen Einblick in die Leap-Generationen 4.0 und 5.0. Die Kernentwickler versuchten, die Community zu informieren und Feedback einzuholen.

In dieser Woche begrüßte die Gruppe die ENF-Kernentwickler, um Einblicke und Demos von v4.0.0 zu geben. Brian Hazzard lieferte Notizen, die auch auf EOS Nation GitHub für April 05 verfügbar sind. Du kannst dir das komplette Treffen auf dem YouTube-Kanal der ENF ansehen.

Antelope v4.0.0 wird die Dominanz von EOS in Bezug auf Leistung, Skalierbarkeit und Zuverlässigkeit im Vergleich zu anderen Blockchains weiter ausbauen. Zu den identifizierten Funktionen (aus Brians Notizen) gehören:

Spezifische Erkenntnisse (aus Brians Notizen):

Nach Brians Überblick folgte eine Präsentation von Lin Huang. Auf dem Weg zu Nur-Lese-Transaktionen (und Aufgaben) diskutierte Lin:

Lin führte eine < /cleos push transaction > Demonstration und read-only-Transaktionen durch. Die wichtigsten Merkmale von parallelisierten read-only-Transaktionen (und Aufgaben) sind:

Zu den von Vlad vorgestellten Schlüsselelementen für Snapshot-Scheduling gehören:

Er bezeichnete wiederkehrende Snapshots als "die interessanteste" Funktion. Snapshots werden alle 20 Blöcke aufgefüllt und laufen weiter, bis sie beendet werden. Ungeplante Snapshots können mit einer ID erstellt werden.

Vlad erwähnte auch, dass ein neues Tool (leap-util) derzeit neue Funktionen hinzufügt und eine aktualisierte /cleos-Unterstützung haben wird.

Peter Oschwald erläuterte ausführlich die Funktionsweise von Performance Harness mit einem Kommandozeilenbeispiel und einem Bericht. Ursprünglich sollte damit eine bessere Möglichkeit geschaffen werden, Leistungskennzahlen für verschiedene Betriebsknoten zu ermitteln. So konnten die Entwickler sehen, wie sich ihre Verbesserungen auf die Leistung im gesamten Ökosystem auswirken.

Peter führte durch drei verschiedene Schichten des Performance Harness: einfach, grundlegend und fortgeschritten. Je fortgeschrittener die Schicht ist, desto mehr Parameter sind zulässig. Weitere Informationen über die Testumgebung und typische Konfigurationen findest du in der Pefromance_tests README-Datei [siehe 31:12 des Videos].

Peter beschreibt weiter den Transaktionsgenerator, einen Ersatz für das zugehörige Plugin, und die Handhabung großer TPS. Nachdem er auf weitere Funktionen eingegangen ist, weist er auf Pläne hin, die Leistungsmetriken weiter auszubauen. Zum Beispiel soll gemessen werden, ob sich die Leistung von Nodeos verbessert oder verschlechtert.

Kevin Heifner gab einen kurzen Überblick über mehrere Themen, bevor er die Sitzung beendete. Anhand von Brians Notizen gab Kevin einen Überblick über vier große Verbesserungsbereiche und ihre Unterthemen:

Kevin testete dann, wie das Auto-Peering derzeit funktioniert. Das Beispiel ging auf die Konnektivität in Bezug auf die BP-Planung ein.

Als nächstes gab er einige Hinweise zum Prometheus-Exporter-Plugin:

Zum Abschluss der Sitzung wurde erwähnt, dass Nodeos Zugriff auf das (Retain-)Verzeichnis hat, nicht aber auf die Archive. Die State History verhält sich genauso.

Kevin schloss mit Mikro-Optimierungen, bei denen Blöcke nach einer Header-Validierung propagiert werden und nicht auf dem Haupt-Thread stattfinden müssen. Neben einer 4-fachen Verbesserung von get_block erwartet er, dass das Propagieren von Blöcken in einer 4.0-Umgebung viel schneller sein wird. Er beschreibt, wie "how it's faster period" und mehr als die Hälfte des Prozesses (time) vom Haupt-Thread verlagert wurde.

EOS ist die schnellste Blockchain, die es gibt. Antelope's Entwicklung von v4.0.0 wird EOS wesentlich schneller, effizienter und entwicklerfreundlicher machen.

Die Kernentwickler von Antelope stellten ihre Vision einer 5.0-Umgebung vor und baten um Feedback. Es wurden Vergleiche zu bestehenden Operationen, einer 4.0-Umgebung und der Vision von 5.0 angestellt. Du findest die Notizen zum Runden Tisch vom 12. April auf EOS Nation GitHub und das Video auf YT der ENF.

Neue Funktionen, die mit v4.0.0-rc3 kommen, sind in dem angegebenen Link detailliert beschrieben.

Zweiwöchentlich stattfindende Entwicklersprechstunden bieten weitere Unterstützung für diejenigen, die an Roundtable-Treffen teilnehmen. Stephen Diesel wird die Treffen leiten. Das erste Treffen wird am 20. April stattfinden und danach jeden zweiten Donnerstag. Du kannst Stephen auf Telegram erreichen, um mehr über CDT und andere entwicklerbezogene Themen zu erfahren (z.B. DUNE, Pain Points und die neuen Antler Pods).

In Anbetracht der Tatsache, dass ein 5.0-Konsens-Upgrade noch Monate entfernt ist (möglicherweise im frühen Herbst), war das Treffen weniger strukturiert als sonst. Zu den wichtigsten Themen gehören:

4.0 wird das Prometheus-Plugin einführen. In der kurzen Zeit, in der es getestet wurde, haben Mitglieder der Community darum gebeten, das Plugin auf einem separaten, konfigurierbaren Port laufen zu lassen. Dies scheint nun ein Hauptziel für 5.0 zu sein.

Prometheus auf einem separaten Endpunkt inspirierte andere Endpunktkonfigurationen. Einige der vorgeschlagenen Endpunktkategorien sind:

Kategorien werden nicht für jeden Endpunkt konfigurierbar sein. Stattdessen werden die Endpunkte so gruppiert, wie es Sinn macht. Es wird auch eine Einheitlichkeit zwischen den Kategorien geben. Standardmäßig werden alle Endpunkte in einer Kategorie sein, so dass das System so laufen kann, wie es immer gelaufen ist.

Gemeinsam wurde ein Vorschlag mit dem Titel “custom port/io configurations”." erarbeitet.

Eine weitere Priorität für 5.0 ist die Einführung von IPv6.

Die Idee der effizienten Endpunktkategorien schien gut anzukommen. Einige der ersten Rückmeldungen und Antworten waren

So wie es heute aussieht, wird get_info generell öffentlich gemacht. In Peer-Umgebungen (z.B. Producer Nodes) besteht jedoch die Notwendigkeit, get_info nicht öffentlich zu machen.

Beachte, dass es starke Standpunkte über die Beibehaltung von get_info auf allen Endpunkten gibt.

Der runde Tisch begann mit einer Diskussion über eine Art Aufholmodus und einen konfigurierbaren Schwellenwert zu enden.

Brian schloss das Treffen, indem er die Community nach einer Traumumgebung für 5.0 fragte. Er machte Vorschläge für Bereiche, auf die sich die Vorschläge konzentrieren sollten, betonte aber, dass das Feedback praktisch uneingeschränkt sein sollte:

Das EOS-Netzwerk ist jetzt über EOS EVM mit Ethereum verbunden. 4.0 (kein erwartetes Konsens-Upgrade) und 5.0 (geplantes Konsens-Upgrade) machen zuversichtlich Fortschritte. Beide Versionen verbessern die Geschwindigkeit und Funktionalität. EOS hat sich im Bereich der Blockchains bereits gut geschlagen. Jetzt ist es an der Zeit, Träume zu verwirklichen.