Das letzte Vaulta ($EOS $A) Node Operator Meeting am 11. Juni 2025 behandelte einige große bevorstehende Änderungen. Wir sprachen über einen neuen Multi-Signatur (MSIG)-Plan für Systemverträge, eine vollständige Überarbeitung der Funktionsweise von Staking und Belohnungen und wie wir BPay-Ansprüche bearbeiten werden. Es gab auch viel Diskussion über das Testen des neuen Antelope Spring v1.2 RC3 im Jungle-Netzwerk. Es klingt, als ob sich die Dinge schnell bewegen und sich alle auf diese Updates vorbereiten.
Wichtige Erkenntnisse
-
Ein großes Vaulta-Systemvertragsupdate ist für Juli geplant, das die Funktionsweise von Staking und Belohnungen ändern und alles auf den $A-Token umstellen wird.
-
Das neue System wird nur Staking und Unstaking in $A-Tokens erlauben, und Belohnungen werden ebenfalls in $A beansprucht.
-
Wir arbeiten mit Proxy-Betreibern zusammen, um ihnen zu helfen, schrittweise auf das neue Token-System umzusteigen.
-
Es gibt einen Plan, einen Wrapper für BPay-Ansprüche hinzuzufügen, um sicherzustellen, dass sie weiterhin mit dem neuen Token-System funktionieren.
-
Node-Betreiber testen Antelope Spring v1.2 RC3, insbesondere das neue Gossip-basierte Peering, um sicherzustellen, dass es für den Praxiseinsatz bereit ist, mit Empfehlungen für Produktions-Setups.
Bevorstehendes Vaulta MSIG für die Bereitstellung von Systemverträgen
Die Vaulta Foundation plant also eine Multi-Signatur (MSIG)-Transaktion. Gerüchten zufolge streben sie einen Vorschlag um den 8. Juli an. Das Ziel? Die Ausführung bis zum 15. Juli, aber das hängt von der Genehmigung durch genügend Parteien ab.
Dieses MSIG dreht sich alles um aktualisierte Systemverträge, die Änderungen an Staking, Belohnungen und der Registrierung von Peer-Schlüsseln zusammenführen.
Was ändert sich genau?
-
Zunächst wollen sie, dass Staking und Un-Staking nur noch über den core.vaulta-Vertrag erfolgen. Stellen Sie sich das als Straffung des gesamten Prozesses vor.
-
BPs können Peer-Schlüssel registrieren. Dies ist für das Gossip-basierte BP-Peering von Spring v1.2.0 erforderlich.
-
Sie können nicht mehr von $EOS aus staken. Staking in $A wird weiterhin über core.vaulta verfügbar sein.
-
Dasselbe gilt für das Unstaking – kein Unstaking mehr zu $EOS. $A ist der Weg über core.vaulta.
-
Und BP-Belohnungsansprüche in $EOS? Nein. Diese Belohnungen müssen in $A über core.vaulta beansprucht werden.
Überarbeitung von Staking und Belohnungsansprüchen
Okay, das System wird also in Bezug auf Staking und Belohnungsansprüche etwas überarbeitet. Grundsätzlich muss alles in tokenisierter Form erfolgen. Keine direkte EOS-Ausgabe mehr für Belohnungen, was eine ziemlich große Sache ist.
Stellen Sie es sich so vor:
-
Staking und Unstaking? Alles über Token.
-
Belohnungen beanspruchen? Ja, wieder Token.
-
Das Ziel? Eine strengere Kontrolle über die Verteilung der Token. Macht Sinn, oder?
Ich weiß, dass die leitenden Entwickler noch an den Details arbeiten, aber die Hauptidee ist, die Dinge zu straffen und den Token-Fluss genauer zu überwachen. Es geht darum, das System effizienter und, ich schätze, auf lange Sicht einfacher zu verwalten.
Koordination der Proxy-Infrastruktur
Es gab einige Gespräche darüber, wie man mit den großen Staking-Proxys während der Umstellung zusammenarbeitet. Das Wichtigste ist, sicherzustellen, dass alle auf dem gleichen Stand sind, wenn Vaulta zu einem neuen System wechselt.
-
Einige Proxys werden anfangen, Gebühren in dem neuen Token zu erheben, aber die Belohnungen für eine Weile noch in EOS auszahlen. Das ist wie ein Zwischenschritt.
-
Der Plan ist, schließlich auf ein vollständig Token-basiertes Belohnungssystem umzusteigen. Das ist eine schrittweise Sache.
-
Node-Betreiber sollten sich melden, wenn sie andere Proxys oder Pools kennen, die von diesen Änderungen betroffen sein könnten. Je mehr Informationen, desto besser.
BPay-Anspruchsbehandlungslücke
Es sieht so aus, als hätten die aktuellen Systemvertrags-Updates die Integration der eosio.bpay-Belohnungsansprüche irgendwie vergessen. Hoppla! Das bedeutet, dass Blockproduzenten ihre Belohnungen während des Übergangs möglicherweise nicht richtig beanspruchen können.
Um dies zu beheben, ist die Idee, eine Wrapper-Aktion hinzuzufügen. Grundsätzlich würde dieser Wrapper es BPs ermöglichen, ihre Belohnungen im neuen Token-Format zu beanspruchen. Dies ist aus mehreren Gründen wichtig:
-
Es sorgt für einen reibungslosen Ablauf während des Wechsels.
-
Es stellt sicher, dass niemand Belohnungen verpasst, die ihm zustehen.
-
Es gibt allen etwas Luft zum Atmen, so dass die Wahrscheinlichkeit, dass etwas kaputt geht, geringer ist.
Im Grunde ist es eine schnelle Lösung, um potenzielle Kopfschmerzen zu vermeiden. Der Zeitpunkt ist flexibel, so dass nichts anderes durcheinandergebracht werden sollte.
Überprüfung der Einschränkung des Anspruchsfensters
Es gibt also diese alte Regel, die besagt, dass man Dinge nur innerhalb eines 24-Stunden-Fensters plus einer zusätzlichen Sekunde beanspruchen kann. Das ist irgendwie nervig, oder? Nun, es wird darüber gesprochen, es zu ändern. Jemand schlug vor, dieses Fenster zu vergrößern oder die Einschränkung mit einem Vertragsupdate ganz aufzuheben.
Node-Betreiber scheinen mit der Idee einverstanden zu sein, aber sie denken, dass es am besten ist, zu warten, bis die MSIG-Sache erledigt ist. Macht Sinn, eins nach dem anderen. Ein zukünftiges MSIG könnte diese Änderung für eine reibungslose Bereitstellung beinhalten. Im Grunde wollen sie es jetzt nicht anfassen und riskieren, mehr Probleme zu verursachen, als es löst. Es geht darum, die Dinge stabil zu halten, wissen Sie?
Antelope Spring v1.2 RC3 Tests und Verbesserungen
Antelope Spring v1.2 RC3 ist da und bringt einige interessante Änderungen mit sich. Diese Version konzentriert sich auf die Behebung einiger lästiger Probleme und die Erhöhung der Flexibilität für Node-Betreiber.
Es ist kein obligatorisches Upgrade für die Testteilnahme, also kein Druck. Hier ist eine kurze Zusammenfassung:
-
Das Update kürzt Serveradressen. Dies sollte dazu beitragen, Fehlkonfigurationen zu reduzieren. Das kennen wir alle, oder?
-
Es erlaubt jetzt doppelte Gossip-Peer-IPs. Das ist eine gute Nachricht für diejenigen, die komplexere Setups betreiben.
-
Das Gossip-Peering-Verhalten bleibt dasselbe wie bei RC2. Wenn Sie also bereits testen, sollte sich alles ziemlich vertraut anfühlen.
Validierung des Gossip-basierten Peering-Netzwerks
Die nächste Testrunde dreht sich also darum, sicherzustellen, dass die automatisierte Peer-Erkennung und -Verbindung tatsächlich funktioniert. Das Ziel ist es, zu sehen, ob sich Knoten nur über die Gossip-Daten verbinden können, die sie empfangen.
Hier ist der Plan:
-
Alle Teilnehmer müssen alle ihre manuellen Peer-Einträge entfernen, außer einem bestimmten Knoten. Dies zwingt das System, sich auf Gossip zu verlassen.
-
Die Idee ist, zu bestätigen, dass sich Knoten nur basierend auf den Gossip-Daten verbinden, die sie erhalten.
-
Die Jungle Testnet Telegram-Gruppe wird die gesamte Konfiguration und Planung koordinieren. Behalten Sie diese also für Updates im Auge.
Empfehlungen für das Produktions-Peering
Bei Produktions-Blockproduzenten (BPs) ist direktes externes Peering aus Sicherheitsgründen im Allgemeinen keine gute Idee. Es ist viel sicherer, einen mehrschichtigen Ansatz zu implementieren.
Hier ist, was empfohlen wird:
-
Richten Sie eine „Canary Node“-Architektur ein: BP → Canary Node → Externes Netzwerk.
-
Behalten Sie Ihre Gossip-Konfigurationen auf den Canary Nodes, nicht direkt auf den BPs.
-
Dieses Setup hilft bei der Firewall-Kompatibilität und isoliert Ihre BP-Operationen von jeglichen Netzwerk-Eigenheiten. Im Grunde ist es wie eine Pufferzone, um den Kern Ihres Betriebs zu schützen.
Fazit
Das Vaulta Node Operator Meeting am 11. Juni 2025 hat also viel behandelt. Sie sprachen über den bevorstehenden Multi-Signatur (MSIG)-Plan, der eine große Sache für neue Systemverträge ist. Das bedeutet Änderungen daran, wie Staking und Belohnungen funktionieren, wobei alles auf $A-Token umgestellt wird. Sie diskutierten auch die Zusammenarbeit mit Proxy-Betreibern und das Testen des Jungle-Netzwerks für Antelope Spring v1.2 RC3. Außerdem sprachen sie Probleme mit BPay-Ansprüchen an und wie sie das Timing der Belohnungsansprüche später beheben könnten. Es scheint, als gäbe es viele bewegliche Teile, aber es geht alles darum, das System zu verbessern.
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.
 Node Operator Meeting - MSIG Plans, System Contract Changes, And Gossip Network Testing.jpeg)