BTC aura également sa propre fonction de smart contracts

Récemment, un projet nommé Fractal BTC dans l'écosystème Bitcoin a officiellement lancé son réseau principal en septembre après plusieurs tours de test. L'un des points forts de Fractal est sa capacité à exécuter des smart contracts, et au moment du lancement du réseau principal, un nouveau protocole de jeton, le CAT20, a été introduit. Quelles sont donc les subtilités techniques du CAT20 ? Que pouvons-nous en apprendre ?

Introduction au Fractal Bitcoin

Avant de comprendre CAT20, nous devons d'abord avoir une brève compréhension de Fractal Bitcoin. La relation entre les deux est similaire à celle entre ERC20 et ETH, le protocole CAT20 est déployé sur Fractal Bitcoin.

Fractal Bitcoin, également connu sous le nom de Bitcoin fractal, est un réseau "de deuxième couche" entièrement compatible avec BTC. Par rapport à BTC, son temps de confirmation des blocs est plus rapide, ne prenant qu'une minute. Son principe de base est, en termes simples, de copier le réseau BTC plusieurs fois, chaque chaîne pouvant traiter des transactions, ce qui augmente le nombre de nœuds capables de traiter des transactions et, par conséquent, améliore la vitesse. Cependant, les détails spécifiques, tels que les méthodes de communication entre les différentes chaînes, ne sont pas encore très clairs, et les autorités n'ont pas fourni de documentation technique correspondante pour référence.

Si un échange sur une chaîne de deuxième couche est plus rapide, cela ne semble pas suffisant pour susciter l'enthousiasme. Cependant, Fractal a activé l'opcode OP_CAT, qui avait été abandonné par le BTC pour des raisons de sécurité il y a longtemps, ce qui a permis d'élever les capacités de Fractal Bitcoin à un nouveau niveau. Certains estiment que l'OP_CAT pourrait donner au BTC la capacité de réaliser des smart contracts, offrant ainsi plus d'espace d'imagination.

Actuellement, quelqu'un a déjà mis en œuvre un protocole similaire à l'ERC20 sur Fractal Bitcoin.

CAT Protocol

Avec le soutien de l'OP_CAT de base, le protocole CAT Protocol a rapidement vu le jour. Actuellement, un protocole déjà en fonctionnement est le protocole CAT20.

Comparé au protocole ERC20 mature, il est désormais très facile pour tout le monde de déployer un Token. Alors, comment CAT20 réalise-t-il un cycle de vie similaire à celui d'ERC20?

Déployer

Avant le déploiement, l'utilisateur doit spécifier son adresse de portefeuille ainsi que les informations de base sur le jeton, qui sont similaires à celles de l'ERC20. Certaines différences de CAT20 résident dans la possibilité de définir une pré-extraction et une limite sur le nombre de Mint à chaque fois. Bien sûr, l'ERC20 peut également réaliser ces fonctionnalités grâce aux capacités du contrat.

Au stade du déploiement, deux transactions seront initiées, pouvant être considérées comme deux phases : "commit" et "reveal". Pendant la phase "commit", les informations de base du jeton, telles que le nom et le symbole du jeton, seront écrites dans le script de sortie de la transaction. Le hashId de la transaction initiée lors de la phase "commit" servira d'identifiant pour ce jeton, afin de le distinguer des autres jetons.

Au stade de "reveal", la transaction produira d'abord un OP_RETURN, qui contient le Hash de l'état initial du CAT20. Ensuite, elle produira un Minter, qui jouera un rôle important dans le processus de Mint ultérieur, servant à maintenir les changements d'état du processus de Mint.

Tout le processus de déploiement, "commit" et "reveal" suit les deux étapes couramment utilisées sur la blockchain, ce qui est une méthode assez courante pour déployer des projets.

Mint

Lors de la création d'un jeton, les transactions présentent les caractéristiques suivantes:

• l'entrée de mint est un minter, généré initialement lors du déploiement.
• Chaque mint a un et un seul minter comme entrée, avec n'importe quel nombre de minters comme sortie.
• Chaque mint a et n'a qu'un seul token.
• L'ordre de sortie a des exigences, minter doit être suivi de token.

Le minter, en tant que sortie d'une transaction de mint, peut être 1, plusieurs ou même 0. Si chaque mint est réglé sur 1, alors le nombre de minters utilisables dans tout le réseau restera constant à (1 minters à ), ce qui rendra le mint encombré. Pour éviter cela, il est nécessaire de définir le nombre de minters sortants à chaque fois à plus de 1, ainsi après le mint, le nombre de minters utilisables par tout le monde augmentera.

Cependant, chaque minter supplémentaire signifie qu'il faut payer un utxo supplémentaire. Pour des raisons économiques, davantage de personnes auront tendance à définir le minter à 0, ce qui entraînera inévitablement une déflation du minter, nécessitant que certaines personnes fassent des dons, en payant volontairement le minter supplémentaire.

Dans la version V2, deux Minter sont générés par défaut, et l'état des deux Minter sera aussi proche que possible.

construction de la transaction

Pourquoi peut-on utiliser les utxo de minter pour construire des transactions ? Cela nécessite d'analyser le code source des "smart contracts".

Pendant le processus de révélation, la transaction utilise la sortie commit de la transaction précédente comme entrée. Cela est réalisé par une réécriture astucieuse de la logique du script, où les paires de clés publiques et privées écrites dans le script sont celles de notre propre adresse, ce qui nous permet de contrôler les utxo de deux adresses différentes.

Pour les minters utxo, tout le monde peut utiliser ces utxo comme entrée, ce qui pourrait être la capacité des smart contracts fournie par OP_CAT, chaque minter étant un smart contract.

État de la transaction (V2)

L'état est conservé dans le minter à deux endroits : d'une part dans l'OP_RETURN de la sortie de transaction, d'autre part dans les smart contracts.

Le Hash stockant l'état de la sortie de transaction actuelle dans OP_RETURN, et le nombre de Mint restant du Token stocké dans le contrat. Après chaque Mint, le nombre de mint du nouveau Minter sera égal à la quantité restante pouvant être mintée divisée par deux.

À part le Minter qui est un smart contract, le Token généré est aussi un smart contract, c'est-à-dire CAT20. CAT20 a deux états fondamentaux : la quantité et l'adresse du propriétaire du Token. Il est à noter que, contrairement aux BRC20 ou aux inscriptions, le CAT20 n'est pas sur le UTXO de votre adresse.

Transfert

Lors du transfert, le nombre de tokens en entrée et en sortie de la transaction doit être cohérent. Une même transaction peut avoir plusieurs tokens différents, il suffit que le nombre d'entrées et de sorties pour chaque token soit cohérent.

Burn

Pour brûler des tokens, il suffit de transférer les tokens à une adresse ordinaire.

Résumé

Toutes les opérations sont construites par les utilisateurs eux-mêmes, offrant une grande flexibilité. Par conséquent, la partie contrat nécessite beaucoup de logique de vérification. Certains des vulnérabilités qui apparaissent actuellement sont également dues à des négligences dans la logique de vérification.

Ce design présente certains avantages :

1. Pour trouver la situation de détention de tous les tokens, il suffit de consulter l'utxo du token, sans avoir besoin de continuer à chercher plus haut.
2. Pour voir l'état actuel de mint, vous pouvez rechercher des transactions dans OP_RETURN contenant des données avec cat.