Preparando el Ledger de IOTA para la Web3
TL;DR:
Stardust transforma IOTA en una capa de infraestructura para cadenas de contratos inteligentes e introduce tokens personalizados. El nuevo ledger es capaz de realizar transferencias condicionales y los NFTs pueden funcionar como monederos, mientras que las mejoras adicionales del protocolo protegen los recursos de los nodos, eliminan las suposiciones de confianza del lado del cliente y mejoran las capacidades de equilibrio de carga de la red. Stardust debuta en la nueva red Shimmer antes de ser portado a la red principal de IOTA.
El protocolo IOTA está preparado para recibir su mayor actualización de utilidad después de Chrysalis: Stardust se basa en la actualización de la red Chrysalis del año pasado y añade una utilidad sin precedentes. En esta entrada del blog, exploramos los orígenes de Stardust y los beneficios detallados que traerá a la mesa. Si desea una introducción resumida, consulte Stardust en pocas palabras.
La actualización Chrysalis del año pasado aportó importantes mejoras en el rendimiento, la estabilidad, la fiabilidad y la seguridad de IOTA, al tiempo que eliminó conceptos innecesariamente complejos y poco ortodoxos, y en su lugar los simplificó y alineó con los estándares y las mejores prácticas de la industria. El protocolo Chrysalis ha estado funcionando de forma estable en la red principal de IOTA desde entonces y los esfuerzos del protocolo se han concentrado en Coordicide con el objetivo de una descentralización a gran escala, que actualmente se está probando a través de la implementación de IOTA 2.0 DevNet.
¿Por qué necesitamos entonces Stardust como paso intermedio entre Chrysalis y Coordicide?
Paralelamente a nuestro trabajo en Coordicide, hemos estado construyendo el protocolo IOTA Smart Contract (ISC) sobre la IOTA 2.0 DevNet. El ISC Beta se lanzó en la DevNet el pasado mes de octubre y su protocolo de capa base recibió soporte para acomodar adecuadamente los contratos inteligentes.
Hemos aprendido mucho de esta fase y hemos identificado que las necesidades de ISC en el actual protocolo IOTA no están totalmente cubiertas por los esfuerzos de descentralización de Coordicide. Por lo tanto, es un paso lógico para portar las nuevas características del protocolo a la red principal de IOTA tan pronto como sea posible para permitir a nuestra comunidad comenzar a construir casos de uso basados en contratos inteligentes en la red principal de IOTA. La actualización de Stardust nos permite habilitar el soporte de contratos inteligentes en la red principal, antes de Coordicide.
Stardust se estrenará en Shimmer, la red de ensayo de IOTA, y se someterá a pruebas exhaustivas y a la validación de la comunidad. Para cuando llegue a la red principal de IOTA, nuestra comunidad habrá tenido tiempo de aprender los entresijos del nuevo protocolo y construir aplicaciones y herramientas. De este modo, las dApps podrán lanzarse en la red principal de IOTA junto con el nuevo protocolo.
¿Por qué Stardust?
Naturalmente, surge la pregunta: ¿por qué necesitamos modificar el protocolo actual de IOTA para permitir la ejecución de contratos inteligentes sobre él?
La respuesta es sencilla. El enfoque de segunda capa empleado por ISC permite un escalado horizontal y niveles de rendimiento sin precedentes, pero se basa en el protocolo IOTA de base para proporcionar la infraestructura de confianza para la interoperabilidad.
La palabra clave aquí es infraestructura. Piensa en el Tangle como el sistema de autopistas interestatales: proporciona los medios para que las personas y los bienes fluyan libremente entre los estados, al igual que el protocolo Stardust permite que los activos digitales y la información viajen entre las cadenas de contratos inteligentes, cada una de ellas funcionalmente equivalente a una blockchain como Ethereum que se conecta a través del Tangle de IOTA.
La propiedad feeless del protocolo preserva el valor para las transferencias de valor entre cadenas.
El modelo UTXO puede ampliarse con una lógica de aplicación especial para operaciones atómicas sin confianza.
En la actualidad, el ledger de Chrysalis está optimizado para una única aplicación: los pagos de criptomonedas. Stardust pretende cambiar esto y transformar IOTA en una capa de infraestructura para las cadenas de contratos inteligentes, convirtiéndolo al mismo tiempo en un ledger multiactivos. Además, los nuevos tipos de salida en Stardust le permitirán escribir datos arbitrarios directamente en el estado del ledger, lo que significa que estos conjuntos de datos no son podados por los nodos de la red principal después de algún tiempo como es el caso de los mensajes de datos puros en la Tangle.
Requisitos del contrato inteligente
¿Qué necesita una cadena de contratos inteligentes IOTA para funcionar en la capa de infraestructura IOTA?
1 -Una cuenta de ledger con una dirección permanente que es controlada por un comité rotativo para enviar y recibir tokens.
2 -Un lugar para almacenar los compromisos de estado o state commitments de la cadena de capa 2 (L2).
3 -Tokens personalizadas para las transferencias de activos entre cadenas.
4 -Medios para facilitar la interacción de los usuarios.
Chrysalis no soporta ninguna de estas características. El diseño del protocolo Stardust presenta una solución novedosa a los retos enumerados anteriormente al ampliar la validación de transacciones y el desbloqueo de salidas en el ledger de capa 1 (L1) con scripts configurables, los llamados tipos de salida, condiciones de desbloqueo y características de salida.
Exploremos las soluciones con más detalle.
Una nueva cuenta del ledger
Sin embargo, las cuentas de la cadena de contratos inteligentes son controladas por un conjunto de validadores que se unen para producir una dirección de firma común que sólo puede ser desbloqueada si un número umbral de partes proporcionan sus firmas. Cada vez que se cambia el conjunto de validadores, hay que crear una nueva dirección común.
Como resultado, el concepto de dirección tradicional no puede proporcionar una dirección permanente para las cuentas de la cadena de contratos inteligentes. En su lugar, se necesita una nueva forma de pensar en las cuentas del ledger:
¿Qué pasaría si pudiéramos generar y hacer un seguimiento de las direcciones únicas a nivel de protocolo que pueden rotar las claves privadas reales utilizadas para firmar las transacciones?
Para que esto funcione, tenemos que averiguar cómo:
- Generar direcciones únicas de forma determinista,
- Persistir su estado y las claves de control a través de las transacciones.
El primer reto es el más fácil. Cada transacción en el ledger es única, por lo que podríamos derivar una dirección única del contenido de la transacción que la crea. Comprobación.
El segundo reto requiere la modificación de las reglas de validación de transacciones del ledger para permitir la definición de restricciones adicionales en el contexto de las transacciones. También se requiere una nueva estructura de datos para almacenar la dirección única y la información del propietario de la dirección. En resumen, tenemos que diseñar un nuevo tipo de salida que contenga datos y que, cuando se incluya en las transacciones, ejecute una lógica de validación adicional.
La salida de alias implementa esta estructura de datos e introduce la dirección de alias como una cuenta del ledger. Siempre que se crea por primera vez una salida de alias en el ledger, el protocolo genera una dirección única y la registra en la propia salida, junto con las direcciones respaldadas por claves privadas que la controlan en ese momento. Estos controladores de la cuenta de alias pueden incluir la salida en las transacciones para modificarla según las reglas definidas en su script de validación configurable.
Por ahora, basta con saber que la validación garantiza que:
- La propia salida de alias está presente en el lado de salida de la transacción. Su estado es persistente.
- Las funciones del controlador pueden transferirse a cualquier otra dirección del ledger.
- Cualquier fondo en el ledger bloqueado bajo la dirección permanente del alias puede desbloquearse demostrando la propiedad de la propia salida del alias; es decir, demostrando que uno es el controlador y es capaz de desbloquear la salida.
Almacenamiento de compromisos de estado
Stardust permite almacenar datos arbitrarios en las salidas a través de una función llamada función de metadatos. Las cadenas de contratos inteligentes pueden, por tanto, almacenar sus compromisos de estado directamente en su cuenta del ledger.
Sin embargo, la cuestión del almacenamiento de datos en las salidas arroja luz sobre un problema más general: el tamaño del ledger. Cuanto mayor sea el tamaño del ledger, mayor será la carga impuesta al hardware físico que hace funcionar los nodos de la red. Todos sabemos que no existen recursos infinitos en el mundo físico, por lo que se necesita un sistema que regule el almacenamiento de datos y, por tanto, el tamaño del ledger. Así pues, se han creado los depósitos de almacenamiento.
Mecanismo de depósito de almacenamiento
Los depósitos de almacenamiento protegen la red de un exceso de dust. El término «protección contra el dust» proviene de la forma en que el tamaño del ledger puede inflarse distribuyendo los fondos en trozos cada vez más pequeños (llamados «dust o polvo») que obligan a todos los nodos de la red a almacenar más y más cuentas que contienen sólo una pequeña cantidad de tokens. Como ejemplo: en el momento de escribir este artículo, por el precio de 100 dólares un atacante podría crear 100.000.000 de direcciones que contengan un IOTA cada una. Cada entrada en el ledger de la red requiere una pequeña cantidad de datos que deben gestionar los nodos. Por lo tanto, si no se mitiga adecuadamente, el polvo puede convertirse en un problema importante en las redes que no requieren tarifas de transacción.
Chrysalis ya ha implementado una solución para este problema, aunque no sin advertencias. El problema del hinchamiento de la base de datos es menos transparente en Chrysalis porque las entradas del ledger son fijas y de pequeño tamaño. Además, no es posible almacenar datos definidos por el usuario en las cuentas del ledger.
Stardust introduce una nueva solución que limita la cantidad de datos que se almacenan en las cuentas del ledger en relación con la cantidad de fondos (depósitos) que contienen. Al tener fondos, se alquila espacio de almacenamiento en el ledger. Es importante tener en cuenta que el almacenamiento debe regularse en función de un recurso escaso; de lo contrario, el tamaño del ledger podría crecer indefinidamente.
También hay que tener en cuenta que, por el mero hecho de tener una cuenta en el ledger, el almacenamiento permanente de datos ya está forzado en todos los nodos de la red. Por lo tanto, se requiere que una cuenta tenga una cantidad mínima de fondos para ser creada. Los mismos principios están presentes en Bitcoin y Cardano, pero los ataques de hinchamiento de la base de datos tienen menos probabilidades de manifestarse en ellos debido al factor disuasorio de las tasas de transacción.
Tokens personalizados
En cuanto los tokens pudieron desplegarse en plataformas de contratos inteligentes, el número de nuevos tokens (como ERC-20 o ERC-721) en el espacio de las criptomonedas creció exponencialmente. Son una parte vital del ecosistema de las dApps y ayudan a los proyectos a recaudar capital, implementar estructuras de gobierno novedosas o proporcionar acceso a características únicas.
ISC apoya la máquina virtual Ethereum (EVM) y la creación de dichos tokens en L2. Pero si los tokens personalizados se crean en la capa 2, ¿cómo pueden trasladarse dichos tokens entre diferentes cadenas de contratos inteligentes? Otras redes suelen requerir la implementación de un puente para trasladar entre dos cadenas, pero estos puentes están muy centralizados, son objetivos de alto valor y, en consecuencia, suelen ser hackeados, como se demostró en el último hackeo del puente Ronin.
Stardust implementa el marco de tokenización de IOTA, que está diseñado para ser una solución de puente integrada en el protocolo, sin confianza y atómica para las transferencias de activos entre cadenas ISC. En resumen: con Stardust, no hay necesidad de construir ningún puente complicado. El IOTA Tangle, al que están conectadas todas las cadenas, es el puente.
El núcleo del marco es la transformación del ledger de IOTA en un ledger multiactivo. Cualquiera, incluidas las cadenas de contratos inteligentes, puede crear tokens personalizados controlados por la oferta directamente en el L1 Tangle. Esta es la base de la envoltura de activos, un mecanismo que permite la creación de representaciones L1 de activos procedentes de cadenas de contratos inteligentes. Una vez envueltos y representados en la capa base de IOTA, los activos pueden ser enviados sin problemas a otra dirección en el ledger de IOTA, incluyendo direcciones controladas por otras cadenas L2.
Tokens nativos
Las transacciones con tokens nativos se realizan mediante transferencias regulares y todos los tipos de salida posibles admiten su tenencia, ya sean cuentas de cadenas de contratos inteligentes o direcciones regulares. Debido al mecanismo de depósito de almacenamiento descrito anteriormente, una transferencia siempre debe incluir la moneda base de la red para cubrir el almacenamiento de la red, lo que hace que las transferencias de tokens nativos puros sean ligeramente más complicadas. Tengan por seguro que todos los requisitos se abstraerán de los usuarios finales a través de interfaces gráficas de usuario como Firefly. Exploraremos los requisitos para las transferencias nativas de activos más adelante en esta entrada del blog.
La versión inicial de Stardust se lanzará con soporte para el esquema de tokens simples. Los esquemas de tokens definen las reglas de control de la oferta, es decir, lo que los emisores de tokens pueden hacer. El esquema simple pone un límite superior a la oferta total de tokens, garantizando que no hay forma de que los emisores inflen la oferta más allá de la oferta máxima definida al crear el token.
Tokens no fungibles
NFTs en Stardust:
Reciben un identificador único global en el momento de la acuñación o minteo que también funciona como una dirección permanente controlada por el propietario actual.
Pueden tener un conjunto de datos inmutables en el momento de la acuñación, que son transportados por el NFT durante toda su vida.
Puede tener también un conjunto de identidades inmutables del emisor en el momento del minteo.
Puede poseer otros NFT, tokens o cualquier activo tanto en la capa base como en las cadenas de contratos inteligentes. Cada NFT funciona como un monedero independiente con una dirección permanente.
Pueden ser quemados por sus propietarios; por ejemplo, para liberar tokens encerrados en ellos que puedan ser requeridos como depósito.
Interacción del usuario con los contratos inteligentes
Hasta ahora se han discutido las características para la creación de cadenas de contratos inteligentes, el almacenamiento de compromisos de estado y las transferencias de activos entre cadenas. ¿Cómo interactúan los usuarios normales con las cadenas?
ISC define dos tipos de interacción con las cadenas de contratos inteligentes:
Como su nombre indica, las solicitudes fuera del ledger se envían directamente a la cadena de contratos inteligentes L2, por lo que no son de interés para el protocolo Stardust. Las solicitudes On-ledger, por otro lado, requieren un soporte especial del protocolo base, implementado en Stardust a través de dos nuevas salidas, Condiciones de Desbloqueo y Características de Salida.
Condiciones de desbloqueo en el Output
Una solicitud en el ledger es un output de transacción que se envía a la dirección de la cadena del contrato inteligente en L1. Como tal, el output sólo debe ser desbloqueable por la cadena de contratos inteligentes para que la solicitud sea procesada.
En Stardust, esta característica está soportada por la Condición de Desbloqueo de la Dirección (Address Unlock Condition), que no es más que una generalización del concepto de bloqueo de la salida en Chrysalis y ampliado con los nuevos tipos de dirección.
Una solicitud en el ledger puede depositar activos nativos en la cadena (tokens nativos o NFTs). Como se ha discutido antes, el envío de tokens nativos sin involucrar la moneda base no es posible, y es una demanda bastante dura para los usuarios depositar siempre tokens base junto con tokens nativos en las cadenas. Por lo tanto, una nueva Condición de Desbloqueo del Depósito de Almacenamiento hace posible reclamar automáticamente el depósito de almacenamiento de las salidas por parte del remitente
Si Alice desea enviar exactamente un AliceCoin a Bob, crearía una salida (output) en la dirección de Bob con Cantidad de Depósito de Almacenamiento de Tokens IOTA + 1 AliceCoin y definiría una condición de devolución que espera que le devuelvan la Cantidad de Depósito de Almacenamiento de Tokens IOTA. Bob sólo puede consumir esta salida en una transacción si devuelve a Alice al menos esa cantidad de IOTAs.
¿Qué pasa si Bob nunca consume la salida? ¡El depósito de Alice está bloqueado para siempre! Por eso Alice es lo suficientemente inteligente como para definir una Condición de Desbloqueo de la salida o output. Ella puede establecer una fecha límite de expiración hasta la cual Bob tiene que consumir la salida, de lo contrario su propiedad revierte exclusivamente a Alice.
Esto también funciona bien para las solicitudes en el ledger: se puede especificar que la cadena del contrato inteligente sólo puede tomar el activo nativo de la salida, pero debe devolver el depósito de almacenamiento. Con la caducidad, el usuario se asegura de que la solicitud sea procesada por la cadena dentro del plazo establecido o se cancele por completo. Es una característica única de Stardust y del sistema ISC.
Características del output o salida
- Ella prepara una transacción IOTA en la que crea una salida o output (solicitud en el ledger) con fondos a la dirección permanente de la Cadena A.
- En la función de metadatos de la salida, codifica los datos de la llamada: «llamar al punto de entrada X del contrato inteligente Y con los parámetros A, B y C»
- Tan pronto como la transacción se confirma en IOTA, la Cadena A reconoce que hay una nueva solicitud en el ledger en su dirección.
- La cadena A recoge la solicitud y ejecuta la llamada codificada en la función de metadatos, avanzando el estado L2 de la cadena de bloques y liquidando el resultado en IOTA a través de una transacción de anclaje de actualización de estado.
Todas las condiciones y funciones de desbloqueo son compatibles con las Salidas o Outputs Básicas, que son el vehículo principal para las solicitudes en el ledger, así como con las Salidas NFT.
Mejoras adicionales del protocolo
Protección contra repeticiones
Las transacciones en DLT son instrucciones firmadas que modifican el estado del ledger. La existencia de redes paralelas con la misma funcionalidad del ledger (pensemos en Shimmer e IOTA) abre la posibilidad de ataques de repetición, que es cuando un atacante reedita una transacción firmada válida en otra red.
Para evitar la más mínima posibilidad de que esto ocurra, Stardust introduce un campo de identificador de red en el contenido de las transacciones firmadas. Como resultado, incluso si una transacción es correcta en otros aspectos, una red diferente a la prevista la rechazaría inmediatamente basándose en la falta de coincidencia del identificador de red.
Compromiso de los inputs
En un ledger basado en UTXO, las transacciones hacen referencia a las entradas o inputs que desean consumir mediante sus identificadores únicos. Los clientes recogen el contenido de las entradasaccediendo a los identificadores de las entradas en los nodos. Si no tienes tu propio nodo, tu monedero probablemente habla con una aplicación exploradora o indexadora que a su vez obtiene datos de un nodo de la red. ¿Confías plenamente en que un tercero te dé el contenido correcto de las entradas que te pertenecen para construir una transacción? ¿Y si su infraestructura es pirateada?
Por suerte, con Stardust no es necesario confiar en terceros. Las transacciones incluyen un campo de compromiso de entradas que (como su nombre indica) es un compromiso criptográfico del contenido de las entradas de la transacción. Si por alguna razón tu monedero recibió datos maliciosos y construyó una transacción basada en esos datos, la red se dará cuenta de que hay un desajuste entre lo que la red cree que son tus entradas y lo que hace tu monedero.
Este mecanismo no sólo protege a los usuarios, sino también a las cadenas de contratos inteligentes. Un atacante podría eclipsar la conexión de los validadores L2 con los nodos L1 y empezar a sustituir el contenido de las peticiones para robar los fondos de los usuarios, pero con este mecanismo de seguridad, esas transacciones maliciosas serían rechazadas por el protocolo base, haciendo que la cadena se dé cuenta de que ha sido eclipsada porque no ha producido una actualización de estado válida.
Descargando el procesamiento de datos del protocolo base
IOTA es único en el sentido de que proporciona transacciones sólo de datos en el Tangle. Sin embargo, los casos de uso que se basan en esta característica se enfrentan a dos grandes problemas:
- La Tangle no tiene permisos, por lo que cualquiera puede enviar mensajes de datos con cualquier contenido y los mensajes no están autenticados con firmas como las transacciones de valores. La fuente de los datos publicados a través de Tangle no es identificable por el protocolo central.
- Las aplicaciones de uso de datos a menudo dependen de datos estructurados, filtrados y procesados específicos de la aplicación. Esta funcionalidad supone una carga innecesaria para los nodos de la red que ejecutan el protocolo central.
Un ejemplo de esto último es la función de indexación de datos presente en la actualización de Chrysalis. Los clientes de aplicaciones de uso de datos quieren ser capaces de obtener datos del Tangle que sean de su interés, por lo que los datos deben ser indexados para soportar las consultas de los clientes. Como se ha descrito anteriormente, Chrysalis no impide que se llenen los índices de datos, lo que podría romper la funcionalidad del cliente si no se implementa ninguna mitigación.
Stardust elimina cualquier tipo de procesamiento de datos del protocolo central, ya que el apoyo a los requisitos de procesamiento de casos específicos en el protocolo central es inviable – y de todos modos, pondría en peligro el rendimiento de los nodos y por lo tanto el rendimiento de las transacciones en la red.
El software de nodo rediseñado proporciona una interfaz de Llamada de Procedimiento Remoto (gRPC), llamada IOTA Node Extension (INX) para que las aplicaciones externas interactúen con los nodos, por ejemplo para escuchar toda la actividad de la red. Se anima a los usuarios de datos a construir sus aplicaciones de procesamiento de datos personalizadas y conectarlas al Tangle a través de INX.
Prueba de trabajo dinámica
La prueba de trabajo (PoW) se emplea actualmente en IOTA para el control de la congestión. Cada transacción debe incluir una pequeña cantidad de trabajo computacional para ser considerada válida. Tenga en cuenta que, mientras que en las redes de blockchain los mineros compiten para resolver el rompecabezas criptográfico de PoW primero y gastan una gran cantidad de energía en el proceso, los usuarios de IOTA que envían transacciones a la red participan en un esfuerzo cooperativo.
Chrysalis tiene un factor de dificultad PoW fijo para una unidad de datos enviada a la red. Por lo tanto, la complejidad real del desafío para una transacción depende únicamente de su longitud.
El diseño del protocolo Stardust incorpora un factor de dificultad PoW dinámico basado en la congestión de la red. La utilidad añadida de la actualización del protocolo podría dar lugar a una mayor actividad de la red. Si esta carga alcanza un determinado umbral cercano al límite de las capacidades de rendimiento de la red, el protocolo autoajusta el factor de dificultad PoW. Cuando la carga se reduce, el proceso se invierte para reducir la dificultad hasta que se alcanza de nuevo el umbral.
Este mecanismo será soportado por la red después de la primera actualización fluida del protocolo, lo que significa que la función se activará en la red ya en funcionamiento y en vivo sin ningún tiempo de inactividad. El software de los nodos se está reformulando para poder gestionar muchas más actualizaciones futuras del protocolo.
Resumen
Con esto concluye nuestra lista de nuevas características de protocolo en Stardust. Recapitulemos lo que hemos aprendido hasta ahora.
Stardust nació como el módulo de soporte de contratos inteligentes del protocolo IOTA 2.0. Las pruebas iniciales de las cadenas de ISC en la DevNet de IOTA 2.0 produjeron una gran cantidad de aprendizajes y mejoras para el prototipo. Stardust fue identificado como un módulo de protocolo independiente que ya puede ser portado a la red principal de IOTA como un gran paso en la dirección de IOTA 2.0 en un entorno de producción.
Shimmer se lanzará con el protocolo Stardust para someterlo a pruebas y validaciones exhaustivas antes de que debute en la red principal. Esto también da tiempo suficiente para que los proyectos de la comunidad construyan y prueben sus dApps antes de su eventual lanzamiento en IOTA.
Para añadir niveles de utilidad sin precedentes al ledger de IOTA, Stardust introduce
- Nuevos tipos de cuentas del ledger.
- Varios tipos de salida nuevos.
- Condiciones y características de desbloqueo de salida.
- Fichas nativas y NFTs sin coste.
- Mecanismos para descargar el procesamiento de datos.
No sólo las cadenas de contratos inteligentes podrán aprovechar la nueva función: también lo harán los usuarios habituales y los futuros innovadores.
Además, un conjunto de mejoras en el protocolo y cambios en la arquitectura tiene como objetivo mejorar la seguridad, el rendimiento y el comportamiento de la red en momentos de gran congestión.
¿Y ahora qué sigue?
Las especificaciones del protocolo Stardust se han revisado a fondo y su implementación está muy avanzada. El prototipo de software de los nodos está siendo sometido a pruebas internas de tipo alfa, mientras que el desarrollo del cliente y de las herramientas está en marcha a toda máquina. Las partes cruciales de este esfuerzo son el soporte de la biblioteca de monederos para los nuevos modelos y conceptos de ledger, así como los nuevos flujos de interacción con el usuario del monedero Firefly.
Paralelamente, el equipo del ISC trabaja día y noche para refactorizar varios componentes clave del software del nodo del ISC para Stardust. Se está desarrollando una nueva máquina virtual ISC llamada Stardust VM, que es totalmente compatible con las nuevas características del protocolo base.
Stardust entrará en fase de prueba beta pública una vez que se hayan implementado las herramientas para desarrolladores y las pruebas alfa del software de nodo den resultados satisfactorios. Los principales destinatarios de las pruebas beta públicas son los desarrolladores y, sobre todo, los proyectos de la comunidad.
Shimmer se lanzará con Stardust y un conjunto completo de herramientas de cara al usuario para que los no técnicos también puedan experimentar la magia de la utilidad añadida de la nueva actualización del protocolo. Finalmente, Stardust llegará a la red principal de IOTA junto con ISC y los contratos inteligentes para acelerar la innovación de la Web3 en el ecosistema de IOTA. ¿Suena emocionante? Embárcate en este viaje con nosotros y sigue el desarrollo de Stardust en GitHub, contribuye a una propuesta de mejora de la Tangle, comparte tus propias ideas o participa con la comunidad en Discord para descubrir más sobre las posibilidades de Stardust.
