Am 12. März 2025 brachte das EOS Node Operator Meeting wichtige Akteure der EOS-Community zusammen, um über aktuelle Entwicklungen und Herausforderungen zu diskutieren. Der Schwerpunkt lag hauptsächlich auf der Einführung der EOS-Systemverträge Version 3.8.0 und den anhaltenden Problemen mit der Netzwerkleistung, insbesondere in Testnetzen. Die Teilnehmer teilten Erkenntnisse darüber, wie die Konnektivität verbessert und das Peer-to-Peer-Netzwerk optimiert werden kann, während sie auch die einzigartigen Herausforderungen ansprachen, die durch schnelle Blockzeiten entstehen. Dieses Treffen war ein Schritt zur Verfeinerung des EOS-Ökosystems und zur Sicherstellung seiner robusten Leistung in der Zukunft.
Wichtige Erkenntnisse
-
Die Bereitstellung der EOS-Systemverträge v3.8.0 wurde erfolgreich genehmigt, mit allen erforderlichen Unterschriften.
-
Wichtige Updates in v3.8.0 umfassen die Einführung von 'Geschenk-RAM' und reservierten Kontonamens-Strings.
-
In Testnetzen gibt es Verzögerungen bei der Stimmenverbreitung, was Diskussionen über mögliche Lösungen anregt.
-
Ein neues gossip-basiertes Peering-System wird entwickelt, um die Effizienz des Peer-to-Peer-Netzwerks zu verbessern.
-
Die schnellen Blockzeiten schaffen Herausforderungen für die Stimmenverbreitung, was die Notwendigkeit einer besseren Koordination unter den Knoten hervorhebt.
Bereitstellung der EOS-Systemverträge v3.8.0
Genehmigung und Ausführung von MSIG
Gute Nachrichten an der Front der Systemverträge! Die MSIG, die zur Bereitstellung der Systemverträge v3.8.0 erforderlich war, erhielt das Okay. Sie erhielt tatsächlich alle 15 erforderlichen Unterschriften, noch bevor das Treffen begann. Das ist ziemlich effizient.
Zusammenfassung der Änderungen in v3.8.0
Was ist also neu in v3.8.0? Hier ist die Zusammenfassung:
-
Es wurden einige Probleme mit Ricardian-Klauseln behoben. Ich bin kein Entwickler, aber ich höre, das ist eine gute Sache.
-
Sie haben "Geschenk-RAM" hinzugefügt. Damit können Sie RAM an jemand anderen geben, aber sie können es nicht übertragen oder weiterverkaufen. Interessant.
-
Sie haben String-Reservierungen für Kontonamen eingeführt. Dies soll Marken schützen, damit jemand nicht einfach einen Namen schnappen kann, der bereits in Gebrauch ist.
Nächste Schritte
Halten Sie am 18. März Ausschau. An diesem Tag wird der gehashte Vektor der reservierten Strings bekannt gegeben. Dies wird verhindern, dass Leute neue Konten mit diesen reservierten Strings erstellen. Es geht darum, die Dinge ordentlich zu halten und Namenssquatting zu verhindern, schätze ich.
Testnet-Upgrades und Konnektivitätsprobleme
Probleme mit der Blockverbreitung in Testnetzen
Nach dem Upgrade auf Version 1.1.1 bemerkten einige der Blockproduzenten, dass Stimmen nicht so schnell verbreitet wurden, wie sie sollten. Dies war besonders auffällig in den Jungle- und Kyland-Testnetzen. Es ist, als ob einige Knoten Schwierigkeiten hatten, die neuesten Blöcke zu verbreiten. Sie haben die Peering-Einstellungen angepasst, und das schien die Dinge ein wenig zu verbessern.
Mögliche Ursachen für Verzögerungen bei der Stimmenverbreitung
Warum waren die Stimmen langsam? Nun, es könnten einige Dinge im Gange sein. Das Upgrade selbst, von 1.1.0 auf 1.1.1, könnte die Art und Weise, wie Verbindungen gehandhabt werden, durcheinandergebracht haben. Es gab einige Änderungen an der "Handhabung doppelter Verbindungen", und vielleicht hat das seltsames Verhalten eingeführt. Außerdem gibt es dieses "Block MAC"-Feature, das in 1.1.0 hinzugefügt wurde. Es könnte Verbindungen filtern oder blockieren, wenn es das nicht sollte.
Fehlerbehebung & Vorgeschlagene Lösungen
Hier ist, was sie versucht haben: Deaktivierung des Block MAC. Und wissen Sie was? Es schien das Problem zu beheben! Aber natürlich müssen sie mehr Tests durchführen, um sicherzustellen, dass das wirklich die Lösung ist. Hier ist eine Liste von Dingen, die sie in Betracht ziehen:
-
Weitere Tests in verschiedenen Testnetzen.
-
Analyse des Netzwerkverkehrs mit und ohne Block MAC.
-
Überprüfung der CPU- und Speicherauslastung während der Stimmenverbreitung.
-
Überprüfung der Codeänderungen im Zusammenhang mit der Handhabung von Verbindungen.
Es geht darum, genau herauszufinden, was die Verzögerungen verursacht und sicherzustellen, dass die Lösung nichts anderes kaputt macht.
Optimierung des Peer-to-Peer-Netzwerks
Wichtigkeit der koordinierten Peering
Derzeit verlässt sich das EOS-Netzwerk darauf, dass Blockproduzenten (BPs) effizient miteinander kommunizieren. Es ist ein globales Netzwerk, daher ist es super wichtig, Informationen schnell zu verbreiten. Die aktuelle Einrichtung erfordert, dass BPs viel koordinieren, um sicherzustellen, dass Blöcke schnell verbreitet werden. Denken Sie daran:
-
Jeder muss wissen, mit wem er sprechen soll.
-
Diese Verbindungen müssen zuverlässig sein.
-
Wenn etwas schiefgeht, kann das alles verlangsamen.
Vorgeschlagene Verbesserungen: Gossip-basiertes Peering
Das Team untersucht eine neue Möglichkeit, die Verbindungen zwischen BPs zu handhaben. Es heißt "gossip-basiertes Peering". Die Idee ist, einen Teil des Verbindungsprozesses zu automatisieren. So könnte es funktionieren:
-
BPs würden automatisch Peers mithilfe eines Gossip-Protokolls finden.
-
Nachrichten würden signiert, um sicherzustellen, dass sie legitim sind.
-
Nur die besten BPs würden Verbindungsinformationen teilen, um die Sicherheit und Effizienz zu gewährleisten.
Konsens- und Netzwerkleistungsdiskussionen
Schnelle Blockzeiten schaffen einzigartige Herausforderungen
Die schnellen Blockzeiten von EOS, die nur eine halbe Sekunde betragen, bedeuten, dass Stimmen super schnell verbreitet werden müssen. Einige Knoten sehen Rundlaufzeiten von bis zu 500 ms, was es schwierig macht, Stimmen rechtzeitig abzugeben. Dies schafft einige interessante Probleme für das Netzwerk. Es ist, als würde man versuchen, ein Rennen zu gewinnen, während man bereits die Ziellinie überschreitet.
Bedarf an zentraler Koordination in einem dezentralen Netzwerk
Es mag seltsam erscheinen, aber selbst in einem dezentralen Setup benötigt man immer noch eine gewisse zentrale Koordination, insbesondere wenn es darum geht, wer mit wem im Netzwerk spricht. Einige Leute denken, dass Blockproduzenten (BPs) sich nicht nur auf Software verlassen sollten, um die Netzwerkoptimierung zu handhaben. Es wurde erwähnt, dass:
-
Manuelle Koordination immer noch wichtig ist.
-
Softwareautomatisierung keine vollständige Lösung ist.
-
Die Skalierung von Finalizern könnte helfen, die Resilienz zu verbessern.
Fazit
Zusammenfassend lässt sich sagen, dass das EOS Node Operator Meeting am 12. März 2025 bedeutende Fortschritte und anhaltende Herausforderungen innerhalb des EOS-Ökosystems hervorgehoben hat. Die erfolgreiche Einführung der Systemverträge v3.8.0, einschließlich Funktionen wie "Geschenk-RAM" und Kontonamenschutz, stellt einen Fortschritt für die Community dar. Allerdings zeigen die Probleme mit der Stimmenverbreitung in Testnetzen nach dem jüngsten Upgrade, dass noch Arbeit zu leisten ist. Die Diskussionen über die Optimierung der Peer-to-Peer-Verbindungen und die Notwendigkeit einer besseren Koordination unter den Blockproduzenten spiegeln die Komplexität wider, ein leistungsstarkes Netzwerk aufrechtzuerhalten. Während die EOS-Community weiterhin diese Herausforderungen angeht, bleibt das Gleichgewicht zwischen Dezentralisierung und effektiver Netzwerkverwaltung ein zentrales Anliegen.
Dieser Artikel wurde mit Hilfe von KI verfasst, um Informationen aus mehreren seriösen Quellen zu sammeln. Der Inhalt wurde von unserem Redaktionsteam überprüft und bearbeitet, um Genauigkeit und Kohärenz sicherzustellen. Die geäußerten Meinungen stammen von der KI und spiegeln nicht unbedingt die Ansichten von BlockzHub wider. Originalquellen werden immer dann angegeben, wenn es angebracht ist und wie es erforderlich ist. Dieser Artikel dient nur zu Informationszwecken und stellt keine finanzielle Beratung dar. Investieren birgt Risiken, und Sie sollten einen qualifizierten Finanzberater konsultieren, bevor Sie Investitionsentscheidungen treffen.