Que ce soit nécessaire de vérifier l'IA dépend de : si les données on-chain sont modifiées, et si l'équité et la confidentialité sont impliquées
Écosystème d'application AI vertical : Comme une extrémité de l'AI vérifiable est un contrat intelligent, les applications AI vérifiables et même les dapps AI et natives peuvent être en mesure de s'utiliser mutuellement sans confiance. Il s'agit d'un écosystème potentiel d'application AI composable
Modulus Labs est une société d'IA "sur chaîne" qui croit que l'IA peut améliorer considérablement les capacités des contrats intelligents et rendre les applications web3 plus puissantes. Cependant, il y a une contradiction lorsque l'IA est appliquée à web3, c'est-à-dire que l'IA nécessite une grande quantité de puissance de calcul pour fonctionner, et l'IA est une boîte noire pour le calcul hors chaîne. Cela ne répond pas aux exigences de base de web3 en matière de confiance et de vérifiabilité.
Ainsi, Modulus Labs s'est appuyé sur le schéma zk rollup [prétraitement hors chaîne+vérification sur chaîne] et a proposé une architecture pouvant vérifier l'IA. Plus précisément, le modèle ML s'exécute hors chaîne, et en outre, un zkp est généré pour le processus de calcul ML hors chaîne. Grâce à ce zkp, l'architecture, les poids et les entrées (inputs) du modèle hors chaîne peuvent être vérifiés. Bien sûr, ce zkp peut également être publié sur la chaîne pour vérification par des contrats intelligents. À ce stade, l'IA et les contrats sur chaîne peuvent interagir de manière plus fiable, c'est-à-dire que l '«IA sur chaîne» a été réalisée.
Basé sur l'idée d'une IA vérifiable, Modulus Labs a lancé jusqu'à présent trois applications "d'IA sur chaîne", et a également proposé de nombreux scénarios d'application possibles.
De plus, Modulus Labs a mentionné quelques autres cas d'utilisation :
Crédit photo: Modulus Labs
Dans le scénario du bot Rocky, les utilisateurs peuvent ne pas être tenus de vérifier le processus de calcul de l'IA. Premièrement, les utilisateurs n'ont pas les compétences ni la capacité de faire une véritable vérification. Même s'il existe un outil de vérification, selon l'opinion de l'utilisateur, "Je presse un bouton, l'interface s'affiche pour me dire que ce service d'IA a en fait été généré par un certain modèle", et l'authenticité ne peut pas être déterminée. Deuxièmement, les utilisateurs n'ont pas besoin de vérifier, car ils se soucient de savoir si le rendement de l'IA est élevé. Les utilisateurs migrent lorsque la rentabilité est faible, et ils choisissent toujours le modèle qui fonctionne le mieux. En bref, lorsque le résultat final de l'IA correspond à ce que l'utilisateur recherche, le processus de vérification peut ne pas être significatif car l'utilisateur n'a besoin que de migrer vers le service qui fonctionne le mieux.
**Une solution possible est que l'IA agisse uniquement en tant que conseiller, et l'utilisateur exécute la transaction de manière indépendante. **Lorsque les gens saisissent leurs objectifs de trading dans l'IA, l'IA calcule et retourne un meilleur chemin de transaction/direction de trade hors chaîne, et l'utilisateur choisit s'il doit l'exécuter. Les gens n'ont pas non plus besoin de vérifier le modèle derrière cela; ils ont juste besoin de choisir le produit avec le rendement le plus élevé.
Une autre situation dangereuse mais très probable est que les gens se soucient peu de leur contrôle sur les actifs ou du processus de calcul de l'IA. Lorsqu'un robot qui gagne automatiquement de l'argent apparaît, les gens sont même prêts à lui confier directement de l'argent, tout comme ils mettent des jetons dans une CEX ou des banques traditionnelles pour la gestion financière. Parce que les gens ne se soucient pas des principes qui le sous-tendent; ils se soucient seulement de la somme d'argent qu'ils obtiennent à la fin, ou même de la somme d'argent que la partie projet leur montre à gagner, ce type de service peut rapidement acquérir un grand nombre d'utilisateurs, et même itérer plus rapidement que les produits côté projet qui utilisent une IA vérifiable.
En prenant du recul, si l'IA ne participe pas du tout aux changements d'état on-chain, mais se contente de collecter des données on-chain et de les prétraiter pour les utilisateurs, alors il n'est pas nécessaire de générer des ZKP pour le processus de calcul. Voici quelques exemples de ce type d'application en tant que "service de données":
Cet article soutient que les scénarios impliquant plusieurs personnes, impliquant l'équité et la confidentialité, nécessitent ZKP pour fournir une vérification, et plusieurs des applications mentionnées par Modulus Labs sont discutées ici :
En règle générale, lorsque l'IA est similaire à un décideur, et que sa production a une large influence et implique l'équité de nombreuses parties, les gens demanderont un examen du processus décisionnel, ou simplement garantir qu'il n'y a pas de problèmes majeurs avec le processus de décision de l'IA, et protéger la vie privée est une exigence très immédiate.
Par conséquent, "que la sortie de l'IA modifie l'état on-chain" et "qu'elle affecte l'équité/la vie privée" sont deux critères pour juger si une solution d'IA vérifiable est nécessaire
Crédit photo : Kernel Ventures
En tout cas, la solution de Modulus Labs est très instructive sur la manière dont l'IA peut combiner la crypto et apporter une valeur d'application pratique. Cependant, le système de chaîne publique améliore non seulement les capacités des services d'IA individuels, mais a également le potentiel de construire un nouvel écosystème d'application d'IA. Cet nouvel écosystème a entraîné une relation différente entre les services d'IA par rapport à Web2, la relation entre les services d'IA et les utilisateurs, et même la manière dont les liens amont et aval collaborent. Nous pouvons résumer les modèles d'écosystème d'application d'IA potentiels en deux types : le mode vertical et le modèle horizontal.
Le cas d'utilisation d'échecs en chaîne "Leela vs. the World" occupe une place spéciale. Les gens peuvent parier sur des humains ou sur une IA, et les jetons sont automatiquement distribués après la fin du jeu. À ce stade, le sens de zkp n'est pas seulement pour que les utilisateurs vérifient les calculs de l'IA, mais aussi comme une garantie de confiance pour déclencher des transitions d'état on-chain. Avec l'assurance de confiance, il peut également y avoir une composabilité au niveau des dapps entre les services d'IA et entre l'IA et les dapps natifs de la crypto.
Source de l'image: Kernel Ventures, avec référence de Modulus Labs
L'unité de base de l'IA combinable est [modèle ML hors chaîne - génération zkp - contrat de vérification sur chaîne - contrat principal]. Cette unité s'appuie sur le cadre "Leela vs. the World", mais l'architecture réelle d'une seule application IA peut ne pas être la même que celle montrée dans l'image ci-dessus. Tout d'abord, la situation du jeu d'échecs dans les échecs nécessite un contrat, mais en réalité, l'IA peut ne pas avoir besoin d'un contrat sur chaîne. Cependant, en ce qui concerne l'architecture de l'IA combinable, si l'activité principale est enregistrée à travers des contrats, il peut être plus pratique pour d'autres applications de la combiner avec elle. Deuxièmement, le contrat principal n'a pas nécessairement besoin d'affecter le modèle ML de l'application IA elle-même, car une application IA peut avoir un effet unidirectionnel. Après que le modèle ML soit traité, il suffit de déclencher un contrat lié à son propre activité, et le contrat sera appelé par d'autres applications.
De manière extensive, les appels entre contrats sont des appels entre différentes applications web3. Ce sont des appels pour l'identité personnelle, les actifs, les services financiers, et même les informations sociales. Nous pouvons imaginer une combinaison spécifique d'applications d'IA :
L'interaction entre l'IA dans le cadre de la chaîne publique n'est pas quelque chose qui n'a pas été discuté. Loaf, un contributeur à l'écosystème Realms des jeux à chaîne complète, a proposé une fois que les PNJ d'IA peuvent commercer entre eux comme les joueurs, de sorte que l'ensemble du système économique puisse s'optimiser lui-même et fonctionner automatiquement. AI Arena a développé un jeu de bataille automatisé par IA. Les utilisateurs achètent d'abord un NFT. Un NFT représente un robot de combat, et un modèle IA est derrière. Les utilisateurs jouent d'abord à des jeux par eux-mêmes, puis transmettent les données à l'IA pour un apprentissage simulé. Lorsque les utilisateurs estiment que l'IA est assez forte, ils peuvent jouer automatiquement contre d'autres IA dans l'arène. Modulus Labs a mentionné que AI Arena veut transformer tout cela en IA vérifiable. Ces deux cas ont vu la possibilité pour l'IA d'interagir les unes avec les autres et de modifier directement les données de la chaîne au fur et à mesure de leur interaction.
Cependant, il reste encore de nombreuses questions à discuter dans la mise en œuvre spécifique de l'IA combinable, comme la façon dont différents dapps peuvent utiliser les zkp de l'autre ou vérifier les contrats. Cependant, il existe également de nombreux projets excellents dans le domaine zk. Par exemple, RISC Zero a réalisé beaucoup de progrès dans l'exécution de calculs complexes hors chaîne et la libération de zkp vers la chaîne. Peut-être qu'un jour, il sera possible de mettre en place une solution appropriée.
2.2 Modèle horizontal: plateformes de services d'IA axées sur la décentralisation
À cet égard, nous présentons principalement une plateforme d'IA décentralisée appelée SAKSHI, qui a été conjointement proposée par des personnes de Princeton, de l'Université Tsinghua, de l'Université de l'Illinois à Urbana-Champaign, de l'Université de Hong Kong pour la Science et la Technologie, de Witness Chain et d'Eigen Layer. Son objectif principal est de permettre aux utilisateurs d'accéder aux services d'IA de manière plus décentralisée, rendant l'ensemble du processus plus décentralisé et automatisé.
Crédit photo: SAKSHI
La structure de SAKSHI peut être divisée en six couches : couche de service (couche de service), couche de contrôle (couche de contrôle), couche de transaction (couche de transaction), couche de preuve (couche de preuve), couche économique (couche économique) et couche de marché (Marketplace)
Le marché est le niveau le plus proche de l'utilisateur. Il y a des agrégateurs sur le marché pour fournir des services aux utilisateurs au nom de différents fournisseurs d'IA. Les utilisateurs passent des commandes par le biais des agrégateurs et concluent des accords avec les agrégateurs sur la qualité des services et les prix de paiement (les accords sont appelés SLA - accords de niveau de service).
Ensuite, la couche de service fournit une API pour le côté client, puis le client fait une demande d'inférence ML à l'agrégateur, et la demande est envoyée à un serveur utilisé pour faire correspondre le fournisseur de services IA (la route utilisée pour transmettre la demande fait partie de la couche de contrôle). Par conséquent, la couche de service et la couche de contrôle sont similaires à un service avec plusieurs serveurs web2, mais les serveurs différents sont exploités par des entités différentes, et chaque serveur est lié par le biais d'un SLA (accord de service précédemment signé) et d'un agrégateur.
Les SLA sont déployés sur la chaîne sous forme de contrats intelligents, qui appartiennent tous à la couche de transaction (note : dans cette solution, ils sont déployés sur la chaîne de témoin). La couche de transaction enregistre également le statut actuel d'une commande de service et est utilisée pour coordonner les utilisateurs, les agrégateurs et les fournisseurs de services pour traiter les litiges de paiement.
Afin que la couche de transaction dispose de preuves sur lesquelles s'appuyer en cas de litige, la couche de preuve (Proof Layer) vérifiera si le fournisseur de services utilise le modèle tel qu'accepté dans l'ASL. Cependant, SAKSHI n'a pas choisi de générer un zkp pour le processus de calcul ML, mais a plutôt utilisé l'idée de preuve optimiste, espérant établir un réseau de nœuds challengers pour tester le service. Les incitations des nœuds sont prises en charge par Witness Chain.
Bien que SLA et le réseau de nœuds challenger soient sur Witness Chain, dans le plan de SAKSHI, Witness Chain ne prévoit pas d'utiliser ses incitations en jetons natifs pour assurer une sécurité indépendante, mais utilise plutôt la sécurité d'Ethereum via Eigen Layer, de sorte que toute l'économie repose en réalité sur Eigen Layer.
Comme on peut le voir, SAKSHI se situe entre les fournisseurs de services d'IA et les utilisateurs, et organise différents AIs de manière décentralisée pour fournir des services aux utilisateurs. Il s'agit plus d'une solution horizontale. Le cœur de SAKSHI est qu'il permet aux fournisseurs de services d'IA de se concentrer davantage sur la gestion de leurs propres calculs de modèle hors chaîne, l'association des besoins des utilisateurs avec les services de modèle, le paiement des services, et la vérification de la qualité des services grâce à des accords sur chaîne, et tente de résoudre automatiquement les litiges de paiement. Bien sûr, à l'heure actuelle, SAKSHI en est encore au stade théorique, et il y a également de nombreux détails d'implémentation qui méritent d'être déterminés.
Que ce soit l'IA combinable ou les plateformes d'IA décentralisées, le modèle d'écosystème d'IA basé sur la chaîne publique semble avoir quelque chose en commun. Par exemple, les fournisseurs de services d'IA ne se connectent pas directement avec les utilisateurs ; ils ont seulement besoin de fournir des modèles ML et d'effectuer des calculs hors chaîne. Les paiements, la résolution des litiges et la coordination entre les besoins des utilisateurs et les services peuvent tous être résolus par des accords décentralisés. En tant qu'infrastructure sans confiance, la chaîne publique réduit les frictions entre les fournisseurs de services et les utilisateurs, et les utilisateurs ont également une plus grande autonomie à ce moment.
Bien que les avantages de l'utilisation de la chaîne publique comme base d'application soient des clichés, il est vrai que cela s'applique également aux services d'IA. Cependant, la différence entre les applications d'IA et les applications dapp existantes est que les applications d'IA ne peuvent pas placer toutes les calculs sur la chaîne, il est donc nécessaire d'utiliser des preuves zk ou optimistes pour connecter les services d'IA au système de chaîne publique de manière plus décentralisée.
Avec la mise en œuvre d'une série de solutions d'optimisation de l'expérience telles que l'abstraction de compte, les utilisateurs peuvent ne pas être en mesure de percevoir l'existence de mnémoniques, de chaînes et de gaz. Cela rapproche l'écosystème de la chaîne publique de web2 en termes d'expérience, tandis que les utilisateurs peuvent obtenir un degré de liberté et de composition plus élevé que les services web2. Cela sera très attractif pour les utilisateurs. L'écosystème d'application d'IA basé sur la chaîne publique mérite d'être attendu avec impatience.
Kernel Ventures est un fonds de capital-risque crypto piloté par une communauté de recherche et développement avec plus de 70 investissements en phase précoce axés sur l'infrastructure, les middleware, les dApps, en particulier ZK, Rollup, DEX, les blockchains modulaires, et les verticaux qui accueilleront les prochains milliards d'utilisateurs de crypto, tels que l'abstraction de compte, la disponibilité des données, la scalabilité, etc. Au cours des sept dernières années, nous nous sommes engagés à soutenir le développement des communautés de développement de base et des associations universitaires de blockchain à travers le monde.
Avertissement:
Que ce soit nécessaire de vérifier l'IA dépend de : si les données on-chain sont modifiées, et si l'équité et la confidentialité sont impliquées
Écosystème d'application AI vertical : Comme une extrémité de l'AI vérifiable est un contrat intelligent, les applications AI vérifiables et même les dapps AI et natives peuvent être en mesure de s'utiliser mutuellement sans confiance. Il s'agit d'un écosystème potentiel d'application AI composable
Modulus Labs est une société d'IA "sur chaîne" qui croit que l'IA peut améliorer considérablement les capacités des contrats intelligents et rendre les applications web3 plus puissantes. Cependant, il y a une contradiction lorsque l'IA est appliquée à web3, c'est-à-dire que l'IA nécessite une grande quantité de puissance de calcul pour fonctionner, et l'IA est une boîte noire pour le calcul hors chaîne. Cela ne répond pas aux exigences de base de web3 en matière de confiance et de vérifiabilité.
Ainsi, Modulus Labs s'est appuyé sur le schéma zk rollup [prétraitement hors chaîne+vérification sur chaîne] et a proposé une architecture pouvant vérifier l'IA. Plus précisément, le modèle ML s'exécute hors chaîne, et en outre, un zkp est généré pour le processus de calcul ML hors chaîne. Grâce à ce zkp, l'architecture, les poids et les entrées (inputs) du modèle hors chaîne peuvent être vérifiés. Bien sûr, ce zkp peut également être publié sur la chaîne pour vérification par des contrats intelligents. À ce stade, l'IA et les contrats sur chaîne peuvent interagir de manière plus fiable, c'est-à-dire que l '«IA sur chaîne» a été réalisée.
Basé sur l'idée d'une IA vérifiable, Modulus Labs a lancé jusqu'à présent trois applications "d'IA sur chaîne", et a également proposé de nombreux scénarios d'application possibles.
De plus, Modulus Labs a mentionné quelques autres cas d'utilisation :
Crédit photo: Modulus Labs
Dans le scénario du bot Rocky, les utilisateurs peuvent ne pas être tenus de vérifier le processus de calcul de l'IA. Premièrement, les utilisateurs n'ont pas les compétences ni la capacité de faire une véritable vérification. Même s'il existe un outil de vérification, selon l'opinion de l'utilisateur, "Je presse un bouton, l'interface s'affiche pour me dire que ce service d'IA a en fait été généré par un certain modèle", et l'authenticité ne peut pas être déterminée. Deuxièmement, les utilisateurs n'ont pas besoin de vérifier, car ils se soucient de savoir si le rendement de l'IA est élevé. Les utilisateurs migrent lorsque la rentabilité est faible, et ils choisissent toujours le modèle qui fonctionne le mieux. En bref, lorsque le résultat final de l'IA correspond à ce que l'utilisateur recherche, le processus de vérification peut ne pas être significatif car l'utilisateur n'a besoin que de migrer vers le service qui fonctionne le mieux.
**Une solution possible est que l'IA agisse uniquement en tant que conseiller, et l'utilisateur exécute la transaction de manière indépendante. **Lorsque les gens saisissent leurs objectifs de trading dans l'IA, l'IA calcule et retourne un meilleur chemin de transaction/direction de trade hors chaîne, et l'utilisateur choisit s'il doit l'exécuter. Les gens n'ont pas non plus besoin de vérifier le modèle derrière cela; ils ont juste besoin de choisir le produit avec le rendement le plus élevé.
Une autre situation dangereuse mais très probable est que les gens se soucient peu de leur contrôle sur les actifs ou du processus de calcul de l'IA. Lorsqu'un robot qui gagne automatiquement de l'argent apparaît, les gens sont même prêts à lui confier directement de l'argent, tout comme ils mettent des jetons dans une CEX ou des banques traditionnelles pour la gestion financière. Parce que les gens ne se soucient pas des principes qui le sous-tendent; ils se soucient seulement de la somme d'argent qu'ils obtiennent à la fin, ou même de la somme d'argent que la partie projet leur montre à gagner, ce type de service peut rapidement acquérir un grand nombre d'utilisateurs, et même itérer plus rapidement que les produits côté projet qui utilisent une IA vérifiable.
En prenant du recul, si l'IA ne participe pas du tout aux changements d'état on-chain, mais se contente de collecter des données on-chain et de les prétraiter pour les utilisateurs, alors il n'est pas nécessaire de générer des ZKP pour le processus de calcul. Voici quelques exemples de ce type d'application en tant que "service de données":
Cet article soutient que les scénarios impliquant plusieurs personnes, impliquant l'équité et la confidentialité, nécessitent ZKP pour fournir une vérification, et plusieurs des applications mentionnées par Modulus Labs sont discutées ici :
En règle générale, lorsque l'IA est similaire à un décideur, et que sa production a une large influence et implique l'équité de nombreuses parties, les gens demanderont un examen du processus décisionnel, ou simplement garantir qu'il n'y a pas de problèmes majeurs avec le processus de décision de l'IA, et protéger la vie privée est une exigence très immédiate.
Par conséquent, "que la sortie de l'IA modifie l'état on-chain" et "qu'elle affecte l'équité/la vie privée" sont deux critères pour juger si une solution d'IA vérifiable est nécessaire
Crédit photo : Kernel Ventures
En tout cas, la solution de Modulus Labs est très instructive sur la manière dont l'IA peut combiner la crypto et apporter une valeur d'application pratique. Cependant, le système de chaîne publique améliore non seulement les capacités des services d'IA individuels, mais a également le potentiel de construire un nouvel écosystème d'application d'IA. Cet nouvel écosystème a entraîné une relation différente entre les services d'IA par rapport à Web2, la relation entre les services d'IA et les utilisateurs, et même la manière dont les liens amont et aval collaborent. Nous pouvons résumer les modèles d'écosystème d'application d'IA potentiels en deux types : le mode vertical et le modèle horizontal.
Le cas d'utilisation d'échecs en chaîne "Leela vs. the World" occupe une place spéciale. Les gens peuvent parier sur des humains ou sur une IA, et les jetons sont automatiquement distribués après la fin du jeu. À ce stade, le sens de zkp n'est pas seulement pour que les utilisateurs vérifient les calculs de l'IA, mais aussi comme une garantie de confiance pour déclencher des transitions d'état on-chain. Avec l'assurance de confiance, il peut également y avoir une composabilité au niveau des dapps entre les services d'IA et entre l'IA et les dapps natifs de la crypto.
Source de l'image: Kernel Ventures, avec référence de Modulus Labs
L'unité de base de l'IA combinable est [modèle ML hors chaîne - génération zkp - contrat de vérification sur chaîne - contrat principal]. Cette unité s'appuie sur le cadre "Leela vs. the World", mais l'architecture réelle d'une seule application IA peut ne pas être la même que celle montrée dans l'image ci-dessus. Tout d'abord, la situation du jeu d'échecs dans les échecs nécessite un contrat, mais en réalité, l'IA peut ne pas avoir besoin d'un contrat sur chaîne. Cependant, en ce qui concerne l'architecture de l'IA combinable, si l'activité principale est enregistrée à travers des contrats, il peut être plus pratique pour d'autres applications de la combiner avec elle. Deuxièmement, le contrat principal n'a pas nécessairement besoin d'affecter le modèle ML de l'application IA elle-même, car une application IA peut avoir un effet unidirectionnel. Après que le modèle ML soit traité, il suffit de déclencher un contrat lié à son propre activité, et le contrat sera appelé par d'autres applications.
De manière extensive, les appels entre contrats sont des appels entre différentes applications web3. Ce sont des appels pour l'identité personnelle, les actifs, les services financiers, et même les informations sociales. Nous pouvons imaginer une combinaison spécifique d'applications d'IA :
L'interaction entre l'IA dans le cadre de la chaîne publique n'est pas quelque chose qui n'a pas été discuté. Loaf, un contributeur à l'écosystème Realms des jeux à chaîne complète, a proposé une fois que les PNJ d'IA peuvent commercer entre eux comme les joueurs, de sorte que l'ensemble du système économique puisse s'optimiser lui-même et fonctionner automatiquement. AI Arena a développé un jeu de bataille automatisé par IA. Les utilisateurs achètent d'abord un NFT. Un NFT représente un robot de combat, et un modèle IA est derrière. Les utilisateurs jouent d'abord à des jeux par eux-mêmes, puis transmettent les données à l'IA pour un apprentissage simulé. Lorsque les utilisateurs estiment que l'IA est assez forte, ils peuvent jouer automatiquement contre d'autres IA dans l'arène. Modulus Labs a mentionné que AI Arena veut transformer tout cela en IA vérifiable. Ces deux cas ont vu la possibilité pour l'IA d'interagir les unes avec les autres et de modifier directement les données de la chaîne au fur et à mesure de leur interaction.
Cependant, il reste encore de nombreuses questions à discuter dans la mise en œuvre spécifique de l'IA combinable, comme la façon dont différents dapps peuvent utiliser les zkp de l'autre ou vérifier les contrats. Cependant, il existe également de nombreux projets excellents dans le domaine zk. Par exemple, RISC Zero a réalisé beaucoup de progrès dans l'exécution de calculs complexes hors chaîne et la libération de zkp vers la chaîne. Peut-être qu'un jour, il sera possible de mettre en place une solution appropriée.
2.2 Modèle horizontal: plateformes de services d'IA axées sur la décentralisation
À cet égard, nous présentons principalement une plateforme d'IA décentralisée appelée SAKSHI, qui a été conjointement proposée par des personnes de Princeton, de l'Université Tsinghua, de l'Université de l'Illinois à Urbana-Champaign, de l'Université de Hong Kong pour la Science et la Technologie, de Witness Chain et d'Eigen Layer. Son objectif principal est de permettre aux utilisateurs d'accéder aux services d'IA de manière plus décentralisée, rendant l'ensemble du processus plus décentralisé et automatisé.
Crédit photo: SAKSHI
La structure de SAKSHI peut être divisée en six couches : couche de service (couche de service), couche de contrôle (couche de contrôle), couche de transaction (couche de transaction), couche de preuve (couche de preuve), couche économique (couche économique) et couche de marché (Marketplace)
Le marché est le niveau le plus proche de l'utilisateur. Il y a des agrégateurs sur le marché pour fournir des services aux utilisateurs au nom de différents fournisseurs d'IA. Les utilisateurs passent des commandes par le biais des agrégateurs et concluent des accords avec les agrégateurs sur la qualité des services et les prix de paiement (les accords sont appelés SLA - accords de niveau de service).
Ensuite, la couche de service fournit une API pour le côté client, puis le client fait une demande d'inférence ML à l'agrégateur, et la demande est envoyée à un serveur utilisé pour faire correspondre le fournisseur de services IA (la route utilisée pour transmettre la demande fait partie de la couche de contrôle). Par conséquent, la couche de service et la couche de contrôle sont similaires à un service avec plusieurs serveurs web2, mais les serveurs différents sont exploités par des entités différentes, et chaque serveur est lié par le biais d'un SLA (accord de service précédemment signé) et d'un agrégateur.
Les SLA sont déployés sur la chaîne sous forme de contrats intelligents, qui appartiennent tous à la couche de transaction (note : dans cette solution, ils sont déployés sur la chaîne de témoin). La couche de transaction enregistre également le statut actuel d'une commande de service et est utilisée pour coordonner les utilisateurs, les agrégateurs et les fournisseurs de services pour traiter les litiges de paiement.
Afin que la couche de transaction dispose de preuves sur lesquelles s'appuyer en cas de litige, la couche de preuve (Proof Layer) vérifiera si le fournisseur de services utilise le modèle tel qu'accepté dans l'ASL. Cependant, SAKSHI n'a pas choisi de générer un zkp pour le processus de calcul ML, mais a plutôt utilisé l'idée de preuve optimiste, espérant établir un réseau de nœuds challengers pour tester le service. Les incitations des nœuds sont prises en charge par Witness Chain.
Bien que SLA et le réseau de nœuds challenger soient sur Witness Chain, dans le plan de SAKSHI, Witness Chain ne prévoit pas d'utiliser ses incitations en jetons natifs pour assurer une sécurité indépendante, mais utilise plutôt la sécurité d'Ethereum via Eigen Layer, de sorte que toute l'économie repose en réalité sur Eigen Layer.
Comme on peut le voir, SAKSHI se situe entre les fournisseurs de services d'IA et les utilisateurs, et organise différents AIs de manière décentralisée pour fournir des services aux utilisateurs. Il s'agit plus d'une solution horizontale. Le cœur de SAKSHI est qu'il permet aux fournisseurs de services d'IA de se concentrer davantage sur la gestion de leurs propres calculs de modèle hors chaîne, l'association des besoins des utilisateurs avec les services de modèle, le paiement des services, et la vérification de la qualité des services grâce à des accords sur chaîne, et tente de résoudre automatiquement les litiges de paiement. Bien sûr, à l'heure actuelle, SAKSHI en est encore au stade théorique, et il y a également de nombreux détails d'implémentation qui méritent d'être déterminés.
Que ce soit l'IA combinable ou les plateformes d'IA décentralisées, le modèle d'écosystème d'IA basé sur la chaîne publique semble avoir quelque chose en commun. Par exemple, les fournisseurs de services d'IA ne se connectent pas directement avec les utilisateurs ; ils ont seulement besoin de fournir des modèles ML et d'effectuer des calculs hors chaîne. Les paiements, la résolution des litiges et la coordination entre les besoins des utilisateurs et les services peuvent tous être résolus par des accords décentralisés. En tant qu'infrastructure sans confiance, la chaîne publique réduit les frictions entre les fournisseurs de services et les utilisateurs, et les utilisateurs ont également une plus grande autonomie à ce moment.
Bien que les avantages de l'utilisation de la chaîne publique comme base d'application soient des clichés, il est vrai que cela s'applique également aux services d'IA. Cependant, la différence entre les applications d'IA et les applications dapp existantes est que les applications d'IA ne peuvent pas placer toutes les calculs sur la chaîne, il est donc nécessaire d'utiliser des preuves zk ou optimistes pour connecter les services d'IA au système de chaîne publique de manière plus décentralisée.
Avec la mise en œuvre d'une série de solutions d'optimisation de l'expérience telles que l'abstraction de compte, les utilisateurs peuvent ne pas être en mesure de percevoir l'existence de mnémoniques, de chaînes et de gaz. Cela rapproche l'écosystème de la chaîne publique de web2 en termes d'expérience, tandis que les utilisateurs peuvent obtenir un degré de liberté et de composition plus élevé que les services web2. Cela sera très attractif pour les utilisateurs. L'écosystème d'application d'IA basé sur la chaîne publique mérite d'être attendu avec impatience.
Kernel Ventures est un fonds de capital-risque crypto piloté par une communauté de recherche et développement avec plus de 70 investissements en phase précoce axés sur l'infrastructure, les middleware, les dApps, en particulier ZK, Rollup, DEX, les blockchains modulaires, et les verticaux qui accueilleront les prochains milliards d'utilisateurs de crypto, tels que l'abstraction de compte, la disponibilité des données, la scalabilité, etc. Au cours des sept dernières années, nous nous sommes engagés à soutenir le développement des communautés de développement de base et des associations universitaires de blockchain à travers le monde.
Avertissement: