BTC va bientôt disposer de la capacité des smart contracts

Récemment, un développement important est survenu dans l'écosystème Bitcoin - Fractal BTC a officiellement lancé son réseau principal en septembre après plusieurs tests. Un des points forts de Fractal est sa capacité à exécuter des smart contracts, et en même temps que le lancement du réseau principal, un nouveau protocole de jetons nommé CAT20 a été introduit. Quelles sont les subtilités dans la conception technique de CAT20 ? Qu'est-ce que nous pouvons en apprendre ?

Introduction au Fractal Bitcoin

Avant de comprendre le CAT20, nous devons d'abord avoir une brève compréhension du Fractal Bitcoin. La relation entre les deux est similaire à celle entre l'ERC20 et l'ETH, le protocole CAT20 est déployé sur le 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 de bloc est plus rapide, ne prenant qu'une minute. Son principe de base est de copier le réseau BTC plusieurs fois, chaque chaîne pouvant traiter des transactions, et avec l'augmentation du nombre de nœuds traitant les transactions, la vitesse augmente naturellement. Cependant, les détails spécifiques sur la manière dont les différentes chaînes communiquent entre elles ne sont pas encore très clairs, et les autorités n'ont pas fourni de documentation technique à ce sujet.

Un des points forts de Fractal est l'activation de l'opcode OP_CAT, qui avait été abandonné depuis longtemps pour des raisons de sécurité. Cela a considérablement amélioré les capacités de Fractal Bitcoin. Certains pensent qu'OP_CAT pourrait doter le BTC de capacités en matière de smart contracts, ce qui offre plus d'espace d'imagination pour Fractal.

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 sous-jacent, un protocole correspondant est rapidement apparu - le CAT Protocol. Actuellement, le protocole CAT20 est déjà en fonctionnement.

Comment le CAT20 parvient-il à réaliser un cycle de vie similaire par rapport au protocole ERC20 mature ?

Déployer

Avant le déploiement, l'utilisateur doit spécifier l'adresse du portefeuille et les informations de base sur le jeton, qui sont similaires à l'ERC20. La différence est que le CAT20 peut définir la quantité de pré-extraction et la limite de quantité pour chaque Mint.

Le déploiement se compose de deux phases : "commit" et "reveal". À la phase de commit, les informations de base du token seront écrites dans le script de sortie de la transaction. Le hashId de la transaction commit servira d'identifiant pour ce token. À la phase de reveal, un OP_RETURN sera émis pour sauvegarder le Hash de l'état initial du CAT20, ainsi qu'un Minter pour le processus de Mint ultérieur.

Tout le processus de déploiement utilise la méthode en deux étapes de soumission-révélation courante sur la blockchain, certaines données du projet ne seront rendues publiques qu'à la phase de révélation.

Mint

Le processus de Mint a les caractéristiques suivantes :

• L'entrée est un minter, initialement généré par le déploiement.
• Chaque mint a exactement un minter comme entrée, et peut avoir n'importe quel nombre de minters comme sortie.
• À chaque mint, il n'y a qu'un seul token.
• L'ordre de sortie a des exigences, le minter doit être avant le token.

Le nombre de minters en sortie peut être de 0, 1 ou plusieurs. Si un seul est produit à chaque fois, le nombre de minters disponibles dans le réseau reste inchangé, ce qui peut entraîner une congestion. Fixer une valeur supérieure à 1 peut augmenter le nombre de minters disponibles, mais cela signifie qu'il faut payer des frais utxo plus élevés. Pour des raisons économiques, beaucoup de personnes peuvent choisir de définir le minter à 0, ce qui entraînera une déflation des minters, nécessitant que certains utilisateurs paient volontairement plus de minters.

Dans la version V2, deux Minter avec des états similaires sont générés par défaut.

construction de transaction

Pourquoi peut-on utiliser les UTXO de minter pour construire des transactions ? Cela concerne quelques conceptions ingénieuses du code source des "smart contracts" :

1. révéler utxo : En utilisant une paire de clés publiques et privées dans le script, vous pouvez contrôler les utxo de deux adresses différentes.

2. minter utxo : Il est supposé que cela utilise la capacité des smart contracts fournie par OP_CAT, chaque minter étant un smart contract. Cependant, cette partie du code source n'est pas encore publique.

État de la transaction (V2)

L'état est conservé dans le minter, stocké dans OP_RETURN et les smart contracts. OP_RETURN stocke le hash de l'état de la sortie de transaction actuelle, tandis que le contrat stocke le nombre de Mint restant pour le Token. Après chaque Mint, le nombre de mint généré par le nouveau Minter est égal à la moitié du nombre restant de mint.

Enfin, le Token( généré, à savoir CAT20), est également un smart contract, avec deux états de base : le nombre et l'adresse du propriétaire. Il convient de noter que CAT20 n'existe pas sur le UTXO de l'adresse utilisateur comme le BRC20 ou les inscriptions.

Transfert

Lors du transfert, le nombre de tokens d'entrée et de sortie dans la construction de la transaction doit rester cohérent. Une même transaction peut avoir plusieurs tokens différents, tant que les quantités d'entrée et de sortie respectives sont cohérentes.

Brûler

Transférer le Token à une adresse ordinaire permet de le brûler.

Résumé

Toutes les opérations de CAT20 sont construites par les utilisateurs eux-mêmes, offrant une grande flexibilité. Par conséquent, la partie contrat nécessite une logique de validation stricte. Les avantages de ce design incluent :

1. Pour consulter tous les avoirs de Token, il suffit de vérifier l'utxo du token, sans remontée dans le temps.

2. Pour voir l'état actuel de la mint, vous pouvez rechercher des transactions contenant des données cat dans OP_RETURN.

Ce design offre aux utilisateurs une plus grande flexibilité, mais impose également des exigences plus élevées en matière de sécurité des contrats. Le développement futur du protocole CAT20 mérite une attention continue.