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).

Arrive Bitcoin et nous avons le même problème, 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.

Les adresses Lightning s’appuient sur le protocole LNURL-pay et ressemblent à peu près à une adresse e-mail :

La nomenclature des adresses e-mail est le moyen idéal pour transmettre des informations d’identité. Il délimite facilement les organisations et se subdivise davantage en unités ou en personnes en son sein. Tout le monde est déjà habitué à ce format et, comme nous le verrons, a le potentiel de transmettre beaucoup plus d’informations que les boîtes aux lettres de destination.

Pendant des années, j’ai 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.

Avec Lightning Addresses, nous voyons un chemin vers des identifiants décentralisés, 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é.

Étant donné l’adresse Lightning :

satoshi@exemple.com

Cela signifie que selon la spécification actuelle, le descripteur de paiement sera situé à :

https://example.com/.well-known/lnurlp/satoshi/

Mais que se passe-t-il si Satoshi n’a pas accès au serveur Web example.com ? 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é.

En fait, ce n’est probablement pas le cas plus souvent qu’il ne l’est. Pour cette raison, il existe le type d’enregistrement MX dans DNS, qui ajoute un niveau supplémentaire d’indirection pour contrôler la destination des e-mails. 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é).

La même chose doit se produire avec les adresses Lightning pour en grande partie les mêmes raisons. Le nom d’hôte à droite du ‘@’ peut ne pas avoir de serveur Web du tout, 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 serait capable de 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.

Ensuite, dans le problème Lightning GitHub, où la RFC LNURL était en cours de discussion, quelqu’un a suggéré de simplement ajouter une adresse au sous-domaine « _lud16 ».

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.

Une étiquette étendue dans DNS, comme _tcp ou _udp, 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.

Pratiquement toute étiquette DNS valide, comme _lud16 ou _btc, 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:

$ORIGIN example.com.
_ie.test IN TXT « ceci est un test »

_eg.test IN TXT « ceci est un test séparé »

Une requête DNS de type TXT sur « test.example.com » ne renverra pas de réponse (NXDOMAIN).

Une requête DNS de type TXT sur « _ie.test.example.com » seulement renvoie un résultat pour le premier enregistrement.

Une requête DNS de type TXT sur « test._ie.example.com » seulement renvoie le deuxième enregistrement.

En d’autres termes, nous avons plusieurs enregistrements TXT pour le test.exemple.com feuille, cependant, nous ne renverrons que celle interrogée avec l’étiquette de portée, 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 peut être installé ultérieurement sur n’importe quelle adresse e-mail existante via DNS.
• 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.

Comment la portée de soulignement pourrait être utilisée dans les chaînes de blocs

En reprenant le format d’adresse email utilisé dans Lightning Addresses : , nous pouvons utiliser la convention via le DNS pour spécifier toutes sortes de points de terminaison pour la même identité :

$ORIGIN bombthrower.com.
_lud16.markjr IN TXT « https://my.ln-node/.well-known/lnurlp/markjr »
_btc.markjr IN TXT « bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl »
_ens.markjr IN TXT « 0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb »

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.

Même cela change, évolue. Je pense que nous nous retrouvons finalement là où les espaces de noms chevauchent à la fois la racine d’arbre inversée existante et les chaînes de blocs entièrement décentralisées.

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.

Tous les espaces de noms décentralisés n’ont pas de résolveurs DNS hérités, mais cela changera également. Des travaux sont également en cours sur une nouvelle implémentation DNSresolvers qui résoudra les domaines Stacks, .btc et HNS par Handshake, et les domaines de premier niveau Unstoppable. Vous pouvez le tester via des recherches sur alpha.dnsresolvers.com :

% dig +short easydns.btc @alpha.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 !

Une fois que nous en avons fait une convention pour utiliser la portée de soulignement, 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 :

Avec la portée de soulignement, nous pouvons affirmer le véritable identifiant Twitter à partir du nom d’hôte dans l’élément url en utilisant la convention suivante :

$ORIGIN bombthrower.com.

stuntpope._twitter EN TXT « StuntPope »

*._twitter EN TXT « faux »

En soi, cela ne fait rien. Personne ne va ouvrir une fenêtre de terminal et taper :

« dig -t TXT + short stuntpope._twitter.bombthrower.com »

… pour savoir si la personne qui vous envoie un DM, « Comment se passe votre trading aujourd’hui? » est vraiment moi, ou l’un des légions des imposteurs StuntPope 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.

Lorsqu’un faux profil Twitter se fait passer pour quelqu’un, il copie généralement toutes les données textuellement, y compris le nom d’hôte dans le champ URL du profil Twitter. Si l’utilisateur réel dispose des enregistrements décrits ci-dessus, la convention de recherche des faux Poignée Twitter au réel L’URL manquera l’enregistrement TXT _twitter réel pour le vrai profil et frappera l’enregistrement générique, 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.

De plus, pour utiliser des étiquettes ou des identifiants lisibles par l’homme, nous avons besoin d’une couche d’abstraction qui offre de la flexibilité et un format facilement reconnaissable.

Enfin, nous pouvons réaliser tout cela en utilisant le DNS, 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 Bitcoin Magazine.