« Natif pour l'IA » s'écrit facilement comme une liste de fonctionnalités : quelques opcodes de plus, un réseau de GPU et une étiquette ZK. Une meilleure question est de savoir quelles tâches liées à l'IA la machine à états on-chain doit prendre en charge nativement, ce qui doit rester hors ligne, et pourquoi le débit de règlement demeure un prérequis. Cet article cartographie les frontières de capacité — non les adjectifs de vision.
Natif par rapport à quoi
Une intégration superficielle signifie généralement : un contrat récupère un résultat de modèle via un oracle ou une API centralisée et l'écrit dans l'état. La latence, les hypothèses de confiance et la composabilité reposent toutes du côté de l'oracle ; la chaîne ne contraint guère quel modèle a été exécuté ni si les entrées ont été remplacées.
Une voie plus « native » comprend généralement au moins trois éléments :
- Des primitives liées à l'IA exprimables par les contrats (extensions, précompilations ou interfaces standard), au lieu de réinventer un pont privé à chaque fois ;
- L'exécution hybride : des étapes légères et vérifiables on-chain ou à proximité ; l'entraînement lourd et l'inférence de grande taille sur un réseau de calcul, avec des preuves ou des fenêtres de contestation renvoyées au règlement ;
- Une séparation nette d'avec le règlement : un EVM parallèle élargit les transitions d'état des contrats ; il n'enfourne pas un entraînement de cent milliards de paramètres dans l'exécution des blocs.
Pour la carte de la pile, voir La pile d'IA décentralisée ; pour les lacunes de confiance, voir Convergence entre le Web3 et l'IA.
Extensions d'instructions ou de précompilations : la compatibilité d'abord
Si la VM expose des primitives de tenseurs ou d'apprentissage profond, des contraintes raisonnables sont :
- Sur-ensemble, pas fork : les chemins de bytecode EVM standard restent utilisables afin que les contrats DeFi/NFT existants ne se cassent pas parce que la chaîne est « à thème IA » ; les extensions occupent un espace d'opcodes ou de précompilations distinct.
- Correspondance avec l'accélération matérielle : les primitives doivent s'exécuter sur des chemins SIMD/GPU, et non sur une simulation « native » purement logicielle et lente dans l'interpréteur.
- Outillage reproductible : la conversion de modèles, la quantification (par ex. INT8/FP16), les SDK et les profileurs doivent reproduire les mêmes résultats ; sinon le « natif » n'existe que dans le livre blanc.
Les documents publics citent souvent des observations d'ingénierie, comme de modestes compromis de précision pour un débit d'inférence multiplié sous des modèles et un matériel donnés — et non un SLA universel. Les frontières de compatibilité elles-mêmes sont traitées dans Ce que signifie la compatibilité EVM.
Méfiez-vous des affirmations laissant entendre que des modèles arbitrairement grands peuvent exécuter des passes avant complètes sur l'ensemble du jeu de validateurs et entrer dans l'état canonique. Cela déverse le non-déterminisme, l'hétérogénéité matérielle et le coût de bande passante directement dans les hypothèses de sécurité du consensus.
Exécution hybride : router selon la complexité
Tout le calcul d'IA n'a pas sa place on-chain. Une intuition de routage plus stable :
| Forme de charge | Voie plus pertinente | Ce qui reste on-chain |
|---|---|---|
| Vérifications de contraintes petites et répétables | On-chain ou précompilation | Le changement d'état lui-même |
| Inférence de taille moyenne / tranches d'ajustement fin | Hors ligne + acceptation légère | Hachage de tâche, acceptation, paiement |
| Entraînement à grande échelle | Réseau de calcul + acceptation forte (échantillonnage/ZK/TEE) | Engagements de tâche et de preuve, paiements |
La sélection des nœuds peut combiner réputation, mise et aléa vérifiable (VRF) pour réduire la manipulation ; les tâches critiques peuvent recourir à une exécution indépendante multipartite et à un accord majoritaire. Ce sont des options de conception dont la robustesse dépend du modèle de menace — et non du nombre d'options disponibles.
L'exécution hybride est le même problème découpé différemment dans Calcul distribué GPU et edge et Cadre d'informatique de confiance : cycle de vie contre hypothèses de preuve.
Réseaux de calcul distribué : rassembler de la capacité, pas des mythes
Le parallélisme de données, de modèle et de pipeline relève d'un vocabulaire mature de l'entraînement distribué ; le filtrage byzantin des gradients, les points de contrôle et la reprise sur incident sont des biens communs de l'ingénierie. Lorsqu'ils entrent dans un récit de chaîne, gardez les frontières :
- Les limites d'interconnexion et de VRAM ne disparaissent pas parce que quelque chose est « on-chain » ;
- Des incitations versées uniquement pour le temps de disponibilité glissent vers le minage inflationniste, et non vers un marché du calcul auditable ;
- La couche de règlement (EVM parallèle optimiste) fournit le débit et les attentes de finalité pour les machines à états des tâches et les paiements — voir Vue d'ensemble de l'architecture EVM parallèle de Bitroot et Positionnement de Bitroot.
La latence de confirmation et le TPS du testnet décrivent le substrat de règlement ; ils ne se traduisent pas en « vitesse d'entraînement ». Comment lire les métriques : Glossaire des métriques de performance.
Informatique de confiance et droits : deux autres briques natives
L'intégrité, la confidentialité et le calcul conjoint multipartite reposent sur des combinaisons ZK/TEE/MPC — et non sur un slogan de plus sur la « sécurité d'entreprise ». Les revenus exécutables des données et des modèles nécessitent des métadonnées on-chain, des permissions et des machines à états de paiement — voir Droits sur les actifs d'IA.
Ordre de livraison suggéré
Un ordre plus stable : règlement prévisible → tâches/paiements avec acceptation légère → TEE/ZK selon le modèle de menace → droits/marchés complexes. Divulguez séparément : les benchmarks de règlement (taux de conflit), la latence d'achèvement du calcul (matériel), le temps de preuve/vérification (circuit/enclave). Une affiche « TPS de chaîne IA » induit tout le monde en erreur. Charges de travail critiques : Points chauds de conflit et charges de travail.
Pour la migration d'applications Ethereum, le natif pour l'IA ne doit pas rompre les chaînes d'outils par défaut. Des précompilations étendues peuvent accélérer la vérification de preuves, mais la voie principale doit préserver Hardhat/Foundry et les hypothèses d'audit — sinon le « natif » devient une « réécriture ». Compatibilité : Ce que signifie la compatibilité EVM ; mécanique optimiste : Mécanique de la parallélisation optimiste.
L'outillage décide si le « natif » est livré
Sans outils reproductibles de conversion, de quantification, de simulation et de débogage, les extensions d'instructions restent des spécifications à l'état de projet. Les développeurs ont besoin d'une relecture déterministe locale des transactions touchant les extensions ; d'une visibilité sur testnet des décisions de routage hybride ; et d'un échec franc lorsque les preuves manquent — et non d'un repli silencieux vers une API centralisée. La maturité de l'outillage doit être divulguée en même temps que les listes d'opcodes.
Les extensions natives ne doivent pas rompre les attentes de bytecode ni les hypothèses d'audit des contrats Solidity existants. Le comptage du gaz, les codes d'erreur et la gouvernance des mises à niveau des nouvelles précompilations doivent figurer dans la spécification — sinon le « natif pour l'IA » devient une surprise de hard fork. Compatibilité : Ce que signifie la compatibilité EVM. Parallélisme de règlement : Parallélisation optimiste.
La ligne rouge entre non-déterminisme et état canonique
Si les extensions natives pour l'IA introduisent de la virgule flottante dépendante du matériel, l'état canonique se scinde. Les spécifications doivent préciser quelles primitives peuvent se trouver sur le chemin critique du consensus, lesquelles doivent s'exécuter hors ligne puis être validées, si la quantification ou l'arrondi est obligatoire, et comment les nœuds sans GPU vérifient ou ignorent. Sans cela, le « natif » devient une confiance implicite dans les nœuds haut de gamme.
Les testnets doivent couvrir la vérification sans accélérateur, la relecture déterministe des transactions d'extension et un échec visible en cas de mauvais routage hybride. Les objectifs de débit doivent préciser si les charges d'extension sont incluses, afin d'éviter les confusions avec des bases de pur transfert. Métriques : Glossaire des métriques de performance.
Un « natif pour l'IA » livrable signifie des spécifications, un outillage et un routage hybride reproductibles de manière indépendante ; non livrable signifie une dégradation honnête vers des expérimentations de précompilations et des interfaces de marché du calcul. Les deux ont de la valeur ; ils ne doivent pas partager une formulation absolue.
Une livraison par étapes vaut mieux qu'une méga-définition
Livrez d'abord des expérimentations de précompilations, des contrats de règlement de tâches et des marchés d'inférence avec vérifications ponctuelles ; itérez ensuite la couverture des instructions et des preuves plus fortes. Lier « ISA IA complet + réseau d'entraînement mondial + droits universels » en un seul jalon rend chacun d'eux inacceptable indépendamment. Des plans par phases avec modèles de menace et conditions de performance constituent la voie d'ingénierie du natif pour l'IA.
À retenir
Une chaîne de blocs native pour l'IA et vérifiable ressemble à ceci : des primitives étendues reproductibles sous contraintes de compatibilité, une exécution hybride routée par le coût, des réseaux de calcul avec acceptation, et une couche de règlement assez rapide et prévisible pour les agents et les machines de tâches. Retirez l'un de ces éléments et le « natif » retombe au niveau de la colle d'oracle. Ceci n'est pas un conseil en investissement ; traitez les chiffres de débit et de latence comme des objectifs de test ou d'ingénierie jusqu'à ce qu'ils soient reproductibles de manière indépendante dans des conditions de mainnet adverses.