Comment la validation côté client complique l’architecture du SDK du portefeuille : analyse de l’intégration RGB-WDK

6 Min Read
6 Min Read

L’interopérabilité est cruciale pour une expérience transparente avec les blockchains et les crypto-monnaies. Cependant, il manque largement dans les intégrations entre de nombreux SDK de portefeuille existants et RGB, un protocole permettant d’émettre des actifs et d’exécuter des contrats intelligents sur Bitcoin.

Utexo, un participant du CTDG Dev Hub, a introduit la prise en charge RVB pour le kit de développement de portefeuille (WDK) de Tether via le SDK Utexo. Le support concilie essentiellement deux visions fondamentalement différentes de l’état des actifs.

Pourquoi les SDK de portefeuille et RVB ne correspondent pas

La plupart des SDK de portefeuille sont conçus autour d’un ensemble restreint et bien défini de responsabilités : gérer les clés, suivre les soldes, construire des transactions et interagir avec la chaîne sous-jacente. Ils supposent que l’état des actifs est globalement observable, dérivé de la blockchain et mis à jour de manière monotone.

Ces hypothèses correspondent clairement au modèle UTXO de Bitcoin ou à des systèmes basés sur des comptes, comme Ethereum.

Cependant, RVB les brise tous par conception. RGB ne publie pas l’état des actifs sur la chaîne ; il est validé côté client et transféré hors chaîne. Les transactions Bitcoin en chaîne ne servent que de points d’ancrage.

Cela crée une inadéquation structurelle, notamment dans trois domaines :

  • Suivi des soldes : étant donné que la validité dépend des preuves et des envois stockés localement, il n’existe pas de source de vérité en chaîne pour les soldes RVB.

  • Cycle de vie d’une transaction : une coordination est requise entre une transaction Bitcoin et une transition d’état RVB, mais aucune ne représente pleinement le transfert à elle seule.

  • Persistance et récupération de l’état : la relecture de la blockchain ne parvient pas à récupérer les portefeuilles ; l’état RVB local doit également être préservé et validé.

LIRE  Alchemy introduit des rails de paiement autonomes pour les agents IA sur la base

Bien que RVB préserve la sécurité et l’évolutivité de Bitcoin, il attribue des responsabilités supplémentaires aux SDK du portefeuille, telles que la gestion de l’état RVB, des données de validation et de la persistance, ainsi que la coordination de ces éléments avec les flux de transactions Bitcoin.

Ce que l’intégration introduit

Le WDK de Tether est un SDK modulaire multichaîne avec des responsabilités de portefeuille de base similaires à celles des autres SDK. Le WDK évite délibérément d’intégrer une logique spécifique au protocole pour permettre aux applications de rester découplées des chaînes individuelles.

Pour corriger cette inadéquation, la prise en charge RVB d’Utexo introduit une couche d’adaptateur dédiée dans WDK. La couche traduit les opérations du portefeuille RVB en abstractions compatibles WDK.

Ce module wdk-wallet-rgb conserve toujours la validation RVB, les envois et la gestion de l’état en dehors du noyau WDK, mais expose les soldes RVB via des interfaces de compte côté portefeuille et aligne l’émission et les transferts RVB avec les flux de transactions de portefeuille existants.

Sans le module, les développeurs doivent gérer les clés RVB, la validation et la persistance en tant que sous-système distinct aux côtés du portefeuille. Une coordination personnalisée entre les transactions Bitcoin et les changements d’état hors chaîne est requise lors de l’exécution des transferts RVB. Les sauvegardes et les restaurations nécessitent également une gestion sur mesure de l’état RVB.

Au lieu de cela, le module wdk-wallet-rgb dérive les clés RVB des graines BIP-39 standard et les intègre dans le flux de gestion des clés existant du portefeuille. L’émission et les transferts RVB suivent les mêmes flux de transactions structurés que ceux utilisés ailleurs dans le portefeuille. Pendant ce temps, l’état du portefeuille RVB peut être sauvegardé et restauré sous forme cryptée avec d’autres données du portefeuille.

LIRE  Quantra serre la main avec Chain Intelligence pour amplifier l’infrastructure Web3

Les limites du module

Le module comporte certaines limitations. Il:

  • ne fournit pas la fonctionnalité de nœud RGB Lightning.

  • ne gère pas la configuration réseau ni la découverte de nœuds.

  • ne définit pas l’UX au niveau de l’application ni les flux de paiement.

  • n’élimine pas la complexité UX inhérente aux actifs validés côté client.

Les limitations existent parce que le module est intentionnellement conçu comme une couche d’intégration de portefeuille et qu’il ne vise pas à remplacer l’infrastructure RVB ou à automatiser les problèmes de déploiement.

Le module fournit plutôt un moyen structuré d’intégrer la fonctionnalité des actifs RVB dans l’écosystème WDK sans casser les abstractions de portefeuille existantes. Son approche reflète la façon dont l’infrastructure du portefeuille doit évoluer à mesure que de plus en plus de protocoles natifs Bitcoin déplacent la validation et l’état hors chaîne.

Un hub nourrissant l’écosystème blockchain

Le développeur du module, Utexo, est membre du CTDG Dev Hub. Faisant partie de l’initiative CTDG de Cointelegraph, le hub constitue un point de rencontre pour les développeurs et les utilisateurs de diverses blockchains.

Sur CTDG Dev Hub, Utexo accède à une main-d’œuvre mondiale capable de susciter des idées, de travailler sur des solutions innovantes et de fournir des commentaires précieux, tout en contribuant également à l’écosystème Bitcoin lui-même.

TAGGED:
Share This Article
Leave a comment