Bitcoin Magazine - Accueil Bitcoin News, articles et avis d'experts
Nostr Wallet Connect : une couche de collaboration d'applications Bitcoin
NOSTR WALLET CONNECT : UNE COUCHE DE COLLABORATION D'APPLICATIONS BITCOIN
SHINOBI IL Y A 48 MINUTES
À mesure que la complexité des logiciels et des applications Bitcoin utilisant Bitcoin augmente, le besoin d'un mécanisme de coordination simple pour que les différentes applications interagissent augmente également.
Dans l’avenir de l’adoption et du développement de Bitcoin, il y a un problème d’interaction logicielle qui arrive au premier plan des obstacles auxquels les développeurs doivent faire face : la compatibilité. À mesure que les applications et les protocoles dans cet espace deviennent plus complexes et plus fonctionnels afin de répondre aux besoins des utilisateurs et des cas d'utilisation réels, cela présente un dilemme qui n'a fondamentalement que deux vraies réponses : soit une application ou un portefeuille doit intégrer en interne tous les protocoles et fonctionnalités nécessaires pour répondre aux exigences de son objectif, soit différentes applications doivent pouvoir communiquer entre elles.
Un exemple de ce problème est l’intégration de Lightning dans différentes applications et outils logiciels. Lightning est une pile de protocoles très compliquée à mettre en œuvre, impliquant de nombreux sous-protocoles dictant la manière de coordonner et de traiter les mises à jour de l'état d'un canal Lightning. Cela implique la structure des transactions pour chaque état de canal et ce qu'il applique, l'ordre dans lequel chaque étape de création et de signature de nouvelles transactions est effectuée pour garantir la sécurité des fonds des utilisateurs, et les fonctions permettant de surveiller la blockchain pour qu'elle réagisse automatiquement de manière appropriée si les états invalides sont toujours soumis à la blockchain.
Cela représente beaucoup de complexité pour un seul développeur d'applications à prendre en charge en s'intégrant directement à son projet. La conclusion évidente si cela nécessite trop d'efforts est de dépendre d'un logiciel déjà produit gérant le problème de la mise en œuvre de Lightning et de simplement créer votre application pour communiquer avec ce logiciel externe. Cela nous amène au problème suivant : que se passe-t-il si les utilisateurs de votre application n’utilisent pas cette implémentation ou ce portefeuille Lightning particulier ?
Même en externalisant cette fonctionnalité d’une application, l’équipe de développement n’a toujours pas complètement échappé au problème de complexité. Bien qu'ils ne soient pas obligés d'implémenter entièrement Lightning par eux-mêmes, un développeur empruntant cette voie doit désormais gérer l'intégration de la prise en charge de l'API pour tout portefeuille Lightning que l'utilisateur de son application pourrait potentiellement utiliser. Cela nécessite de suivre toute modification ou modification apportée à plusieurs portefeuilles Lightning, à leur API, au fonctionnement des fonctionnalités internes de ce portefeuille et à celles qu'ils prennent en charge. Ne pas suivre les modifications apportées à un portefeuille particulier interromprait leur application pour les utilisateurs de ce portefeuille.
Un mécanisme standardisé doit exister pour que les logiciels des deux côtés de cet écart puissent simplement implémenter cette seule chose pour que tous ces différents outils communiquent entre eux. Cela permettrait à chaque développeur d'applications et à chaque développeur de portefeuille Lightning d'intégrer et de maintenir simplement un protocole unique qui permettrait à leurs applications de communiquer entre elles.
Nostr Wallet Connect est un protocole qui tente d'être un mécanisme véritablement généralisé pour répondre à ce besoin. Lorsque nous cherchons à intégrer les paiements Lightning dans Nostr, tous ces problèmes de complexité liés à la manière de le faire sont apparus.
LA FOUDRE ET LE NWC
L'équipe derrière Amethyst, un client Nostr, et Alby, le portefeuille Lightning basé sur le Web, ont créé NWC afin de résoudre le problème des utilisateurs Nostr souhaitant intégrer Lightning dans leur expérience Nostr sans avoir à utiliser un portefeuille spécial. L'application/le protocole est basé sur l'architecture d'identité de Nostr où chaque message (événement) envoyé via Nostr est signé par une paire de clés cryptographiques fonctionnant comme votre identité sur Nostr. Cela permet à une application de générer simplement une paire de clés Nostr et, à partir de celle-ci, de disposer d'un mécanisme d'authentification cryptographique à utiliser pour communiquer avec un portefeuille Bitcoin externe afin de remplir les fonctionnalités de l'application.
[INSÉRER LES INFORMATIONS ICI]
En utilisant la paire de clés pour enregistrer l'application externe auprès du portefeuille Lightning, l'application peut désormais envoyer une requête ping à votre portefeuille pour lancer un paiement. La spécification prend actuellement en charge le paiement des factures BOLT 11, les paiements par clé (paiements sans facture effectués sur la clé publique d'un nœud), le paiement de plusieurs factures simultanément, la génération d'une facture à présenter à quelqu'un d'autre pour vous payer, et quelques autres fonctionnalités pour permettre l'historique des paiements et requêtes sur le solde du portefeuille à partir de l’application externe.
Tout cela est coordonné sur Nostr, permettant un moyen de communication très redondant ne dépendant pas d'un seul mécanisme de messagerie centralisé ou l'utilisateur devant dépendre de logiciels compliqués tels que Tor ou d'autres protocoles pour faciliter la connexion réseau entre une application et un logiciel de portefeuille. ou une infrastructure fonctionnant sur leur réseau domestique. Nostr prend également en charge les messages directs cryptés, ce qui signifie que la communication entre le portefeuille et l'application est entièrement privée, ne révélant aucun détail sur les paiements coordonnés avec les relais Nostr utilisés pour communiquer.
Du côté du portefeuille du pont NWC, des restrictions de sécurité peuvent être mises en œuvre pour empêcher l'application externe d'avoir un accès illimité aux fonds du portefeuille au cas où la clé Nostr utilisée pour communiquer avec le portefeuille serait compromise. Les restrictions sur les montants autorisés à dépenser, ainsi que sur la fréquence des paiements, sont configurables côté portefeuille de la connexion.
NWC est également utile pour bien plus que la simple intégration de Lightning dans les applications Nostr. Toute la philosophie de conception de Nostr lui-même en tant que protocole était centrée sur le fait de rester suffisamment simple pour que l'ensemble du protocole puisse être facilement implémenté correctement par n'importe quel développeur avec un minimum de temps et de ressources. Les applications qui n'ont rien à voir avec Nostr peuvent facilement intégrer NWC ou des protocoles similaires avec presque aucune surcharge ni complexité pour résoudre les problèmes sous-jacents liés à la connexion d'un portefeuille Bitcoin à leur application sans avoir à le créer directement dans l'application.
AU-DELÀ DE LA FOUDRE
Le potentiel d’un protocole tel que NWC à apporter une valeur considérable aux développeurs de portefeuilles et d’applications va bien au-delà de l’intégration des portefeuilles Lightning dans des applications spécifiques. L’orientation à long terme de l’interaction avec Bitcoin, à moins d’une avancée fondamentale époustouflante que personne n’a encore réalisée, est orientée vers des protocoles interactifs entre plusieurs utilisateurs.
Les pools de pièces multipartites en sont un parfait exemple. La plupart des propositions de conception spécifiques telles que les arbres Ark ou Timeout sont construites autour d'une partie centrale de coordination ou d'un fournisseur de services, ce qui peut facilement faciliter la transmission de messages entre les portefeuilles des utilisateurs, mais cela paralyse l'espace de conception avec un seul point de défaillance. Si une centaine d'utilisateurs sont regroupés dans un pool de pièces au-dessus d'un seul UTXO, le modèle de sécurité est basé sur le fait que chaque utilisateur dispose d'un chemin pré-signé pour retirer ses pièces unilatéralement sur la chaîne. Ce mécanisme peut être utilisé en cas de défaillance ou de disparition du coordinateur pour garantir que ses fonds ne soient pas perdus, mais c'est le moyen le moins efficace de gérer un tel scénario du pire.
Si les utilisateurs pouvaient trouver un mécanisme pour communiquer entre eux en l'absence du fournisseur de services ou du coordinateur, des sorties en chaîne beaucoup plus efficaces pourraient être obtenues en utilisant le multisig de groupe plus grand pour migrer leurs fonds ailleurs avec une méthode beaucoup plus efficace ( et donc moins cher) empreinte sur la chaîne. NWC et Nostr conviennent parfaitement à un tel scénario.
Les portefeuilles multisignatures collaboratifs entre plusieurs parties pourraient également bénéficier d’un tel protocole. En combinaison avec des normes telles que PSBT, un simple mécanisme de communication Nostr pourrait considérablement simplifier la complexité des différents portefeuilles avec un support multisig coordonnant la signature des transactions de manière fluide et conviviale.
Les contrats de journaux discrets (DLC) sont une autre utilisation étonnante d'un tel protocole. L'ensemble du système DLC repose sur la capacité des deux parties à accéder aux signatures Oracle pour clôturer unilatéralement et correctement un contrat si les deux parties ne coopèrent pas pour le régler de manière collaborative. Nostr est le mécanisme parfait permettant aux oracles de diffuser ces signatures et permet un simple abonnement à leur clé Nostr dans les portefeuilles des utilisateurs pour suivre et acquérir automatiquement les signatures lorsqu'elles sont diffusées par les oracles.
Au fur et à mesure que le temps passe et que de plus en plus d'applications et de protocoles sont construits sur Bitcoin avec l'exigence d'interactivité entre les utilisateurs et entre différentes applications, un mécanisme de communication à usage général pour faciliter cela sans s'appuyer sur un seul point de défaillance sera cruellement nécessaire. .
Nostr est le protocole sous-jacent idéal pour faciliter cela, compte tenu de son incroyable simplicité et de la redondance d'un large ensemble de relais à utiliser. NWC est l’exemple parfait de cette solution viable.