Hier, le créateur d'Ordinals, Casey Rodarmor, a publié un blog présentant un nouveau protocole de jeton fongible (FT) Runes.
Concernant la question de savoir si Bitcoin a besoin de FT, Casey Rodarmor a déclaré dans son tweet que FT avait deux côtés. D'une part, 99,99 % des FT sont des « merdes » et des escroqueries qui affaiblissent la pureté du Bitcoin ; d'autre part, ils rapportent beaucoup de revenus aux développeurs et aux utilisateurs à l'écosystème Bitcoin. "Les gens adorent les jetons et ils sont comme des casinos cyberpunk, donc les revenus des frais seront probablement substantiels et continus jusqu'à ce que les inquiétudes concernant les budgets de (cyber)sécurité soient complètement atténuées."
Il a ajouté que des protocoles FT tels que BRC-20, RGB et Taproot ont déjà vu le jour. Comparés aux simples protocoles en chaîne, les protocoles tels que RGB et Taproot sont complexes et peuvent poser des défis pour l'expérience utilisateur. BRC-20 est très simple et peut offrir une bonne expérience utilisateur par rapport à RGB/Taproot qui nécessite une infrastructure de stockage et de récupération de données hors chaîne ; mais le problème avec les jetons BRC 20 est qu'ils génèrent des « déchets UTXO » et occupent de l'espace en bits.
Rodarmor a déclaré que Runes est un protocole basé sur UTXO qui s'adapte plus naturellement à Bitcoin et favorise la minimisation des collections UTXO en évitant la création de « UTXO indésirables ».
Le contenu suivant provient du blog de Casey Rodarmor et a été compilé par Odaily Planet Daily
Je ne sais pas si la création d'un nouveau protocole Fungible Token (FT) pour Bitcoin est une bonne idée. 99,9 % des FT sont des escroqueries et des mèmes. Cependant, ils ne semblent pas disparaître de sitôt, tout comme les casinos ne semblent pas disparaître de si tôt.
La création d'un bon protocole FT pour Bitcoin peut apporter des revenus considérables en frais de transaction, attirer l'attention des développeurs et des utilisateurs sur Bitcoin. De plus, si le protocole a une empreinte sur la chaîne plus petite et encourage une gestion responsable des UTXO, il peut réduire les dommages par rapport aux protocoles existants. Par exemple, le BRC-20, actuellement populaire, a conduit à la génération d’une grande quantité d’UTXO indésirables.
Si nous comparons les protocoles FT existants, nous constaterons qu’ils présentent plusieurs différences importantes :
Complexité : Quelle est la complexité du protocole ? Est-ce facile à mettre en œuvre ? Est-ce facile à adopter ?
Expérience utilisateur : y a-t-il des détails de mise en œuvre qui ont un impact négatif sur l'expérience utilisateur ? En particulier, les protocoles qui s'appuient sur des données hors chaîne ont une empreinte en chaîne plus légère mais introduisent une complexité importante et obligent les utilisateurs soit à exécuter leurs propres serveurs, soit à découvrir et interagir avec les serveurs existants.
Modèle d'état : les protocoles basés sur UTXO s'intègrent plus naturellement dans Bitcoin et favorisent la minimisation des ensembles UTXO en évitant la création d'UTXO « indésirables ».
Jetons natifs : les protocoles avec des jetons natifs requis pour le fonctionnement du protocole sont encombrants, retirables et naturellement moins largement adoptés.
Sur la base des dimensions ci-dessus, les résultats de comparaison des protocoles FT existants dans l'écosystème Bitcoin sont les suivants :
BRC-20 : Non basé sur UTXO, et assez complexe car il nécessite l'utilisation de la théorie ordinale dans certaines opérations ;
RVB : Très complexe, repose sur des données hors chaîne, a été développé depuis longtemps et n'a pas été adopté ;
Contrepartie : dispose de jetons natifs requis pour certaines opérations, plutôt que basés sur UTXO ;
Omni Layer : possède des jetons natifs requis pour certaines opérations, plutôt que basés sur UTXO ;
Taproot Assets : un peu compliqué et repose sur des données hors chaîne.
Pour Bitcoin, à quoi ressemblerait un protocole FT simple basé sur UTXO avec une bonne expérience utilisateur ? Ensuite, j'aimerais vous présenter une solution très intéressante appelée "Runes".
(1. Vue d'ensemble
Les soldes de runes sont conservés dans UTXO ; UTXO peut contenir n’importe quel nombre de runes.
Une transaction contient un message de protocole si elle contient une sortie dont la clé publique de script contient OP_RETURN suivi d'un push de données R majuscule ASCII. Le message de protocole contient toutes les données transmises après la première.
Les runes entrées dans les transactions avec des messages de protocole invalides seront détruites, permettant aux futures mises à niveau de modifier la façon dont les runes sont allouées ou créées, évitant ainsi aux clients plus anciens d'attribuer incorrectement les soldes de runes.
Les entiers sont codés avec le préfixe int, où le premier chiffre de int détermine sa longueur en octets.
(2) Transfert
La première transmission de données dans un message de protocole est décodée en une séquence d'entiers.
Ces entiers sont interprétés comme une séquence de tuples (ID, OUTPUT, AMOUNT). Si le nombre d'entiers décodés n'est pas un multiple de 3, le message de protocole n'est pas valide.
ID est l'ID numérique de l'exécution à attribuer
OUTPUT est l'index de la sortie à affecter
AMOUNT est le nombre de courses à allouer
L'ID est codé en tant que delta. Cela permet d'attribuer la même rune plusieurs fois pour éviter de dupliquer l'ID de rune complet. Par exemple, tuple : [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Effectuez les missions suivantes :
ID 100, sortie 1, 20 runes
ID 100, sortie 2, 10 runes
id 120, sortie 1, 5 runes
AMOUNT 0 est l'abréviation de "toutes les runes restantes".
Une fois que toutes les affectations de tuples ont été traitées, toutes les runes non attribuées sont affectées à la première sortie non-OP_RETURN (le cas échéant). Les missions supplémentaires seront ignorées.
Les runes peuvent être gravées en les affectant à la sortie OP_RETURN contenant le message de protocole.
(3)Problème
Si le message de protocole comporte une deuxième transmission de données, il s'agit d'une transaction problématique. La deuxième transmission de données est décodée en deux entiers, SYMBOL et DECIMALS. S'il reste des entiers supplémentaires, le message de protocole n'est pas valide.
Une transaction d'émission peut créer n'importe quel nombre de runes d'émission en utilisant l'ID 0 dans le tuple d'affectation, jusqu'à un maximum de 2 ^ 128 - 1.
SYMBOL est un symbole de codage de base de 26 bits lisible par l'homme, similaire au symbole utilisé dans les noms sat ordinaux. Les seuls caractères valides sont A à Z.
DECIMALS est le nombre de chiffres après la virgule décimale qui doivent être utilisés lors de l'affichage des runes émises.
Si le SYMBOLE n'a pas été attribué, il est attribué à une rune publiée et la rune publiée reçoit le prochain ID de rune numérique disponible (en commençant à 1).
Si SYMBOL a déjà été attribué, ou s'il s'agit de BITCOIN, BTC ou XBT, aucune nouvelle rune ne sera créée. Les allocations de transaction de libération utilisant un ID de rune de 0 seront ignorées, mais les autres allocations seront toujours traitées.
(4) REMARQUE
Lors de l'affichage des soldes UTXO, le solde Bitcoin natif de l'UTXO peut être affiché avec l'ID de rune 0 et les symboles BITCOIN, BTC ou XBT.
Afin de garder le protocole simple, (Runes) n'adopte pas de mécanisme pour éviter le squattage de symboles. En fait, un moyen efficace et simple d’éviter les liens de symboles consiste à autoriser uniquement l’attribution de symboles au-dessus d’une certaine longueur, qui diminue avec le temps, puis finit par atteindre zéro et autorise tous les symboles. Cela éviterait d’attribuer des symboles courts et idéaux au début du protocole et encouragerait les retardataires à rivaliser pour les symboles idéaux – si une telle compétition a du sens.
Écrit à la fin
Cette solution fonctionne-t-elle vraiment pour le marché ? Je n'ai aucune idée.
C'est aussi simple que possible, ne repose pas sur des données hors chaîne, n'a pas de jetons natifs et s'intègre parfaitement dans le modèle UTXO natif de Bitcoin. Un tel système pourrait attirer les utilisateurs d’autres systèmes ayant une empreinte sur la chaîne plus faible et attirer l’attention des développeurs et des utilisateurs sur Bitcoin, les encourageant à adopter Bitcoin lui-même.
Le monde du commerce électronique, en revanche, est un abîme totalement irrémédiable de tromperie et d’avidité, et il pourrait donc être emporté par les eaux.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Remplacer BRC-20 pour activer l’écosystème BTC ? Le fondateur d'Ordinals apporte un nouveau protocole Runes
Original | Casey Rodarmor
Compilé | Odaily Planet Daily
Hier, le créateur d'Ordinals, Casey Rodarmor, a publié un blog présentant un nouveau protocole de jeton fongible (FT) Runes.
Concernant la question de savoir si Bitcoin a besoin de FT, Casey Rodarmor a déclaré dans son tweet que FT avait deux côtés. D'une part, 99,99 % des FT sont des « merdes » et des escroqueries qui affaiblissent la pureté du Bitcoin ; d'autre part, ils rapportent beaucoup de revenus aux développeurs et aux utilisateurs à l'écosystème Bitcoin. "Les gens adorent les jetons et ils sont comme des casinos cyberpunk, donc les revenus des frais seront probablement substantiels et continus jusqu'à ce que les inquiétudes concernant les budgets de (cyber)sécurité soient complètement atténuées."
Il a ajouté que des protocoles FT tels que BRC-20, RGB et Taproot ont déjà vu le jour. Comparés aux simples protocoles en chaîne, les protocoles tels que RGB et Taproot sont complexes et peuvent poser des défis pour l'expérience utilisateur. BRC-20 est très simple et peut offrir une bonne expérience utilisateur par rapport à RGB/Taproot qui nécessite une infrastructure de stockage et de récupération de données hors chaîne ; mais le problème avec les jetons BRC 20 est qu'ils génèrent des « déchets UTXO » et occupent de l'espace en bits.
Rodarmor a déclaré que Runes est un protocole basé sur UTXO qui s'adapte plus naturellement à Bitcoin et favorise la minimisation des collections UTXO en évitant la création de « UTXO indésirables ».
Le contenu suivant provient du blog de Casey Rodarmor et a été compilé par Odaily Planet Daily
Je ne sais pas si la création d'un nouveau protocole Fungible Token (FT) pour Bitcoin est une bonne idée. 99,9 % des FT sont des escroqueries et des mèmes. Cependant, ils ne semblent pas disparaître de sitôt, tout comme les casinos ne semblent pas disparaître de si tôt.
La création d'un bon protocole FT pour Bitcoin peut apporter des revenus considérables en frais de transaction, attirer l'attention des développeurs et des utilisateurs sur Bitcoin. De plus, si le protocole a une empreinte sur la chaîne plus petite et encourage une gestion responsable des UTXO, il peut réduire les dommages par rapport aux protocoles existants. Par exemple, le BRC-20, actuellement populaire, a conduit à la génération d’une grande quantité d’UTXO indésirables.
Si nous comparons les protocoles FT existants, nous constaterons qu’ils présentent plusieurs différences importantes :
Sur la base des dimensions ci-dessus, les résultats de comparaison des protocoles FT existants dans l'écosystème Bitcoin sont les suivants :
Pour Bitcoin, à quoi ressemblerait un protocole FT simple basé sur UTXO avec une bonne expérience utilisateur ? Ensuite, j'aimerais vous présenter une solution très intéressante appelée "Runes".
(1. Vue d'ensemble
Les soldes de runes sont conservés dans UTXO ; UTXO peut contenir n’importe quel nombre de runes.
Une transaction contient un message de protocole si elle contient une sortie dont la clé publique de script contient OP_RETURN suivi d'un push de données R majuscule ASCII. Le message de protocole contient toutes les données transmises après la première.
Les runes entrées dans les transactions avec des messages de protocole invalides seront détruites, permettant aux futures mises à niveau de modifier la façon dont les runes sont allouées ou créées, évitant ainsi aux clients plus anciens d'attribuer incorrectement les soldes de runes.
Les entiers sont codés avec le préfixe int, où le premier chiffre de int détermine sa longueur en octets.
(2) Transfert
La première transmission de données dans un message de protocole est décodée en une séquence d'entiers.
Ces entiers sont interprétés comme une séquence de tuples (ID, OUTPUT, AMOUNT). Si le nombre d'entiers décodés n'est pas un multiple de 3, le message de protocole n'est pas valide.
L'ID est codé en tant que delta. Cela permet d'attribuer la même rune plusieurs fois pour éviter de dupliquer l'ID de rune complet. Par exemple, tuple : [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Effectuez les missions suivantes :
AMOUNT 0 est l'abréviation de "toutes les runes restantes".
Une fois que toutes les affectations de tuples ont été traitées, toutes les runes non attribuées sont affectées à la première sortie non-OP_RETURN (le cas échéant). Les missions supplémentaires seront ignorées.
Les runes peuvent être gravées en les affectant à la sortie OP_RETURN contenant le message de protocole.
(3)Problème
Si le message de protocole comporte une deuxième transmission de données, il s'agit d'une transaction problématique. La deuxième transmission de données est décodée en deux entiers, SYMBOL et DECIMALS. S'il reste des entiers supplémentaires, le message de protocole n'est pas valide.
Une transaction d'émission peut créer n'importe quel nombre de runes d'émission en utilisant l'ID 0 dans le tuple d'affectation, jusqu'à un maximum de 2 ^ 128 - 1.
SYMBOL est un symbole de codage de base de 26 bits lisible par l'homme, similaire au symbole utilisé dans les noms sat ordinaux. Les seuls caractères valides sont A à Z.
DECIMALS est le nombre de chiffres après la virgule décimale qui doivent être utilisés lors de l'affichage des runes émises.
Si le SYMBOLE n'a pas été attribué, il est attribué à une rune publiée et la rune publiée reçoit le prochain ID de rune numérique disponible (en commençant à 1).
Si SYMBOL a déjà été attribué, ou s'il s'agit de BITCOIN, BTC ou XBT, aucune nouvelle rune ne sera créée. Les allocations de transaction de libération utilisant un ID de rune de 0 seront ignorées, mais les autres allocations seront toujours traitées.
(4) REMARQUE
Lors de l'affichage des soldes UTXO, le solde Bitcoin natif de l'UTXO peut être affiché avec l'ID de rune 0 et les symboles BITCOIN, BTC ou XBT.
Afin de garder le protocole simple, (Runes) n'adopte pas de mécanisme pour éviter le squattage de symboles. En fait, un moyen efficace et simple d’éviter les liens de symboles consiste à autoriser uniquement l’attribution de symboles au-dessus d’une certaine longueur, qui diminue avec le temps, puis finit par atteindre zéro et autorise tous les symboles. Cela éviterait d’attribuer des symboles courts et idéaux au début du protocole et encouragerait les retardataires à rivaliser pour les symboles idéaux – si une telle compétition a du sens.
Écrit à la fin
Cette solution fonctionne-t-elle vraiment pour le marché ? Je n'ai aucune idée.
C'est aussi simple que possible, ne repose pas sur des données hors chaîne, n'a pas de jetons natifs et s'intègre parfaitement dans le modèle UTXO natif de Bitcoin. Un tel système pourrait attirer les utilisateurs d’autres systèmes ayant une empreinte sur la chaîne plus faible et attirer l’attention des développeurs et des utilisateurs sur Bitcoin, les encourageant à adopter Bitcoin lui-même.
Le monde du commerce électronique, en revanche, est un abîme totalement irrémédiable de tromperie et d’avidité, et il pourrait donc être emporté par les eaux.