CAT20：Fractal BTC上的Jetonprotocole

Ce document est uniquement destiné à partager des informations techniques et ne constitue en aucun cas un conseil en investissement.

BTC aura-t-il aussi son propre contrat intelligent ?

Récemment, dans l'écosystème BTC, après avoir subi plusieurs Testnet, Fractal BTC est enfin en ligne sur Mainnet en septembre. L'une des grandes caractéristiques de Fractal est sa capacité à exécuter des « smart contracts », et presque simultanément avec le lancement de Mainnet, un nouveau protocole Jeton 20 CAT a été mis en ligne. Quels sont les ingénieuses conceptions techniques de CAT 20 ? Que pouvons-nous en apprendre ?

Bitcoin fractal

Avant de comprendre CAT 20, nous devons d'abord comprendre Fractal Bitcoin. Leur relation est similaire à celle entre ERC 20 et ETH. Le protocole CAT 20 est déployé sur Fractal Bitcoin.

Fractal Bitcoin, also known as fractal BTC, is a "second layer" network that is fully compatible with BTC. Compared to BTC, its Bloc confirmation time is faster, taking only 1 minute. The basic principle is simple, just as its name suggests, it replicates the BTC network several times, and each chain processes transactions. With more Nœud capable of processing transactions, the speed naturally increases. However, specific details, such as how different chains communicate, are currently not very clear, and there are no corresponding technical documents available from the official source.

Si une transaction de couche 2 est simplement plus rapide, elle ne semble pas excitante. Cependant, l'utilisation de l'opération OP_CAT dans Fractal, qui a été abandonnée depuis longtemps pour des raisons de sécurité dans BTC, élève les capacités de Fractal Bitcoin d'un cran. Certains disent que OP_CAT peut donner à BTC la capacité de Smart Contracts, ce qui ouvre encore plus de possibilités d'imagination.

Maintenant, quelqu'un a mis en place un protocole similaire à ERC 20 sur Fractal Bitcoin.

À propos de OP_CAT, pourquoi a-t-il été abandonné et pourquoi peut-il être utilisé sur Fractal Bitcoin maintenant, nous pouvons en parler en détail plus tard, ici nous suivons CAT 20.

Protocole CAT Les informations suivantes sont basées sur le Livre blanc: Introduction | Protocole CAT ()

Et le dépôt GitHub : GitHub - CATProtocol/cat-token-box : Un monorepo pour les packages implémentant le protocole CAT ()

Avec le support sous-jacent d'OP_CAT, un protocole correspondant, CAT Protocol, a rapidement été mis en place. Actuellement, un protocole qui est déjà en cours d'exécution est le protocole CAT 20, et un panneau correspondant a également été ajouté sur Unisat :

En voyant le nom CAT 20, vous devriez aussi pouvoir deviner qu'il est probablement similaire à ERC 20. Par rapport au protocole ERC 20 mature, le déploiement d'un jeton est déjà très pratique. Comment CAT 20 parvient-il à réaliser un cycle de vie similaire à ERC 20 ?

Déployer

Avant le déploiement, l'utilisateur doit spécifier son Adresse de Portefeuille ainsi que les informations de base du Jeton, lesquelles sont similaires à celles de ERC 20.

Il peut y avoir quelques différences. CAT 20 permet de définir des limites pour la pré-minage et la quantité maximale de Mint à chaque fois. Bien sûr, ERC 20 peut également réaliser ces fonctions par le biais de la capacité du contrat.

Pendant la phase de déploiement, deux transactions seront initiées, que l'on peut considérer comme deux étapes : "commit" et "reveal". En citant le graphique officiel, les étapes de déploiement sont les suivantes :

Lors de l'étape "commit", les informations de base du Jeton, telles que le nom et le symbole du Jeton, sont écrites dans le script de sortie de la transaction. L'identifiant de hachage de la transaction initiée lors de l'étape "commit" servira d'identifiant pour ce Jeton, le distinguant ainsi des autres Jetons.

Vous pouvez voir que cette transaction 'bc 1 pucq...ashx' correspond à l'utxo commit. Ensuite, les deux autres transactions pointent vers la transaction 'bc 1 pszp...rehc 4', la première étant utilisée pour payer les frais de gaz de la phase 'reveal' ci-dessous, tandis que l'autre est un remboursement.

À la phase de « révélation », vous pouvez voir qu'il y a deux entrées UTXO correspondant aux deux sorties de la phase précédente de « commit ». Cette transaction commencera par une sortie OP_RETURN, où le Hash de l'état initial de CAT 20 sera conservé. Ensuite, il y aura une autre sortie Minter, qui jouera un rôle crucial dans le processus ultérieur de Mint, en maintenant les changements d'état du processus de Mint.

En regardant en arrière le processus complet de déploiement, les étapes de "commit" et de "reveal" suivent les deux étapes de soumission et de révélation couramment utilisées dans le Blocoff-chain, c'est une manière assez courante de déployer un projet, certaines données du projet ne seront révélées qu'à l'étape de "reveal".

Mint

Lorsque nous examinons pour la première fois le Mint Token, voici à quoi ressemblent les transactions.

Dans le schéma ci-dessus, on peut observer les caractéristiques suivantes du processus de Mint.

• L'entrée de mint est un minter, généré lors du déploiement initial.
• Chaque mint a un et un seul minter en entrée, avec un nombre quelconque de minters en sortie (un peu problématique).
• Chaque fois que vous créez un token, il n'y a qu'un seul token (un peu de problème)
• L'ordre de sortie est requis, 'minter' doit être suivi de 'TOKEN'.

Après avoir compris le processus de Mint, en fait, nous pouvons découvrir certaines situations spéciales qui rendent tout le processus de Mint intéressant.

Par exemple, en tant que sortie de transaction mint, minter peut être 1, plusieurs ou même 0. Si à chaque fois que vous créez un nouveau jeton, vous définissez le minter comme 1, le nombre de minter disponibles dans l'ensemble du réseau restera constant (1), rendant le processus de création de jetons encombré car tout le monde devra se battre pour ce minter. Pour éviter cette situation, il est nécessaire de définir le nombre de minter en sortie à plus de 1 à chaque fois, de sorte qu'après chaque transaction mint, de plus en plus de minter seront disponibles pour une utilisation commune.

Cependant, chaque sortie supplémentaire d'un minter signifie que vous devez payer un utxo supplémentaire. Pour des raisons économiques, plus de personnes seront prêtes à définir le minter comme 0, ce qui rendra inévitablement le minter devenu déflationniste, ce qui nécessitera que certaines personnes fassent des dons et paient volontairement le minter supplémentaire.

Dans la version V2, par défaut, deux Minter sont générés et leur état est aussi similaire que possible.

Construction des transactions

Il se peut que certains camarades aient remarqué un problème : pourquoi peut-on utiliser la construction de transactions avec les UTXO du minter ? Pour comprendre cette question, il faut analyser le code source du "contrat".

1, révéler utxo

Tout d'abord, nous analysons les transactions dans le processus de révélation et nous constatons qu'il utilise le commit de sortie de la transaction précédente comme entrée. Pourquoi peut-il utiliser une sortie utxo qui n'est pas notre Adresse comme entrée pour construire une transaction ?

Selon la logique habituelle, une Clé privée correspond à une Clé publique, et une Clé publique dérive une Adresse. Lors de la validation de l'utxo d'une entrée pour déterminer sa validité, on compare généralement si le déchiffrement avec la Clé publique utilisée pour signer est conforme à la transaction d'origine. Cette logique est écrite dans le script BTC. Par conséquent, nous pouvons astucieusement modifier la logique du script en écrivant que la paire de Clés privée et publique dans le script est la nôtre, ce qui nous permet de contrôler les utxo de deux Adresses différentes.

En regardant le code source, nous pouvons comprendre ce qui s'est passé :

Il y a encore une question ici, c'est qu'une Clé privée correspond à une Clé publique, alors pourquoi l'Adresse commit générée est-elle différente de notre Adresse ? On peut voir cela dans le code source.

En d’autres termes, notre Clé privée ajuste la Clé publique en fonction d’un ISSUE_PUBKEY, qui est également une caractéristique de l’Adresse P 2 TR.

2, minter utxo

Au cours du processus de révélation, nous utilisons des UTXO différents comme entrée, mais en réalité la clé secrète de chiffrement est la même, c'est-à-dire la clé privée du déploieur. Mais lors de la phase de minage, comment tout le monde peut-il utiliser ces UTXO comme entrée?

Je suppose que cette partie est la capacité OP_CAT mentionnée précédemment, c’est-à-dire la capacité de Smart Contract, et chaque minter est un Smart Contract. Cependant, à l’heure actuelle, le code source de cette partie n’a pas été divulgué, et je ne sais pas quelle sera l’implémentation spécifique pour le moment.

État de la transaction (V2)

Dans Minter, l'état est également conservé. Cet état se trouve à deux endroits : dans la sortie de transaction OP_RETURN et stocké dans les smart contracts, c'est-à-dire dans le Minter et le TOKEN mentionnés ci-dessus.

Le Hash stocké dans OP_RETURN est l'état actuel de la sortie de la transaction, et le contrat stockera le nombre de fois restant pour le Jeton à Minter. Après chaque Mint, la quantité de mint du nouveau Minter sera égale au nombre restant de mint divisé par deux. Représentation graphique :

Une fois terminé, le nombre restant de Minter est de 0.

Revenons à la première image, en plus de Minter étant un Smart Contract, le Token généré est également un Smart Contract, c'est-à-dire CAT 20. CAT 20 a deux états fondamentaux : la quantité et le propriétaire du Token Adresse. Comme vous pouvez le voir, contrairement à BRC 20 ou aux inscriptions précédentes, votre CAT 20 n'est pas sur votre UTXO Adresse.

Transfert

Lors du transfert, les quantités de jetons dans les entrées et les sorties de la transaction doivent être cohérentes. Bien sûr, une même transaction peut contenir plusieurs jetons différents, tant que les quantités d'entrées et de sorties des différents jetons sont cohérentes.

Brûler

Si vous voulez brûler le TOKEN, il vous suffit de transférer le TOKEN sur une Adresse normale.

Résumé

Il peut être vu que toutes les opérations sont construites par l'utilisateur lui-même, avec une grande flexibilité, donc il y a beaucoup de logique de vérification à faire dans la partie contrat. Certaines vulnérabilités qui ont été découvertes sont également dues à une négligence dans la logique de vérification.

Ce type de conception peut avoir certains avantages:

• Si vous souhaitez rechercher toutes les informations de détention des jetons, il vous suffit de vérifier les utxo des jetons, vous n'avez pas besoin de continuer à chercher plus loin.
• Si vous souhaitez vérifier l'état actuel de la mint, vous pouvez rechercher les transactions avec des données OP_RETURN contenant le mot "cat".

ZAN 01928374656574839201

Astuce: Vous pouvez recevoir une fois toutes les 24 heures 0.01 ETH en jetons de testnet gratuits, pour soutenir votre expérience et tester les projets Web3 sur l'écosystème Ethereum. Cliquez ici pour réclamer immédiatement : 01928374656574839201

Plus de chaînes publiques seront bientôt prises en charge~

Cet article a été rédigé par Yeezo (compte X @GaoYeezo 75065) de ZAN Team (compte X @zan_team).