TL;DR:
Lanzamos las especificaciones para el nuevo Framework Tokenization para la mainnet de IOTA. Esta futura actualización transformará el protocolo de la red principal en un ledger de múltiples activos con Contratos Inteligentes y transferencias de activos entre cadenas sin problemas. Los tokens nativos y los NFTs viven dentro del Tangle y heredan la naturaleza sin fees y escalable de la moneda base, la moneda IOTA. Un mecanismo de puente sin confianza del Marco de Tokenización Nativa asegura que los tokens de los Contratos Inteligentes puedan ser envueltos y desenvueltos sin esfuerzo de los tokens nativos. Las especificaciones del protocolo están siendo revisadas públicamente y se ha empezado a trabajar en la implementación de la red de pruebas.
La tokenización es una de las mayores innovaciones en el espacio DLT, que permite casos de uso y modelos de negocio totalmente nuevos. IOTA ha estado explorando el panorama de la tokenización con el Native Tokenization Framework, que fue lanzado para la DevNet de IOTA 2.0 en Junio de 2021.
En anteriores publicaciones, hemos explicado los Novedosos Casos de Uso y las oportunidades que la tokenización pone sobre la mesa, hemos mostrado lo potente que es la implementación de la red de pruebas del framework. Los usuarios pueden mintear sus propios tokens y activos nativos directamente en la Tangle, que luego son transferibles sin problemas al igual que las monedas IOTA.
Al experimentar con activos digitales en la red de desarrollo, hemos aprendido mucho sobre las limitaciones de nuestros conceptos. Hemos dado un paso atrás y hemos imaginado un mundo en el que los activos digitales son un bloque de construcción vital de toda la pila tecnológica de IOTA. En este país de las maravillas de los tokens, los activos fluyen sin problemas y sin confianza entre las cadenas de contratos inteligentes y las cuentas de los usuarios. Pueden ser envueltos o desenvueltos (wrap o unwraped) sin necesidad de soluciones puente centralizadas. Cualquiera es libre de crear y gestionar sus propios tokens. Al fin y al cabo, IOTA es libertad.
Hoy, estamos orgullosos de presentar las especificaciones de la red principal del Framework de Tokenización de IOTA e invitar a la comunidad a explorar este emocionante espacio con nosotros mientras comenzamos nuestro viaje para traer la mayor actualización de utilidad a la red principal de IOTA.
Transformando IOTA en un Ledger Multi-Asset
La mayoría de las DLTs entran en la categoría de ledger de un solo activo, ya que sólo son capaces de rastrear la propiedad de una moneda base específica dentro de su ledger. Los ledger multiactivos, por el contrario, son capaces de gestionar varios tokens nativos en el mismo ledger que mantiene la moneda base. Como el ledger base de IOTA proporciona transacciones sin fees, un ledger IOTA multi-activos es capaz de ejecutar transferencias sin fees de cualquier token nativo, lo que es un cambio de juego único en el campo.
Hemos rediseñado y ampliado el modelo de salida de transacciones no utilizadas (UTXO) del ledger de IOTA para transformarlo en un ledger multiactivo de pleno derecho. Cualquier cuenta del ledger es capaz de mantener y transferir tokens nativos minteados por Token Foundries. Ya no es necesario «etiquetar» o «colorear» las monedas IOTA: todos los tokens nativos son tokens independientes en el ledger que son forjados a la existencia por las fundiciones.
Los usuarios inyectan los tokens nativos en el ledger de IOTA, por lo que también se denominan tokens definidos por el usuario. Consumen recursos preciosos de los nodos que mantienen la red, principalmente el almacenamiento. Como consecuencia, cada cuenta que tiene tokens nativos debe llevar un depósito en monedas IOTA para compensar el uso excesivo de recursos.
Fundiciones de tokens
El creador del token definido por el usuario, denominado emisor, tiene el control del Token Foundry y regula la actividad de minteo o quema de tokens que pertenecen al foundry fundición.
Cualquiera puede convertirse en emisor y empezar a mintear sus propios tokens. Las fundiciones de tokens permiten a los emisores elegir una política de control de la oferta adecuada para sus casos de uso. Así, dependiendo del esquema del Token Foundry, un token nativo en IOTA puede tener un suministro total dinámico, fijo o limitado. Esquemas más avanzados como el minteo o el control de flujo de quema se añadirán iterativamente al marco a medida que progrese su implementación.
La entidad del emisor puede ser una dirección única, una dirección multifirma, una dirección multifirma threshold (con umbral) con participantes y threshold arbitrarios, o una dirección de cadena de contrato inteligente. También es posible transferir los derechos del emisor a otras entidades, pero está prohibido cambiar la política de control de la oferta definida al desplegar el foundry, lo que permite una increíble variedad de casos de uso que van mucho más allá de una mera coloración de tokens, introducida a principios de este año.
La transparencia del Framework de Tokenización es de suma importancia para IOTA. Los foundrys producen tokens con un ID de token específico que incorpora el identificador único global del foundry que lo controla y algunos metadatos de token predefinidos, como un nombre. Basándose en el ID de token de un token nativo, es posible inferir información sobre:
- Etiquetas de token definidas por el emisor, como el nombre o el ticker
- Información de la cuenta del emisor
- El esquema de tokens, que es la política de control del suministro
- El suministro de tokens en circulación y máximo
- Metadatos de los tokens almacenados en la cadena
No hay necesidad de registros de tokens off-chain; todo lo relacionado con un token puede documentarse y almacenarse on-chain, directamente dentro del ledger UTXO de la Tangle. Los emisores pueden optar por revelar su cuenta en la chain o cadena públicamente para aumentar la transparencia de sus tokens. Dada una lista de identidades de emisores validadas que están vinculadas a identidades del mundo real, las wallets pueden determinar automáticamente la autenticidad de cualquier token nativo.
Tokens no fungibles
Los foundry de tokens son excelentes para los tokens fungibles, pero también pueden producir tokens no fungibles (NFT). Una fundición de tokens que define la oferta máxima como 1, controla esencialmente un solo token que es globalmente único en el ledger; por lo tanto, es un NFT.
La mayoría de los NFT representan la propiedad de algo único, como una obra de arte digital o un objeto de colección. Por lo tanto, deben tener un identificador único a nivel mundial y una descripción del activo subyacente. Esta última suele estar codificada como metadatos adjuntos al NFT. La propiedad del token implica también la propiedad de los metadatos.
Un NFT nativo controlado por foundry puede transferirse a cualquier cuenta del ledger, pero los metadatos en la cadena siguen residiendo en la foundry. Además, el emisor sigue teniendo el control de la grabación del NFT nativo, no el propietario real. Para mitigar los riesgos que conlleva el hecho de que un emisor tenga el control en lugar del propietario actual, hemos añadido un soporte avanzado para los NFT en el marco de la tokenización con un tipo de salida dedicado a los NFT.
Con su propio tipo de salida, los NFT se convierten en ciudadanos de primera clase en el ledger de IOTA. Cualquiera puede crear un NFT que tenga:
- Un identificador único a nivel mundial, asignado en el momento del minteo. Este identificador también funciona como una dirección IOTA normal, por lo que sus NFT pueden poseer fondos, tokens nativos u otros NFT.
- Metadatos adjuntos inmutables que describen el activo subyacente del token. Establecidos en el momento del minteo, no pueden cambiarse a lo largo de toda la vida del NFT.
- Dirección del emisor verificada que nunca puede cambiar. El protocolo garantiza que un NFT con un emisor verificado sólo puede crearse en una transacción firmada criptográficamente por el emisor.
- Las transacciones con NFT no tienen fee, como cualquier otra transacción de IOTA, y el propietario actual tiene el control total de transferir el token con los metadatos adjuntos o quemarlo. La salida de NFT fue diseñada teniendo en cuenta la interoperabilidad de los contratos inteligentes, por lo que es posible enviarla como parte de una solicitud de contrato inteligente, por ejemplo, para depositarla en una cadena de contrato inteligente como garantía o listarla para subasta.
Tokenización de contratos inteligentes
Los contratos inteligentes de IOTA son una extensión de capa 2 del ledger base que hace que el poderoso mundo de los contratos inteligentes y la programabilidad del ledger sean una realidad para IOTA. Los contratos inteligentes se ejecutan en cadenas de contratos inteligentes ejecutadas por validadores de capa 2. Como los contratos inteligentes proporcionan una programabilidad casi Turing completa, dan vida a un sinfín de complejos esquemas de tokenización.
De hecho, la mayoría de los tokens del mercado actual se construyen mediante contratos inteligentes. Cada uno de ellos guarda y mantiene un ledger local dentro del contrato inteligente que registra quién es dueño de qué. Esto ofrece una gran funcionalidad y composibilidad. Sin embargo, también viene con una advertencia para las principales blockchains: bajo rendimiento y costosa ejecución de contratos inteligentes.
Como consecuencia, IOTA diseñó su plataforma de contratos inteligentes para escalar horizontalmente a través de cadenas paralelas. Sin embargo, esta estrategia plantea un reto importante: ¿cómo se comunican las cadenas de contratos inteligentes y se transfiere el valor entre ellas? La respuesta es obvia: se basan en la Tangle y el Native Tokenization Framework para hacer el trabajo.
Wrapping de Activos (Envoltura de Activos)
No sólo es posible depositar Activos Nativos en las cadenas de contratos inteligentes, sino que las propias cadenas también pueden actuar como emisoras de activos nativos. Por lo tanto, cada contrato inteligente puede emitir tokens nativos que son transparentemente rastreables hasta el contrato inteligente específico en la cadena específica. Este mecanismo proporciona la base para los puentes de activos garantizados y sin confianza a través de múltiples cadenas.
Un contrato inteligente que maneja tokens de capa 2 (tokens ERC-20, por ejemplo) dentro de una cadena puede interactuar con los contratos principales para envolver (wrap) tokens de capa 2 en activos nativos de capa 1 o desenvolver (unwrap) tokens nativos que pertenecen al contrato inteligente en su representación de capa 2. La lógica de envoltura de activos es proporcionada por la máquina virtual (VM) de la cadena; los contratos inteligentes sólo tienen que llamar al contrato central apropiado en la cadena para realizar la operación.
Una propiedad importante de este enfoque de tokenización multicapa es la flexibilidad:
- Los tokens de contrato inteligente de capa 2 son totalmente programables y personalizables, pero conllevan posibles tasas de ejecución de contratos inteligentes.
- Los tokens nativos de capa 1 aprovechan el rendimiento y la seguridad del ledger de IOTA; además, no poseen ninguna fee de transferencia.
- Los tokens de los contratos inteligentes pueden envolverse sin problemas en tokens nativos y viceversa. Los contratos inteligentes de IOTA proporcionan un soporte integrado para los desarrolladores.
Las dos clases de tokens podrían entenderse mejor a través de la metáfora de los bancos y el dinero en efectivo. Las cadenas de contratos inteligentes son bancos que ofrecen una amplia gama de activos financieros, pagarés, productos y servicios (tokens de contratos inteligentes) a aquellos que tienen una cuenta en la cadena. El banco puede optar por imprimir dinero en efectivo (tokens nativos) que representan los activos mencionados, que luego pueden circular en la economía (capa 1, Tangle) independientemente del control de los bancos.
Solicitudes de Contratos Inteligentes
La interacción con las cadenas de contratos inteligentes desde las cuentas regulares de IOTA de capa 1 se realiza a través de solicitudes en el ledger enviadas a la cuenta de capa 1 de la cadena. Estas solicitudes pueden llevar tokens nativos o NFTs que forman parte de la solicitud. Un usuario puede elegir depositar algunos activos nativos en una cadena y ordenar a la cadena que los desenvuelva para desbloquear todo su potencial.
Algunos posibles casos de uso de los tokens nativos en los contratos inteligentes:
- El propietario de la cadena decide aceptar fees para ejecutar cualquier contrato inteligente en un token nativo concreto.
- Un contrato inteligente específico sólo puede ejecutarse si se pagan los fees con un token nativo determinado.
- Un contrato inteligente requiere el depósito de un token nativo específico para desbloquear la funcionalidad para el usuario.
- Los privilegios de los contratos inteligentes están ligados a la presencia de un token nativo específico. Los derechos de control son transferibles en lugar de codificarlos en el contrato inteligente.
- Una dApp de juegos acepta artículos del juego como NFT de un emisor verificado.
La lista anterior está lejos de ser completa; más bien ofrece un vistazo a lo que es posible con los contratos inteligentes de IOTA y el marco de tokenización nativo.
¿Qué se viene?
Con el lanzamiento de las especificaciones del protocolo de la mainnet (Chrysalis) para los Contratos Inteligentes y la Tokenización, entramos en un período emocionante para IOTA. Las especificaciones nos guiarán para implementar las nuevas características del protocolo e integrarlas en los frameworks o marcos existentes, las librerías de clientes y las herramientas para desarrolladores.
Nuestro primer hito es una red de pruebas basada en Hornet con el marco de tokenización habilitado. Mientras llegamos a ese punto, el trabajo de integración de los contratos inteligentes de IOTA con el nuevo protocolo ya ha comenzado.
Invitamos a la comunidad y a nuestros socios a leer los cambios propuestos en el protocolo y a ayudarnos a iterar el diseño compartiendo sus opiniones y comentarios. Únete a la conversación en GitHub o participa con nuestro equipo directamente en el canal #digital-assets en nuestro Discord.
Post original: IOTA Tokenization Framework Specifications
