Cet article est uniquement destiné au partage technique et ne constitue aucun conseil en investissement.

BTC aura-t-il également son propre contrat intelligent ?

Dans le récent écosystème Bitcoin, Fractal BTC a finalement lancé le réseau principal en septembre après avoir parcouru plusieurs réseaux de test. Une caractéristique majeure de Fractal est la possibilité d'avoir des « contrats intelligents », et presque en même temps que le lancement du réseau principal, un nouveau protocole de jeton CAT 20 a été lancé. Quelle est l'ingéniosité technique du CAT 20 ? Que pouvons-nous apprendre ?

Bitcoin fractal

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

Fractal Bitcoin, également connu sous le nom de Fractal Bitcoin, est un réseau de « deuxième couche » entièrement compatible avec BTC. Par rapport au BTC, son temps de confirmation de bloc est plus rapide, ne prenant qu’une minute. Son principe de base est simplement, comme son nom l'indique, de faire plusieurs copies du réseau BTC. Chaque chaîne traitera les transactions. Plus il y aura de nœuds capables de traiter les transactions, plus cela sera naturellement rapide. Cependant, les détails spécifiques, tels que la manière dont les différentes chaînes communiquent, ne sont pas encore clairs et il n'existe pas de documents techniques officiels correspondants pour référence.

Si seule une transaction en chaîne de deuxième niveau est plus rapide, il ne semble y avoir aucun enthousiasme. Cependant, l'activation d'OP_CAT dans Fractal, qui a été abandonnée par BTC il y a longtemps pour des raisons de sécurité, a porté les capacités de Fractal Bitcoin à un niveau supérieur. Certaines personnes disent qu'OP_CAT peut permettre à BTC d'avoir des capacités de contrat intelligent dans ce domaine. façon, il y a de la place pour l'imagination.

Maintenant, quelqu'un a implémenté un protocole de type ERC 20 sur Fractal Bitcoin.

Concernant la raison pour laquelle OP_CAT a été abandonné et pourquoi il peut être utilisé sur Fractal Bitcoin, nous pourrons en parler plus tard. Nous nous concentrerons ici sur CAT 20.

Protocole CAT Veuillez vous référer au livre blanc pour le contenu suivant : Introduction | Protocole CAT (https://catprotocol.org/)

Et le référentiel github : GitHub - CATProtocol/cat-token-box : Un monorepo pour les packages implémentant le protocole CAT (https://github.com/CATProtocol/cat-token-box)

Avec la prise en charge sous-jacente d'OP_CAT, un protocole correspondant, CAT Protocol, sera bientôt disponible. Actuellement, un protocole actuellement en cours d'exécution est le protocole CAT 20, et un panneau correspondant a été ajouté sur Unisat : https://explorer.unisat.io/fractal-mainnet/cat20.

Tout le monde devrait pouvoir réagir en voyant le nom de CAT 20. Il devrait ressembler davantage à ERC 20. Par rapport au protocole ERC 20 mature, il est très pratique pour tout le monde de déployer un Token. Comment CAT 20 implémente-t-il un cycle de vie similaire à ERC 20 ?

Déployer

Avant le déploiement, les utilisateurs doivent spécifier l'adresse de leur portefeuille et les informations de base sur le jeton. Les informations de base sur le jeton sont similaires à celles de l'ERC 20 :

Il y aura quelques différences. CAT 20 peut définir des limites de pré-extraction et de quantité pour chaque menthe. Bien entendu, l’ERC 20 peut également atteindre ces capacités grâce à des capacités contractuelles.

Lors de la phase de déploiement, deux transactions seront initiées, qui peuvent être considérées comme deux phases : « commit » et « reveal ». Citant le schéma officiel, les étapes de déploiement sont les suivantes :

Lors de l'étape « commit », les informations de base du jeton seront écrites dans le script de sortie de la transaction, telles que le nom, le symbole, etc. du jeton. Le hashId de la transaction initiée dans la phase « commit » sera utilisé comme symbole du token pour distinguer les autres tokens.

Vous pouvez voir que l'utxo de cette transaction " bc 1 pucq...ashx " correspond au commit. Ensuite, il reste deux transactions pointant vers " bc 1 pszp...rehc 4 ". La première est utilisée pour payer les frais de gaz pour l'étape de " révélation " suivante, et l'autre est la monnaie.

Dans l'étape "révéler", vous pouvez voir qu'il existe deux entrées utxo, correspondant aux deux premières sorties de l'étape de validation précédente. Cette transaction produira d'abord un OP_RETURN, dans lequel le hachage de l'état initial du CAT 20 sera enregistré. Ensuite, un Minter sera généré, qui jouera un rôle important dans le processus Mint ultérieur et sera utilisé pour maintenir les changements d'état du processus Mint.

En regardant l'ensemble du processus de déploiement, "commit" et "reveal" suivent les deux étapes de soumission et de révélation couramment utilisées sur la blockchain. C'est une manière relativement courante de déployer des projets. Certaines données du projet sont uniquement en "révélation". les étapes seront révélées.

Comme

Lorsque nous examinons pour la première fois Mint Token, la transaction ressemble à ceci.

Comme vous pouvez le voir sur l’image ci-dessus, le processus de Mint présente les caractéristiques suivantes.

  • L'entrée de mint est un monnayeur, qui est initialement généré lors du déploiement.

  • Chaque fois que Mint a un et un seul monnayeur en entrée, et un nombre quelconque de monnayeurs en sortie (un peu problématique)

  • Chaque menthe n'a qu'un seul jeton (un peu problématique)

  • L'ordre de sortie est obligatoire, le monnayeur doit être suivi du jeton

Connaissant le processus Mint, nous pouvons en fait découvrir des situations particulières qui rendront l'ensemble du processus Mint intéressant.

Par exemple, monnayeur, en tant que résultat d'une transaction monétaire, peut être 1, multiple ou même 0. Si Mint est réglé sur 1 à chaque fois, alors le nombre de monnayeurs pouvant être utilisés dans l'ensemble du réseau restera inchangé (1), ce qui rendra Mint encombré, et tout le monde doit saisir ce monnayeur afin d'éviter cela. Dans ce cas, il est nécessaire de fixer à chaque fois le nombre de monnayeurs émis à un niveau supérieur à 1, afin qu'après la frappe, de plus en plus de monnayeurs puissent être utilisés.

Cependant, chaque production supplémentaire de monnayeur signifie que vous devez payer un utxo supplémentaire. Pour des raisons économiques, davantage de personnes seront prêtes à mettre mon monnaie à 0, ce qui entraînera inévitablement une déflation du monnaie, ce qui obligera certaines personnes à venir faire un don et à payer. le monnayeur supplémentaire volontairement.

Dans la version V2, la valeur par défaut est de générer deux monteurs, et le statut des deux monteurs sera aussi similaire que possible.

Structuration des transactions

Certains amis ont peut-être découvert un problème : pourquoi l'utxo du monnayeur peut-il être utilisé pour construire des transactions ? Pour comprendre ce problème, il faut analyser le code source du « contrat ».

1. révéler utxo

Tout d’abord, nous analysons la transaction pendant le processus de révélation et nous constatons qu’elle utilise la validation de sortie de la transaction précédente comme entrée. Pourquoi pouvons-nous prendre un utxo qui n'est pas notre adresse et construire l'entrée de la transaction ?

Selon le bon sens, une clé privée correspond à une clé publique, et la clé publique dérive l'adresse. Lors de la vérification de la validité d'un utxo d'entrée, il est généralement déterminé en comparant si la signature est cohérente avec la transaction d'origine après avoir été déchiffrée avec la clé publique. Cette partie de la logique est écrite en script Bitcoin. Nous pouvons donc intelligemment réécrire la logique du script. Les paires de clés publique et privée écrites dans le script appartiennent à notre propre adresse, afin de pouvoir contrôler l'utxo de deux adresses différentes.

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

Il y a un autre problème ici, c'est-à-dire qu'une clé privée correspond à une clé publique, alors pourquoi l'adresse de validation générée est-elle différente de notre adresse ? Ici vous pouvez le voir à partir du code source

Autrement dit, notre clé privée va ajuster la clé publique en fonction d'un ISSUE_PUBKEY, qui est aussi une caractéristique de l'adresse P 2 TR.

2、minter uxo

Pendant le processus de révélation, nous utilisons différents utxo comme entrée, mais en fait la clé de cryptage est la même, qui est la clé privée du déployeur. Mais au stade intermédiaire, tout le monde peut utiliser ces utxo comme entrée, comment cela se fait-il ?

Je suppose que cette partie est la capacité d'OP_CAT mentionnée précédemment, c'est-à-dire la capacité des contrats intelligents. Chaque monteur est un contrat intelligent. Cependant, le code source de cette partie n’a pas encore été rendu public et nous ne connaissons pas encore l’implémentation spécifique.

Statut de la transaction (V2)

En fait, l'état est également préservé. Cet état existe à deux endroits : l'un se trouve dans l'OP_RETURN de la sortie de la transaction et l'autre est stocké dans le contrat intelligent, qui est le Minter et le Token mentionnés ci-dessus.

Ce qui est stocké dans OP_RETURN est le hachage de l'état de sortie de la transaction actuelle, et les temps de menthe restants du jeton sont stockés dans le contrat. Après chaque Mint, le nombre de Mints du Minter nouvellement généré sera égal au nombre de Mints restant divisé par deux. Représentez par un schéma :

À la fin du jeu, le nombre restant de tous les Minter est 0.

Pour en revenir à l'image originale, en plus du fait que Minter soit un contrat intelligent, le jeton généré est également un contrat intelligent, qui est CAT 20. CAT 20 a deux états de base : la quantité et l'adresse du propriétaire du jeton. Vous pouvez constater que contrairement au précédent BRC 20 ou inscription, votre CAT 20 n'est pas sur l'UTXO de votre adresse.

Transfert

Lors du transfert, le nombre de jetons d'entrée et de sortie dans la transaction doit être cohérent. Bien entendu, il peut y avoir plusieurs jetons différents dans la même transaction, à condition que les numéros d'entrée et de sortie des différents jetons soient cohérents.

Brûler

Si vous souhaitez graver le Token, il vous suffit de transférer le Token à une adresse normale.

Résumer

On peut voir que toutes les opérations sont construites par les utilisateurs eux-mêmes, ce qui est très flexible, donc beaucoup de logique de vérification doit être effectuée dans la partie contractuelle. Certaines des vulnérabilités exposées jusqu’à présent sont également dues à une négligence dans la logique de vérification.

Une telle conception peut présenter certains avantages :

  • Si vous souhaitez connaître le statut de détention de tous les jetons, il vous suffit de vérifier l'utxo du jeton et il n'est pas nécessaire de continuer la recherche.

  • Si vous souhaitez vérifier la situation actuelle de Mint, vous pouvez rechercher des transactions avec cat dans OP_RETURN.

ZAN est là pour avoir de l'eau sans aucun seuil !

Astuce : vous pouvez recevoir un jeton testnet gratuit de 0,01 ETH toutes les 24 heures pour vous aider à expérimenter et tester des projets Web3 dans l'écosystème Ethereum. Cliquez pour le recevoir maintenant : https://zan.top/faucet?chInfo=ch_WZ.

D'autres chaînes publiques seront bientôt prises en charge ~

Cet article est écrit par Yeezo (compte X @GaoYeezo 75065) de l'équipe ZAN (compte X @zan_team)

#BTC