Simplifier le DNS des adresses Bitcoin : Bitcoin Magazine
Ceci est un éditorial d’opinion de Mark Jeftovic, cofondateur et PDG d’easyDNS Technologies Inc. et auteur de « Managing Mission Critical Domains and DNS ».
Dès le moment où j’ai découvert Bitcoin en 2013, je savais qu’il devrait éventuellement y avoir un moyen de référencer les adresses de portefeuille à l’aide d’étiquettes lisibles par l’homme.
Le gros problème avec les longues adresses de Bitcoin est qu’elles ne sont pas mémorables, et malgré les caractéristiques pseudonymes ou anonymes de Bitcoin, la plupart du temps, vous voulez pouvoir affirmer ou vérifier facilement qu’une adresse de portefeuille appartient à une entité spécifique – pensez des dons à une association caritative ou à un crowdfund. Cela affecte chaque blockchain.
En tant que gars du DNS (système de noms de domaine), j’ai déjà vu ce film : DNS a été inventé pour résoudre le même problème avec l’adressage IPv4. Au fil du temps, le DNS a évolué pour faire beaucoup plus – non seulement le DNS a ajouté la capacité de résoudre les adresses IPv6, mais il est également de plus en plus utilisé pour transmettre des métadonnées sur un espace de noms. Pensez aux enregistrements SRV, aux NAPTR, aux listes de blocage RBL, aux zones de politique de réponse (RPZ) et à l’enregistrement TXT omniprésent (qui est utilisé pour SPF, DMARC, DKIM et tout ce qui ne correspond pas nativement au protocole).
en gros.
Le problème spécifique au Bitcoin et à la foudre
Il semble qu’une grande partie de l’activité de transaction de paiement passera à la couche 2 avec des protocoles comme Lightning, et plus récemment l’avènement de l’adresse Lightning.
com/andrerfneves/lightning-address/blob/master/README.md
Il délimite facilement les organisations et se subdivise davantage en unités ou en personnes en son sein a le potentiel de transmettre beaucoup plus d’informations que les boîtes aux lettres de destination.
Pendant des années, j’avais anticipé que ce format deviendrait la norme de facto pour les points de terminaison d’identité avec Session Initiation Protocol (SIP) et XMPP.
SIP et XMPP n’ont pas conquis le monde comme je m’y attendais (du moins pas encore) et pendant un certain temps, les identifiants ont commencé à graviter vers des plates-formes centralisées telles que les identifiants Twitter et les identifiants d’utilisateur Github. J’ai toujours trouvé cela interrogateur, en particulier chez les Bitcoiners.
puisque les adresses e-mail sont elles-mêmes décentralisées, dans les limites du système DNS lui-même (plus de détails ci-dessous).
Il n’y a qu’un seul problème : la spécification LNURL telle que définie manque un niveau d’abstraction. Sans cela, le cas d’utilisation des adresses d’éclairage devient très limité.
com
com/.well-known/lnurlp/satoshi/
Si nous nous en tenons à l’analogie de l’adresse e-mail : ce n’est pas parce que vous l’avez comme adresse que le serveur avec le nom d’hôte correspondant est celui où l’e-mail est livré.
Ils peuvent diriger la livraison des e-mails vers des noms d’hôte fonctionnant sous un nom de domaine complètement différent (pensez aux personnes qui utilisent un fournisseur de messagerie externe, mais avec leur propre domaine personnalisé).
ou l’utilisateur est indûment limité à l’utilisation d’une adresse Lightning où le composant de nom d’hôte ne peut être que celui du serveur Web sur lequel le fichier JSON est hébergé. Cela peut poser problème lors de la publication d’une adresse Lightning que l’utilisateur souhaite modifier ultérieurement.
En tant que gars du DNS, la solution semblait évidente mais j’étais coupable d’y avoir trop réfléchi :
En 2017, j’ai été invité par ce qui était alors le groupe de travail Ethereum Name Service à une réunion à Londres pour élaborer les spécifications du registre ENS.
J’ai quitté cette réunion en pensant qu’il devait y avoir un nouvel enregistrement de ressource DNS, un nouveau type d’enregistrement qui pourrait référencer les ressources de la blockchain à partir de l’ancien DNS.
Dans mon esprit, cela ressemblerait à quelque chose comme un enregistrement SRV ou NAPTR, qui avait différents champs pour les protocoles, les ports et les pondérations (le fait que les navigateurs Web d’aujourd’hui ne regardent toujours pas les enregistrements SRV pour les adresses Web est l’une des grandes opportunités manquées de l’ère d’internet).
Mon raccourci de travail était « BCPTR » pour « Blockchain Pointer » et il avait une spécification trop compliquée et alambiquée pour indiquer exactement vers quelle blockchain un enregistrement pointait et de quel type de ressource il s’agissait.
L’utilisation de traits de soulignement pour différencier certains attributs de nommage des noms d’hôte réels existe depuis un certain temps. Il a été utilisé dans la spécification SRV RR RFC2872 d’origine et décrit plus tard comme « portée soulignée » dans la RFC 8552.
La suggestion a immédiatement explosé dans mon cerveau et j’ai réalisé que j’y réfléchissais depuis des années.
est insensible à la casse et nous les voyons dans les enregistrements SRV et NAPTR pour une utilisation dans les applications SIP, VOIP et ENUM, l’équilibrage de charge, sans parler des enregistrements TXT pour DKIM et DomainKeys.
nous fournit un mécanisme pour limiter une réponse à une requête correspondant à la portée, sous le nœud parent dans l’arborescence DNS.
Sens:
test IN TXT « ceci est un test »
test IN TXT « ceci est un test séparé »
test
example.com » ne renverra que le deuxième enregistrement.
example celle qui commence par un trait de soulignement.
Il s’avère que c’est assez puissant pour nos besoins. C’est aussi la solution la plus simple et la plus optimale dans notre cas d’utilisation car :
- Tout le monde peut l’utiliser
- C’est un format que les gens reconnaissent facilement
- Il permet à un enregistrement json d’exister ailleurs que sur le serveur (comme le fonctionnement d’un enregistrement MX)
- Peut fournir tout type de charge utile
- Peut fonctionner sur toutes les blockchains
/li>
Comment la portée de soulignement pourrait être utilisée dans les chaînes de blocs
nous pouvons utiliser la convention via le DNS pour spécifier toutes sortes de points de terminaison pour la même identité :
markjr IN TXT « https://my.ln-node/.well-known/lnurlp/markjr »
markjr IN TXT « »
markjr IN TXT « »
Nous pouvons y arriver à partir d’ici sans casser quoi que ce soit déjà en place :
- Les applications utilisant déjà l’adresse LNURL peuvent toujours continuer à l’utiliser
- Les applications peuvent ajouter la recherche DNS
Mais le DNS est centralisé !
Il est vrai que le DNS a une arborescence inversée qui se termine à la racine «. ». Mais même cette racine est assez décentralisée, comprenant des milliers de serveurs exploités par au moins 13 opérateurs disparates. L’ancien DNS peut être logiquement centralisé, mais en réalité fonctionne plus comme une sorte de fédération décentralisée.
Une partie de cela est déjà là aujourd’hui : vous pouvez utiliser quelque chose comme les domaines Stacks et.btc qui s’épinglent à Bitcoin et il y aura probablement d’autres espaces de noms construits directement sur Bitcoin.
dnsresolvers.com
3.14.49.122
(Ce serveur est une preuve de concept et disparaîtra à l’avenir, s’il vous plaît ne l’ajoutez pas à votre resolv.conf.)
Tout cela, et cela résout aussi le problème du faux compte Twitter !
nous constatons que nous pouvons résoudre toutes sortes de problèmes en utilisant les méthodes existantes.
Regardons le faux problème de gestion de Twitter qui sévit dans l’espace Bitcoin.
La structure de données d’un utilisateur de Twitter ressemble à ceci :
En soi, cela ne fait rien. Personne ne va ouvrir une fenêtre de terminal et taper :
bombthrower.com »
… pour savoir si la personne qui vous envoie un DM, « Comment se passe votre trading aujourd’hui? » est vraiment moi, ou l’une des légions d’imposteurs StuntPope là-bas sur Twitter. (Je plaisante bien sûr, personne de sensé ne se ferait passer pour moi. Mais pour beaucoup de sommités fines, c’est un vrai problème.)
Mais ce qui peut arriver si cela devient la convention, c’est que les développeurs peuvent créer des crochets rapides et sales dans leurs applications pour effectuer ces recherches.
provoquant une incompatibilité.
Nous avons publié une extension Chrome de preuve de concept via le Github easyDNS, qui fait exactement cela avec trois modes :
A) Aucune information affirmée ;
B) Le profil correspond aux informations affirmées ;
C) Le profil ne correspond pas aux informations affirmées (c’est un faux).
Tout cela et plus encore, peut être fait en utilisant des conventions très simples dans un protocole omniprésent qui est déjà déployé.
Conclusion
Les adresses de portefeuille se prêtent à la nécessité d’une sorte de mécanisme de dénomination. Il existe de nombreux cas d’utilisation où la nécessité d’affirmer en toute sécurité une adresse à partir d’une identité prime sur le pseudonymat ou l’anonymat.
qui sous-tend déjà l’infrastructure technique d’Internet, est déjà une fédération décentralisée et en voie de s’ancrer sur des protocoles décentralisés de couche 1. Nous pouvons le faire sans ajouter de nouveaux types d’enregistrement ni ajouter de protocole aux spécifications existantes.
Ceci est un article invité de Mark Jeftovic. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.
