Publier
KAZ_0
·
--
J’ai passé les derniers jours à me pencher sur Space and Time $SXT , et en réalité, le sujet n’a rien à voir avec l’engouement autour des jetons. Tout tourne autour du goulot d’étranglement des données.
Les contrats intelligents ne sont utiles qu’autant que les informations auxquelles ils peuvent accéder. Des données erronées en entrée donnent des résultats erronés en sortie. Une application DeFi peut avoir besoin de vérifier l’activité d’un portefeuille sur plusieurs chaînes, ou un produit d’IA peut devoir vérifier la provenance de ses données. Pour y parvenir, les développeurs s’appuient encore largement sur des indexeurs, des API, des fournisseurs RPC et des bases de données centralisées. Ça fonctionne, mais il subsiste un problème de confiance.
C’est là que Proof of SQL de Space and Time a retenu mon attention. Cette solution permet aux développeurs d’exécuter des requêtes SQL hors chaîne et de générer des preuves cryptographiques attestant que les calculs ont été effectués correctement à partir de données engagées. Les opérations lourdes se déroulent hors chaîne. Le résultat peut ensuite être vérifié par une application ou un contrat intelligent.
C’est une utilisation assez intéressante de la technologie ZK. Pas juste un nouvel acronyme dans une présentation commerciale.
Je constate aussi que les données vérifiables suscitent davantage d’intérêt à mesure que les actifs tokenisés et les agents d’IA prennent une place plus importante dans le Web3. Ces applications ont besoin d’informations fiables, surtout lorsque de l’argent réel est en jeu.
Il y a toutefois une chose qui m’intrigue vraiment : l’adoption par les développeurs. Les indexeurs et les fournisseurs de données existants sont déjà profondément intégrés à de nombreux projets. Les équipes ne changent pas d’infrastructure du jour au lendemain.
La technologie me semble pertinente, mais c’est dans sa mise en œuvre que Space and Time devra faire ses preuves. Je suivrai de plus près l’utilisation réelle et l’adhésion des développeurs que les fluctuations à court terme du $SXT cours.
Aux développeurs ici présents : qu’est-ce qui vous ferait vraiment abandonner votre indexeur actuel ? Des requêtes moins coûteuses, ou attendez-vous de voir si les coûts supplémentaires liés à la ZK ralentissent les choses ?
#sxt $SXT @SpaceandTime
Les contrats intelligents ne sont utiles qu’autant que les informations auxquelles ils peuvent accéder. Des données erronées en entrée donnent des résultats erronés en sortie. Une application DeFi peut avoir besoin de vérifier l’activité d’un portefeuille sur plusieurs chaînes, ou un produit d’IA peut devoir vérifier la provenance de ses données. Pour y parvenir, les développeurs s’appuient encore largement sur des indexeurs, des API, des fournisseurs RPC et des bases de données centralisées. Ça fonctionne, mais il subsiste un problème de confiance.
C’est là que Proof of SQL de Space and Time a retenu mon attention. Cette solution permet aux développeurs d’exécuter des requêtes SQL hors chaîne et de générer des preuves cryptographiques attestant que les calculs ont été effectués correctement à partir de données engagées. Les opérations lourdes se déroulent hors chaîne. Le résultat peut ensuite être vérifié par une application ou un contrat intelligent.
C’est une utilisation assez intéressante de la technologie ZK. Pas juste un nouvel acronyme dans une présentation commerciale.
Je constate aussi que les données vérifiables suscitent davantage d’intérêt à mesure que les actifs tokenisés et les agents d’IA prennent une place plus importante dans le Web3. Ces applications ont besoin d’informations fiables, surtout lorsque de l’argent réel est en jeu.
Il y a toutefois une chose qui m’intrigue vraiment : l’adoption par les développeurs. Les indexeurs et les fournisseurs de données existants sont déjà profondément intégrés à de nombreux projets. Les équipes ne changent pas d’infrastructure du jour au lendemain.
La technologie me semble pertinente, mais c’est dans sa mise en œuvre que Space and Time devra faire ses preuves. Je suivrai de plus près l’utilisation réelle et l’adhésion des développeurs que les fluctuations à court terme du $SXT cours.
Aux développeurs ici présents : qu’est-ce qui vous ferait vraiment abandonner votre indexeur actuel ? Des requêtes moins coûteuses, ou attendez-vous de voir si les coûts supplémentaires liés à la ZK ralentissent les choses ?
#sxt $SXT @SpaceandTime
