Descubra cómo Shardeum está redefiniendo la resiliencia de blockchain con su Modo de Seguridad para garantizar el funcionamiento continuo y la seguridad, incluso en…

Promoviendo la innovación y la educación en Web3

En nombre del equipo de ingeniería de Shardeum, estamos encantados de desvelar gradualmente una serie de entradas de blog que revelan los esfuerzos entre bastidores para construir la primera plataforma autoescalable de contratos inteligentes del mundo que escala horizontalmente. A través de estas revelaciones, nuestro objetivo es inspirar tanto a la comunidad como al ecosistema Web3 en general y fomentar futuras innovaciones. Muchas de las características que estamos introduciendo con Shardeum son revolucionarias y establecen nuevos estándares en la tecnología blockchain. Conseguir que Shardeum tenga todas las funcionalidades completas no es sólo tachar elementos de una lista, sino afrontar los mayores retos del sector, hacer que la cadena de bloques sea accesible y asequible, y generalizar su uso. Permanezca atento, no querrá perderse estas actualizaciones.

En esta entrada del blog, nos centraremos en uno de los últimos avances de Shardeum, ya que hemos completado la implementación de los modos de red, especialmente el “Modo Seguridad” a finales de 2023. Al igual que una respuesta inmune biológica, el modo de seguridad garantiza que las transacciones de las aplicaciones se puedan pausar temporalmente si surgen condiciones de red subóptimas y que Shardeum continúe prosperando y palpitando con vida, procesando transacciones y sincronizando datos mientras tengamos nodos activos. Este hito marca otro paso significativo en nuestro viaje para llevar la descentralización a las masas, subrayando la tecnología avanzada y la preparación minuciosa que lo hacen posible.

Recientemente publicamos un artículo sobre los modos de red, centrándonos en el "Modo Recuperación", que permitió a Shardeum superar fácilmente una importante caída de la betanet, convirtiéndola en la primera red blockchain fragmentada en autorrestaurar todos sus datos. ¡Échale un vistazo aquí! https://shardeum.org/blog/shardeum-resilience-restoring-sharded-network/

Entendiendo los Modos de Red en Shardeum

Con esta actualización de Shardeum, los modos de red (de los cuales el modo de seguridad es uno de los principales) se han integrado con éxito en la red Shardus. Los modos de red, en esencia, son los diferentes estados de la red que garantizan colectivamente que la red pueda gestionar su ciclo de vida con eficacia, desde la formación y el funcionamiento a través de posibles crisis e incluso en un modo de recuperación, garantizando así la estabilidad de la red en el caso de que surjan circunstancias de red subóptimas.

Es importante subrayar que, incluso con las ventajas que aportan los modos de red, algunos de ellos, como el modo de reinicio o apagado, puede que nunca lleguen a surgir en Shardeum. Por ejemplo, sería necesario que todos (o casi todos) los validadores se perdieran para activar el modo reinicio. Pero Shardeum tiene modos como el reinicio para prepararse incluso para los escenarios más improbables.

Los siete (¡maravillosos!) modos de red de Shardeum

De forma similar a los semáforos que dirigen el flujo de vehículos, estos modos guían el comportamiento de nuestra red en respuesta al número de validadores activos y otros umbrales clave. Desde un punto de vista técnico, los modos de red de Shardeum están diseñados para responder dinámicamente a las necesidades y condiciones de la red. Guían la forma en que interactúan los validadores, garantizando tanto el rendimiento como la resistencia. Veamos qué significa cada modo para Shardeum:

Formación: Esta fase inicial permite a los nuevos nodos unirse y sincronizar sus datos de estado hasta alcanzar un número mínimo especificado de nodos activos, preparando la red para su fase operativa.

Procesamiento: En este modo, la red está plenamente operativa, procesando transacciones de aplicaciones. Los nodos pueden unirse, salir o ser sustituidos según sea necesario, garantizando la funcionalidad continua de la red. Este es el modo de funcionamiento por defecto en Shardeum.

Seguridad: Se activa cuando se cuestiona la estabilidad operativa de la red. Este modo restringe la actividad a las transacciones de protocolo, deteniendo las transacciones de aplicación para salvaguardar la integridad de la red.

Recuperación: Se inicia cuando el recuento de nodos activos cae por debajo de un determinado umbral. Este modo detiene el procesamiento de transacciones de aplicaciones y la sincronización de datos de aplicaciones. Su objetivo es añadir rápidamente nodos de reserva para restaurar los nodos mínimos necesarios de la red, centrándose en la sincronización de datos de protocolo y la creación de nuevos registros de ciclo.

Reinicio: Este modo se activa cuando es necesario reiniciar la red, a menudo tras un apagado completo o cuando se pierden demasiados nodos. Los nodos se unen a la red sin sincronizar los datos de la aplicación, confiando en los Archivers para obtener la información esencial de la red. El objetivo es alcanzar rápidamente el mínimo de nodos necesarios para pasar al modo de restauración.

Restauración: Los nodos se centran en sincronizar los datos de estado de los Archivadores y otros nodos para pasar a estar activos. Este modo es fundamental para pasar de un estado de recuperación o reinicio a plenamente operativo, garantizando que todos los nodos estén sincronizados y activos.

Apagado: Este modo final puede activarse por una acción administrativa o una caída significativa de los nodos activos. Detiene todas las transacciones y prepara a los nodos para salir de la red, garantizando que los Archiver tengan un registro del cierre para posibles reinicios futuros de la red.

Cada modo tiene su momento y su lugar, incluso en caso de que las condiciones de la red no sean óptimas, y los modos en su conjunto garantizan que la red sea resistente, fuerte y pueda seguir siempre viva. En primer lugar, vamos a explorar el modo de seguridad, antes de centrar nuestra atención en los beneficios generales de tener este nivel de preparación en el contexto de la tecnología distribuida y descentralizada. Ten en cuenta que exploraremos los modos restantes en detalle en los próximos posts.

Características y ventajas del modo Seguridad

1. La seguridad ante todo

El Modo de Seguridad garantiza que si hay una caída significativa de validadores activos, Shardeum pasará a un estado de protección, priorizando la sincronización de datos sobre el procesamiento de transacciones de la aplicación.

2. Estabilidad e integridad de la red

El modo de seguridad está diseñado para mantener la estabilidad de la red cuando el número de nodos activos cae por debajo de un determinado umbral. Al limitar la red al procesamiento exclusivo de transacciones de protocolo, reduce la carga y la complejidad de las operaciones, ayudando a garantizar que las funciones centrales de la red permanezcan intactas y seguras.

3. Prevención de la corrupción o pérdida de datos

En los sistemas basados en fragmentos, la pérdida de un número significativo de nodos puede poner en riesgo la integridad de los datos, especialmente si estos nodos son responsables de fragmentos específicos. Al entrar en modo seguro, el sistema puede prevenir escenarios en los que las transacciones podrían procesarse incorrectamente o en los que los datos podrían perderse debido a una cobertura insuficiente de nodos.

4. Respuesta automática al estrés de la red

El modo de seguridad actúa como mecanismo de respuesta automática ante caídas repentinas de la participación de los nodos. Este cambio automático puede ser crucial para evitar fallos en cascada que podrían producirse si la red siguiera funcionando en condiciones normales a pesar de una reducción significativa de los nodos activos.5. Facilita la recuperación de la red

Al centrarse únicamente en las transacciones del protocolo, el modo de seguridad permite que la red funcione con una capacidad reducida, lo que resulta más fácil de mantener y gestionar. Este funcionamiento simplificado facilita que los nodos nuevos o en recuperación se sincronicen y participen en la red, ayudando en el proceso general de recuperación.

5. Garantiza la integridad del consenso

En los sistemas descentralizados, mantener el consenso es vital. El modo de seguridad ayuda a preservar la integridad del proceso de consenso reduciendo la complejidad operativa de la red y garantizando que los nodos restantes puedan seguir acordando el estado de la red.

6. Protege frente a posibles ataques

En algunos escenarios, una caída repentina de los nodos activos podría deberse a un ataque coordinado. Al cambiar al modo de seguridad, la red reduce su vulnerabilidad, ya que sólo se procesan las transacciones esenciales del protocolo, dejando menos espacio para que las actividades maliciosas exploten un estado debilitado de la red.

7. Mantiene las operaciones esenciales

Incluso en una capacidad reducida, el modo de seguridad garantiza que las operaciones esenciales de la red continúen. Esto significa que se conservan las actualizaciones críticas, las tareas de mantenimiento necesarias y las funcionalidades básicas de la red, garantizando que ésta no se detiene por completo.

En resumen, el modo de seguridad en un sistema como Sharduem proporciona una red de seguridad crítica que garantiza la estabilidad de la red, evita la pérdida de datos, ayuda a la recuperación y mantiene la integridad de los mecanismos de consenso durante periodos de estrés o de actividad reducida de los nodos. Este modo es esencial para la resistencia y la sostenibilidad a largo plazo de una red descentralizada basada en fragmentos.

Ventajas de los modos de red en Shardeum: Una visión.

Así que ahora que tenemos una comprensión global de las ventajas del modo de seguridad, ¿qué ventajas aportan los otros modos principales a Shardeum?

⚡Formación rápida: Durante la fase de formación, la red crece a un ritmo impresionante, alcanzando rápidamente la capacidad operativa.

🔄 Rotación eficiente: Durante la fase de procesamiento, los validadores rotan de forma eficiente, equilibrando la demanda de la red y la disponibilidad de los validadores a la perfección.

🚦 Adaptabilidad dinámica: También durante la fase de procesamiento, la red puede crecer o decrecer en función de la demanda, garantizando un rendimiento óptimo.

🔒 Recuperación robusta: Incluso si la cantidad total de validadores activos necesarios disminuye considerablemente, el modo de recuperación de Shardeum entra en acción para estabilizar, reagrupar y reconstruir.

🤝 Colaboración sin fisuras: En la fase de reinicio, gracias al papel de los archivadores, la red puede recuperarse incluso en el caso de que se pierdan todos los validadores activos

🚀 Reinicios rápidos: También durante la fase de reinicio, en el improbable escenario de pérdida total de validadores, el modo de reinicio asegura una rápida resurrección de la red — esto significa que Shardeum siempre será capaz de recuperarse, incluso en escenarios extremadamente improbables.

🔄 Sincronización rápida: Al pasar de un modo a otro, los procesos de sincronización se aceleran para que los nodos se pongan al día.

💡 Aprendizaje continuo: La aplicación nos enseña a adaptarnos y evolucionar, lo que nos lleva a futuras innovaciones. A los Shardianes estelares A nuestros apasionados Shardians, dedicados operadores de nodos, colaboradores del ecosistema y socios inestimables: ¡GRACIAS! Vuestro inquebrantable apoyo, energía y compromiso hacen que cada línea de código y cada función implementada merezcan la pena. Sois el corazón de Shardeum, y juntos, ¡estamos dando forma al futuro!

Conclusión

¿Qué hemos descubierto hoy? La última implementación de los modos de red de Shardeum, con especial atención al Modo Seguridad, dota a nuestra red de resistencia, adaptabilidad y la capacidad de prosperar en medio de los desafíos. Se trata tanto de salvaguardar las operaciones y los activos como de garantizar que la experiencia de cada shardiano siga siendo de primera categoría. A medida que avanzamos, sabemos que Shardeum es más robusto, resistente y está en constante evolución, todo gracias a nuestros esfuerzos colectivos. Brindemos por una plataforma de contratos inteligentes más segura, rápida y sólida. 🚀

Fuente de la traducción (4 de abril de 2024): https://shardeum.org/blog/shardeum-network-safety-mode-resilience/

@Shardeum #ShardeumIsBorderless

Al incorporar métodos RPC compatibles con Ethereum junto con sus innovadores RPC personalizados, Shardeum impulsa la accesibilidad de los desarrolladores y la tecnología…

Estamos muy contentos de compartir un hito importante en nuestro viaje hacia la mainnet — la integración exitosa de todos los métodos RPC compatibles con Ethereum necesarios en Shardeum a finales de 2023. Esto llega tras nuestros esfuerzos iniciales del año pasado, comenzando con la implementación de métodos RPC como WSS eth_subscribe. Esta optimización es una parte crucial de la mejora de la funcionalidad de Shardeum. Cabe destacar que hemos introducido métodos RPC Shardeum especializados. Estos están diseñados para complementar los RPCs estándar de Ethereum, capturando las diferencias únicas que Shardeum pone sobre la mesa promoviendo una experiencia de desarrollador sin fisuras y la educación de las innovaciones de vanguardia que ofrece. Esta configuración mejora aún más la plataforma de contratos inteligentes de Shardeum, reduciendo la barrera de entrada no sólo para los desarrolladores basados en EVM, sino para todos los desarrolladores en el ecosistema de ledger/blockchain.

Antes de sumergirnos en los detalles de nuestra implementación de métodos RPC compatibles con Ethereum, tomemos un momento para explorar por qué Shardeum se destaca como la plataforma de elección para desarrollar o migrar sus dApps, especialmente en un paisaje poblado de blockchains L1 más recientes, soluciones modulares y cadenas L2.

¿Por qué debería construir en Shardeum?

Shardeum se dedica a mejorar la escalabilidad de la capa uno y la descentralización, optando por dar prioridad a estas áreas en lugar de reinventar los componentes clave de cara al usuario, como el lenguaje de contratos inteligentes, la máquina virtual y el explorador de bloques. Este enfoque estratégico se basa en la creencia de que Ethereum ya ofrece un robusto conjunto de herramientas para el desarrollo de contratos inteligentes y dApps, complementado por lenguajes de programación fáciles de desarrollar como Solidity y Vyper. Al aprovechar estos recursos establecidos, queremos ayudar a acelerar los procesos de desarrollo y aprovechar todo el potencial de la tecnología blockchain. Sin embargo, con la introducción de una plataforma independiente de contratos inteligentes a nivel de protocolo, Shardeum se concentra en construir un producto que solucione las auténticas deficiencias de Ethereum y otras cadenas L1: una cadena fragmentada que se autoescala linealmente para mantener altos niveles de escalabilidad, descentralización y seguridad, con el fin de garantizar que las comisiones por transacción sigan siendo muy bajas de forma permanente, independientemente de la demanda en la red.

La guinda del pastel es la capacidad de Shardeum para procesar transacciones y alcanzar el consenso de forma individual, lo que permite la composabilidad atómica y entre fragmentos con la ejecución de transacciones en paralelo. Este desarrollo elimina eficazmente los cuellos de botella habituales a los que se enfrentan los desarrolladores con llamadas a contratos inteligentes complejos en blockchains contemporáneos y redes fragmentadas que buscan una alta escalabilidad. Aunque Shardeum es naturalmente atractiva para los desarrolladores de EVM como una red de capa 1 basada en EVM, estamos igualmente comprometidos a dar la bienvenida a nuestro redil a aquellos que trabajan fuera del ecosistema EVM.

El espacio blockchain se nutre de la diversidad, con numerosos protocolos dedicados a fomentar la interoperabilidad entre blockchains variados. Shardeum destaca por ofrecer una solución de capa 1 que aborda de forma decisiva el trilema de la escalabilidad, un paso crucial para permitir una interoperabilidad fluida entre plataformas. Nuestro compromiso se extiende a la apertura del protocolo en breve, para inspirar y elevar el ecosistema en general. Para los desarrolladores que buscan tener un impacto significativo, independientemente de su plataforma actual, Shardeum ofrece una oportunidad única e indispensable para construir sobre una base que no sólo es escalable, sino también amigable para los desarrolladores con una comunidad masiva de más de 1 millón de miembros de la comunidad ya en 2 años de lanzamiento.

¿Qué son los métodos JSON-RPC de Ethereum?

Los métodos JSON-RPC de Ethereum son un conjunto de llamadas a procedimientos remotos (RPC) codificadas en formato JSON, que permiten interactuar con la red Ethereum. Estos métodos permiten la ejecución de una amplia gama de operaciones, como la consulta de datos de blockchain, el envío de transacciones y el seguimiento de los cambios en la red. Esencialmente, actúan como puente entre aplicaciones o clientes externos y la blockchain de Ethereum, facilitando un flujo fluido de información y comandos. Este conjunto de métodos forma una API que agiliza el acceso y la interacción de los desarrolladores con la red Ethereum.

La incorporación de los métodos JSON-RPC de Ethereum a Shardeum supone una mejora significativa de las capacidades de su plataforma. Estos métodos, que van desde eth_feeHistory hasta eth_chainId, son fundamentales para permitir un seguimiento preciso de las transacciones, la monitorización en tiempo real y una interacción eficiente con la red. Al adoptar estos métodos, Shardeum no sólo facilita una transición más suave para los desarrolladores de Ethereum, sino que también enriquece su ecosistema con funcionalidades avanzadas y posibilidades más amplias. Estos métodos simbolizan el compromiso de Shardeum con la construcción de una plataforma sólida y centrada en el usuario, preparada para la innovación y la colaboración en el amplio espacio Web3. Para aquellos que no estén familiarizados con estos métodos, veamos qué hace cada uno de ellos.

Métodos RPC populares de Ethereum

Los siguientes métodos son especialmente populares entre los desarrolladores y proyectos de terceros para extraer información de las redes blockchain permitiéndoles crear una serie de productos y servicios valiosos.

• eth_feeHistory: Este método recupera un rango de tarifas históricas de la red que es útil para analizar los precios del gas a lo largo del tiempo.

• eth_getBlockReceipts: Este método proporciona una lista de recibos de todas las transacciones de un bloque determinado y es útil para la confirmación de transacciones y el seguimiento del estado.

• eth_getBlockTransactionCountByHash: Este método devuelve el número de transacciones de un bloque, identificadas por su hash, útil para el análisis de bloques.

• eth_getBlockTransactionCountByNumber: Este método devuelve el número de transacciones en un bloque, pero identifica el bloque por su número en lugar de por su hash.

• eth_getTransactionByBlockHashAndIndex: Este método obtiene una transacción basándose en el hash del bloque y la posición del índice dentro del bloque.

• eth_getTransactionByBlockNumberAndIndex: Este método recupera una transacción por su número de bloque e índice dentro de ese bloque.

• eth_newPendingTransactionFilter: Este método crea un filtro para notificar sobre nuevas transacciones pendientes. Es útil para rastrear transacciones emitidas pero aún no confirmadas.

• eth_chainId: Esto devuelve el ID de cadena actual de la red, una pieza importante de información para asegurar la integridad de la transacción en la red Ethereum correcta.

Los métodos PRC de Ethereum complementan los requisitos personalizados de Shardeum

Shardeum no sólo garantiza la compatibilidad con los métodos JSON-RPC de Ethereum mencionados anteriormente, sino que también se esfuerza por asegurar que nuestros métodos RPC existentes proporcionen respuestas estrechamente alineadas con las de Ethereum. Este enfoque garantiza una integración perfecta para los desarrolladores familiarizados con Ethereum, mejorando la facilidad de adopción y la interoperabilidad. Y como se ha mencionado, esto también minimiza la cantidad de tiempo que los desarrolladores tienen que dedicar al aprendizaje, lo que permite una transición eficiente y la utilización de nuestra plataforma en proyectos basados en Ethereum.

Por ejemplo, en el contexto de la implementación de Shardeum del método eth_feeHistory JSON-RPC, existe una diferencia notable en comparación con Ethereum. En lugar de devolver el baseFeePerGas, que es un elemento estándar en Ethereum, Shardeum proporciona una matriz de precios del gas para los bloques especificados. Esta desviación se debe a la estructura de transacción única de Shardeum, que no incorpora baseFeePerGas y es impermeable a MEV. La matriz de precios del gas proporcionada ofrece una visión histórica de los costes de transacción en Shardeum, lo que permite a los usuarios analizar y comprender las tendencias del precio del gas a lo largo del tiempo dentro de la red.

Otro ejemplo es la notable diferencia que encontraríamos con nuestra implementación de consultas estándar relacionadas con bloques como eth_getBlockReceipts y eth_getBlockTransactionCountByHash. La diferencia se debe al hecho de que Shardeum técnicamente tiene una arquitectura sin bloques. En lugar de bloques, Shardeum tiene ciclos, dado que las transacciones se procesan individualmente en la red, tras lo cual las transacciones procesadas se agrupan en grupos o bloques a intervalos predeterminados antes de ser transferidas a los nodos de archivo. Se calcula que un ciclo dura 60 segundos en Shardeum y que se forma un bloque cada 6 segundos.

¿Por qué Shardeum necesita métodos JSON-RPC de Ethereum?

Dado que Shardeum técnicamente no es una blockchain sino que también incorpora el EVM, la integración de sus tecnologías principales presenta desafíos técnicos únicos. Sin embargo, integrar los métodos JSON-RPC de Ethereum en Shardeum es crítico por varias razones:

1. Compatibilidad y familiaridad

Al implementar los métodos RPC de Ethereum, Shardeum ofrece un entorno familiar para los desarrolladores ya expertos en el ecosistema de Ethereum. Esto reduce la curva de aprendizaje y acelera la adopción para la comunidad basada en Ethereum que representa más del 85% de todo el ecosistema de contratos inteligentes.

2. Interoperabilidad

Los métodos RPC de Ethereum son un estándar en el amplio mundo de los desarrolladores. La adopción de estos métodos por parte de Shardeum garantiza la interoperabilidad con las herramientas y aplicaciones existentes diseñadas para Ethereum, mejorando sus capacidades de integración.

3.Funcionalidad completa

La implementación de una gama completa de métodos RPC permite a Shardeum ofrecer una experiencia de servidor RPC más completa y robusta. Garantiza que todas las funcionalidades necesarias estén disponibles para diversas interacciones.

4.Personalización para la Arquitectura de Shardeum

Mientras Shardeum se esfuerza por igualar las especificaciones RPC de Ethereum, también adapta u omite ciertos métodos para ajustarse a su estructura única de libro mayor. Esta personalización asegura que los métodos RPC se alinean bien con la arquitectura de Shardeum, mejorando la eficiencia y el rendimiento.

Ventajas de implementar métodos RPC de Ethereum en Shardeum

A medida que nos embarcamos en una exploración exhaustiva de los beneficios aportados por la integración de los métodos JSON-RPC de Ethereum en Shardeum, es crucial comprender la profundidad y amplitud de estas ventajas. Esta inmersión en profundidad arrojará luz sobre cómo estos métodos no sólo mejoran la destreza técnica de Shardeum, sino que también afectan significativamente a su red, a la comunidad de desarrolladores y al ecosistema en general.

1.Beneficios para la red Shardeum

🧑‍ Experiencia mejorada para desarrolladores: Un servidor RPC más completo con métodos similares a Ethereum mejora la experiencia general del desarrollador, haciendo que sea más fácil y eficiente construir en Shardeum.

📈 Crecimiento y adopción de la red: La familiaridad y la facilidad de uso pueden atraer a más desarrolladores del ecosistema Ethereum, contribuyendo al crecimiento y la diversidad de la red Shardeum.

🏎️ Rendimiento mejorado: Con un conjunto robusto de métodos RPC, Shardeum puede manejar una gama más amplia de consultas y comandos de manera más eficiente, lo que lleva a un mejor rendimiento de la red.

2.Ventajas para los desarrolladores

🛠️ Facilidad de transición: Los desarrolladores experimentados con Ethereum pueden hacer fácilmente la transición a Shardeum, aprovechando sus conocimientos y herramientas existentes.

🔧 Riqueza de herramientas e integración: El acceso a un amplio conjunto de métodos RPC permite la creación de aplicaciones sofisticadas y una integración perfecta con las herramientas existentes basadas en Ethereum.

💡 Oportunidades innovadoras: Las adaptaciones únicas en los métodos RPC de Shardeum ofrecen a los desarrolladores la oportunidad de explorar nuevas funcionalidades e innovaciones que no son posibles en la red Ethereum.

3.Beneficios para la comunidad

🌱 Desarrollo de un ecosistema más amplio: A medida que más desarrolladores se unen a la red Shardeum, el ecosistema se enriquece, ofreciendo aplicaciones más diversas y sofisticadas a la comunidad.

🛡️ Mayor seguridad e integridad de la red: Con métodos como eth_chainId, Shardeum garantiza transacciones seguras y fiables, fomentando la confianza dentro de la comunidad.

📊 Información y análisis en tiempo real: Métodos como eth_feeHistory y eth_getBlockReceipts proporcionan a la comunidad información valiosa sobre la actividad de la red, mejorando la transparencia y la toma de decisiones informadas.

En conclusión, la integración de los métodos JSON-RPC de Ethereum en Shardeum representa un paso estratégico hacia la compatibilidad, la funcionalidad mejorada y un mayor atractivo dentro de la comunidad Web3 más amplia. Sienta las bases de un ecosistema vibrante que es a la vez innovador y accesible, beneficiando a la red, a sus desarrolladores y a la comunidad en general.

Para terminar: Para llevar

En resumen, el reciente logro de Shardeum en la implantación de los métodos RPC de EVM marca un avance fundamental en la evolución de nuestra red. Mejora nuestras capacidades y garantiza que Shardeum se mantenga a la vanguardia de la innovación. Esta actualización no sólo optimiza nuestro sistema, sino que también significa nuestro compromiso inquebrantable de ofrecer soluciones de vanguardia en el amplio mundo de Web3.

Shardians, ¡celebremos juntos este hito! 🎉Vuestra pasión y apoyo son las piedras angulares del creciente éxito de Shardeum. ¡Por muchos más hitos y continuos avances en nuestro viaje colectivo!

Fuente de la traducción (20 de marzo de 2024): https://shardeum.org/blog/shardeum-integrates-ethereum-rpc/

Shardeum’s Blast Off: un logro revolucionario

El lunes 27 de enero de 2024 se produjo un acontecimiento sin precedentes en el mundo de la web3 que puede compararse a la hazaña histórica de una nave espacial que regresa sin problemas a su plataforma de lanzamiento tras su primera misión de vuelo de prueba. En este extraordinario escenario, Shardeum no sólo se enfrentó a un reto formidable, sino que también salió triunfal, con la capacidad de recuperación de su red marcando la primera vez que una red fragmentada se ha auto-restaurado en el ámbito de la tecnología de ledger distribuido.

Al igual que el viaje de una nave espacial implica una planificación meticulosa, ingeniería de precisión y la ejecución perfecta de maniobras complejas, la restauración por Shardeum de su betanet Sphinx, que había sufrido un accidente crítico, requirió un nivel equivalente de dominio tecnológico e innovación. La capacidad de preservar todos los datos de una red, sobre todo de una que funciona con fragmentación dinámica de estados, no tiene nada de innovador.

Al embarcarnos en esta exploración, no sólo celebramos el trascendental aterrizaje de Shardeum, sino que lo reconocemos como un momento crucial en la evolución de la tecnología web3, un salto que podría redefinir los límites de la resistencia de las redes informáticas y la integridad de los datos.

Primera red fragmentada que se autorrestaura y conserva los datos

Mantener y restaurar una red fragmentada dinámicamente, como Shardeum, conlleva una serie de complejos retos técnicos que la diferencian de las redes blockchain tradicionales como Bitcoin o Ethereum. En un entorno de fragmentación dinámica con autoescalado, la reasignación y el equilibrio continuos de nodos y recursos entre diferentes fragmentaciones son cruciales para optimizar el rendimiento y la escalabilidad. Este flujo constante en la arquitectura de red añade una complejidad significativa a la hora de mantener la coherencia de los datos, garantizar la estabilidad de la red y facilitar una recuperación eficaz de los fallos.

La criticidad de estos retos se acentúa al contrastar la respuesta de Shardeum a las fluctuaciones de los nodos con la de Bitcoin. La red Bitcoin mantiene su funcionalidad incluso con un número mínimo de nodos, ya que cada nodo completo posee el estado completo y el historial de transacciones. Por el contrario, cada nodo activo de Shardeum no posee el estado completo ni el historial de transacciones, ya que la red Shardeum está fragmentada y cada validador sólo posee un subconjunto del estado completo. La consecuencia de esta fragmentación es que todos los nodos validadores son extremadamente ligeros. Esto crea una plétora de oportunidades y retos de ingeniería. Si un nodo se cae, ¿cómo nos aseguramos de que se conservan todos los datos? Shardeum tiene dos formas principales.

En primer lugar, Shardeum utiliza la fragmentación dinámica de estados, en la que el espacio global de direcciones se particiona (o divide) en función del número de nodos activos. Cada nodo es responsable de sus particiones asignadas, junto con un determinado 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 en el marco de la red. Así, aunque un nodo se caiga, sigue habiendo continuidad en la red y no se pierden datos.

En segundo lugar, Shardeum utiliza nodos archivadores para almacenar el estado completo de toda la red. Para ello, los nodos activos envían sus estados parcialmente almacenados a los archivadores para que los recojan. Debido a estos dos factores y a las optimizaciones de diseño, la restauración de una red de este tipo tiene que diseñarse de forma novedosa para seguir facilitando características ventajosas como el autoescalado y el escalado lineal.

Entendiendo el Choque

Ahora que entendemos los fundamentos de la fragmentación dinámica de estados y que los nodos archivadores están implicados de alguna manera, vamos a desentrañar primero algunos componentes adicionales más profundamente y a explicarlos. Para entender la caída y la restauración de la betanet Shardeum, primero debemos entender un poco lo siguiente:

• Nodos archivadores

• Detección de archivadores perdidos

• Modos de red

• Modo de recuperación

Entender lo básico de cada uno de ellos es necesario antes de sumergirnos de cabeza en los fallos, ¡así que echemos un vistazo!

Nodos archivadores: Almacenamiento interestelar

En Shardeum, los nodos archivadores, también llamados archiveros, constituyen una categoría crítica de nodos, encargados de preservar el estado completo y los registros históricos de la red. A diferencia de los nodos activos, los archivadores no participan en los procesos de consenso; su función principal es archivar exhaustivamente la totalidad de los datos de la red, incluidas las transacciones y los recibos. La contribución de los nodos archivadores es esencial para mantener la integridad de la red y garantizar su perfecto funcionamiento, afirmando así el estatus de Shardeum como una red robusta, completa y fiable. Debido a que los archivadores son parte integral de la red, Shardeum debe tener un protocolo para detectar cualquier archivador (y validador) que no responda.

Detección del Archivador perdido: Tecnología alienígena al descubierto

Shardeum tiene un protocolo llamado detección de nodos perdidos que detecta cuando los nodos activos dejan de funcionar — esto está reservado únicamente para los nodos activos. Sin embargo, Shardeum también tiene un protocolo para los archivadores que hace algo similar llamado detección de archivador perdido. La detección de archivadores perdidos es un protocolo especializado diseñado para manejar escenarios raros en los que uno o más archivadores dejan de estar operativos y se marcan como perdidos. Dado que los nodos archivadores son fundamentales para mantener la integridad y accesibilidad de los datos históricos dentro de la red, es esencial que, en las raras ocasiones en que no respondan o no funcionen, se detecten estos eventos críticos para mitigar cualquier efecto posterior. Aunque la pérdida de archivadores no causó este fallo en particular, sí lo hizo la interacción entre el protocolo de detección de pérdida de archivadores y un modo de red específico. Examinemos ahora cuáles son los modos de red en Shardeum.

Modos de red en Shardeum: No se necesita a la NASA

Una innovación emblemática de Shardeum, impulsada por el protocolo subyacente Shardus, es el marco de modos de red. Estos modos trascienden los estados operativos básicos y encarnan una intrincada coordinación de diversas actividades de nodos, métodos de sincronización de datos y sistemas de gestión de transacciones. Estas configuraciones de red desempeñan un papel crucial en la preservación 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 fragmentada.

A un nivel más simple, la mejor manera de concebir los modos de red en Shardeum es como planes de contingencia codificados que permiten la continuidad de las operaciones de toda la red, incluso en condiciones improbables como la caída de la red o la degradación de toda la red. Esta resistencia y robustez operativas preprogramadas garantizan que Shardeum siempre seguirá viva, sea cual sea la adversidad a la que se enfrente la red.

Aunque para entender el fallo no hace falta digerir todas las facetas del marco de los modos de red, sí ayuda familiarizarse con lo básico. Un elemento central del marco de modos de red es la incorporación de varias fases de red distintas: Formación, Procesamiento, Seguridad, Recuperación, Reinicio, Restauración y Apagado. Estos modos están cuidadosamente diseñados para hacer frente a diversas situaciones y emergencias de la red. Sin embargo, el modo que nos ocupa en este artículo es el de recuperación.

Modo de recuperación de ingeniería inversa: Rosewell revisitado

El modo de recuperación es 1 de los 7 modos de red antes mencionados. El modo de recuperación se inicia cuando el recuento de nodos activos de la red desciende por debajo de un umbral crítico predefinido (actualmente configurado en 75% o inferior). Este umbral es ajustable según los requisitos de la red. En este modo, la red detiene temporalmente 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 mediante la introducción gradual de nodos de reserva como parte de la rotación de nodos, restaurando así el recuento de nodos activos a un nivel óptimo, idealmente por encima del 100%.

Durante el modo de recuperación, la arquitectura de red de Shardeum permite un aumento incremental de los nodos, con un tope del 20% de crecimiento por ciclo (cada ciclo dura aproximadamente 60 segundos). Este ritmo de crecimiento controlado es fundamental para mantener la estabilidad de la red y garantizar una integración perfecta de los nuevos nodos. Un aumento rápido del número de nodos, por ejemplo del 50%, podría desestabilizar la red y complicar el proceso de integración.

Cada nuevo nodo añadido necesita recursos de red para su sincronización e integración. Al limitar el aumento al 20% por ciclo, la red se asegura de que su infraestructura pueda soportar adecuadamente la adición de nuevos nodos sin tensiones. Este enfoque no sólo preserva la estabilidad de la red, sino que también minimiza el riesgo de incoherencias o errores en los datos durante el proceso de sincronización, manteniendo así la integridad de los datos de la cadena de ciclos.

La causa principal del accidente: Horizonte de sucesos

Es importante señalar que había dos errores distintos. El bug de la librería neon — que causaba que los validadores se bloquearan aparentemente al azar y un bug en el protocolo de detección de archivadores perdidos — que no aceptaba una lista de validadores vacía. Aunque es el bug del protocolo de detección de archivadores perdidos el que causó el fallo de la versión betanet, me gustaría explicarles primero el bug de la librería neon.

En la versión Sphinx 1.9.1, integramos una actualización a una librería que emplea Neon bindings para unir funcionalidades Rust y TypeScript ya que Shardeum está construido predominantemente en TypeScript. Neon es reconocido por su enfoque innovador, aunque experimental, a menudo empujando los límites de las prácticas convencionales de desarrollo de software. Esta integración tenía 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 provocó un error que hacía que los nodos abandonaran aleatoriamente la red.

En segundo lugar, en el reciente incidente que provocó la caída de la betanet en Shardeum, la causa principal se identificó como una anomalía crítica originada por la interacción entre los dos subsistemas distintos antes mencionados: el mecanismo de detección de archivadores perdidos y el protocolo de modo de recuperación de la red.Este breve fallo se precipitó por la activación simultánea de estos dos mecanismos, un escenario no encontrado ni probado anteriormente. El proceso de archivador perdido se activó junto con el mod de recuperación de red y debido a un fallo en el modo de archivador perdido que no aceptaba una lista de nodos activos vacía. Esto culminó en la caída de la red.

Crónica de la recuperación: Del shock sistémico a la recuperación estelar

¿Qué más ocurrió realmente y cuándo? La cronología de los acontecimientos que rodearon la caída de la red y su resolución es la siguiente:

1. Vulnerabilidad inicial y actualización: La red se encontró con una vulnerabilidad señalada por el proceso 1.9.1 linting dentro de una biblioteca npm (neon). Se implementó una actualización para solucionar este problema. Sin embargo, esta actualización introdujo inadvertidamente una excepción que no se reprodujo durante las pruebas locales.

2. Excepción intermitente en la biblioteca que provoca cierres del validador: La biblioteca neon experimentaba excepciones esporádicas que provocaban cierres periódicos de los validadores de red. Aunque el diseño de la red permitía la resistencia mediante el rellenado de estos validadores y, por desgracia, la sincronización de fallos simultáneos entre varios validadores activó el modo de recuperación de la red.

3. Activación del modo de recuperación de la red: Una vez en el modo de recuperación de la red, el protocolo necesitó borrar y regenerar la lista de nodos activos. La causa principal de la caída de la red fue un fallo simultáneo en el sistema de archivo de pérdidas, que no admitía una lista de validadores vacía.

4. Resolución y restauración de la red: Se rectificó el fallo y la red se restauró con éxito utilizando los datos almacenados en los archivadores. Es la primera vez en la historia que una red fragmentada de capa 1 que se ha bloqueado se restaura con éxito y todos los datos de la red se conservan intactos. Esto no se había conseguido nunca en ninguna red, y mucho menos en una red con fragmentación dinámica de estados. Este logro marcó el exitoso “aterrizaje del cohete” en términos de recuperación de redes.

5. Correcciones realizadas: Se implementó una corrección preliminar para solucionar el problema 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 introdujo un fallo singular pero crucial. Esta actualización introdujo una corrección de errores singular pero crucial que abordaba otro caso del fallo de enlace de neon, señalando y rectificando una vulnerabilidad específica sin obligar a una actualización de toda la red. Inicialmente, los usuarios que utilizaban la versión 1.9.4 tenían la posibilidad de permanecer en su versión actual u optar por la actualización a la 1.9.5, en función de sus preferencias de rendimiento y estabilidad de la red. Sin embargo, finalmente se decidió que, con el fin de mejorar la estabilidad de la red y resolver los problemas persistentes relacionados con los enlaces de neon, la versión mínima requerida para los validadores debía aumentarse a 1.9.5. Con esta actualización se pretendía excluir sistemáticamente a los validadores que funcionan con la versión 1.9.4, que se han identificado como susceptibles de bloquearse debido a la complicación de los neon bindings antes mencionada. Esto es necesario para asegurarse de que el fallo de neon está totalmente anulado y completamente solucionado.

Ahora que conocemos la cronología y cómo se desencadenaron los principales acontecimientos, echemos un vistazo a lo que ocurrió para que la red se restableciera tan rápidamente.

Rumbo a la restauración

Recuperación ágil

La restauración de la red constó de muchas partes, pero una de las fundamentales fue el modo de recuperación de Shardeum. Como ya se ha dicho, el modo de recuperación se inicia cuando el recuento de nodos activos de la red desciende por debajo de un umbral crítico predefinido y permite un crecimiento rápido, controlado y eficaz de la red de forma segura para restaurarla. Es importante destacar que, sin el ingenio tecnológico de los diseñadores y desarrolladores de los modos de red, Shardeum no habría podido recuperarse de la caída con tanta facilidad ni hacer gala de su capacidad innovadora.

Además, el equipo técnico de Shardeum realizó esfuerzos clave al lanzarse a la acción inmediata. El primer paso consistió en un análisis exhaustivo para identificar la causa de la caída, que se atribuyó a una anomalía en la interacción entre la detección de archivos perdidos de la red y sus sistemas de modo de recuperación. Consciente de la complejidad del problema, el equipo aplicó rápidamente un enfoque polifacético para hacer frente tanto a las consecuencias inmediatas como a las vulnerabilidades subyacentes.

Respuesta polifacética del equipo técnico de Shardeum

Técnicamente, la respuesta fue polifacética: en primer lugar, el equipo aisló los componentes afectados para evitar una mayor degradación de la red. Al mismo tiempo, desplegaron un parche para rectificar el error en el sistema de archivo perdido, asegurándose de que podía manejar una lista de validadores vacía, un descuido crítico que había precipitado el fallo de la red. Para restablecer la plena capacidad operativa de la red, se activaron los datos conservados en los archivadores y se utilizaron para reconstruir el estado de la red antes de la caída, garantizando que no se perdieran datos en el proceso.

Desde el punto de vista logístico, el equipo se coordinó a través de diferentes zonas horarias y disciplinas, aprovechando las herramientas basadas en la nube para la colaboración y la supervisión en tiempo real. Este esfuerzo coordinado no solo facilitó el rápido desarrollo y despliegue de las correcciones, sino que también garantizó que todos los miembros del equipo estuvieran alineados en el proceso de recuperación y los siguientes pasos.

Este incidente sirvió como rigurosa prueba de los protocolos de gestión de accidentes de Shardeum y puso de relieve la importancia de las respuestas ágiles e innovadoras a los retos imprevistos. Subraya el compromiso del equipo de mantener una red resistente y segura, preparada para afrontar los complejos obstáculos técnicos que surjan.

Aterrizaje seguro e innovación espacial

En conclusión, la exitosa restauración de la red fragmentada de Shardeum anuncia un cambio significativo en la tecnología de redes, marcando un hito con implicaciones de largo alcance para la industria. Aunque actualmente no se reconocen en gran medida, innovaciones como los modos de red acabarán estableciendo nuevas normas industriales en la web3.

Creo desde hace tiempo que las innovaciones fundamentales de Shardeum influirán con toda probabilidad en futuros avances tecnológicos, inspirando innovaciones y nuevas generaciones de tecnologías de libro mayor. Habiendo sido testigo de primera mano de la restauración de la red de Shardeum, la primera de su clase, sé que esto catalizará una reevaluación de los estándares de la industria, lo que potencialmente conducirá a la adopción de protocolos y metodologías más rigurosos en el diseño y la arquitectura de la red.

Este acontecimiento no sólo pone de manifiesto la destreza técnica y la innovación del equipo de Shardeum, sino que también señala el comienzo de una era en la que las redes descentralizadas son más robustas, adaptables y capaces de hacer frente a retos imprevistos en la planificación de la recuperación en caso de catástrofe. En última instancia, la tecnología de Shardeum anunciará una nueva era de descentralización.

Fuente de la traducción (15 de marzo de 2024): https://shardeum.org/blog/shardeum-resilience-restoring-sharded-network/

Echa un vistazo a cómo construir una sencilla aplicación para mintear NFT en la red de pruebas Shardeum utilizando React JS, IPFS y…

Esta guía te guiará a través del proceso de creación de una sencilla aplicación de minteo de NFT que utiliza React JS para el front-end, IPFS para el almacenamiento descentralizado y despliega un contrato inteligente Solidity en la red de pruebas Shardeum. Esta aplicación permite a los usuarios mintear NFTs con metadatos personalizados como nombre, descripción e imagen/gif.

1. Configurar nuestro proyecto

Vamos a empezar con la creación de un archivo de proyecto vacío y la inicialización de npm.

mkdir shardeum-nft-minter
cd shardeum-nft-minter
npm init

2. Contrato inteligente y configuración de Hardhat

Utilizaremos Hardhat — Un marco de desarrollo para desplegar, probar y depurar contratos inteligentes.

i) Ahora, vamos a instalar hardhat como dev-dependencia; elige ‘Create an empty hardhat.config.js’ e instala la librería de contratos de Openzeppelin. Además, vamos a instalar todas las otras bibliotecas necesarias hardhat.

npm install --save-dev hardhat
npx hardhat
npm install @openzeppelin/contracts
npm install --save ethers@5.7.2 hardhat @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers

ii) Crear una carpeta ‘contracts’ y ‘scripts’. En la carpeta de contratos, agrega el siguiente código al archivo NftMinter.sol:

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.3;
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

contract NFTMinter is ERC721URIStorage {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIds;
    constructor() ERC721("Shardeum Dev NFTMinter, "SNFT") {}
    function mintNFT(address recipient, string memory tokenURI) public returns (uint256) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();
        _mint(recipient, newItemId);
        _setTokenURI(newItemId, tokenURI);
        return newItemId;
    }
}

El contrato anterior hereda del contrato ERC721URIStorage de OpenZeppelin, poniendo a nuestra disposición la mayoría de las funcionalidades necesarias de un ERC721. Puedes personalizar el constructor y cambiar el nombre y el símbolo del token ERC721 a tu gusto. También estamos definiendo una función minNFT en la que hacemos un seguimiento de los tokenIDs y establecemos el tokenURI que almacena los metadatos de ese token. Eso es todo, este único contrato inteligente es suficiente para nuestra aplicación minter.

iii) Crea un archivo deploy.js en tu carpeta de scripts y añade el siguiente script de despliegue:

const { ethers } = require("hardhat");

async function main() {
    const NFTMinter = await ethers.getContractFactory("NFTMinter");
    const nftMinter = await NFTMinter.deploy();
    await nftMinter.deployed();
    console.log("NFTMinter deployed to:", nftMinter.address);
  }

    main()
    .then(() => process.exit(0))
    .catch((error) => {
      console.error(error);
      process.exit(1);
    });

iv) Ahora, vamos a añadir el código necesario para desplegar en Shardeum testnet.

require("@nomiclabs/hardhat-waffle");
module.exports = {
  networks: {
    hardhat: {
    },
    sphinx: {
      url: "https://dapps.shardeum.org/",
      accounts:[``] // Add private key here
    },
  solidity: "0.8.3",
};

Añade tu clave privada en la variable accounts y asegúrate de que tu cuenta tiene suficientes tokens Shardeum testnet.

v) Ahora, vamos a desplegar nuestros contratos inteligentes en la Shardeum Sphinx Dapp para este ejemplo.

npx hardhat run scripts/deploy.js --network sphinx

El script desplegará el contrato inteligente en la Testnet de Shardeum y mostrará la dirección del contrato inteligente desplegado. Necesitarás esta dirección más adelante, así que guárdala.

3. Crear una Aplicación Front-End

Ahora, vamos a crear una aplicación front-end básica para interactuar con nuestro contrato inteligente desplegado.

Vamos a empezar con la inicialización de un react-aplicación en la misma carpeta. Después de configurar la aplicación react, instala también todos los paquetes front-end necesarios.

npx create-react-app .
npm install @emotion/react @emotion/styled @mui/material axios

Haremos todos nuestros cambios de código front-end en la carpeta src. Localiza el archivo NFTMinter.json de tu carpeta de artifactos y llévalo a la carpeta src.

Aquí están los cuatro nuevos archivos javascript que necesitas crear para tener las funcionalidades necesarias:

• connectWallet.js: Este archivo nos permitirá conectar nuestro front-end con el contrato inteligente y nos conecta a metamask. Añade la dirección de tu contrato en la variable designada.

import { ethers } from "ethers";
import NFTMinter from "./NftMinter.json";
export async function connectWallet() {
  await window.ethereum.request({ method: "eth_requestAccounts" });
  const provider = new ethers.providers.Web3Provider(window.ethereum);
  const signer = provider.getSigner();
  // Insert deployed contract address here
  const contract = new ethers.Contract(``, NFTMinter.abi, signer);
  
  return { signer, contract };
  }
  
  export async function connectMetaMask (){
    const { signer } = await connectWallet();
    const address = await signer.getAddress();
    const balance = await signer.getBalance();
    const formattedBalance = ethers.utils.formatEther(balance);
    return {address, formattedBalance}
  };

• ipfsUploader.js: Este archivo contiene todo el código necesario para subir nuestros archivos a ipfs usando Pinata. Crea una cuenta en Pinata y genera un nuevo enlace API.

import axios from 'axios';
const pinataApiKey = ``; // Insert pinata Api Key
const pinataApiSecret = `` ; // Insert pinata Api secret
const pinataApiUrl = 'https://api.pinata.cloud/pinning/pinFileToIPFS';
const pinataHeaders = {
  headers: {
    'Content-Type': 'multipart/form-data',
    pinata_api_key: pinataApiKey,
    pinata_secret_api_key: pinataApiSecret,
  },
};
export async function uploadToIPFS(file) {
  const formData = new FormData();
  formData.append('file', file);
  try {
    const response = await axios.post(pinataApiUrl, formData, pinataHeaders);
    const ipfsHash = response.data.IpfsHash;
    return `https://gateway.pinata.cloud/ipfs/${ipfsHash}`;
  } catch (error) {
    console.error('Error uploading file to Pinata:', error);
    throw error;
  }
}

• MintNFT.js: Este archivo contiene los componentes principales de nuestra aplicación de minting y también todo nuestro código front-end.

import React, { useState } from "react";
import { connectWallet, connectMetaMask } from "./connectWallet";
import { uploadToIPFS } from "./ipfsUploader";
import {
  TextField,
  Button,
  Typography,
  Container,
  Box,
  Link,
  Grid,
  Snackbar,
  Alert,
  LinearProgress,
} from "@mui/material";
function MintNFT() {
  const [name, setName] = useState("");
  const [description, setDescription] = useState("");
  const [image, setImage] = useState(null);
  const [status, setStatus] = useState("");
  const [ipfsLink, setIpfsLink] = useState("");
  const [imageStatus, setImageStatus] = useState("");
  const [alertOpen, setAlertOpen] = useState(false);
  const [loading, setLoading] = useState(false);
  const [walletAddress, setWalletAddress] = useState("");
  const [walletBalance, setWalletBalance] = useState("");
  const [imagePreviewUrl, setImagePreviewUrl] = useState(null);
  const [transactionHistory, setTransactionHistory] = useState([]);
  const handleConnectMetaMask = async () => {
    const { address, formattedBalance } = await connectMetaMask();
    setWalletAddress(address);
    setWalletBalance(formattedBalance);
  };
  const handleImageChange = (e) => {
    setImage(e.target.files[0]);
    setImageStatus("Image selected for upload");
    setImagePreviewUrl(URL.createObjectURL(e.target.files[0]));
  };
  const mint = async () => {
    setStatus("Uploading to IPFS...");
    const imageURI = await uploadToIPFS(image);
    setIpfsLink(imageURI);
    setStatus("Minting NFT...");
    setLoading(true);
    const { signer, contract } = await connectWallet();
    const tokenURI = `data:application/json;base64,${btoa(
      JSON.stringify({
        name,
        description,
        image: imageURI,
      })
    )}`;
    const transaction = await contract.mintNFT(signer.getAddress(), tokenURI);
    await transaction.wait();
    setTransactionHistory((prevHistory) => [
      ...prevHistory,
      transaction.hash,
    ]);
    setStatus("NFT minted!");
    setAlertOpen(true);
    setLoading(false);
  };
  return (
    
    <Container maxWidth="lg">
      <Box sx={{ mt: 4, mb: 2 }}>
        <Typography variant="h4" align="center" gutterBottom>
          Shardeum NFT Minter
        </Typography>
      </Box>
      <Grid container spacing={2}>
        <Grid item xs={12} md={6}>
        <Box mt={2}>
              <Button
                fullWidth
                variant="contained"
                color="primary"
                onClick={handleConnectMetaMask}
                size="small"
                disabled={walletAddress} 
              >
                {walletAddress ? "Wallet Connected" : "Connect Wallet to Shardeum Sphinx Dapp 1.X"}
              </Button>
            </Box>
          {walletAddress && (
            <Box mt={2}>
              <Typography align="center">
                Wallet Address: {walletAddress}
              </Typography>
              <Typography align="center">
                Wallet Balance: {walletBalance} SHM
              </Typography>
            </Box>
          )}
          <TextField
            fullWidth
            label="NFT Name"
            variant="outlined"
            margin="normal"
            onChange={(e) => setName(e.target.value)}
          />
          <TextField
            fullWidth
            label="NFT Description"
            variant="outlined"
            margin="normal"
            onChange={(e) => setDescription(e.target.value)}
          />
          <input
            type="file"
            style={{ display: "none" }}
            id="image-upload"
            onChange={handleImageChange}
          />
          <p></p>
          <label      htmlFor="image-upload">
        <Button variant="contained" color="primary" component="span">
          Upload Image
        </Button>
      </label>
      {imageStatus && (
        <Typography variant="caption" display="block" gutterBottom>
          {imageStatus}
        </Typography>
      )}
      <Box mt={2}>
        <Button
          fullWidth
          variant="contained"
          color="secondary"
          onClick={mint}
        >
          Mint NFT
        </Button>
      </Box>
      {loading && <LinearProgress />}
      
      <Snackbar
        open={alertOpen}
        autoHideDuration={6000}
        onClose={() => setAlertOpen(false)}
        anchorOrigin={{ vertical: "top", horizontal: "right" }}
      >
        <Alert
          onClose={() => setAlertOpen(false)}
          severity="success"
          variant="filled"
          sx={{ width: "100%" }}
        >
          NFT minted successfully!
        </Alert>
      </Snackbar>
    </Grid>
    <Grid item xs={12} md={6}>
  <Box
    mt={2}
    sx={{
      border: "1px dashed #999",
      borderRadius: "12px",
      padding: "16px",
      display: "flex",
      justifyContent: "center",
      alignItems: "center",
      minHeight: "300px",
      background: imagePreviewUrl
        ? "none"
        : "linear-gradient(45deg, rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%)",
    }}
  >
    {imagePreviewUrl ? (
      <img
        src={imagePreviewUrl}
        alt="Uploaded preview"
        style={{
          width: "100%",
          maxHeight: "300px",
          objectFit: "contain",
          borderRadius: "12px",
        }}
      />
    ) : (
      <Typography variant="caption" color="text.secondary">
        Preview image will be displayed here
      </Typography>
    )}
  </Box>
</Grid>
    <Box mt={2}>
        <Typography align="center" color="textSecondary">
          {status}
        </Typography>
        {ipfsLink && (
      <Typography align="left">
    IPFS Link:{" "}
    <Link href={ipfsLink} target="_blank" rel="noopener noreferrer">
      {ipfsLink}
    </Link>
      </Typography>
)}
      </Box>
  </Grid>
  <Box mt={4}>
        <Typography variant="h7" align="center">
          Transaction History:
        </Typography>
        {transactionHistory.length > 0 ? (
          transactionHistory.map((hash, index) => (
            <Box key={index} mt={1} textAlign="left">
              <Link
                href={`https://explorer-dapps.shardeum.org/transaction/${hash}`}
                target="_blank"
                rel="noopener noreferrer"
              >
                {`Transaction ${index + 1}: ${hash}`}
              </Link>
            </Box>
          ))
        ) : (
          <Typography align="center" mt={1}>
            No transactions yet.
          </Typography>
        )}import React, { useState } from "react";
import { connectWallet, connectMetaMask } from "./connectWallet";
import { uploadToIPFS } from "./ipfsUploader";
import {TextField,Button,Typography,Container,Box,Link,Grid,Snackbar,Alert,LinearProgress,} from "@mui/material";
function MintNFT() {
  const [name, setName] = useState("");
  const [description, setDescription] = useState("");
  const [image, setImage] = useState(null);
  const [status, setStatus] = useState("");
  const [ipfsLink, setIpfsLink] = useState("");
  const [imageStatus, setImageStatus] = useState("");
  const [alertOpen, setAlertOpen] = useState(false);
  const [loading, setLoading] = useState(false);
  const [walletAddress, setWalletAddress] = useState("");
  const [walletBalance, setWalletBalance] = useState("");
  const [imagePreviewUrl, setImagePreviewUrl] = useState(null);
  const [transactionHistory, setTransactionHistory] = useState([]);
  const handleConnectMetaMask = async () => {
    const { address, formattedBalance } = await connectMetaMask();
    setWalletAddress(address);
    setWalletBalance(formattedBalance);
  };
  const handleImageChange = (e) => {
    setImage(e.target.files[0]);
    setImageStatus("Image selected for upload");
    setImagePreviewUrl(URL.createObjectURL(e.target.files[0]));
  };
  const mint = async () => {
    setStatus("Uploading to IPFS...");
    const imageURI = await uploadToIPFS(image);
    setIpfsLink(imageURI);
    setStatus("Minting NFT...");
    setLoading(true);
    const { signer, contract } = await connectWallet();
    const tokenURI = `data:application/json;base64,${btoa(
      JSON.stringify({
        name,
        description,
        image: imageURI,
      })
    )}`;
    const transaction = await contract.mintNFT(signer.getAddress(), tokenURI);
    await transaction.wait();
    setTransactionHistory((prevHistory) => [
      ...prevHistory,
      transaction.hash,
    ]);
    setStatus("NFT minted!");
    setAlertOpen(true);
    setLoading(false);
  };
  return (
    
    <Container maxWidth="lg">
      <Box sx={{ mt: 4, mb: 2 }}>
        <Typography variant="h4" align="center" gutterBottom>
          Shardeum NFT Minter
        </Typography>
      </Box>
      <Grid container spacing={2}>
        <Grid item xs={12} md={6}>
        <Box mt={2}>
              <Button
                fullWidth
                variant="contained"
                color="primary"
                onClick={handleConnectMetaMask}
                size="small"
                disabled={walletAddress} 
              >
                {walletAddress ? "Wallet Connected" : "Connect Wallet to Shardeum Sphinx Dapp 1.X"}
              </Button>
            </Box>
          {walletAddress && (
            <Box mt={2}>
              <Typography align="center">
                Wallet Address: {walletAddress}
              </Typography>
              <Typography align="center">
                Wallet Balance: {walletBalance} SHM
              </Typography>
            </Box>
          )}
          <TextField
            fullWidth
            label="NFT Name"
            variant="outlined"
            margin="normal"
            onChange={(e) => setName(e.target.value)}
          />
          <TextField
            fullWidth
            label="NFT Description"
            variant="outlined"
            margin="normal"
            onChange={(e) => setDescription(e.target.value)}
          />
          <input
            type="file"
            style={{ display: "none" }}
            id="image-upload"
            onChange={handleImageChange}
          />
          <p></p>
          <label      htmlFor="image-upload">
        <Button variant="contained" color="primary" component="span">
          Upload Image
        </Button>
      </label>
      {imageStatus && (
        <Typography variant="caption" display="block" gutterBottom>
          {imageStatus}
        </Typography>
      )}
      <Box mt={2}>
        <Button
          fullWidth
          variant="contained"
          color="secondary"
          onClick={mint}
        >
          Mint NFT
        </Button>
      </Box>
      {loading && <LinearProgress />}
      
      <Snackbar
        open={alertOpen}
        autoHideDuration={6000}
        onClose={() => setAlertOpen(false)}
        anchorOrigin={{ vertical: "top", horizontal: "right" }}
      >
        <Alert
          onClose={() => setAlertOpen(false)}
          severity="success"
          variant="filled"
          sx={{ width: "100%" }}
        >
          NFT minted successfully!
        </Alert>
      </Snackbar>
    </Grid>
    <Grid item xs={12} md={6}>
  <Box
    mt={2}
    sx={{
      border: "1px dashed #999",
      borderRadius: "12px",
      padding: "16px",
      display: "flex",
      justifyContent: "center",
      alignItems: "center",
      minHeight: "300px",
      background: imagePreviewUrl
        ? "none"
        : "linear-gradient(45deg, rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%)",
    }}
  >
    {imagePreviewUrl ? (
      <img
        src={imagePreviewUrl}
        alt="Uploaded preview"
        style={{
          width: "100%",
          maxHeight: "300px",
          objectFit: "contain",
          borderRadius: "12px",
        }}
      />
    ) : (
      <Typography variant="caption" color="text.secondary">
        Preview image will be displayed here
      </Typography>
    )}
  </Box>
</Grid>
    <Box mt={2}>
        <Typography align="center" color="textSecondary">
          {status}
        </Typography>
        {ipfsLink && (
      <Typography align="left">
    IPFS Link:{" "}
    <Link href={ipfsLink} target="_blank" rel="noopener noreferrer">
      {ipfsLink}
    </Link>
      </Typography>
)}
      </Box>
  </Grid>
  <Box mt={4}>
        <Typography variant="h7" align="center">
          Transaction History:
        </Typography>
        {transactionHistory.length > 0 ? (
          transactionHistory.map((hash, index) => (
            <Box key={index} mt={1} textAlign="left">
              <Link
                href={`https://explorer-dapps.shardeum.org/transaction/${hash}`}
                target="_blank"
                rel="noopener noreferrer"
              >
                {`Transaction ${index + 1}: ${hash}`}
              </Link>
            </Box>
          ))
        ) : (
          <Typography align="center" mt={1}>
            No transactions yet.
          </Typography>
        )}
      </Box>
</Container>
);
}
export default MintNFT;

• Theme.js: Este archivo contiene todos los temas necesarios para dar estilo a nuestra aplicación.

import { createTheme } from "@mui/material/styles";
const theme = createTheme({
  palette: {
    mode: "dark",
    
    primary: {
      main: "#ffc926",
    },
    secondary: {
      main: "#088ef3",
    },
  },
  typography: {
    fontFamily: "Roboto, Arial, sans-serif",
    h4: {
      fontWeight: 700,
      marginBottom: "16px",
    },
    h5: {
      fontWeight: 600,
      marginBottom: "12px",
    },
    h6: {
      fontWeight: 500,
      marginBottom: "8px",
    },
    subtitle1: {
      fontWeight: 400,
      marginBottom: "8px",
    },
    caption: {
      fontStyle: "italic",
    },
  },
});
export default theme;

Con los archivos anteriores, ahora tenemos la mayor parte de nuestro front-end cubierto. Realiza los cambios necesarios en App.js, App.css, index.js & index.css para incorporar todos los estilos e importar los archivos necesarios. Puedes encontrar los archivos finales para estos en el Github Jist aquí.

También puedes encontrar la aplicación completamente construida aquí. Siéntete libre para que coincida con su propio código siempre que se pegue.

4. Ejecutar la aplicación localmente

Ahora que tenemos todo el código necesario escrito, es el momento de ejecutar nuestra aplicación localmente. Ejecuta el siguiente comando para ejecutarlo en tu localhost.

npm start

Abre http://localhost:3000 en tu navegador web para empezar a utilizar tu aplicación recién creada para mintear NFT en Shardeum.

Aquí tienes una imagen de demostración de la aplicación:

Fuente de la traducción (9 de marzo de 2024): https://shardeum.org/blog/build-an-nft-minter-dapp-on-shardeum/

Shardeum’s Blast Off: un logro revolucionario

El lunes 27 de enero de 2024 se produjo un acontecimiento sin precedentes en el mundo de la web3 que puede compararse a la hazaña histórica de una nave espacial que regresa sin problemas a su plataforma de lanzamiento tras su primera misión de vuelo de prueba. En este extraordinario escenario, Shardeum no sólo se enfrentó a un reto formidable, sino que también salió triunfal, con la capacidad de recuperación de su red marcando la primera vez que una red fragmentada se ha auto-restaurado en el ámbito de la tecnología de ledger distribuido.

Al igual que el viaje de una nave espacial implica una planificación meticulosa, ingeniería de precisión y la ejecución perfecta de maniobras complejas, la restauración por Shardeum de su betanet Sphinx, que había sufrido un accidente crítico, requirió un nivel equivalente de dominio tecnológico e innovación. La capacidad de preservar todos los datos de una red, sobre todo de una que funciona con fragmentación dinámica de estados, no tiene nada de innovador.

Al embarcarnos en esta exploración, no sólo celebramos el trascendental aterrizaje de Shardeum, sino que lo reconocemos como un momento crucial en la evolución de la tecnología web3, un salto que podría redefinir los límites de la resistencia de las redes informáticas y la integridad de los datos.

Primera red fragmentada que se autorrestaura y conserva los datos

Mantener y restaurar una red fragmentada dinámicamente, como Shardeum, conlleva una serie de complejos retos técnicos que la diferencian de las redes blockchain tradicionales como Bitcoin o Ethereum. En un entorno de fragmentación dinámica con autoescalado, la reasignación y el equilibrio continuos de nodos y recursos entre diferentes fragmentaciones son cruciales para optimizar el rendimiento y la escalabilidad. Este flujo constante en la arquitectura de red añade una complejidad significativa a la hora de mantener la coherencia de los datos, garantizar la estabilidad de la red y facilitar una recuperación eficaz de los fallos.

La criticidad de estos retos se acentúa al contrastar la respuesta de Shardeum a las fluctuaciones de los nodos con la de Bitcoin. La red Bitcoin mantiene su funcionalidad incluso con un número mínimo de nodos, ya que cada nodo completo posee el estado completo y el historial de transacciones. Por el contrario, cada nodo activo de Shardeum no posee el estado completo ni el historial de transacciones, ya que la red Shardeum está fragmentada y cada validador sólo posee un subconjunto del estado completo. La consecuencia de esta fragmentación es que todos los nodos validadores son extremadamente ligeros. Esto crea una plétora de oportunidades y retos de ingeniería. Si un nodo se cae, ¿cómo nos aseguramos de que se conservan todos los datos? Shardeum tiene dos formas principales.

En primer lugar, Shardeum utiliza la fragmentación dinámica de estados, en la que el espacio global de direcciones se particiona (o divide) en función del número de nodos activos. Cada nodo es responsable de sus particiones asignadas, junto con un determinado 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 en el marco de la red. Así, aunque un nodo se caiga, sigue habiendo continuidad en la red y no se pierden datos.

En segundo lugar, Shardeum utiliza nodos archivadores para almacenar el estado completo de toda la red. Para ello, los nodos activos envían sus estados parcialmente almacenados a los archivadores para que los recojan. Debido a estos dos factores y a las optimizaciones de diseño, la restauración de una red de este tipo tiene que diseñarse de forma novedosa para seguir facilitando características ventajosas como el autoescalado y el escalado lineal.

Entendiendo el Choque

Ahora que entendemos los fundamentos de la fragmentación dinámica de estados y que los nodos archivadores están implicados de alguna manera, vamos a desentrañar primero algunos componentes adicionales más profundamente y a explicarlos. Para entender la caída y la restauración de la betanet Shardeum, primero debemos entender un poco lo siguiente:

• Nodos archivadores

• Detección de archivadores perdidos

• Modos de red

• Modo de recuperación

Entender lo básico de cada uno de ellos es necesario antes de sumergirnos de cabeza en los fallos, ¡así que echemos un vistazo!

Nodos archivadores: Almacenamiento interestelar

En Shardeum, los nodos archivadores, también llamados archiveros, constituyen una categoría crítica de nodos, encargados de preservar el estado completo y los registros históricos de la red. A diferencia de los nodos activos, los archivadores no participan en los procesos de consenso; su función principal es archivar exhaustivamente la totalidad de los datos de la red, incluidas las transacciones y los recibos. La contribución de los nodos archivadores es esencial para mantener la integridad de la red y garantizar su perfecto funcionamiento, afirmando así el estatus de Shardeum como una red robusta, completa y fiable. Debido a que los archivadores son parte integral de la red, Shardeum debe tener un protocolo para detectar cualquier archivador (y validador) que no responda.

Detección del Archivador Perdido: Tecnología alienígena al descubierto

Shardeum tiene un protocolo llamado detección de nodos perdidos que detecta cuando los nodos activos dejan de funcionar — esto está reservado únicamente para los nodos activos. Sin embargo, Shardeum también tiene un protocolo para los archivadores que hace algo similar llamado detección de archivador perdido. La detección de archivadores perdidos es un protocolo especializado diseñado para manejar escenarios raros en los que uno o más archivadores dejan de estar operativos y se marcan como perdidos. Dado que los nodos archivadores son fundamentales para mantener la integridad y accesibilidad de los datos históricos dentro de la red, es esencial que, en las raras ocasiones en que no respondan o no funcionen, se detecten estos eventos críticos para mitigar cualquier efecto posterior. Aunque la pérdida de archivadores no causó este fallo en particular, sí lo hizo la interacción entre el protocolo de detección de pérdida de archivadores y un modo de red específico. Examinemos ahora cuáles son los modos de red en Shardeum.

Modos de red en Shardeum: No se necesita a la NASA

Una innovación emblemática de Shardeum, impulsada por el protocolo subyacente Shardus, es el marco de modos de red. Estos modos trascienden los estados operativos básicos y encarnan una intrincada coordinación de diversas actividades de nodos, métodos de sincronización de datos y sistemas de gestión de transacciones. Estas configuraciones de red desempeñan un papel crucial en la preservación 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 fragmentada.

A un nivel más simple, la mejor manera de concebir los modos de red en Shardeum es como planes de contingencia codificados que permiten la continuidad de las operaciones de toda la red, incluso en condiciones improbables como la caída de la red o la degradación de toda la red. Esta resistencia y robustez operativas preprogramadas garantizan que Shardeum siempre seguirá viva, sea cual sea la adversidad a la que se enfrente la red.

Aunque para entender el fallo no hace falta digerir todas las facetas del marco de los modos de red, sí ayuda familiarizarse con lo básico. Un elemento central del marco de modos de red es la incorporación de varias fases de red distintas: Formación, Procesamiento, Seguridad, Recuperación, Reinicio, Restauración y Apagado. Estos modos están cuidadosamente diseñados para hacer frente a diversas situaciones y emergencias de la red. Sin embargo, el modo que nos ocupa en este artículo es el de recuperación.

Modo de recuperación de ingeniería inversa: Rosewell revisitado

El modo de recuperación es 1 de los 7 modos de red antes mencionados. El modo de recuperación se inicia cuando el recuento de nodos activos de la red desciende por debajo de un umbral crítico predefinido (actualmente configurado en 75% o inferior). Este umbral es ajustable según los requisitos de la red. En este modo, la red detiene temporalmente 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 mediante la introducción gradual de nodos de reserva como parte de la rotación de nodos, restaurando así el recuento de nodos activos a un nivel óptimo, idealmente por encima del 100%.

Durante el modo de recuperación, la arquitectura de red de Shardeum permite un aumento incremental de los nodos, con un tope del 20% de crecimiento por ciclo (cada ciclo dura aproximadamente 60 segundos). Este ritmo de crecimiento controlado es fundamental para mantener la estabilidad de la red y garantizar una integración perfecta de los nuevos nodos. Un aumento rápido del número de nodos, por ejemplo del 50%, podría desestabilizar la red y complicar el proceso de integración.

Cada nuevo nodo añadido necesita recursos de red para su sincronización e integración. Al limitar el aumento al 20% por ciclo, la red se asegura de que su infraestructura pueda soportar adecuadamente la adición de nuevos nodos sin tensiones. Este enfoque no sólo preserva la estabilidad de la red, sino que también minimiza el riesgo de incoherencias o errores en los datos durante el proceso de sincronización, manteniendo así la integridad de los datos de la cadena de ciclos.

La causa principal del accidente: Horizonte de sucesos

Es importante señalar que había dos errores distintos. El bug de la librería neon — que causaba que los validadores se bloquearan aparentemente al azar y un bug en el protocolo de detección de archivadores perdidos — que no aceptaba una lista de validadores vacía. Aunque es el bug del protocolo de detección de archivadores perdidos el que causó el fallo de la versión betanet, me gustaría explicarles primero el bug de la librería neon.

En la versión Sphinx 1.9.1, integramos una actualización a una librería que emplea Neon bindings para unir funcionalidades Rust y TypeScript ya que Shardeum está construido predominantemente en TypeScript. Neon es reconocido por su enfoque innovador, aunque experimental, a menudo empujando los límites de las prácticas convencionales de desarrollo de software. Esta integración tenía 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 provocó un error que hacía que los nodos abandonaran aleatoriamente la red.

En segundo lugar, en el reciente incidente que provocó la caída de la betanet en Shardeum, la causa principal se identificó como una anomalía crítica originada por la interacción entre los dos subsistemas distintos antes mencionados: el mecanismo de detección de archivadores perdidos y el protocolo de modo de recuperación de la red.Este breve fallo se precipitó por la activación simultánea de estos dos mecanismos, un escenario no encontrado ni probado anteriormente. El proceso de archivador perdido se activó junto con el mod de recuperación de red y debido a un fallo en el modo de archivador perdido que no aceptaba una lista de nodos activos vacía. Esto culminó en la caída de la red.

Crónicas de la recuperación: Del shock sistémico a la recuperación estelar

¿Qué más ocurrió realmente y cuándo? La cronología de los acontecimientos que rodearon la caída de la red y su resolución es la siguiente:

1. Vulnerabilidad inicial y actualización: La red se encontró con una vulnerabilidad señalada por el proceso 1.9.1 linting dentro de una biblioteca npm (neon). Se implementó una actualización para solucionar este problema. Sin embargo, esta actualización introdujo inadvertidamente una excepción que no se reprodujo durante las pruebas locales.

2. Excepción intermitente en la biblioteca que provoca cierres del validador: La biblioteca neon experimentaba excepciones esporádicas que provocaban cierres periódicos de los validadores de red. Aunque el diseño de la red permitía la resistencia mediante el rellenado de estos validadores y, por desgracia, la sincronización de fallos simultáneos entre varios validadores activó el modo de recuperación de la red.

3. Activación del modo de recuperación de la red: Una vez en el modo de recuperación de la red, el protocolo necesitó borrar y regenerar la lista de nodos activos. La causa principal de la caída de la red fue un fallo simultáneo en el sistema de archivo de pérdidas, que no admitía una lista de validadores vacía.

4. Resolución y restauración de la red: Se rectificó el fallo y la red se restauró con éxito utilizando los datos almacenados en los archivadores. Es la primera vez en la historia que una red fragmentada de capa 1 que se ha bloqueado se restaura con éxito y todos los datos de la red se conservan intactos. Esto no se había conseguido nunca en ninguna red, y mucho menos en una red con fragmentación dinámica de estados. Este logro marcó el exitoso “aterrizaje del cohete” en términos de recuperación de redes.

5. Correcciones realizadas: Se implementó una corrección preliminar para solucionar el problema 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 introdujo un fallo singular pero crucial. Esta actualización introdujo una corrección de errores singular pero crucial que abordaba otro caso del fallo de enlace de neon, señalando y rectificando una vulnerabilidad específica sin obligar a una actualización de toda la red. Inicialmente, los usuarios que utilizaban la versión 1.9.4 tenían la posibilidad de permanecer en su versión actual u optar por la actualización a la 1.9.5, en función de sus preferencias de rendimiento y estabilidad de la red. Sin embargo, finalmente se decidió que, con el fin de mejorar la estabilidad de la red y resolver los problemas persistentes relacionados con los enlaces de neon, la versión mínima requerida para los validadores debía aumentarse a 1.9.5. Con esta actualización se pretendía excluir sistemáticamente a los validadores que funcionan con la versión 1.9.4, que se han identificado como susceptibles de bloquearse debido a la complicación de los neon bindings antes mencionada. Esto es necesario para asegurarse de que el fallo de neon está totalmente anulado y completamente solucionado.

Ahora que conocemos la cronología y cómo se desencadenaron los principales acontecimientos, echemos un vistazo a lo que ocurrió para que la red se restableciera tan rápidamente.

Rumbo a la restauración

Recuperación ágilLa restauración de la red constó de muchas partes, pero una de las fundamentales fue el modo de recuperación de Shardeum. Como ya se ha dicho, el modo de recuperación se inicia cuando el recuento de nodos activos de la red desciende por debajo de un umbral crítico predefinido y permite un crecimiento rápido, controlado y eficaz de la red de forma segura para restaurarla. Es importante destacar que, sin el ingenio tecnológico de los diseñadores y desarrolladores de los modos de red, Shardeum no habría podido recuperarse de la caída con tanta facilidad ni hacer gala de su capacidad innovadora.

Además, el equipo técnico de Shardeum realizó esfuerzos clave al lanzarse a la acción inmediata. El primer paso consistió en un análisis exhaustivo para identificar la causa de la caída, que se atribuyó a una anomalía en la interacción entre la detección de archivos perdidos de la red y sus sistemas de modo de recuperación. Consciente de la complejidad del problema, el equipo aplicó rápidamente un enfoque polifacético para hacer frente tanto a las consecuencias inmediatas como a las vulnerabilidades subyacentes.

Respuesta polifacética del equipo técnico de Shardeum

Técnicamente, la respuesta fue polifacética: en primer lugar, el equipo aisló los componentes afectados para evitar una mayor degradación de la red. Al mismo tiempo, desplegaron un parche para rectificar el error en el sistema de archivo perdido, asegurándose de que podía manejar una lista de validadores vacía, un descuido crítico que había precipitado el fallo de la red. Para restablecer la plena capacidad operativa de la red, se activaron los datos conservados en los archivadores y se utilizaron para reconstruir el estado de la red antes de la caída, garantizando que no se perdieran datos en el proceso.

Desde el punto de vista logístico, el equipo se coordinó a través de diferentes zonas horarias y disciplinas, aprovechando las herramientas basadas en la nube para la colaboración y la supervisión en tiempo real. Este esfuerzo coordinado no solo facilitó el rápido desarrollo y despliegue de las correcciones, sino que también garantizó que todos los miembros del equipo estuvieran alineados en el proceso de recuperación y los siguientes pasos.

Este incidente sirvió como rigurosa prueba de los protocolos de gestión de accidentes de Shardeum y puso de relieve la importancia de las respuestas ágiles e innovadoras a los retos imprevistos. Subraya el compromiso del equipo de mantener una red resistente y segura, preparada para afrontar los complejos obstáculos técnicos que surjan.

Aterrizaje seguro e innovación espacial

En conclusión, la exitosa restauración de la red fragmentada de Shardeum anuncia un cambio significativo en la tecnología de redes, marcando un hito con implicaciones de largo alcance para la industria. Aunque actualmente no se reconocen en gran medida, innovaciones como los modos de red acabarán estableciendo nuevas normas industriales en la web3.

Creo desde hace tiempo que las innovaciones fundamentales de Shardeum influirán con toda probabilidad en futuros avances tecnológicos, inspirando innovaciones y nuevas generaciones de tecnologías de libro mayor. Habiendo sido testigo de primera mano de la restauración de la red de Shardeum, la primera de su clase, sé que esto catalizará una reevaluación de los estándares de la industria, lo que potencialmente conducirá a la adopción de protocolos y metodologías más rigurosos en el diseño y la arquitectura de la red.

Este acontecimiento no sólo pone de manifiesto la destreza técnica y la innovación del equipo de Shardeum, sino que también señala el comienzo de una era en la que las redes descentralizadas son más robustas, adaptables y capaces de hacer frente a retos imprevistos en la planificación de la recuperación en caso de catástrofe. En última instancia, la tecnología de Shardeum anunciará una nueva era de descentralización.

Fuente de la traducción (19 de febrero de 2024): https://shardeum.org/blog/shardeum-resilience-restoring-sharded-network/