Interpréter les jetons ORC-20 : une nouvelle règle d'émission de jetons dans l'écosystème Ordinals
TechFlow SélectionTechFlow Sélection
Interpréter les jetons ORC-20 : une nouvelle règle d'émission de jetons dans l'écosystème Ordinals
Orc20 supprime certaines restrictions de BRC20 et définit davantage d'opérations.
Dédié à des analyses Web3 approfondies*TechFlow est autorisé par xiyu à publier cet article
Dans le protocole ordinals, toute inscription frappée puis interprétée via JSON utilise probablement l'inscription comme un simple brouillon, ce qui comporte un risque élevé de dépendance excessive aux services centralisés.
1. Contexte
BRC20 présente plusieurs limitations : nom de devise limité à quatre caractères, impossibilité de mise à niveau, risque de double dépense, absence de possibilité d'annuler une transaction, etc. ORC20 vise à supprimer ces restrictions ; on peut dire qu'il s'agit d'un hard fork de BRC20. Cela vous rappelle-t-il quelque chose ? Ce modèle ancestral de fork dans l'écosystème BTC.
2. Qu'est-ce qu'ORC20 ?
ORC-20 est une norme ouverte conçue pour renforcer les fonctionnalités des jetons ordonnés sur le réseau Bitcoin, en améliorant la norme populaire BRC-20. ORC20 est rétrocompatible avec BRC-20 et améliore l'adaptabilité, l'évolutivité et la sécurité, tout en éliminant la possibilité de dépenses doubles.
3. Changements apportés par ORC20
3.1 Possibilité de modifier l'offre initiale et la quantité maximale de frappe. Je ne considère pas cela comme un progrès : fixer l'offre initiale et l'offre totale n'est pas un défaut. ORC20 rend simplement plus flexible la création de devises sur ordinals. Fixer ou permettre la flexibilité n'est qu'un choix, sans lien direct avec la qualité.
3.2 L'espace de nommage n'a plus de limite fixe et permet d'utiliser des noms de taille arbitraire. Le nommage est effectivement un point critique, surtout lorsque la majorité des mots de quatre lettres BRC20 ont déjà été pré-enregistrés.
3.3 Utilisation du modèle UTXO afin d'assurer qu'aucune dépense double n'ait lieu pendant les transactions. Vous pouvez rechercher « modèle UTXO » pour plus d'informations : lorsqu'une transaction est envoyée, le solde restant est également transféré vers une adresse de monnaie. Cela permet de résoudre partiellement le problème de double dépense.
Par exemple, diviser 10 000 ORC d'ID 1 en deux parties envoyées à une adresse de réception. Chaque transaction doit avoir un nonce unique. Étape 1 : enregistrer un événement d'envoi vers le destinataire, envoyant 1 000 (avec nonce 5) à l'adresse de réception. Étape 2 : enregistrer un événement d'envoi vers l'expéditeur, renvoyant le solde restant à l'expéditeur (avec nonce 6). La transaction n’est considérée comme terminée que lorsque le solde restant a été renvoyé.
3.4 Permet d'annuler une transaction, en utilisant "op": "cancel", pour annuler la transaction associée à un nonce donné.
3.5 Autorise le transfert des devises BRC20 déjà déployées vers ORC20. Seul le créateur initial de la devise BRC20 peut exécuter cette commande de migration.
4. Nouvelles règles ajoutées par ORC20
4.1 Identifiant id, valeur par défaut 1. L'identifiant doit être unique entre tous les ORC-20 partageant le même identifiant. S’il existe deux ORC-20 ayant le même identifiant et le même ID, le « principe du premier arrivé » s'applique : le second ORC-20 est invalide.
4.2 Le nonce est un identifiant unique associé à chaque transaction, permettant à l'expéditeur de suivre ses transactions partielles. En incluant un nonce dans chaque transaction, l'expéditeur garantit que chaque transaction partielle est unique et ne peut être copiée accidentellement ou malicieusement, ce qui compromettrait la sécurité. Grâce au nonce, l'expéditeur peut également annuler une transaction spécifique en indiquant le nonce correspondant lors de l'envoi d'une transaction d'annulation. Cela ajoute une couche supplémentaire de sécurité et de flexibilité à la norme ORC-20.
4.3 "op": "cancel", opération permettant d'annuler une transaction partielle.
4.4 Champ ug (upgradable) : pouvant être mis à jour : true ou false, valeur par défaut true. Permet au créateur de mettre ultérieurement à jour l'ORC-20.
4.5 Champ wp (wrapped/migration) : true ou false, valeur par défaut false. Utilisé à des fins de migration de jeton, action irréversible. Seul le créateur initial du BRC-20 peut déployer un événement de migration. Ce wrapper copie les métadonnées du BRC-20 d'origine, telles que l'offre maximale et les limites d'émission.
4.6 Version : version du contrat : utile lors de la mise à jour d'ORC-20. En général, chaque mise à jour devrait entraîner une incrémentation du numéro de version, ce qui facilite l'identification des différentes versions du contrat, aidant ainsi le développement, la gestion et l'utilisation futures.
4.7 msg : message : texte personnalisé, message ou déclaration, de taille arbitraire. Ce champ peut fournir des informations sur le jeton, telles que son objectif, sa vision ou ses cas d'utilisation. Cela aide les utilisateurs à mieux comprendre la valeur et l'utilité du jeton, augmentant ainsi sa crédibilité.
4.8 Clé personnalisée (Custom Key). Réservée aux implémentations personnalisées, par exemple : taxe – taxe obligatoire sur les transactions, telle que des royalties ; créateur – adresse spéciale autorisée à frapper ; image – image du jeton ; tkid – identifiant du jeton ; url – URL contenant des informations sur le jeton.
Ces champs optionnels permettent de répondre à des besoins spécifiques de personnalisation, étendant ainsi les fonctionnalités non prises en charge par le protocole standard ORC-20. Par exemple, la taxe peut servir à prélever un frais à chaque transaction, les royalties permettent de reverser une compensation à l’auteur initial, etc. Le créateur peut désigner une adresse spéciale pour accorder le droit de frapper des jetons.
5. Limites d'ORC20
5.1 Complexité : dans l'écosystème ordinals basé sur Bitcoin, la simplicité peut être perçue comme un avantage. Or, après que BRC20 a complexifié le processus d’émission de devises, ORC20 va encore plus loin dans la complexité. Plus de définitions, des opérations fastidieuses, tout cela augmente le risque d'erreurs. Par exemple, l'opération de migration peut conduire à l’existence simultanée de deux versions de la même devise.
5.2 Centralisation : l’utilisation de JSON vise à faciliter la recherche, mais la recherche repose inévitablement sur des services centralisés. C’est là une faiblesse intrinsèque de toutes les applications ordinals autres que les NFT.
5.3 Royalties obligatoires : il s'agit essentiellement d'intégrer dans les règles le système de redevances habituellement appliqué sur les marchés de NFT. Imposer des royalties sur une devise me semble relever d’une incompréhension. Pour un NFT, dont la nature est artistique, il est compréhensible de reverser des royalties à l’artiste – relation entre créateur et utilisateur. Mais pour une devise, les détenteurs sont plutôt des investisseurs. Exiger qu’un investisseur reverse une redevance au projet après avoir investi paraît peu raisonnable.
5.4 Dépendance au chemin suivi (path dependency) : en analysant ORC20, on constate qu’il cherche à rapprocher l’émission de devises sur Bitcoin du modèle RC20. Ce qui soulève alors la question suivante : pourquoi ne pas utiliser directement ERC20 ?
6. Conclusion
En un mot : ORC20 supprime certaines limitations de BRC20 et introduit davantage d'opérations.
En réalité, la compétitivité clé de l’émission de devises sur ordinals réside dans les services centralisés, pas dans la norme elle-même. Seule une chaîne complète d'authentification intégralement stockée sur blockchain peut prévenir les risques de centralisation.
Le principal problème de BRC20 ne réside pas dans ses nombreuses limitations, mais dans sa dépendance aux services centralisés. ORC20 ne résout pas ce problème. ORC20 considère BRC20 comme un concurrent et vise principalement à conquérir le marché. Son impact sur l’écosystème ordinals est négligeable, tout comme son influence sur BRC20 reste limitée.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
xiyu
