Le problème qu’elle veut résoudre est très direct :
Quand une tâche, des données, un message ou une opération on-chain est exécuté(e) par un certain système, qui va prouver que c’est bien vrai, correct, et que rien n’a été altéré par un nœud centralisé ?
DeepSafe se positionne comme suit :
Universal Verification Layer, la couche universelle de validation.
📍 En essence, elle veut mettre en place un réseau de validation indépendant.
Peu importe que la couche supérieure soit un agent IA, un protocole inter-chaînes, une application, ou tout autre système nécessitant une exécution fiable : DeepSafe veut fournir une couche de validation externe.
En clair, ça veut dire :
Un système dit “j’ai fini”, DeepSafe se charge de vérifier —
Comment le prouver ?
🗝️ 1. Quel problème DeepSafe résout-il réellement ?
Aujourd’hui, beaucoup d’applications s’appuient en fait sur un modèle de confiance très simple :
Le serveur vous dit quel est le résultat, et vous le croyez par défaut.
Un nœud vous dit que le message a déjà été exécuté, et vous le croyez par défaut.
Un système renvoie un résultat, et vous supposez qu’il n’a pas de mauvaises intentions.
Dans des scénarios à faible valeur, ce n’est pas un gros problème.
Mais dès qu’il est question de fonds, d’actifs, de cross-chain ou d’exécution automatisée, le risque de confiance en un seul point commence à s’amplifier.
Donc ce que veut faire DeepSafe, ce n’est pas d’accomplir lui-même toutes ces tâches.
Il ajoute une couche au traitement des tâches :
La vérifiabilité.
Par exemple :
Un agent a exécuté une transaction.
DeepSafe ne s’occupe pas d’exécuter les transactions à sa place ; il vérifie le résultat de l’exécution.
Un certain système transmet un message cross-chain.
DeepSafe ne se charge pas de décider du contenu du message : il vérifie seulement si ce message a été produit correctement et transmis correctement.
Un certain résultat de calcul doit être adopté par d’autres systèmes.
DeepSafe espère que les utilisateurs n’auront pas simplement à croire le fournisseur des résultats.
C’est la logique centrale de sa “couche de vérification”.
📍2. Qu’est-ce que CRVA ?
Le cœur de DeepSafe est le réseau de vérification CRVA.
On y impliquera différentes technologies comme Ring VRF, MPC, TEE, ZKP, etc.
Ces noms en anglais semblent compliqués, mais en réalité, il ne faut pas les imaginer comme quelque chose de mystérieux.
On peut le décomposer simplement en plusieurs choses :
🔻 Sélection aléatoire des validateurs, réduisant le risque de contrôle à long terme d’un système à nœuds fixes ;
🔻 Plusieurs parties prenantes réalisent ensemble la vérification, évitant que le résultat dépende entièrement d’un seul acteur ;
🔻 En tirant parti d’environnements d’exécution fiables comme le TEE, on réduit la probabilité d’une ingérence externe pendant l’exécution ;
🔻 Puis, grâce à des outils cryptographiques comme les ZKP, fournir une preuve vérifiable du résultat.
En combinant tout cela, au final, l’objectif revient à une seule question :
Comment réduire au maximum le risque qu’“un nœud décide de tout”.
Je pense que c’est le point le plus important pour comprendre DeepSafe.
Il y a beaucoup de termes techniques, mais dans l’essentiel, le projet n’est pas si complexe.
Il fait :
la vérification décentralisée.
🗝️ 3. Pourquoi l’appeler “couche de vérification universelle” ?
car DeepSafe ne souhaite pas être lié uniquement à un seul scénario.
Si c’est juste pour fournir une vérification à un certain AI Agent, cela ressemble en fait à un plugin d’agent.
S’il ne sert qu’au cross-chain, il ressemble davantage à un Bridge Verification Network.
Mais ce que DeepSafe veut faire, c’est plutôt une couche plus bas niveau :
Tant qu’un système existe avec un besoin du type “le résultat doit être validé par un tiers”, il peut théoriquement s’y raccorder.
Donc ce qu’il met en avant, c’est l’Universal.
C’est aussi une réflexion d’infrastructure assez typique de ce projet :
Il ne produit pas directement le produit final ; il fournit des capacités de confiance au système de niveau supérieur.
Si cette position arrive finalement à fonctionner, sa valeur ne dépendra pas seulement de la réussite d’une application donnée : elle dépendra du fait qu’il puisse devenir un réseau de vérification que différents systèmes appellent en commun.
Évidemment, c’est aussi un point difficile.
“Universel” signifie plafond élevé.
Mais cela signifie aussi qu’il faut être compatible avec davantage de scénarios, ainsi qu’avec les besoins des développeurs et des activités.
📍4. DeepSafe n’est pas un projet d’IA qui s’est reconverti subitement
Je pense que cela mérite d’être dit à part.
Le prédécesseur de DeepSafe, c’est Bool Network.
À partir de 2024, l’équipe avance déjà sur des axes comme le réseau de vérification, le BTC cross-chain, le TEE, CRVA, etc.
Autrement dit, aujourd’hui, il parle de la vérification, mais ce n’est pas parce qu’après que l’AI Agent est devenu à la mode, ils auraient soudain emballé l’ancien projet dans une idée d’IA.
À l’origine, il étudiait déjà l’exécution et la vérification fiables.
À l’heure actuelle, le DeepSafe Beta Mainnet est déjà en fonctionnement.
Son token natif est DEF, avec un total de 1 milliard de jetons.
On peut aussi voir sur GitHub une trace de développement continu.
Auparavant, le projet avait aussi divulgué un financement Seed de 3 millions de dollars, avec des investisseurs incluant Antalpha Ventures, ViaBTC Capital, Gate Ventures, Spark Digital Capital, CKB Eco Fund, etc.
Au moins si l’on regarde la chronologie, sa trajectoire technique est continue.
C’est bien plus solide que de “changer de nom pour surfer sur l’IA”.
🗝️ 5. Je pense que ce que DeepSafe cherche vraiment à prouver n’est pas la technologie, mais la demande
Les projets de ce type de réseau de vérification ont souvent un problème :
La technique semble très complète.
Il y a de la cryptographie, du TEE, du MPC, du ZK : tout y est.
Le schéma d’architecture est aussi très beau.
Mais à la fin, il n’y a pas assez d’applications disposées à appeler.
C’est là le risque le plus important.
Parce qu’une infrastructure doit finalement répondre à une question :
Qui accepterait de payer pour cette infrastructure ?
Pour DeepSafe, je pense que la chose la plus intéressante à observer ensuite n’est pas simplement combien de modules techniques on ajoute.
Ce n’est pas plutôt quelques indicateurs plus concrets :
Y a-t-il des cas d’usage réels qui appellent en continu le réseau de vérification ;
Le volume des demandes de vérification peut-il augmenter ;
Dans les scénarios IA, cross-chain ou d’automatisation on-chain, y a-t-il vraiment une demande irréductible ;
Les développeurs sont-ils prêts à assumer un surcoût de vérification et une latence supplémentaires ;
Et est-ce que DEF pourra finalement créer un lien réel avec l’usage du réseau.
Ces choses sont plus importantes que l’annonce de quelques partenariats.
📍Donc, si maintenant je devais donner une position à DeepSafe :
Je vais le considérer comme un projet d’infrastructure qui soutient la croissance d’exigences relatives au “calcul vérifiable / exécution vérifiable”.
Son avantage est que la trajectoire est relativement cohérente, et que le projet dispose déjà d’un socle technique acquis à l’époque du Bool Network ; ce n’est pas une construction à partir de zéro.
Mais son problème est aussi très typique :
La couche de vérification deviendra-t-elle un marché réellement indépendant et suffisamment vaste ?
On ne peut pas encore conclure à l’avance.
Ce que DeepSafe doit prouver n’est pas “que la vérification est importante”.
Cette proposition n’est pas vraiment controversée.
La vraie difficulté, c’est :
Le marché est-il prêt à payer spécialement pour la vérification ?
Si à l’avenir il parvient réellement à passer d’un “réseau de vérification technique” à une infrastructure appelée par un grand nombre d’applications, alors le projet aura franchi l’étape la plus critique.
Avant cela, je serais plutôt disposé à le mettre sur une liste d’observation.
La voie technique est déjà tracée ; ensuite, il faut voir l’adoption.