Les exemples des débats sur IPFS et ENS
Il y a eu de nombreux débats récemment autour des limites de la décentralisation du “web3”, notamment suite au débat entre Moxie Marlinspike (le créateur de Signal) et Vitalik Buterin (le co-créateur d’Ethereum) : https://fortune.com/2022/01/10/signal-moxie-marlinspike-nft-web3-ethereum-blockchain-vitalik-buterin/
Pour diverses raisons, certains NFTs stockent encore leur metadata sur des espaces centralisés… mais ce n’est plus recommandé depuis déjà longtemps : il existe même différents sites comme checkmynft.com pour tester ce type de faiblesse.
Certains aspects de cette centralisation excessive sont donc facilement évitables mais ce n’est pas toujours aussi aisé pour d’autres. Par exemple, même si certaines données peuvent être stockées sur des espaces décentralisés comme IPFS ou Arweave, l’accès à ces données depuis un navigateur s’effectue encore actuellement essentiellement à travers des passerelles centralisées peu répandues comme celle d’Infura. Il en va de même pour la résolution décentralisée des noms de domaines à travers l’Ethereum Name Service.
La réponse d’Andreas M. Antonopoulos sur ce débat est mesurée : il serait dommage de condamner le mouvement “Web3” en plein essor en raison des compromis actuels. Pour reprendre les cas spécifiques d’IPFS et d’ENS, des navigateurs comme Brave et Opera ont déjà partiellement intégré leur support et laissent leurs utilisateurs choisir la passerelle IPFS de leur choix ou les options de résolutions ENS. Il est possible à l’avenir que ces navigateurs intègrent des capacités de véritables nœuds ou que ces capacités soient intégrées à nos “Boxs” (ADSL, Fibre, Satellite), etc.
Nos propres compromis pour certaines clés
Dans un article précédent, nous avions évoqué les différentes possibilités pour le stockage et l’utilisation des clés d’un émetteur d’Attestations Vérifiables et récemment, nous avons dû fournir du code “serveur” pour que des partenaires puissent effectuer :
- le test d’existence d’un DID Document
- la création d’un DID Document
- la signature d’Attestations Vérifiables
Nous ouvrirons prochainement ce code de test, accompagné de probables recommandations quant à l’utilisation de “Cloud HSM”. En effet, pour de nombreux acteurs comme par exemple les émetteurs d’Attestation de KYC, il est essentiel de pouvoir automatiser ces procédures (il ne peut pas s’agir d’une interface web nécessitant des confirmations manuelles comme on peut l’expérimenter à travers Metamask).
Il y aura certainement des solutions plus décentralisées à l’avenir mais cette architecture type sera le compromis que nous rencontrons souvent :
Nos propres compromis pour les nœuds et wallets
[Edité pour précision : Moralis propose des services dont nous avons besoin pour la partie “wallet crypto” à l’intérieur de notre wallet global orienté Identité. Un wallet crypto sur smartphone ne peut se connecter directement à la blockchain et surveiller toutes les transactions, ce ne sont pas des nœuds complets avec toutes les informations de la blockchain et même des blockchains quand on réfléchit à un support de plusieurs chaînes. Il faut donc utiliser des services web intermédiaires permettant d’interroger de véritables nœuds qui font ce travail et pour, par exemple, recevoir des alertes sur les mises à jour des balances des adresses gérées par le wallet, par exemple “vous avez reçus 200 SYL”.]
Un autre sujet de préoccupation est la création de services de surveillance et d’alertes des évènements “on-chain” (sur une blockchain) relatifs à certaines adresses. C’est un service indispensable pour les portefeuilles n’intégrant pas de nœuds et de synchronisation de chaînes complètes.
Ces services de passerelles entre web2 et web3 doivent être fiabilisés et évoluer avec nos besoins en terme de scalabilité et de support multi-chaîne. Après avoir comparé plusieurs services, nous avons sélectionné Moralis.io comme fournisseur d’API et de Nœuds à la demande.
