Die Veröffentlichung von Leap 3.2 wurde in dieser Gesprächsrunde bekanntgegeben. Darüber hinaus wurde das grundlegende Problem der State Database - ihr astronomisch hoher RAM-Verbrauch - diskutiert. Mögliche lang- und kurzfristige Lösungen sowie Kompromisse wurden erörtert.

Zum Abschluss des Treffens gab die ENF eine kurze Zusammenfassung der spezifischen NET-Plugin-Verbesserungen und legte den Zeitplan für den nächsten Runden Tisch fest: Statistische Daten zur Black Box nodEOS aus dem Leap 4.0 Prometheus Exporter. Diesmal nahmen 13 Personen an dem runden Tisch teil.

Die Softwareentwicklung ist das Hauptthema der wöchentlichen EOS Node Operator Round Table Sitzungen. Entwickler, Blockproduzenten, Blockchain-Ingenieure und Community-Mitglieder, die mehr über den EOS-Entwicklungsprozess erfahren möchten, profitieren alle von dem Wissen, das hier vermittelt wird.

Ein Ökosystem kann durch häufigen Austausch und Interaktion gesund und natürlich wachsen. Die EOS Network Foundation hat von BPs und Entwicklern positive Kommentare zu ihren Fortschritten erhalten. Die EOS-Gemeinschaft ist sich der Tatsache bewusst, dass ihre Stimme nun geschätzt und gehört wird. Und nicht zuletzt wird auf die Bedenken der Gemeinschaft reagiert.

Klicke hier für die Videoaufzeichnung des Treffens (Passcode: 1Gx@h=9e)

Zusammenfassung der Antelope Leap Updates auf dem Weg von Stephen Diesel (ENF, Produktmanager von Leap)

UPDATES	VERÖFFENTLICHUNG
Leap 3.2 finale Veröffentlichung	Auf Github veröffentlicht
System Contract Updates	unterwegs
Veröffentlichung von DUNE	Dezember 2022

Zu Beginn des Treffens gab Stephen Diesel bekannt, dass Leap 3.2 auf Github veröffentlicht wurde, es sich aber nicht um ein Konsens-Upgrade handelt und daher optional ist.

Brian Hazzard erklärt sich bereit, für Fragen bezüglich Upgrades in verschiedenen Kanälen zur Verfügung zu stehen. Nächste Woche wird es ein Update des Net Plugin Enhancements Dokuments geben, da beim letzten Treffen großartige Ideen gesammelt und einige neue potentielle Funktionen für den Backlog definiert wurden.

"Trimming der State Database" neu definiert: Zu viel RAM für die Speicherung der State History benötigt

Michael von EOSUSA konnte nicht am Treffen teilnehmen, aber er hatte das Thema für dieses Treffen vorgeschlagen: Trimmen der State Database. Die Teilnehmer des Meetings waren sich allerdings einig, dass das eigentliche Problem darin besteht, dass zu viel Arbeitsspeicher verwendet wird. Laut Stephen wird eine RFP (Request for Proposal) zur Untersuchung des RAM-Problems gerade ausgearbeitet.

Abwägung zwischen Leistung und RAM-Größe.

Die Hauptfrage wurde von Kevin Heifner gestellt: "Wie viel Leistung seid ihr bereit, gegen die Lösung des RAM Problems einzutauschen? Seid ihr bereit, einen Blockproduktionszyklus für das Laden von Daten in den Arbeitsspeicher (wie einen Aufwärm-Block) auszusetzen?" Diese Lösung würde allerdings ein gewisses Spam-Risiko in sich bergen.

Es gibt einfach eine riesige Nachfrage nach Arbeitsspeicher, die nie gedeckt zu sein scheint. Im Moment werden 128 GB RAM benötigt, um die WAX-State Database problemlos zu betreiben. Das Problem ist, dass normale Geräte nicht genug Platz für mehr RAM haben. Es ist schwer, Geräte mit starken CPUs und viel Platz für RAM zu finden. Vielleicht könnten Geräte für Grafikdesigner/Animatoren die zukünftigen Anforderungen erfüllen.

Definition von kurz- und langfristigen Lösungen (zitiert)

Kurzfristige Möglichkeiten

Die Antelope-Koalition arbeitet ein RFP aus, um das RAM Problem zu untersuchen.
Schnelleres Starten und Herunterfahren des Heap-Modes
Gibt es eine Möglichkeit, das tmpfs zu optimieren?
Die Deaktivierung von queries (Kontoabfragen) kann RAM einsparen (Möglichkeit der Konfiguration durch den Knotenbetreiber, bereits möglich)
Speichern von queries auf der Festplatte (vielleicht 4 GB für ca. 14 Mio. Konten auf WAX an Arbeitsspeicher sparen, wahrscheinlich lohnt sich das nicht)

Langfristige Möglichkeiten

Können Smart Contracts dazu inzentiviert werden RAM vs. Festplattenspeicher zu spezifizieren?
Hardware-Hersteller sollten anfangen, sehr schnelle CPU-Kerne mit großen Mengen an RAM anzubieten

P2P-Verbesserungen (Net Plugin) (von Brain Hazzard)

Nachdem der Host, Daniel Keyes, kurz angefragt hatte, ob Brian Hazzard eine kurze Zusammenfassung der spezifischen Vorschläge zur Verbesserung des Net Plugin geben könnte, die kürzlich intern diskutiert wurden, ging dieser kurz auf folgende Verbesserungen ein und bot an, diese in der nächsten Sitzung ausführlicher darzustellen:

Es gäbe die Möglichkeit, die Validierungen, die für Blöcke auf Relay erfolgen, zu erleichtern. Dies könnte Zeit sparen und das Relay schneller machen.
Es wäre möglich, zu kodifizieren, dass, wenn ein Block voll ist (in Bezug auf die angehäufte CPU-Zeit), die Übertragung und der Start des nächsten Blocks erfolgt.
Automatische Konfiguration von Peers zur Optimierung der Latenzzeit (BPs tun dies derzeit manuell).
- Optimierung für den Zeitplan (welcher BP kommt vorher, welcher nachher?)
- Optimierung im Hinblick auf die Latenzzeit

Agenda für das nächste Meeting

Eine Debatte darüber, welche Daten im nächsten Leap 4.0 in den Prometheus-Exporter aufgenommen werden sollten, vorgeschlagen von Matthew von EOS Nation:

nodeEOS ist wie eine Black Box, viele Knotenbetreiber haben wenig Ahnung davon, was darin passiert. Es gibt eine Anfrage, einige Statistiken darüber bereitzustellen.
Die Teilnehmer des Node Operator-Treffens werden ermutigt, ihre Wunschliste für Prometheus zum nächsten Treffen mitzubringen.

Teilnehmer (13) des runden Tisches:
- Randall Roland | EOSsupport.io
- Dario | EOSsupport.io
- Kevin Heifner | OCI
- Matt Witherspoon | ENF
- Brian Hazzard
- Jannis - Rakeden (Jannis)
- Max Cho | KOREOS
- Daniel Keyes | EOS Nation
- Stephen Diesel | ENF
- Matthew Darwin | EOS Nation
- Corvin Meyer auf der Heide | liquiid.io
- Patrick Burns | Aloha EOS
- Ross Dold | EOSphere
Quellen & Referenzen
- Videoaufzeichnung des Meetings (Passcode: 1Gx@h=9e)
- EOS Node Operator Round Table Mitschrift von Daniel Keyes
- Bildnachweis:
  - Banner by EOS Support Graphics