In der vergangenen Woche trafen sich die Node-Betreiber von Vaulta, früher bekannt als EOS, um wichtige Updates zu besprechen. Das Treffen befasste sich mit dem Fortschritt der Antelope Spring 2.0 Software, wie das neue Gossip-System zur Verbindung von Blockproduzenten funktioniert und Ideen zur Erhöhung der Sicherheit von Netzwerkverbindungen. Die Node-Betreiber tauschten ihre Erfahrungen mit technischen Problemen und der Einrichtung ihrer Netzwerke aus, während sie die Vaulta-Blockchain reibungslos am Laufen hielten.
Wichtige Erkenntnisse
-
Die Developer Preview 1 von Antelope Spring 2.0 ist veröffentlicht und konzentriert sich auf Synchronisationsaufrufe, wobei bedeutendere Änderungen in Preview 2 um September erwartet werden.
-
Das neue Ereignissystem wird von Node-Betreibern verlangen, Speichergrenzen festzulegen, wobei weitere Details im Laufe der Entwicklung bekannt gegeben werden.
-
Die Einführung des Gossip-Peering-Systems ist im Gange, aber noch nicht alle großen Blockproduzenten sind verbunden, was bedeutet, dass das Netzwerk noch nicht vollständig vermascht ist.
-
Die Einrichtung des Gossip-Netzwerks war schwierig, mit Problemen bei der Peer-Suche und Vorschlägen, gehostete Listen zu verwenden, um neuen Nodes die Verbindung zu erleichtern.
-
Eine neue Idee ist es, Node-Betreibern zu ermöglichen, Listen von erlaubten oder blockierten Peers für das Gossip-System zu erstellen, um Verbindungen und Sicherheit zu verwalten.
Entwicklungsfortschritt von Antelope Spring 2.0
Die Entwicklung von Antelope Spring 2.0 schreitet voran, wobei die erste Developer Preview (DP1) nun veröffentlicht ist. Diese erste Version bietet Unterstützung für Synchronisationsaufrufe und ermöglicht den Zugriff auf eine Testnet-Umgebung. Entwickler werden gebeten, ihre Verträge mit CDT 5.0 dev 1.1 neu zu erstellen. Derzeit ändert DP1 nicht viel für Node-Betreiber, da größere Auswirkungen mit DP2 erwartet werden. Diese nächste Preview, DP2, ist für Anfang September geplant und wird das neue Ereignissystem zusammen mit Verbesserungen der Ausführungsgeschwindigkeit enthalten.
Vorschau auf das Ereignissystem und Implikationen
Die kommende Developer Preview 2 (DP2) für Antelope Spring 2.0 wird ein neues Ereignissystem einführen. Dieses System wird die Übertragung von kurzlebigen Ereignissen ermöglichen, die kryptografisch innerhalb der Konsensdaten festgeschrieben sind. Für Node-Betreiber bedeutet dies, dass ein neuer Konfigurationsparameter eingeführt wird, der sie dazu verpflichtet, minimale Speichereinstellungen für diese Ereignisse festzulegen. Die genauen Details und Best Practices für die Verwaltung dieser Ereignisse werden noch im Laufe der Entwicklung ausgearbeitet, aber DP2 wird die anfänglichen Node-relevanten Funktionen und Konfigurationen bereitstellen, die für deren Handhabung erforderlich sind. Die Auswirkungen für Node-Betreiber sind erheblich, da sie ihre Konfigurationen an diesen neuen Datenstrom anpassen müssen.
Funktionalität des Ereignissystems
-
Ereignisse sind temporäre Nachrichten.
-
Sie werden durch kryptografische Festschreibungen im Konsens gesichert.
-
Node-Betreiber müssen Speichergrenzen definieren.
Konfigurationsanforderungen für Node-Betreiber
-
Mindestspeicher für kurzlebige Ereignisse festlegen.
-
Ereignisdatenfluss überwachen.
-
An neue Konfigurationsparameter in DP2 anpassen.
Erwartete Auswirkungen des Ereignissystems
-
Neue Datentypen zur Verwaltung.
-
Potenzial für verbesserte Netzwerküberwachung.
-
Bedarf an aktualisierten Betriebsverfahren.
Adoptionsstatus des Gossip BP Peerings
Mehrere führende Blockproduzenten (BPs) haben Schritte unternommen, um ihre Peer-Schlüssel zu registrieren, was ein guter Anfang ist. Wir sehen einige teilweise Peering-Verbindungen, wie zwischen Genereos und Eosphere, was zeigt, dass die grundlegende Konnektivität für einige funktioniert. Dies geschieht jedoch noch nicht im gesamten Netzwerk. Die Adoption ist noch in Arbeit, und mehr Koordination und klare Bestätigungen von BPs würden die Dinge wirklich beschleunigen. Wir haben noch keine kritische Masse an Adoption erreicht, was der Grund sein könnte, warum das Gossip-Netzwerk nicht wie erwartet vollständig vermascht ist.
Technische Herausforderungen bei der Bildung von Gossip-Netzwerken
Ein stabiles Gossip-Netzwerk für Blockproduzenten (BPs) einzurichten, ist nicht so einfach, wie es scheinen mag. Wir stoßen auf einige Hürden. Zunächst einmal ist die Suche nach anderen Peers oft ein Glücksspiel. Dies liegt häufig daran, dass einige BPs ihre Konfigurationen möglicherweise nicht vollständig eingerichtet haben oder dass Firewalls die Verbindungen blockieren. Das bedeutet, dass Nodes sich manchmal einfach nicht sehen können, obwohl sie es sollten.
Im Moment wird vorgeschlagen, Peers manuell hinzuzufügen, um die Verbindungen zu starten. Das funktioniert, ist aber nicht ideal für ein dezentrales System, das seinen eigenen Weg finden soll. Uns fehlt eine Möglichkeit für Nodes, sich automatisch gegenseitig zu entdecken, wie ein „Seed-Peer“-System, das neuen Nodes hilft, bestehende zu finden. Einige Ideen, die im Umlauf sind, beinhalten die Verwendung von gehosteten JSON-Listen von Peers, um bei dieser anfänglichen Einrichtung zu helfen.
Vorgeschlagene Whitelist-/Blacklist-Funktion für Gossip-Verbindungen
Um die Verbindungen innerhalb des Gossip-Netzwerks besser zu verwalten, wird eine Funktion in Betracht gezogen, die Whitelists und Blacklists von Peers ermöglicht. Dies würde Node-Betreibern mehr Kontrolle darüber geben, mit welchen anderen Nodes sie sich verbinden. Die Idee ist, Betreibern zu ermöglichen, bestimmte Blockproduzenten (BP)-Konten festzulegen, die entweder zum Verbinden zugelassen oder nicht zugelassen sind.
Dieses vorgeschlagene System würde neben bestehenden manuellen Peer-Konfigurationen funktionieren. Alle Peers, die Sie manuell zur Konfiguration Ihres Nodes hinzufügen, hätten weiterhin Priorität. Für Peers, die über das Gossip-Protokoll entdeckt werden, würden jedoch die Whitelist- und Blacklist-Regeln gelten.
Das Hauptziel dieser Funktion ist es, eine Möglichkeit zu bieten, Verbindungen mit Nodes zu verhindern, die möglicherweise fehlerhaft sind oder unter einer Art von Angriff stehen. Es wird als eine Möglichkeit angesehen, den Bedarf an komplexen externen Firewall-Regeln für Betreiber zu reduzieren, nur um eingehenden Gossip-Verkehr zu filtern.
Hier ist eine Aufschlüsselung, wie es funktionieren könnte:
-
Whitelist: Eine Liste spezifischer BP-Konten, denen explizit erlaubt ist, sich über Gossip mit Ihrem Node zu verbinden.
-
Blacklist: Eine Liste spezifischer BP-Konten, denen explizit verboten ist, sich über Gossip mit Ihrem Node zu verbinden.
-
Standardverhalten: Wenn weder eine Whitelist noch eine Blacklist konfiguriert ist oder wenn ein Peer auf keiner der Listen steht, würde der Node wahrscheinlich seinem Standardverbindungsverhalten folgen und die Verbindung möglicherweise zulassen.
Bedenken hinsichtlich Peer-Identifikation und Missbrauchsminderung
Herausforderungen bei der Peer-Identifikation
Eine der Hauptsorgen beim Gossip-System ist herauszufinden, wer tatsächlich was sendet. Da Nachrichten von verschiedenen Nodes weitergeleitet werden können, ist es schwierig, den Ursprung von schädlichem Datenverkehr zu ermitteln. Dies erschwert es, Probleme an der Quelle zu stoppen. Wenn Sie einen Node blockieren, der Probleme verursacht, könnte sich das Problem einfach über andere Nodes weiterverbreiten, die Sie noch nicht identifiziert haben. Es fühlt sich ein bisschen an wie Whack-a-Mole spielen, und es gibt keine einfache Möglichkeit, sicher zu wissen, wer der ursprüngliche Absender war.
Strategien zur Missbrauchsminderung
Um damit umzugehen, fordern die Leute bessere Möglichkeiten zur Kontrolle, wer sich verbinden kann und welche Art von Datenverkehr erlaubt ist. Das bedeutet mehr als nur einfaches Blockieren. Wir brauchen Systeme, die die Identität der Peers überprüfen und Regeln sorgfältiger durchsetzen können. Die aktuelle Einrichtung bietet uns diese Art von detaillierter Kontrolle nicht wirklich, was ein großes Hindernis für die Sauberkeit und Sicherheit des Netzwerks darstellt. Es ist klar, dass das Blockieren einzelner Nodes nicht ausreicht, wenn das Netzwerk darauf ausgelegt ist, Informationen so frei weiterzuleiten.
Netzwerkbeschränkungen, die die Machbarkeit von Funktionen beeinflussen
Wenn wir uns ansehen, wie neue Funktionen, insbesondere Dinge wie die vorgeschlagene Whitelist und Blacklist für Gossip-Verbindungen, funktionieren sollen, stoßen wir auf einige reale Netzwerkprobleme. Es ist nicht immer so einfach, wie einen Schalter umzulegen. Zum Beispiel verwenden viele Nodes Proxyserver, um sich zu verbinden. Das ist ziemlich üblich, aber es bedeutet, dass die ursprüngliche IP-Adresse einer Verbindung verborgen wird. Das macht es schwierig, genau zu wissen, woher der Datenverkehr kommt, was ein großes Problem ist, wenn man kontrollieren möchte, wer sich verbinden kann.
Dann gibt es die zugrunde liegende Technologie selbst. Das TCP-Protokoll, das Gossip verwendet, bietet nicht die gleiche Art von feingranularer Kontrolle darüber, wer sich verbindet, wie es beispielsweise HTTP tun könnte. Das bedeutet, dass wir nicht einfach Regeln einrichten können, um bestimmte Verbindungen basierend auf detaillierten Informationen zuzulassen oder zu blockieren. Hinzu kommt, dass bei dynamischen IP-Adressen und all diesen verschiedenen Proxy-Setups der Versuch, eine strikte Whitelist oder Blacklist durchzusetzen, zu einem echten Problem wird. Es fühlt sich an, als würden wir ständig hinterherhinken.
Aufgrund dieser Herausforderungen stellen viele Node-Betreiber fest, dass traditionelle Firewall-Kontrollen immer noch die praktischste und effektivste Methode sind, ihren Netzwerkverkehr zu verwalten. Sie sind daran gewöhnt, und es funktioniert zuverlässig, auch wenn es nicht so integriert ist, wie es eine Gossip-spezifische Funktion sein könnte. Wir müssen überlegen, ob die vorgeschlagenen Funktionen diese bestehenden Netzwerkrealitäten wirklich überwinden können oder ob sie nur zusätzliche Komplexität hinzufügen, ohne die Kernprobleme zu lösen.
Fazit und nächste Schritte
Die Entwicklung von Antelope Spring 2.0, insbesondere die kommende Developer Preview 2 (DP2) und ihr integriertes Ereignissystem, stellt einen wichtigen Bereich für bevorstehende Tests und Rückmeldungen von Node-Betreibern dar. Fortgesetzte Bemühungen zur Förderung und Überwachung der Einführung des Gossip-Protokolls für das Peering von Blockproduzenten (BP) sind ebenfalls wichtig. Die vorgeschlagene Whitelist- und Blacklist-Funktion zur Verwaltung von Gossip-Verbindungen wurde als potenziell nützliches Werkzeug anerkannt, obwohl ihre derzeitigen Einschränkungen bedeuten, dass sie keine vollständige Lösung für die Netzwerksicherheit darstellt. Weitere Forschung und Community-Input werden gesammelt, um die praktische Machbarkeit und Wirksamkeit der Implementierung solcher Funktionen zu bewerten.
Wichtige Schwerpunkte für Betreiber
-
DP2 und das Ereignissystem: Node-Betreiber sollten sich auf das Testen dieser Komponenten vorbereiten, sobald sie verfügbar sind.
-
Gossip-Peering-Adoption: Fortgesetzte Teilnahme und Bestätigung erfolgreichen Peerings werden gefördert, um ein robusteres Gossip-Netzwerk aufzubauen.
-
Feedback zu Sicherheitsfunktionen: Die Bereitstellung von Input zum vorgeschlagenen Whitelist-/Blacklist-Mechanismus und anderen Sicherheitsbedenken wird dazu beitragen, zukünftige Entwicklungen zu gestalten.
Zukünftige Überlegungen
-
Robustheit des Gossip-Netzwerks: Die Bewältigung von Herausforderungen bei der Peer-Erkennung und Verbindungsstabilität bleibt eine Priorität.
-
Identität und Missbrauch: Die Entwicklung effektiverer Methoden zur Identifizierung und Minderung von Missbrauch innerhalb des Gossip-Netzwerks erfordert weitere Untersuchungen.
-
Netzwerkrealitäten: Praktische Einschränkungen im Zusammenhang mit IP-Maskierung und bestehender Netzwerkinfrastruktur müssen bei der Gestaltung neuer Funktionen sorgfältig berücksichtigt werden.
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.