Autor del artículo: Yunwen Liu 1, Academia Mimir
Sé que, cuando se menciona este tema, los puristas de bitcoin pueden pensar: ¿no es mejor que bitcoin simplemente actúe como un oro digital? ¿Por qué es necesario tener tokens? ¿Por qué tiene que haber USDT? Sin embargo, si te preocupa especialmente la seguridad de los activos, no puedes evitar pensar, ¿y si Ethereum colapsa? ¿Quién se encargará de DeFi? Además, los esquemas de tokens son compatibles con el protocolo de bitcoin y no rompen las funciones originales; si no te gusta, puedes no descargar el cliente de tokens y no sentirás un gran impacto.
Emitir tokens en bitcoin: ¿por qué no?
Emitir tokens en bitcoin para trasladar transacciones de activos del mundo real a la cadena, esta idea surgió alrededor de 2010 en la comunidad de bitcoin. La discusión inicial de la comunidad imaginó trasladar activos del mundo real—como propiedades, acciones, moneda fiduciaria, etc.—a bitcoin para realizar transacciones descentralizadas. Sin embargo, debido a factores legales, el traslado de activos como propiedades y acciones no es tan fácil. Incluso si entregas el token de activo digital de tu casa a otra persona, el gobierno puede no reconocerlo, o puede que se deba cambiar automáticamente el título de propiedad del mundo real, además de tener que pagar varios impuestos. Además, bajo regulación, no se pueden realizar transacciones en la cadena libremente.
Por lo tanto, un enfoque más atractivo es emitir tokens vinculados a un stablecoin, es decir, stablecoins. A diferencia de los NFT, los stablecoins siguen siendo tokens fungibles, solo que se distinguen de los bitcoins originales. Cuando aparecen como tokens, su valor se determina por el precio de los activos del mundo real que representan, y ya no está relacionado con el precio de la criptomoneda original (si el precio de la criptomoneda sube mucho por encima del precio del activo, renunciar al activo no es imposible). Es por esto que los tokens en bitcoin suelen expresarse en satoshis.
Para usar criptomonedas como tokens de activos, es necesario resolver dos problemas principales:
Cómo representar activos del mundo real con bitcoin;
Cómo establecer reglas de transacción y contratos complejos dentro de un lenguaje de script de bitcoin muy limitado.
El contenido a continuación se centra en los dos puntos anteriores, y resume los actuales principales esquemas de emisión de activos en bitcoin, comparando aspectos como la disponibilidad de datos, portadores de activos, expresividad, escalabilidad, entre otros.
El primer token en bitcoin: coloridos
La persona que diseñó el primer protocolo de tokens en bitcoin es desconocida, la idea probablemente surgió de discusiones en foros o comunidades de bitcoin. El proyecto de coloridos (Colored Coin) fue iniciado por Yoni Assia en 2012, cuando él y Vitalik Buterin, Lior Hakim, Meni Rosenfeld y Rotem Lev escribieron el (libro blanco de coloridos) (Colored Coins whitepaper), el proyecto comenzó a funcionar en 2013.
El funcionamiento de los coloridos es marcar un satoshi como una moneda especial, escribiendo la información relevante del activo en este satoshi; este proceso se llama coloración. Puedes teñir un satoshi de diferentes colores, marcándolo con diferentes etiquetas (tag), pero las monedas del mismo color no pueden ser diferenciadas entre sí, por ejemplo, un grupo de satoshis coloreados como dólares sigue siendo fungible. Los protocolos más antiguos usaban el campo nSequence, agregando una etiqueta en el nSequence del primer UTXO de entrada de la transacción. Sin embargo, el límite de almacenamiento de nSequence es de solo 4 bytes, por lo que el diseño de tokens posterior ha cambiado principalmente al campo OP_RETURN, que puede almacenar más metadatos.
Los coloridos se mencionan principalmente porque son el primer proyecto de tokens en bitcoin. Dado que el desarrollo del proyecto no fue ideal y no tuvo una aplicación a gran escala, el proyecto mismo ha sido gradualmente olvidado. El problema que enfrentaban los coloridos en ese momento era que las funciones de bitcoin aún no podían soportar esta idea bastante avanzada, y era difícil implementar y operar de manera eficiente y estable. Esta podría ser también la razón por la cual Vitalik, tras el proyecto de coloridos, se volvió contra bitcoin, obsesionándose con los contratos inteligentes.
Dado que los coloridos existen en forma de satoshis, su validación es igual a la validación de la validez de un UTXO, y requiere descargar toda la cadena. Este problema se resolverá más adelante mediante la validación del lado del cliente (client-side validation).
Emitir tokens con OP_RETURN: Counterparty & Omni Layer
A diferencia de los coloridos, Counterparty y Omni Layer (el protocolo detrás de USDT) no tiñen directamente los satoshis, sino que establecen un UTXO con un valor de 0 en la transacción y almacenan los metadatos en el OP_RETURN de este UTXO. OP_RETURN puede almacenar 80 bytes, indicando que el UTXO de OP_RETURN no puede ser gastado, el verdadero token es la i-ésima salida registrada en OP_RETURN. El valor de esta salida suele ser 0.00000546 BTC, que es el mínimo permitido por el sistema, y dado que el valor del token no está vinculado a BTC, no hay necesidad de emitir más de 0.00000546 BTC.
La validación de estos proyectos debe realizarse en la cadena, y los metadatos se almacenan en la cadena.
Omni Layer ha sido un jugador en la cadena de Ethereum durante mucho tiempo, hasta que recientemente regresó al ecosistema de bitcoin, preparándose para emitir BTC-USDT. Counterparty ha apostado una parte de bitcoin y tiene su propio token XCP. Según Twitter, recientemente parece estar trabajando en NFT.
Para obtener más información sobre OP_RETURN, consulte:
Un análisis de los metadatos de bitcoin OP RETURN
Construcción manual de OP_RETURN para enviar USDT 1
Anclando bitcoin con cadenas laterales: Rootstock & Liquid Network
Los proyectos Rootstock y Liquid Network aparecieron alrededor de 2017, ambos son soluciones de cadena lateral —reemplazando bitcoin en la cadena lateral mediante anclaje bidireccional (Two-way peg), y utilizando diversas DeFi y dApps en cadenas laterales compatibles con EVM. Tienen tokens similares a WBTC (RSK tiene RBTC, Liquid tiene L-BTC), principalmente dirigidos a aquellos que desean construir en el ecosistema de Ethereum usando BTC.
Emitir tokens en Rootstock es igual que en Ethereum, o se puede decir que esta cadena lateral, excepto por la minería, hace todo en conjunto con la cadena de bitcoin; otras funciones están diseñadas para adaptarse al ecosistema de Ethereum, como el código de contratos inteligentes que también está escrito en Solidity. Por lo tanto, los tokens aquí se emiten sobre la base de RBTC y no están directamente relacionados con BTC.
Dado que este artículo se centra principalmente en cadenas públicas, y Liquid Network es una cadena de consorcio, no se discutirá en profundidad aquí.
Para obtener más información sobre RSK, consulte
RSK: Una cadena lateral de bitcoin con contratos inteligentes con estado (documento de RSK)
Dinero RSK
Preguntas frecuentes (FAQs)
Algunos de los proyectos mencionados anteriormente han desaparecido (como los coloridos), mientras que otros que se presentan como bitcoin están vendiendo el ecosistema de Ethereum. Esto se debe principalmente a que Ethereum, tras abrazar el capital, ha dominado el mercado con DeFi y dApps, por lo que es difícil para los proyectos DeFi que no juegan con él obtener ventajas. Los tokens en Ethereum se emiten y comercian a través de contratos, siguiendo estándares como ERC-20. En los últimos dos años, el ecosistema de bitcoin también ha comenzado a desbloquear funciones de contrato, como BitVM, y ha aparecido un estándar de token BRC-20.
Implementar contratos inteligentes en bitcoin: RGB
RGB (Really Good for Bitcoin), que nació en 2016, fue diseñado originalmente como competidor de los coloridos. Pero frente a desafíos similares, se volvió hacia la habilitación de contratos inteligentes en bitcoin. Aunque su enfoque principal es la ejecución de contratos inteligentes en lugar de la emisión de tokens, debido a las limitaciones de su máquina virtual AluVM, a partir de 2024, las funciones completas del contrato todavía son limitadas.
La idea de RGB es llevar los datos que pueden obtenerse fuera de la cadena y el código de contratos inteligentes fuera de bitcoin, utilizando la raíz de Merkle para proporcionar un compromiso (commitment) de validación de transacciones y emisión de tokens, mientras que la cadena de bitcoin solo se encarga de validar el compromiso de la transacción y su finalización, demostrando que no ha habido doble gasto.
RGB vale la pena mencionar porque utiliza simultáneamente la validación del lado del cliente y la tecnología de sellos de uso único, por lo que no marca el UTXO para indicar tokens. Estos dos conceptos fueron propuestos por primera vez por Peter Todd en 2013, y Giacomo Zucco y Maxim Orlovsky diseñaron el protocolo RGB sobre esta base.
La validación del lado del cliente (Client-side validation) permite que los datos y el código utilizados en las transacciones se mantengan fuera de la cadena, sin ser transmitidos públicamente; algunos datos pueden ser intercambiados en privado entre las partes de la transacción, sin que otros no relacionados a la transacción tengan conocimiento. El estado fuera de la cadena se mantiene por bitcoin, la blockchain actúa como un sello de tiempo, lo que permite probar el orden de los estados.
Y el sello de uso único (single-use seal) —que es también una de las formas más comunes de validación del lado del cliente— es un sello de una sola vez en formato digital. Aprovecha la propiedad de que cada UTXO solo puede gastarse una vez, escribiendo la información del estado fuera de la cadena en un UTXO. Así, si en algún momento este UTXO es gastado, sabemos que el estado ha sido actualizado, y la información del nuevo estado se escribe en el nuevo UTXO generado. Esta información del estado fuera de la cadena puede ser la propiedad de un token USDT o cuántos tokens hay en un contrato.
Por ejemplo, si Alice quiere transferir un USDT a Bob, este USDT no existe en la cadena de bitcoin, su información se mantiene fuera de la cadena, pero está relacionado con un UTXO controlado por Alice. Su información se guarda en la transacción que generó este UTXO en el campo OP_RETURN de un UTXO con valor cero. De esta manera, solo Alice puede gastar este USDT, y Bob puede rastrear a través de transacciones en la cadena dónde ha estado este USDT en transacciones anteriores, si estos UTXO son válidos, y si la transacción es legal. Así, cuando Alice inicia una transacción para transferir la información del compromiso de este USDT a un UTXO controlado por Bob, este puede estar seguro de que ha recibido este USDT.
RGB también puede funcionar en la red Lightning, ya que su estado se mantiene fuera de la cadena, solo necesita colocar el compromiso en la cadena o en la red Lightning. Después de la actualización de Taproot, RGB puede incrustar el compromiso en una transacción Taproot, lo que permite que RGB incruste el compromiso de manera más flexible en la cadena de bitcoin.
Para obtener más información sobre RGB, consulte:
RGB Blueprint 1
Solo soporta tokens, no soporta contratos inteligentes: Activos Taproot
El activo Taproot es un proyecto desarrollado por el equipo de Lightning Network Daemon (LND). Su principio es similar al de RGB, pero no soporta contratos inteligentes complejos, solo tokens (ver aquí la explicación del término Taproot).
Para obtener más información sobre la validación del lado del cliente, RGB y Taproot, consulte
Validación del lado del cliente
Transacciones fuera de la cadena: La evolución de los protocolos de activos de bitcoin
Counterparty vs RGB vs TARO
Haciendo que cada satoshi sea único: Ordinals & Inscriptions
Casey Rodarmor lanzó el protocolo Ordinal a principios de 2023. Este proyecto surgió de la idea de: ¿cómo numerar los satoshis, de modo que cada satoshi tenga un número de serie único y pueda ser ordenado? Esta idea surgió al mismo tiempo que los coloridos, pero solo se volvió a proponer el año pasado. Además, con la introducción de las funciones SegWit y Taproot, su implementación se volvió menos difícil. Ordinal permite que cada satoshi sea diferente, lo que facilita la emisión directa de NFT en la cadena de bitcoin.
Inscriptions es un proyecto NFT de este tipo. Los datos del NFT se almacenan en los datos del testigo de la transacción, en lugar del campo OP_RETURN utilizado por proyectos anteriores, permitiendo almacenar metadatos de hasta 4MB. A diferencia de los NFT en Ethereum, la Inscripción se almacena en la cadena, incluyendo metadatos e imágenes.
Para obtener más información sobre ordinals, consulte:
Ordinals: ¿un terreno común para maximalistas de Ethereum y Bitcoin?
La Guía Definitiva sobre Ordinals y Inscriptions de Bitcoin
Vinculando bidireccionalmente cualquier cadena UTXO: enlace isomórfico RGB++
RGB++ se originó como un protocolo de enlace isomórfico entre BTC y CKB (la base de Nervos Network), y ahora su alcance se ha ampliado, no solo se limita a CKB y BTC, sino que cualquier dos cadenas UTXO pueden teóricamente utilizar este protocolo para unirse.
RGB++ ha desarrollado aún más la idea de la Validación del lado del Cliente y los Sellos de Uso Único. Como se mencionó anteriormente, el mayor problema del protocolo RGB es que los datos son almacenados localmente por el usuario. Si el usuario accidentalmente pierde los datos, no hay respaldo y no se pueden recuperar. Además, dado que el usuario solo guarda datos relacionados con sus propios tokens, es difícil validar otros datos. La solución de la capa de enlace isomórfico es no solo enlazar el token al campo OP_RETURN de un UTXO de bitcoin, sino también enlazar la información de transacción de bitcoin correspondiente a las transacciones en la cadena CKB (utilizando un script IB-lock-script especial en el Lock Script de CKB Cell). Al determinar la validez de una transacción en la cadena CKB, el Lock Script utilizará los datos del cliente ligero BTC en CKB para verificar si el UTXO correspondiente ha sido gastado y si el nuevo UTXO generado está vinculado a la información de la transacción de tokens actual (como parte de la información sin firma).
Características destacadas de RGB++:
Resolver el problema de la disponibilidad de datos mediante el enlace bidireccional:
El compromiso del CKB Cell se vincula en el campo OP_RETURN del UTXO
La información del UTXO se vincula en la output Cell de la transacción CKB
Compatible con la red Lightning y Fiber Network (una red Lightning basada en CKB)
Soporta múltiples activos
Puede vincularse a cualquier cadena UTXO
Para obtener más información sobre RGB++, consulte:
RGB++ Protocolo Light Paper
La Guía Definitiva sobre RGB, RGB++ y Validación del Lado del Cliente
Para comprender más claramente las ventajas y limitaciones de cada proyecto, compararemos los proyectos anteriores en la tabla a continuación. Los indicadores que deben ser destacados son:
Disponibilidad de datos (Data availability): las cadenas isomórficas (isomorphic-chain) y las cadenas laterales (side-chain) son casi equivalentes, mientras que la disponibilidad de datos fuera de la cadena es más débil que en otros enfoques. El orden de esta categoría de fuerte a débil es: en cadena ≥ cadena isomórfica ≥ cadena lateral > fuera de cadena;
Portador de activos (Asset carrier): los esquemas de tokens directamente asociados con BTC son superiores a los que no están directamente asociados;
Fungibilidad (Fungibility): aquí se refiere a si el token nativo del proyecto es intercambiable entre sí; no significa que el proyecto no soporte la emisión de NFT, lo cual se puede lograr mediante la adición de protocolos adicionales;
Expresividad (Expressiveness): se refiere a la capacidad de manejar contratos inteligentes complejos.
