Le calcul vérifiable et la vérité vérifiée ne sont pas la même chose, et cette distinction est plus importante que la plupart des gens ne le pensent.
Space and Time a développé Proof of SQL, un système de preuve à divulgation nulle de connaissance dans lequel un prouveur exécute une requête SQL sur des données engagées cryptographiquement et génère une preuve. Un vérificateur, qu’il s’agisse d’un contrat intelligent on-chain ou d’un client off-chain, peut alors vérifier que le résultat correspond à la requête spécifiée et au jeu de données engagé, sans avoir à réexécuter la requête. Cela comble une véritable faille de confiance au niveau du calcul.
Voici un exemple hypothétique pour illustrer cette limite : imaginez qu’un fonds immobilier tokenisé stocke les chiffres de ses réserves dans une table Space and Time. Dans cet exemple, Proof of SQL pourrait vérifier une requête qui additionne les réserves enregistrées pour le fonds. Il ne peut pas établir si ces données correspondent aux actifs réels détenus off-chain. La preuve porte sur l’intégrité du calcul, et non sur la question de savoir si les données externes reflètent la réalité.
C’est important dans les domaines de l’IA, de la tokenisation et de la DeFi, car tous trois reposent sur la récupération de données à grande échelle. Un agent d’IA qui interroge des données analytiques on-chain peut s’assurer que les résultats n’ont pas été altérés entre la base de données et leur transmission. Un protocole DeFi qui vérifie les ratios de garantie bénéficie de la même assurance. La couche de saisie des données reste un défi distinct, auquel les oracles, les audits ou d’autres mécanismes doivent répondre. Comprendre où commencent et où s’arrêtent les garanties de la preuve permet de distinguer une analyse éclairée du battage médiatique.
#sxt $SXT @SpaceandTime
Space and Time a développé Proof of SQL, un système de preuve à divulgation nulle de connaissance dans lequel un prouveur exécute une requête SQL sur des données engagées cryptographiquement et génère une preuve. Un vérificateur, qu’il s’agisse d’un contrat intelligent on-chain ou d’un client off-chain, peut alors vérifier que le résultat correspond à la requête spécifiée et au jeu de données engagé, sans avoir à réexécuter la requête. Cela comble une véritable faille de confiance au niveau du calcul.
Voici un exemple hypothétique pour illustrer cette limite : imaginez qu’un fonds immobilier tokenisé stocke les chiffres de ses réserves dans une table Space and Time. Dans cet exemple, Proof of SQL pourrait vérifier une requête qui additionne les réserves enregistrées pour le fonds. Il ne peut pas établir si ces données correspondent aux actifs réels détenus off-chain. La preuve porte sur l’intégrité du calcul, et non sur la question de savoir si les données externes reflètent la réalité.
C’est important dans les domaines de l’IA, de la tokenisation et de la DeFi, car tous trois reposent sur la récupération de données à grande échelle. Un agent d’IA qui interroge des données analytiques on-chain peut s’assurer que les résultats n’ont pas été altérés entre la base de données et leur transmission. Un protocole DeFi qui vérifie les ratios de garantie bénéficie de la même assurance. La couche de saisie des données reste un défi distinct, auquel les oracles, les audits ou d’autres mécanismes doivent répondre. Comprendre où commencent et où s’arrêtent les garanties de la preuve permet de distinguer une analyse éclairée du battage médiatique.
#sxt $SXT @SpaceandTime
