Explorando Identidad IOTA en Shimmer

TL;DR:
La próxima actualización de Stardust de IOTA permite que Identidad IOTA llegue a la capa 1 de la red. La nueva implementación marca una actualización importante sobre el método de datos anterior, ya que permite que las identidades interactúen con NFT, tokens nativos y contratos inteligentes, al tiempo que mejora la disponibilidad de datos, la accesibilidad y las garantías de sincronización. Con la actualización del protocolo Stardust ya en vivo en la red Shimmer, el nuevo método de identificador descentralizado basado en UTXO y otras capacidades están a la espera de ser probadas.

La próxima actualización de Stardust en la red IOTA ampliará significativamente las capacidades del protocolo e introducirá nuevas formas de diseñar soluciones en el ledger. Esta mejora nos ha inspirado a repensar cómo la identidad IOTA debe trabajar en IOTA y cómo podemos interactuar con las capacidades ampliadas. La actualización de Stardust a Shimmer, la red de pruebas de IOTA, nos permite explorar estas nuevas capacidades.

Stardust no sólo transforma a IOTA en una capa de infraestructura para cadenas de contratos inteligentes, sino que también lo convierte en un ledger multiactivo e introduce mecanismos para que los datos arbitrarios estén disponibles permanentemente en todos los nodos de IOTA. Para una visión general de lo que Stardust puede hacer, esta entrada del blog da una buena visión general; pero en resumen, Stardust añade nuevas salidas a la capa 1 que amplían significativamente las capacidades del ledger de IOTA.

Una de estas nuevas capacidades -el almacenamiento permanente de datos en el ledger- nos permite almacenar documentos de identificadores descentralizados (DID) directamente en el ledger, abriendo todo un abanico de nuevas posibilidades. Los DIDs pueden interactuar directamente con cualquiera de los otros tipos de salida y pueden estar compuestos por contratos inteligentes. En esta entrada del blog, echaremos un vistazo más profundo a lo que permite esta capacidad.

Métodos DID más eficientes y capaces

La implementación actual de DID en Chrysalis utiliza mensajes de datos en el Tangle para difundir documentos DID que son indexados por todos los nodos, pero que se eliminan después de una cierta cantidad de tiempo. Esto significa que los resolutores de DIDs necesitan acceder a un nodo que almacena todos los mensajes de datos que pasan por la Tangle, un llamado “permanode”. Sin embargo, los permanodes requieren importantes recursos para su ejecución, copia de seguridad y posible restauración. Las nuevas características de Stardust nos permiten ofrecer una solución más resistente, eficaz y con menos recursos. Un documento DID almacenado directamente en el estado del ledger está libre de las deficiencias de un permanode, ya que una salida no gastada no es podada por los nodos y, por tanto, no hay necesidad de un permanode. Esto mejora la disponibilidad, accesibilidad y sincronización que ofrece nuestra implementación actual.

Imaginamos el método DID basado en UTXO como el método para las identidades de alta seguridad (como los emisores de Credenciales Verificables) y las identidades que se benefician de la interacción directa con otros artefactos de Capa 1 (como NFTs y tokens nativos), así como las que necesitan ser compuestas de contratos inteligentes. Almacenar las identidades en el ledger garantizará que su estado más reciente esté sincronizado con todos los demás nodos y hace posible la resolución de DID desde cualquier nodo. Sin embargo, el espacio de almacenamiento del ledger es un recurso escaso, lo que significa que se requiere un depósito de tokens, como MIOTA o SMR, para cubrir el coste del byte del documento almacenado. Se trata de un depósito reembolsable proporcional al tamaño del documento almacenado y que puede ser reclamado en su totalidad al destruir la salida.

Dado que un depósito puede ser indeseable para algunos casos de uso, también estamos trabajando en un sustituto de nuestro actual método DID. Anticipamos que este reemplazo no necesitará un depósito por identidad, aunque carecerá de la integración de la Capa 1 del método UTXO. Este método está pensado para casos de uso en los que es necesario poner a disposición del público un gran número de identidades, y en los que un depósito por identidad sería inviable; por ejemplo, cuando es necesario equipar sensores baratos con identidades, pero el depósito supera el coste del sensor.

En resumen, queremos ofrecer dos métodos DID para Stardust en la red principal de IOTA que sean complementarios entre sí, con las siguientes compensaciones:

1. El método DID basado en UTXO que desbloquea la integración completa de la Capa 1, requiere un depósito de almacenamiento y está destinado a las identidades de alta seguridad.
2. Un método DID que sustituye al actual método Chrysalis y que no requiere un depósito por identidad, carece de la integración directa de la Capa 1 y está pensado para que un gran número de identidades puedan resolverse en el ecosistema.

Los dos métodos DID pretenden ser complementarios en cuanto a sus garantías. Esto significa que los desarrolladores que construyan sobre Identidad IOTA podrán elegir qué compensaciones aceptar e incluso podrán utilizar ambos métodos en paralelo, dándoles lo mejor de ambos mundos.

En este blog queremos centrarnos en el método basado en UTXO, describir cómo funciona y cómo se puede utilizar. Seguiremos con el segundo método cuando hayamos completado la investigación necesaria.

Resumen técnico

El objetivo del método UTXO es hacer que los documentos DID estén disponibles en la Capa 1 siguiendo el estándar DID lo más fielmente posible. Para ello, utilizamos otra innovación introducida por la actualización de Stardust, el Alias Output.

El Alias Output tiene una propiedad de metadatos de estado que puede contener datos arbitrarios hasta un determinado tamaño. El documento DID se almacena en esa propiedad. Para el identificador específico del método (o “ID”) del DID, se utiliza el Alias ID. El propio Alias ID se deriva del contenido de las transacciones de creación y es globalmente único e inmutable después de la creación. Estas propiedades lo hacen adecuado como DID y al mismo tiempo un identificador significativo en la capa 1 para casos de uso ampliados.

En resumen, la Salida Alias proporciona cuatro capacidades que son particularmente adecuadas para alojar identidades:

1. El ID de Alias es un identificador único global que no puede cambiarse después de la creación, lo que se ajusta perfectamente a la naturaleza inmutable de los DID. El DID contiene el ID de Alias, por lo que el DID y el Output (salida) pueden convertirse fácilmente el uno en el otro. Un ejemplo sencillo: La última parte del DID (el identificador específico del método) did:iota:0x0a6cf67b1faff3c4c9097ce91d84b1df490917b39a64a5b6ef30476ce4c528d3 es el ID de Alias del correspondiente Alias Output.
2. El Output puede almacenar datos arbitrarios en sus metadatos de estado, que es donde se almacena el documento DID.
3. Sólo el controlador de estado puede actualizar el estado del Output de Alias, como el documento DID en los metadatos de estado, lo que significa que el controlador de estado se convierte en el controlador DID en la terminología DID.
4. Un DID en un Alias Output hereda todas las capacidades de ese output, como la capacidad de enviar y recibir tokens o mintear activos nativos. A continuación exploramos estos casos de uso con más detalle.

Dado que el Output Alias es capaz de interactuar con NFTs y tokens nativos y permite que las cadenas de contratos inteligentes estén ancladas a la capa 1, se sitúa en el centro de la red de la capa 1, que es donde también deberían estar los DIDs.

Mirando hacia el futuro, para ser totalmente compatible con la especificación DID, tenemos que ampliar el output de Alias para permitir múltiples controladores. Esperamos que esta actualización llegue antes de que Stardust entre en la red principal de IOTA.

Casos de uso

En la siguiente sección, queremos demostrar las interacciones de las identidades UTXO con los otros artefactos de la capa 1 y describir los casos de uso desbloqueados por estas interacciones. Para cada interacción, hemos proporcionado ejemplos en la librería, que se puede encontrar aquí:

JavaScript/TypeScript: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm/examples
Rust: https://github.com/iotaledger/identity.rs/tree/main/examples

Identidades que controlan otras identidades

Dado que un Alias Output puede controlar otros Alias Outputs, una identidad puede efectivamente controlar otra identidad. Esto nos permite crear jerarquías de identidades y modelar situaciones como filiales para empresas o custodios para humanos. En este contexto, el control debe distinguirse entre dos partes: el gobernador y el controlador del estado. El controlador estatal tiene la capacidad de realizar cambios en el documento DID y, por tanto, puede decidir cómo representar la identidad. El gobernador controla quién está autorizado a realizar actualizaciones en una identidad mediante la asignación de un controlador de estado. Como ejemplo, consideremos el caso de un fabricante de smartphones llamado “Phonemkr” y sus dos filiales: “Phoneshop”, donde se pueden comprar los teléfonos, y “Phoneshippr”, que los envía. Se supone que “Phoneshop” gestiona la identidad de la filial de envíos, pero el fabricante quiere mantener el control final sobre ambas.

Esto se consigue estableciendo la dirección de la Salida Alias de una identidad como controlador de estado o condición de desbloqueo del gobernador de otra identidad. Actualmente, el Alias Output sólo permite un único controlador de estado, pero nuestra intención es trabajar para permitir múltiples controladores con futuras actualizaciones del protocolo. En el ejemplo anterior, múltiples controladores permitirían tanto al fabricante como a la tienda realizar actualizaciones de la identidad, proporcionando más flexibilidad.

Autenticación de emisores y receptores de fondos

Las identidades pueden recibir y mantener tanto tokens IOTA como tokens nativos, y enviarlos a otras identidades. Esto puede identificar al remitente y al receptor de los fondos, proporcionando así una mayor garantía al receptor y al remitente, respectivamente.

Debido a que un Alias Output puede contener tokens, cualquier DID puede ser fácilmente convertido en una dirección. Supongamos que Alicia acaba de intercambiar DIDs con Bob y quiere enviarle algunos fondos. Durante el intercambio de DIDs, Alice ha exigido a Bob que autentifique su DID ante ella, demostrando que el DID que ha compartido es realmente suyo. De esta manera, cuando Alice envía fondos a la dirección de su Alias Output, puede estar segura de que quien controla la identidad de Bob podrá acceder a los fondos. Lo más probable es que sea el propio Bob, pero también puede ser cualquier otra dirección, como una dirección Alias o NFT.

A la inversa, si alguien recibe fondos de un Alias Output que contiene un DID, puede estar seguro de que el propietario del DID envió los fondos. Esto permite autentificar el origen de los fondos, lo que podría, por ejemplo, apoyar las medidas contra el lavado de dinero.

Dado que los observadores pueden ver el movimiento de los fondos, podría ser preferible utilizar diferentes identidades para diferentes casos de uso en lugar de utilizar una única identidad para todas las interacciones (esto también se aplica a las interacciones de identidad en general).

A nivel técnico, una identidad puede controlar los fondos porque la dirección de una Salida Alias puede utilizarse como condición de desbloqueo de cualquier salida, lo que permite a la Salida Alias controlar la Salida Básica y sus fondos. Los fondos se envían creando una Salida Básica controlada por la Salida Alias de Bob. La Salida Alias de Identidad proporciona aquí un identificador permanente para recibir fondos al tiempo que permite las mejores prácticas de seguridad, como la rotación de claves. Esto permite efectivamente transferir fondos a los DID en la capa 1.

DIDs que emiten NFTs

Con la introducción de la actualización del protocolo Stardust, los NFTs pueden ahora ser minteados y transferidos en la capa 1 a través de una salida NFT dedicada. Los DID pueden ayudar a demostrar la identidad del emisor de un NFT.

Supongamos que el fabricante de smartphones de nuestro ejemplo, “Phonemkr”, quiere emitir pasaportes digitales de producto en forma de NFT para cada teléfono que vende. “Phonemkr” crea su identidad en un Alias Output y vincula de forma demostrable su DID a su sitio web phonemkr.com. Si “Phonemkr” emite NFTs con su identidad como emisor, esto probará efectivamente que phonemkr.com emitió esos NFTs.

Tenga en cuenta que la vinculación de dominios es una próxima extensión de la id entidad IOTA, pero aún no está incluida en la versión actual.

De forma similar a la transferencia de fondos, los NFTs también pueden ser propiedad de DIDs y ser transferidos a ellos, ya que la condición de desbloqueo de una salida de NFT puede ser una salida de Alias que represente a un DID, proporcionando garantías sobre de quién se reciben NFTs o a quién se envían.

Además, las identidades pueden ser desbloqueadas (léase como “propiedad”) por los NFT. Esto puede parecer extraño al principio y generalmente no se recomienda para los humanos, pero puede ser muy beneficioso para las cosas u organizaciones que se representan y comercian a través de sus respectivas NFT. Esto permite transferir la propiedad de una cosa (u organización) y el control de la identidad respectiva en una sola interacción atómica.

DIDs que emiten tokens nativos

Si quien mintea los tokens nativos es un DID, el “minteador” puede ofrecer mejores garantías y más confianza a los titulares de los tokens. Con esta información, los poseedores de los tokens pueden verificar quién creó originalmente un token nativo y, por tanto, comprobar si un token nativo que han recibido se originó donde esperaban, o verificar las afirmaciones de alguien respecto a los activos que acuñó.

Técnicamente, esto funciona porque los tokens nativos se crean a través de una Salida de Fundición que, a su vez, está controlada por una única Salida de Alias. Tener una identidad incrustada en este Alias Output permite resolver la identidad del minteador.

Ampliación de la funcionalidad de DID con contratos inteligentes

La actualización del protocolo Stardust permitirá que el estado de las cadenas de contratos inteligentes IOTA (ISC) se ancle en Alias Outputs en el ledger. Con Identidad IOTA, las cadenas de contratos inteligentes pueden estar vinculadas de forma demostrable a las identidades. Como se ha descrito anteriormente en “Identidades que controlan otras identidades”, las identidades pueden organizarse jerárquicamente, permitiendo que una sola identidad cree y controle otras múltiples Alias Outputs. Esto significa que una identidad en una Salida Alias puede gobernar la Salida Alias de una cadena ISC. Esto permite a los usuarios identificar al gobernador de una cadena y les ayuda a decidir si quieren confiar e interactuar con la cadena. También permite a los observadores externos verificar y probar quién tiene el control final de la cadena.

El almacenamiento de las identidades en las salidas de la capa 1 también permitirá la componibilidad a través de los contratos inteligentes. En los contratos inteligentes pueden incorporarse funcionalidades adicionales para las identidades no cubiertas por el estándar DID, como los casos de uso avanzados o más especializados de la Gestión de Identidad y Acceso (IAM). Seguiremos este tema más cerca del lanzamiento de los contratos inteligentes en Shimmer.

¡Empieza a construir ahora!

En esta entrada del blog, exploramos las nuevas capacidades de Identidad IOTA habilitadas por Stardust. Para recapitular:

• Las identidades pueden controlar otras identidades, lo que permite un modelado flexible de quién puede cambiar la representación de una identidad y quién está autorizado a hacer estas actualizaciones en primer lugar.
• Las identidades pueden proporcionar más confianza al enviar y recibir fondos.
• Las identidades pueden aumentar la confianza de los titulares hacia los emisores de NFT y tokens nativos.
• Las identidades permiten la autenticación de las cadenas de contratos inteligentes y permitirán una mayor integración en el futuro.

Para obtener la última versión alfa de la biblioteca de Identidades de IOTA dirigida a la red Shimmer sigue:

Rust: https://github.com/iotaledger/identity.rs

JavaScript/TypeScript: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm

Queremos proporcionar una versión temprana lo antes posible, para que puedas explorar todas estas nuevas posibilidades. Pero ten en cuenta que esta es una versión alfa y que todavía estamos trabajando para proporcionar la API más ergonómica y los puntos de extensión para personalizar tus implementaciones, así que espera cambios potencialmente rompedores en las próximas versiones.

En las próximas semanas, continuaremos puliendo y estabilizando el método UTXO y comenzaremos a implementar el segundo método para tener ambos listos antes de que la actualización del protocolo Stardust llegue a la red principal de IOTA.

Mientras tanto, si tienes algún comentario sobre el estado actual de la biblioteca, dirígete a GitHub y crea un problema o ponte en contacto con nosotros en Discord en #identity. Estamos deseando escuchar tus comentarios.