#sxt $SXT @SpaceandTime Une adresse a emprunté trois fois sur Ethereum et tout remboursé à temps ; elle a été liquidée une fois sur une autre chaîne ; et elle a effectué des dépôts à long terme pendant deux ans dans un troisième protocole. Ces données sont dispersées entre différentes chaînes et différents contrats, et au moment d’accorder un prêt, le protocole ne voit que le solde actuel de l’emprunteur : tous sont des inconnus, soumis au même taux de garantie.
Si le crédit on-chain ne se développe pas, le problème ne vient pas des fonds, mais de la confiance. La finance traditionnelle s’appuie sur les dossiers de prêts hypothécaires, les flux de trésorerie et l’historique de remboursement pour fixer ses tarifs. Toutes ces données existent en réalité déjà on-chain, mais personne ne peut les assembler de manière fiable ni prouver que le résultat obtenu n’a pas été altéré.
@SpaceandTime change ce point de départ : l’historique des activités sur plusieurs chaînes et protocoles est rassemblé en un dossier consultable et vérifiable — emprunts, remboursements et liquidations passés, rétablissement après liquidation, ainsi que protocoles sur lesquels l’adresse a été active à long terme. Le résultat est ensuite transmis on-chain au moyen de preuves à divulgation nulle de connaissance, afin que le contrat puisse le vérifier lui-même au lieu de faire confiance à une interface de programmation d’application en arrière-plan.
Sur le plan technique, le système repose sur trois couches : les données on-chain sont enregistrées intégralement (y compris les transactions et les journaux d’événements des contrats), l’historique des chaînes EVM peut être interrogé directement en SQL, et les résultats des requêtes sont certifiés par Proof of SQL. L’appel du protocole ressemble à une simple lecture de données, avec une couche supplémentaire de vérifiabilité.
Les changements se reflètent dans les paramètres : exigences de garantie, taux d’intérêt, plafonds et listes d’autorisation varient en fonction des comportements prouvés, au lieu d’être fixés uniformément par un vote de gouvernance. Les adresses ayant un historique de remboursement irréprochable obtiennent des exigences de garantie plus faibles ; celles qui ont été liquidées à plusieurs reprises doivent fournir une marge de sécurité plus importante ; les déposants de longue date bénéficient de plafonds plus élevés. Même principe pour la distribution : elle est calculée en fonction des comportements réels, et la lutte contre les attaques Sybil passe de la « conjecture » au « calcul ».
La dimension de la confidentialité est tout aussi essentielle : une requête n’a pas besoin de révéler l’identité réelle derrière une adresse, ni de rendre publics les mécanismes de gestion des risques. Ce qui est prouvé, c’est que « le calcul n’a pas été altéré », et non que « vos données sont exposées ». Pour les fonds institutionnels, c’est souvent cette distinction qui détermine s’ils osent ou non passer on-chain.
Il faut toutefois bien en comprendre les limites : la vérifiabilité garantit que « les données et le calcul n’ont pas été altérés », mais ne résout pas la question de savoir si « le passé permet de prédire l’avenir ». La gestion des risques doit toujours être conçue, testée rétrospectivement et améliorée ; elle repose simplement enfin sur des données d’entrée qui ne peuvent pas être discrètement réécrites.
Le crédit n’a jamais été une question de solde, mais de temps. Pour que le crédit on-chain se développe vraiment, la première étape consiste à rendre les « antécédents » dignes de confiance.
Si le crédit on-chain ne se développe pas, le problème ne vient pas des fonds, mais de la confiance. La finance traditionnelle s’appuie sur les dossiers de prêts hypothécaires, les flux de trésorerie et l’historique de remboursement pour fixer ses tarifs. Toutes ces données existent en réalité déjà on-chain, mais personne ne peut les assembler de manière fiable ni prouver que le résultat obtenu n’a pas été altéré.
@SpaceandTime change ce point de départ : l’historique des activités sur plusieurs chaînes et protocoles est rassemblé en un dossier consultable et vérifiable — emprunts, remboursements et liquidations passés, rétablissement après liquidation, ainsi que protocoles sur lesquels l’adresse a été active à long terme. Le résultat est ensuite transmis on-chain au moyen de preuves à divulgation nulle de connaissance, afin que le contrat puisse le vérifier lui-même au lieu de faire confiance à une interface de programmation d’application en arrière-plan.
Sur le plan technique, le système repose sur trois couches : les données on-chain sont enregistrées intégralement (y compris les transactions et les journaux d’événements des contrats), l’historique des chaînes EVM peut être interrogé directement en SQL, et les résultats des requêtes sont certifiés par Proof of SQL. L’appel du protocole ressemble à une simple lecture de données, avec une couche supplémentaire de vérifiabilité.
Les changements se reflètent dans les paramètres : exigences de garantie, taux d’intérêt, plafonds et listes d’autorisation varient en fonction des comportements prouvés, au lieu d’être fixés uniformément par un vote de gouvernance. Les adresses ayant un historique de remboursement irréprochable obtiennent des exigences de garantie plus faibles ; celles qui ont été liquidées à plusieurs reprises doivent fournir une marge de sécurité plus importante ; les déposants de longue date bénéficient de plafonds plus élevés. Même principe pour la distribution : elle est calculée en fonction des comportements réels, et la lutte contre les attaques Sybil passe de la « conjecture » au « calcul ».
La dimension de la confidentialité est tout aussi essentielle : une requête n’a pas besoin de révéler l’identité réelle derrière une adresse, ni de rendre publics les mécanismes de gestion des risques. Ce qui est prouvé, c’est que « le calcul n’a pas été altéré », et non que « vos données sont exposées ». Pour les fonds institutionnels, c’est souvent cette distinction qui détermine s’ils osent ou non passer on-chain.
Il faut toutefois bien en comprendre les limites : la vérifiabilité garantit que « les données et le calcul n’ont pas été altérés », mais ne résout pas la question de savoir si « le passé permet de prédire l’avenir ». La gestion des risques doit toujours être conçue, testée rétrospectivement et améliorée ; elle repose simplement enfin sur des données d’entrée qui ne peuvent pas être discrètement réécrites.
Le crédit n’a jamais été une question de solde, mais de temps. Pour que le crédit on-chain se développe vraiment, la première étape consiste à rendre les « antécédents » dignes de confiance.