Este artículo es sólo para compartir aspectos técnicos y no constituye ningún consejo de inversión.
¿BTC también tendrá su propio contrato inteligente?
En el reciente ecosistema de Bitcoin, Fractal BTC finalmente lanzó la red principal en septiembre después de pasar por múltiples redes de prueba. Una característica importante de Fractal es la capacidad de tener "contratos inteligentes" y casi al mismo tiempo que se lanzó la red principal, se lanzó un nuevo protocolo de token CAT 20. ¿Qué inteligencia técnica tiene CAT 20? ¿Qué podemos aprender?
Fractal Bitcoin
Antes de comprender CAT 20, debemos 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 Fractal Bitcoin, es una red de "segunda capa" que es totalmente compatible con BTC. En comparación con BTC, el tiempo de confirmación de bloque es más rápido y solo toma 1 minuto. Su principio básico es simplemente, como su nombre lo indica, que es hacer varias copias de la red BTC. Cada cadena procesará transacciones. Cuantos más nodos puedan procesar transacciones, más rápido será naturalmente. Sin embargo, los detalles específicos, como cómo se comunican las diferentes cadenas, aún no están claros y no existen documentos técnicos oficiales correspondientes como referencia.
Si solo una transacción en cadena de segunda capa es más rápida, no parece haber motivo de entusiasmo. Sin embargo, la activación de OP_CAT en Fractal, que BTC abandonó hace mucho tiempo por razones de seguridad, ha llevado las capacidades de Fractal Bitcoin a un nivel superior. Algunas personas dicen que OP_CAT puede permitir que BTC tenga capacidades de contrato inteligente. De esta manera, hay espacio para la imaginación.
Ahora, alguien ha implementado un protocolo similar a ERC 20 en Fractal Bitcoin.
En cuanto a por qué se abandonó OP_CAT y por qué se puede usar en Fractal Bitcoin, podemos hablar de ello más adelante. Aquí nos centraremos en CAT 20.
Protocolo CAT Consulte el documento técnico para conocer el siguiente contenido: Introducción | Protocolo CAT (https://catprotocol.org/)
Y repositorio de github: GitHub - CATProtocol/cat-token-box: un monorepo para paquetes que implementan el protocolo CAT (https://github.com/CATProtocol/cat-token-box)
Con el soporte OP_CAT subyacente, pronto estará disponible el protocolo correspondiente, el protocolo CAT. Actualmente, un protocolo que se está ejecutando es el protocolo CAT 20 y se ha agregado un panel correspondiente en Unisat: https://explorer.unisat.io/fractal-mainnet/cat20.
Todos deberían poder reaccionar cuando vean el nombre de CAT 20. Debería ser más similar a ERC 20. En comparación con el protocolo ERC 20 maduro, es muy conveniente para todos implementar un token. ¿Cómo implementa CAT 20 un ciclo de vida similar al ERC 20?
Desplegar
Antes de la implementación, los usuarios deben especificar la dirección de su billetera y la información básica sobre el token. La información básica sobre el token es similar a la de ERC 20:
Habrá algunas diferencias. CAT 20 puede establecer límites de cantidad y preminería para cada Mint. Por supuesto, ERC 20 también puede lograr estas capacidades a través de capacidades contractuales.
Durante la fase de implementación, se iniciarán dos transacciones, que pueden considerarse como dos fases: "comprometer" y "revelar". Citando el diagrama oficial, las etapas de implementación son las siguientes:
En la etapa de "compromiso", la información básica del token se escribirá en el script de salida de la transacción, como el nombre, símbolo, etc. del token. El hashId de la transacción iniciada en la fase de "commit" se utilizará como símbolo del token para distinguir otros tokens.
Puedes ver que el utxo de esta transacción " bc 1 pucq...ashx " corresponde a commit. Luego quedan dos transacciones que apuntan a " bc 1 pszp...rehc 4 ". La primera se utiliza para pagar la tarifa del gas para la siguiente etapa de "revelación" y la otra es el cambio.
En la etapa de "revelación", puede ver que hay dos entradas utxo, correspondientes a las dos primeras salidas de la etapa de confirmación anterior. Esta transacción generará primero un OP_RETURN, en el que se guardará el Hash del estado inicial de CAT 20. Luego se generará un Minter, que desempeñará un papel importante en el proceso Mint posterior y se utilizará para mantener los cambios de estado del proceso Mint.
Mirando hacia atrás en todo el proceso de implementación, "confirmar" y "revelar" siguen los dos pasos de envío y revelación que se usan comúnmente en la cadena de bloques. Es una forma relativamente común de implementar proyectos. Algunos datos del proyecto solo están en "revelar". Las etapas serán reveladas.
Como
Cuando miramos por primera vez Mint Token, la transacción se ve así.
Como puedes ver en la imagen de arriba, el proceso de Mint tiene las siguientes características.
La entrada de mint es un minter, que se genera inicialmente durante la implementación.
Cada vez, Mint tiene uno y solo un minter como entrada, y cualquier número de minters como salida (un poco problemático)
Cada casa de moneda tiene solo una ficha (un poco problemático)
El orden de salida es obligatorio, el minter debe ir seguido del token.
Conociendo el proceso Mint, podemos descubrir algunas situaciones especiales que harán que todo el proceso Mint sea interesante.
Por ejemplo, minter, como resultado de la transacción mint, puede ser 1, múltiplo o incluso 0. Si Mint se establece en 1 cada vez, la cantidad de minters que se pueden usar en toda la red permanecerá sin cambios (1), lo que hará que Mint esté lleno de gente y todos deben tomar este minter para evitar esto. En este caso, debe establecer el número de minters producidos cada vez en mayor que 1, de modo que después de acuñar, se puedan usar más y más minters.
Sin embargo, cada producción adicional de minter significa que debe pagar un utxo adicional. Por razones económicas, más personas estarán dispuestas a establecer minter en 0, lo que inevitablemente provocará una deflación, lo que requiere que algunas personas vengan a hacer una donación y pagar. el minter extra voluntariamente.
En la versión V2, el valor predeterminado es generar dos minters y el estado de los dos minters será lo más similar posible.
Estructuración de transacciones
Es posible que algunos amigos hayan descubierto un problema, es decir, ¿por qué se puede utilizar el utxo de minter para construir transacciones? Para comprender este problema, es necesario analizar el código fuente del "contrato".
1、revelar utxo
Primero, analizamos la transacción durante el proceso de revelación y encontramos que utiliza la confirmación de salida de la transacción anterior como entrada. ¿Por qué podemos tomar un utxo que no es nuestra dirección y construir la entrada de la transacción?
Según el sentido común, una clave privada corresponde a una clave pública y de la clave pública se deriva la dirección. Al verificar si un utxo de entrada es válido, generalmente se determina comparando si la firma es consistente con la transacción original después de ser descifrada con la clave pública. Esta parte de la lógica está escrita en escritura Bitcoin. De esta manera podemos reescribir inteligentemente la lógica del script. Los pares de claves públicas y privadas escritas en el script pertenecen a nuestra propia dirección, de modo que podamos controlar utxo de dos direcciones diferentes.
Mirando el código fuente podemos ver lo que pasó:
Hay otro problema aquí, es decir, una clave privada corresponde a una clave pública, entonces, ¿por qué la dirección de confirmación generada es diferente de nuestra dirección? Aquí puedes verlo desde el código fuente.
En otras palabras, nuestra clave privada ajustará la clave pública de acuerdo con ISSUE_PUBKEY, que también es una característica de la dirección P 2 TR.
2、minter uxo
Durante el proceso de revelación, utilizamos diferentes utxo como entrada, pero en realidad la clave de cifrado es la misma, que es la clave privada del implementador. Pero en la etapa minter, todos pueden usar estos utxo como entrada, ¿cómo se hace esto?
Supongo que esta parte es la capacidad de OP_CAT mencionada anteriormente, es decir, la capacidad de los contratos inteligentes. Cada minter es un contrato inteligente. Sin embargo, el código fuente de esta parte no se ha hecho público en este momento y aún no conocemos la implementación específica.
Estado de la transacción (V2)
En minter también se conserva el estado. Este estado existe en dos lugares: uno está en el OP_RETURN de la salida de la transacción y el otro se almacena en el contrato inteligente, que es 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 Mint restantes del Token se almacenan en el contrato. Después de cada Mint, el número de mints del Minter recién generado será igual al número restante de mints dividido por dos. Representado con un diagrama:
Al final del juego, el número restante de todos los 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, que es CAT 20. CAT 20 tiene dos estados básicos: cantidad y dirección del propietario del Token. Puedes ver que a diferencia del BRC 20 o inscripción anterior, tu CAT 20 no está en el UTXO de tu dirección.
Transferir
Al transferir, la cantidad de tokens de entrada y salida en la transacción debe ser consistente. Por supuesto, puede haber varios tokens diferentes en la misma transacción, siempre que los números de entrada y salida de diferentes tokens sean consistentes.
Quemar
Si desea quemar el Token, solo necesita transferir el Token a una dirección normal.
Resumir
Se puede ver que todas las operaciones las construyen los propios usuarios, lo cual es muy flexible, por lo que se debe realizar mucha lógica de verificación en la parte del contrato. Algunas de las vulnerabilidades expuestas hasta ahora también se deben a negligencias en la lógica de verificación.
Un diseño de este tipo puede tener algunos beneficios:
Si desea encontrar el estado de tenencia de todos los tokens, solo necesita verificar el utxo del token y no es necesario continuar buscando.
Si desea verificar la situación actual de mint, puede buscar transacciones con cat en los datos en OP_RETURN.
¡ZAN está aquí para conseguir agua sin ningún umbral!
Consejo: puede recibir un token testnet gratuito de 0,01 ETH cada 24 horas para ayudarle a experimentar y probar proyectos Web3 en el ecosistema Ethereum. Haga clic para recibirlo ahora: https://zan.top/faucet?chInfo=ch_WZ.
Pronto se admitirán más cadenas públicas ~
Este artículo está escrito por Yeezo (cuenta X @GaoYeezo 75065) del equipo ZAN (cuenta X @zan_team)