Riunione degli operatori del nodo Vaulta (ex EOS): Piani MSIG, modifiche al contratto di sistema e test della rete Gossip

L'ultima riunione degli operatori di nodi Vaulta ($EOS $A) dell'11 giugno 2025 ha trattato alcuni grandi cambiamenti in arrivo. Abbiamo parlato di un nuovo piano multi-firma (MSIG) per i contratti di sistema, una completa rielaborazione di come funzioneranno lo staking e le ricompense, e come gestiremo le richieste BPay. C'è stata anche molta discussione sul test del nuovo Antelope Spring v1.2 RC3 sulla rete Jungle. Sembra che le cose stiano andando veloci, e tutti si stanno preparando per questi aggiornamenti.

Punti chiave

• Un importante aggiornamento del contratto di sistema Vaulta è previsto per luglio, che cambierà il funzionamento dello staking e delle ricompense, spostando tutto al token $A.

• Il nuovo sistema consentirà lo staking e l'unstaking solo in token $A, e le ricompense saranno anch'esse richieste in $A.

• Stiamo lavorando con gli operatori proxy per aiutarli a passare gradualmente al nuovo sistema di token.

• C'è un piano per aggiungere un wrapper per le richieste BPay per assicurarsi che funzionino ancora con il nuovo sistema di token.

• Gli operatori di nodi stanno testando Antelope Spring v1.2 RC3, in particolare il nuovo peering basato su gossip, per assicurarsi che sia pronto per il prime time, con raccomandazioni per le configurazioni di produzione.

Prossimo MSIG Vaulta per la distribuzione del contratto di sistema

Quindi, la Fondazione Vaulta sta pianificando una transazione multi-firma (MSIG). Si dice che stiano puntando a una proposta intorno all'8 luglio. L'obiettivo? Farla eseguire entro il 15 luglio, ma questo dipende dall'ottenimento di sufficienti approvazioni.

Questo MSIG riguarda gli aggiornamenti dei contratti di sistema, che riuniscono i cambiamenti allo staking, alle ricompense e alla registrazione delle chiavi peer.

Cosa sta cambiando, esattamente?

• Innanzitutto, vogliono che lo staking e l'unstaking avvengano solo tramite il contratto core.vaulta. Pensatelo come una semplificazione dell'intero processo.

• I BP potranno registrare le chiavi peer. Questo è necessario per il peering BP basato su gossip di Spring v1.2.0.

• Non sarà più possibile fare staking da $EOS. Lo staking in $A sarà comunque disponibile tramite core.vaulta.

• Lo stesso vale per l'unstaking – non più unstaking a $EOS. $A è la strada da seguire tramite core.vaulta.

• E le richieste di ricompensa BP in $EOS? No. Bisogna richiedere quelle ricompense in $A tramite core.vaulta.

Revisione dello staking e delle ricompense

Ok, quindi il sistema sta subendo un piccolo restyling per quanto riguarda lo staking e la richiesta di ricompense. In pratica, tutto dovrà avvenire in forma tokenizzata. Niente più emissione diretta di EOS per le ricompense, il che è un bel cambiamento.

Pensatela così:

• Staking e unstaking? Tutto tramite token.

• Richiesta di ricompense? Sì, di nuovo token.

• L'obiettivo? Un controllo più stretto su come vengono distribuiti i token. Ha senso, no?

So che gli sviluppatori principali stanno ancora definendo i dettagli, ma l'idea principale è quella di semplificare le cose e tenere d'occhio il flusso dei token. Si tratta di rendere il sistema più efficiente e, suppongo, più facile da gestire a lungo termine.

Coordinamento dell'infrastruttura proxy

Si è parlato di come lavorare con i grandi proxy di staking durante il passaggio. La cosa principale è assicurarsi che tutti siano sulla stessa pagina mentre Vaulta passa a un nuovo sistema.

• Alcuni proxy inizieranno a riscuotere le commissioni nel nuovo token ma pagheranno comunque le ricompense in EOS per un po'. È come un punto intermedio.

• Il piano è di passare eventualmente a un sistema di ricompense completamente basato su token. È una cosa graduale.

• Gli operatori di nodi dovrebbero parlare se conoscono altri proxy o pool che potrebbero essere interessati da questi cambiamenti. Più informazioni, meglio è.

Lacuna nella gestione delle richieste BPay

Quindi, sembra che gli attuali aggiornamenti del contratto di sistema abbiano in qualche modo dimenticato l'integrazione della ricompensa di richiesta eosio.bpay. Ops! Ciò significa che i produttori di blocchi potrebbero non essere in grado di richiedere correttamente le loro ricompense durante la transizione.

Per risolvere questo problema, l'idea è di aggiungere un'azione wrapper. In pratica, questo wrapper consentirebbe ai BP di richiedere le loro ricompense nel nuovo formato token. Questo è importante per diversi motivi:

• Mantiene le cose in funzione senza intoppi durante il passaggio.

• Assicura che nessuno perda le ricompense che gli spettano.

• Dà a tutti un po' di respiro, in modo che ci siano meno possibilità che qualcosa si rompa.

In pratica, è una soluzione rapida per evitare un potenziale mal di testa. La tempistica è flessibile, quindi non dovrebbe rovinare nient'altro.

Revisione della restrizione della finestra di richiesta

Quindi, c'è questa vecchia regola che dice che puoi richiedere le cose solo entro una finestra di 24 ore, più un secondo extra. È un po' fastidioso, vero? Bene, si parla di cambiarla. Qualcuno ha suggerito di allargare quella finestra o semplicemente di eliminare del tutto la restrizione con un aggiornamento del contratto.

Gli operatori di nodi sembrano essere d'accordo con l'idea, ma pensano che sia meglio aspettare che la cosa del MSIG sia fatta. Ha senso, una cosa alla volta. Un futuro MSIG potrebbe includere questo cambiamento per una distribuzione senza intoppi. In pratica, non vogliono metterci mano adesso e rischiare di causare più problemi di quanti ne risolva. Si tratta di mantenere le cose stabili, sapete?

Test e miglioramenti di Antelope Spring v1.2 RC3

Antelope Spring v1.2 RC3 è qui, e sta portando alcuni cambiamenti interessanti. Questa versione si concentra sulla risoluzione di alcuni problemi fastidiosi e sul rendere le cose un po' più flessibili per gli operatori di nodi.

Non è un aggiornamento obbligatorio per la partecipazione ai test, quindi nessuna pressione. Ecco un rapido riepilogo:

• L'aggiornamento taglia gli indirizzi del server. Questo dovrebbe aiutare a ridurre gli errori di configurazione. Ci siamo passati tutti, vero?

• Ora consente IP peer gossip duplicati. Questa è una buona notizia per coloro che gestiscono configurazioni più complesse.

• Il comportamento del peering gossip rimarrà lo stesso di RC2. Quindi, se stai già testando, le cose dovrebbero sembrare abbastanza familiari.

Validazione della rete di peering basata su gossip

Quindi, il prossimo ciclo di test riguarda la verifica che la scoperta automatica dei peer e la connessione funzionino effettivamente. L'obiettivo è vedere se i nodi possono connettersi semplicemente usando i dati gossip che ricevono.

Ecco il piano:

• Tutti i partecipanti devono rimuovere tutte le loro voci peer manuali, tranne un nodo designato. Questo costringe il sistema a fare affidamento sul gossip.

• L'idea è di confermare che i nodi si connettono solo in base ai dati gossip che stanno ricevendo.

• Il gruppo Telegram di Jungle Testnet coordinerà tutte le configurazioni e la pianificazione. Quindi, tenete d'occhio quello per gli aggiornamenti.

Raccomandazioni per il peering di produzione

Quando si tratta di produttori di blocchi (BP) di produzione, il peering esterno diretto non è generalmente una buona idea dal punto di vista della sicurezza. È molto più sicuro implementare un approccio più stratificato.

Ecco cosa si raccomanda:

• Impostare un'architettura a "Canary Node": BP → Nodo Canary → Rete Esterna.

• Mantieni le configurazioni di gossip sui nodi canary, non direttamente sui BP.

• Questa configurazione aiuta con la compatibilità del firewall e mantiene le operazioni dei tuoi BP isolate da eventuali anomalie di rete. In pratica, è come avere una zona cuscinetto per proteggere il cuore della tua operazione.

Conclusione

Quindi, l'incontro degli operatori di nodo Vaulta dell'11 giugno 2025 ha coperto molti argomenti. Si è parlato del piano di multi-firma (MSIG) in arrivo, che rappresenta un cambiamento importante per i nuovi contratti di sistema. Questo comporta modifiche al funzionamento dello staking e delle ricompense, spostando tutto verso i token $A. Hanno anche discusso della collaborazione con operatori proxy e dei test sulla rete Jungle per Antelope Spring v1.2 RC3. Inoltre, è stato affrontato il problema delle richieste di BPay e di come potrebbero sistemare la tempistica per il riscatto delle ricompense in futuro. Sembrano esserci molte cose in movimento, ma l'obiettivo è sempre migliorare il sistema.

Questo articolo è stato creato con il supporto di una tecnologia basata sull'intelligenza artificiale, attingendo a molteplici fonti affidabili. Il contenuto finale è stato accuratamente revisionato e modificato dal team editoriale di BlockzHub per garantire accuratezza, chiarezza e coerenza. Le fonti originali delle informazioni vengono citate ove appropriato e necessario. Le opinioni espresse in questo articolo non rappresentano necessariamente le posizioni o i punti di vista ufficiali di BlockzHub. Questo articolo ha esclusivamente scopo informativo e non deve essere considerato come consulenza finanziaria o professionale. Investire comporta dei rischi ed è consigliabile consultare un consulente finanziario qualificato prima di prendere qualsiasi decisione di investimento.