Das jüngste Vaulta (ehemals EOS) Node Operator Meeting brachte die Teilnehmer zusammen, um die neuesten Entwicklungen in der Antelope-Software zu besprechen. Das Gespräch umfasste eine dringende Patch-Veröffentlichung für Version 1.2.2, den fortlaufenden Fortschritt des mit Spannung erwarteten Spring 2.0 und eine lebhafte Debatte darüber, wie Nodes sich im Netzwerk finden. Es war eine arbeitsreiche Sitzung, die sich darauf konzentrierte, das System stabiler und einfacher zu verwalten.
Wichtige Erkenntnisse
-
Ein dringender Patch für Antelope Spring 1.2.2 wird Node-Betreibern empfohlen, um ein seltenes Problem zu beheben, das die Blockproduktion stoppen könnte. Dieses Update enthält auch kleinere Netzwerkverbesserungen.
-
Die Entwicklung von Antelope Spring 2.0 schreitet voran, wobei Developer Preview 2 bald erwartet wird, die eine neue Funktion namens „Events“ einführt. Ein separates Testnetz ist für diese Veröffentlichung geplant.
-
Developer Preview 3 ist auf dem Weg und wird die letzte Gelegenheit sein, wesentliche Änderungen an Schnittstellen vor der endgültigen Veröffentlichung von Spring 2.0 vorzunehmen, wobei der Fokus auf Stabilität liegt.
-
Es gibt eine fortlaufende Diskussion darüber, wie Nodes sich verbinden, da die aktuellen Methoden viele Betreiber nicht verbinden. Ideen wie der Start mit einer kleinen Gruppe zuverlässiger „Hub“-Nodes werden in Betracht gezogen.
-
Node-Betreiber fordern einfachere Wege, andere Nodes zu finden, und schlagen Tools wie das Abrufen von Peer-Listen von einer URL oder die Verwendung einfacher JSON-Dateien vor.
Antelope Spring 1.2.2 Patch-Veröffentlichung dringend empfohlen
Das Antelope-Entwicklungsteam hat Node-Betreiber dazu aufgerufen, ihre Systeme auf die Patch-Veröffentlichung 1.2.2 der Spring-Version zu aktualisieren. Dieses Update ist wichtig, da es ein seltenes Problem behebt, das die Blockproduktion stoppen könnte. Es enthält auch einige kleine Verbesserungen, wie Nodes miteinander kommunizieren, und behebt einige andere Fehler. Es liegt wirklich im besten Interesse der Netzwerkstabilität, dass jeder diesen Patch so schnell wie möglich installiert.
Fortschritt der Antelope Spring 2.0 Entwicklung
Die Entwicklung von Antelope Spring 2.0 schreitet voran, wobei das Team an mehreren Schlüsselmerkmalen arbeitet. Developer Preview 2 soll bald veröffentlicht werden, voraussichtlich Ende September oder Anfang Oktober. Diese Vorschau wird eine neue Datenklasse namens „Events“ einführen, die voraussichtlich die Art und Weise ändern wird, wie bestimmte Informationen innerhalb des Netzwerks gehandhabt werden. Zur Unterstützung dieser Veröffentlichung wird ein separates, temporäres Testnetz eingerichtet, das sich vom bestehenden Jungle-Testnetz unterscheidet. Dies ermöglicht gezielte Tests der neuen Funktionen, bevor sie breiter integriert werden. Das Team plant auch Developer Preview 3, die darauf abzielen wird, die in Preview 2 eingeführten Funktionen zu verfeinern und etwaige Kompromisse zu beheben. Diese dritte Vorschau soll die letzte Gelegenheit sein, wesentliche Änderungen an Schnittstellen vorzunehmen, wobei der Fokus darauf liegt, Synchronisationsaufrufe und die neue Event-Funktionalität robuster zu gestalten.
Developer Preview 3 am Horizont
Das Team bereitet sich auf Developer Preview 3 vor, die die letzte Gelegenheit für wesentliche Änderungen an der Schnittstelle vor der vollständigen Veröffentlichung von Antelope Spring 2.0 sein wird. Diese kommende Vorschau zielt darauf ab, Probleme zu bereinigen und Kompromisse zu beheben, die während der Entwicklung von Preview 2 eingegangen wurden. Ein Hauptaugenmerk wird darauf liegen, die Synchronisationsaufrufe robuster zu gestalten und die zuvor eingeführte Event-Funktionalität zu verfeinern.
Wichtige Arbeitsbereiche für Developer Preview 3 umfassen:
-
Verbesserung der Stabilität und Zuverlässigkeit des Node-Synchronisationsprozesses.
-
Weitere Entwicklung und Tests der neuen Datenklasse „Events“.
-
Behebung aller ausstehenden Fehler oder Leistungsengpässe, die in früheren Vorschauen identifiziert wurden.
-
Sicherstellung eines reibungsloseren Übergangs für Node-Betreiber, die auf die neue Version aktualisieren.
Debatte über Gossip-Peering und Netzwerkerkennung
Die Diskussion darüber, wie Nodes sich im Antelope-Netzwerk finden, oft als Peer-Discovery bezeichnet, war ein heißes Thema. Im Moment scheint es, als ob nicht jeder mit so vielen anderen Nodes verbunden ist, wie es möglich wäre. Dies hat zu vielen Gesprächen über die aktuelle Methode geführt, die auf einem System namens „Gossip-Peering“ basiert. Im Wesentlichen teilen Nodes Informationen über andere Nodes, die sie kennen. Die Wirksamkeit dieses Systems scheint jedoch ein Streitpunkt zu sein.
Mehrere Ideen wurden vorgebracht, um die Situation zu verbessern. Ein Vorschlag war, neue Nodes mit einer kleinen, zuverlässigen Gruppe von „Hub“-Nodes zu starten. Dies würde ihnen eine solide Basis für den Verbindungsaufbau geben. Ein weiterer diskutierter Aspekt war das Gleichgewicht zwischen dem manuellen Einrichten von Verbindungen zu bestimmten Peers und dem automatischen Finden durch das Gossip-System. Das Kernproblem scheint darin zu bestehen, eine robuste und weit verbreitete Konnektivität sicherzustellen, ohne es für Node-Betreiber übermäßig kompliziert zu machen.
Dies führte natürlich zu Forderungen nach einfacheren Wegen, Peers zu finden. Viele Betreiber äußerten den Wunsch nach Tools, die Peer-Listen von einer URL oder einer Datei abrufen könnten. Die Idee, Listen von anfänglichen Verbindungspunkten zu veröffentlichen, vielleicht im JSON-Format, gewinnt an Unterstützung. Es wurde auch erwähnt, Möglichkeiten hinzuzufügen, um zu überprüfen, ob diese Listen legitim sind, nur zur zusätzlichen Sicherheit.
Forderungen nach vereinfachten Peer-Discovery-Tools
Viele Node-Betreiber haben den Wunsch geäußert, einfachere Wege zu finden, um andere Nodes im Netzwerk zu finden und sich mit ihnen zu verbinden. Die aktuellen Methoden können etwas aufwendig sein, und es gibt Bestrebungen, diesen Prozess zu vereinfachen. Ein häufiger Vorschlag ist, den Betreibern zu ermöglichen, eine URL oder einen Dateipfad anzugeben, von dem der Node eine Liste von Peers zum Verbinden abrufen kann. Dies würde die Notwendigkeit beseitigen, jeden Peer manuell zu konfigurieren. Eine weitere Idee, die Unterstützung findet, beinhaltet die Veröffentlichung von Seed-Node-Listen im JSON-Format. Dieser strukturierte Ansatz könnte es Nodes erleichtern, ihre Verbindungen zu bootstrappen. Es wird auch darüber gesprochen, optionale Möglichkeiten hinzuzufügen, um zu überprüfen, ob diese Peer-Listen vertrauenswürdig sind, was eine Sicherheitsebene zum Erkennungsprozess hinzufügt.
Langfristige Verbesserungen in Betracht gezogen
Über die unmittelbaren Korrekturen und bevorstehenden Veröffentlichungen hinaus sucht das Team nach Wegen, das Netzwerk im Laufe der Zeit robuster und einfacher zu verwalten. Eine Idee, die diskutiert wird, beinhaltet die Schaffung von leichtgewichtigen Relay-Nodes. Diese Nodes, die möglicherweise mit etwas wie Wharfkit erstellt werden, könnten helfen, Informationen effizienter im Netzwerk zu verbreiten.
Es wird auch darüber gesprochen, das Gossip-System intelligenter zu machen. Dies könnte bedeuten, die Art und Weise zu erweitern, wie Nodes Informationen teilen, und Wege zu finden, Verbindungen automatisch zu verwalten, sodass Betreiber nicht so viel manuelle Einrichtung vornehmen müssen.
Zusätzlich plant die Gruppe, einige Funktionen, die zuvor vorgeschlagen, aber nie wirklich in den Code aufgenommen wurden, erneut zu prüfen. Diese älteren Ideen könnten Lösungen für einige der aktuellen Herausforderungen bei der Art und Weise bieten, wie Nodes sich finden.
Zusammenfassung des Meetings und nächste Schritte
Die Diskussionen endeten mit einer klaren Reihe von Maßnahmen und Bereichen für den weiteren Fokus. Node-Betreiber werden dringend ermutigt, die bevorstehende Developer Preview 2 von Antelope Spring zu testen, sobald sie verfügbar ist. Diese praktische Erfahrung ist entscheidend für das Sammeln von Feedback, insbesondere hinsichtlich der Auswirkungen der neuen Datenklasse „Events“. Das Team sucht eine breite Beteiligung, um zu beurteilen, wie diese Events in realen Szenarien funktionieren werden.
Aus den Gesprächen des Tages ergaben sich mehrere wichtige Punkte:
-
Das Interesse der Community an einfacheren Peer-Discovery-Methoden, wie der „Poor Man’s Discovery“ mittels Seed-Listen, wurde bekräftigt. Dieser Ansatz, der das Abrufen von Peer-Listen von einer URL oder Datei beinhaltet, wurde als praktischer Schritt nach vorn angesehen.
-
Eine weitere Untersuchung von leichtgewichtigen Relay-Nodes, möglicherweise unter Verwendung von Tools wie Wharfkit, wurde als Weg zur Verbesserung der Netzwerkverbreitung und zur Erleichterung des Verbindungsprozesses für Betreiber vereinbart.
-
Das Team wird zuvor vorgeschlagene, aber nicht zusammengeführte Funktionen, die darauf abzielen, die gesamten Netzwerkerkennungsmechanismen zu verbessern, erneut prüfen.
Diese nächsten Schritte zielen darauf ab, die unmittelbaren Bedürfnisse nach Stabilität und Benutzerfreundlichkeit zu erfüllen und gleichzeitig die Grundlage für robustere langfristige Lösungen im Netzwerkmanagement zu legen.
Dieser Artikel wurde mit Unterstützung KI-gestützter Technologie erstellt und basiert auf mehreren renommierten Quellen. Der endgültige Inhalt wurde von der Redaktion von BlockzHub sorgfältig geprüft und bearbeitet, um Genauigkeit, Klarheit und Kohärenz sicherzustellen. Originalquellen werden, sofern erforderlich und angemessen, entsprechend gewürdigt. Die in diesem Artikel geäußerten Meinungen spiegeln nicht notwendigerweise die offiziellen Ansichten oder Positionen von BlockzHub wider. Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Fachberatung dar. Investitionen bergen Risiken, und Sie sollten vor Anlageentscheidungen einen qualifizierten Finanzberater konsultieren.