Un professeur m’a dit un jour qu’une bonne réponse à la mauvaise question reste une mauvaise réponse. Pour une raison ou une autre, cette phrase m’est revenue en lisant comment fonctionne Space and Time. L’idée est assez simple. Les données provenant de chaînes, d’entreprises ou de jeux de données externes sont inscrites dans des tables, puis un prouveur démontre que la requête SQL a été correctement exécutée sur ces engagements. Ainsi, une application ou un contrat intelligent peut se fier au résultat sans jamais voir les données brutes. Franchement, cette partie est ingénieuse, surtout pour les agents d’IA et les applications financières qui ne peuvent pas simplement transmettre leurs données 👏 Mais voici ce qui me chiffonne… la preuve ne couvre que la requête, pas les données sous-jacentes. Si de mauvaises données sont engagées, on obtient une réponse erronée parfaitement prouvée. Dans le contexte décentralisé, les validateurs signent ces engagements ; j’aimerais donc savoir quelle part de cette étape repose réellement sur leur honnêteté. Côté entreprise, c’est encore plus frappant, car l’entreprise génère elle-même ses engagements locaux : on fait donc à nouveau confiance au propriétaire des données, simplement avec des maths plus élégantes. Alors, qui vérifie les données en entrée avant qu’elles ne soient engagées ? Et combien coûte la preuve, en temps et en argent, lorsque les requêtes deviennent lourdes ? Je ne dis pas que cela invalide quoi que ce soit. Prouver le calcul est une véritable avancée, et beaucoup de projets ne vont même pas jusque-là. Malgré tout, une preuve me fait penser à un reçu, et un reçu n’a de valeur que si le commerçant était honnête au départ. Je regarde comment $SXT gère ce problème…👀
@SpaceandTime #sxt
$AGT $MAGMA