Nostr 2.0 peut être en mesure de s'appuyer sur Bitcoin en tant que couche 2, fournissant un stockage de données hors chaîne sécurisé, tout comme le Lightning Network fournit des paiements hors chaîne instantanés en tant que couche 2.
Cet article explique comment le relais Nostr synchronise ses données tout en conservant sa nature légère, permettant aux utilisateurs de supprimer sélectivement des données, qui ne sont pas disponibles dans les blockchains de couche 1. Dans le même temps, par rapport au stockage de grandes quantités de données dans la blockchain Bitcoin, en raison de la capacité et de la vitesse limitées des blocs Bitcoin, il peut être moins coûteux de stocker des données à l'aide de relais Nostr.
La conception informatique simple suivante améliore les propriétés de distribution des réseaux Nostr sous le critère du théorème CAP standardisé. CAP signifie cohérence, disponibilité et tolérance de partition
**Le relais Nostr ne sait pas quand un fichier de configuration est incomplet, le relais manque de cohérence (C dans le théorème CAP). **
Le relais manque de cohérence (C dans le théorème CAP)
La cohérence signifie que les bases de données synchronisées sur chaque ordinateur sont les mêmes. Les relais Nostr ne peuvent pas effectuer de synchronisation avec minimisation de la confiance de la même manière que les blockchains synchronisent leurs données bloc par bloc. Contrairement aux nœuds complets Bitcoin, la base de données stockée par le relais Nostr est généralement incomplète. En plus de demander aveuglément tous les messages signés par un utilisateur spécifique, le relais Nostr ne peut pas découvrir les données manquantes.
Problèmes de cohérence/synchronisation de Nostr :
Si deux utilisateurs téléchargent leurs messages respectifs sur différents relais Nostr, ces deux utilisateurs peuvent ne pas être en mesure de voir les messages de l'autre car Nostr n'est pas comme une blockchain. Dans la blockchain, chaque fois qu'il y a un nouvel enregistrement, tous les nœuds complets synchroniseront la blockchain. Tous les nœuds complets ajouteront ces données en tant que bloc à leur blockchain en même temps. Chaque nœud complet de la blockchain Bitcoin possède exactement la même blockchain.
Si nous voulons que les utilisateurs de Nostr puissent toujours voir les messages des autres, alors tous les relais Nostr ont besoin d'un moyen d'identifier les données manquantes dans les profils d'utilisateurs afin qu'ils puissent demander les pièces manquantes à d'autres relais ou utilisateurs Nostr.
Utilisez les hachages hebdomadaires de la racine Merkle et de l'arbre complet sur la chaîne pour synchroniser le relais Nostr
Environ une fois par semaine, les utilisateurs peuvent organiser tous leurs messages dans un arbre Merkle.
Chaque feuille de l'arbre Merkle contient le hachage d'une publication, tout comme chaque feuille de Bitcoin contient le hachage d'une transaction.
Une fois qu'un utilisateur a organisé l'intégralité de son profil dans un arbre Merkle, il publiera la racine Merkle dans OP_RETURN on-chain, sous une transaction Bitcoin normale. C'est pourquoi Nostr 2.0 ne nécessite pas de hard fork de la blockchain pour fonctionner. OP_RETURN est une section sous une transaction Bitcoin qui permet d'ajouter une petite note avant la signature de l'expéditeur.
De plus, l'utilisateur hachera l'arbre entier et le téléchargera dans la chaîne avec la racine Merkle (dans OP_RETURN). La racine Merkle n'est que le hachage de la branche supérieure, pas l'arbre entier. Le hachage de l'arborescence entière est essentiel pour que les utilisateurs et les relayeurs puissent détecter si des données de profil sont manquantes.
Pour obtenir un hachage de l'arbre entier, placez la racine Merkle à la racine du fichier texte. Ensuite, placez la branche Merkle sur la ligne sous la racine. Ensuite, placez les feuilles de Merkle sur la rangée sous la branche. Une fois que l'arborescence est disposée comme décrit, hachez-la en une seule fois. Vous trouverez ci-dessous un exemple de hachage d'arbre entier de ce à quoi ressemblerait un hachage d'arbre entier pour l'arbre de Merkle illustré ci-dessus. Hachage de l'arbre entier (hachage de toutes les données de l'arbre Merkle à la fois)
Les hachages Merkle de la racine et de l'arbre entier fournissent deux fonctions clés :
Les racines Merkle permettent aux utilisateurs et aux relais de télécharger une partie d'un fichier de configuration à la fois, comme de pouvoir télécharger une transaction sans avoir à télécharger le bloc entier.
Le hachage de l'arborescence complète permet aux utilisateurs et aux relayeurs de savoir si leurs fichiers de configuration stockés sont incomplets. Contrairement à une racine Merkle, le hachage de l'arbre entier ne correspondra que si vous avez tous les bits de l'arbre Merkle.
Cette méthode peu coûteuse peut être utilisée pour mettre à jour l'intégralité du fichier de configuration à une fréquence hebdomadaire ou définie par l'utilisateur. Nostr fonctionnera toujours comme il le fait actuellement, mais les utilisateurs peuvent occasionnellement payer quelques sats pour synchroniser leurs données entre les relais Nostr s'ils veulent que leurs messages soient vus par tous les utilisateurs.
Les utilisateurs et les relais peuvent télécharger des messages pour une branche à la fois. Après chaque branche, ils hachent cette branche avec une autre branche la plus proche de la racine Merkle pour vérifier si elle correspond à la racine Merkle sur la chaîne (similaire à SPV). Si ces branches se hachent ensemble pour correspondre à la racine Merkle, alors ils sauront que cette branche fait partie du profil utilisateur, même s'ils n'ont pas encore le profil utilisateur complet. Les utilisateurs peuvent télécharger différentes branches du même fichier de configuration à partir de nombreux troncs Nostr différents, tout en vérifiant la validité de chaque branche et en s'assurant que le fichier de configuration téléchargé est complet.
Le téléchargement de fourches une par une empêche les attaques par retard qui pourraient faire tomber de nombreux réseaux distribués, c'est pourquoi les racines et les fourches de Merkle sont utilisées dans le livre blanc Bitcoin pour protéger les portefeuilles légers SPV.
**Pourquoi une racine de Merkle ne peut-elle pas fonctionner comme un hachage d'arbre entier ? **
** Si les relais Nostr ne dépendaient que de la racine Merkle, ils ne pourraient pas savoir quand l'arbre Merkle était complet, puisque chaque paire de branches les plus proches de la racine Merkle se hacherait dans la même racine Merkle. **
Pour s'assurer que le profil de l'utilisateur est complet, le relais ou l'utilisateur hachera l'intégralité de son arbre Merkle mis à jour et vérifiera qu'il correspond à l'ensemble du hachage de l'arbre sur la chaîne. Si tous les hachages de l'arborescence correspondent, les données utilisateur sont complètes. Si le hachage de l'arbre entier ne correspond pas, un relais ou un utilisateur peut indiquer aux autres relais son dernier numéro de feuille et demander la branche manquante jusqu'à ce que le hachage de l'arbre entier corresponde. Afin de garder une trace de toutes les nouvelles racines Merkle ajoutées chaque semaine environ, les relais Nostr doivent devenir des nœuds complets Bitcoin. Les relais Nostr 2.0 sont payés indirectement pour stocker la blockchain Bitcoin tout en améliorant la sécurité de Bitcoin et Nostr.
Limites du stockage Nostr : règle empirique de l'utilisateur
Étant donné que les relais ont le droit de choisir quoi stocker, contrairement aux nœuds complets Bitcoin, les relais Nostr peuvent perdre certaines données utilisateur. Par conséquent, les utilisateurs ne doivent stocker des données sur le relais Nostr que si les utilisateurs peuvent effectuer des sauvegardes localement. Le service auto-hébergé de Web5 permet aux utilisateurs de synchroniser les sauvegardes sur tous leurs appareils locaux, ce qui réduira le risque pour les utilisateurs préoccupés par l'utilisation de Nostr. En fin de compte, seule la blockchain est l'endroit où les données sont vraiment immuables. Cela dit, Nostr est une solution hybride assez sûre qui fonctionnera toujours bien pour de nombreuses applications. Les échanges sont listés ci-dessous :
Trois niveaux de minimisation de la confiance
Niveau 1 : Stockage de données immuable et coûteux, extrêmement difficile à censurer. (Les blocs de la chaîne synchronisent tous les nœuds complets Bitcoin)
Niveau 2 : Stockage de données modifiable et bon marché, censure modérément difficile. (arbre Merkle hors chaîne et hachage en chaîne, relais Nostr synchrone à la demande)
Stockage de données local synchronisé avec tous les appareils locaux, facile à censurer. (centralisation locale)
Compromis fondamentaux entre les blockchains basées sur le consensus de Nakamoto et Nostr
** Plus il y a de relais Nostr qui stockent des données pour une adresse particulière, plus il est difficile de censurer ces données. Cela signifie que les données populaires hébergées par de nombreux relais Nostr peuvent être plus difficiles à censurer que les données impopulaires qui sont rarement téléchargées. **
**D'autre part, la blockchain du consensus Nakamoto empêche la censure basée sur l'âge des données. Plus les données existent dans la blockchain, plus il est difficile de les supprimer en utilisant une attaque à 51 %. **
Comme nous pouvons vérifier que certaines fourches appartiennent à des utilisateurs spécifiques, les relais Nostr peuvent être payés chaque fois qu'ils transmettent une petite donnée à un utilisateur. Pour ce faire, l'utilisateur doit télécharger la tête de la blockchain (comme dans SPV) pour pouvoir exécuter les fonctions typiques d'un portefeuille léger. L'utilisateur tirera parti de la fonctionnalité SPV du portefeuille léger pour récupérer une transaction spécifique de la chaîne, qui inclura la racine Merkle du profil utilisateur et l'intégralité du hachage de l'arborescence dans son OP_RETURN. Les utilisateurs peuvent désormais payer le relais pour télécharger le profil de cet utilisateur branche par branche et vérifier chaque branche en les hachant pour qu'elles correspondent à la racine Merkle sur la chaîne.
Afin d'envoyer des sats (la plus petite unité de Bitcoin) au relais Nostr en échange de la fourniture de données, nous utilisons le design ZKCP (Zero-Knowledge Conditional Payments) de Gregory Maxwell (célèbre développeur Bitcoin Core) [1] Une version évoluée de ZKCSP : preuve de récupérabilité [2] Combiné avec Lightning Network.
Selon la description du livre blanc ZKCSP :
"... pas besoin d'un tiers de confiance... Nous avons également implémenté le protocole ZKCSP pour le cas de preuve de récupérabilité, où le client paie le serveur pour avoir la preuve que les données du client ont été correctement stockées sur le serveur." [2]
Un utilisateur initie un contrat intelligent Lightning avec plusieurs financiers.
L'utilisateur envoie des demandes aux financiers environnants. Le financier signe la demande.
Les utilisateurs envoient des demandes signées par des financiers directement aux relais Nostr connectés à ces financiers.
Les utilisateurs lancent désormais des constructions ZKCSP pour s'assurer que les relais Nostr ne sont payés par les financiers qu'après la livraison des données correctement demandées.
Une fois l'étape 3 effectuée, l'utilisateur apportera des modifications en plus de la demande originale signée par le financier avant de lancer la construction du ZKCSP à l'étape 4. L'utilisateur ajoutera un supplément à la demande d'origine, en précisant le montant à déduire des soldes de l'utilisateur et du financier (ils doivent être du même montant, plus les frais du financier), que l'utilisateur ajoutera ensuite au message d'origine. contenu à signer.
** Si l'utilisateur spécifie d'envoyer plus de sats qu'il n'en possède, ou plus que le financier n'a gelé sur ce relais Nostr, alors le relais Nostr rejettera la demande car le relais ne pourra pas être payé. **
De cette façon, les utilisateurs peuvent se connecter avec de nombreux relais Nostr tout en gelant leurs fonds avec seulement quelques bailleurs de fonds. Une approche similaire pourrait être adoptée avec le Lightning Network, où les financiers à confiance minimisée sont des intermédiaires sans autorisation entre les utilisateurs et les commerçants. Les sauts éclair P2P normaux sont également disponibles dans Nostr 2.0, mais cela peut être utile si le routage et l'équilibrage des canaux échouent fréquemment.
Liste blanche déverrouiller le relais Nostr payant
Les relais Nostr peuvent mettre en liste blanche certaines clés s'ils souhaitent stocker des données consultées par tous ces utilisateurs. Si les relais Nostr ne sont pas en mesure de mettre sur liste blanche les utilisateurs souhaitant stocker des données, ils stockeront toutes les données qui leur seront envoyées. Si les utilisateurs peuvent toujours envoyer des données aux relais gratuitement, alors les utilisateurs n'auront jamais besoin de payer pour les relais Nostr. Nostr ne peut proposer des options payantes que si le relais a la possibilité de refuser de stocker des données qui ne peuvent pas être payées. Les relais gratuits existent toujours, mais l'option pour les relais payants n'existe pas actuellement.
Au lieu d'essayer de stocker gratuitement toutes les données Nostr, un relais Nostr payant peut utiliser une liste blanche pour stocker de manière sélective toutes les données que ses utilisateurs payants consultent quotidiennement. Certains relais Nostr continueront à fonctionner sur un modèle gratuit, mais à plus grande échelle, ce n'est pas durable car la plupart des relais gratuits ne sont que des passionnés. La liste blanche (même si nous pouvions attribuer en toute sécurité une clé publique à chaque profil Nostr) donnant au relais Nostr la possibilité de décider quelles données stocker ne serait pas possible.
Une clé publique par profil déverrouille la fonction de liste blanche : l'adresse Bitcoin devient votre clé publique Nostr.
Ce système permet enfin d'attribuer une clé publique à chaque fichier de configuration.
Il n'y a aucun avantage à ce que les utilisateurs créent de nouvelles clés publiques pour chaque publication... car elles sont toutes associées à leurs profils ! Ce n'est pas la même chose qu'une adresse Bitcoin. Contrairement à Bitcoin, le fait que les utilisateurs disposent de plusieurs clés publiques dans la même application n'améliore pas la confidentialité.
**La clé publique du profil Nostr doit correspondre à la clé publique de la transaction Bitcoin qui contient le hachage hebdomadaire (la racine Merkle de tous les messages de l'utilisateur et le hachage de l'arbre entier). Contrairement aux utilisateurs de Nostr qui utilisent les signatures Schnorr, ils devront utiliser un portefeuille Bitcoin (portefeuille mobile/portefeuille léger ou nœud complet) pour signer. **
La beauté de ceci est que chaque compte Nostr sera représenté par son adresse Bitcoin, ** ce qui signifie que les utilisateurs peuvent envoyer des paiements directement aux comptes Nostr sans demander deux clés publiques différentes. Cela réduit le coût cognitif des nouveaux utilisateurs du système. Au lieu d'utiliser des noms d'utilisateur, les utilisateurs doivent toujours s'envoyer des clés publiques ou DNS pour se trouver sur Nostr. **
Si d'autres applications Nostr utilisent des clés publiques différentes, elles peuvent toujours être attachées à la même identité décentralisée (DID) - de cette façon, la façon dont votre compte est identifié reste cohérente entre les applications. Cependant, cette règle de consensus Nostr limitera l'utilisation d'une seule clé publique par profil sur chaque application Nostr.
DHT agit comme un classement pour la découverte par les pairs.
Les relais peuvent utiliser une table de hachage distribuée (DHT) pour trouver d'autres relais. Les relais peuvent partager leur liste blanche dans une table de hachage distribuée en répertoriant la clé publique où les données sont stockées. De cette façon, les relais avec des fourches de données manquantes pour une certaine clé publique peuvent scanner le DHT et se connecter directement aux adresses IP d'autres relais prétendant stocker ces fourches manquantes. Les relais peuvent alors télécharger les branches manquantes directement à partir de ces relais Nostr.
Les relais pourront également trouver les relais les plus actifs en vérifiant le nombre de transactions ZKCSP précédentes que ces relais ont résolues sur la chaîne - récentes et de tous les temps. Dans ce système, tous les relais Nostr deviennent des nœuds complets, de sorte que l'audit des transactions précédentes des autres relais sera indolore. Cela rendrait coûteux l'instauration de la confiance, car les transactions en chaîne nécessitent toujours des frais de transaction. Si un relais Nostr ouvre de nombreux canaux pour établir la confiance avec lui-même afin de gagner la confiance des autres relais, il devra payer beaucoup de frais de transaction pour maintenir la fausse réputation chaque semaine. Une fois que l'attaquant n'a pas réussi à fournir la branche manquante, le délai d'attente entraînera la déconnexion du relais - il ne s'agit donc que d'une attaque temporaire et coûteuse (tout comme une attaque à 51 % est une attaque temporaire et coûteuse).
Le DHT n'est pas aussi anonyme que l'exploitation minière, car la clé publique de chaque relais Nostr sera répertoriée à côté de l'adresse IP dans le DHT, mais cela évitera aux relais d'envoyer aveuglément des requêtes sur le réseau - à une échelle suffisamment grande. surchargera le réseau. Les relais Nostr à la recherche de plus de confidentialité peuvent utiliser un VPN ou un autre service de protection IP.
Les utilisateurs n'auront pas accès à ce même système de confiance car ils ne sont pas des nœuds complets. Cependant, les utilisateurs peuvent s'y fier.
Les amateurs sont indirectement connectés à des centaines de relais Nostr
Étant donné que les utilisateurs stockent automatiquement tous les en-têtes de bloc dans leurs portefeuilles légers, les utilisateurs peuvent voir qui sont les mineurs les plus actifs. Les mineurs devenant des financiers permettront aux utilisateurs de filtrer les mineurs les plus populaires afin qu'ils n'aient pas à lier aveuglément des fonds à des financiers aléatoires qui n'ont aucune corrélation avec la viabilité du réseau.
**Les financiers (mineurs) n'ont qu'à verrouiller leurs sats avec le relais Nostr, sans transmettre les données elles-mêmes entre les utilisateurs et le relais. ** Le financier (mineur) a juste besoin de signer la demande de l'utilisateur afin que l'utilisateur puisse interagir directement avec tous les relais Nostr auxquels le financier est connecté - 4 étapes pour ZKCSP+Lightning comme ci-dessus.
en conclusion
Le Lightning Network n'existerait pas sans la blockchain de consensus Nakamoto de Bitcoin, car les utilisateurs n'auraient aucun endroit pour stocker leurs preuves groupées de transactions hors chaîne.
Tout comme les utilisateurs regroupent toutes ces transactions Lightning Network et placent de petites preuves dans la blockchain, nous regrouperons toutes les données Nostr et placerons de petites preuves dans la blockchain. De la même manière que le Lightning Network fournit des paiements instantanés à la deuxième couche, Nostr peut être en mesure de fournir un stockage de données à la deuxième couche sans risque de sidechain non sécurisée. **
** Il utilise la même approche que le Lightning Network, avec la blockchain de consensus Nakamoto de Bitcoin sur la première couche et Nostr + ZKCSP Lightning sur la deuxième couche. **
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Nostr2.0 : en tant que couche de stockage de données sous la chaîne Bitcoin Layer 2
Auteur : Colby Serpa Compilateur : DAOrayaki
Nostr 2.0 peut être en mesure de s'appuyer sur Bitcoin en tant que couche 2, fournissant un stockage de données hors chaîne sécurisé, tout comme le Lightning Network fournit des paiements hors chaîne instantanés en tant que couche 2.
Cet article explique comment le relais Nostr synchronise ses données tout en conservant sa nature légère, permettant aux utilisateurs de supprimer sélectivement des données, qui ne sont pas disponibles dans les blockchains de couche 1. Dans le même temps, par rapport au stockage de grandes quantités de données dans la blockchain Bitcoin, en raison de la capacité et de la vitesse limitées des blocs Bitcoin, il peut être moins coûteux de stocker des données à l'aide de relais Nostr.
La conception informatique simple suivante améliore les propriétés de distribution des réseaux Nostr sous le critère du théorème CAP standardisé. CAP signifie cohérence, disponibilité et tolérance de partition
**Le relais Nostr ne sait pas quand un fichier de configuration est incomplet, le relais manque de cohérence (C dans le théorème CAP). **
Le relais manque de cohérence (C dans le théorème CAP)
La cohérence signifie que les bases de données synchronisées sur chaque ordinateur sont les mêmes. Les relais Nostr ne peuvent pas effectuer de synchronisation avec minimisation de la confiance de la même manière que les blockchains synchronisent leurs données bloc par bloc. Contrairement aux nœuds complets Bitcoin, la base de données stockée par le relais Nostr est généralement incomplète. En plus de demander aveuglément tous les messages signés par un utilisateur spécifique, le relais Nostr ne peut pas découvrir les données manquantes.
Problèmes de cohérence/synchronisation de Nostr :
Si deux utilisateurs téléchargent leurs messages respectifs sur différents relais Nostr, ces deux utilisateurs peuvent ne pas être en mesure de voir les messages de l'autre car Nostr n'est pas comme une blockchain. Dans la blockchain, chaque fois qu'il y a un nouvel enregistrement, tous les nœuds complets synchroniseront la blockchain. Tous les nœuds complets ajouteront ces données en tant que bloc à leur blockchain en même temps. Chaque nœud complet de la blockchain Bitcoin possède exactement la même blockchain.
Si nous voulons que les utilisateurs de Nostr puissent toujours voir les messages des autres, alors tous les relais Nostr ont besoin d'un moyen d'identifier les données manquantes dans les profils d'utilisateurs afin qu'ils puissent demander les pièces manquantes à d'autres relais ou utilisateurs Nostr.
Utilisez les hachages hebdomadaires de la racine Merkle et de l'arbre complet sur la chaîne pour synchroniser le relais Nostr
Les hachages Merkle de la racine et de l'arbre entier fournissent deux fonctions clés :
Cette méthode peu coûteuse peut être utilisée pour mettre à jour l'intégralité du fichier de configuration à une fréquence hebdomadaire ou définie par l'utilisateur. Nostr fonctionnera toujours comme il le fait actuellement, mais les utilisateurs peuvent occasionnellement payer quelques sats pour synchroniser leurs données entre les relais Nostr s'ils veulent que leurs messages soient vus par tous les utilisateurs.
Les utilisateurs et les relais peuvent télécharger des messages pour une branche à la fois. Après chaque branche, ils hachent cette branche avec une autre branche la plus proche de la racine Merkle pour vérifier si elle correspond à la racine Merkle sur la chaîne (similaire à SPV). Si ces branches se hachent ensemble pour correspondre à la racine Merkle, alors ils sauront que cette branche fait partie du profil utilisateur, même s'ils n'ont pas encore le profil utilisateur complet. Les utilisateurs peuvent télécharger différentes branches du même fichier de configuration à partir de nombreux troncs Nostr différents, tout en vérifiant la validité de chaque branche et en s'assurant que le fichier de configuration téléchargé est complet.
Le téléchargement de fourches une par une empêche les attaques par retard qui pourraient faire tomber de nombreux réseaux distribués, c'est pourquoi les racines et les fourches de Merkle sont utilisées dans le livre blanc Bitcoin pour protéger les portefeuilles légers SPV.
**Pourquoi une racine de Merkle ne peut-elle pas fonctionner comme un hachage d'arbre entier ? **
** Si les relais Nostr ne dépendaient que de la racine Merkle, ils ne pourraient pas savoir quand l'arbre Merkle était complet, puisque chaque paire de branches les plus proches de la racine Merkle se hacherait dans la même racine Merkle. **
Pour s'assurer que le profil de l'utilisateur est complet, le relais ou l'utilisateur hachera l'intégralité de son arbre Merkle mis à jour et vérifiera qu'il correspond à l'ensemble du hachage de l'arbre sur la chaîne. Si tous les hachages de l'arborescence correspondent, les données utilisateur sont complètes. Si le hachage de l'arbre entier ne correspond pas, un relais ou un utilisateur peut indiquer aux autres relais son dernier numéro de feuille et demander la branche manquante jusqu'à ce que le hachage de l'arbre entier corresponde. Afin de garder une trace de toutes les nouvelles racines Merkle ajoutées chaque semaine environ, les relais Nostr doivent devenir des nœuds complets Bitcoin. Les relais Nostr 2.0 sont payés indirectement pour stocker la blockchain Bitcoin tout en améliorant la sécurité de Bitcoin et Nostr.
Limites du stockage Nostr : règle empirique de l'utilisateur
Étant donné que les relais ont le droit de choisir quoi stocker, contrairement aux nœuds complets Bitcoin, les relais Nostr peuvent perdre certaines données utilisateur. Par conséquent, les utilisateurs ne doivent stocker des données sur le relais Nostr que si les utilisateurs peuvent effectuer des sauvegardes localement. Le service auto-hébergé de Web5 permet aux utilisateurs de synchroniser les sauvegardes sur tous leurs appareils locaux, ce qui réduira le risque pour les utilisateurs préoccupés par l'utilisation de Nostr. En fin de compte, seule la blockchain est l'endroit où les données sont vraiment immuables. Cela dit, Nostr est une solution hybride assez sûre qui fonctionnera toujours bien pour de nombreuses applications. Les échanges sont listés ci-dessous :
Trois niveaux de minimisation de la confiance
Compromis fondamentaux entre les blockchains basées sur le consensus de Nakamoto et Nostr
** Plus il y a de relais Nostr qui stockent des données pour une adresse particulière, plus il est difficile de censurer ces données. Cela signifie que les données populaires hébergées par de nombreux relais Nostr peuvent être plus difficiles à censurer que les données impopulaires qui sont rarement téléchargées. **
**D'autre part, la blockchain du consensus Nakamoto empêche la censure basée sur l'âge des données. Plus les données existent dans la blockchain, plus il est difficile de les supprimer en utilisant une attaque à 51 %. **
Comme nous pouvons vérifier que certaines fourches appartiennent à des utilisateurs spécifiques, les relais Nostr peuvent être payés chaque fois qu'ils transmettent une petite donnée à un utilisateur. Pour ce faire, l'utilisateur doit télécharger la tête de la blockchain (comme dans SPV) pour pouvoir exécuter les fonctions typiques d'un portefeuille léger. L'utilisateur tirera parti de la fonctionnalité SPV du portefeuille léger pour récupérer une transaction spécifique de la chaîne, qui inclura la racine Merkle du profil utilisateur et l'intégralité du hachage de l'arborescence dans son OP_RETURN. Les utilisateurs peuvent désormais payer le relais pour télécharger le profil de cet utilisateur branche par branche et vérifier chaque branche en les hachant pour qu'elles correspondent à la racine Merkle sur la chaîne.
Afin d'envoyer des sats (la plus petite unité de Bitcoin) au relais Nostr en échange de la fourniture de données, nous utilisons le design ZKCP (Zero-Knowledge Conditional Payments) de Gregory Maxwell (célèbre développeur Bitcoin Core) [1] Une version évoluée de ZKCSP : preuve de récupérabilité [2] Combiné avec Lightning Network.
Selon la description du livre blanc ZKCSP :
"... pas besoin d'un tiers de confiance... Nous avons également implémenté le protocole ZKCSP pour le cas de preuve de récupérabilité, où le client paie le serveur pour avoir la preuve que les données du client ont été correctement stockées sur le serveur." [2]
Une fois l'étape 3 effectuée, l'utilisateur apportera des modifications en plus de la demande originale signée par le financier avant de lancer la construction du ZKCSP à l'étape 4. L'utilisateur ajoutera un supplément à la demande d'origine, en précisant le montant à déduire des soldes de l'utilisateur et du financier (ils doivent être du même montant, plus les frais du financier), que l'utilisateur ajoutera ensuite au message d'origine. contenu à signer.
** Si l'utilisateur spécifie d'envoyer plus de sats qu'il n'en possède, ou plus que le financier n'a gelé sur ce relais Nostr, alors le relais Nostr rejettera la demande car le relais ne pourra pas être payé. **
De cette façon, les utilisateurs peuvent se connecter avec de nombreux relais Nostr tout en gelant leurs fonds avec seulement quelques bailleurs de fonds. Une approche similaire pourrait être adoptée avec le Lightning Network, où les financiers à confiance minimisée sont des intermédiaires sans autorisation entre les utilisateurs et les commerçants. Les sauts éclair P2P normaux sont également disponibles dans Nostr 2.0, mais cela peut être utile si le routage et l'équilibrage des canaux échouent fréquemment.
Liste blanche déverrouiller le relais Nostr payant
Les relais Nostr peuvent mettre en liste blanche certaines clés s'ils souhaitent stocker des données consultées par tous ces utilisateurs. Si les relais Nostr ne sont pas en mesure de mettre sur liste blanche les utilisateurs souhaitant stocker des données, ils stockeront toutes les données qui leur seront envoyées. Si les utilisateurs peuvent toujours envoyer des données aux relais gratuitement, alors les utilisateurs n'auront jamais besoin de payer pour les relais Nostr. Nostr ne peut proposer des options payantes que si le relais a la possibilité de refuser de stocker des données qui ne peuvent pas être payées. Les relais gratuits existent toujours, mais l'option pour les relais payants n'existe pas actuellement.
Au lieu d'essayer de stocker gratuitement toutes les données Nostr, un relais Nostr payant peut utiliser une liste blanche pour stocker de manière sélective toutes les données que ses utilisateurs payants consultent quotidiennement. Certains relais Nostr continueront à fonctionner sur un modèle gratuit, mais à plus grande échelle, ce n'est pas durable car la plupart des relais gratuits ne sont que des passionnés. La liste blanche (même si nous pouvions attribuer en toute sécurité une clé publique à chaque profil Nostr) donnant au relais Nostr la possibilité de décider quelles données stocker ne serait pas possible.
Une clé publique par profil déverrouille la fonction de liste blanche : l'adresse Bitcoin devient votre clé publique Nostr.
Ce système permet enfin d'attribuer une clé publique à chaque fichier de configuration.
Il n'y a aucun avantage à ce que les utilisateurs créent de nouvelles clés publiques pour chaque publication... car elles sont toutes associées à leurs profils ! Ce n'est pas la même chose qu'une adresse Bitcoin. Contrairement à Bitcoin, le fait que les utilisateurs disposent de plusieurs clés publiques dans la même application n'améliore pas la confidentialité.
**La clé publique du profil Nostr doit correspondre à la clé publique de la transaction Bitcoin qui contient le hachage hebdomadaire (la racine Merkle de tous les messages de l'utilisateur et le hachage de l'arbre entier). Contrairement aux utilisateurs de Nostr qui utilisent les signatures Schnorr, ils devront utiliser un portefeuille Bitcoin (portefeuille mobile/portefeuille léger ou nœud complet) pour signer. **
La beauté de ceci est que chaque compte Nostr sera représenté par son adresse Bitcoin, ** ce qui signifie que les utilisateurs peuvent envoyer des paiements directement aux comptes Nostr sans demander deux clés publiques différentes. Cela réduit le coût cognitif des nouveaux utilisateurs du système. Au lieu d'utiliser des noms d'utilisateur, les utilisateurs doivent toujours s'envoyer des clés publiques ou DNS pour se trouver sur Nostr. **
Si d'autres applications Nostr utilisent des clés publiques différentes, elles peuvent toujours être attachées à la même identité décentralisée (DID) - de cette façon, la façon dont votre compte est identifié reste cohérente entre les applications. Cependant, cette règle de consensus Nostr limitera l'utilisation d'une seule clé publique par profil sur chaque application Nostr.
DHT agit comme un classement pour la découverte par les pairs.
Les relais peuvent utiliser une table de hachage distribuée (DHT) pour trouver d'autres relais. Les relais peuvent partager leur liste blanche dans une table de hachage distribuée en répertoriant la clé publique où les données sont stockées. De cette façon, les relais avec des fourches de données manquantes pour une certaine clé publique peuvent scanner le DHT et se connecter directement aux adresses IP d'autres relais prétendant stocker ces fourches manquantes. Les relais peuvent alors télécharger les branches manquantes directement à partir de ces relais Nostr.
Les relais pourront également trouver les relais les plus actifs en vérifiant le nombre de transactions ZKCSP précédentes que ces relais ont résolues sur la chaîne - récentes et de tous les temps. Dans ce système, tous les relais Nostr deviennent des nœuds complets, de sorte que l'audit des transactions précédentes des autres relais sera indolore. Cela rendrait coûteux l'instauration de la confiance, car les transactions en chaîne nécessitent toujours des frais de transaction. Si un relais Nostr ouvre de nombreux canaux pour établir la confiance avec lui-même afin de gagner la confiance des autres relais, il devra payer beaucoup de frais de transaction pour maintenir la fausse réputation chaque semaine. Une fois que l'attaquant n'a pas réussi à fournir la branche manquante, le délai d'attente entraînera la déconnexion du relais - il ne s'agit donc que d'une attaque temporaire et coûteuse (tout comme une attaque à 51 % est une attaque temporaire et coûteuse).
Le DHT n'est pas aussi anonyme que l'exploitation minière, car la clé publique de chaque relais Nostr sera répertoriée à côté de l'adresse IP dans le DHT, mais cela évitera aux relais d'envoyer aveuglément des requêtes sur le réseau - à une échelle suffisamment grande. surchargera le réseau. Les relais Nostr à la recherche de plus de confidentialité peuvent utiliser un VPN ou un autre service de protection IP.
Les utilisateurs n'auront pas accès à ce même système de confiance car ils ne sont pas des nœuds complets. Cependant, les utilisateurs peuvent s'y fier.
Les amateurs sont indirectement connectés à des centaines de relais Nostr
Étant donné que les utilisateurs stockent automatiquement tous les en-têtes de bloc dans leurs portefeuilles légers, les utilisateurs peuvent voir qui sont les mineurs les plus actifs. Les mineurs devenant des financiers permettront aux utilisateurs de filtrer les mineurs les plus populaires afin qu'ils n'aient pas à lier aveuglément des fonds à des financiers aléatoires qui n'ont aucune corrélation avec la viabilité du réseau.
**Les financiers (mineurs) n'ont qu'à verrouiller leurs sats avec le relais Nostr, sans transmettre les données elles-mêmes entre les utilisateurs et le relais. ** Le financier (mineur) a juste besoin de signer la demande de l'utilisateur afin que l'utilisateur puisse interagir directement avec tous les relais Nostr auxquels le financier est connecté - 4 étapes pour ZKCSP+Lightning comme ci-dessus.
en conclusion
Le Lightning Network n'existerait pas sans la blockchain de consensus Nakamoto de Bitcoin, car les utilisateurs n'auraient aucun endroit pour stocker leurs preuves groupées de transactions hors chaîne.
Tout comme les utilisateurs regroupent toutes ces transactions Lightning Network et placent de petites preuves dans la blockchain, nous regrouperons toutes les données Nostr et placerons de petites preuves dans la blockchain. De la même manière que le Lightning Network fournit des paiements instantanés à la deuxième couche, Nostr peut être en mesure de fournir un stockage de données à la deuxième couche sans risque de sidechain non sécurisée. **
** Il utilise la même approche que le Lightning Network, avec la blockchain de consensus Nakamoto de Bitcoin sur la première couche et Nostr + ZKCSP Lightning sur la deuxième couche. **