Reunión de operadores de nodos de Vaulta (anteriormente EOS): planes de MSIG, cambios en el contrato del sistema y pruebas de red de chismorreo

La última reunión de operadores de nodos de Vaulta ($EOS $A) el 11 de junio de 2025, cubrió algunos cambios importantes que se avecinan. Hablamos sobre un nuevo plan de multifirma (MSIG) para contratos de sistema, una reelaboración completa de cómo funcionarán el staking y las recompensas, y cómo manejaremos las reclamaciones de BPay. También hubo mucha discusión sobre la prueba de la nueva Antelope Spring v1.2 RC3 en la red Jungle. Parece que las cosas se están moviendo rápido y todos se están preparando para estas actualizaciones.

Puntos clave

• Se planea una importante actualización del contrato del sistema Vaulta para julio, que cambiará la forma en que funcionan el staking y las recompensas, moviendo todo al token $A.

• El nuevo sistema solo permitirá el staking y el unstaking en tokens $A, y las recompensas también se reclamarán en $A.

• Estamos trabajando con operadores proxy para ayudarlos a cambiar gradualmente al nuevo sistema de tokens.

• Hay un plan para agregar un wrapper para las reclamaciones de BPay para asegurarse de que sigan funcionando con el nuevo sistema de tokens.

• Los operadores de nodos están probando Antelope Spring v1.2 RC3, especialmente el nuevo emparejamiento basado en gossip, para asegurarse de que esté listo para el horario estelar, con recomendaciones para configuraciones de producción.

Próximo MSIG de Vaulta para la implementación del contrato del sistema

Entonces, la Fundación Vaulta está planeando una transacción de multifirma (MSIG). Se rumorea que tienen como objetivo una propuesta alrededor del 8 de julio. ¿El objetivo? Que se ejecute antes del 15 de julio, pero eso depende de obtener suficientes aprobaciones.

Este MSIG trata sobre contratos de sistema actualizados, que reúnen cambios en el staking, las recompensas y el registro de claves de pares.

¿Qué está cambiando, exactamente?

• En primer lugar, quieren que el staking y el unstaking solo se realicen a través del contrato core.vaulta. Piense en ello como una simplificación de todo el proceso.

• Los BP podrán registrar claves de pares. Esto es necesario para el emparejamiento de BP basado en gossip de Spring v1.2.0.

• Ya no podrá hacer staking desde $EOS. El staking en $A seguirá estando disponible a través de core.vaulta.

• Lo mismo ocurre con el unstaking: no más unstaking a $EOS. $A es el camino a seguir a través de core.vaulta.

• ¿Y las reclamaciones de recompensas de BP en $EOS? No. Hay que reclamar esas recompensas en $A a través de core.vaulta.

Revisión del staking y las recompensas de reclamación

Bien, el sistema está recibiendo una pequeña renovación en lo que respecta al staking y la reclamación de recompensas. Básicamente, todo tendrá que ocurrir en forma de token. No más emisión directa de EOS para recompensas, lo cual es bastante importante.

Piénselo de esta manera:

• ¿Staking y unstaking? Todo a través de tokens.

• ¿Reclamar recompensas? Sí, tokens de nuevo.

• ¿El objetivo? Un control más estricto sobre cómo se distribuyen los tokens. Tiene sentido, ¿verdad?

• Sé que los desarrolladores principales todavía están trabajando en los detalles, pero la idea principal es simplificar las cosas y vigilar de cerca el flujo de tokens. Se trata de hacer que el sistema sea más eficiente y, supongo, más fácil de administrar a largo plazo.

Coordinación de la infraestructura proxy

Se habló sobre cómo trabajar con los grandes proxies de staking durante el cambio. Lo principal es asegurarse de que todos estén en sintonía a medida que Vaulta se mueve a un nuevo sistema.

• Algunos proxies comenzarán a cobrar tarifas en el nuevo token, pero seguirán pagando recompensas en EOS por un tiempo. Es como un punto intermedio.

• El plan es eventualmente cambiar a un sistema de recompensas totalmente basado en tokens. Es algo gradual.

• Los operadores de nodos deben hablar si conocen otros proxies o pools que puedan verse afectados por estos cambios. Cuanta más información, mejor.

Brecha en el manejo de reclamaciones de BPay

Entonces, parece que las actualizaciones actuales del contrato del sistema se olvidaron de la integración de la recompensa de reclamación de eosio.bpay. ¡Vaya! Esto significa que los productores de bloques podrían no poder reclamar sus recompensas correctamente durante la transición.

Para solucionar esto, la idea es agregar una acción de envoltura. Básicamente, esta envoltura permitiría a los BP reclamar sus recompensas en el nuevo formato de token. Esto es importante por varias razones:

• Mantiene las cosas funcionando sin problemas durante el cambio.

• Se asegura de que nadie se pierda las recompensas que se le deben.

• Les da a todos un poco de margen de maniobra, por lo que hay menos posibilidades de que algo se rompa.

Básicamente, es una solución rápida para evitar un posible dolor de cabeza. El tiempo es flexible, por lo que no debería estropear nada más.

Revisión de la restricción de la ventana de reclamación

Entonces, existe esta vieja regla que dice que solo puedes reclamar cosas dentro de una ventana de 24 horas, más un segundo extra. Es un poco molesto, ¿verdad? Bueno, se habla de cambiarlo. Alguien sugirió hacer esa ventana más grande o simplemente eliminar la restricción por completo con una actualización del contrato.

Los operadores de nodos parecen estar de acuerdo con la idea, pero creen que es mejor esperar hasta que termine lo del MSIG. Tiene sentido, una cosa a la vez. Un futuro MSIG podría incluir este cambio para una implementación sin problemas. Básicamente, no quieren meterse con eso ahora y arriesgarse a causar más problemas de los que resuelve. Se trata de mantener las cosas estables, ¿sabes?

Pruebas y mejoras de Antelope Spring v1.2 RC3

Antelope Spring v1.2 RC3 ya está aquí y trae algunos cambios interesantes. Esta versión se centra en corregir algunos problemas molestos y hacer que las cosas sean un poco más flexibles para los operadores de nodos.

No es una actualización obligatoria para la participación en las pruebas, así que no hay presión. Aquí hay un resumen rápido:

• La actualización recorta las direcciones del servidor. Esto debería ayudar a reducir los errores de configuración. Todos hemos pasado por eso, ¿verdad?

• Ahora permite direcciones IP de pares de gossip duplicadas. Esta es una buena noticia para quienes ejecutan configuraciones más complejas.

• El comportamiento de emparejamiento de gossip seguirá siendo el mismo que en RC2. Entonces, si ya está probando, las cosas deberían parecerle bastante familiares.

Validación de la red de emparejamiento basada en gossip

Entonces, la próxima ronda de pruebas se trata de asegurarse de que el descubrimiento automático de pares y la conexión realmente funcionen. El objetivo es ver si los nodos pueden conectarse solo usando los datos de gossip que reciben.

Aquí está el plan:

• Todos los participantes deben eliminar todas sus entradas de pares manuales, excepto un nodo designado. Esto obliga al sistema a depender del gossip.

• La idea es confirmar que los nodos se conectan solo en función de los datos de gossip que están obteniendo.

• El grupo de Telegram de Jungle Testnet coordinará toda la configuración y la programación. Así que, esté atento a las actualizaciones.

Recomendaciones de emparejamiento de producción

Cuando se trata de productores de bloques (BP) de producción, el emparejamiento externo directo generalmente no es una buena idea desde el punto de vista de la seguridad. Es mucho más seguro implementar un enfoque más en capas.

Esto es lo que se recomienda:

• Configure una arquitectura de "Nodo Canario": BP → Nodo Canario → Red Externa.

• Mantenga sus configuraciones de gossip en los nodos canario, no directamente en los BP.

• Esta configuración ayuda con la compatibilidad del firewall y mantiene sus operaciones de BP aisladas de cualquier rareza de la red. Básicamente, es como tener una zona de amortiguación para proteger el núcleo de su operación.

Conclusión

Así que, esa reunión de operadores de nodos de Vaulta del 11 de junio de 2025, cubrió mucho terreno. Hablaron sobre el próximo plan de multifirma (MSIG), que es un gran avance para los nuevos contratos del sistema. Esto significa cambios en la forma en que funcionan el staking y las recompensas, moviendo todo a los tokens $A. También discutieron trabajar con operadores proxy y probar la red Jungle para Antelope Spring v1.2 RC3. Además, plantearon problemas con las reclamaciones de BPay y cómo podrían solucionar el momento de las reclamaciones de recompensas más adelante. Parece que hay muchas partes móviles, pero todo se trata de mejorar el sistema.

Este artículo fue creado con el apoyo de tecnología impulsada por IA, basándose en múltiples fuentes reputadas. El contenido final ha sido revisado y editado minuciosamente por el equipo editorial de BlockzHub para garantizar precisión, claridad y coherencia. Las fuentes originales de los informes se citan siempre que sea apropiado y necesario. Las opiniones expresadas en este artículo no representan necesariamente los puntos de vista o posiciones oficiales de BlockzHub. Este artículo tiene únicamente fines informativos y no debe considerarse asesoramiento financiero o profesional. Invertir implica riesgos, y se recomienda consultar a un asesor financiero calificado antes de tomar decisiones de inversión.