Actualización de EOS Mainnet: la nueva arquitectura de nodo mejora enormemente la confiabilidad de EOS

En nuestro anterior entrada en el blog y más reciente Salsa picante EOS, Echamos un vistazo detrás de escena al trabajo colaborativo que ha estado ocurriendo en las últimas semanas entre Block.one y los productores de bloques clave de EOS Mainnet. Hoy queremos echar un vistazo más técnico a los detalles de los cambios arquitectónicos implementados recientemente por los productores de bloques. 

Solución de problemas

A mediados de enero, EOS Mainnet comenzó a experimentar un volumen mucho mayor de transacciones entrantes, lo que condujo a un aumento posterior en las microformas. La primera hipótesis fue que el alto número de transacciones abrumaba a los nodos de firma (también conocidos como nodos productores). 

Los productores de bloques clave primero intentaron aumentar la velocidad de la CPU en los nodos de firma para compensar el gran volumen de transacciones, lo que ayudó, pero no solucionó el problema. Los nodos de firma ahora producían bloques más grandes, pero aún se sobrecargaban al intentar procesar las transacciones entrantes. Además, los bloques eran demasiado lentos para propagarse al siguiente productor de bloques y las microformas permanecían demasiado altas.

Después de una investigación significativa, Block.one y los productores de bloques clave identificaron la fuente del problema: la gran cantidad de transacciones que golpeaban el nodo de firma desde múltiples conexiones significaba que el nodo no podía funcionar de manera eficiente. La solución requirió una reducción en el número de conexiones en el nodo de firma. En definitiva, eso significaba tener solo 2 conexiones.

Este es un cambio significativo ya que los productores de bloques podrían haber tenido múltiples conexiones al clúster P2P público, múltiples conexiones a nodos API y otras conexiones diferentes. Todos ellos debían ser reemplazados por solo 2 conexiones.

Primera conexión: solo bloques

Los productores de bloques se organizaron para crear una red P2P de 'solo bloques' para entregar rápidamente bloques entre ellos. Permitir que los productores de bloques ignoren las transacciones significa una carga de procesamiento reducida, y cuando los bloques llegan a tiempo, las microformas no suceden.

Por lo tanto, un bloque recién producido debe ir del productor 1 -> bloque par 1 -> bloque par 2 -> productor 2.

Para que esto funcione correctamente, se necesitaron algunos cambios en EOSIO desde Block.one:

  1. Capacidad para establecer conexiones bidireccionales solo con bloques (agregado solo en EOSIO 2.0.2)
  2. Posibilidad de limitar la CPU utilizada para crear bloques en el nodo de firma (agregado en EOSIO 1.8.11 y 2.0.2).

A medida que estos cambios estuvieron disponibles, los productores de bloques los implementaron rápidamente y les asignaron un valor de esfuerzo de CPU de 50%. Esto redujo drásticamente el número de bloques caídos.

Esta arquitectura funciona muy bien en el momento de la publicación, pero se necesitan algunos ajustes más para reducir aún más los bloques restantes. Para guiar cambios futuros, Block.one escribió una explicación detallada de cómo configurar los ajustes para asegurar que los bloques lleguen a tiempo.

Segunda conexión: transacciones

En esta nueva arquitectura de nodo, los productores de bloques también tuvieron que crear una red de transacciones. Nota: la red de transacciones también incluye bloques.

Todas las transacciones entrantes, sin importar de dónde provengan, deben consolidarse en un solo nodo "igual de transacción" que se conecta al nodo de firma. Este nodo debe manejar tantas transacciones como sea posible, pero tampoco debe abrumar al nodo de firma con demasiadas transacciones para permitir que el nodo de firma continúe produciendo bloques de manera eficiente.

Para manejar el volumen de transacciones entrantes, los productores de bloques pueden desear usar EOSIO 2.0 con EOS-VM habilitado. Sin embargo, el uso de EOS-VM abrumaría un nodo de firma de bloque que ejecuta la versión 1.8. En este caso, se necesita un nodo adicional de "barrera" 1.8 para ralentizar las transacciones y permitir que el nodo de firma funcione de manera eficiente.

Mientras que los productores de bloques estaban optimizando el mecanismo de entrega de solo bloques, la capacidad de procesar transacciones se redujo temporalmente. Esto afectó negativamente a algunos dapps debido a la pérdida de transacciones. Esto ya no debería ser un problema.

Conclusión

Resolver el problema y encontrar una solución fue un esfuerzo muy colaborativo entre Top 21 y Block.one. Esto requirió una gran cantidad de trabajo y coordinación por parte de muchos equipos ubicados en todo el mundo. Por ejemplo, en un momento, varios productores de bloques adyacentes enviaron sus registros a Block.one para que los problemas pudieran rastrearse de un productor de bloques al siguiente. Es normal que algunos equipos estuvieran más involucrados que otros, pero todos los equipos contribuyeron con lo que tenían que hacer. También queremos dar un agradecimiento especial a WhaleEx, que brindó un gran liderazgo al proponer la solución, además de ofrecer mucha ayuda para implementarla.

Como nota final, es importante saber que no todos los productores de bloques tienen exactamente la misma configuración. Las versiones de topología de nodo, velocidad de CPU, carga de transacción y EOSIO tienen alguna variación ya que los diferentes productores de bloques tienen diferentes necesidades y requisitos. EOS Nation continúa trabajando con Block.one para trabajar para tener más de 2 conexiones al nodo de firma de bloque para que funcione con eficiencia y redundancia.

Este resumen debería ser útil para otros productores de bloques en EOS, así como para otros productores de bloques de red EOSIO que quieran crear un diseño similar para evitar la sobrecarga.

Problemas que ayudarían con la resolución de problemas:

Solicitudes de extracción de GitHub EOSIO:

Detalles del diagrama

Aquí están los detalles técnicos de configuración:

  • Nodo Productor
    1.8.xo 2.0.x, wabt, especulativo, porcentaje de esfuerzo de la CPU = 50 - 80
  • Bloques de nodo par
    2.0.x, eos-vm-jit, solo lectura, validación completa
  • Nodo de barrera de transacciones
    1.8.x, wabt, especulativo, validación ligera
  • Nodo par de transacciones
    2.0.x, eos-vm-jit, especulativo, validación completa

EOS Nation es uno de los 21 principales productores de bloques en la red pública de EOS. Ganamos recompensas por inflación en función del porcentaje de fichas apostadas hacia nosotros. Esas recompensas se comparten con los titulares de tokens a través de nuestro Proxy4Nation Reward Proxy y también reinvertido en la comunidad EOSIO, herramientas e infraestructura. Ayude a hacer crecer el ecosistema al apostar su voto a eosnationftw o representando a proxy4nation

2 comentarios en “EOS Mainnet Update: New Node Architecture Greatly Improves EOS Reliability”

  1. Estas actualizaciones para EOSNation son increíbles y me ayudan a creer que mi inversión en EOS está en buenas manos. Sería genial si todos los BP publicaran un informe similar desde cada una de sus perspectivas de forma regular. Uno de los mayores combustibles para FUD en esto es el espacio (aparte de las viejas mentiras) es el silencio. Gracias por su gran trabajo y aliente a otros BP a seguir su ejemplo en excelentes comunicaciones.

    • ¡Gracias por leer y por el maravilloso comentario! En cuanto a otros BP que publican informes similares, no creemos que sea necesario. Nos complace asumir este papel de "comunicador líder" dentro de Top21.

Los comentarios están cerrados.

Daniel Keyes

Director de Operaciones (COO)
Las responsabilidades incluyen: gestión de productos, operaciones, comunidad
Ubicación: Toronto, Canadá

Antes de fundar la primera comunidad de EOS en Toronto y cofundar EOS Nation, Daniel pasó una década en la industria de tecnología financiera desempeñando varios roles diversos. Su amplia experiencia en servicio al cliente, ventas, entrenamiento de ventas, capacitación de agentes, marketing digital, gestión de procesos digitales (magro cinturón verde) y gestión de productos (scrum master certificado, propietario de producto certificado) eventualmente lo llevó a consultar para una tienda de desarrollo blockchain.

Daniel obtuvo una Licenciatura en Periodismo de la Universidad de Ryerson en 2009 y trabajó como pasante productor de persecución en Global TV.

Daniel vive por los principios de Verdad, Amor y Libertad.