CAT20: Tokenprotocolo en Fractal BTC

Este artículo es solo para compartir información técnica y no constituye ninguna recomendación de inversión.

BTC 上也要有自己的 Contrato inteligente了？

Recientemente, en el ecosistema de BTC, después de pasar por varias pruebas de Testnet, finalmente se lanzó en Mainnet en septiembre. Una de las características principales de Fractal BTC es su capacidad para contratos inteligentes, y casi al mismo tiempo que se lanzó en Mainnet, se lanzó un nuevo protocolo de token CAT 20. ¿Qué diseños técnicos ingeniosos tiene CAT 20? ¿Qué podemos aprender de esto?

Bitcoin Fractal

Antes de entender CAT 20, necesitamos comprender brevemente Fractal Bitcoin, su relación es similar a la de ERC 20 y ETH, el protocolo CAT 20 se implementa en Fractal Bitcoin.

Fractal Bitcoin, también conocido como BTC fractal, es una red de "segunda capa" completamente compatible con BTC. En comparación con BTC, tiene tiempos de confirmación de Bloquear más rápidos, solo se requiere 1 minuto. El principio básico es simplemente como su nombre lo indica, copia la red BTC varias veces, cada cadena procesará transacciones y la cantidad de Nodos que pueden procesar transacciones aumenta, lo que naturalmente acelera la velocidad. Sin embargo, los detalles específicos, como cómo se comunica entre las diferentes cadenas, aún no están muy claros y no hay documentos técnicos correspondientes proporcionados por el oficial para su referencia.

Si solo se trata de una transacción de cadena de segundo nivel más rápida, parece no haber un punto emocionante. Sin embargo, en Fractal, habilitar BTC, que se abandonó hace mucho tiempo por razones de seguridad, utilizando el Código de operación OP_CAT, eleva la capacidad de Bitcoin Fractal Subir un escalón. Algunos dicen que OP_CAT puede dotar a BTC con la capacidad de Contrato inteligente, lo que abre aún más espacio para la imaginación.

Ahora, alguien ha implementado un protocolo similar a ERC 20 en Fractal Bitcoin.

Sobre por qué se abandonó y por qué se puede usar en Fractal Bitcoin, se puede ampliar más adelante, aquí seguiremos hablando de CAT 20 .

Protocolo CAT A continuación se muestra la referencia al libro blanco: Introducción | Protocolo CAT ()

Además del repositorio de GitHub: GitHub - CATProtocol/cat-token-box: Un monorepo para paquetes que implementan el protocolo CAT ()

Con el soporte subyacente de OP_CAT, pronto se desarrolló el protocolo correspondiente, CAT Protocol. Actualmente, un protocolo que ya se está ejecutando en la práctica es el protocolo CAT 20, y también se ha añadido un panel correspondiente en Unisat:

Al ver el nombre CAT 20, creo que todos pueden darse cuenta de que debería ser similar al ERC 20. En comparación con el maduro protocolo ERC 20, desplegar un Token ya es muy conveniente. ¿Cómo logra CAT 20 implementar un ciclo de vida similar al de ERC 20?

Deploy

Antes de implementar, los usuarios deben especificar su DIRECCIÓN de Billetera y la información básica del Token, que es similar a la de ERC 20.

Habrá algunas diferencias. CAT 20 permite establecer límites de pre-minado y cantidad de Mint cada vez. Por supuesto, ERC 20 también puede lograr estas capacidades a través de la capacidad del contrato.

Durante la etapa de implementación, se realizarán dos transacciones, que se pueden considerar como dos etapas: 'commit' y 'reveal'. Según la imagen oficial, las etapas de implementación son las siguientes:

En la etapa de "commit", la información básica del Token se escribirá en el script de salida de la transacción, como el nombre y el símbolo del Token. El hashId de la transacción iniciada en la etapa de "commit" servirá como identificador de este Token, utilizado para distinguirlo de otros Tokens.

Se puede ver que esta transacción "bc 1 pucq...ashx" corresponde a commit. Luego, las otras dos transacciones apuntan a "bc 1 pszp...rehc 4", la primera se utiliza para pagar la tarifa de gas en la etapa "reveal", y la otra es el cambio.

En la etapa de "revelación", se pueden ver dos entradas UTXO, que corresponden a las dos salidas anteriores de la etapa de compromiso. Esta transacción primero producirá un OP_RETURN, que guardará el estado inicial del Hash de CAT 20 en OP_RETURN. Luego producirá un Minter, que desempeñará un papel importante en el proceso posterior de acuñación, para mantener los cambios de estado en el proceso de acuñación.

Mirando hacia atrás en todo el proceso de implementación, "confirmar" y "revelar" siguen los dos pasos de confirmación y revelación comúnmente utilizados por Bloquearon-chain, que es una forma más común de implementar un proyecto, y algunos datos del proyecto solo se revelarán en la etapa de "revelación".

Mint

Cuando miramos el Mint Token, el comercio es así.

En la figura anterior, se pueden ver las siguientes características del proceso de Mint.

• La entrada de 'mint' es un creador de monedas, que se genera inicialmente al momento del despliegue.
• Cada vez que se crea una nueva moneda (mint) hay solo un creador de monedas (minter) como entrada y cualquier número de creadores de monedas como salidas (esto puede tener algunos problemas).
• Cada vez que se crea un token, solo hay un token (hay un pequeño problema)
• El orden de salida es importante, token debe ir después de minter.

Al entender el proceso de Mint, en realidad podemos descubrir algunas situaciones especiales que hacen que todo el proceso de Mint sea interesante.

Por ejemplo, como salida de la transacción de acuñación, Minter puede ser 1, varios o incluso 0. Si se establece en 1 cada vez que se acuña, la cantidad de Minter disponible en toda la red se mantendrá constante (1), lo que hará que la acuñación esté congestionada y todos tendrán que competir por este Minter. Para evitar esta situación, es necesario establecer la cantidad de Minter generados en cada transacción en un número mayor que 1, de esta manera, después de acuñar, habrá cada vez más Minter disponibles para todos.

Sin embargo, cada salida adicional de Minter significa que debe pagar una UTXO adicional. Por razones económicas, más personas estarán dispuestas a establecer Minter en 0, lo que inevitablemente hará que Minter sea deflacionario. Esto requiere que algunas personas hagan donaciones y paguen Minter adicionales.

En la versión V2, se generan dos Minter de forma predeterminada, y el estado de los dos Minter será lo más similar posible.

Construcción de operaciones

Es posible que algunos compañeros hayan encontrado un problema, que es por qué se puede utilizar la construcción de transacciones de utxo del minter. Para entender este problema, es necesario analizar el código fuente del "contrato".

1、reveal utxo

Primero analizamos las transacciones en el proceso de revelación, y descubrimos que utiliza el compromiso de salida de la transacción anterior como entrada. ¿Por qué se puede usar una utxo que no es nuestro DIRECCIÓN para construir la entrada de la transacción?

Según la lógica convencional, una Llave privada corresponde a una Llave pública, y la Llave pública deriva en DIRECCIÓN. Al verificar si una entrada de utxo es válida, generalmente se determina comparando si la desencriptación con la Llave pública utilizada para firmar es consistente con la transacción original. Esta lógica se escribe en el script de BTC. Por lo tanto, podemos ingeniar la lógica del script escribiendo que la clave pública en el script corresponde a nuestra propia DIRECCIÓN, permitiéndonos controlar los utxo de dos DIRECCIONES diferentes.

Podemos entender qué ha sucedido al mirar el código fuente:

Aquí también surgirá un problema, y es que una Llave privada corresponde a una Llave pública, entonces ¿por qué la DIRECCIÓN de commit generada es diferente de nuestra DIRECCIÓN? Esto se puede ver en el código fuente.

Es decir, nuestra llave privada se ajustará según una ISSUE_PUBKEY para ajustar la llave pública, que es una característica de la dirección P 2 TR.

2, minter utxo

En el proceso de revelación, utilizamos diferentes utxo como entradas, pero en realidad la Llave secreta de encriptación es la misma, es decir, la Llave privada del desplegador. Pero en la etapa de acuñación, ¿cómo puede todo el mundo utilizar estas utxo como entradas?

Esta parte es la capacidad del OP_CAT mencionada anteriormente, es decir, la capacidad de contratos inteligentes, donde cada minter es un contrato inteligente. Sin embargo, actualmente esta parte del código fuente no está disponible públicamente, por lo que no se sabe exactamente cómo se implementa.

Estado de la transacción (V2)

En Minter, el estado también se conserva. Este estado existe en dos lugares: uno es en OP_RETURN de la salida de la transacción, y el otro se almacena en el contrato inteligente, es decir, en el Minter y Token mencionados anteriormente.

Lo que se almacena en OP_RETURN es el hash del estado de salida de la transacción actual, y los tiempos de acuñación restantes del token se almacenarán en el contrato. Después de cada acuñación, el número de cecas para la acuñación recién generada será igual al número de cecas restantes dividido por dos. Representado por un diagrama:

Al finalizar, la cantidad restante de Minter es 0.

Volviendo a la imagen original, además de que Minter es un contrato inteligente, el token generado también es un contrato inteligente, es decir, TOKEN 20. TOKEN 20 tiene dos estados básicos: la cantidad y el dueño del token DIRECCIÓN. Se puede observar que, a diferencia de BRC 20 o inscripción anteriores, tu TOKEN 20 no está en tu UTXO DIRECCIÓN.

Transfer

Al transferir, la cantidad de tokens en las entradas y salidas construidas para la transacción debe ser consistente. Por supuesto, una transacción puede tener múltiples tokens diferentes, solo asegúrese de que la cantidad de entradas y salidas de tokens diferentes sea consistente.

Quemar

Si desea quemar TOKEN, simplemente transfiera TOKEN a una DIRECCIÓN normal.

Resumen

Se puede ver que todas las operaciones son construidas por el usuario mismo, lo que proporciona una gran flexibilidad, por lo que se requiere mucho lógica de validación en la parte del contrato. Algunos de los fallos descubiertos hasta ahora se deben a descuidos en la lógica de validación.

Este diseño puede tener algunos beneficios:

• Si desea buscar la situación de tenencia de todos los TOKEN, solo necesita verificar el utxo del token, no es necesario seguir buscando hacia arriba.
• Si desea ver la situación actual de mint, simplemente busque la transacción con datos OP_RETURN que contenga la palabra cat.

¡ZAN sin barreras para obtener agua!

Consejo: Puede reclamar 0.01 ETH de fichas de prueba gratuitas de la red de pruebas una vez cada 24 horas para apoyar su experiencia y prueba de proyectos Web3 en la red de Ethereum. Haga clic para reclamar de inmediato:

Más cadenas de bloques públicas serán compatibles próximamente～

Este artículo fue escrito por Yeezo (cuenta X @GaoYeezo 75065) del equipo ZAN (cuenta X @zan_team).