Ordinals a été lancé par le développeur Casey Rodarmor le 20 janvier 2023 sur le réseau principal de Bitcoin en tant que protocole de commande pour les "Satoshis". "Composé de 100 millions de satoshis (1 btc = 10^8 sat), le protocole Ordinals confère à chaque satoshi une identité unique.
Les Inscriptions Ordinales sont des jetons non fongibles (NFT) construits sur le protocole Ordinals et contiennent des données telles que des images, du texte et des vidéos.
Par rapport à Ethereum NFT, nous pouvons simplement penser que le protocole Ordinals met en œuvre le tokenID et que l'inscription met en œuvre les métadonnées.
TokenID fournit un identifiant unique pour chaque NFT, permettant aux utilisateurs de distinguer les tokens les uns des autres. Le TokenID est ce qui rend les NFT vraiment uniques.
Ethereum dispose d'une bonne programmabilité, ce qui facilite la mise en œuvre de TokenID. Cependant, dans le cas de Bitcoin, des implémentations similaires nécessitent généralement l'utilisation de réseaux de seconde couche. Des plateformes telles que Counterparty et Stacks ont déjà mis en œuvre des NFT basés sur le bitcoin, mais l'inscription d'Ordinals présente des différences fondamentales par rapport aux autres architectures NFT du bitcoin.
Le protocole Ordinals utilise le modèle de transaction UTXO de Bitcoin. L'UTXO s'apparente à un système de caisse, par opposition au modèle traditionnel basé sur le solde des comptes.
Dans la blockchain Bitcoin, tous les soldes sont stockés dans une liste appelée Unspent Transaction Outputs (UTXO). Chaque UTXO contient une certaine quantité de bitcoins, ainsi que des informations sur son propriétaire et sur la possibilité de les dépenser. Vous pouvez l'assimiler à un chèque en espèces portant le nom du propriétaire, qui peut être transféré à quelqu'un d'autre par la signature du propriétaire. Pour une adresse donnée, la somme de tous ses montants UTXO représente le solde du portefeuille de cette adresse. En parcourant tous les UTXO, nous pouvons obtenir le solde actuel de chaque adresse. En additionnant tous les montants UTXO, on obtient la circulation totale du bitcoin.
Pour mieux comprendre le modèle de paiement du réseau Bitcoin, prenons l'exemple d'un A qui envoie n bitcoins à un B. Le diagramme ci-dessous illustre le processus d'envoi de 3 bitcoins par un A à un B.
Pour l'utilisateur A, il faut d'abord déterminer l'ensemble des UTXO qu'il possède, c'est-à-dire tous les bitcoins que l'utilisateur A peut contrôler ;
A sélectionne un ou plusieurs UTXO de cet ensemble comme entrée de la transaction. La somme des montants de ces intrants est m (2+0,8+0,5=3,3 BTC), qui est supérieur au montant à payer n (3 BTC) ;
L'utilisateur A définit deux sorties pour la transaction, une sortie est payée à l'adresse de B, le montant est n (3 BTC), et l'autre sortie est payée à l'adresse de changement de A, le montant est m-n-fee (3.3-3- 0.001=0.299). BTC). Le portefeuille d'un utilisateur se compose généralement de plusieurs adresses. En général, chaque adresse n'est utilisée qu'une seule fois et les changements sont renvoyés à une nouvelle adresse par défaut ;
Une fois que le mineur a préparé la transaction et l'a envoyée à la chaîne pour confirmation, B peut recevoir les informations relatives à la transaction. Étant donné que la taille des blocs a une limite supérieure (environ 1 Mo), les mineurs donneront la priorité aux transactions dont le taux est élevé (fee_rate=fee/size) afin d'obtenir en retour la rémunération la plus élevée.
Selon le protocole Ordinals, le nombre de "Satoshi" est basé sur l'ordre dans lequel ils sont extraits, et comme chaque BTC "Satoshi" est généré par des récompenses minières, son numéro de série peut être déterminé grâce à la traçabilité.
Supposons que l'utilisateur A obtienne le 100e-110e Satoshi par le biais de l'exploitation minière (10 Satoshis sont stockés dans le même UTXO avec l'ID adc123). Lorsque l'utilisateur A veut payer 5 satoshis à l'utilisateur B, il choisit d'utiliser l'ID abc123 comme entrée de la transaction, dont 5 satoshis sont donnés à l'utilisateur B, et 5 satoshis sont retournés à l'utilisateur A comme monnaie. Ces deux copies de 5 "Satoshi" forment un tout et sont stockées dans deux UTXO avec les ID abc456 et abc789 respectivement. L'identifiant UTXO ci-dessus et le nombre de "Satoshi" ne sont donnés qu'à titre d'exemple. Dans la réalité, le nombre minimum de "Satoshi" envoyés est limité à 546 et l'identifiant UTXO n'est pas exprimé sous cette forme.
Dans la transaction ci-dessus, le chemin de circulation des 10 satoshis de l'utilisateur A est le suivant :
L'exploitation minière produit 10 "Satoshi", numérotés [100, 110]. Indique que le 100e à 109e "Satoshi" est stocké dans l'UTXO avec l'ID abc123, et que son propriétaire est l'utilisateur A.
Lorsque A transfère de l'argent, 10 "satoshis" sont divisés en deux parties, chacune avec 5 "satoshis". Le principe est que le nombre de "Satoshi" à commander est déterminé en fonction de leur indice dans le résultat de la transaction. En supposant que l'ordre de sortie soit d'abord l'utilisateur A, puis l'utilisateur B, les numéros de série des 5 "satoshis" restants de l'utilisateur A sont [100, 105), qui sont stockés dans l'UTXO avec l'identifiant abc456, et les 5 "satoshis" de l'utilisateur B ont le numéro de séquence [105, 110) et sont stockés dans l'UTXO avec l'identifiant abc789.
Les métadonnées des inscriptions ordinales ne sont pas stockées dans un endroit spécifique. Au lieu de cela, ces métadonnées sont intégrées dans les données témoins de la transaction (données témoins, champ témoin), d'où le nom d'"inscription", car ces données sont "gravées" comme une inscription sur des parties spécifiques de la transaction Bitcoin. et ces données sont rattachées à des "Satoshi" spécifiques. Ce processus d'inscription est mis en œuvre par Segregated Witness (SegWit) et Taproot, qui comprend deux étapes : commit et reveal, et peut inscrire n'importe quelle forme de contenu (texte, image ou vidéo) sur le "satoshi" désigné.
SegWit est une mise à jour de 2017 qui a donné lieu à une fourchette souple de la blockchain Bitcoin. La mise à jour sépare effectivement les transactions Bitcoin en deux parties en ajoutant une section "données témoins" qui peut prendre en charge des données arbitraires.
Le témoin séparé sépare les données de la transaction et du témoin (signature) en deux parties distinctes et permet de stocker des données arbitraires dans la partie témoin.
Techniquement, la mise en œuvre de Segregated Witness signifie que les transactions n'ont plus besoin d'inclure des données de témoin (et n'occuperont pas les 1 Mo d'espace que Bitcoin avait initialement alloué aux blocs). Au lieu de cela, à la fin d'un bloc, un espace séparé supplémentaire est créé pour les données témoins. Il prend en charge les transferts de données arbitraires et dispose d'un "poids de bloc" actualisé qui permet de maintenir intelligemment de grandes quantités de données dans les limites de la taille des blocs de Bitcoin, afin d'éviter un "hard fork".
Mis en œuvre en novembre 2021, Taproot est une mise à jour à multiples facettes conçue pour améliorer la confidentialité, l'évolutivité et la sécurité de Bitcoin. Taproot crée un système qui facilite le stockage de données témoins arbitraires et assouplit les limites de la quantité de données arbitraires pouvant être placées dans une transaction Bitcoin. L'objectif initial de cette mise à jour est d'améliorer les contrats intelligents basés sur Bitcoin, tels que les contrats à durée déterminée, qui sont généralement exprimés en données de témoin.
Les ordinaux stockent les métadonnées dans un script spend dans le chemin d'accès au script Taproot.
Tout d'abord, grâce à la manière dont les scripts Taproot sont stockés, nous pouvons stocker le contenu des inscriptions dans les scripts de dépenses du chemin de script Taproot, qui n'ont presque aucune restriction sur le contenu, tout en recevant des remises sur les données des témoins, ce qui rend le stockage du contenu des inscriptions relativement économique. Comme la consommation des scripts Taproot ne peut se faire qu'à partir de sorties Taproot déjà existantes, les Inscriptions sont frappées en utilisant un processus de validation/révélation en deux étapes. Tout d'abord, dans la transaction de validation, une sortie Taproot est créée qui promet un script contenant le contenu de l'inscription. Ensuite, dans la transaction de révélation, une transaction est initiée en prenant comme entrée l'UTXO correspondant à cette inscription. À cette occasion, le contenu de l'inscription correspondante a été rendu public sur l'ensemble de l'internet.
Cette approche réduit considérablement la consommation de ressources. Si vous n'utilisez pas le script Taproot, les informations sur les témoins sont stockées dans la sortie de la transaction. Ainsi, tant que cette sortie n'est pas consommée, l'information témoin sera toujours stockée dans l'ensemble UTXO. En revanche, si P2TR est utilisé, les informations relatives au témoin n'apparaîtront pas dans la transaction générée pendant la phase de validation, et ne seront donc pas écrites dans l'ensemble UTXO. Ce n'est que lorsque cette UTXO est consommée que l'information sur le témoin apparaît dans l'entrée de la transaction pendant la phase de révélation. P2TR permet d'écrire des métadonnées dans la blockchain Bitcoin, mais elles n'apparaissent jamais dans l'ensemble UTXO. Étant donné que la maintenance/modification de l'ensemble des UTXO nécessite davantage de ressources, cette approche permet d'économiser beaucoup de ressources.
Bien que le nom de BRC-20 soit très similaire à celui de l'ERC-20 d'Ethereum, les différences techniques entre les deux sont en fait significatives. L'état de détention des jetons ERC-20 est sauvegardé sur la chaîne et le consensus du réseau peut être obtenu sur la chaîne. BRC-20 Juste une inscription spéciale du protocole Ordinals, créée par l'utilisateur de Twitter @domodata le 8 mars 2023, qui utilise des inscriptions ordinales de données JSON pour déployer des contrats de jetons, battre monnaie et transférer des jetons. Le json déployé est le suivant :
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Les opérations correspondantes sont la frappe et le transfert, et les deux formats sont pratiquement identiques. Lorsque op est Transfer, le destinataire du transfert de l'inscription est le destinataire du "Satoshi" correspondant à l'inscription. Par conséquent, le transfert de BRC-20 doit s'accompagner du transfert de la propriété des bitcoins et ne pas être simplement consommé en tant que frais de gestion.
Le BRC-20 met en œuvre un mécanisme de "premier arrivé, premier servi". Les déploiements répétés et l'utilisation excessive de la menthe ne sont pas valables. L'organisation centralisée déduira le solde actuel que l'utilisateur devrait avoir sur la base de chaque OP enregistré sur la chaîne, et jugera de la validité de la transaction.
Dans ce processus, les inscriptions sont "attachées" au "Satoshi" transactionnel. Les mineurs de bitcoins ne traiteront pas ces inscriptions. Du point de vue de la chaîne, ils ne sont pas différents des autres "Satoshis". Ils sont tous considérés comme des "Satoshis" ordinaires. Le "Cong" est transféré.
Pour le protocole BRC-20, l'inscription est considérée comme un grand livre qui enregistre le déploiement, la frappe et le transfert des jetons BRC-20. Étant donné que les contrats intelligents ne peuvent pas être exécutés sur Bitcoin, les jetons BRC-20 ne peuvent pas demander des informations pertinentes sur le jeton actuel en exécutant des contrats intelligents. Par conséquent, BRC-20 utilise des requêtes hors chaîne, c'est-à-dire qu'il utilise un serveur centralisé pour récupérer les blocs Bitcoin, enregistrer les opérations de déploiement, de frappe et de transfert de tous les jetons BRC-20 afin de demander le solde final des jetons BRC-20 de chaque utilisateur.
En d'autres termes, le grand livre BRC-20 est décentralisé et enregistré sur la chaîne Bitcoin, mais le processus de règlement est centralisé. Il existe actuellement deux sites web, brc-20.io et unisat.io, qui prennent en charge les requêtes relatives aux jetons BRC-20.
La centralisation du processus de règlement peut entraîner des résultats différents d'une plateforme à l'autre lorsqu'on demande le solde d'un compte donné. Bien que toutes les opérations soient enregistrées sur la chaîne, il incombe au client de les vérifier. Si ces fournisseurs de services centralisés ne divulguent pas leurs règles de vérification, il n'y a en fait aucune garantie pour l'ensemble de l'écosystème BRC-20.
En fait, dans la soirée du 23 avril, UniSat a lancé la plateforme commerciale BRC-20, mais en raison de vulnérabilités dans la bibliothèque de code, elle a subi un grand nombre d'attaques de double dépense. L'adresse bc1pwturekq4w455l64ttze8j7mnhgaupsn99ggd0ds23js924e6ms9fxyht a initialement frappé les Ordinals NFT transférés et a tenté de transférer 5 000 ORDI et 35 000 ORDI à sa propre adresse à partir de rien, et a essayé de vendre les ORDI frappés à partir de rien à d'autres utilisateurs. Unisat a ensuite suspendu l'accès au site web et mené une enquête qui a finalement permis de découvrir que 70 transactions avaient été affectées.
Si Unisat n'avait pas récupéré l'erreur cette nuit-là, les dommages causés par la double attaque ont été estimés à plus d'un million de dollars. La question la plus importante à résoudre au cours du développement du BRC-20 est de savoir comment garantir l'absence d'erreurs lors de la récupération et de la vérification du serveur centralisé.
L'essence de l'inscription ordinale est la suivante : sur le réseau Bitcoin avec l'aide d'un Taproot Le script construit une couche comptable simple pour compter et enregistrer les actifs et les données.
Comme il s'agit uniquement de comptabilité, cela signifie qu'il n'y aura pas d'exécution de script et de processus de vérification similaires aux contrats intelligents, et qu'il doit être fortement dépendant d'une gestion centralisée hors chaîne et de la communication des résultats.
Par conséquent, à l'exception de BRC-20, toutes les inscriptions aux Ordinals doivent être basées sur des services hors ligne en dehors du réseau Bitcoin pour la maintenance de l'état tant qu'elles impliquent un transfert d'état (tel que des transactions). Si le service d'état sous-jacent est indisponible ou défectueux, cela peut entraîner des pertes d'actifs, car le réseau Bitcoin ne peut pas empêcher que des inscriptions non valides soient téléchargées sur la chaîne. La plateforme centralisée doit décider de la validité de l'inscription, qui sera valable sur la plateforme.
Cette méthode centralisée de négociation et de fixation des prix donne à la plateforme centralisée une possibilité importante de comportement malveillant. En outre, la combinaison du paradoxe logique de l'inscription "premier arrivé, premier servi" et du mécanisme de hiérarchisation des emballages par les mineurs en fonction des droits d'exploitation minière permet aux mineurs et aux robots de frappe de frapper un grand nombre d'inscriptions populaires avant les autres, ce qui donne lieu à un processus de frappe inéquitable.
Cependant, il est difficile de prévoir et d'évaluer le développement de nouvelles choses. L'introduction de l'inscription ordinale a sans aucun doute suscité un débat au sein de la communauté Bitcoin sur le rôle fondamental et l'essence de Bitcoin. Cette discussion pourrait déboucher sur la création d'une fourche du bitcoin, axée sur la sécurité et la programmabilité. Il semble que la boîte de Pandore soit en train de s'ouvrir.
Ordinals a été lancé par le développeur Casey Rodarmor le 20 janvier 2023 sur le réseau principal de Bitcoin en tant que protocole de commande pour les "Satoshis". "Composé de 100 millions de satoshis (1 btc = 10^8 sat), le protocole Ordinals confère à chaque satoshi une identité unique.
Les Inscriptions Ordinales sont des jetons non fongibles (NFT) construits sur le protocole Ordinals et contiennent des données telles que des images, du texte et des vidéos.
Par rapport à Ethereum NFT, nous pouvons simplement penser que le protocole Ordinals met en œuvre le tokenID et que l'inscription met en œuvre les métadonnées.
TokenID fournit un identifiant unique pour chaque NFT, permettant aux utilisateurs de distinguer les tokens les uns des autres. Le TokenID est ce qui rend les NFT vraiment uniques.
Ethereum dispose d'une bonne programmabilité, ce qui facilite la mise en œuvre de TokenID. Cependant, dans le cas de Bitcoin, des implémentations similaires nécessitent généralement l'utilisation de réseaux de seconde couche. Des plateformes telles que Counterparty et Stacks ont déjà mis en œuvre des NFT basés sur le bitcoin, mais l'inscription d'Ordinals présente des différences fondamentales par rapport aux autres architectures NFT du bitcoin.
Le protocole Ordinals utilise le modèle de transaction UTXO de Bitcoin. L'UTXO s'apparente à un système de caisse, par opposition au modèle traditionnel basé sur le solde des comptes.
Dans la blockchain Bitcoin, tous les soldes sont stockés dans une liste appelée Unspent Transaction Outputs (UTXO). Chaque UTXO contient une certaine quantité de bitcoins, ainsi que des informations sur son propriétaire et sur la possibilité de les dépenser. Vous pouvez l'assimiler à un chèque en espèces portant le nom du propriétaire, qui peut être transféré à quelqu'un d'autre par la signature du propriétaire. Pour une adresse donnée, la somme de tous ses montants UTXO représente le solde du portefeuille de cette adresse. En parcourant tous les UTXO, nous pouvons obtenir le solde actuel de chaque adresse. En additionnant tous les montants UTXO, on obtient la circulation totale du bitcoin.
Pour mieux comprendre le modèle de paiement du réseau Bitcoin, prenons l'exemple d'un A qui envoie n bitcoins à un B. Le diagramme ci-dessous illustre le processus d'envoi de 3 bitcoins par un A à un B.
Pour l'utilisateur A, il faut d'abord déterminer l'ensemble des UTXO qu'il possède, c'est-à-dire tous les bitcoins que l'utilisateur A peut contrôler ;
A sélectionne un ou plusieurs UTXO de cet ensemble comme entrée de la transaction. La somme des montants de ces intrants est m (2+0,8+0,5=3,3 BTC), qui est supérieur au montant à payer n (3 BTC) ;
L'utilisateur A définit deux sorties pour la transaction, une sortie est payée à l'adresse de B, le montant est n (3 BTC), et l'autre sortie est payée à l'adresse de changement de A, le montant est m-n-fee (3.3-3- 0.001=0.299). BTC). Le portefeuille d'un utilisateur se compose généralement de plusieurs adresses. En général, chaque adresse n'est utilisée qu'une seule fois et les changements sont renvoyés à une nouvelle adresse par défaut ;
Une fois que le mineur a préparé la transaction et l'a envoyée à la chaîne pour confirmation, B peut recevoir les informations relatives à la transaction. Étant donné que la taille des blocs a une limite supérieure (environ 1 Mo), les mineurs donneront la priorité aux transactions dont le taux est élevé (fee_rate=fee/size) afin d'obtenir en retour la rémunération la plus élevée.
Selon le protocole Ordinals, le nombre de "Satoshi" est basé sur l'ordre dans lequel ils sont extraits, et comme chaque BTC "Satoshi" est généré par des récompenses minières, son numéro de série peut être déterminé grâce à la traçabilité.
Supposons que l'utilisateur A obtienne le 100e-110e Satoshi par le biais de l'exploitation minière (10 Satoshis sont stockés dans le même UTXO avec l'ID adc123). Lorsque l'utilisateur A veut payer 5 satoshis à l'utilisateur B, il choisit d'utiliser l'ID abc123 comme entrée de la transaction, dont 5 satoshis sont donnés à l'utilisateur B, et 5 satoshis sont retournés à l'utilisateur A comme monnaie. Ces deux copies de 5 "Satoshi" forment un tout et sont stockées dans deux UTXO avec les ID abc456 et abc789 respectivement. L'identifiant UTXO ci-dessus et le nombre de "Satoshi" ne sont donnés qu'à titre d'exemple. Dans la réalité, le nombre minimum de "Satoshi" envoyés est limité à 546 et l'identifiant UTXO n'est pas exprimé sous cette forme.
Dans la transaction ci-dessus, le chemin de circulation des 10 satoshis de l'utilisateur A est le suivant :
L'exploitation minière produit 10 "Satoshi", numérotés [100, 110]. Indique que le 100e à 109e "Satoshi" est stocké dans l'UTXO avec l'ID abc123, et que son propriétaire est l'utilisateur A.
Lorsque A transfère de l'argent, 10 "satoshis" sont divisés en deux parties, chacune avec 5 "satoshis". Le principe est que le nombre de "Satoshi" à commander est déterminé en fonction de leur indice dans le résultat de la transaction. En supposant que l'ordre de sortie soit d'abord l'utilisateur A, puis l'utilisateur B, les numéros de série des 5 "satoshis" restants de l'utilisateur A sont [100, 105), qui sont stockés dans l'UTXO avec l'identifiant abc456, et les 5 "satoshis" de l'utilisateur B ont le numéro de séquence [105, 110) et sont stockés dans l'UTXO avec l'identifiant abc789.
Les métadonnées des inscriptions ordinales ne sont pas stockées dans un endroit spécifique. Au lieu de cela, ces métadonnées sont intégrées dans les données témoins de la transaction (données témoins, champ témoin), d'où le nom d'"inscription", car ces données sont "gravées" comme une inscription sur des parties spécifiques de la transaction Bitcoin. et ces données sont rattachées à des "Satoshi" spécifiques. Ce processus d'inscription est mis en œuvre par Segregated Witness (SegWit) et Taproot, qui comprend deux étapes : commit et reveal, et peut inscrire n'importe quelle forme de contenu (texte, image ou vidéo) sur le "satoshi" désigné.
SegWit est une mise à jour de 2017 qui a donné lieu à une fourchette souple de la blockchain Bitcoin. La mise à jour sépare effectivement les transactions Bitcoin en deux parties en ajoutant une section "données témoins" qui peut prendre en charge des données arbitraires.
Le témoin séparé sépare les données de la transaction et du témoin (signature) en deux parties distinctes et permet de stocker des données arbitraires dans la partie témoin.
Techniquement, la mise en œuvre de Segregated Witness signifie que les transactions n'ont plus besoin d'inclure des données de témoin (et n'occuperont pas les 1 Mo d'espace que Bitcoin avait initialement alloué aux blocs). Au lieu de cela, à la fin d'un bloc, un espace séparé supplémentaire est créé pour les données témoins. Il prend en charge les transferts de données arbitraires et dispose d'un "poids de bloc" actualisé qui permet de maintenir intelligemment de grandes quantités de données dans les limites de la taille des blocs de Bitcoin, afin d'éviter un "hard fork".
Mis en œuvre en novembre 2021, Taproot est une mise à jour à multiples facettes conçue pour améliorer la confidentialité, l'évolutivité et la sécurité de Bitcoin. Taproot crée un système qui facilite le stockage de données témoins arbitraires et assouplit les limites de la quantité de données arbitraires pouvant être placées dans une transaction Bitcoin. L'objectif initial de cette mise à jour est d'améliorer les contrats intelligents basés sur Bitcoin, tels que les contrats à durée déterminée, qui sont généralement exprimés en données de témoin.
Les ordinaux stockent les métadonnées dans un script spend dans le chemin d'accès au script Taproot.
Tout d'abord, grâce à la manière dont les scripts Taproot sont stockés, nous pouvons stocker le contenu des inscriptions dans les scripts de dépenses du chemin de script Taproot, qui n'ont presque aucune restriction sur le contenu, tout en recevant des remises sur les données des témoins, ce qui rend le stockage du contenu des inscriptions relativement économique. Comme la consommation des scripts Taproot ne peut se faire qu'à partir de sorties Taproot déjà existantes, les Inscriptions sont frappées en utilisant un processus de validation/révélation en deux étapes. Tout d'abord, dans la transaction de validation, une sortie Taproot est créée qui promet un script contenant le contenu de l'inscription. Ensuite, dans la transaction de révélation, une transaction est initiée en prenant comme entrée l'UTXO correspondant à cette inscription. À cette occasion, le contenu de l'inscription correspondante a été rendu public sur l'ensemble de l'internet.
Cette approche réduit considérablement la consommation de ressources. Si vous n'utilisez pas le script Taproot, les informations sur les témoins sont stockées dans la sortie de la transaction. Ainsi, tant que cette sortie n'est pas consommée, l'information témoin sera toujours stockée dans l'ensemble UTXO. En revanche, si P2TR est utilisé, les informations relatives au témoin n'apparaîtront pas dans la transaction générée pendant la phase de validation, et ne seront donc pas écrites dans l'ensemble UTXO. Ce n'est que lorsque cette UTXO est consommée que l'information sur le témoin apparaît dans l'entrée de la transaction pendant la phase de révélation. P2TR permet d'écrire des métadonnées dans la blockchain Bitcoin, mais elles n'apparaissent jamais dans l'ensemble UTXO. Étant donné que la maintenance/modification de l'ensemble des UTXO nécessite davantage de ressources, cette approche permet d'économiser beaucoup de ressources.
Bien que le nom de BRC-20 soit très similaire à celui de l'ERC-20 d'Ethereum, les différences techniques entre les deux sont en fait significatives. L'état de détention des jetons ERC-20 est sauvegardé sur la chaîne et le consensus du réseau peut être obtenu sur la chaîne. BRC-20 Juste une inscription spéciale du protocole Ordinals, créée par l'utilisateur de Twitter @domodata le 8 mars 2023, qui utilise des inscriptions ordinales de données JSON pour déployer des contrats de jetons, battre monnaie et transférer des jetons. Le json déployé est le suivant :
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Les opérations correspondantes sont la frappe et le transfert, et les deux formats sont pratiquement identiques. Lorsque op est Transfer, le destinataire du transfert de l'inscription est le destinataire du "Satoshi" correspondant à l'inscription. Par conséquent, le transfert de BRC-20 doit s'accompagner du transfert de la propriété des bitcoins et ne pas être simplement consommé en tant que frais de gestion.
Le BRC-20 met en œuvre un mécanisme de "premier arrivé, premier servi". Les déploiements répétés et l'utilisation excessive de la menthe ne sont pas valables. L'organisation centralisée déduira le solde actuel que l'utilisateur devrait avoir sur la base de chaque OP enregistré sur la chaîne, et jugera de la validité de la transaction.
Dans ce processus, les inscriptions sont "attachées" au "Satoshi" transactionnel. Les mineurs de bitcoins ne traiteront pas ces inscriptions. Du point de vue de la chaîne, ils ne sont pas différents des autres "Satoshis". Ils sont tous considérés comme des "Satoshis" ordinaires. Le "Cong" est transféré.
Pour le protocole BRC-20, l'inscription est considérée comme un grand livre qui enregistre le déploiement, la frappe et le transfert des jetons BRC-20. Étant donné que les contrats intelligents ne peuvent pas être exécutés sur Bitcoin, les jetons BRC-20 ne peuvent pas demander des informations pertinentes sur le jeton actuel en exécutant des contrats intelligents. Par conséquent, BRC-20 utilise des requêtes hors chaîne, c'est-à-dire qu'il utilise un serveur centralisé pour récupérer les blocs Bitcoin, enregistrer les opérations de déploiement, de frappe et de transfert de tous les jetons BRC-20 afin de demander le solde final des jetons BRC-20 de chaque utilisateur.
En d'autres termes, le grand livre BRC-20 est décentralisé et enregistré sur la chaîne Bitcoin, mais le processus de règlement est centralisé. Il existe actuellement deux sites web, brc-20.io et unisat.io, qui prennent en charge les requêtes relatives aux jetons BRC-20.
La centralisation du processus de règlement peut entraîner des résultats différents d'une plateforme à l'autre lorsqu'on demande le solde d'un compte donné. Bien que toutes les opérations soient enregistrées sur la chaîne, il incombe au client de les vérifier. Si ces fournisseurs de services centralisés ne divulguent pas leurs règles de vérification, il n'y a en fait aucune garantie pour l'ensemble de l'écosystème BRC-20.
En fait, dans la soirée du 23 avril, UniSat a lancé la plateforme commerciale BRC-20, mais en raison de vulnérabilités dans la bibliothèque de code, elle a subi un grand nombre d'attaques de double dépense. L'adresse bc1pwturekq4w455l64ttze8j7mnhgaupsn99ggd0ds23js924e6ms9fxyht a initialement frappé les Ordinals NFT transférés et a tenté de transférer 5 000 ORDI et 35 000 ORDI à sa propre adresse à partir de rien, et a essayé de vendre les ORDI frappés à partir de rien à d'autres utilisateurs. Unisat a ensuite suspendu l'accès au site web et mené une enquête qui a finalement permis de découvrir que 70 transactions avaient été affectées.
Si Unisat n'avait pas récupéré l'erreur cette nuit-là, les dommages causés par la double attaque ont été estimés à plus d'un million de dollars. La question la plus importante à résoudre au cours du développement du BRC-20 est de savoir comment garantir l'absence d'erreurs lors de la récupération et de la vérification du serveur centralisé.
L'essence de l'inscription ordinale est la suivante : sur le réseau Bitcoin avec l'aide d'un Taproot Le script construit une couche comptable simple pour compter et enregistrer les actifs et les données.
Comme il s'agit uniquement de comptabilité, cela signifie qu'il n'y aura pas d'exécution de script et de processus de vérification similaires aux contrats intelligents, et qu'il doit être fortement dépendant d'une gestion centralisée hors chaîne et de la communication des résultats.
Par conséquent, à l'exception de BRC-20, toutes les inscriptions aux Ordinals doivent être basées sur des services hors ligne en dehors du réseau Bitcoin pour la maintenance de l'état tant qu'elles impliquent un transfert d'état (tel que des transactions). Si le service d'état sous-jacent est indisponible ou défectueux, cela peut entraîner des pertes d'actifs, car le réseau Bitcoin ne peut pas empêcher que des inscriptions non valides soient téléchargées sur la chaîne. La plateforme centralisée doit décider de la validité de l'inscription, qui sera valable sur la plateforme.
Cette méthode centralisée de négociation et de fixation des prix donne à la plateforme centralisée une possibilité importante de comportement malveillant. En outre, la combinaison du paradoxe logique de l'inscription "premier arrivé, premier servi" et du mécanisme de hiérarchisation des emballages par les mineurs en fonction des droits d'exploitation minière permet aux mineurs et aux robots de frappe de frapper un grand nombre d'inscriptions populaires avant les autres, ce qui donne lieu à un processus de frappe inéquitable.
Cependant, il est difficile de prévoir et d'évaluer le développement de nouvelles choses. L'introduction de l'inscription ordinale a sans aucun doute suscité un débat au sein de la communauté Bitcoin sur le rôle fondamental et l'essence de Bitcoin. Cette discussion pourrait déboucher sur la création d'une fourche du bitcoin, axée sur la sécurité et la programmabilité. Il semble que la boîte de Pandore soit en train de s'ouvrir.