La solution ultime pour le secteur du stockage ? Le passé et le présent du stockage de données dans le cloud.

Auteur : Ray Source : X, @RayAC1397

Résumé : À partir de l'ancêtre du secteur du stockage en nuage, analysez les changements dans l'ensemble du secteur et son histoire, puis examinez les problèmes de Filcoin et d'Arweave, et enfin analysez le modèle commercial d'Irys et prévoyez l'évaluation après le TGE d'Irys. Une FDV d'Irys inférieure à 300 millions est considérée comme sous-évaluée, quant à savoir si elle pourra maintenir sa position de leader sur le marché du cloud à long terme, il est nécessaire de surveiller l'adéquation entre les activités et la tokenomics ainsi que la capacité des cas d'utilisation principaux à fonctionner correctement.

Mots-clés : Analyse du secteur du stockage dans le cloud, Analyse du modèle commercial de Filcoin, Analyse du modèle commercial d'Arweave, Présentation du projet Irys, Prévisions d'évaluation, Analyse stratégique d'Irys

Texte :

Chapitre 1 : De la paroi rocheuse à l'évolution dans les nuages

Dans la lointaine civilisation mésopotamienne, l'humanité a eu pour la première fois l'idée de stocker des informations : nos ancêtres ont intelligemment gravé les informations sur des "tablettes durables" ; pendant la révolution industrielle, la musique, en tant qu'information, a été stockée sur des disques ; et à l'ère de l'informatique, les gens ont inventé une série de matériels de stockage d'informations tels que des cassettes, des disques durs, des CD...

La manière de stocker des données a toujours été le reflet des progrès de l'époque.

En 1956, IBM a lancé le modèle 350, une machine aussi grande que deux réfrigérateurs côte à côte, pesant près d'une tonne, mais ne pouvant stocker que 5 Mo de données. Les gens devaient utiliser une grue pour la soulever et l'introduire dans la salle des machines. Bien qu'extrêmement encombrante, elle a permis pour la première fois que le "stockage électronique" devienne une ressource que les entreprises pouvaient payer. Cette percée a changé le destin de l'information : elle n'était plus entièrement dépendante du papier difficile à maintenir en vie, mais pouvait exister sur des matériaux électromagnétiques capables de perdurer dans le temps. Au cours des décennies suivantes, les fabricants de disques durs ont engagé une guerre invisible. Des entreprises comme SeaGate, Western Digital et Hitachi n'ont cessé d'augmenter la densité de stockage des disques, permettant de disposer de plus en plus de particules magnétiques par pouce carré de disque. Chaque itération technologique signifiait un doublement de la capacité et une diminution des prix. Dans les années 1990, la prolifération des ordinateurs personnels et l'essor d'Internet ont fait de ces fabricants de disques durs la pierre angulaire de toute l'industrie. À cette époque, le stockage était la "matière première", avec un seul critère principal sur le marché : quelle solution de stockage était la plus efficace, à la fois bon marché et de bonne qualité. Cependant, lorsque l'échelle de stockage des données a commencé à croître de manière exponentielle, la principale préoccupation des entreprises est devenue "comment garantir la stabilité et la sécurité des données". Les opérations des banques, des compagnies aériennes et des entreprises manufacturières dépendent des données, et pour elles, la moindre erreur peut entraîner des pertes énormes. Ainsi, des entreprises de stockage de niveau entreprise comme EMC et NetApp ont émergé, vendant un ensemble complet d'array de stockage et de logiciels associés. À ce moment-là, la logique commerciale du stockage dans le cloud est passée d'un service ponctuel à une collaboration à long terme, les clients d'entreprise signant des contrats de service et de garantie à long terme avec les fournisseurs de services. Pour la première fois, le stockage a été classé comme un "actif commercial".

Au début du 21e siècle, l'Internet et la vague mobile ont permis aux données de commencer à circuler au-delà des frontières. Les solutions de stockage d'entreprise traditionnelles apparaissent lourdes et coûteuses face à la demande de mondialisation. En 2006, Amazon a lancé le service S3, transformant le stockage en une simple API : les développeurs n'ont plus besoin d'acheter des salles de serveurs et des disques, il leur suffit de quelques lignes de code pour écrire des fichiers dans le cloud à tout moment. Ce modèle de "à la demande" a complètement changé les habitudes des développeurs et a permis aux startups d'accéder pour la première fois à des infrastructures similaires à celles des grandes entreprises. La valeur du stockage dans le cloud ne réside pas dans son prix abordable, mais dans sa flexibilité et son écosystème. Cela a transformé le stockage d'un dispositif en un "service toujours en ligne". Rapidement, Dropbox et Google Drive ont porté cette expérience au grand public. Les utilisateurs n'ont plus besoin de se soucier de l'ordinateur sur lequel se trouve un fichier ; tant qu'ils ont Internet, ils peuvent passer d'un téléphone, d'une tablette à un ordinateur portable sans interruption. Le concept de stockage a de nouveau été modifié : les données ne sont plus stockées sur des dispositifs physiques, mais appartiennent à notre propre "cyberspace". De tambours d'IBM, aux ensembles de stockage d'EMC, jusqu'au stockage d'objets AWS S3, l'évolution du stockage de données confirme à plusieurs reprises une règle : chaque nouvelle tête de pont couronnée est due au fait qu'elle a créé, ou plutôt satisfait, un nouveau besoin d'utilisation des données. La première génération de disques durs a résolu le problème de capacité, les solutions de stockage d'entreprise ont répondu aux besoins de "stabilité et de sécurité", tandis que le stockage dans le cloud vise les points de douleur de "flexibilité et d'évolutivité". Cependant, derrière cette histoire, une caractéristique est restée inchangée : la propriété des données est excessivement concentrée entre les mains des fournisseurs de cloud. À une époque où les données sont devenues des actifs, cela est manifestement inacceptable.

À ce stade, Web3 commence à entrer en jeu.

Chapitre 2 : La logique des mineurs de Filecoin et l'idéalisme d'Arweave

Dans le système Web2, la propriété et le contrôle des données sont fortement centralisés. Que ce soit les relations sociales de Facebook ou les données de transaction d'Amazon, elles sont essentiellement détenues par les entreprises. Les utilisateurs, bien qu'ils "utilisent", n'ont jamais vraiment "possédé". Les entreprises exploitent sans vergogne les données pour gagner de l'argent, mais les utilisateurs ne peuvent être que de petits agneaux impuissants : lorsque leur compte personnel est suspendu, leurs données disparaissent également ; lorsque les entreprises retirent du contenu en raison de la conformité ou de pressions politiques, ces informations disparaissent immédiatement de l'espace public.

Ainsi, la demande de stockage décentralisé a émergé. En 2015, le projet IPFS a proposé une nouvelle idée : utiliser le "hash de contenu" pour trouver des fichiers. Cela signifie que tout nœud qui a sauvegardé ce fichier peut répondre à une demande, ce qui résout le problème du "risque de stockage unique". Mais rapidement, les gens ont réalisé qu'une technologie seule ne suffisait pas, sans incitation économique, les nœuds ne seraient pas disposés à conserver les données à long terme. Ainsi, Filecoin est né, ajoutant à IPFS une tokenomics : les mineurs fournissent de l'espace de stockage pour gagner des $FIL, le protocole Filecoin utilise des algorithmes complexes de preuve de temps et d'espace pour vérifier si les données ont réellement été sauvegardées. D'un point de vue de conception, sa proposition de base est de "transformer le stockage en un marché ouvert", ce qui fonctionne effectivement du côté de l'offre : tant qu'il y a des récompenses en tokens, il est certain qu'un grand nombre de mineurs participeront aux activités écologiques. Mais ce qu'ils n'avaient pas pris en compte, c'est que le marché a non seulement une offre, mais aussi une demande. À ce moment-là, une multitude de passagers clandestins est apparue. Les incitations de Filecoin reposent principalement sur "la fourniture de capacité et la présentation de preuves à temps", les mineurs se préoccupent naturellement plus des intérêts économiques que de la manière de servir les utilisateurs. Ainsi, une multitude de passagers clandestins est apparue. Vous verrez un écart structurel : le côté offre est extrêmement actif, tandis que le côté demande ne croît pas en synchronisation. Cet écart se propage rapidement au niveau des produits. Une équipe ayant besoin de lectures et d'écritures stables posera d'abord trois questions lors de l'évaluation de Filecoin : que faut-il préparer avant d'écrire, quelle est l'incertitude de la latence de récupération, et qui est responsable en cas de problème. D'autre part, du côté de l'écriture, les données commerciales réelles sont souvent accompagnées de mises à jour constantes, tandis que la sémantique de Filecoin penche naturellement vers le stockage à froid "de longueur fixe, à intervalles réguliers, avec renouvellement", les développeurs doivent construire des index, des mappages de versions et des stratégies de renouvellement supplémentaires. Et lors de la récupération, le problème se pose à nouveau : si l'on décide de faire son propre CDN et cache, le rendement marginal de l'utilisation de Filecoin sera infiniment réduit ; si l'on dépend de passerelles tierces ou de fournisseurs de services, la relation de service devient "semi-centralisée", et les responsables s'interrogeront sur la raison pour laquelle ils ne passent pas directement au cloud. Le dernier maillon est la limite de responsabilité : la preuve sur la chaîne ne peut pas directement garantir l'expérience produit. Pour les clients d'entreprise, même une incertitude de 1 % est suffisante pour exclure Filecoin des chaînes critiques. La dépendance aux chemins causée par la conception des incitations se manifeste également chez les payeurs. Dans un marché ouvert idéal, le payeur devrait être l'utilisateur. Mais lorsque la demande réelle est insuffisante au début, l'écosystème doit utiliser des incitations pour stimuler la demande (par exemple, en offrant des conditions de mise en chaîne plus favorables pour certains ensembles de données). Cela peut stimuler à court terme le nombre de transactions, mais il est très difficile de prouver que la demande "spontanée, prête à payer de manière continue" existe vraiment. Avec le temps, le modèle financier du côté de l'offre fonctionne autour de "subventions de blocs, de garanties et de confiscations", tandis que la volonté de payer du côté de la demande fluctue autour de "s'il y a des subventions et des limites", les deux systèmes ne se sont pas réellement couplés. C'est aussi pourquoi dans de nombreux cas de succès, vous verrez des nouvelles sur "la mise en chaîne de grandes données", mais très peu sur "la récupération haute fréquence, la réutilisation continue et la rentabilité des produits de niveau supérieur".

À peu près en même temps, Arweave a proposé une autre solution : les utilisateurs paient une fois pour les frais de stockage, et le réseau s'engage à conserver les données à long terme. L'inspiration du fondateur Sam Williams provient de l'histoire et de la sociologie : si le passé peut être effacé, alors la mémoire sociale ne sera plus fiable. La valeur de cette voie est évidente : une fois que certaines valeurs sont altérées, la confiance de la société sera érodée.

Arweave monétise le "stockage du futur" par un paiement unique, le réseau continuant de copier et de conserver pendant une longue période, c'est ce qui touche le cœur. Mais lorsque vous le placez dans le contexte des produits et des affaires, un autre ensemble de problèmes apparaît. Le premier est la tension entre "permanence" et "itération". La grande majorité des applications ne sont pas écrites une seule fois et jamais mises à jour, mais sont constamment révisées, régressées, A/B. La bonne utilisation d'Arweave est d'écrire chaque changement comme un nouveau contenu, en pointant vers la dernière version par indexation. Techniquement faisable et pas complexe en ingénierie, mais la conception au niveau des applications reste toujours un problème : les utilisateurs ne veulent voir que la dernière version, et non passer du temps à comprendre une chaîne temporelle immuable. Le deuxième problème est l'éthique de la permanence du stockage. Un réseau ouvert portera inévitablement du contenu gris et illégal, le protocole Arweave ne peut pas être supprimé, il doit compter sur l'auto-régulation et le filtrage des passerelles, des interfaces et des couches d'index, ce qui rend les développeurs dans une situation délicate face à la "responsabilité" : une fois que vous prenez activement en charge le travail de filtrage, vous devenez le responsable ; si vous ne le faites pas, vous perdrez des clients. Le troisième problème est l'idéalisation du système économique. La promesse d'Arweave repose sur deux hypothèses long terme simples : la baisse continue du coût unitaire de stockage et le maintien de l'intensité de la copie par le réseau pendant une durée suffisamment longue. Elles ont une forte probabilité d'être valables à un niveau macro, mais pour un seul chef de produit, la pression de trésorerie immédiate est très difficile à résoudre, car cela signifie des frais d'écriture élevés à payer d'un seul coup, rien que le calcul des intérêts peut faire peur. Avec le temps, les affaires d'Arweave se retrouvent limitées à un marché de niche très restreint, et la valorisation n'arrive toujours pas à franchir le cap.

Chapitre 3 : IA et stockage dans le cloud, les données dansent

Après que Filecoin et Arweave aient ouvert les portes du stockage cloud Web3, le secteur du stockage cloud est resté longtemps sans intérêt. Et c'est durant cette période vide qu'Irys est apparu. La question centrale qu'il soulève est : pourquoi les données ne peuvent-elles pas bouger par elles-mêmes ? Puisque le moment où les données sont écrites dans le stockage est essentiellement un "événement", pourquoi cet événement ne peut-il pas déclencher immédiatement une logique ? Si le réseau lui-même peut supporter un environnement d'exécution, alors les données ne sont plus de simples archives endormies, mais des unités capables de dynamiser des applications. Le point de conception d'Irys est précisément cela. Il ne se concentre plus sur la "logique de minage" de Filecoin et le "stockage permanent" d'Arweave pour faire des mises à jour, mais combine le stockage et le calcul, en introduisant le concept de "chaîne de données programmable". Écrire des données déclenche immédiatement, les données portent la logique dans le réseau, et sont exécutées directement par l'environnement d'exécution d'Irys (IrysVM). Pour les développeurs, cela signifie passer d'une opération "en deux étapes" à une opération "en une seule étape" — écrire c'est appeler.

Comme mentionné précédemment, au cours du dernier demi-siècle, chaque évolution du stockage a été motivée par la création de nouveaux besoins. Par conséquent, je pense que la vision d'Irys est particulièrement importante à l'ère de l'IA. Les modèles d'IA nécessitent une grande quantité de données, ainsi que des sources fiables et une exécution vérifiable. Le stockage traditionnel enferme les données dans des entrepôts froids, puis les confie à une logique hors chaîne, ce qui est non seulement encombrant, mais laisse également des lacunes en termes de crédibilité. La forme de données envisagée par Irys est auto-dirigée : elles peuvent automatiquement "nourrir les modèles", inclure des règles de facturation et de permission, et peuvent collaborer entre organisations sans nécessiter d'hébergement tiers.

D'un autre côté, la force d'Irys réside dans l'intégration du stockage, de l'exécution et de la validation dans le même protocole de base. Cela signifie que les données écrites dans différents protocoles peuvent être lues et réutilisées directement les unes par les autres, voire conduire à une logique d'application plus complexe. Ainsi, à mesure que le nombre de nœuds augmente, la valeur globale du réseau croît naturellement, car la découvrabilité et la combinabilité des données s'améliorent constamment. Pour comprendre cela, pensez à Ethereum. À l'époque où il a introduit les contrats intelligents, beaucoup de gens ne comprenaient pas en quoi cela différait des simples transferts sur la chaîne, jusqu'à ce que des applications financières telles que Uniswap, Aave et Compound voient le jour, les gens réalisant alors que les contrats intelligents sont les graines d'une narration infinie. Irys fait en fait quelque chose de similaire, sauf que l'objet passe de "financier" à "données". Bien que les données soient trop abstraites pour être aussi intuitives que l'argent, une fois l'écosystème accumulé, les développeurs découvriront : je peux continuer à construire directement sur les sorties de données des autres, sans avoir à dépendre d'oracles externes ou à collecter à nouveau. Cette narration ressemble à celle du parcours d'AWS à l'époque. AWS ne s'est pas imposé uniquement grâce à un "stockage bon marché", mais a réussi à verrouiller complètement les développeurs dans son écosystème grâce à un ensemble complet de SDK, de consoles et d'API. Si vous utilisez un ou deux services d'AWS, vous serez rapidement attiré par la commodité de l'ensemble du système AWS. Si Irys exécute correctement la collaboration, par exemple en rendant les "données de haute qualité" accessibles uniquement lors de l'écriture dans Irys, elle formera également un verrouillage de valeur similaire. À ce moment-là, les données sur Irys ne seront pas seulement des actifs d'un certain protocole, mais le carburant de tout l'écosystème, et ce cycle positif finira par nourrir le réseau de données lui-même et la valeur du jeton.

Chapitre 4 : Évaluation et marché d'Irys

Il faut savoir que si l'idéal est beau, la réalité est souvent cruelle. Avoir un projet prometteur ne signifie pas nécessairement réussir. Le premier défi auquel Irys est confronté est le démarrage à froid. Sans demande réelle, c'est-à-dire sans suffisamment d'applications prêtes à consommer ces "données programmables", il risque de se transformer en une autre solution de stockage bon marché. Le deuxième défi est la compatibilité. Les développeurs dépendent déjà fortement des interfaces EVM, IPFS, AWS, etc. Tout nouveau paradigme augmentera le coût d'apprentissage. Pour qu'Irys puisse s'ouvrir, il doit réussir à offrir une "utilisation sans barrière" de manière suffisamment fluide. Le troisième défi est la gouvernance. Une fois que les données peuvent déclencher des logiques, cela crée de nouvelles surfaces d'attaque : des données fausses pour frauder des assurances, des déclenchements malveillants consommant des ressources, des litiges en matière de droits d'auteur et de confidentialité. Le cloud centralisé s'appuie sur la loi et les droits pour résoudre ces problèmes, tandis que le protocole décentralisé doit apporter des réponses en termes de mécanisme et de gouvernance, sinon il sera difficile d'obtenir une adoption à l'échelle institutionnelle. Ainsi, Irys est-elle un dieu ou un démon ? Cela ne pourra être jugé qu'après son lancement sur le réseau principal. Attendons de voir si elle peut, comme AWS à l'époque, rendre l'abstraction suffisamment élégante et faire fonctionner les scénarios types de manière suffisamment impressionnante pour que les développeurs soient prêts à la remplacer par les solutions existantes. D'un point de vue historique, c'est le point clé pour que toutes les infrastructures puissent éjecter les grands acteurs et devenir "le leader de la prochaine génération".

Si j'étais l'auteur, je prêterais attention aux trois voies suivantes :

  1. Premier cas d'utilisation. Toutes les infrastructures fondamentales de l'histoire ont des cas d'utilisation emblématiques pour prouver leur valeur. S3 repose sur Flickr et Dropbox ; Snowflake s'appuie sur des scénarios d'analyse en temps réel dans la finance et le commerce de détail.

De même, Irys doit créer un ou deux scénarios révolutionnaires, comme un système d'incitation en temps réel pour les données de santé ou un mécanisme de règlement automatisé pour les dispositifs DePIN.

  1. Baisser le seuil de migration. Les habitudes des développeurs sont les plus difficiles à changer. Pourquoi l'EVM a-t-il pu devenir un standard de fait ? Parce qu'il permet aux gens de réutiliser d'anciens outils et langages dans un nouvel environnement. Irys doit éviter de "rééduquer le marché" et se concentrer sur la maximisation de la compatibilité avec les habitudes existantes au niveau des interfaces, des SDK et de l'expérience de développement.

  2. Établir des outils de gouvernance ou des règles écologiques. Une fois que les données peuvent déclencher une logique, cela entraînera inévitablement des attaques et des différends : des données fausses pour obtenir des récompenses, des déclenchements malveillants consommant des ressources, des zones grises sur la propriété des droits d'auteur. Si Irys peut fournir au niveau des mécanismes des outils pour "vérifier la source des données", "limiter les déclenchements malveillants" et "intégrer la logique des droits d'auteur et de la vie privée", elle pourra gagner la confiance dans les scénarios ToB et ToG. L'intensité de la guerre dans le domaine du cloud ne doit pas être sous-estimée. Les fournisseurs de cloud restent des géants, les solutions assemblées restent flexibles et bon marché, et les modèles de preuve hors chaîne sont encore peu coûteux. Mais l'histoire prouve encore et encore que la véritable rupture ne vient pas d'une lutte dans l'ancien cadre, mais que c'est seulement lorsque de nouvelles habitudes sont créées et deviennent la norme que le cadre est redéfini. Irys doit résoudre ce problème central pour devenir le leader.

En ce qui concerne l'évaluation, à la date de rédaction de cet article, la capitalisation boursière en circulation de $FIL est de 2 milliards, avec une FDV atteignant 4,7 milliards ; la capitalisation boursière en circulation de $AR est de 400 millions, presque entièrement en circulation. Pendant ce temps, le $Prove de Succinct, une infrastructure ZK rolldown lancée en même temps que BN, a une capitalisation boursière en circulation de 200 millions et une FDV de 1,1 milliard. Étant donné qu'Irys possède deux grands concepts, l'IA et le stockage en cloud, bien que le concept d'IA soit en plein essor sur le marché, en raison d'une grande incertitude macroéconomique, il est difficile pour le marché d'accorder une prime.

Je pense que la valorisation après IrysTGE est la suivante :

  1. Ouverture basse : 300 millions – 500 millions FDV ;

2、Normal : 8 milliards – 12 milliards FDV

Étant donné que l'auteur a une faible tolérance au risque :

  1. Si les affaires progressent bien et qu'il est possible de créer un cercle vertueux avec la Tokenomics, et que le niveau d'évaluation est inférieur à 300 millions de FDV, j'achèterai directement. Si le FDV atteint environ 500 millions, j'achèterai une petite position ; au-dessus de 500 millions, je resterai en observation.

  2. Si les affaires avancent mal, ou si la tokenomics ne peut pas s'harmoniser avec les activités, je resterai en observation et déplacerai le poids des indicateurs de tendance des fondamentaux vers l'analyse technique.

FIL0.2%
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Reposter
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)