Cryptocom Chain Crossfire Mainnet Dry-Run fue una red de prueba incentivada destinada a realizar pruebas de estrés en la red en un entorno práctico y del mundo real antes del lanzamiento público. Es un hito importante y el paso final en la preparación para el lanzamiento de Mainnet.
La prueba duró 4 semanas entre el 18 de enero y el 15 de febrero de 2021. Fue un gran éxito para el equipo de Crypto.com Chain, ya que logró sus objetivos y nos brindó una valiosa experiencia y la oportunidad de probar diferentes cosas bajo una red estresada. . El ensayo sacó a la luz algunos problemas esperados, así como áreas de mejora recientemente identificadas. Estas lecciones nos ayudarán en nuestra preparación para el lanzamiento de Mainnet.
¿Cuáles fueron las tareas en Crossfire?
Crossfire se dividió en tres fases:
- Fase uno (semana 1): los participantes configuran sus nodos y se preparan;
- Fase dos (semana 2 y 3): los validadores deben mantener una tasa de firma del 50%;
- Fase tres (semana 4): la fase de ataque, donde se anima a los participantes a lanzar un ataque en la red y otros validadores mientras mantienen el tiempo de actividad lo más alto posible.
A lo largo de la competencia, los participantes también fueron calificados según la realización de diferentes tareas, el número total de transacciones enviadas y la tasa de firma de su validador. Los 10 mejores participantes con la puntuación más alta obtienen recompensas adicionales.
Estadísticas
El equipo recibió 1000 registros en los primeros 3 días después del anuncio del ensayo. En total, recibimos 3.342 registros, incluidos los de los partidarios de Crypto.com desde hace mucho tiempo y los entusiastas de blockchain con sólida experiencia en la configuración de nodos de validación en otras blockchains.
Para simular un número más realista de validadores simultáneos en una red, decidimos albergar solo 220 participantes para este evento. Nos gustaría aprovechar esta oportunidad para expresar nuestro agradecimiento por el abrumador apoyo de la comunidad.
Entre los 206 participantes que respondieron, 197 de ellos se han unido a la red y han completado al menos una de las tareas. 174 participantes completaron al menos 2, 158 participantes completaron al menos 3 y 124 participantes completaron todos.
Al final del evento Crossfire, se propusieron 180 mil bloques y se transmitieron 275 millones de transacciones a la red en solo 4 semanas, creando un entorno altamente estresado que nunca antes habíamos visto. En el momento pico, hubo más de 180 validadores de todo el mundo, logrando consenso juntos en la red.
Una cosa a tener en cuenta es que, aunque Crossfire está posicionado como Mainnet Dry-Run, las tareas que configuramos y el tráfico real que vimos fue un entorno más extremo de lo que esperábamos ver en Mainnet. Uno de los grandes objetivos de cualquier red blockchain es la tolerancia a fallas en condiciones adversas, y nos complace decir que Crossfire ha logrado este objetivo. Vimos la degradación de la red, pero trabajamos con los participantes del validador para mantener la cadena de bloques en funcionamiento y, finalmente, sobrevivimos a las condiciones extremas.
Con este tráfico extremadamente activo, pudimos recopilar datos que antes eran difíciles de configurar. También observamos y monitoreamos de cerca el comportamiento de la red. Algunos problemas requirieron que nuestro equipo actuara con prontitud, que trataremos más adelante.
Mainnet Dry-Run no solo nos ayudó a estar preparados para Mainnet, también descubrimos algunos problemas que podrían ayudar a que Tendermint y Cosmos SDK (en el que se construyó la cadena) fueran mejores y más seguros durante este proceso.
Cómo Crypto.com ayudó a proteger Stargate
Stargate es la actualización más grande del ecosistema Tendermint Core y Cosmos SDK hasta el momento. Ha traído mejoras de rendimiento, nuevas características (como State Sync, que permite que los nuevos nodos obtengan el último estado de la cadena de bloques en segundos en lugar de sincronizarse durante horas o días) y desbloquea todo el nuevo mundo de oportunidades a través de la interoperabilidad de cadenas de bloques autónomas. a través del protocolo Inter-Blockchain Communication (IBC). Puede leer más sobre este enorme esfuerzo de desarrollo colaborativo en este artículo..
Crypto.com Chain ha utilizado Cosmos SDK desde los primeros candidatos de Stargate y se ha mantenido al día con su desarrollo. Al igual que con cualquier gran revisión de desarrollo de software, Stargate ha experimentado dolores de crecimiento iniciales y Crypto.com ayudó de diferentes maneras a fortalecer las pilas de software Tendermint Core y Cosmos SDK.
Primero, durante las rondas de pruebas internas, el equipo de seguridad de Crypto.com descubrió vulnerabilidades de denegación de servicio en Tendermint Core. Tras el proceso de divulgación responsable, comunicamos este problema a los desarrolladores de Tendermint Core y los ayudamos a identificar la causa raíz y probar las soluciones propuestas. Estas vulnerabilidades se han solucionado en las versiones posteriores v0.34.2 y v0.34.3 de Tendermint Core. Puede leer más detalles en esta retrospectiva reportaje .
En segundo lugar, identificamos varios problemas en Cosmos SDK, que habíamos notificado a los mantenedores principales o contribuido con nuestros parches. Además de eso, también cofinanciamos una auditoría de seguridad de varios módulos críticos de Cosmos SDK. Dependiendo de los hallazgos de la auditoría, sus respectivas correcciones se incorporarán en las próximas versiones de Cosmos SDK.
Cuando comenzó la competencia, estábamos evaluando las vulnerabilidades, lo que llevó a un parche de seguridad urgente en la red Crossfire durante la competencia. Para obtener más detalles, consulte la sección » Parche de seguridad aplicado en acción » a continuación.
Finalmente, varios participantes de Crossfire informaron un mayor uso de RAM durante algunos de los períodos de prueba de estrés. Ayudamos al equipo de Tendermint Core a investigar la causa raíz de este problema. Ahora se ha corregido ( https://github.com/tendermint/tendermint/pull/6068 ) y se incorporó en la versión 0.34.4.
Para obtener más detalles sobre el descubrimiento del uso de memoria, consulte la sección «Requisitos de red y hardware revisados después de las pruebas de esfuerzo» a continuación.
En términos de la próxima versión importante (v0.35), el equipo de Tendermint Core se está enfocando en algunos de los problemas relacionados con P2P y mempool de larga data.
Lo que hemos aprendido
Rendimiento mejorado del explorador de bloques con optimización de la base de datos
La competencia tuvo una carga alta, lo que podría ayudarnos a identificar las ineficiencias del explorador de bloques y mejorar mediante la optimización de la base de datos.
El primer desafío de prueba de estrés que observamos está en nuestro explorador de bloques . Hemos estado utilizando nuestro propio servicio de indexación para impulsar los datos del explorador de bloques y el tablero de Crossfire . Cuando comenzó la red de prueba y los participantes comenzaron a ejecutar su herramienta de spam de transacciones, observamos que la página de inicio se cargaba más lento de lo normal. Después de la investigación, nos dimos cuenta de que estamos usando algunas consultas SQL no optimizadas en nuestra página principal.
Una vez que identificamos el problema, volvimos a visitar las consultas SQL utilizadas en la indexación y creamos índices de base de datos para las que se utilizan con más frecuencia.
Con el índice de la base de datos en su lugar, redujimos con éxito la latencia de unos pocos cientos de milisegundos a milisegundos de un solo dígito, pero aún era insuficiente debido al alto tráfico. Por lo tanto, implementamos más mejoras:
- Base de código de índice modificado para realizar la inserción de bases de datos por lotes
- Mejoramos nuestro hardware de base de datos de indexación y Postgres
- Separó la base de datos en un maestro de escritura y una réplica de lectura, con una máquina dedicada para servir API con una réplica de lectura
Finalmente, tenemos un explorador de bloques más saludable. Estas mejoras se aplicarán en el lanzamiento de Mainnet.
Problemas solucionados de tiempo de espera de Block Explorer y Tendermint debido a bloques
grandes El «ataque» de bloque grande durante la semana 4 reveló un problema potencial: el tiempo de espera HTTP predeterminado era demasiado corto. Como resultado, revisamos la configuración de tiempo de espera del servicio de indexación y Tendermint, sin dejar de poder proteger el servidor del ataque de slowloris.
Otro desafío observado fue que el gran tamaño del bloque provocó un tiempo de respuesta HTTP prolongado. Algunos participantes estaban enviando transacciones muy grandes, y estos grandes bloques tardaron mucho más en devolverse en la llamada a la API HTTP.
Por razones de seguridad, es una buena práctica restringir el tiempo de espera de la conexión del cliente y del servidor HTTP para evitar un ataque de slowloris . Nuestro servicio de indexación y Tendermint adoptaron esta medida y utilizan un tiempo de espera de 10 segundos. Sin embargo, 10s no es suficiente para estos bloques grandes.
Identificamos la causa de este problema en la sincronización de informes de nuestro sistema de monitoreo de indexación. Intentamos solicitar la API de resultados de bloque y la respuesta se cortó a la mitad. Cuando solicitamos programáticamente con curl, vimos que el error de la secuencia no se cerró limpiamente. Todos estos eran signos de que WriteTimeout estaba en marcha.
Para solucionar este problema, tuvimos que extender el tiempo de espera mientras protegíamos el servidor del ataque de slowloris. Se aplicaron las siguientes configuraciones:
- Para el servicio de indexación, ampliamos solo el tiempo de espera del cliente HTTP a Tendermint
- Para el servidor Tendermint, no había una configuración dedicada para el tiempo de espera HTTP. Después de estudiar su registro de cambios , nos dimos cuenta de que «rpc.timeout_broadcast_tx_commit» controla el tiempo de espera en la API de transmisión de transacciones. Dado que Golang no tiene un control detallado del tiempo de espera HTTP en diferentes rutas API, el tiempo de espera de escritura del servidor HTTP general se especifica mediante la fórmula «MAX (10s, rpc.timeout_broadcast_tx_commit)».
- También configuramos un nodo completo privado y dedicado para brindar servicio de indexación. Esto garantiza que los clientes de confianza accedan a él y podría proporcionar beneficios adicionales de aumento de rendimiento para la indexación.
Parche de seguridad aplicado en acción
La vulnerabilidad de evidencia de Tendermint nos permitió coordinar un parche de seguridad urgente con los 200 participantes en acción, lo cual es una experiencia valiosa para nosotros.
Cuando lanzamos la prueba de ejecución de mainnet, el parche para la vulnerabilidad de evidencia de Tendermint todavía estaba siendo evaluado, por lo que decidimos usar primero la versión sin parche. Durante las dos primeras semanas de Crossfire, comenzamos a ver algunas pruebas propagadas en la red, lo que sugería que el problema podría haberse aprovechado. Nos enfrentamos a dos opciones: podíamos aplicar el parche inmediatamente o esperar hasta la actualización de la red programada al final de la semana 3.
Tomamos una decisión rápida para aplicar el parche de inmediato porque este exploit se clasificó como un parche de seguridad severo, queríamos ver el parche en acción para hacer que la red sea más eficiente. Por lo tanto, el parche se lanzó el 25 de enero, y las instrucciones se anunciaron el 26 de enero.
Aquí, nos gustaría enfatizar la importancia de proporcionar el contacto de seguridad cuando configura un validador. Esta vez utilizamos una combinación de correo electrónico de registro y contacto de seguridad para notificar a los operadores de validación de las actualizaciones. Cuando se lance Mainnet, el contacto de seguridad de un validador será una forma importante para que podamos contactar a los validadores sobre los parches de seguridad.
Comprensión de la relación entre los parámetros de la red
Otra lección que hemos aprendido es la importancia de equilibrar diferentes parámetros. En la competencia, tuvimos la oportunidad de observar cómo los parámetros se afectan entre sí en la práctica. Esto puede ayudarnos a decidir los parámetros en Mainnet.
Crypto.com Chain se basa en Tendermint, que utiliza el algoritmo de consenso Practical Byzantine Fault Tolerance (PBFT). La cadena de bloques es segura siempre que menos de ⅓ de los validadores sean defectuosos. Esta es una propiedad estricta para que la cadena sea segura.
Sin embargo, cuando tenemos un total de 200 validadores y un tiempo de bloqueo esperado de 5 segundos, tenemos que decidir cuidadosamente qué parámetros debemos usar para asegurarnos de que los validadores no sean defectuosos. Cuando decimos que un validador está defectuoso, no necesariamente significa que los nodos están tratando de engañar a otros validadores, también podría referirse a la capacidad del nodo para enviar y propagar los votos durante las rondas de consenso debido a problemas como la velocidad de la red.
En el ensayo de mainnet, observamos y, a veces, modificamos deliberadamente el equilibrio entre los diferentes parámetros. El spam de transacciones por parte de los participantes era inevitable para el cumplimiento de sus tareas, por lo que en cualquier momento la red se inundó con transacciones válidas e inválidas. El tráfico de transacciones había creado presión y vimos que el algoritmo de consenso estaba tomando múltiples rondas de intercambio de votos antes de que se pudiera proponer un bloque.
Cuando aumentamos el tamaño del grupo de memoria de transacciones de 5k a 20K, vimos que el proceso de consenso estaba tomando aún más rondas, porque los bloques más grandes y el mayor número de transacciones necesitaban más tiempo para propagarse y están congestionando la red, exigiendo los validadores con una red más alta. ancho de banda y potencia de cálculo.
Al final del día, entendimos la importancia de los diferentes parámetros, y esta es una buena práctica que puede ayudarnos a decidir los parámetros para mainnet.
Configure el nodo en una ubicación geográfica diversa para una mejor cobertura de la red
Antes del ensayo, configuramos los nodos principalmente en una sola región. Sin embargo, durante la competencia, recibimos comentarios de algunos de los participantes, ya que tenían dificultades para conectarse y sincronizarse. Sospechamos que estaba relacionado con la ubicación de nuestros nodos semilla.
Nuestros validadores y nodos de semillas se establecieron inicialmente en Singapur. Para averiguar si la ubicación del nodo era la causa principal, realizamos una encuesta en Discord y observamos que los validadores ubicados en Europa experimentaron una alta latencia.
Después de probar la teoría, creamos dos nodos semilla públicos más en las regiones de Europa y EE. UU. Y los compartimos con la comunidad. Luego, hemos visto mejoras en la latencia y la sucesión de sincronización.
Requisitos de red y hardware revisados después de las pruebas de estrés
Gracias a la alta carga de la red, ahora comprendemos los requisitos de hardware óptimos para ejecutar nodos de manera confiable en diferentes circunstancias.
En nuestra experiencia anterior ejecutando la red de prueba Croeseid, ejecutamos nuestros validadores con 2 vCPU y 16 GB de RAM y no encontramos ningún problema.
Para ser más cautelosos, configuramos nuestros validadores en Crossfire con hardware un poco más fuerte que los utilizados en Croeseid. Sin embargo, cuando más de cien validadores se unieron y los participantes enviaron spam a la red, vimos que nuestros validadores experimentaron una degradación del rendimiento con un alto uso de CPU, memoria y ancho de banda de red que nunca antes habíamos visto.
Después de la investigación, parece que
- Los requisitos de hardware recomendados existentes (2 vCPU, 16 GB de RAM) no pudieron procesar una gran cantidad de transacciones en la red de manera muy confiable
- También hubo signos de pérdida de memoria como se observó en nuestro panel de control.
- Algunos de los participantes también informaron problemas de memoria similares en Discord. Más tarde, ayudamos al equipo de Tendermint Core a resolver este problema.
Ahora hemos revisado los requisitos de hardware recomendados para asegurarnos de que los nodos puedan funcionar como se espera en diferentes circunstancias.
La configuración de nodo subóptima no se recomienda a largo plazo
En la competencia, descubrimos que algunos de los participantes se ejecutan con una configuración de nodo subóptima. Si bien apreciamos la diversidad de configuraciones de nodos, por el mejor interés de la seguridad de la red y el riesgo potencial de perder los fondos apostados, recomendamos ejecutar un nodo con mejor hardware o considerar usar un proveedor de infraestructura confiable como Bison Trail, o delegar su fondos a validadores robustos.
La prueba de ejecución de Crossfire Mainnet no solo fue una oportunidad para que el equipo de Crypto.com Chain aprendiera, sino que también tenía como objetivo que el público probara diferentes opciones de implementación y ejecutara un validador en acción. Apreciamos la diversidad de configuración de nodos que hemos visto en la competencia. Los nodos se configuraron en diferentes regiones en diferentes hardware y se ejecutaron en proveedores de nube, centros de datos, oficinas y hogares.
Por otro lado, de la encuesta que realizamos anteriormente, observamos que algunos de los participantes estaban usando configuraciones subóptimas de nodos de validación. Si bien apreciamos la diversidad de configuración que refleja la descentralización, uno de los objetivos de Crossfire Mainnet Dry-run es recomendar y educar a todos para que tengan una configuración de nodo segura y confiable. Esto es importante porque cuando ejecute sus validadores en Mainnet, estará apostando dinero real, por lo que querrá minimizar el riesgo de que sus fondos se reduzcan drásticamente debido a la falla del nodo.
Si está interesado en ejecutar un validador en Mainnet, generalmente le recomendamos que lo ejecute con una máquina con la siguiente configuración:
- al menos 4 núcleos de CPU;
- 32 GB de RAM;
- servicio de gestión de claves para asegurar su clave privada (por ejemplo, Tendermint KMS );
- conexión de red confiable, con un mínimo de conexión dedicada de 200 Mb / s (es decir, banda ancha doméstica no compartida);
- fuente de alimentación confiable: si está funcionando en casa, considere tener una fuente de alimentación ininterrumpida (UPS);
- asegurar una alta disponibilidad;
- siga la lista de verificación de seguridad preparada por el equipo de seguridad de Crypto.com
Si está interesado en participar como validador en Mainnet, pero no puede cumplir con la infraestructura y los requisitos operativos, Crypto.com ha contratado a Bison Trails para proporcionar una infraestructura de nodo validador confiable para Crypto.com Chain Testnet y Mainnet.
Por otro lado, también puede considerar delegar su CRO a validadores confiables en Mainnet para ganar las recompensas.
¿Que sigue?
En el futuro, aplicaremos las lecciones que aprendimos de Crossfire a la configuración de Mainnet, y prepararemos nuestra preparación final para Mainnet. Estamos resumiendo nuestros aprendizajes y enriqueciendo la documentación de nuestra cadena para que pueda servir como un portal de todos los recursos educativos para futuros desarrolladores y validadores.
Si está interesado en convertirse en un validador en mainnet, le recomendamos que participe en nuestro Croeseid Testnet para que pueda obtener acceso temprano a las funciones de la cadena y estar preparado para Mainnet. La documentación de nuestra cadena puede ayudarlo a comenzar. También te recomendamos que te unas a nuestro Discord para obtener las últimas actualizaciones.
Mas informacion de Crypto.com
