Problème : les wallets et serveurs (par exemple pour la vérification de paiement correspondant à un achat en ligne) dépendent des indexeurs comme sources de vérité. (cf ce sujet)
Un indexeur peut facilement mentir sur tous les résultats qu’il donne.
Chaque serveur de boutique en ligne ou d’authentification ne peut pas héberger un nœud archive et un indexeur.
Il pourrait donc y avoir une couche supplémentaire, avec des serveurs qu’on appellera ici des méta-indexeurs (vrai nom à trouver). Le client envoie sa requête au méta-indexeur.
- Si l’entrée n’existe pas, le méta-indexeur envoie la requête à N indexeurs. Chacun répond et signe le couple (requête, réponse) avec sa clé membre (ou clé déléguée). Le méta-indexeur vérifie les signatures et que toutes les réponses sont identiques, ou sélectionne la réponse majoritaire. Il la met en cache et répond au client en incluant les signatures des indexeurs.
- Si l’entrée existe, le méta-indexeur répond le document qui contient la réponse et les signatures.
Le client peut vérifier les signatures.
Le cache peut être une simple base de données locale clé-valeur ou bien du IPFS. À voir s’il vaut mieux économiser grâce à une mise en cache globale ou si le surcoût réseau IPFS est plus lourd encore.
Comme ce protocole est un peu lourd, on pourrait ne l’utiliser que pour certains usages, comme la vérification automatique de paiement, ou certaines actions critiques dans les wallets.