Conflit dans le secteur DePIN : le fondateur d'Akash critique io.net
TechFlow SélectionTechFlow Sélection
Conflit dans le secteur DePIN : le fondateur d'Akash critique io.net
Officiellement, il s'agit de questions-réponses objectives sur l'expérience produit ; en réalité, ce sont deux projets aux activités similaires qui s'affrontent tout en protégeant leur image de marque.
Dédié à des analyses Web3 approfondiesRédaction : TechFlow
L'un des événements les plus remarqués ces derniers jours a été le lancement du jeton d'IO.NET.
Des variations de prix sur Binance aux retours d'expérience sur l'extraction de jetons IO via des cartes graphiques... Tous les regards semblent concentrés sur la dimension financière d'IO.
Pourtant, certains s'élèvent contre cette tendance.
Prenez par exemple Akash Network, un autre projet de cloud computing décentralisé. Son fondateur, Greg Osuri, n’a pas pu s’empêcher, alors que toute l’attention se portait sur les fluctuations du prix d’IO, d’aller tester lui-même le produit d’IO.NET.
Mais ce test ne fut pas vraiment concluant.
Greg a alors commencé à pointer publiquement sur Twitter plusieurs problèmes liés à l’expérience utilisateur d’IO.NET, passant ainsi du statut de fondateur concurrent à celui de « contrôleur qualité » officieux d’IO.NET.
Le CTO d'IO.NET, GauravTdhinait, a répondu point par point, expliquant patiemment chaque critique soulevée par Greg.
Un échange public et animé, qui, en apparence, ressemble à une discussion objective sur l’expérience produit, mais qui, en réalité, reflète une rivalité entre deux projets aux activités similaires, chacun défendant son image de marque.
Quand le fondateur d’Akash teste un produit concurrent et donne son avis, à ce moment précis, on peine à croire qu’il s’agisse d’un simple « coup d’essai » plutôt que d’une volonté délibérée de « chercher la petite bête ».
Nous avons reconstitué ici l’échange entre Greg, fondateur d’Akash, et GauravTdhinait, CTO d’IO.NET, afin de retracer fidèlement les faits.
Acheté un iPhone, reçu un Nokia ?
Tout a commencé par un retour de bug initial de Greg lors de son utilisation d’IO.NET.
Greg a acheté sur IO.NET un service de cluster composé de 4 GPU A100, en payant le prix correspondant.
Une fois le processus de déploiement et de paiement terminé, il s’est rendu compte que la marchandise livrée ne correspondait pas à sa commande : après vérification des données, il constata qu’il n’avait pas reçu quatre GPU A100, mais seulement une RTX A4000.
Sur le papier, l’écart de performance entre ce qu’il attendait et ce qu’il a obtenu est considérable. Greg compare cela à payer le prix d’un iPhone pour se retrouver avec un vieux Nokia.
Pour renforcer la crédibilité de son propos, Greg a non seulement mentionné IO.NET dans un tweet pour demander des explications, mais a également joint une vidéo complète montrant toutes les étapes d’achat et d’opération.
Ce post s’est rapidement répandu et amplifié, poussant d’autres utilisateurs à y voir une forme de fraude, exigeant des comptes de la part d’IO.NET.
La réponse ne s’est pas fait attendre : le CTO d’IO.NET, Gaurav (@GauravTdhinait), est intervenu personnellement, apportant une explication relativement cohérente.
En réalité, le prétendu « désaccord entre attente et livraison » relevé par Greg dans sa vidéo provient du fait qu’un serveur (nœud) dans le cluster créé était défaillant, empêchant ainsi le bon fonctionnement du cluster.
Quant à la confusion entre A100 et RTX A4000, elle vient du fait que la RTX A4000 affichée par Greg est en réalité le nœud principal du cluster (serveur responsable de la gestion et de la coordination), et non pas les nœuds de travail chargés des tâches de calcul haute performance.
De plus, précise le CTO, aucun paiement n’est facturé pour un cluster défectueux comme celui-ci, qui sera automatiquement supprimé par la suite.
Autrement dit, ce que vous avez filmé et ce qui se passe réellement sont deux choses différentes.
Vous avez bien acheté un iPhone, mais parce que cet iPhone présente un défaut, vous pensez avoir été trompé.
Plus important encore, le CTO Gaurav a fourni des preuves supplémentaires : Greg a en réalité créé 7 clusters sur IO.NET, dont 6 ont fonctionné correctement.
Or Greg n’a choisi de publier un post que sur cet unique cas d’échec, exigeant des explications. Bien qu’IO.NET n’ait pas commenté directement ce comportement, il est difficile de ne pas penser que Greg cherche délibérément à saisir un cas isolé pour critiquer.
Les 6 cas réussis ne sont ni filmés ni mentionnés ; seul l’échec est mis en avant avec demande de réponse. Certains internautes ont d’ailleurs souligné en commentaire :
Tu ne sembles pas vraiment là pour utiliser honnêtement le produit…
Contrôleur qualité jusqu’au bout
Après avoir remis en cause la conformité du produit, Greg n’a pas cessé son rôle de « contrôleur qualité » d’IO.NET, continuant de critiquer d'autres aspects du produit et s’acharnant sur divers points d’expérience utilisateur.
Par exemple, Greg affirme avoir crédité 100 USDT sur son compte IO.NET, sans toutefois obtenir de mise à niveau lui permettant d’acheter davantage de clusters. Il accuse alors IO.NET de pratiquer sciemment une forme de censure en limitant les droits de son compte.
Ou encore, le CTO d’IO.NET ayant remarqué un comportement inhabituel de la part de Greg — création rapide d’un service de cluster puis suppression deux minutes plus tard —, Greg rétorque fermement qu’il n’a pas supprimé immédiatement, mais après un long délai, car le système d’IO.NET ne parvenait pas à afficher correctement les GPU, donnant l’impression que le programme ne répondait pas, justifiant ainsi sa suppression légitime…
À la rédaction de cet article, Greg continue de publier activement de nouveaux posts sur Twitter, regroupant divers problèmes, affirmant que l’on ne doit pas croire la version unilatérale du CTO d’IO.NET, tout en vantant au passage le bon fonctionnement fluide de son propre projet, Akash Network.
Finalement, savoir si IO.NET présente ou non des problèmes d’expérience utilisateur, et dans quelle mesure, devient secondaire face à cet échange public et à ces publications médiatisées.
Ce qui frappe désormais, c’est qu’un fondateur de projet concurrent consacre autant d’énergie à « tester » le produit d’un autre, s’acharnant à pointer chaque défaut, réfutant systématiquement chaque « version unique des faits ».
S’agit-il vraiment du PDG d’une entreprise, ou plutôt du contrôleur qualité gratuit d’un concurrent ?
Dans ce cas, s’obstiner sur les détails donne moins l’impression de rigueur que d’abaisser le niveau du débat.
Le comportement de Greg a suscité des critiques au sein de la communauté. Certains lui disent clairement : « Frère, tu ferais mieux d’améliorer ton propre produit plutôt que de critiquer tes concurrents ». D’autres détenteurs d’AKT jugent que Greg manque de hauteur, au point qu’ils envisagent même de vendre leurs jetons.
Concurrents jaloux
On dit souvent que les lettrés se méprisent mutuellement, faisant référence à cette tendance qu’ont les intellectuels à ne pas reconnaître les mérites des autres.
Il est facile de comprendre le plaisir et la motivation derrière les critiques de Greg : je fais le même métier que toi, donc je ne peux tolérer la moindre petite erreur de ta part. On ressent même parfois une pulsion du type : « Si tu n’es même pas capable de régler ça, alors je dois absolument te le dire. »
Critiquer IO.NET par le fondateur d’Akash relève donc incontestablement d’une forme de « jalousie entre projets DePIN ».
Chacun pense avoir ses atouts, mais espère surtout que l’autre n’en ait qu’un seul.
Les projets DePIN ou de cloud computing décentralisé se multiplient, et techniquement, les barrières d’entrée ne sont pas très élevées. Ces activités reposent davantage sur l’intensité des ressources. Ce sont donc l’expérience utilisateur, la fluidité du service et la richesse de l’image de marque qui font souvent la différence.
Mais descendre soi-même dans l’arène pour jouer les contrôleurs qualité, sans certitude absolue de pouvoir pointer des erreurs, risque surtout de nuire à sa propre image de marque.
Car si l’on est trop sévère envers un concurrent, dès que son propre produit connaîtra le moindre incident, la communauté n’hésitera pas à ressortir les vieux dossiers.
Se ménager, ainsi qu’aux autres, une marge de manœuvre, reste peut-être la philosophie la plus sage pour naviguer dans un monde où les acteurs improvisés foisonnent.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
