Lanzamiento de Shardeum: un logro innovador
Imagen generada por IA
El lunes 27 de enero de 2024 se produjo un acontecimiento innovador en el mundo de web3 que puede compararse con la hazaña histórica de una nave espacial que regresa perfectamente a su plataforma de lanzamiento después de su primera misión de prueba de vuelo. En este escenario extraordinario, Shardeum no solo enfrentó desafíos difíciles sino que también salió victorioso, y la resiliencia de su red marcó la primera vez que una red fragmentada pudo autorrepararse en el ámbito de la tecnología de contabilidad distribuida.
Así como el viaje de una nave espacial implica una planificación cuidadosa, ingeniería de precisión y la ejecución perfecta de maniobras complejas, la restauración de la betanet Sphinx de Shardeum, que había sufrido una caída crítica, requirió un nivel igual de dominio tecnológico e innovación. La capacidad de conservar todos los datos en una red, especialmente una que opera mediante fragmentación de estado dinámico, es innovadora.
Al embarcarnos en esta exploración, no solo celebramos el aterrizaje histórico de Shardeum, sino que también lo reconocemos como un momento decisivo en la evolución de la tecnología web3, un salto que podría redefinir los límites de la resiliencia de la red de TI y la integridad de los datos.
La primera Shard Network que recupera y retiene datos de forma independiente
Mantener y restaurar dinámicamente una red fragmentada, como Shardeum, incluye un espectro de desafíos técnicos complejos que la diferencian de las redes blockchain tradicionales como Bitcoin o Ethereum. En un entorno de fragmentos expresado dinámicamente con escalado automático, la reasignación continua y el equilibrio de nodos y recursos entre diferentes fragmentos son fundamentales para optimizar el rendimiento y la escalabilidad. Estos cambios constantes en la arquitectura de la red añaden una complejidad significativa a la hora de mantener la coherencia de los datos, garantizar la estabilidad de la red y facilitar la recuperación eficaz de fallos.
La importancia de este desafío se enfatiza al comparar la respuesta de Shardeum a las fluctuaciones de los nodos con Bitcoin. La red Bitcoin mantiene la funcionalidad incluso con una pequeña cantidad de nodos, ya que cada nodo activo tiene un estado completo y un historial de transacciones. Por el contrario, cada nodo activo en Shardeum no tiene un estado completo ni un historial de transacciones, debido a la red de fragmentos de Shardeum, y cada validador solo tiene una parte del estado general. La consecuencia de esta fragmentación es que todos los nodos validadores se vuelven muy livianos. Por lo tanto, esto crea una multitud de oportunidades y desafíos de ingeniería. Si un nodo deja de funcionar, ¿cómo nos aseguramos de que se mantengan todos los datos? Shardeum tiene dos formas principales.
Primero, Shardeum utiliza fragmentación de estado dinámico, donde todo el espacio de direcciones se particiona (o divide) según la cantidad de nodos activos. Cada nodo es responsable de su partición asignada, junto con un cierto radio (R) a su alrededor y particiones adicionales (E) adyacentes a él, lo que garantiza una adaptabilidad dinámica y una sólida redundancia de datos dentro del marco de la red. Por lo tanto, incluso si un nodo cae, todavía hay continuidad de la red y no se pierden datos.
En segundo lugar, Shardeum utiliza nodos de archivo para almacenar el estado completo de toda la red. Esto se logra mediante nodos activos que transmiten el estado parcialmente almacenado al archivador para su recopilación. Debido a estos dos factores y a la optimización del diseño, la recuperación de dichas redes debe diseñarse de nuevas maneras para seguir facilitando características beneficiosas como el escalado automático y el escalado lineal.
Comprender las fallas
Ahora que entendemos los conceptos básicos de la fragmentación de estado dinámico y que los nodos archivadores están involucrados de alguna manera, analicemos algunos de los componentes adicionales con más profundidad y los expliquemos. Para comprender el bloqueo y la recuperación de Shardeum betanet, primero debemos comprender un poco sobre lo siguiente:
Nodo archivador
Detectar archivadores faltantes
Modo de red
Modo de recuperación
Comprender los conceptos básicos de cada uno de estos es importante antes de profundizar en los errores involucrados, ¡así que echemos un vistazo!
Nodo de archivo: almacenamiento interestelar
En Shardeum, los nodos archivadores, también llamados archivadores, constituyen una categoría muy importante de nodos, cuya tarea es almacenar todo el estado y los registros históricos de la red. A diferencia de los nodos activos, los archivadores no participan en el proceso de consenso; Su función principal es archivar de forma integral todos los datos de la red, incluidas las transacciones y los recibos. La contribución del nodo archivador es fundamental para mantener la integridad de la red y garantizar que sus operaciones funcionen sin problemas, confirmando así el estatus de Shardeum como una red fuerte, completa y confiable. Debido a que los archivadores son una parte integral de su red, Shardeum debe contar con protocolos implementados para detectar archivadores (y validadores) que no responden.
Detección de archivos perdidos: tecnología alienígena revelada
Shardeum tiene un protocolo llamado protocolo de detección de nodos perdidos que detecta cuando un nodo activo deja de funcionar — esto solo está destinado a nodos activos. Sin embargo, Shardeum también tiene un protocolo para archivadores que hace algo similar llamado detección de archivadores faltantes. La detección de archivadores faltantes es un protocolo especial diseñado para manejar el raro escenario en el que uno o más archivadores dejan de funcionar y se marcan como faltantes. Dado que los nodos de archivo son fundamentales para mantener la integridad y accesibilidad de los datos históricos en la red, es fundamental que, en caso de que dejen de responder o funcionen mal, estos eventos críticos puedan capturarse para mitigar los efectos posteriores. Aunque la falta de un archivador no causa este bloqueo en particular, la interacción entre el protocolo de detección del archivador faltante y el modo de red en particular sí lo causa. Ahora veamos qué modos de red hay en Shardeum.
Modo de red en Shardeum: no se requiere NASA
La innovación emblemática en Shardeum respaldada por el protocolo Shardus subyacente es el marco del modo de red. Estos modos van más allá de las condiciones operativas básicas y permiten una coordinación compleja de diversas actividades de nodos, métodos de sincronización de datos y sistemas de gestión de transacciones. Dicha configuración de red juega un papel importante en el mantenimiento de la integridad operativa de la red, especialmente en escenarios caracterizados por la pérdida de nodos y datos, ya que Shardeum es una red de fragmentos.
En un nivel más simple, la mejor manera de entender el modo de red en Shardeum es como un plan de contingencia bien codificado que permita la continuidad de las operaciones para toda la red, incluso en condiciones improbables como fallas de la red o degradación en toda la red. Esta resiliencia operativa preprogramada garantiza que Shardeum siempre estará vivo, sin importar las dificultades que enfrente la red.
Si bien comprender los errores no requiere comprender todos los aspectos del marco del modo de red, es útil conocer los conceptos básicos. La esencia del marco del modo de red es la incorporación de varias fases de red diferentes: establecimiento, procesamiento, seguridad, recuperación, reinicio, recuperación e interrupción. Estos modos están cuidadosamente diseñados para abordar diversas situaciones y emergencias de la red. Sin embargo, el modo que nos ocupa en este artículo es el modo de recuperación.
Imágenes generadas por IA
Modo de recuperación de ingeniería inversa: Rosewell revisitado
El modo de recuperación es 1 de los 7 modos de red mencionados anteriormente. El modo de recuperación se inicia cuando la cantidad de nodos activos de la red cae por debajo de un umbral crítico predeterminado (actualmente configurado en 75% o menos). Este umbral se puede ajustar según los requisitos de la red. En este modo, la red detiene el procesamiento de transacciones de aplicaciones y la sincronización de datos de aplicaciones. Esta estrategia está diseñada para facilitar la expansión de la red al realizar ciclos sin problemas de nodos inactivos como parte de la rotación de nodos, devolviendo así la cantidad de nodos activos a niveles óptimos, idealmente por encima del 100%.
Durante el modo de recuperación, la arquitectura de red de Shardeum permite actualizaciones graduales de los nodos, limitadas a un crecimiento del 20 % por ciclo (cada ciclo dura aproximadamente 60 segundos). Esta tasa de crecimiento controlada es fundamental para mantener la estabilidad de la red y garantizar una integración fluida de nuevos nodos. Un aumento rápido en el número de nodos, como un aumento del 50%, tiene el potencial de desestabilizar la red y complicar el proceso de integración.
Cada nodo recién agregado requiere recursos de red para su sincronización e integración. Al limitar las actualizaciones al 20 % por ciclo, la red garantiza que su infraestructura pueda soportar adecuadamente la adición de nuevos nodos sin tensión. Este enfoque no solo mantiene la estabilidad de la red sino que también minimiza el riesgo de inconsistencias o errores de datos durante el proceso de sincronización, manteniendo así la integridad de los datos de la cadena del ciclo.
Causas fundamentales de las fallas: horizonte de eventos
Es importante tener en cuenta que existen dos errores diferentes. Error en la biblioteca de neón — que provocó que los validadores fallaran aleatoriamente y un error en el protocolo de detección del archivador faltante — que no aceptaba una lista de validadores vacía. Aunque es el error del protocolo de detección del archivador faltante el que causa que la versión actual de Betanet falle, me gustaría invitarlo a discutir primero el error de la biblioteca de neón.
En la versión 1.9.1 de Sphinx, integramos una actualización de la biblioteca que utiliza la carpeta Neon para vincular funciones de Rust y TypeScript porque Shardeum está construido principalmente en TypeScript. Neon es conocido por su enfoque innovador, aunque experimental, que a menudo traspasa los límites de las prácticas convencionales de desarrollo de software. Esta integración tiene como objetivo mejorar la interoperabilidad entre estos dos lenguajes, permitiendo una comunicación más eficiente y directa dentro de nuestra arquitectura de software. Sin embargo, esto provoca un error que hace que los nodos se abandonen aleatoriamente de la red.
En segundo lugar, en el reciente incidente que provocó una caída de betanet en Shardeum, la causa raíz se identificó como una anomalía crítica originada en la interacción entre los dos subsistemas diferentes mencionados anteriormente: el mecanismo de detección del archivador faltante y el protocolo del modo de recuperación de red.
Esta breve caída fue provocada por la activación simultánea de estos dos mecanismos, un escenario nunca antes encontrado ni probado. El proceso de archivo perdido se activa junto con el modo de restauración de red y debido a un error en el modo de archivo perdido que no acepta una lista vacía de nodos activos. Esto provoca una caída de la red.
Crónicas de recuperación: del shock sistémico al despertar estelar
Entonces, ¿qué pasó realmente y cuándo? Una cronología de los eventos que rodearon la caída de la red y su resolución es la siguiente:
Vulnerabilidades y actualización inicial: la red tiene una vulnerabilidad señalada por el proceso de linting 1.9.1 en la biblioteca npm (neón). Se ha implementado una mejora para abordar este problema. Sin embargo, esta mejora generó inadvertidamente una excepción que no se reprodujo durante las pruebas locales.
Excepciones intermitentes de la biblioteca que provocan interrupciones del validador: la biblioteca, neón, experimenta excepciones esporádicas que provocan interrupciones periódicas del validador de la red. Aunque el diseño de la red permite la resiliencia mediante la recarga de estos validadores, desafortunadamente los tiempos de falla simultáneos entre múltiples validadores activan el modo de recuperación de la red.
Activación del modo de recuperación de red: una vez en el modo de recuperación de red, el protocolo debe purgar y recrear la lista de nodos activos. Un error simultáneo en el sistema de archivo faltante, que no daba cabida a una lista de validadores vacía, fue la causa principal del fallo de la red.
Resolución y recuperación de la red: se solucionó el problema y la red se restauró exitosamente utilizando los datos almacenados en el archivador. Esta es la primera vez en la historia que una red de fragmentos de Capa 1 colapsada se recuperó con éxito y todos los datos de la red se conservaron intactos. Esto nunca se ha hecho en ninguna red, y mucho menos en una red con fragmentación de estado dinámico. Este logro marca un “aterrizaje de cohete” exitoso en términos de recuperación de la red.
Correcciones completadas: se implementaron correcciones iniciales para abordar los problemas de la biblioteca, pero en un esfuerzo continuo por mejorar la estabilidad de la red, se lanzó la versión 1.9.5. Esta actualización presenta una solución de error única pero importante que aborda otro caso de falla del enlace de neón, identificando y solucionando la vulnerabilidad específica sin requerir una actualización en toda la red. Inicialmente, los usuarios que operan con la versión 1.9.4 tienen la flexibilidad de permanecer en la versión actual o elegir actualizar a la 1.9.5, según su evaluación del rendimiento de la red y sus preferencias de estabilidad. Sin embargo, finalmente se decidió que, con el fin de mejorar la estabilidad de la red y abordar los problemas persistentes relacionados con el enlace de neón, la versión mínima requerida para el validador debería aumentarse a 1.9.5. Esta actualización tiene como objetivo excluir sistemáticamente los validadores que se ejecutan en la versión 1.9.4, que han sido identificados como vulnerables a fallas debido a las complicaciones de vinculación de neón antes mencionadas. Esto es necesario para garantizar que el error de neón se haya eliminado y reparado por completo.
Ahora que conocemos la línea de tiempo y cómo sucedieron los eventos más importantes, echemos un vistazo a lo que sucedió para que la red pueda restaurarse rápidamente.
Elevándose hacia la recuperación
Recuperación ágil
La recuperación de la red consta de muchas partes, pero una de las principales es el modo de recuperación Shardeum. Como se indicó anteriormente, el modo de recuperación se inicia cuando la cantidad de nodos activos de la red cae por debajo de un umbral crítico predeterminado y permite un crecimiento rápido, controlado y efectivo de la red de una manera segura para restaurar la red. Es importante enfatizar que sin el ingenio tecnológico de los diseñadores y desarrolladores del modo de red, Shardeum no habría podido recuperarse del colapso tan fácilmente y tampoco habría demostrado su destreza innovadora.
Además, el equipo de tecnología de Shardeum realizó importantes esfuerzos al lanzar medidas inmediatas. El paso inicial implicó un análisis exhaustivo para identificar la causa raíz del bloqueo, que se debió a una anomalía en la interacción entre la detección de archivos faltantes de la red y su sistema de modo de recuperación. Al comprender la complejidad del problema, el equipo implementó rápidamente un enfoque multifacético para abordar los impactos inmediatos y las vulnerabilidades subyacentes.
Respuesta mixta del equipo de tecnología de Shardeum
Técnicamente, la respuesta fue mixta: primero, el equipo aisló los componentes afectados para evitar una mayor degradación del tejido. Al mismo tiempo, aplicaron un parche para corregir un error en el sistema de archivo faltante, asegurando que pudiera manejar una lista de validadores vacía, un error crítico que desencadenó la falla de la red. Para restaurar la red a su capacidad operativa total, los datos almacenados en el archivo se activan y se utilizan para reconstruir la condición de la red antes del accidente, asegurando que no se pierdan datos en el proceso.
Logísticamente, el equipo coordina zonas horarias y disciplinas, aprovechando herramientas basadas en la nube para colaboración y monitoreo en tiempo real. Este esfuerzo coordinado no solo facilita el rápido desarrollo e implementación de correcciones, sino que también garantiza que todos los miembros del equipo estén alineados con el proceso de recuperación y los próximos pasos.
Este incidente sirvió como una prueba rigurosa de los protocolos de gestión de accidentes de Shardeum y destacó la importancia de respuestas ágiles e innovadoras a desafíos inesperados. Esto subraya el compromiso del equipo de mantener una red resistente y segura, lista para superar obstáculos técnicos complejos a medida que surjan.
Innovaciones en aterrizajes seguros y con destino al espacio
En conclusión, la recuperación exitosa de la red Shardeum shard marca un cambio significativo en la tecnología de la red, lo que marca un hito con implicaciones de gran alcance para la industria. Si bien actualmente son poco conocidas, innovaciones como el modo de red eventualmente establecerán nuevos estándares de la industria en web3.
Durante mucho tiempo he creído que es muy probable que las principales innovaciones de Shardeum influyan en futuros desarrollos tecnológicos, inspirando innovación y una nueva generación de tecnología de contabilidad. Habiendo sido testigo de primera mano de la primera recuperación de la red Shardeum, sabía que esto sería un catalizador para reevaluar los estándares de la industria, lo que podría conducir a la adopción de protocolos y metodologías más estrictos en el diseño y la arquitectura de la red.
Este evento no solo mostró la destreza técnica y la innovación del equipo de Shardeum, sino que también marcó el comienzo de una era en la que las redes descentralizadas se vuelven más robustas, adaptables y capaces de manejar desafíos imprevistos cuando se trata de planificación de recuperación ante desastres. En última instancia, la tecnología Shardeum presagiará una nueva era de descentralización.
