Prouver sa bonne foi sans dévoiler sa liste de clients : c’est possible
Le plus délicat, pour une institution qui se lance, c’est de vouloir prouver sa bonne foi sans pour autant remettre sa liste de clients. Aujourd’hui, il y a essentiellement deux façons de procéder : soit transmettre les adresses et l’historique des transactions à une société d’analyse on-chain pour qu’elle les évalue — autrement dit, dévoiler son jeu à un tiers —, soit créer une liste blanche de Merkle, qui permet seulement de prouver qu’une adresse appartient à un ensemble, mais pas que l’ensemble lui-même est irréprochable. J’ai essayé une troisième approche, via la voie des données privées de SXT : placer la liste interne et la liste publique des adresses soumises à restrictions dans la même table, puis faire renvoyer à la requête une valeur booléenne accompagnée d’une preuve. À l’extérieur, on ne révèle que le résultat, sans divulguer la moindre entrée. Les possibilités de cette approche sont bien plus vastes que la plupart des gens ne le pensent : on peut ainsi prouver les réserves, effectuer des vérifications liées aux sanctions, voire déterminer si les actifs d’un client dépassent un certain seuil. Dans tous les cas, on ne révèle qu’une réponse par oui ou par non. En pratique, la vraie difficulté technique, c’est l’actualité des données. Les listes changent tous les jours, et les preuves doivent être régénérées en conséquence ; sinon, vous prouvez que vous étiez irréprochable la semaine dernière. J’ai fait cette erreur une fois : j’ai utilisé une ancienne preuve pour vérifier une nouvelle liste, et le contrat m’a dit que tout était en ordre. J’en ai eu froid dans le dos. Depuis, j’ai appris à inclure le hachage de la version des données dans la preuve ; si la version ne correspond pas, la vérification échoue immédiatement. Le véritable obstacle n’est pas la cryptographie, mais la liste elle-même. Qui la gère, à quelle fréquence elle est mise à jour, si l’historique des modifications peut être audité : ce sont des questions opérationnelles, et tout le reste ne sert à rien si elles sont mal traitées. En outre, la reconnaissance juridique des preuves cryptographiques reste une zone grise, et les responsables de la conformité préfèrent toujours consulter un rapport portant un tampon officiel. Par rapport à la preuve de réserves de Chainlink, cette solution est plus flexible : elle permet d’exécuter n’importe quelle requête SQL, et pas seulement d’additionner des soldes. En contrepartie, il faut assumer soi-même tout le travail d’ingénierie nécessaire aux preuves. À mon avis, cette approche sera d’abord adoptée par les acteurs de la RWA et les dépositaires, car ce qui leur manque le plus, c’est précisément ce moyen de prouver leur conformité sans rien divulguer. Pour aller vraiment loin, il faudra aussi combiner les preuves à divulgation nulle de connaissance sur les plages de valeurs et les preuves agrégées. On pourrait, par exemple, prouver à la fois que l’exposition totale est inférieure à une limite et qu’aucune contrepartie unique ne dépasse son plafond. Il n’existe pas encore d’outil prêt à l’emploi pour ce genre de cas : il faut assembler soi-même les pièces. Une fois cette couche bien rodée, le discours commercial des institutions changera : au lieu de dire « notre gestion des risques est très stricte », elles diront « vous pouvez le vérifier vous-même ». #sxt $SXT @SpaceandTime
Le plus délicat, pour une institution qui se lance, c’est de vouloir prouver sa bonne foi sans pour autant remettre sa liste de clients. Aujourd’hui, il y a essentiellement deux façons de procéder : soit transmettre les adresses et l’historique des transactions à une société d’analyse on-chain pour qu’elle les évalue — autrement dit, dévoiler son jeu à un tiers —, soit créer une liste blanche de Merkle, qui permet seulement de prouver qu’une adresse appartient à un ensemble, mais pas que l’ensemble lui-même est irréprochable. J’ai essayé une troisième approche, via la voie des données privées de SXT : placer la liste interne et la liste publique des adresses soumises à restrictions dans la même table, puis faire renvoyer à la requête une valeur booléenne accompagnée d’une preuve. À l’extérieur, on ne révèle que le résultat, sans divulguer la moindre entrée. Les possibilités de cette approche sont bien plus vastes que la plupart des gens ne le pensent : on peut ainsi prouver les réserves, effectuer des vérifications liées aux sanctions, voire déterminer si les actifs d’un client dépassent un certain seuil. Dans tous les cas, on ne révèle qu’une réponse par oui ou par non. En pratique, la vraie difficulté technique, c’est l’actualité des données. Les listes changent tous les jours, et les preuves doivent être régénérées en conséquence ; sinon, vous prouvez que vous étiez irréprochable la semaine dernière. J’ai fait cette erreur une fois : j’ai utilisé une ancienne preuve pour vérifier une nouvelle liste, et le contrat m’a dit que tout était en ordre. J’en ai eu froid dans le dos. Depuis, j’ai appris à inclure le hachage de la version des données dans la preuve ; si la version ne correspond pas, la vérification échoue immédiatement. Le véritable obstacle n’est pas la cryptographie, mais la liste elle-même. Qui la gère, à quelle fréquence elle est mise à jour, si l’historique des modifications peut être audité : ce sont des questions opérationnelles, et tout le reste ne sert à rien si elles sont mal traitées. En outre, la reconnaissance juridique des preuves cryptographiques reste une zone grise, et les responsables de la conformité préfèrent toujours consulter un rapport portant un tampon officiel. Par rapport à la preuve de réserves de Chainlink, cette solution est plus flexible : elle permet d’exécuter n’importe quelle requête SQL, et pas seulement d’additionner des soldes. En contrepartie, il faut assumer soi-même tout le travail d’ingénierie nécessaire aux preuves. À mon avis, cette approche sera d’abord adoptée par les acteurs de la RWA et les dépositaires, car ce qui leur manque le plus, c’est précisément ce moyen de prouver leur conformité sans rien divulguer. Pour aller vraiment loin, il faudra aussi combiner les preuves à divulgation nulle de connaissance sur les plages de valeurs et les preuves agrégées. On pourrait, par exemple, prouver à la fois que l’exposition totale est inférieure à une limite et qu’aucune contrepartie unique ne dépasse son plafond. Il n’existe pas encore d’outil prêt à l’emploi pour ce genre de cas : il faut assembler soi-même les pièces. Une fois cette couche bien rodée, le discours commercial des institutions changera : au lieu de dire « notre gestion des risques est très stricte », elles diront « vous pouvez le vérifier vous-même ». #sxt $SXT @SpaceandTime
