En la reciente reunión de operadores de nodos de EOS/Vaulta celebrada el 30 de abril de 2025, desarrolladores y operadores de infraestructura se reunieron para discutir actualizaciones importantes y desafíos en el ecosistema de EOS. Entre los temas clave se encontraban el parche Antelope Spring 1.1.5, que abordó errores críticos, y el progreso en las características de red basadas en gossip. La reunión también cubrió el próximo piloto de la testnet Jungle para el auto-peering basado en gossip y el cambio de la Fundación de la Red EOS a la Fundación Vaulta. Las discusiones sobre la propagación de transacciones y los roles de finalizadores destacaron la evolución continua de los modelos de gobernanza dentro de la red EOS. Aquí hay un resumen de los puntos principales de la reunión.
Conclusiones Clave
-
Antelope Spring 1.1.5 corrige errores importantes, mejorando la estabilidad y el rendimiento de los nodos.
-
La actualización 3.9.0 RC1 introduce el auto-peering basado en gossip, mejorando la conectividad de la red.
-
La testnet Jungle probará escenarios de gossip en el mundo real para evaluar la resiliencia de la red.
-
La Fundación Vaulta es ahora la organización principal para proyectos relacionados con EOS en GitHub.
-
El soporte de IPv4 e IPv6 es limitado, con desafíos continuos en la configuración y la publicidad.
El Parche Antelope Spring 1.1.5 Corrige Problemas Críticos de Compilación y Caídas
Así que, el parche Antelope Spring 1.1.5 ya está disponible, y parece que es bastante importante. Aborda algunos problemas serios que estaban causando problemas a los operadores de nodos.
Básicamente, había un error que hacía que la compilación de contratos OC fallara sin avisar, lo que, por supuesto, afectaba el rendimiento del nodo. Reiniciar los nodos ayudaba un poco, pero la verdadera solución es simplemente actualizar. También arreglaron algunos fallos raros que ocurrían con ship, especialmente cuando se cortaban las conexiones. Si estás usando OC o ship para sincronizar o indexar, probablemente deberías actualizar.
El Progreso de la Función de Peering Basada en Gossip con 3.9.0 RC1
La función de peering basada en gossip está avanzando, con actualizaciones incluidas en la versión 3.9.0 RC1. Esto es un gran avance porque podría cambiar la forma en que los nodos se conectan y comparten información. Los contratos del sistema se han actualizado para manejar el registro y eliminación de claves de pares, lo que hace posible el auto-peering.
Aquí hay un resumen rápido de lo que está sucediendo:
-
Se espera una propuesta de firma múltiple (MSIG) para implementar esto en la testnet Jungle pronto, tal vez a principios de la próxima semana.
-
Si estás interesado en probar esto, se han compartido instrucciones en el canal de Jungle. El equipo está buscando comentarios para asegurarse de que todo funcione sin problemas.
-
El objetivo es facilitar y hacer más eficiente la operación de nodos automatizando el proceso de peering. ¡Sin más necesidad de agregar pares manualmente, con suerte!
La Testnet Jungle Pilotará el Auto-Peering Basado en Gossip con Escenarios del Mundo Real
La testnet Jungle está a punto de convertirse en un campo de pruebas para la función de auto-peering basada en gossip. La idea es simular condiciones de red del mundo real para ver qué tan bien se sostiene el nuevo sistema. Es un paso bastante importante antes de que algo se active en la red principal.
Se pide a los operadores que mantengan sus listas de pares codificadas al mínimo. Esto es importante para que el sistema de gossip pueda ser probado adecuadamente. La red necesita un buen número de participantes para realmente ponerlo a prueba, especialmente cuando las cosas se ponen un poco caóticas.
Hablando de caos, hay planes para introducir algunos escenarios deliberadamente disruptivos, como:
-
Cambiar puertos.
-
Reorganizar horarios.
-
Generalmente hacer las cosas un poco impredecibles.
Una gran incógnita es cómo se comportarán los firewalls con el nuevo sistema. Se necesita la opinión de la comunidad sobre las configuraciones de firewalls para obtener una imagen más clara.
La Fundación Vaulta Reemplaza a la Fundación de la Red EOS en GitHub
Así que, la Fundación de la Red EOS ya no está en GitHub, y la Fundación Vaulta ha tomado su lugar. Es básicamente un cambio de nombre para la organización que se encarga de cosas como contratos del sistema y documentación. Todos los repositorios se han trasladado.
No es un gran problema, pero es algo a tener en cuenta. Aquí hay lo que debes saber:
-
El nombre de la organización ha cambiado, por lo que los repositorios como contratos del sistema y documentación están bajo un nuevo paraguas.
-
Los enlaces antiguos deberían redirigir automáticamente, lo cual es agradable. Pero sigue siendo una buena idea actualizar tus marcadores si tienes alguno.
-
Esto no cambia realmente nada sobre cómo opera la red, es más bien un asunto administrativo.
Limitaciones de Publicidad y Desafíos de Configuración de IPv4 e IPv6
En este momento, los nodos solo pueden publicitar una dirección P2P. Si estás tratando de ejecutar tanto IPv4 como IPv6, necesitarás hacer algunos cambios en el código para que funcione correctamente. Es un poco complicado, honestamente. Los operadores están viendo diferentes cosas debido a cómo funciona DNS y cómo están configuradas las redes. Además, no mucha gente está usando realmente IPv6 todavía, por lo que la mayoría de las conexiones siguen siendo IPv4. Es algo a tener en cuenta si estás manipulando la configuración de tu nodo.
Los nodos actualmente solo soportan una dirección P2P publicitada; el soporte de doble pila necesita cambios en el código.
Aquí hay algunas cosas a considerar:
-
La resolución de DNS puede ser un poco impredecible.
-
Las configuraciones de red varían mucho, lo que lleva a diferentes experiencias.
-
La adopción de IPv6 sigue siendo bastante baja en el mundo real.
Rediseño de la Propagación de Transacciones para Abordar Cuellos de Botella de Grandes Transacciones
Así que, hay un problema con las grandes transacciones que a veces congestionan la red. El equipo está trabajando en una solución que debería hacer que las cosas funcionen más suavemente, especialmente cuando hay mucha actividad. La idea es reducir la congestión de la red enviando mensajes de "notificación de transacción" más pequeños en lugar de toda la transacción de inmediato.
Piénsalo así:
-
En lugar de que todos griten el mensaje completo a la vez, solo envían un aviso rápido.
-
Las transacciones solo se reenvían a los pares que aún no han sido notificados, lo que reduce las repeticiones innecesarias.
-
Esto debería ayudar realmente al rendimiento cuando la red está muy ocupada.
Esta actualización está planeada para la versión Spring 1.3. Se trata de asegurarse de que las cosas no se congestionen cuando hay un montón de transacciones sucediendo al mismo tiempo. Es como darle un poco de espacio a la red.
Discusiones sobre Finalizadores Revelan Flexibilidad en el Consenso de Savannah
Así que, ha habido algunas conversaciones sobre los finalizadores y cómo funcionan dentro del mecanismo de consenso de Savannah. Resulta que hay más flexibilidad de la que la gente pensaba inicialmente. La conclusión principal es que los roles de finalizadores no tienen que estar directamente vinculados a los proponentes de bloques, lo que abre posibilidades para una mejor redundancia.
Piénsalo así:
-
En este momento, los contratos del sistema están configurados para hacer cumplir un consenso de 2/3+1. Pero, mira esto, eso se puede ajustar hasta el 51%. Eso es un gran avance.
-
Las cadenas más pequeñas, como Ultra, están realmente presionando por modelos de consenso que puedan escalar. Necesitan algo que funcione sin romper el banco.
-
Lo interesante es que podrías técnicamente ejecutar un montón de finalizadores ligeros para aumentar la tolerancia a fallos. Más finalizadores, menos riesgo de que las cosas salgan mal. Se trata de opciones, y Savannah parece estar ofreciendo muchas.
Ponderaciones y Separación de Roles Permiten Modelos de Gobernanza Avanzados
Así que, el sistema está configurado para manejar votos de finalizadores ponderados. ¿Qué significa eso? Básicamente, significa que puedes tratar a los productores y finalizadores de manera diferente. Esto abre algunas posibilidades interesantes para cómo se estructura la gobernanza.
Piénsalo así:
-
Podrías pagar solo a los nodos de alto peso, recompensando a aquellos que contribuyen más a la seguridad y estabilidad de la red.
-
Podrías usar voluntarios para la participación de bajo peso, permitiendo que más personas se involucren sin necesariamente tener una gran participación.
-
Esta flexibilidad te permite ajustar el mecanismo de consenso sin tener que hacer cambios a nivel de protocolo. Se trata de ajustar las ponderaciones y roles para lograr el resultado deseado.
-
Realmente enfatiza el potencial para diseños escalables y resilientes, especialmente en cadenas más pequeñas donde los recursos pueden ser limitados. Puedes ser creativo con cómo asignas responsabilidades y recompensas para asegurar que la red se mantenga saludable y segura.
Conclusión
En resumen, la reunión de operadores de nodos de EOS/Vaulta del 30 de abril de 2025 destacó varios desarrollos importantes en el ecosistema de EOS. Las discusiones sobre la red basada en gossip y la flexibilidad de los roles de finalizadores mostraron un compromiso con la mejora del rendimiento y la adaptabilidad de la red. Las actualizaciones al software de Antelope y la introducción de nuevas características como el auto-peering son pasos hacia un sistema más eficiente y resiliente. A medida que cadenas más pequeñas como Ultra buscan beneficiarse de estos avances, el potencial para modelos de gobernanza innovadores se vuelve más claro. En general, estos cambios reflejan un enfoque proactivo para abordar los desafíos que enfrentan los operadores de nodos y la comunidad en general.
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.