pa
Je réfléchissais aux raisons pour lesquelles les contrats intelligents ont encore du mal à prendre des décisions à partir de l’activité passée sur la blockchain.
Prenons un protocole de prêt. Deux portefeuilles peuvent avoir exactement le même solde actuel, mais leur historique peut être complètement différent. L’un peut avoir des années d’emprunts et de remboursements responsables à son actif, tandis que l’autre a été créé hier.
Le contrat peut voir leur état actuel. Mais comment évalue-t-il tout ce qui s’est passé auparavant ?
C’est là que j’ai commencé à examiner de plus près @SpaceandTime
Ce qui a retenu mon attention, ce n’était pas simplement le fait qu’il utilise Proof of SQL. C’était la façon dont un contrat intelligent reçoit concrètement un résultat sans avoir à effectuer lui-même le calcul sur la base de données.
Il y a ici une distinction importante.
Un contrat intelligent ne devient pas soudainement une base de données. Il envoie un plan de requête SQL précompilé au QueryRouter de Space and Time, accompagné d’un paiement et d’une cible de rappel.
La requête est exécutée sur les tables de SXT Chain. Le système génère une preuve Proof of SQL en même temps que le résultat, et cette preuve est vérifiée sur la chaîne avant que le résultat soit renvoyé au contrat qui en a fait la demande.
Mais le rappel est un autre aspect intéressant.
Le contrat destinataire doit vérifier que la réponse provient bien de l’exécuteur de routeur autorisé, puis décoder les données renvoyées avant de les utiliser.
Autrement dit, recevoir des données et agir dessus en toute sécurité sont deux étapes différentes.
Cela change ma façon de concevoir l’architecture. Le calcul lourd est effectué en dehors du contrat demandeur, tandis que la vérification cryptographique permet au contrat de se fier au résultat renvoyé sans traiter lui-même l’ensemble des données. Space and Time +1
Attendez, il y a encore un autre aspect que je ne veux pas négliger.
Une preuve valide ne signifie pas automatiquement que les informations d’origine étaient vraies.
Si des informations erronées sont introduites dans une base de données lors de l’ingestion, prouver qu’un calcul SQL a été correctement effectué sur ces données validées ne corrige pas comme par magie l’erreur initiale. L’intégrité des données et leur exactitude sont liées, mais elles ne sont pas identiques. Preuve .
@SpaceandTime #sxt $SXT
Je réfléchissais aux raisons pour lesquelles les contrats intelligents ont encore du mal à prendre des décisions à partir de l’activité passée sur la blockchain.
Prenons un protocole de prêt. Deux portefeuilles peuvent avoir exactement le même solde actuel, mais leur historique peut être complètement différent. L’un peut avoir des années d’emprunts et de remboursements responsables à son actif, tandis que l’autre a été créé hier.
Le contrat peut voir leur état actuel. Mais comment évalue-t-il tout ce qui s’est passé auparavant ?
C’est là que j’ai commencé à examiner de plus près @SpaceandTime
Ce qui a retenu mon attention, ce n’était pas simplement le fait qu’il utilise Proof of SQL. C’était la façon dont un contrat intelligent reçoit concrètement un résultat sans avoir à effectuer lui-même le calcul sur la base de données.
Il y a ici une distinction importante.
Un contrat intelligent ne devient pas soudainement une base de données. Il envoie un plan de requête SQL précompilé au QueryRouter de Space and Time, accompagné d’un paiement et d’une cible de rappel.
La requête est exécutée sur les tables de SXT Chain. Le système génère une preuve Proof of SQL en même temps que le résultat, et cette preuve est vérifiée sur la chaîne avant que le résultat soit renvoyé au contrat qui en a fait la demande.
Mais le rappel est un autre aspect intéressant.
Le contrat destinataire doit vérifier que la réponse provient bien de l’exécuteur de routeur autorisé, puis décoder les données renvoyées avant de les utiliser.
Autrement dit, recevoir des données et agir dessus en toute sécurité sont deux étapes différentes.
Cela change ma façon de concevoir l’architecture. Le calcul lourd est effectué en dehors du contrat demandeur, tandis que la vérification cryptographique permet au contrat de se fier au résultat renvoyé sans traiter lui-même l’ensemble des données. Space and Time +1
Attendez, il y a encore un autre aspect que je ne veux pas négliger.
Une preuve valide ne signifie pas automatiquement que les informations d’origine étaient vraies.
Si des informations erronées sont introduites dans une base de données lors de l’ingestion, prouver qu’un calcul SQL a été correctement effectué sur ces données validées ne corrige pas comme par magie l’erreur initiale. L’intégrité des données et leur exactitude sont liées, mais elles ne sont pas identiques. Preuve .
@SpaceandTime #sxt $SXT
