Quel est le meilleur modèle de gestion déléguée pour les actifs sur BTC ?
TechFlow SélectionTechFlow Sélection
Quel est le meilleur modèle de gestion déléguée pour les actifs sur BTC ?
Prenons l'exemple de Runes pour analyser le meilleur mécanisme de représentation d'actifs sur Bitcoin.
Dédié à des analyses Web3 approfondiesRédaction : Shi Jun
Les échanges sont l'âme du web3, l'attention est la ressource la plus fondamentale du web3, le prix est le point de départ de la foule, et la valeur est la destination finale dans le temps.
Un mois s'est écoulé depuis la halving du BTC, tout comme un mois depuis le tant attendu protocole Runes. Pendant cette période, une dizaine de plateformes d'inscription («代打») ont vu le jour, créant un marché actif où, le jour de la halving, le coût d'une inscription unique pour un actif Runes dépassait même les 100 dollars américains.
Cet article prend les actifs Runes comme exemple afin d’analyser quel modèle d’inscription sur Bitcoin est le plus optimal ?
1. Classement des plateformes d’inscription Runes par coût en frais de gaz (GAS)
Le graphique ci-dessous présente une synthèse réalisée par Shi Jun.
Voici les conclusions principales selon les différentes approches :
-
Coût en gaz : « division + chaîne » < chaîne < division < inscription individuelle
-
Degré de centralisation : chaîne (sans adresse intermédiaire) < division (sans adresse intermédiaire) < chaîne (avec adresse intermédiaire) < division (avec adresse intermédiaire)
-
Regroupement des actifs : chaîne > division + chaîne > division
-
Vitesse de mise en ligne en masse : division = division + chaîne > chaîne
Cela peut sembler confus au premier abord : que signifient « modèle en chaîne » et « modèle divisé » ?
Pour comprendre cela, revenons au protocole Runes lui-même. Pour approfondir, nous recommandons la lecture de cet article : À l’approche de la halving du BTC : décryptage du mécanisme fondamental et des limites du protocole Runes.
1.1. Principe d’inscription (etching) des Runes
Runes utilise une technique d’inscription, qui consiste à enregistrer des informations directement sur la blockchain via le champ op-return des UTXO (sorties non dépensées) de Bitcoin. Cette fonctionnalité, disponible depuis la version 0.9 du client Bitcoin Core (depuis 2014), permet via OP-RETURN de créer une sortie vérifiable, non consommable, stockant des données sur la blockchain, similaire aux UTXO mais non transférable.
Dans un explorateur blockchain BTC, on peut facilement observer qu’une transaction contient une information op-return, comme illustré ci-dessous :
On remarque ici que la sortie #3 est isolée : bien qu’elle occupe une position d’UTXO, sa forme circulaire indique qu’elle ne peut pas être transférée ou dépensée. Elle agit donc comme une note attachée à la transaction, conservée dans l’espace de stockage de Bitcoin et accessible via le hachage de la transaction.
Vous avez peut-être remarqué la mention « RUNE_TEST » après OP_RETURN. Il s’agit du résultat du décodage des données hexadécimales (ex. : 52554e455f54455354). En cliquant sur les détails, on retrouve ces chaînes codées, qui, décodées, forment des structures semblables à du JSON, décrivant le déploiement, le minting et l’émission des actifs Runes.
En résumé, le mécanisme d’inscription repose sur le fait qu’une seule transaction Runes peut inscrire un seul actif.
Dans le réseau BTC, le coût de transaction correspond à la taille des données envoyées. Ainsi, le meilleur modèle d’inscription est celui qui minimise le nombre d’UTXO générés dans une transaction.
Passons maintenant à l’explication des modèles divisé et en chaîne.
1.2. Modèle divisé
Le modèle divisé consiste, lors de l’inscription, à effectuer d’abord une transaction de division en plusieurs sous-transactions, chacune procédant ensuite au minting d’un actif.
Par exemple, la solution d’inscription de tools.mempool fonctionne comme suit :
La première transaction estime les frais pour chaque sous-transaction, puis divise en plusieurs UTXO en réservant 546 satoshis (valeur typique de « dust ») plus les frais. Ces UTXO sont transférés vers une nouvelle adresse.
La deuxième transaction ramène les fonds vers l’adresse utilisateur tout en exécutant l’inscription, permettant à l’utilisateur de recevoir ses actifs Runes.
Ce modèle présente plusieurs inconvénients majeurs :
- Nécessite une transaction initiale de division.
- Les UTXO reçus par l’utilisateur sont fragmentés.
Lorsqu’un utilisateur souhaite vendre, il doit soit lister chaque UTXO individuellement, soit les fusionner avant — ce qui augmente le coût, surtout pour les gros volumes.
De plus, tools.mempool n’effectue pas d’inscription supplémentaire lors de la division, ce qui entraîne des pertes supérieures à d’autres modèles divisés.
1.3. Modèle en chaîne
Le modèle en chaîne fonctionne comme illustré ci-dessous : un utilisateur possédant initialement 20 000 satoshis consomme successivement chaque transaction encore en mémoire (mempool), formant ainsi une chaîne de transactions multiples.
On observe ici que l’adresse se terminant par s2t4 perçoit 6 144 satoshis, correspondant aux frais d’inscription de la plateforme. Comparé au coût réel de transaction (3 892 satoshis), la marge bénéficiaire est élevée.
Cette plateforme est Runestone, qui affirmait avoir développé son système d’inscription et de marché en seulement 5 jours. Bien qu’elle soit aujourd’hui inactive, elle a généré près de 3 BTC (plus de 1,5 million USD) de frais durant ses premiers jours — une somme considérable pour un développeur indépendant.
Toutefois, ces frais sont injustifiés. De nombreux outils open source existent désormais, comme le SDK JS Wallet d’OKX, qui résout entièrement les problèmes d’encodage/décodage et d’inscription pour Runes : https://github.com/okx/js-wallet-sdk.
Revenons au modèle en chaîne : puisque les frais sont prélevés dès la première transaction, les suivantes sont traitées de manière cyclique comme montré ci-dessous, ce qui limite la quantité de données transmises.
2. Meilleur modèle d’inscription Runes : division + chaîne
Luminex propose actuellement l’un des meilleurs modèles : capable de gérer des mintings massifs, doté d’un outil de division d’UTXO, et utilisant une combinaison de division et de chaîne.
Comme illustré ci-dessous :
- Lors de la division, la plateforme attribue immédiatement un actif à l’utilisateur, sans gas perdu.
- Si le nombre de mintings est inférieur à 25, elle divise suffisamment de gaz en chaîne, puis procède au minting.
- Au-delà de 25, elle crée plusieurs chaînes de gaz, puis exécute le minting.
Bien que les frais de base ne soient pas inférieurs au modèle en chaîne pure, Luminex offre deux avantages clés : la capacité de minting massif et une efficacité maximale, pouvant finaliser le processus en seulement 2 blocs.
2.1. Pourquoi l’efficacité de mise en ligne est-elle un critère important ?
Cela découle d’un mécanisme de sécurité des nœuds BTC contre les attaques DoS :
Le nombre de transactions en mémoire (mempool) consommant un même UTXO (et sa chaîne de consommation) est limité à 25.
C’est pourquoi la plupart des grandes campagnes de minting utilisent une adresse intermédiaire : pour contourner cette limite. Dans le modèle en chaîne, les actifs sont accumulés puis transférés à l’utilisateur.
Ainsi, le modèle en chaîne est limité à 25 transactions simultanées en mempool, tandis que le modèle divisé, après la confirmation de la transaction de division, permet un nombre illimité de transactions (car chaque UTXO est compté séparément avec sa propre limite de 25).
Luminex est donc optimal non seulement par son faible coût en gaz, mais aussi par sa capacité à gérer des mintings à grande échelle.
Toutefois, un modèle encore meilleur existe.
En effet, Luminex effectue une inscription supplémentaire lors de la division, alors que cet actif pourrait simplement être transféré dans le second UTXO de la chaîne, profitant du mécanisme de transfert par défaut des Runes. Cela permettrait d’économiser un UTXO supplémentaire par rapport à Luminex.
2.2. Comparaison du taux d’optimisation des frais BTC
Après avoir longuement parlé de coûts, comment les mesurer ? Très simplement : les utilisateurs fixent généralement un prix unitaire (similaire au gasPrice), mais sur BTC, les frais dépendent directement de la taille des données, exprimée en vsize.
Prenons l’exemple d’une adresse Taproot (qui offre des frais plus bas que d’autres types d’adresses). Dans cette structure :
- Chaque input supplémentaire augmente le vsize de 58.
- Chaque output supplémentaire augmente le vsize de 43.
- Chaque op-return nécessite environ 30 de vsize.
Nous pouvons donc calculer les taux d’optimisation suivants :
Chaîne – Minting de 10 actifs : coût = i*10 + o*10 + p*10 = 1310
Division – Minting de 10 actifs : coût = i*10 + o*10 + o*9 + p*10 = 1697
Optimisation du gaz : (1697 - 1310)/1697 = 22,8 %
Chaîne – Minting de 20 actifs : coût = i*20 + o*20 + p*20 = 2620
Division – Minting de 20 actifs : coût = i*20 + o*20 + o*19 + p*20 = 3437
Optimisation du gaz : (3437 - 2620)/3437 = 23,8 %
Bien que 20 % semble modeste, pendant les pics où une inscription unique coûtait 100 USD, réaliser 10 mintings groupés permettait d’économiser 200 USD. Ces petites différences finissent par influencer fortement les seuils psychologiques de transaction.
Face à des frais d’inscription élevés, ceux qui souhaitent profiter tôt du web3 devraient apprendre les bases de Node.js, utiliser directement les codes open source disponibles (comme le composant de signature d’OKX mentionné plus haut), éviter les frais de plateforme, et même, dans un prochain article sur les marchés, construire des solutions inter-plateformes, surveiller directement la mempool, et réaliser des arbitrages rapides.
3. Conclusion
Un mois après son lancement, le protocole Runes n’a malheureusement pas franchi le seuil des 1 milliard de dollars, suscitant même des plaisanteries sur un prétendu livestream de seppuku de Casey, fondateur d’Ordinals et de Runes.
Mais en dernière analyse, c’est l’absence d’infrastructures clés — inscription et marché — qui rend la participation trop coûteuse pour les petits investisseurs et l’exploitation écosystémique difficile pour les institutions.
Actuellement, les plateformes disponibles exigent soit des frais excessifs, soit manquent de fonctionnalités. Par exemple, Runestone, bien que son modèle en chaîne soit économique, souffre d’estimations imprécises de gaz, entraînant des pertes sur la dernière transaction, ainsi qu’une incertitude de confirmation, ce qui l’a progressivement fait disparaître.
De plus, les modèles d’inscription ignorent souvent la véritable demande des utilisateurs : la liquidité.
Les actifs inscrits doivent souvent être revendus rapidement. Or, en phase initiale avec une forte volatilité des prix et un réseau BTC saturé, hormis les actions marketing des projets eux-mêmes, il y a peu de demande pour des mintings massifs. Qui plus est, ceux disposant du capital nécessaire pour inscrire 1 000 actifs ont généralement les compétences techniques pour le faire eux-mêmes. Le cœur de cible des plateformes reste donc les petits utilisateurs.
Ainsi, bien que le modèle en chaîne soit moins coûteux, il n’est pas adapté aux toutes premières phases, où les prix fluctuent rapidement. En l’absence d’outils de division sur les marchés, les 20+ actifs regroupés dans une seule transaction augmentent le seuil d’achat, limitant la liquidité.
Enfin, cet article traite des mécanismes d’inscription d’actifs sur BTC. Un prochain article analysera les modèles de marché applicables aux nouveaux actifs (BRC20, Ordinals, Atomicals, Runes, etc.). Restez informés !
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
