#opg $OPG La plupart des projets « IA + blockchain » se contentent de déposer le résultat du modèle sur la chaîne, mais personne ne peut vérifier si le résultat est correct. Le livre blanc d’OpenGradient met en évidence la contradiction centrale : les blockchains traditionnelles reposent sur « la réexécution des transactions par chaque nœud » pour parvenir à un consensus ; sur le plan logique, le transfert de fonds n’y pose aucun problème, mais appliqué à l’inférence d’IA, cela ne fonctionne tout simplement pas.
Pourquoi ? Exécuter un LLM nécessite des GPU : si 100 nœuds de validation exécutent chacun l’inférence, le coût est multiplié par 100 ; la sortie du LLM comporte de l’aléa, donc les nœuds de validation ne peuvent pas simplement vérifier la réponse ; une inférence prend quelques secondes, et pendant que tous les nœuds ont terminé, la chaîne a déjà pris du retard. Utiliser l’IA comme une oracles — exécuter le résultat hors chaîne puis l’alimenter sur la chaîne — revient à un « problème d’oracle inversé » : au final, il faut faire confiance au seul acteur qui a fourni les données.
La solution d’OpenGradient : séparer l’exécution et la vérification. Les nœuds d’inférence traitent la requête dans un TEE et génèrent une preuve matérielle — garantissant que le code de la preuve n’a pas été modifié, que l’entrée n’a pas été altérée et que la sortie n’a pas été manipulée. Les nœuds complets ne font que valider la preuve (opérations cryptographiques pures), sans avoir besoin de connaître les prompts, le modèle ou le contenu renvoyé. ZKML fait la même chose, simplement avec des preuves à connaissance zéro. La couche de vérification ne ré-exécute jamais le calcul de l’IA ; vérifier une preuve ne prend que quelques millisecondes.
Le réseau comprend quatre types de nœuds : nœuds d’inférence (exécution GPU), nœuds complets (validation des preuves + consensus CometBFT), nœuds de données (TEE récupérant des données externes) et couche de stockage. Compatible avec EVM : les développeurs peuvent appeler directement via Hardhat, Foundry.
L’offre totale d’OPG est de 1 milliard de jetons, répartis comme suit : écosystème 40 %, fondation 15 %, contributeurs principaux 15 %, investisseurs 10 %, récompenses de staking 10 %, liquidité 6 %, airdrop 4 %. Sert à payer les frais d’inférence, le staking des nœuds, l’incitation aux modèles, et la gouvernance.
Risques : le TEE dépend des fabricants de matériel ; s’il existe des vulnérabilités, la confiance accordée aux preuves en sera affectée ; le coût de génération des preuves ZKML n’est pas favorable pour les scénarios à faible latence ; le déblocage de 1 milliard de jetons sur le long terme peut entraîner une pression vendeuse.
Mon avis : OpenGradient reconstruit la couche de vérification autour des besoins réels de l’IA, avec une cohérence logique. Mais les performances réelles doivent être validées par des données du mainnet ; la direction vaut la peine d’être suivie.
Le TEE + ZKML peuvent-ils résoudre le problème de la « boîte noire » de l’IA ? Discutons-en dans la section commentaires. @OpenGradient
Pourquoi ? Exécuter un LLM nécessite des GPU : si 100 nœuds de validation exécutent chacun l’inférence, le coût est multiplié par 100 ; la sortie du LLM comporte de l’aléa, donc les nœuds de validation ne peuvent pas simplement vérifier la réponse ; une inférence prend quelques secondes, et pendant que tous les nœuds ont terminé, la chaîne a déjà pris du retard. Utiliser l’IA comme une oracles — exécuter le résultat hors chaîne puis l’alimenter sur la chaîne — revient à un « problème d’oracle inversé » : au final, il faut faire confiance au seul acteur qui a fourni les données.
La solution d’OpenGradient : séparer l’exécution et la vérification. Les nœuds d’inférence traitent la requête dans un TEE et génèrent une preuve matérielle — garantissant que le code de la preuve n’a pas été modifié, que l’entrée n’a pas été altérée et que la sortie n’a pas été manipulée. Les nœuds complets ne font que valider la preuve (opérations cryptographiques pures), sans avoir besoin de connaître les prompts, le modèle ou le contenu renvoyé. ZKML fait la même chose, simplement avec des preuves à connaissance zéro. La couche de vérification ne ré-exécute jamais le calcul de l’IA ; vérifier une preuve ne prend que quelques millisecondes.
Le réseau comprend quatre types de nœuds : nœuds d’inférence (exécution GPU), nœuds complets (validation des preuves + consensus CometBFT), nœuds de données (TEE récupérant des données externes) et couche de stockage. Compatible avec EVM : les développeurs peuvent appeler directement via Hardhat, Foundry.
L’offre totale d’OPG est de 1 milliard de jetons, répartis comme suit : écosystème 40 %, fondation 15 %, contributeurs principaux 15 %, investisseurs 10 %, récompenses de staking 10 %, liquidité 6 %, airdrop 4 %. Sert à payer les frais d’inférence, le staking des nœuds, l’incitation aux modèles, et la gouvernance.
Risques : le TEE dépend des fabricants de matériel ; s’il existe des vulnérabilités, la confiance accordée aux preuves en sera affectée ; le coût de génération des preuves ZKML n’est pas favorable pour les scénarios à faible latence ; le déblocage de 1 milliard de jetons sur le long terme peut entraîner une pression vendeuse.
Mon avis : OpenGradient reconstruit la couche de vérification autour des besoins réels de l’IA, avec une cohérence logique. Mais les performances réelles doivent être validées par des données du mainnet ; la direction vaut la peine d’être suivie.
Le TEE + ZKML peuvent-ils résoudre le problème de la « boîte noire » de l’IA ? Discutons-en dans la section commentaires. @OpenGradient
