📝CNS: Contract Name Service 🚧

[BertrandD]

### Tasks
- [ ] item 1

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

✅ All tests successful. No failed tests found.

[hhalex]

J'ai l'impression qu'il faudrait envoyer la proof d'ownership du nom de domaine dans chaque transaction ? Car le nom de domaine peut changer de propriétaire après que le contrat ait été registered sur Hyle ?

[hhalex]

Si on veut mimic les dns classiques, il faut envoyer une preuve d'ownership du domaine au niveau de la tx, et faire en sorte que cette preuve ne soit valide qu'une fois pour cette transaction spécifiquement?

Un truc du genre:

• le contrat est attribué un nom généré à partir du name et du digest de son code, unique, et qui ne change pas
• plein de contrats peuvent essayer d'avoir un nom similaire, mais un seul pourra avoir une proof d'owneship qui matche "contract.com"

[hhalex]

Ça veut dire qu'on peut potentiellement être sans identité ? Inacessible?

[wraitii]

Vrac d'idée peut-être sans queue ni tête à ce sujet:

• je pense qu'il est très interessant de permettre des sous-domaines pour les contrats, et de faire passer le déploiement par les TLD
• Je pense que pour le moment tu ne touches pas du tout au problème de "comment éviter le domain squatting", c'est un gros sujet à creuser
• Est-ce qu'on autorise un système de déploiement de contrat par UUID sans impacter ce système de naming? Comment ça se joue avec nos histoire de state vs contracts?
• Je me perds un peu dans ce que tu dis sur l'identité, pour moi y a de facto une adéquation 1-1 entre un contrat et un identity provider, ensuite c'est up-to-the contract.
• IMO je permettrais plutôt un type de TX spéciale/ output dans HyleOutput spécial "RegisterContract" qui passe potentiellement par le même zk-smart-contract et qu'on traite génétiquement. aUtrement dit tu appelles le contrat hyle, tu dois provide une proof valable pour hyle, et ensuite on considère que ton contrat est ajouté. Je sais pas si c'est ce que tu voulais dire.