#sxt $SXT @SpaceandTime
Chaque fois que j’essaie de vérifier combien j’ai dépensé en café l’année dernière, mon application bancaire se bloque si je fais défiler au-delà de quatre-vingt-dix jours. Pour consulter des données plus anciennes, elle m’oblige à demander un relevé PDF mensuel et à attendre. C’est tout simplement ainsi que la plupart des systèmes à état restent rapides. On garde les données récentes et fréquemment consultées à portée de main et on relègue l’historique dans un sous-sol glacial, en partant du principe que personne n’aura besoin de calculer trois années de données au beau milieu d’un paiement en cours.
Les contrats intelligents sont soumis exactement à cette limitation. Un protocole de prêt ou un hook Uniswap ne voit que les variables d’état actuelles, et non ce qu’un portefeuille a fait il y a six mois. Si un agent automatisé ou un fonds tokenisé a besoin de connaître le volume de transactions historique sur plusieurs pools, il doit généralement attendre qu’un indexeur offchain fasse les calculs et renvoie un chiffre non vérifié onchain.
Space and Time tente de contourner ce goulot d’étranglement grâce à Proof of SQL. Lorsqu’un contrat ou une application demande une requête portant sur des données historiques, un prouveur offchain exécute le calcul SQL sur les métadonnées de tables engagées et génère une preuve à divulgation nulle de connaissance à l’aide de processeurs graphiques. Le résultat et la preuve cryptographique sont renvoyés à un contrat vérificateur onchain. Si le prouveur omet une ligne ou truque les calculs, la vérification échoue et le contrat rejette le résultat.
Au début, je pensais que cela conférait aux contrats intelligents une mémoire instantanée et gratuite. Mais quand on examine le processus, on constate qu’il transforme en réalité un problème de stockage d’état en compromis entre coordination et latence. Le contrat vérificateur vérifie rapidement la preuve, mais l’appelant doit tout de même attendre un rappel asynchrone pendant que le prouveur offchain construit les calculs polynomiaux, et quelqu’un doit payer le gas pour vérifier cette preuve sur la chaîne de destination. Le coût de la consultation de l’historique ne disparaît pas : il passe simplement du stockage permanent onchain au calcul par requête et au délai du rappel. Je me demande encore à quel point le délai disponible dans un bloc peut se réduire avant qu’un échange DeFi ne devance la génération de la preuve.
Avertissement : l’achat de SXT comporte des risques. Nous vous encourageons à faire vos propres recherches (DYOR) et à consulter un professionnel avant d’acheter du SXT ou toute autre cryptomonnaie.
Chaque fois que j’essaie de vérifier combien j’ai dépensé en café l’année dernière, mon application bancaire se bloque si je fais défiler au-delà de quatre-vingt-dix jours. Pour consulter des données plus anciennes, elle m’oblige à demander un relevé PDF mensuel et à attendre. C’est tout simplement ainsi que la plupart des systèmes à état restent rapides. On garde les données récentes et fréquemment consultées à portée de main et on relègue l’historique dans un sous-sol glacial, en partant du principe que personne n’aura besoin de calculer trois années de données au beau milieu d’un paiement en cours.
Les contrats intelligents sont soumis exactement à cette limitation. Un protocole de prêt ou un hook Uniswap ne voit que les variables d’état actuelles, et non ce qu’un portefeuille a fait il y a six mois. Si un agent automatisé ou un fonds tokenisé a besoin de connaître le volume de transactions historique sur plusieurs pools, il doit généralement attendre qu’un indexeur offchain fasse les calculs et renvoie un chiffre non vérifié onchain.
Space and Time tente de contourner ce goulot d’étranglement grâce à Proof of SQL. Lorsqu’un contrat ou une application demande une requête portant sur des données historiques, un prouveur offchain exécute le calcul SQL sur les métadonnées de tables engagées et génère une preuve à divulgation nulle de connaissance à l’aide de processeurs graphiques. Le résultat et la preuve cryptographique sont renvoyés à un contrat vérificateur onchain. Si le prouveur omet une ligne ou truque les calculs, la vérification échoue et le contrat rejette le résultat.
Au début, je pensais que cela conférait aux contrats intelligents une mémoire instantanée et gratuite. Mais quand on examine le processus, on constate qu’il transforme en réalité un problème de stockage d’état en compromis entre coordination et latence. Le contrat vérificateur vérifie rapidement la preuve, mais l’appelant doit tout de même attendre un rappel asynchrone pendant que le prouveur offchain construit les calculs polynomiaux, et quelqu’un doit payer le gas pour vérifier cette preuve sur la chaîne de destination. Le coût de la consultation de l’historique ne disparaît pas : il passe simplement du stockage permanent onchain au calcul par requête et au délai du rappel. Je me demande encore à quel point le délai disponible dans un bloc peut se réduire avant qu’un échange DeFi ne devance la génération de la preuve.
Avertissement : l’achat de SXT comporte des risques. Nous vous encourageons à faire vos propres recherches (DYOR) et à consulter un professionnel avant d’acheter du SXT ou toute autre cryptomonnaie.