Road to Neo3 : service de noms de domaine natifs basé à NFT

Dans l’article précédent, nous avons introduit la nécessité de noms de comptes convivial dans blockchain. De plus, nous avons couvert la première approche proposée, un service d’alias. Ce service aurait permis à alias d’aborder le mappage et la conversion en contrat.

Le principal inconvénient était l’absence de contrôle indépendant sur les alias. Permettre aux utilisateurs de posséder et d’échanger des alias nécessite une solution plus complexe.

L’article d’aujourd’hui présentera cette approche alternative, un service de nom natif. S’appuyant sur la conception précédente, il introduit les noms de domaine comme des jetons non fongibles. Ces NFT sont uniques, sous le contrôle du titulaire du bail, et négociables par les utilisateurs.

Jetons non fongibles

Avant le début des travaux sur le service de nom, les jetons non fongibles n’avaient pas encore été introduits sur Neo3. Cela signifiait qu’un modèle NFT natif devait être créé en premier. Actuellement en cours de développement, cette implémentation NFT native sert de base à tous les actifs de noms de domaine.

Les jetons non fongibles correspondent naturellement aux noms de domaine. Plutôt que d’être des copies identiques, elles sont distinctes les unes des autres. Comme un domaine Web typique, deux personnes ne peuvent pas enregistrer le même domaine. Par exemple, il n’y a qu’une seule Google.com. En outre, ils peuvent être achetés et vendus comme n’importe quel autre produit.

Le contrat NFT natif de Neo3 suit la norme de jeton NEP-11existante . Parallèlement à quelques variantes, il est actuellement utilisé par plusieurs contrats sur Neo2. NEP-11 définit la logique de base nécessaire pour créer et gérer des jetons uniques et leurs diverses propriétés.

Une fois déployé sur Neo3, le contrat natif de NEP-11 pourrait également être hérité dans d’autres contrats. Cela pourrait grandement simplifier la mise en œuvre d’autres cas d’utilisation NFT pour les développeurs.

Vue d’ensemble du service de noms

Le service de noms proposé permettra de représenter les adresses contractuelles, les adresses de portefeuille et d’autres chaînes complexes dans un format DNS traditionnel. Le niveau le plus bas est connu sous le nom de domaine racine. Il peut être considéré de la même manière que les domaines de haut niveau tels que .com ou .org sur Internet.

Initialement, un nombre limité de domaines racine sera disponible. Dans la mise en œuvre actuelle, encore en cours de développement, les domaines racine sont néo, portefeuille, dapp, et org. La solution permet jusqu’à trois autres niveaux de sous-domaine.

À partir du premier niveau (p. ex. nnt.neo), ces sous-domaines peuvent être loués et renouvelés via le contrat NNS. L’achat d’un bail de nom de domaine créera le NFT correspondant, l’acheteur étant désigné comme propriétaire. Le propriétaire peut alors transférer la propriété lorsque vous le souhaitez, c’est ainsi que le trading est activé.

Dans sa forme actuelle, l’exploitation du service de nom est gérée dans un contrat natif. Ce contrat prévoit trois parties principales: le contrat NFT de service de nom, une table d’enregistrement et un résolateur.

La logique de base du contrat NNS inclut toutes les fonctionnalités de service de base. Cela inclut la possibilité d’enregistrer, de renouveler et de transférer des noms de domaine sous la forme de NFT NEP-11. Il ajoute également quelques méthodes pour définir des paramètres tels que le prix de location, le prix de renouvellement, et l’enregistrement de nouveau domaine racine.

La table de registre gère la liste de tous les noms de domaine avec leurs propriétaires actuels, la période de validité et d’autres informations. Il permet la création de nouveaux domaines, à partir du premier niveau. Ceux-ci sont valables pendant un an jusqu’à ce qu’ils soient renouvelés. Cette période de validité est ensuite héritée par n’importe quel sous-domaine de deuxième ou troisième niveau.

Le résolateur stocke les instances de résolution. Il s’agit de groupes de méthodes qui permettent de résoudre correctement le nom de domaine sur sa chaîne correspondante. Plusieurs types d’enregistrements sont déjà pris en charge, y compris des enregistrements A pour les adresses de contrat ou de compte et les enregistrements CNAME pour la redirection.

Expérience utilisateur

Une fois terminés, les utilisateurs doivent être en mesure de louer directement des noms de domaine de premier niveau en invoquant le contrat natif. Toutefois, on s’attend à ce qu’aucune interface officielle du contrat ne soit ajoutée. Ce n’est pas très surprenant, car le service de nom natif ne comprendra pas non plus son propre mécanisme de négociation.

Cela poussera probablement le développement et l’exploitation de l’infrastructure de soutien aux équipes tierces. Par exemple, Neo core n’inclut pas l’infrastructure pour le commerce des jetons NEP-5. Au lieu de cela, divers échanges ont surgi pour répondre à ce besoin. Le même résultat est attendu avec les noms de domaine NFT. Les plates-formes indépendantes, telles que GhostMarket,sont susceptibles de rivaliser pour fournir ces installations.

Ces services peuvent également fournir des interfaces pour la location de domaines à partir du contrat natif. Nous pouvons également nous attendre à ce que certains fournisseurs de portefeuille ajoutent des options similaires, ce qui aidera à rationaliser le processus. Ces deux options aident les utilisateurs en rendant la fonctionnalité accessible et contribuent à réduire la complexité.

Une fois la fonctionnalité en direct, les utilisateurs doivent être en mesure de remplacer complètement leur utilisation des adresses publiques sur Neo. Plutôt que d’envoyer des actifs à une adresse comme NbnPGLE386Gc6mAqhHeumKbp37zhGPXLzH, les transferts et les interactions contractuelles pourraient plutôt être dirigés vers un domaine comme bob.nnt.neo, beaucoup plus facile à travailler et à se souvenir!

Prévenir l’usurpation d’identité

Il ya encore des inconvénients au service. Par exemple, il y a la possibilité d’usurpation d’identité. Ceci est courant sur Internet, réalisé en créant un nom d’utilisateur visuellement similaire. Alternativement, parfois les utilisateurs peuvent s’accroupir sur des noms qui sont habituellement associés à une entité connue. Prévenir ce type de comportement est une bataille en cours, mais il existe des options possibles.

Comme pour le service alias précédemment proposé, il est possible que les NFT de nom de domaine puissent être liés à une identité vérifiée. Cela pourrait être fourni par NeoID. En utilisant une solution comme Vivid, les domaines pourraient être étroitement (ou vaguement) couplé avec diverses revendications / preuves sur une identité. Cela permet des niveaux personnalisables d’assurance que le propriétaire d’un alias est qui ils prétendent être.

En outre, comme l’a noté Mengyu Liu, le passage à une résolution de nom de domaine ouvre la porte à plusieurs améliorations potentielles:

« Étant donné que la résolution de noms de domaine n’est pas aussi simple que l’obtention d’une adresse, de nombreuses logiques de résolution complexes doivent être abstraites dans ce composant, telles que la redirection des noms de domaine, la vérification du format et l’appariement flou. »

L’appariement flou est également connu sous le nom de correspondance approximative des chaînes. C’est une technique qui permet de comparer différentes cordes en fonction de leurs similitudes. Il est souvent utilisé pour aider à découvrir certaines attaques, telles que les tentatives de phishing.

Par exemple, le contrat peut rechercher les tentatives de registre des noms de domaine avec une distance Levenshtein de 1 à partir d’un nom de domaine existant.

Cela empêcherait l’enregistrement du domaine 03.wallet si O3.wallet existait déjà. Il y a un inconvénient évident à cette solution simple. Il exclurait également l’enregistrement de noms de domaine similaires (mais clairement différents), tels que larry.neo et harry.neo.

Cela pourrait être évité avec d’autres restrictions. Par exemple, le contrat ne pouvait vérifier que les cas qui utilisent des caractères couramment mal interprétés, tels que « I » et « l ».

Superposées, ces deux règles empêcheraient l’enregistrement de dyIan.nnt.neo si le domaine dylan.nnt.neo existe déjà. Une logique de correspondance floue plus complexe peut être utilisée pour réduire le nombre de faux positifs de cette façon.

Ceci conclut l’introduction au composant de service de nom natif de Neo3. Bien que la base du service semble solide, il est possible que la fonctionnalité change à nouveau à l’avenir. Il convient de noter que le développement de la composante n’a pas bougé depuis juillet. Cela est probablement dû au fait que les ressources sont orientées vers des aspects prioritaires du développement de base de Neo3 avant le lancement.