protocole RGB

Qu'est-ce que RGB

RGB est un protocole de contrat intelligent évolutif et confidentiel applicable à Bitcoin et au Lightning Network, développé par l'Association des normes LNP/BP. Il adopte les concepts de propriété privée et commune, offrant une forme de calcul distribué complète de Turing, sans confiance et sans avoir besoin d'une blockchain, fonctionnant comme un système de contrat intelligent client-validé et à état partiel.

Histoire du développement du protocole RGB

Histoire du protocole RGB

RGB a d'abord été conçu par Giacomo Zucco du BHB Network en 2016 comme un "système d'actifs non basé sur la blockchain." La même année, Peter Todd a introduit les concepts de sceaux à usage unique et de validation côté client. Inspiré par ces idées, RGB a été proposé en 2018. En 2019, le développeur principal Maxim Orlovsky a joué un rôle de premier plan dans le développement du code RGB et la conception des normes fondamentales. Maxim Orlovsky et Giacomo Zucco ont fondé l'association des normes LNP/BPhttps://www.lnp-bp.org) pour faire passer RGB du concept à l'application, avec le soutien de Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime et DIBA. Après un développement approfondi, RGB a publié sa première version stable, V0.10, en avril 2023. En janvier 2024, les développeurs principaux de RGB ont annoncé que la version V0.11 serait publiée au début du premier semestre de l'année.

Derniers développements dans le protocole RGB

Les nouvelles fonctionnalités de RGB V0.10 ont été minutieusement analysées dans d'autres rapports. Alors que V0.11 n'a pas encore été officiellement publiée, voici quelques-uns des derniers développements des développeurs et de la communauté :

• Prise en charge à venir de L-BTC

• Mises à jour sur l'interopérabilité et les ponts inter-chaînes entre les actifs RGB et les actifs Liquid

Cependant, RGB V0.11 sera incompatible avec V0.10, ce qui entraînera des coûts de migration importants pour les projets actuels. De plus, en raison de l'avancement lent du développement, de nombreux projets attendent actuellement la sortie de V0.11.

Philosophie de conception RGB et principes de fonctionnement

Les contrats intelligents RGB utilisent une validation côté client, ce qui signifie que toutes les données sont stockées en dehors des transactions Bitcoin, c'est-à-dire sur la blockchain Bitcoin ou l'état des canaux Lightning. Cela permet au système de fonctionner sur le réseau Lightning sans aucun changement apporté aux protocoles du mainnet BTC ou du réseau Lightning, posant ainsi les bases de la scalabilité et de la confidentialité du protocole.

RGB utilise des scellés à usage unique définis sur les UTXO Bitcoin, permettant à quiconque disposant d'un historique de l'état du contrat intelligent de vérifier son caractère unique. En d'autres termes, RGB exploite les scripts Bitcoin pour mettre en œuvre son modèle de sécurité et définir la propriété et les droits d'accès.

RGB est un graphe acyclique dirigé (DAG) de transitions d'état, où les contrats sont complètement isolés les uns des autres, et personne ne sait de leur existence sauf les propriétaires de contrat (ou ceux à qui le propriétaire divulgue des informations sur le contrat).

Un graphe acyclique dirigé (DAG) est une structure de graphe spéciale qui peut expliquer de manière vivante des systèmes ou des relations complexes. Dans un DAG, chaque arête peut être considérée comme une rue à sens unique dans une ville, ce qui représente l'aspect 'dirigé' du graphe. Supposons que dans ce réseau de rues, peu importe comment vous voyagez, il est impossible de revenir au point de départ et de former une boucle fermée ; cela représente la nature 'acyclique' du graphe. Dans un DAG, il n'y a pas de séquence de nœuds qui vous permet de partir d'un nœud, de voyager à travers une série d'arêtes et de revenir au même nœud.

Appliquer ce concept au système RGB, chaque contrat peut être considéré comme un nœud dans le graphe, et les relations entre les contrats (comme le transfert de propriété) peuvent être vues comme des arêtes dirigées. Cette structure garantit que les relations entre les contrats sont claires et ordonnées, sans former de boucles fermées, ce qui signifie qu'un contrat ne peut pas affecter directement ou indirectement lui-même.

Ce design garantit que les engagements dans la transmission d'état sont uniques et immuables, empêchant le double dépense et réalisant des transitions d'état efficaces et cohérentes.

Plongée dans les contrats RGB

Après avoir compris les principes de base de la conception architecturale de RGB, regardons la partie contrat. Dans le monde actuel des contrats intelligents, les créateurs doivent organiser ou exécuter le développement du code de contrat intelligent eux-mêmes. La philosophie de conception de RGB considère cette pratique comme indésirable, entraînant un plus grand nombre de vulnérabilités du code de contrat et de multiples attaques de pirates. Par conséquent, RGB vise à réduire le risque de vulnérabilités dans le développement et le besoin d'audits en introduisant le concept de "Schémas de modèles". Les "Schémas de modèles" sont le code réel des contrats intelligents. Les éditeurs peuvent les utiliser comme des "modèles de contrat" sans avoir besoin de coder ou d'auditer un code personnalisé écrit pour eux par un entrepreneur aléatoire.

Scalabilité flexible et bonne interopérabilité

Les contrats RGB sont définis de manière déclarative, et non impérative. Cela signifie que la logique du contrat n'est pas définie par une série de commandes ou d'étapes, mais par un ensemble de règles qui décrivent son comportement et ses transitions d'état, formant un graphe acyclique dirigé (DAG) des changements d'état. La clé des opérations d'état local réside dans le Schéma. Les opérations dans les contrats RGB sont locales, et non globales. Chaque nœud (ou état) a ses propres règles et est uniquement responsable de ses transitions d'état. Cela diffère des algorithmes mondiaux sur des plateformes comme Ethereum, qui exigent que chaque état suive le même algorithme. Cette caractéristique rend RGB suffisamment flexible et évolutif tout en offrant une bonne interopérabilité.

Création simplifiée de contrats intelligents

Le schéma définit quels types d'états globaux et possédés, de sceaux et de métadonnées sont autorisés dans les transitions d'état. RGB utilise le langage Contractum pour écrire des schémas RGB et AluVM (Arithmetic Logic Unit Virtual Machine), simplifiant l'écriture de contrats intelligents RGB. AluVM est basé sur une conception de registre sans accès mémoire aléatoire, ce qui le rend très adapté aux contrats intelligents, à l'exécution de code à distance, à l'informatique distribuée et périphérique, offrant une base pour divers cas d'utilisation avancés de contrats intelligents.

Comment RGB assure la sécurité et la confidentialité

De la conception de RGB elle-même :

• Confidentialité sans diffusion globale : Comme mentionné, la validation côté client de RGB signifie que le processus de validation se déroule uniquement entre les pairs directement impliqués, pas l'ensemble du réseau. Cette approche de non-diffusion globale renforce la confidentialité et la résistance à la censure car les détails de l'état du contrat ne sont visibles que des participants concernés, et les mineurs ne peuvent pas voir les détails de la transaction.

• Confidentialité des données dans un environnement sandbox : D'un autre côté, RGB stocke toutes les données d'opération dans une réserve. Comme RGB n'est pas basé sur la blockchain, le stockage n'est pas répliqué vers d'autres nœuds pairs. Le stockage contrôlé localement par les utilisateurs réduit le risque d'attaques externes et de fuites de données, garantissant la confidentialité des données. RGB est une plateforme informatique où chaque programme ("smart contract") est isolé dans son environnement sandbox, offrant une meilleure évolutivité et sécurité que les plateformes basées sur la blockchain. Cependant, les données hors chaîne signifient également qu'il y a un risque de perte.

• Au-delà de la validation et du stockage, le système de facturation garantit également la sécurité et la confidentialité. Les opérations de contrat dans RGB sont effectuées en créant des factures, qui peuvent contenir plusieurs demandes d'opérations contractuelles. En permettant aux utilisateurs de spécifier et de vérifier explicitement les opérations contractuelles, la précision et la sécurité des opérations sont améliorées. Parallèlement, le système de facturation prend en charge la transmission privée des demandes d'opérations contractuelles entre les utilisateurs, renforçant la confidentialité des transactions. Les transitions d'état, telles que les transferts de jetons, sont exécutées via des factures et des commandes spécifiques.

Du point de vue de l'interaction avec BTC

La conception de RGB est étroitement liée aux UTXOs. Lors des interactions avec le BTC mainnet, les utilisateurs créent des contrats hors chaîne pour émettre des actifs RGB et les allouer aux UTXOs de Bitcoin, de manière similaire au Lightning Network. Ensuite, les transferts d'actifs, les interactions de contrats et les validations sont effectués hors chaîne comme introduit ci-dessus.

RGB bénéficie de l’amélioration des protocoles de signature multisig basés sur des adaptateurs et des contrats à verrouillage temporel (PTLC) apportés par les signatures Schnorr, mais ses avantages sont purement basés sur ceux de Bitcoin (c’est-à-dire indirects). Il n’y a rien dans RGB qui nécessite des signatures (donc Schnorr n’apporte aucun changement en interne), ni n’utilise de scripts Bitcoin (donc le nouveau Tapscript n’est d’aucune utilité).

BTC Security Lab, co-fondé par ScaleBit, est un laboratoire de sécurité BTC dédié travaillant sur les derniers développements du protocole RGB. Son objectif est de protéger la sécurité des contrats, en promouvant conjointement la croissance continue et le renforcement du protocole RGB et la construction de l'infrastructure de l'écosystème BTC.

Vue d'ensemble des projets de l'écosystème RGB

BiHelix

• Site Web : https://www.bihelix.net/

• BiHelix est une infrastructure écosystème Bitcoin optimisée pour les nœuds, construite sur la blockchain Bitcoin native, intégrant le protocole RGB et le Lightning Network. Son objectif est de faciliter le développement, d'élargir les cas d'utilisation du Bitcoin et de résoudre les défis de la scalabilité et de l'incomplétude de Turing auxquels est confrontée la blockchain Bitcoin. BiHelix s'efforce de créer un monde cryptographique décentralisé plus juste pour les mineurs, les validateurs, les fournisseurs de services de nœuds, les échanges et les utilisateurs. En tant que première infrastructure construite sur le protocole RGB, BiHelix développera la prochaine génération de scénarios d'application Bitcoin à grande échelle. Le projet est actuellement en phase de développement et n'est pas encore ouvert à l'interaction ; restez à l'écoute.

  Caractéristiques du projet

• Seuil d'utilisateur bas : Utilise le protocole SLR (Security-Lightning-RGB), reconditionnant RGB et le Lightning Network avec des solutions innovantes pour que les nœuds d'éclairage puissent atteindre un paiement universel.

• Fiabilité et évolutivité élevées : Adopte une architecture de service cloud mature, exploitant pleinement les fonctionnalités de rust-lightning pour prendre en charge les fonctions de fabrique de canaux, gérer efficacement les canaux et créer des canaux en masse.

• Protection de la sécurité et de la vie privée : Transmission et stockage hors chaîne des données d'état, utilisant des preuves de savoirs nuls récursives entre autres technologies pour randomiser les paiements multipartites et la sélection de chemin pour la protection de la vie privée.

• Convivial pour les développeurs : Fournit des outils de développement complets, y compris une documentation open-source, des outils, etc., et introduit le mécanisme de consensus social Schema, facilitant ainsi la construction d'applications pour les développeurs.

  Portefeuille Iris

• Site web : https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

• IRIS Wallet, le premier portefeuille Android développé par l'équipe Bitfinex, est dédié à l'intégration de RGB et aux outils associés à RGB, prenant en charge les actifs fongibles et non fongibles. Iris Wallet permet d'effectuer des opérations sur les actifs RGB, de l'émission aux dépenses et à la réception, en regroupant toutes les fonctionnalités dans une application de portefeuille familière tout en abstrayant autant de détails techniques que possible. Il s'agit actuellement d'une application expérimentale recommandée pour de petites quantités de bitcoins et des actifs de faible valeur.

  DIBA

• Site internet : https://diba.io/

• DIBA est le premier marché NFT sur Bitcoin utilisant le protocole RGB et le Lightning Network. Il vise à façonner la compréhension des actifs artistiques non détenus sur la blockchain Bitcoin.

  Bitmask

• Site Web : https://bitmask.app/

• Créé par DIBA, Bitmask est le premier portefeuille NFT dans l'écosystème RGB, utilisable dans les navigateurs web et interagissant avec des contrats RGB similaires à MetaMask sur Ethereum. Il est actuellement fréquemment mis à jour, en attendant la sortie de V0.11.

  Pandora Prime Inc

• Site Web : https://pandoraprime.ch/

• Basé dans la vallée de Verify, en Suisse, Pandora Prime est également membre fondateur de LNP/BP. Pandora Prime est dédié à la finance Bitcoin pionnière en utilisant la combinaison de contrats intelligents RGB et du Lightning Network. Ils commencent avec des actifs programmables sur Bitcoin (RGBTC et CHFN), qui peuvent augmenter le débit des transactions aux niveaux de VISA/MasterCard grâce au Lightning Network tout en offrant des facilités pour l'échange facile de ces actifs. Leurs produits incluent MyCitadel (portefeuille), RGB Explorer (navigateur) et Pandora Network, entre autres.

  MyCitadel

• Site web : https://mycitadel.io/

• Une marque de Pandora Prime, MyCitadel est le premier portefeuille GUI prenant en charge RGB, créé par les développeurs RGB en 2021. Il propose des portefeuilles de bureau multiplateformes et des portefeuilles iOS/iPad. Le portefeuille mobile peut gérer des actifs RGB fongibles.

  Explorateur RGB

• Site web : https://rgbex.io/

• Développé par Pandora Prime, RGB Explorer est le premier navigateur à offrir l'enregistrement d'actifs RGB et des contrats intelligents. Actuellement, il prend en charge RGB 20, RGB 21, RGB 25, affichant des actifs tels que LNPBP, RGBTC, dCHF et RGBEX.

  Bitlight Labs (anciennement Cosminmart)

• Site Web : https://bitlightlabs.com/

• Bitlight Labs développe une infrastructure basée sur le protocole RGB, se préparant à déployer plusieurs applications sur le réseau Lightning, y compris le portefeuille Bitlight pour l'utilité RGB et Bitswap, un fournisseur de liquidité automatisé pour BitcoinFi sur le réseau Lightning et le protocole RGB.

Mèmes RGB & NFT

1. PPRGB

   • X: @PepeRgb20

   • PPRGB est actuellement émis sur le réseau Liquid, en attente de mapping vers RGB après la publication de RGB V0.11 (V0.11 développe également des fonctions de code pour l'interface avec Liquid).

2. Inscription MRGB

   • L'inscription MRGB est un jeton basé sur la validation de l'état client du protocole RGB et le système de contrat intelligent. Il fonctionne sur les deuxième et troisième couches (hors chaîne) de l'écosystème Bitcoin et fournira un code de protocole sous-jacent open-source, permettant à toutes les chaînes publiques BRC20 d'utiliser directement ce système. Cette innovation apporte un potentiel significatif aux chaînes publiques BRC20, notamment en réduisant la consommation de GAS, en accélérant la vitesse des transactions et en améliorant les performances globales. En adoptant le système MRGB, les chaînes publiques BRC20 pourront traiter les transactions de manière plus efficace et réduire les coûts de transaction pour les utilisateurs. Parallèlement, le jeton d'inscription MRGB servira également de consommable dans le processus de transaction, augmentant ainsi la liquidité et la scalabilité du BTC.

3. Single-Use-Seal

   • X: @Single_Use_Seal

   • Seal, est une collection de 10k PFP, UDA rare et de jetons sur RGB20 et RGB21, nommée d'après le concept de Single Use Seal de Peter Todd. En attendant actuellement que les portefeuilles Bitlight et Bitmask se mettent à jour vers la version v0.11 de RGB, après quoi ils y seront émis.

4. Bitman

   • X: @bitmancity

   • Émettra 10k UDA sur diba, probablement par le biais d'une vente privée+publique, dans le but de "transmettre l'esprit du BTC." Le projet a un but louable et offrira une wl aux contributeurs de l'écosystème BTC, la plupart des recettes de la vente publique étant données à LNP/BP.

BitVM

Pourquoi BitVM?

BitVM (Bitcoin Virtual Machine) introduit un système qui permet de vérifier toute computation sur la blockchain Bitcoin sans compromettre sa sécurité ou altérer le réseau. Ce développement ouvre la voie à des computations complexes, telles que des smart contracts complètement turing-complets, toutes les computations étant traitées hors chaîne pour réduire la congestion sur la blockchain Bitcoin.

En termes simples, BitVM est un modèle computationnel capable d'exprimer des contrats complets de Turing sur le réseau Bitcoin. Comme RGB, BitVM ne nécessite pas de modifications des règles de consensus du réseau.

Le 9 octobre 2023, Robin Linus, co-fondateur du développeur blockchain ZeroSync, a publié le livre blanc BitVM. Comparé à RGB, BitVM est beaucoup plus jeune.

Architecture de conception de BitVM

Architecture

Similaire aux Rollups Optimistes et à la proposition Merkelize All The Things (MATT), basée sur des preuves de fraude et des protocoles de challenge-réponse, elle ne nécessite pas de changements aux règles de consensus de Bitcoin. BitVM démontre que Bitcoin est Turing-complet en encodant des preuves de fraude dans de grands Taptrees.

Conception de circuit Gate

L'engagement de valeur de bit est le composant le plus basique, permettant au commitant de définir la valeur d'un bit spécifique à "0" ou "1". Toute fonction calculable peut être représentée sous forme de circuit booléen, formant des engagements de portes logiques. Construit à travers des portes NAND (portes logiques universelles), chaque porte a son propre engagement. Tout circuit peut être exprimé en combinant les engagements de portes. Chaque étape d'exécution est engagée dans un Tapleaf et combinée dans la même adresse Taproot.

BitVM utilise la mise à niveau Taproot de Bitcoin en créant une structure similaire à un circuit binaire (appelée taptree) pour atteindre sa fonctionnalité. Dans ce système, les conditions de dépense de chaque UTXO, représentées par des instructions dans un script, forment l'unité de base du programme. Ces instructions génèrent des sorties binaires (0 ou 1) dans une adresse Taproot, construisant ainsi l'intégralité du taptree. La sortie du taptree peut être considérée comme le résultat de l'exécution d'un circuit binaire, semblable à un programme exécutable. La complexité des programmes qu'un taptree peut exécuter dépend du nombre et de la complexité des adresses Taproot le composant. En bref, BitVM réalise la capacité d'exécuter des programmes plus complexes sur le réseau Bitcoin en traduisant les instructions du script Bitcoin en opérations binaires.

Les rôles participants sont deux parties

Actuellement, le modèle est limité à deux parties et ne peut pas être étendu pour inclure plus de participants. De plus, pour que BitVM fonctionne correctement, un grand nombre de pré-signatures (calculs hors chaîne) sont nécessaires, ce qui rend BitVM assez complexe et potentiellement inefficace.

Preuves de fraude et protocole de challenge-response

Le prouveur et le challenger déposent tous deux un montant égal de BTC dans une transaction en guise de pari (en entrée), et le résultat de cette transaction inclura un circuit logique. Une série de transactions est pré-signée pendant la phase de configuration pour réfuter les déclarations incorrectes. BitVM est comparé à Optimistic Rollups car il effectue la plupart des calculs hors chaîne et soumet certains de ces calculs sur chaîne pour résoudre les litiges lorsqu'ils surviennent.

Les Rollups optimistes sont une solution de mise à l'échelle de deuxième couche qui réduit la charge sur la couche de base en déplaçant le calcul et le stockage des données hors chaîne. Il regroupe ensuite plusieurs transactions et les publie sur la chaîne principale. Les Rollups optimistes supposent que toutes les transactions sont valides. Cependant, si les participants du réseau remarquent un comportement malhonnête, ils peuvent initier une preuve de fraude. Une preuve de fraude est une preuve d'un calcul inexact de quelqu'un. Elles sont produites après une inspection.

Calcul hors chaîne

Presque toutes les activités sur BitVM sont effectuées hors chaîne. Cela inclut l'initiation des tâches de calcul, le partage des données et la vérification des réclamations soumises. BitVM ne réalise généralement pas de calculs sur la blockchain Bitcoin. Les calculs et les vérifications ne sont publiés en chaîne que lorsqu'il y a un litige dû à une fraude présumée. Cependant, en cas de litige, une petite partie du processus de litige s'exécute effectivement en chaîne, juste assez pour déterminer quelle partie est malhonnête.

Avec les connaissances de base ci-dessus, nous pouvons mieux comprendre les principes spécifiques de l'interaction à deux parties de BitVM.

Le modèle d'interaction à deux parties de BitVM implique un prouveur et un vérificateur. Dans ce système, le prouveur crée et soumet d'abord un contrat intelligent ou un programme, puis envoie des fonds à une adresse racine maître contrôlée en commun. Ces fonds sont conservés dans un arrangement multisignature 2-sur-2. Le prouveur doit également partager suffisamment d'informations avec le vérificateur pour prouver que son programme peut produire le résultat promis.

La tâche du vérificateur est d'exécuter le code du prouveur et de vérifier si la sortie correspond aux attentes. Si la sortie ne correspond pas, le vérificateur mettra au défi le prouveur. Ce processus d'interaction défi-réponse implique l'échange de données hors chaîne et l'utilisation de transactions pré-signées pour vérifier la justesse du calcul.

Si une erreur de calcul est découverte, le vérificateur peut prouver publiquement le comportement malhonnête du prouveur grâce à une preuve de fraude sur la chaîne. Dans le système BitVM, si la réponse du prouveur est prouvée incorrecte, il perdra le pari et abandonnera les fonds. En revanche, si toutes les réponses sont correctes, le prouveur conservera ses fonds. Ce mécanisme d'incitation économique est conçu pour prévenir tout comportement malhonnête.

Au final, cette interaction garantit que la vérification computationnelle n'est transférée à la blockchain Bitcoin qu'en cas de litige, effectuant ainsi la grande majorité des calculs hors chaîne. Cette conception maintient l'efficacité du réseau Bitcoin tout en offrant la possibilité d'exécuter des programmes plus complexes sur Bitcoin.

Sécurité de BitVM

Du point de vue de la conception architecturale, la sécurité de BitVM repose principalement sur les aspects suivants :

Preuves de fraude

En cas de litige, les validateurs peuvent contester les déclarations incorrectes du proposant grâce aux preuves de fraude. Ce mécanisme est similaire aux Rollups Optimistes et ne nécessite pas de modifier les règles de consensus de Bitcoin.

Protocole de défi-réponse

BitVM utilise un protocole de challenge-response, où les proposants et les validateurs signent une série de transactions à l'avance pendant la phase de configuration du protocole. Ces transactions sont utilisées pour résoudre les problèmes lorsqu'un litige survient.

Calcul hors chaîne avec vérification sur chaîne

BitVM permet d'exécuter des calculs complexes hors chaîne, tandis que la vérification et la résolution n'interviennent que sur la chaîne en cas de litige. Cette approche réduit la consommation de ressources en chaîne tout en maintenant l'intégrité et la sécurité de la blockchain Bitcoin.

Mécanisme de dépôt et de pénalité

Si un proposant fait une déclaration incorrecte, les validateurs peuvent confisquer leur dépôt. Ce mécanisme garantit que les attaquants perdent toujours leur dépôt pour des actions fautives.

Mécanisme de contrat bilatéral

Ce mécanisme offre une meilleure confidentialité sur BitVM et réduit les coûts de transaction, mais par rapport au mécanisme multipartite d’EVM, son universalité est quelque peu réduite.

Protocole Nostr

Qu'est-ce que le protocole Nostr

Nostr signifie "Notes et autres trucs transmis par relais", ce qui indique qu'il s'agit d'un protocole de transmission impliquant des relais, suggérant qu'il ne s'agit pas d'un protocole de transmission pair à pair (P2P). Selon le code GitHubmettre à jour les enregistrements, ce projet a été lancé en novembre 2020. Le protocole vise à créer le protocole ouvert le plus simple pour un réseau social mondial résistant à la censure. Il s'agit d'un protocole social décentralisé qui permet aux utilisateurs de créer, publier et s'abonner à tout type de contenu sans contrôle ni intervention de la part de plates-formes centralisées ou d'institutions. Nostr s'inspire de Bitcoin et du Lightning Network, en utilisant des mécanismes cryptographiques et de consensus similaires, ainsi qu'une structure de données basée sur des événements connue sous le nom de réseau Nostr.

Composants du protocole Nostr

Paire de clés publique et privée

Une paire de clés publique et privée constitue un compte Nostr. Contrairement au système traditionnel de nom d'utilisateur et de mot de passe, les comptes Nostr utilisent un système de clé publique et privée similaire aux cryptomonnaies. Pour simplifier, la clé publique peut être considérée comme le nom d'utilisateur, et la clé privée comme le mot de passe. Il est important de noter qu'une fois la clé privée perdue, elle ne peut pas être réinitialisée comme un mot de passe. Les clés publiques sont préfixées par npub1, et les clés privées par nsec1. Il est crucial de veiller à la conservation sécurisée de ces clés, car elles ne peuvent pas être récupérées en cas de perte.

Client

Nostr est un protocole pour l'envoi d'informations sur Internet, nécessitant un logiciel client pour l'utilisation. Les clients peuvent être des pages Web, des logiciels de bureau ou des applications mobiles. Les clients lisent des informations à partir de relais et envoient des données nouvellement générées à des relais pour que d'autres clients les lisent. Les informations comprennent des signatures pour garantir que les données sont envoyées par l'expéditeur authentique. Le client utilise la clé privée pour créer des signatures. Lors de l'utilisation d'un client de bureau ou mobile pour la première fois, la clé privée doit être stockée en elle. La clé publique peut être obtenue à partir de la clé privée. Pour les clients Web, il n'est pas recommandé de sauvegarder directement la clé privée en eux ; il est préférable d'utiliser un plugin pour sauvegarder la clé privée.

Relais

Les relais peuvent être compris comme les serveurs backend du protocole Nostr. Les clients Nostr envoient des informations aux relais, qui peuvent (ou non) stocker les informations et les diffuser à tous les clients connectés. Il est important de noter que les relais ne sont pas constants ; ils peuvent changer significativement avec le temps. Le protocole Nostr repose sur les relais pour stocker et récupérer des données. Si un utilisateur rencontre des vitesses lentes du client, cela peut être dû à la lenteur du relais connecté, et il pourrait envisager d'ajouter d'autres relais.

NIPs

Les NIP (Nostr Implementation Possibilities) sont des normes utilisées pour réguler les relais compatibles avec Nostr et les logiciels clients, spécifiant ce qui doit, devrait ou pourrait être implémenté. « NIP » fait référence à des documents de référence décrivant le fonctionnement du protocole Nostr. Nostr est un protocole décentralisé, non monopolisé par une entité centralisée quelconque (comme Twitter), ce qui signifie que son orientation de développement dépend de tous les participants. Nous pouvons proposer et plaider pour des changements et donner des retours sur les idées des autres. En tant que membres actifs de la communauté du protocole, chacun a son mot à dire dans l'orientation future du développement du réseau Nostr. Les NIP dans le code source principal ont été approuvés et de nouvelles idées peuvent être ajoutées via des demandes de tirage.

Les principaux NIP incluent:

• NIP-04: Chiffrement des messages, utilisant l'algorithme secp256k1 pour l'échange de clés Diffie-Hellman, permettant le chiffrement de bout en bout.

• NIP-05 : Mappe les clés publiques aux noms de domaine pour un rappel facile, comme la mise en correspondance de la clé publique de l'auteur avec le @NomandJamesdomaine.

• NIP-06: Phrases mnémoniques, similaires à celles utilisées dans les portefeuilles de cryptomonnaie.

• NIP-13 : Preuve de travail. Ce concept précède Bitcoin et est largement utilisé dans les couches de consensus POW de la blockchain et le protocole de chuchotement d'Ethereum. Il consiste à effectuer une preuve de travail computationnellement intensive avant d'envoyer un message, que le serveur relais récepteur vérifie. Fournir cette preuve signifie dépenser de la puissance de calcul, élevant le seuil pour le spam des relais avec des messages indésirables.

• NIP-22: Horodatage des messages. Informer les serveurs relais de l'heure à laquelle un message a été créé, permettant aux relais d'accepter sélectivement les messages. Les horodatages peuvent être définis pour le passé ou le futur.

• NIP-40: Heure d'expiration. Informer les serveurs relais de la date d'expiration d'un message afin qu'il puisse être supprimé.

• NIP-57: Liens de pourboire du réseau Lightning.

• NIP-65: Liste recommandée des services de relais.

Les événements sont les seuls Objetstructure sur Nostr. Chaque événement a un aimablepour indiquer le type d'événement (quelle action l'utilisateur a prise ou quelles informations il a reçues).

Opération du protocole Nostr

Le protocole Nostr fonctionne à travers des relais. Ces relais permettent aux utilisateurs sur le même relais d'envoyer des fichiers Json entre eux.

Pour aider à comprendre cela, considérez un diagramme simplifié :

Le diagramme comprend 3 relais et 3 clients, chaque client utilisant une plateforme différente.

Dans ce diagramme :

• Bob peut voir tous les tweets d’Alice mais aucun de ceux de Mary (Bob n’est même pas au courant de l’existence de Mary).

• Alice peut voir tous les tweets de Bob mais aucun de Mary (Alice ignore également l'existence de Mary).

• Mary peut voir les tweets de Bob et Alice car elle n'écrit des données que sur Relay 3 mais peut lire des données depuis Relay 2 (qui contient les données de Bob et Alice).

Plongée profonde dans les contrats Nostr

Étant donné le protocole Nostr comme un protocole ouvert très léger, il fournit un ensemble de spécifications de protocole pour les plates-formes de médias sociaux décentralisées. Effectuons une analyse de code simple du protocole :

La base du protocole est un serveur WebSocket (connu sous le nom de nostr-relay), qui traite et stocke une structure de données très simple appelée un Événement. Il est affiché comme suit:

{  "id": "<32 octets sha256 des données d'événement sérialisées>",  "pubkey": "<32 octets clé publique encodée en hexadécimal du créateur d'événement>",  "created_at": "<horodatage Unix en secondes>",  "kind": "<entier>",  "tags": [    ["e", "<32 octets hexadécimal de l'identifiant d'un autre événement>", "<URL de relais recommandée>"],    ["p", "<32 octets hexadécimal de la clé>", "<URL de relais recommandée>"],    ... // d'autres types de balises peuvent être inclus ultérieurement  ],  "content": "<chaîne arbitraire>",  "sig": "<signature de 64 octets du hachage sha256 des données d'événement sérialisées, identique au champ 'id'>"}

Les événements sont toujours signés (en utilisant des signatures de type Schnorr) et contiennent des données structurées qui peuvent avoir des significations sémantiques différentes. Les clés publiques de type XOnlyPubkeys définies dans le BIP340 (actuellement utilisées avec Bitcoin Taproot) sont utilisées comme "identités" tout au long du protocole.

Le client nostr est une application qui peut communiquer avec le relais nostr et peut utiliser des abonnés pour souscrire à tout ensemble d'événements.

Les filtres représentent l'ensemble de tous les événements Nostr auxquels le client s'intéresse.

Les clients n'ont pas besoin de s'inscrire ou de créer des comptes, car le client utilise la clé publique de l'utilisateur pour l'identification. Chaque fois que le client se connecte au relais, il soumet le filtre d'abonnement de l'utilisateur, et tant qu'ils sont connectés, le relais diffusera les "événements d'intérêt" au client.

Les relais peuvent mettre en cache les abonnements des clients, mais cela n'est pas obligatoire. Les clients doivent gérer tout du "côté client", tandis que les relais peuvent être aussi stupides qu'un caillou.

Les clients ne parlent pas entre eux. Mais les relais peuvent le faire. Cela permet aux relais de récupérer des données pour le client qu'il n'a pas, et les clients peuvent s'abonner à des événements en dehors du relais auquel ils sont connectés.

À première vue, cela donne l'impression que Nostr en tant que protocole est inutile (pourquoi ne pas simplement signer et rejeter le JSON brut et laisser le client le comprendre?), mais un examen plus approfondi révèle que le modèle "serveur idiot, client intelligent" peut découvrir certains avantages significatifs dans l'ingénierie de la conception de protocoles décentralisés.

Entièrement décentralisé comme une caractéristique clé de Nostr

Nostr sert de couche de protocole pour les applications sociales, transférant des Notes et d'autres Choses via des Relais sans compter sur des serveurs centralisés. Sa pleine décentralisation permet à n'importe quelle application d'accéder librement à travers un réseau distribué, offrant une plateforme sociale ouverte et sans permission. Par conséquent, Nostr n'offre pas de produit directement aux consommateurs, mais se concentre sur la mise en œuvre de l'infrastructure sociale nécessaire au niveau du protocole. La capacité de productisation est fournie par des applications tierces, et les utilisateurs de différentes applications peuvent interagir socialement les uns avec les autres.

L'avantage de Nostr réside dans sa fourniture d'un réseau social vraiment libre et ouvert, non affecté et non menacé par un pouvoir centralisé ou des intérêts. Les utilisateurs peuvent librement exprimer leurs opinions et croyances sans craindre la censure, les interdictions ou la déplateformisation ; les créateurs de contenu peuvent librement définir leurs modèles d'incitation sans craindre d'être privés de revenus ou de faire face à une concurrence déloyale. Les utilisateurs de Nostr peuvent également choisir librement leurs cercles sociaux sans craindre la manipulation, la désinformation ou l'atteinte à la vie privée.

Nostr diffère considérablement des médias sociaux traditionnels et présente les caractéristiques et avantages suivants :

Décentralisation : Nostr ne dépend d'aucun serveur ou plateforme centralisée, mais utilise plutôt le réseau Bitcoin pour la transmission et le stockage des informations. Cela garantit que les utilisateurs n'ont pas à craindre le vol de données, la censure ou la suppression, et ne sont pas soumis aux règles ou politiques de tiers.

Autonomie : Nostr permet aux utilisateurs de contrôler leurs propres données et identités. Les utilisateurs peuvent librement choisir qui ils veulent suivre et en qui ils veulent avoir confiance, et exprimer leurs points de vue et idées sans craindre d'être bannis, bloqués ou déclassés, et sans subir d'interférences publicitaires ou de contenu recommandé. La vérifiabilité des utilisateurs spécifiques facilite également l'identification du spam et du contenu généré par des bots.

Ouverture : Nostr est un protocole ouvert auquel tout le monde peut participer et contribuer. Les utilisateurs peuvent développer et utiliser différents clients, ainsi que construire et exécuter leurs propres nœuds (serveurs pouvant transférer et stocker des informations Nostr). Les utilisateurs peuvent également créer et utiliser différents types et balises, qui sont des métadonnées utilisées pour différencier et catégoriser les informations Nostr. La simplicité et la flexibilitéÉvénementLe format prend en charge divers types de publication : publications sur les médias sociaux, contenus longs, contenus riches, commerce électronique, etc. De plus, l'intégration de Nostr avec le Lightning Network a facilité un nouveau modèle économique plus équitable basé sur la valeur.

Préoccupations de sécurité du protocole Nostr

Gestion des clés privées

Le protocole Nostr utilise des paires de clés publique-privée pour les comptes, obligeant les utilisateurs à gérer correctement leurs clés privées. Une fois perdue, la clé privée ne peut pas être récupérée. Cela peut poser un défi pour la plupart des utilisateurs, qui pourraient manquer de connaissances techniques et d'expérience pour gérer en toute sécurité les clés privées.

Sélection du relais

Dans le protocole Nostr, les utilisateurs doivent choisir et vérifier les relais par eux-mêmes. Choisir un relais peu fiable ou malveillant pourrait entraîner la divulgation, la manipulation ou la suppression de leurs informations.

Diffusion d'informations

Dans le protocole Nostr, les informations envoyées par les utilisateurs ne se propagent pas à travers plusieurs relais. Cela signifie que si leurs informations ne sont pas reçues et stockées par un nombre suffisant de relais, elles pourraient être perdues ou non vues par d'autres utilisateurs, aggravant le problème des silos d'informations.

Stockage d'informations discrétionnaires des relais

Les relais du protocole Nostr peuvent décider librement de recevoir et de stocker les informations des utilisateurs. Cela peut conduire certains relais à choisir de ne recevoir et de stocker que des informations qu’ils jugent précieuses ou conformes à leurs intérêts, tout en ignorant ou en rejetant d’autres informations.

Extensions de protocole malveillantes

Alors que le protocole Nostr définit certains types d'événements de base et fonctionnalités, il permet également aux clients et relais de mettre en œuvre sélectivement des fonctionnalités supplémentaires. Cela pourrait entraîner la mise en œuvre de fonctionnalités non sécurisées ou malveillantes par certains clients et relais, affectant la sécurité et la vie privée des utilisateurs.

Traitement de l'information

En raison de l'absence d'une couche de consensus dans le protocole Nostr, certains relais ne traitent pas les messages avec une différence significative de timestamps et de temps UNIX, laissant ainsi la possibilité aux clients d'exploiter cette disparité pour falsifier les messages.

Aperçu de l'écosystème Nostr

Jack Dorsey, co-fondateur de Twitter et grand partisan du protocole Nostr, a fait un don de 14,17 Bitcoins (environ 245 000 $) pour soutenir son développement en décembre 2022. Son profil X affiche clairement son adresse Nostr personnelle, indiquant son attachement au protocole.

Damus⚡️: Principales applications du protocole Nostr

X：https://twitter.com/damusapp

Damus est une application sociale qui prend en charge le pourboire Bitcoin via le Lightning Network, remplaçant le commun 'J'aime' ou le pouce levé par un pourboire. Les faibles frais de transaction du Lightning Network rendent le pourboire pratiquement gratuit. Outre Damus, les applications du protocole Nostr comprennent l'outil de communication Anigma, l'outil de partage de texte Sendtr et le jeu d'échecs en ligne Jeste, entre autres.

Principal partenaire média du protocole Nostr: TGFB

TGFB est une plate-forme d’éducation chrétienne Bitcoin visant à éduquer et à équiper les chrétiens pour qu’ils comprennent Bitcoin et l’utilisent pour glorifier Dieu et bénéficier à l’humanité. Une partie importante de son contenu est consacrée à la promotion du protocole Nostr par le biais de podcasts animés par Jon et Jordan, explorant les implications du protocole d’un point de vue chrétien. La combinaison du christianisme, largement connu aux États-Unis et dans le monde, de l’ETF Bitcoin approuvé par la SEC et du protocole Nostr basé sur la vaste base d’utilisateurs du Lightning Network, devrait favoriser de manière significative l’adoption et le soutien du protocole Nostr.

Protocoles dérivés Nostr

Actifs Nostr + Taproot

Le protocole Nostr Assets est un protocole open-source qui intègre les actifs Taproot et les paiements Bitcoin natifs (libellés en Satoshis) dans l’écosystème Nostr, prenant en charge les interactions avec d’autres protocoles de paiement, notamment le Lightning Network et les actifs Taproot.

Une fois les actifs introduits, ils peuvent être envoyés et reçus à l’aide des clés publiques et privées du protocole Nostr, le règlement et la sécurité dépendant toujours du Lightning Network. Le protocole Nostr Assets, bien que construit sur la technologie de Nostr, est un protocole distinct qui facilite les fonctions transactionnelles de base par le biais des messages Nostr.

Le service de garde complet du protocole Nostr Assets implique que les utilisateurs déposent leur Bitcoin ou d'autres actifs dans un portefeuille contrôlé par le protocole, puis exécutent des instructions de déploiement de jetons, de frappe et de transfert via des messages Nostr.

Cependant, le service de garde complet est controversé en raison des risques potentiels pour la sécurité. Les utilisateurs ne peuvent pas contrôler entièrement leurs actifs, et en cas de violation de la plateforme ou d’escroquerie à la sortie, ils pourraient perdre tous leurs actifs.

De plus, suite à son lancement le 30 octobre, Nostr a connu une forte demande de dépôts d'actifs, entraînant une maintenance fréquente du site et des arrêts, suscitant des inquiétudes quant à l'expérience de l'équipe et à la fiabilité du projet. Le 8 novembre, le protocole d'actifs Nostr a officiellement répondu à un commentaire en chinois sur un tweet, certains utilisateurs remettant toujours en question la crédibilité du projet. La communauté Nostr a exprimé une forte opposition au jeton associé à ce protocole d'extension.

Nostr + Inscription

Noscription est un protocole de token expérimental basé sur Nostr, permettant aux utilisateurs de créer et d’échanger des tokens de type brc-20, distincts des tokens Taproot assets.

Analyse comparative

Implémentation du protocole

• BitVM exige des capacités de calcul extrêmement élevées et n'existe actuellement que dans la théorie. En termes de mise en œuvre commerciale, RGB a un avantage significatif avec de nombreuses applications déjà en cours d'utilisation. (L'organisation technique derrière RGB, LNP/BP, compte peu de développeurs et est à but non lucratif, ce qui ralentit les progrès du développement). Nostr, entravé par les goulots d'étranglement courants de SocialFi, a également échoué à faire progresser davantage l'écosystème d'application de son protocole.

  Protection de la vie privée

• Les deux RGB et BitVM effectuent des calculs hors chaîne, mais le protocole RGB garantit que les tiers ne peuvent pas suivre l'historique des actifs RGB sur la blockchain. Ce n'est que lorsque qu'un utilisateur reçoit un actif qu'il apprend son histoire, une fonctionnalité impossible à réaliser par BitVM. Le protocole Nostr, en tant que protocole social, présente un degré élevé d'incertitude dans la transmission d'informations, ce qui peut entraîner des fuites d'informations, des blocages, des pertes et des manipulations malveillantes en raison de vulnérabilités.

  Compatibilité native BTC

• RGB et BitVM ne nécessitent pas de modifications du protocole Bitcoin; Nostr est construit sur le réseau Lightning natif, offrant une compatibilité native relativement bonne et une expérience de développement fluide.

  Sécurité du protocole

• Le protocole RGB fonctionne hors chaîne dans un environnement sandbox, garantissant la sécurité des données. Son système de facturation garantit également la sécurité des données d'un point de vue conception. En termes d'interaction avec BTC, il utilise un mécanisme similaire au Lightning Network pour l'émission d'actifs.

• BitVM utilise un modèle Rollup, exécutant des données hors chaîne également. Les caractéristiques de la machine virtuelle, combinées à des preuves de fraude et un modèle de défi-réponse, garantissent la sécurité de BitVM.

• Nostr utilise un modèle de relais, où la conception ingénieuse de la transmission d'informations entre les relais et les algorithmes de chiffrement garantit la sécurité des informations au sein du protocole Nostr.

Dans l'industrie Web3, il n'y avait pas de laboratoire spécifiquement axé sur la sécurité de l'écosystème Bitcoin avant la création du BTC Security Lab, comblant ainsi ce vide en fournissant un soutien professionnel en matière de sécurité et de recherche pour l'écosystème Bitcoin. ScaleBit et BiHelix visent à prendre la tête de la course en matière de sécurité de l'écosystème Bitcoin, établissant des normes de sécurité pour l'industrie et favorisant le développement sain de l'écosystème.

Écosystème et Commercialisation

• En tant que protocole social, Nostr dépasse à la fois BitVM et RGB en termes de base d'utilisateurs et de popularité du trafic, ce qui rend son expansion de protocole d'écosystème et sa commercialisation d'application plus complètes que les deux autres.

• Le protocole RGB existe depuis un certain temps, de nombreux projets attendent actuellement la sortie de RGB V0.11.

• BitVM n'a publié son livre blanc que quelques mois auparavant, et son écosystème est encore en développement.

L'avenir de ces trois protocoles devrait engendrer de nombreux Dapps dans les domaines de SocialFi, GameFi et DeFi, apportant une nouvelle vague de popularité à l'écosystème BTC.

Un merci spécial à Ausdin.eth, 0xLayman, Echo, Venus pour leurs contributions à ce rapport.

Avertissement：

1. Cet article est repris à partir de[chaincatcher]. Tous les droits d'auteur appartiennent à l'auteur original [浙大链协，BiHelix，ScaleBit & BTC Security Lab]. If there are objections to this reprint, please contact thePorte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.