Los activos en BTC: emisión de proyectos existentes y sus respectivas guías de implementación

Fuente: Nervos CKB

Sé que cuando se trata de este tema, los puristas de BTC pueden pensar: ¿No sería suficiente que BTC simplemente sea el oro digital? ¿Por qué necesitar Token? ¿Por qué necesitar USDT? Sin embargo, si te preocupa especialmente la seguridad de los activos, ¿no deberías considerar qué sucederá si Ethereum colapsa? ¿Quién respaldará a DeFi? Además, la solución de Token es compatible con el protocolo BTC y no afectará significativamente sus funciones originales. Si no te gusta, no necesitas descargar el cliente de Token, y no te verás muy afectado.

¿Por qué no se puede hacer emisiónToken en BTC?

En Bitcoin, la emisión de tokens se utiliza para transferir transacciones de activos del mundo real a la cadena (on-chain). Esta idea surgió en la comunidad de Bitcoin alrededor de 2010. Las primeras discusiones de la comunidad imaginaban la Descentralización de activos del mundo real, como propiedades, acciones, moneda fiat, etc., a la cadena de Bitcoin para su intercambio. Sin embargo, debido a cuestiones legales, no es tan fácil transferir activos como propiedades y acciones. Incluso si pagas un token de activo digital de tu casa a otra persona, es posible que el gobierno no lo reconozca o que automáticamente cambie el certificado de propiedad del mundo real, lo que podría implicar el pago de varios impuestos. Además, no se puede realizar transacciones on-chain libremente bajo regulaciones.

Por lo tanto, el método más atractivo es Token vinculado a Moneda fiat, es decir, moneda estable. Moneda estable es diferente de Token no fungible, siguen siendo tokens fungibles, pero se distinguen de BTC original. Cuando aparecen como tokens, su valor está determinado por el precio de los activos del mundo real que representan, en lugar del precio original de dinero digital (si el precio del dinero digital sube mucho más que el precio de los activos, también se puede desechar los activos). Por eso, los tokens en BTC suelen estar denominados en Satoshi (Satoshi).

Para convertir Dinero Digital en un Token de activo, se deben resolver dos problemas principales:

1. Cómo representar activos del mundo real con BTC;
2. Cómo establecer reglas de transacción y contratos complejos en el lenguaje de script extremadamente limitado de BTC.

El siguiente contenido se centra en los dos puntos anteriores y resume los principales esquemas de emisión de activos BTC existentes, y los compara desde varios aspectos como la disponibilidad de datos, los medios de activos, el rendimiento y la escalabilidad.

El primer Token en BTC: Token de colorante

La identidad de la persona que primero diseñó el protocolo Token en BTC no se puede determinar, pero la idea probablemente surgió de discusiones en los foros o comunidades de BTC. El proyecto Colored Coins fue iniciado por Yoni Assia en 2012, cuando escribió el White Paper de Colored Coins junto con Vitalik Buterin, Lior Hakim, Meni Rosenfeld y Rotem Lev.[1], El proyecto comenzó a funcionar en 2013.

El principio de funcionamiento de una moneda coloreada es etiquetar un satoshi como una moneda especial y escribir la información relevante del activo en ese satoshi, este proceso se llama coloreado. Puede colorear un satoshi con diferentes colores y etiquetas, pero las monedas del mismo color todavía no se pueden distinguir entre sí, como un montón de satoshis coloreados como dólares, todavía son homogéneos. Los protocolos más antiguos usaban el campo nSequence y agregaban una etiqueta en el nSequence del primer input UTXO de la transacción. Sin embargo, el límite de almacenamiento de nSequence es solo de 4 bytes, por lo que los diseños de Token posteriores se cambiaron a OP_RETURN, que puede almacenar más metadatos.

La razón principal por la que se menciona actualmente la moneda teñida es porque es el primer proyecto de token en BTC. Debido a que el desarrollo del proyecto no fue ideal y no se aplicó a gran escala, el proyecto en sí ha sido olvidado gradualmente. El problema que enfrentó la moneda teñida en ese momento fue que la funcionalidad de BTC no podía admitir esta idea avanzada. Es difícil que esta idea se implemente, funcione de manera eficiente y estable. Esto puede ser también por qué Vitalik se opuso a BTC después del proyecto de la moneda teñida y está tan dedicado a los contratos inteligentes.

Dado que las monedas coloreadas existen en forma de tokens, su validación es similar a la validación de la efectividad de un UTXO, ya que se requiere descargar toda la cadena. Este problema se resolverá más adelante mediante la validación del cliente (client-side validation).

Cómo usar OP_RETURN para emitir tokens: Counterparty & Omni Layer

A diferencia de la moneda teñida, Counterparty[2][3]Y Omni Layer(El protocolo detrás de USDT) no se tiñe directamente en la cadena de bloques, sino que se establece un UTXO con un valor de 0 en la transacción y se almacenan los metadatos en el campo OP_RETURN de este UTXO. OP_RETURN puede contener hasta 80 bytes y marca el UTXO con OP_RETURN como no gastable, el verdadero token se registra en el i-ésimo output de OP_RETURN. El valor de este output generalmente es de 0.00000546 BTC, que es el valor mínimo permitido para enviar según el sistema, y como el valor del token no está vinculado al BTC, no es necesario enviar más que 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 bloques de Ether durante mucho tiempo, hasta hace poco que regresó al ecosistema de Bitcoin, preparándose para la emisión BTC-USDT. Counterparty stakeó una parte de BTC y tiene su propio Token XCP. Desde Twitter[4]Recientemente, parece que están trabajando en NFT.

Para obtener más información sobre OP_RETURN, consulte:

1. Un análisis de los metadatos de Bitcoin OP RETURN[5]
2. Construya manualmente OP_RETURN envíe USDT[6]

Anclando BTC con Sidechains: Rootstock y Liquid Network

Rootstock[7][8]Y Liquid Network[9]Estos dos proyectos aparecieron alrededor de 2017 y ambos son soluciones de cadena lateral, que intercambian Bitcoin por cadena lateral a través de anclaje bidireccional (Two-way peg) y utilizan varios DeFi y dApps en la cadena lateral compatible con EVM. Tienen algo en común con WBTC.El token (RSK tiene RBTC, Liquid tiene L-BTC), está dirigido principalmente a aquellos que deseen construir en el ecosistema de Ethereum utilizando BTC.

La emisión de tokens en Rootstock se realiza de la misma manera que en la cadena ETH, o se podría decir que esta cadena lateral de Rootstock, aparte de la Minería, está diseñada para adaptarse al ecosistema de Ethereum, por ejemplo, el código de los contratos inteligentes también se escribe en Solidity. Por lo tanto, los tokens aquí se emiten sobre la base de RBTC y no tienen una relación directa con BTC.

Dado que este artículo se centra principalmente en la cadena pública, y Liquid Network es una cadena de consorcio, no profundizaremos en este tema.

Para obtener más información sobre RSK, consulte:

• RSK: Una cadena lateral de Bitcoin con contratos inteligentes (papel RSK)[10]
• Dinero RSK[11]
• Preguntas frecuentes[12]

De los proyectos mencionados anteriormente, algunos han desaparecido (como cromosoma de color) y otros que venden la ecología de Ethereum bajo la apariencia de BTC. Esto se debe principalmente a que después de abrazar el capital, las Finanzas descentralizadas y las dApps tienen una ventaja absoluta en el mercado, por lo que es más difícil para los proyectos que no se juegan con ellas obtener una ventaja. Los tokens en Ethereum se emiten y negocian mediante contratos, siguiendo estándares de tokens como ERC-20. El ecosistema de BTC también ha comenzado a desbloquear la función de contrato en los últimos dos años, como BitVM, y ha aparecido el estándar de token BRC-20.

Implementar contrato inteligente en BTC: RGB

RGB (Really Good for Bitcoin), creado en 2016[13]Originalmente diseñado como competidor de las monedas de tinte. Pero ante desafíos similares, cambió su enfoque a habilitar contratos inteligentes en Bitcoin. Aunque se centra principalmente en la ejecución de contratos inteligentes en lugar de la emisión de tokens, la funcionalidad completa del contrato sigue siendo limitada hasta 2024 debido a las limitaciones de su máquina virtual AluVM.

La idea de RGB es colocar los datos que se pueden obtener fuera de la cadena y el código de contrato inteligente fuera de Bitcoin, proporcionando verificación de transacciones y compromiso de emisión de tokens a través de la raíz de Merkle, mientras que la cadena BTC solo realiza verificación y finalización de compromiso de transacciones, demostrando que no hay doble gasto.

Una característica destacada del RGB es el uso simultáneo de la verificación del cliente y la tecnología de cinta de sellado único, de modo que no se marca en la UTXO para representar Token. Estos dos conceptos fueron introducidos por primera vez por Peter Todd en 2013.[14]Giacomo Zucco y Maxim Orlovsky propusieron el protocolo RGB basado en esto.

La validación del lado del cliente (validación del lado del cliente) permite que los datos y el código utilizados en la transacción se mantengan fuera de la cadena, no se difundan públicamente, y algunos datos pueden intercambiarse solo entre las dos partes de la transacción en privado, sin que otros involucrados en la transacción lo sepan. El estado fuera de la cadena se mantiene con BTC, y la cadena de bloques actúa como un Marca de tiempo, lo que puede demostrar el orden de los estados.

Y un sello de un solo uso (single-use seal) - también es la apariencia más común de la verificación del cliente - es una versión digital de un sello de un solo uso. Aprovechando la propiedad de que cada UTXO solo puede gastarse una vez, se escribe información en estado fuera de la cadena en un UTXO. De esta manera, si en algún momento se gasta este UTXO, sabemos que el estado se ha actualizado y la información del estado actualizada se escribe en un nuevo UTXO generado. Esta información de estado fuera de la cadena puede ser la propiedad de un token USDT o la cantidad de tokens en un contrato.

Por ejemplo, Alice quiere transferir un USDT a Bob. Este USDT no existe en la cadena (on-chain), su información se mantiene fuera de la cadena (off-chain), pero está vinculado a un UTXO controlado por Alice. Su información se guarda en el campo OP_RETURN del UTXO que generó la transacción con valor cero. De esta manera, solo Alice puede gastar este USDT, y Bob puede rastrear a través de transacciones on-chain en qué UTXO anteriores se ha guardado este USDT, si estos UTXO son válidos y si la transacción es legítima. Por lo tanto, cuando Alice inicia la transacción para transferir la información de compromiso de este USDT a un UTXO controlado por Bob, él puede estar seguro de que ha recibido este USDT.

RGB también puede funcionar en la Red de Rayos, ya que su estado es off-chain, solo es necesario colocar el compromiso en on-chain o en la Red de Rayos. Después de la actualización de Taproot, RGB puede incrustar el compromiso en una transacción Taproot, lo que permite a RGB incrustar el compromiso en Bitcoin de manera más flexible.

Para obtener más información sobre RGB, consulte: Plan RGB[15]

Solo admite Token, no admite contratos inteligentes: activo Taproot

Taproot Asset es Lightning Network Daemon (LND)[16][17]Proyecto desarrollado por el equipo. Su principio es similar al de RGB, pero no admite contratos inteligentes complejos, solo admite tokens (consulte la entrada de TAPROOT aquí)explicación).

Obtenga más información sobre la validación del lado del cliente, RGB y Taproot, consulte:

1. Validación en el lado del cliente[18]
2. Transacciones fuera de cadena: La evolución de los protocolos de activos de Bitcoin[19]
3. Counterparty vs RGB vs TARO[20]

Hacer que cada Satoshi sea único: Ordinales & Iniones

Casey Rodarmor lanzó Ordinal Protocol a principios de 2023[21]El proyecto se originó a partir de la idea de cómo asignar números a los satoshis para que cada uno tenga un número de serie único y pueda ser ordenado. Esta idea surgió al mismo tiempo que la de las monedas coloreadas, pero fue propuesta nuevamente el año pasado. Además, con la incorporación de las funciones SegWit y Taproot, su implementación se volvió menos complicada. Ordinal hace que cada satoshi sea único, lo que permite la emisión directa de NFT en la cadena de Bitcoin.

Inions[22]Es un proyecto NFT así. Los datos NFT se almacenan en los datos de testigo de transacción, en lugar del campo OP_RETURN utilizado por proyectos anteriores, lo que puede almacenar metadatos de hasta 4MB. A diferencia de los NFT en Ethereum, Inion se almacena en la cadena, incluidos metadatos e imágenes.

Para obtener más información sobre Ordinals, consulte:

1. ¿Los ordinales: un terreno común para los maximalistas de Ethereum y Bitcoin?[23]
2. La guía definitiva de ordinales e iniones de Bitcoin[24]

Vinculación bidireccional de cualquier cadena UTXO: Vinculación homomórfica RGB++

RGB++[25][26]Originalmente como BTC y CKB (Nervos Network)Apareció el protocolo de vinculación isomórfica (isomorphic binding protocol) entre las cadenas de UTXO (transacción no gastada) (en su base), y ahora su alcance es muy amplio, no se limita solo a CKB y BTC, en teoría, cualquier par de cadenas de UTXO puede usar este protocolo para vincularse.

RGB++ lleva a cabo una mayor expansión de las ideas de validación del lado del cliente y de los sellos de un solo uso de RGB. Como se mencionó anteriormente, el mayor problema del protocolo RGB es que los datos son almacenados por los usuarios localmente. Si los usuarios pierden los datos por descuido, no hay respaldo y no se pueden recuperar. Además, debido a que los usuarios solo almacenan los datos relacionados con sus propios tokens, es difícil verificar otros datos. La solución propuesta por la capa de enlace homogénea es vincular los tokens no solo al campo OP_RETURN de una salida no gastada de Bitcoin, sino también vincular la información de transacción de Bitcoin correspondiente a la transacción en cadena de CKB (a través de la celda CKB[27]Dentro del Lock , se utiliza un IB-lock especial para implementarlo. Cuando se determina si una transacción en cadena CKB es válida, el Lock utilizará los datos del cliente ligero BTC en CKB para verificar si se ha gastado el UTXO correspondiente y si el nuevo UTXO generado después del gasto está vinculado a la información de transacción de Token actual (como información no firmada).

Las características de RGB++ que vale la pena seguir:

• Solucionar el problema de disponibilidad de datos mediante la vinculación bidireccional: CKB Cell se compromete a vincularse al campo OP_RETURN de UTXO; La información de UTXO está vinculada a la Output Cell de la transacción CKB.
• Compatible con Lighting Network y Fiber Network (Lightning Network basado en CKB)
• Soporte para múltiples activos
• Se puede vincular con cualquier cadena UTXO

Para obtener más información sobre RGB++, consulte:

1. RGB++ Protocol Light Paper[28]
2. La guía definitiva para RGB, RGB++ y validación del lado del cliente[29]

Para comprender mejor las ventajas y limitaciones de cada proyecto, hemos comparado los proyectos en la tabla a continuación. Los indicadores a los que debemos prestar especial atención son:

• Disponibilidad de datos: La cadena isomórfica y la cadena lateral son casi iguales, mientras que la disponibilidad de datos fuera de la cadena es más débil que otras soluciones. El orden de fortaleza a debilidad es: en la cadena ≥ cadena isomórfica ≥ cadena lateral > fuera de la cadena;
• Portador de activos (Asset carrier): los esquemas de Token directamente relacionados con BTC son mejores que los esquemas no directamente relacionados;
• Fungibilidad: Esto se refiere a si el Token nativo del proyecto es intercambiable entre sí, no significa que el proyecto no admita Token no fungible, este último puede lograrse mediante la adición de protocolos adicionales.
• 表现力（Expressiveness）：指处理复杂 Contrato inteligente的能力。

Enlaces mencionados en el texto:[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

knowledge-base/ultimate_guide_to_rgb_rgbpp_and_client_side_validation[29]