Sumergiéndonos más profundo en Stardust

886

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.

IOTA es muy adecuada para ser la base de las redes de tecnología de ledger distribuido (DLT) que operan sobre ella, porque:
La naturaleza asíncrona del Tangle y el modelo de ledger UTXO permite el procesamiento de transacciones en paralelo.

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.

Un ejemplo ilustrativo de esto sería el documento DID utilizado en IOTA Identity. Hasta ahora el patrón de uso dependía de los permanodes para poder obtener un DID determinado con fines de verificación. Con un documento DID almacenado en el estado del libro mayor de IOTA, estaría disponible en cada uno de los nodos de la mainnet mientras su propietario esté dispuesto a bloquear su depósito de almacenamiento de IOTA, lo que se describe con más detalle más adelante en esta entrada del blog.

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

Una cuenta del ledger suele ser una dirección derivada directamente de una clave privada secreta. El propietario puede firmar transacciones con la clave secreta y cualquiera puede verificar en el ledger si la firma es válida o no.

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

Las cadenas de contratos inteligentes son como cadenas de bloques que producen actualizaciones de estado en bloques. Cada bloque identifica el estado de la cadena de bloques correspondiente a ese bloque específico. Al anclar el estado L2 en L1 nos referimos a registrar un compromiso criptográfico con el estado actual de la blockchain L2 dentro de la salida del alias. Esto es beneficioso para sincronizar de forma fiable el estado del ledger L2 con el estado del ledger L1 y abre la puerta a la verificación de la actualización del estado L2 con conocimiento cero en L1 en el futuro.

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

Los tokens fungibles se implementan en el protocolo Stardust a través de tokens nativos. Estos tokens se mintean en las fundiciones de tokens. La cuenta del ledger que controla la fundición se denomina emisor. Tiene el derecho de fundir los tokens en su posesión, disminuyendo el suministro total, mientras que los titulares pueden quemar tokens (lo que no los elimina del suministro total, sino del suministro en circulación).

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

A diferencia de los tokens personalizados fungibles descritos anteriormente, los tokens no fungibles (NFT) son tokens únicos en el ledger que llevan consigo metadatos inmutables. Se implementan en Stardust como un tipo de salida independiente, llamado salida NFT. El concepto descrito anteriormente para una cuenta de dirección de contrato inteligente permanente encaja muy bien aquí, por lo que la salida NFT es en realidad un primo de la salida de alias pero con ventajas adicionales.

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.

Mintear un NFT es tan barato como enviar una transferencia normal: de hecho, ¡no tiene fee! Sin embargo, dado que las NFT pueden llevar consigo datos adicionales, los emisores tienen que suministrar suficientes tokens a la salida de la NFT para cubrir el depósito de almacenamiento. Cuando el NFT se quema, este depósito se devuelve completamente a su propietario actual.

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:

Las solicitudes en el ledger que se originan en el protocolo base,
Solicitudes fuera del ledger enviadas directamente a la cadena L2.

 

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.

Otra característica útil es la Condición de Desbloqueo del Timelock que impide que la salida se desbloquee hasta que se cumpla el plazo del timelock. ¿Por qué es tan importante? Porque con ella puedes cronometrar con precisión las peticiones de los contratos inteligentes. Tan pronto como se cumpla el plazo, la cadena del contrato inteligente recoge y ejecuta la solicitud.
Estas condiciones de desbloqueo están actualmente soportadas por Stardust porque son necesarias para los contratos inteligentes, pero muchas ideas están flotando alrededor del foro de discusión del repositorio Tangle Improvement Proposal (TIP), siendo el intercambio o swapping una de ellas.

Características del output o salida

Las características que no afectan al desbloqueo real de la salida se definen como características de salida. Para los contratos inteligentes, ya se ha mencionado una de las características más importantes: la Característica de Metadatos. Ésta también es esencial para los usuarios y las solicitudes en el ledger. La característica de metadatos de la salida contiene los datos de la llamada real, es decir, las instrucciones que deben llevar a cabo los contratos inteligentes.
Cuando Alice quiere invocar un contrato inteligente en la Cadena A desde su cuenta IOTA:
  • 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.
¿Cómo sabe la cadena que Alice ha creado el resultado, es decir, que la solicitud debe llevarse a cabo a nombre de Alice? No tiene acceso a la transacción IOTA, sólo a su resultado. E incluso si lo tuviera, ¿qué pasa si Bob y Alice envían solicitudes en la misma transacción?
La solución de Stardust es la Función de Remitente (Sender Feature). Las salidas pueden especificar sus remitentes explícitamente, mientras que la validación de la transacción se asegura de que la dirección del remitente está desbloqueada en el lado de entrada de la transacción. Por lo tanto, el propietario de la dirección del remitente debe haber aceptado realizar la solicitud en el ledger a su nombre.
Tenga en cuenta que las solicitudes en el ledger pueden enviarse desde cualquier dirección IOTA, incluso desde direcciones NFT y direcciones Alias. Esto último hace posible que la cadena A ejecute una solicitud en la cadena B, llevando la componibilidad de los contratos inteligentes al siguiente nivel: la componibilidad entre cadenas. La primera, el envío de solicitudes de contratos inteligentes desde Direcciones NFT, introduce nuevas posibilidades para los desarrolladores de dApps, ya que la funcionalidad específica de los contratos inteligentes puede estar disponible sólo para los titulares de NFT.

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

Hasta ahora, hemos presentado la historia del origen de la mayoría de las características del protocolo Stardust. Pero además de satisfacer los requisitos de los contratos inteligentes, hay más mejoras en comparación con Chrysalis.

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.

Los datos en Stardust se publican a través de Cargas Útiles de Datos Etiquetados (Tagged Data Payloads) que son tratados como datos binarios por el protocolo. Se recomienda que el procesamiento y la exposición de los datos específicos de la aplicación publicados a través de estas cargas útiles sean implementados por protocolos de segunda capa. Una de las principales ventajas de este enfoque es su flexibilidad: cada aplicación puede definir e implementar sus propios requisitos, por ejemplo, autenticar las cargas útiles de datos basándose en firmas digitales, indexar por campos personalizados o validar las cargas útiles con respecto a las estructuras de datos esperadas.

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.

Para mantener la coherencia con esta nueva arquitectura, Stardust también elimina la indexación del ledger del protocolo central e implementa una aplicación de indexación del ledger a través de un módulo INX.
https://files.iota.org/media/218_graphic_14.mp4

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.

Attachments

Comentarios

comentarios

pasarela de pagos con criptomonedas