Esta semana pasada, los operadores de nodos de Vaulta, anteriormente conocido como EOS, se reunieron para discutir actualizaciones importantes. La reunión cubrió el progreso del software Antelope Spring 2.0, cómo está funcionando el nuevo sistema de chismorreo (gossip) para conectar a los productores de bloques, e ideas para hacer las conexiones de red más seguras. Los operadores de nodos compartieron sus experiencias con problemas técnicos y cómo están configuradas sus redes, todo ello mientras mantenían la cadena de bloques de Vaulta funcionando sin problemas.
Puntos Clave
-
La Vista Previa para Desarrolladores 1 de Antelope Spring 2.0 ya está disponible, centrándose en las llamadas síncronas, con cambios más significativos esperados en la Vista Previa 2 alrededor de septiembre.
-
El nuevo sistema de eventos requerirá que los operadores de nodos establezcan límites de almacenamiento, con más detalles a medida que continúe el desarrollo.
-
La adopción del sistema de emparejamiento por chismorreo (gossip) está ocurriendo, pero no todos los principales productores de bloques están conectados todavía, lo que significa que la red no está completamente mallada.
-
Configurar la red de chismorreo (gossip) ha sido difícil, con problemas para encontrar pares y sugerencias para usar listas alojadas para ayudar a los nuevos nodos a conectarse.
-
Una nueva idea es permitir a los operadores de nodos crear listas de pares permitidos o bloqueados para el sistema de chismorreo (gossip) para ayudar a gestionar las conexiones y la seguridad.
Progreso del Desarrollo de Antelope Spring 2.0
El desarrollo de Antelope Spring 2.0 avanza, con la primera Vista Previa para Desarrolladores (DP1) ya disponible. Esta versión inicial trae soporte para llamadas síncronas y da acceso a un entorno de red de prueba. Se está pidiendo a los desarrolladores que reconstruyan sus contratos usando CDT 5.0 dev 1.1. Por ahora, DP1 no cambia mucho para los operadores de nodos, ya que los mayores impactos se esperan con DP2. Esa próxima vista previa, DP2, está planeada para principios de septiembre e incluirá el nuevo sistema de eventos junto con mejoras en la velocidad de ejecución.
Vista Previa del Sistema de Eventos e Implicaciones
La próxima Vista Previa para Desarrolladores 2 (DP2) para Antelope Spring 2.0 introducirá un nuevo sistema de eventos. Este sistema permitirá la difusión de eventos efímeros que están comprometidos criptográficamente dentro de los datos de consenso. Para los operadores de nodos, esto significa que se introducirá un nuevo parámetro de configuración, que les exigirá establecer configuraciones de almacenamiento mínimas para estos eventos. Los detalles exactos y las mejores prácticas para gestionar estos eventos aún se están elaborando a medida que avanza el desarrollo, pero DP2 proporcionará las características y configuraciones iniciales relevantes para los nodos necesarias para manejarlos. Las implicaciones para los operadores de nodos son significativas, ya que deberán adaptar sus configuraciones para acomodar este nuevo flujo de datos.
Funcionalidad del Sistema de Eventos
-
Los eventos son mensajes temporales.
-
Se aseguran mediante compromisos criptográficos en el consenso.
-
Los operadores de nodos deben definir límites de almacenamiento.
Requisitos de Configuración para Operadores de Nodos
-
Establecer almacenamiento mínimo para eventos efímeros.
-
Monitorizar el flujo de datos de eventos.
-
Adaptarse a los nuevos parámetros de configuración en DP2.
Impacto Anticipado del Sistema de Eventos
-
Nuevos tipos de datos para gestionar.
-
Potencial para una monitorización de red mejorada.
-
Necesidad de procedimientos operativos actualizados.
Estado de Adopción del Emparejamiento BP por Chismorreo (Gossip)
Varios de los principales Productores de Bloques (BPs) han tomado medidas para registrar sus claves de pares, lo cual es un buen comienzo. Estamos viendo algunas conexiones de emparejamiento parciales, como entre Genereos y Eosphere, lo que demuestra que la conectividad básica es funcional para algunos. Sin embargo, esto aún no está ocurriendo en toda la red. La adopción sigue siendo un trabajo en progreso, y una mayor coordinación y confirmaciones claras por parte de los BPs realmente ayudarían a acelerar las cosas. No hemos alcanzado una masa crítica de adopción, lo que podría ser la razón por la que la red de chismorreo (gossip) no está completamente mallada como se esperaba.
Desafíos Técnicos en la Formación de la Red de Chismorreo (Gossip)
Configurar una red de chismorreo (gossip) estable para los Productores de Bloques (BPs) no es tan sencillo como podría parecer. Hay algunos obstáculos con los que nos estamos encontrando. Para empezar, encontrar otros pares puede ser impredecible. Esto a menudo se debe a que algunos BPs podrían no tener sus configuraciones completamente resueltas, o quizás los cortafuegos están interfiriendo, bloqueando esas conexiones. Significa que a veces, los nodos simplemente no pueden verse entre sí cuando deberían poder hacerlo.
Ahora mismo, para que las cosas funcionen, la gente sugiere que añadamos pares manualmente para arrancar las conexiones. Esto funciona, pero no es ideal para un sistema descentralizado que se supone que debe encontrar su propio camino. Nos falta una forma para que los nodos se descubran automáticamente entre sí, como un sistema de "pares semilla" que ayude a los nuevos nodos a encontrar los existentes. Algunas ideas que circulan incluyen el uso de listas JSON de pares alojadas para ayudar con esta configuración inicial.
Característica Propuesta de Lista Blanca/Lista Negra para Conexiones de Chismorreo (Gossip)
Para ayudar a gestionar las conexiones dentro de la red de chismorreo (gossip), se está considerando una característica que permita listas blancas y listas negras de pares. Esto daría a los operadores de nodos más control sobre a qué otros nodos se conectan. La idea es permitir que los operadores especifiquen cuentas particulares de Productores de Bloques (BP) que están permitidas o no permitidas para conectarse.
Este sistema propuesto funcionaría junto con las configuraciones manuales de pares existentes. Cualquier par que añada manualmente a la configuración de su nodo seguiría teniendo prioridad. Sin embargo, para los pares descubiertos a través del protocolo de chismorreo (gossip), se aplicarían entonces las reglas de lista blanca y lista negra.
El objetivo principal de esta característica es proporcionar una forma de prevenir conexiones con nodos que podrían estar funcionando mal o que están bajo algún tipo de ataque. Se considera una forma de reducir la necesidad de que los operadores gestionen reglas complejas de cortafuegos externos solo para filtrar el tráfico de chismorreo (gossip) entrante.
Aquí hay un desglose de cómo podría funcionar:
-
Lista Blanca: Una lista de cuentas BP específicas que están explícitamente permitidas para conectarse a su nodo a través de chismorreo (gossip).
-
Lista Negra: Una lista de cuentas BP específicas que están explícitamente prohibidas de conectarse a su nodo a través de chismorreo (gossip).
-
Comportamiento Predeterminado: Si no se configura una lista blanca ni una lista negra, o si un par no está en ninguna de las listas, el nodo probablemente seguiría su comportamiento de conexión predeterminado, permitiendo potencialmente la conexión.
Preocupaciones sobre la Identificación de Pares y la Mitigación de Abusos
Desafíos en la Identificación de Pares
Una de las principales preocupaciones con el sistema de chismorreo (gossip) es averiguar quién está enviando qué. Debido a que los mensajes pueden ser pasados por diferentes nodos, es difícil rastrear dónde comenzó realmente el tráfico malicioso. Esto dificulta detener los problemas en la fuente. Si bloqueas un nodo que está causando problemas, podría seguir propagándose a través de otros nodos que aún no has identificado. Se siente un poco como jugar al topo, y no hay una manera fácil de saber con certeza quién fue el remitente original.
Estrategias de Mitigación de Abusos
Para lidiar con esto, la gente está pidiendo mejores formas de controlar quién puede conectarse y qué tipo de tráfico está permitido. Esto significa tener más que un simple bloqueo. Necesitamos sistemas que puedan examinar la identidad de los pares y aplicar las reglas con más cuidado. La configuración actual no nos da ese tipo de control detallado, lo cual es un gran obstáculo para mantener la red limpia y segura. Está claro que simplemente bloquear nodos individuales no es suficiente cuando la red está diseñada para retransmitir información tan libremente.
Restricciones de Red que Afectan la Viabilidad de las Características
Cuando consideramos hacer que las nuevas características funcionen, especialmente cosas como la lista blanca y la lista negra propuestas para las conexiones de chismorreo (gossip), nos encontramos con algunos problemas de red del mundo real. No siempre es tan simple como encender un interruptor. Por ejemplo, muchos nodos usan servidores proxy para conectarse. Esto es bastante común, pero significa que la dirección IP original de una conexión se oculta. Eso hace que sea difícil saber exactamente de dónde proviene el tráfico, lo cual es un gran problema si intentas controlar quién puede conectarse.
Luego está la tecnología subyacente en sí misma. El protocolo TCP, que es lo que usa el chismorreo (gossip), no ofrece el mismo tipo de control granular sobre quién se conecta como lo haría algo como HTTP. Esto significa que no podemos establecer fácilmente reglas para permitir o bloquear conexiones específicas basadas en información detallada. Además, con las direcciones IP dinámicas y todas estas diferentes configuraciones de proxy, intentar aplicar una lista blanca o lista negra estricta se convierte en un verdadero dolor de cabeza. Parece que estamos constantemente tratando de ponernos al día.
Debido a estos desafíos, muchos operadores de nodos están descubriendo que los controles tradicionales a nivel de cortafuegos siguen siendo la forma más práctica y efectiva de gestionar su tráfico de red. Están acostumbrados a ello, y funciona de manera fiable, incluso si no está tan integrado como podría estar una característica específica de chismorreo (gossip). Necesitamos considerar si las características propuestas pueden realmente superar estas realidades de red existentes o si simplemente añadirán más complejidad sin resolver los problemas centrales.
Conclusión y Próximos Pasos
El desarrollo de Antelope Spring 2.0, particularmente la próxima Vista Previa para Desarrolladores 2 (DP2) y su sistema de eventos integrado, representa un área significativa para las próximas pruebas y comentarios de los operadores de nodos. Los esfuerzos continuos para fomentar y monitorizar la adopción del protocolo de Chismorreo (Gossip) para el emparejamiento de Productores de Bloques (BP) también son importantes. La característica propuesta de lista blanca y lista negra para gestionar las conexiones de chismorreo (gossip) ha sido reconocida como una herramienta potencialmente útil, aunque sus limitaciones actuales significan que no es una solución completa para la seguridad de la red. Se recopilará más investigación y aportes de la comunidad para evaluar la viabilidad práctica y la efectividad de implementar dichas características.
Áreas Clave de Enfoque para Operadores
-
DP2 y el Sistema de Eventos: Los operadores de nodos deben prepararse para probar estos componentes a medida que estén disponibles.
-
Adopción del Emparejamiento por Chismorreo (Gossip): Se fomenta la participación continua y la confirmación de un emparejamiento exitoso para construir una red de chismorreo (gossip) más robusta.
-
Comentarios sobre las Características de Seguridad: Proporcionar comentarios sobre el mecanismo propuesto de lista blanca/lista negra y otras preocupaciones de seguridad ayudará a dar forma a futuros desarrollos.
Consideraciones Futuras
-
Robustez de la Red de Chismorreo (Gossip): Abordar los desafíos en el descubrimiento de pares y la estabilidad de la conexión sigue siendo una prioridad.
-
Identidad y Abuso: Desarrollar métodos más efectivos para identificar y mitigar el abuso dentro de la red de chismorreo (gossip) requiere una investigación adicional.
-
Realidades de la Red: Las limitaciones prácticas relacionadas con el enmascaramiento de IP y la infraestructura de red existente deben considerarse cuidadosamente al diseñar nuevas características.
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.