Une chaîne héberge une foule de tables de bases de données, mais elle-même ne stocke presque aucune donnée. La première fois que j’ai découvert cette conception, j’ai cru que c’était de la paresse. Plus j’y réfléchissais, plus je me disais que c’était intentionnel.
Sur la SXT Chain, on ne stocke que l’engagement cryptographique de chaque table — on peut le voir comme son empreinte. Les données proprement dites restent hors chaîne. Les requêtes et les preuves sont confiées aux nœuds Prover, qui renvoient les résultats avec les preuves une fois la recherche terminée. Le vérificateur compare alors le tout à l’empreinte pour savoir si les données ont été modifiées. Le détail essentiel, c’est que cette empreinte peut être mise à jour : quand de nouvelles données arrivent, on peut calculer la nouvelle empreinte à partir de l’ancienne et de ces nouvelles données, sans avoir à revenir parcourir les données historiques. Les tables peuvent donc s’étoffer sans que la chaîne ne grossisse avec elles.
Mon avis : cette retenue est à la fois son idée la plus astucieuse et son plus grand pari. Astucieuse, parce qu’elle ne cherche pas du tout à rivaliser avec Ethereum ou Solana sur l’exécution généraliste : elle leur cède directement ce terrain pour se concentrer sur ce qui manque le plus aux contrats, à savoir la capacité de poser des questions. Le pari, c’est qu’une chaîne qui ne fait que gérer des engagements de données tire toute sa valeur du fait que « quelqu’un est prêt à payer régulièrement pour des requêtes vérifiables ». Même si une chaîne généraliste est peu active, elle peut toujours compter sur d’autres applications ; elle, n’a pas de filet de sécurité. Si la demande ne vient pas, ce ne sera qu’une très belle chaîne vide.
Il y a un autre aspect que je trouve sous-estimé : les validateurs doivent mettre en jeu du SXT et peuvent être pénalisés en cas de comportement malveillant. Les motifs de sanction incluent la falsification d’engagements, l’impossibilité de vérifier les résultats d’une requête et des réponses trop lentes. En clair, ici, la sécurité ne consiste pas seulement à empêcher la double dépense : elle vise aussi à empêcher que « les données soient modifiées en douce ». C’est une autre conception de la sécurité.
Alors, pour l’évaluer, je ne regarde pas le TPS, mais deux choses : les requêtes réelles augmentent-elles de façon continue, et qui paie exactement ? La première mesure la demande ; la seconde permet de savoir si cette demande est réelle ou simplement gonflée par des subventions.
La viabilité de cette voie, @SpaceandTime , et la captation de valeur de $SXT reposent entièrement là-dessus. #SXT
#sxt $SXT
Sur la SXT Chain, on ne stocke que l’engagement cryptographique de chaque table — on peut le voir comme son empreinte. Les données proprement dites restent hors chaîne. Les requêtes et les preuves sont confiées aux nœuds Prover, qui renvoient les résultats avec les preuves une fois la recherche terminée. Le vérificateur compare alors le tout à l’empreinte pour savoir si les données ont été modifiées. Le détail essentiel, c’est que cette empreinte peut être mise à jour : quand de nouvelles données arrivent, on peut calculer la nouvelle empreinte à partir de l’ancienne et de ces nouvelles données, sans avoir à revenir parcourir les données historiques. Les tables peuvent donc s’étoffer sans que la chaîne ne grossisse avec elles.
Mon avis : cette retenue est à la fois son idée la plus astucieuse et son plus grand pari. Astucieuse, parce qu’elle ne cherche pas du tout à rivaliser avec Ethereum ou Solana sur l’exécution généraliste : elle leur cède directement ce terrain pour se concentrer sur ce qui manque le plus aux contrats, à savoir la capacité de poser des questions. Le pari, c’est qu’une chaîne qui ne fait que gérer des engagements de données tire toute sa valeur du fait que « quelqu’un est prêt à payer régulièrement pour des requêtes vérifiables ». Même si une chaîne généraliste est peu active, elle peut toujours compter sur d’autres applications ; elle, n’a pas de filet de sécurité. Si la demande ne vient pas, ce ne sera qu’une très belle chaîne vide.
Il y a un autre aspect que je trouve sous-estimé : les validateurs doivent mettre en jeu du SXT et peuvent être pénalisés en cas de comportement malveillant. Les motifs de sanction incluent la falsification d’engagements, l’impossibilité de vérifier les résultats d’une requête et des réponses trop lentes. En clair, ici, la sécurité ne consiste pas seulement à empêcher la double dépense : elle vise aussi à empêcher que « les données soient modifiées en douce ». C’est une autre conception de la sécurité.
Alors, pour l’évaluer, je ne regarde pas le TPS, mais deux choses : les requêtes réelles augmentent-elles de façon continue, et qui paie exactement ? La première mesure la demande ; la seconde permet de savoir si cette demande est réelle ou simplement gonflée par des subventions.
La viabilité de cette voie, @SpaceandTime , et la captation de valeur de $SXT reposent entièrement là-dessus. #SXT
#sxt $SXT