RGB et Taro, tous deux mettant des jetons sur Bitcoin, adoptent deux approches différentes du développement
RGB et Taro, deux protocoles capables de mettre des jetons comme des stablecoins sur Bitcoin, ont adopté des approches différentes pour résoudre des problèmes similaires.
Ceci est un éditorial d’opinion de Kishin Kato, le fondateur de Trustless Services KK, une société japonaise de recherche et développement Lightning Network.
La demande de pièces stables sur Bitcoin revient car le Lightning Network offre des avantages d’évolutivité massifs. Actuellement, les utilisateurs des marchés émergents qui souhaitent effectuer des transactions et économiser en USD se contenteront de pièces stables sur d’autres chaînes, selon les partisans. En mettant de côté mes sentiments personnels à propos de ces autres chaînes de blocs, je dois reconnaître que les bitcoins reçus dans des envois de fonds transfrontaliers bon marché ne peuvent pas facilement être vendus pour des dollars alors qu’ils résident dans des canaux Lightning non dépositaires.
RGB et Taro sont deux nouveaux protocoles qui permettent l’émission de jetons sur Bitcoin, et devraient donc apporter des transactions stables sur Lightning. J’ai étudié ces protocoles et le paradigme de validation côté client qu’ils utilisent et j’ai publié un rapport sur mes découvertes intitulé « Emergence Of Token Layers On Bitcoin » via Diamond Hands, une importante communauté d’utilisateurs et de développeurs du Lightning Network japonais et un fournisseur de solutions centrées sur Bitcoin.
Priorités et état d’esprit, révélés par le développement de protocoles
Le développement de protocoles n’est pas facile et prend souvent des années. Il est essentiel de décider des fonctionnalités à prioriser et de faire des compromis, et l’un des principaux différenciateurs entre RVB et Taro réside dans les décisions qu’ils ont prises à cet égard.
RGB, avec ses ambitions en tant que couche de contrat intelligent au-dessus de Bitcoin (c’est-à-dire pas seulement pour les jetons), dispose d’un protocole en chaîne robuste pour exécuter des transitions d’état hors chaîne. Une conception soignée a entraîné une confidentialité supérieure, une évolutivité et une polyvalence en chaîne, au prix d’une complexité conceptuelle. D’autre part, Taro semble se concentrer davantage sur l’utilisation hors chaîne, comme sur le Lightning Network, en spécifiant les méthodes de paiement multi-sauts et d’échange de jetons. Cependant, parmi les raccourcis pratiques que Taro a pris en faveur de la simplicité conceptuelle, il y a sa négligence à normaliser au moins un élément de base de son protocole en chaîne.
Étant donné que les actifs de Taro sont stockés à l’aide d’un UTXO en chaîne, les transactions de Taro peuvent théoriquement être construites de deux manières : l’une où l’expéditeur paie le bitcoin pour la sortie du destinataire, et l’autre où le destinataire apporte sa propre contribution pour le payer lui-même. Le premier cas est plus simple, mais l’expéditeur offre effectivement du bitcoin ; ce dernier peut être plus précis, mais nécessite une interaction expéditeur-destinataire pour créer la transaction. À moins que ces méthodes et leur sélection ne soient standardisées, l’interopérabilité des portefeuilles est une chimère.
En effet, une fois qu’un protocole est largement adopté, il est difficile de le mettre à jour ou de le remplacer sans rompre l’interopérabilité. Cependant, ce n’est pas nécessairement le cas si votre implémentation est la seule. Lightning Labs peut réserver sa capacité à itérer rapidement en reportant intentionnellement l’adoption généralisée du protocole. J’ai eu cette impression de l’écart de normalisation susmentionné, ainsi que du fait que Lightning Labs prévoit d’expédier son portefeuille Taro avec LND, son implémentation de nœud Lightning avec plus de 90 % de part de marché.
Il est certainement possible que l’approche de Lightning Labs réussisse mieux à apporter des jetons à Lightning. Mais à moins qu’il ne renonce à son rôle dominant à un moment donné, Taro risque de devenir un peu plus qu’une API LND. Il n’est pas inimaginable pour moi que Taro reste une fonctionnalité spécifique à LND.
Lightning survivra-t-il aux jetons ?
En tant que Bitcoiner semi-paranoïaque, je dois me demander si la prolifération des jetons sur Bitcoin entraînera des conséquences négatives pour le Lightning Network ou Bitcoin lui-même. Alors que les préoccupations de ce dernier sont validées par la capacité de Circle (l’émetteur de l’USDC) à influencer les utilisateurs lors de tout hard fork controversé potentiel dans Ethereum.
Comme mentionné précédemment, l’approche de Taro, si elle se poursuit, se traduira par une utilité accrue de LND grâce à l’utilisation de son portefeuille Taro inclus, par rapport à d’autres implémentations. Cela peut potentiellement verrouiller davantage la position dominante de LND dans le paysage de la mise en œuvre des nœuds. Pour maintenir la décentralisation de Lightning, il est préférable que les utilisateurs soient répartis plus uniformément sur plusieurs implémentations, de sorte que même l’implémentation la plus populaire ne puisse pas simplement implémenter des changements de protocole sans conséquence pour ses utilisateurs.
Bien que je ne sois pas personnellement fan de la grande majorité des jetons cryptographiques, je pense que le Lightning Network a quelque chose à offrir aux utilisateurs de ces jetons : des échanges et des paiements rapides, privés et décentralisés. Pouvoir payer quelqu’un dans sa devise locale ou préférée instantanément, sans que l’expéditeur en soit propriétaire, a un potentiel immense pour perturber les rails de paiement et de remise existants. Bien qu’il ne soit pas clair quel protocole prévaudra pour l’émission de jetons sur Bitcoin, j’espère que la prolifération des jetons ne sacrifiera pas les choses que Bitcoin et Lightning représentent.
Ceci est un article invité de Kishin Kato. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.
