Contrats intelligents sur BTC : Fractal Bitcoin et protocole CAT20

Récemment, l'écosystème Bitcoin a connu un développement important. Après plusieurs tests sur le réseau, Fractal BTC a été officiellement lancé sur le réseau principal en septembre. Un des points forts de Fractal est qu'il dispose de fonctionnalités de smart contracts, et a presque simultanément lancé le nouveau protocole de jetons CAT20. Alors, quelles sont les subtilités de la conception technique de CAT20 ? Que pouvons-nous en apprendre ?

Introduction au Fractal Bitcoin

Avant de plonger dans CAT20, nous devons d'abord comprendre brièvement le 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 couche deux" entièrement compatible avec BTC. Par rapport à BTC, son temps de confirmation des blocs est plus rapide, n'ayant besoin que d'une minute. Son principe de base est, comme son nom l'indique, de copier le réseau BTC plusieurs fois, chaque chaîne pouvant traiter des transactions, ce qui améliore la vitesse de traitement globale. Cependant, concernant les détails techniques spécifiques, tels que la communication entre les différentes chaînes, les responsables n'ont pas encore fourni de documentation technique détaillée.

Un des grands points forts de Fractal est l'activation de l'opcode OP_CAT, qui avait été abandonné depuis longtemps par BTC en raison de problèmes de sécurité. Cela améliore considérablement les capacités de Fractal Bitcoin, et certains estiment qu'OP_CAT peut conférer à BTC des capacités de smart contracts, ouvrant ainsi plus de possibilités pour le développement futur.

Actuellement, des développeurs ont mis en œuvre un protocole similaire à l'ERC20 sur Fractal Bitcoin.

CAT Protocol aperçu

Avec le soutien de l'OP_CAT sous-jacent, des protocoles associés sont rapidement apparus, à savoir le protocole CAT. Actuellement, le protocole CAT20 est en cours d'exécution.

Comment le CAT20 réalise-t-il un cycle de vie de jetons similaire par rapport aux protocoles ERC20 matures ?

processus de déploiement

Avant le déploiement, l'utilisateur doit spécifier l'adresse du portefeuille et les informations de base sur le jeton. Par rapport à l'ERC20, le CAT20 a ajouté la possibilité de définir des pré-mines et des limites sur le nombre de Mint par fois.

Le déploiement se divise en deux phases : "commit" et "reveal".

1. Phase "commit": Les informations de base du token, telles que le nom, le symbole, etc., sont écrites dans le script de sortie de la transaction. Le hashId de cette transaction sert d'identifiant unique pour le token.

2. Phase "reveal" : sortie un OP_RETURN, enregistre le Hash de l'état initial du CAT20. En même temps, sort un Minter, utilisé pour maintenir les changements d'état lors du processus de Mint ultérieur.

Cette approche en deux étapes est couramment utilisée dans le déploiement de projets blockchain, permettant de révéler certaines données du projet uniquement lors de la phase "reveal".

processus de Mint

Les transactions Mint présentent les caractéristiques suivantes :

• L'entrée est un minter, initialement généré par le déploiement.
• Chaque mint n'a qu'un seul minter en entrée, mais peut avoir plusieurs minters en sortie
• Chaque mint génère un token
• L'ordre de sortie exige que minter soit avant le token

La configuration du nombre de minters affectera l'activité de Mint dans l'ensemble du réseau. Un réglage à 1 entraînera des congestions, tandis qu'un réglage supérieur à 1 augmentera le coût pour les utilisateurs. La version V2 génère par défaut deux minters dans des états proches.

construction de la transaction

Le processus de Reveal utilise une réécriture astucieuse de la logique des scripts, en contrôlant les UTXO de différentes adresses avec sa propre clé privée. La phase Minter pourrait alors tirer parti des capacités des smart contracts d'OP_CAT, les détails de mise en œuvre n'ayant pas encore été rendus publics.

État de la transaction (V2)

L'état est stocké dans OP_RETURN et les smart contracts. OP_RETURN stocke le Hash de l'état de sortie actuel, le contrat stocke le nombre restant de Mint. La quantité de mint pour le nouveau Minter est la moitié de la quantité restante à mint.

Contrairement aux BRC20 ou aux inscriptions, le CAT20 n'existe pas sur l'UTXO de l'adresse utilisateur.

transfert et destruction

Lors du transfert, les quantités d'entrée et de sortie du même token doivent rester cohérentes. La destruction ne nécessite que de transférer le token à une adresse ordinaire.

Résumé

La conception de CAT20 permet aux utilisateurs de construire des transactions de manière flexible, mais nécessite également une vérification rigoureuse des contrats. Cette conception facilite la consultation de la situation de détention des tokens et de l'avancement du minting, mais peut également présenter un risque de lacunes dans la logique de vérification.