Резюме: Від попередників сектора хмарного зберігання, аналізуючи зміни в цілому секторі та історії, далі аналізуючи питання Filcoin та Arweave, нарешті, аналізуючи бізнес-модель irys і прогнозуючи оцінку після TGE Irys. FDV Irys нижче 300 млн є недооцінкою, а щодо того, чи зможе він стабільно утримувати позицію лідера в секторі хмарних послуг у довгостроковій перспективі, необхідно звернути увагу на відповідність бізнесу та токеноміки, а також на те, чи зможуть основні випадки використання успішно реалізуватися.
Ключові слова: аналіз ринку хмарного зберігання, аналіз бізнес-моделі Filcoin, аналіз бізнес-моделі Arweave, представлення проекту Irys, прогноз оцінки, стратегічний аналіз Irys
Текст:
Розділ 1: Еволюція від кам'яної стіни до хмар
У далекій цивілізації Месопотамії люди вперше задумалися про зберігання інформації: наші предки розумно викарбували інформацію на "вічних" кам'яних табличках; під час промислової революції музика як форма інформації була збережена на платівках; а в епоху комп'ютерів люди винайшли касети, жорсткі диски, компакт-диски та інші засоби зберігання інформації...
Спосіб зберігання даних завжди був відображенням прогресу епохи.
У 1956 році IBM представила Model 350 - це була машина розміром з два холодильники, вагою майже в тонну, яка могла зберігати лише 5MB даних; для її установки в серверну використовувалися крани. Незважаючи на її громіздкість, вона вперше зробила "електронне зберігання" ресурсом, за який підприємства могли платити. Цей прорив змінив долю інформації: вона більше не залежала повністю від важкості паперу, а могла зберігатися на електромагнітних матеріалах, які могли існувати протягом тривалого часу. У наступні десятиліття виробники жорстких дисків розпочали невидиму війну. Компанії такі як SeaGate, Western Digital, Hitachi постійно підвищували щільність зберігання на дисках, дозволяючи все більше магнітних частинок розміщувати на кожному квадратному дюймі диска. Кожна технічна ітерація означала подвоєння ємності та зниження ціни. У 1990-х роках, з поширенням персональних комп'ютерів та зростанням Інтернету, ці виробники жорстких дисків стали основою всієї індустрії. У ті часи зберігання було "сировиною", а єдиним основним стандартом на ринку було: чия рішення для зберігання є найефективнішим, тобто дешевим і якісним. Однак, коли обсяги зберігання даних почали зростати експоненційно, першочерговою потребою підприємств стало "як забезпечити стабільність і безпеку даних". Операції банків, авіакомпаній, виробничих підприємств залежать від даних, для них навіть незначна помилка може призвести до величезних втрат. Таким чином, такі компанії, як EMC і NetApp, що займаються корпоративним зберіганням, стали на підйом, продаючи цілі комплекти систем зберігання та супутнє програмне забезпечення. У цей час бізнес-логіка ринку хмарного зберігання змінилася з одноразового сервісу на довгострокове співробітництво, корпоративні клієнти укладали довгострокові контракти на обслуговування та保障. Зберігання тут вперше було класифіковано як "бізнес-актив".
Час настав на початку 21 століття, коли Інтернет і мобільні технології дозволили даним почати перетинати кордони. Традиційні корпоративні рішення для зберігання виявилися громіздкими та дорогими перед потребами глобалізації. У 2006 році Amazon запустила сервіс S3, абстрагуючи зберігання в простий API: розробникам більше не потрібно було купувати серверні приміщення та диски, достатньо кількох рядків коду, щоб в будь-який час записати файли в хмару. Ця модель "за запитом" кардинально змінила звички розробників і надала стартапам можливість отримати таку ж інфраструктуру, як у великих компаній. Цінність хмарного зберігання полягає не в дешевизні, а в гнучкості та екосистемі. Воно перетворило зберігання з пристрою на "послугу, доступну в будь-який час онлайн". Незабаром Dropbox та Google Drive перенесли цей досвід на споживчий ринок. Користувачам не потрібно турбуватися про те, на якому комп'ютері зберігаються файли, головне мати доступ до мережі, щоб у будь-який час безперешкодно переключатися між телефоном, планшетом і ноутбуком. Концепція зберігання знову змінилася: дані більше не зберігаються на фізичних пристроях, а належать власному "кіберпростору" людини. Від магнітних барабанів IBM до масивів зберігання EMC і об'єктного зберігання AWS S3, еволюція зберігання даних неодноразово підтверджує одну закономірність: кожне нове керівництво стає успішним завдяки створенню або задоволенню нових вимог до використання даних. Перші жорсткі диски вирішили проблему обсягу, корпоративні рішення для зберігання задовольняли потреби у "стабільності та безпеці", а хмарне зберігання націлене на "гнучкість та масштабованість". Проте, за всім цим історичним контекстом залишається одна характеристика, яка ніколи не змінювалася: право власності на дані надмірно централізоване в руках постачальників хмарних послуг. У час, коли дані стали активами, це очевидно неприпустимо.
Отже, Web3 починає входити в гру.
Розділ 2: Логіка майнерів Filecoin та ідеалізм Arweave
У рамках системи Web2 право власності та контролю над даними сильно централізоване. Незалежно від того, чи це соціальні зв’язки Facebook, чи торгові дані Amazon, суть полягає в тому, що ці дані контролюються компанією. Користувачі, хоча й "використовують" їх, насправді ніколи не "володіють" ними. Компанії безсоромно заробляють на даних, в той час як користувачі залишаються безсилими, мов ягнята: коли особистий акаунт блокується, дані також зникають; коли компанії знімають контент через нормативні чи політичні тиски, ця інформація миттєво зникає з публічного простору.
Оттак, з'явився заклик до децентралізованого зберігання. У 2015 році проект IPFS запропонував новий підхід: шукати файли за допомогою "контентного хешу". Це означає, що будь-який вузол, який зберігає цей файл, може відповісти на запит, що вирішує проблему "ризику єдиного пункту зберігання". Але дуже швидко люди зрозуміли, що однієї технології недостатньо, без економічних стимулів вузли не будуть готові довго зберігати дані. Так з'явився Filecoin, який на основі IPFS додав токеноміку: майнери надають простір для зберігання, щоб отримати $FIL, протокол Filecoin використовує складні алгоритми доказу часу і простору, щоб перевірити, чи дані дійсно зберігаються. З точки зору дизайну, його основна ідея полягає в тому, щоб "перетворити зберігання на відкритий ринок", що дійсно спрацювало з боку пропозиції: лише за наявності токенових винагород можна організувати велику кількість майнерів для участі в екосистемних заходах. Але вони не врахували, що на ринку є не лише пропозиція, але й попит. У цей момент з'явилася велика кількість тих, хто використовує ситуацію. Стимул Filecoin в основному полягає в "наданні потужності та своєчасному наданні доказів", тому майнери природно більше піклуються про економічні вигоди, а не про те, як обслуговувати користувачів. Таким чином, знову з'явилася велика кількість тих, хто використовує ситуацію. Ви побачите структурну розрив: пропозиція надзвичайно активна, тоді як попит не зростає синхронно. Цей розрив швидко передається на рівень продукту. Команда, якій потрібно стабільне читання та запис, оцінюючи Filecoin, спочатку запитає три питання: що потрібно підготувати перед записом, в якому діапазоні знаходиться невизначеність затримки пошуку, і хто відповідає, якщо щось піде не так. З іншого боку, на стороні запису справжні бізнес-дані зазвичай супроводжуються постійними оновленнями, а семантика Filecoin природно схиляється до "фіксованого терміну, періодичного, з продовженням" холодного зберігання, розробники повинні додатково налаштувати індексацію, версії та стратегію продовження. А коли йдеться про пошук, виникає нова проблема: якщо вирішити зробити CDN та кешування самостійно, гранична вигода від використання Filecoin буде безмежно знижена; якщо покладатися на шлюзи або постачальників послуг третьої сторони, сервісні відносини знову стають "напівцентралізованими", а відповідальні особи ставлять під сумнів, чому не перейти на хмару. Останній етап - це межі відповідальності: докази на ланцюзі не можуть прямо відповідати за досвід використання продукту. Для корпоративних клієнтів навіть 1% невизначеності достатньо, щоб виключити Filecoin з ключових ланцюгів. Залежність від шляху, викликана дизайном стимулів, також проявляється у платниках. У ідеальному відкритому ринку платники повинні бути користувачами. Але коли на початку справжній попит був недостатнім, екосистема мусила використовувати стимули для залучення попиту (наприклад, надаючи певним наборам даних більш вигідні умови для запису). Це може короткочасно збільшити кількість угод, але важко довести, що "спонтанний, готовий продовжувати платити" попит дійсно існує. З часом фінансова модель з боку пропозиції обертається навколо "блокових субсидій, застави та конфіскації", тоді як бажання платити з боку попиту коливається навколо "чи є субсидії та ліміти", і ці дві системи не з'єднані насправді. Ось чому ви побачите новини про "великий обсяг даних на ланцюзі" в багатьох успішних випадках, але рідко побачите закінчену розповідь про "високочастотний пошук, постійне повторне використання та прибутковість верхнього рівня продукту".
Майже одночасно Arweave запропонував інше рішення: користувачі одноразово сплачують плату за зберігання, а мережа обіцяє довготривале збереження. Натхнення засновника Сема Вільямса походить з історії та соціології: якщо минуле можна стерти, то соціальна пам'ять більше не буде надійною. Цінність цього шляху очевидна: якщо певна цінність буде змінена або видалена, довіра суспільства буде підриватися.
Arweave конвертує "зберігання майбутнього" в одноразову оплату, мережа протягом тривалого часу безперервно копіює та зберігає дані, саме в цьому її привабливість. Але коли ви ставите це в контекст продуктів та бізнесу, виникає інша група питань. Перше — це напруга між "вічністю" та "ітерацією". Абсолютна більшість додатків не є одноразовим записом, який ніколи не оновлюється, а постійно переглядається, повертатиметься назад, A/B. Правильне використання Arweave полягає в тому, щоб розглядати кожну зміну як новий контент, записуючи його, а через індексацію вказувати на останню версію. Технічно це можливо, інженерно це також не складно, але проектування на рівні застосування завжди є проблемою: користувачі хочуть бачити лише останню версію, а не витрачати час на розуміння незмінного ланцюга часу. Друге — етичні проблеми, пов’язані з постійним зберіганням. Відкриті мережі неминуче міститимуть сіру та незаконну інформацію, протокол Arweave не може видаляти, лише покладається на "самодисципліну" та фільтрацію на рівнях шлюзу, фронтенду та індексації, що ускладнює ситуацію для розробників у питанні "відповідальності": як тільки ви берете на себе відповідальність за фільтрацію, ви стаєте суб’єктом відповідальності; якщо ж ви не візьмете на себе, ви втратите клієнтів. Третє — ідеалізація економічної системи. Обіцянка Arweave залежить від двох простих довгострокових припущень: постійного зниження вартості одиниці зберігання та підтримання сили копіювання в мережі протягом достатньо тривалого часу. Вони мають високу ймовірність справдження на макрорівні, але для окремого продуктового менеджера тиск на грошовий потік є дуже складним для вирішення, адже це означає одноразові великі витрати на запис, і навіть відсотки можуть налякати. З часом бізнес Arweave виявився обмеженим дуже маленьким сегментом ринку, оцінка так і не зуміла прорватися.
Розділ 3: AI та хмарне сховища, дані танцюють
Після того, як Filecoin і Arweave відкрили двері до Web3 хмарного зберігання, тривалий час цю галузь ніхто не цікавив. І саме в цей період виникла Irys. Її основне питання: чому дані не можуть рухатися самі? Оскільки момент запису в сховище за своєю суттю є "подією", чому ця подія не може негайно викликати логіку? Якщо сама мережа може виконувати функції середовища виконання, дані більше не є просто сплячими архівами, а стають одиницями, що керують додатками. Дизайн Irys базується саме на цьому. Вона більше не зосереджується на "логіці видобутку" Filecoin і "постійного зберігання" Arweave, а об'єднує зберігання та обчислення, пропонуючи концепцію "програмованого ланцюга даних". Запис даних автоматично викликає подію, дані несуть логіку в мережу, де вони безпосередньо виконуються в середовищі виконання Irys (IrysVM). Для розробників це означає перехід від "двухетапної" операції до "одинетапної" — запис означає виклик.
У попередньому тексті згадувалося, що за останнє півстоліття кожна еволюція зберігання відбулася через створення нових потреб. Тому я вважаю, що проактивність Irys особливо важлива в епоху ШІ. Моделі ШІ потребують великої кількості даних, а також надійних джерел і перевірених виконань. Традиційне зберігання блокує дані в холодних сховищах, а потім передає їх для обробки оффлайн-логікою, що є не тільки громіздким, але й залишає прогалини в надійності. А концепція даних Irys полягає в самостійності даних: вони можуть автоматично "підживлювати моделі", мають вбудовані правила обліку та доступу, здатні співпрацювати між організаціями без потреби у третій стороні.
З іншого боку, крутість Irys полягає в інтеграції зберігання, виконання та перевірки в одному базовому протоколі. Це означає, що дані, записані в різні протоколи, можуть бути безпосередньо зчитані та повторно використані один одним, навіть забезпечуючи більш складну логіку додатків. Тож, коли кількість вузлів зростає, загальна цінність мережі природним чином зростає, оскільки виявлення та комбінування даних постійно посилюється. Щоб зрозуміти це, можна подумати про Ethereum. Коли він впровадив смарт-контракти, багато людей не розуміли, чим це відрізняється від звичайних транзакцій на блокчейні, поки не з'явилися фінансові додатки, такі як Uniswap, Aave, Compound, і люди не усвідомили, що смарт-контракти – це насіння безмежного оповідання. Irys насправді робить щось подібне, лише об'єкт змінився з "фінансів" на "дані". Хоча дані занадто абстрактні, щоб бути такими ж очевидними, як гроші, як тільки екосистема накопичиться, розробники виявлять: я можу безпосередньо будувати на виходах даних інших, не покладаючись на зовнішні оракули чи повторне збори. Таке оповідання насправді дуже нагадує шлях AWS в ті часи. AWS не перемагав лише завдяки "дешевому зберіганню", а через цілий набір SDK, консолей, API, повністю закріплюючи розробників у своїй екосистемі. Якщо ви використовували один або два сервіси AWS, ви швидко будете залучені до зручності всієї системи AWS. Якщо Irys правильно реалізує співпрацю, наприклад, "високоякісні дані" будуть доступні лише при запису в Irys, це також створить подібну ціннісну блокування. У той час дані на Irys будуть не лише активами певного протоколу, а паливом для всієї екосистеми, і цей позитивний цикл врешті решт повернеться до самої мережі даних та цінності токенів.
Розділ 4: Оцінка Irys та ринок
Слід знати, що ідеали хоч і гарні, але реальність часто жорстока. Мати перспективний проєкт не означає неминучий успіх. Перша проблема, з якою стикається Irys, — це холодний старт. Якщо немає реального попиту, тобто достатньо додатків, готових споживати ці "програмовані дані", він перетвориться на ще одне дешеве рішення для зберігання. Другою проблемою є сумісність. Розробники вже глибоко залежать від інтерфейсів EVM, IPFS, AWS та інших, тому будь-яка нова парадигма підвищить витрати на навчання. Щоб Irys змогла зрушити ситуацію з мертвої точки, їй потрібно зробити "нульовий поріг використання" достатньо плавним. Третьою проблемою є управління. Як тільки дані можуть активувати логіку, це створює нові вектори атак: шахрайство з фальшивими даними, зловмисне активування ресурсів, суперечки з приводу авторських прав та конфіденційності. Централізоване хмарне сховище покладається на законодавство та повноваження, а децентралізовані протоколи повинні дати відповідь на питання механізму та управління, інакше їм буде важко отримати рівень впровадження в організаціях. Таким чином, чи є Irys богом чи дияволом, стане зрозуміло лише після запуску в основній мережі. Давайте сподіватися, що він зможе, як колись AWS, зробити абстракцію достатньо елегантною, а шаблонні сценарії - достатньо привабливими, щоби розробники захотіли замінити свої існуючі рішення на нього. З історичної точки зору, це ключовий момент, чи зможе вся інфраструктура позбутися старшого партнера і стати "наступним лідером".
Якщо б я був автором, я б звернув увагу на такі три шляхи:
Перша прикладна сфера. В історії всі інфраструктури мали знакові прикладні сфери, щоб підтвердити свою цінність. S3 спирається на Flickr, Dropbox; Snowflake на реальний аналіз у фінансовій та роздрібній сферах.
Так само Irys має продемонструвати один-два вражаючі сценарії, такі як система реального часу стимулювання здоров'я або автоматичний механізм розрахунків для пристроїв DePIN.
Знизити поріг міграції. Звички розробників - це найважче, що можна змінити. Чому EVM став фактичним стандартом? Тому що він дозволяє людям використовувати старі інструменти та мови в новому середовищі. Irys повинна уникати "перепідготовки ринку", а натомість максимально сумісно працювати з існуючими звичками на рівні інтерфейсу, SDK та досвіду розробки.
Встановлення інструментів управління або екологічних правил. Як тільки дані можуть викликати логіку, це обов'язково призведе до атак і суперечок: фальшиві дані для отримання винагороди, злочинне спонукання до витрат ресурсів, сірі зони авторських прав. Якщо Irys зможе на механічному рівні надати інструменти "перевірка джерела даних", "обмеження злочинного спонукання", "вбудована логіка авторських прав та конфіденційності", то вона зможе завоювати довіру в сценаріях ToB та ToG. Інтенсивність війни на ринку хмарних технологій не можна недооцінювати. Хмарні постачальники все ще є величезними гігантами, зібрані рішення все ще гнучкі та дешеві, а поза ланцюгом моделі доказів є особливо дешевими. Але історія знову і знову доводить, що справжній прорив не відбувається через боротьбу в старій системі, а тоді, коли створюється певна нова звичка, яка стає стандартом, система лише тоді переформатовується. Irys має вирішити це основне питання, щоб стати лідером.
Щодо оцінки, на момент написання цієї статті, ринкова капіталізація $FIL становить 2 мільярди, а FDV досягає 4,7 мільярда; ринкова капіталізація $AR становить 400 мільйонів, практично повністю обігові. У той же час, ринкова капіталізація $Prove, інфраструктури ZK rolldown Succinct, що запустилася одночасно з BN, становить 200 мільйонів, а FDV - 1,1 мільярда. Враховуючи, що Irys має два великих концепти AI+хмарне зберігання, хоча концепція AI на ринку наразі процвітає, через величезну невизначеність з макроекономіки ринок важко надає премію.
Я вважаю, що оцінка після IrysTGE така:
Низьке відкриття: 3 мільярди – 5 мільярдів FDV;
2、нормально: 8 мільярдів - 12 мільярдів FDV
Враховуючи, що автор має низький ризик-профіль:
Якщо бізнес буде розвиватися успішно, і зможе утворити замкнуте коло з Tokenomics, а рівень оцінки буде нижче 300 мільйонів FDV, я куплю напряму. Якщо FDV досягне близько 500 мільйонів, я куплю маленьку позицію; вище 500 мільйонів буду спостерігати.
Якщо бізнес буде розвиватися неуспішно, або токеноміка не зможе співпрацювати з бізнесом, я залишуся в очікуванні і перенесу вагу індикаторів для оцінки тенденцій з фундаментальних на технічні.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Остаточне рішення для зберігання даних? Історія та сучасність ринку хмарного зберігання даних
Автор: Рей Джерело: X, @RayAC1397
Резюме: Від попередників сектора хмарного зберігання, аналізуючи зміни в цілому секторі та історії, далі аналізуючи питання Filcoin та Arweave, нарешті, аналізуючи бізнес-модель irys і прогнозуючи оцінку після TGE Irys. FDV Irys нижче 300 млн є недооцінкою, а щодо того, чи зможе він стабільно утримувати позицію лідера в секторі хмарних послуг у довгостроковій перспективі, необхідно звернути увагу на відповідність бізнесу та токеноміки, а також на те, чи зможуть основні випадки використання успішно реалізуватися.
Ключові слова: аналіз ринку хмарного зберігання, аналіз бізнес-моделі Filcoin, аналіз бізнес-моделі Arweave, представлення проекту Irys, прогноз оцінки, стратегічний аналіз Irys
Текст:
Розділ 1: Еволюція від кам'яної стіни до хмар
У далекій цивілізації Месопотамії люди вперше задумалися про зберігання інформації: наші предки розумно викарбували інформацію на "вічних" кам'яних табличках; під час промислової революції музика як форма інформації була збережена на платівках; а в епоху комп'ютерів люди винайшли касети, жорсткі диски, компакт-диски та інші засоби зберігання інформації...
Спосіб зберігання даних завжди був відображенням прогресу епохи.
У 1956 році IBM представила Model 350 - це була машина розміром з два холодильники, вагою майже в тонну, яка могла зберігати лише 5MB даних; для її установки в серверну використовувалися крани. Незважаючи на її громіздкість, вона вперше зробила "електронне зберігання" ресурсом, за який підприємства могли платити. Цей прорив змінив долю інформації: вона більше не залежала повністю від важкості паперу, а могла зберігатися на електромагнітних матеріалах, які могли існувати протягом тривалого часу. У наступні десятиліття виробники жорстких дисків розпочали невидиму війну. Компанії такі як SeaGate, Western Digital, Hitachi постійно підвищували щільність зберігання на дисках, дозволяючи все більше магнітних частинок розміщувати на кожному квадратному дюймі диска. Кожна технічна ітерація означала подвоєння ємності та зниження ціни. У 1990-х роках, з поширенням персональних комп'ютерів та зростанням Інтернету, ці виробники жорстких дисків стали основою всієї індустрії. У ті часи зберігання було "сировиною", а єдиним основним стандартом на ринку було: чия рішення для зберігання є найефективнішим, тобто дешевим і якісним. Однак, коли обсяги зберігання даних почали зростати експоненційно, першочерговою потребою підприємств стало "як забезпечити стабільність і безпеку даних". Операції банків, авіакомпаній, виробничих підприємств залежать від даних, для них навіть незначна помилка може призвести до величезних втрат. Таким чином, такі компанії, як EMC і NetApp, що займаються корпоративним зберіганням, стали на підйом, продаючи цілі комплекти систем зберігання та супутнє програмне забезпечення. У цей час бізнес-логіка ринку хмарного зберігання змінилася з одноразового сервісу на довгострокове співробітництво, корпоративні клієнти укладали довгострокові контракти на обслуговування та保障. Зберігання тут вперше було класифіковано як "бізнес-актив".
Час настав на початку 21 століття, коли Інтернет і мобільні технології дозволили даним почати перетинати кордони. Традиційні корпоративні рішення для зберігання виявилися громіздкими та дорогими перед потребами глобалізації. У 2006 році Amazon запустила сервіс S3, абстрагуючи зберігання в простий API: розробникам більше не потрібно було купувати серверні приміщення та диски, достатньо кількох рядків коду, щоб в будь-який час записати файли в хмару. Ця модель "за запитом" кардинально змінила звички розробників і надала стартапам можливість отримати таку ж інфраструктуру, як у великих компаній. Цінність хмарного зберігання полягає не в дешевизні, а в гнучкості та екосистемі. Воно перетворило зберігання з пристрою на "послугу, доступну в будь-який час онлайн". Незабаром Dropbox та Google Drive перенесли цей досвід на споживчий ринок. Користувачам не потрібно турбуватися про те, на якому комп'ютері зберігаються файли, головне мати доступ до мережі, щоб у будь-який час безперешкодно переключатися між телефоном, планшетом і ноутбуком. Концепція зберігання знову змінилася: дані більше не зберігаються на фізичних пристроях, а належать власному "кіберпростору" людини. Від магнітних барабанів IBM до масивів зберігання EMC і об'єктного зберігання AWS S3, еволюція зберігання даних неодноразово підтверджує одну закономірність: кожне нове керівництво стає успішним завдяки створенню або задоволенню нових вимог до використання даних. Перші жорсткі диски вирішили проблему обсягу, корпоративні рішення для зберігання задовольняли потреби у "стабільності та безпеці", а хмарне зберігання націлене на "гнучкість та масштабованість". Проте, за всім цим історичним контекстом залишається одна характеристика, яка ніколи не змінювалася: право власності на дані надмірно централізоване в руках постачальників хмарних послуг. У час, коли дані стали активами, це очевидно неприпустимо.
Отже, Web3 починає входити в гру.
Розділ 2: Логіка майнерів Filecoin та ідеалізм Arweave
У рамках системи Web2 право власності та контролю над даними сильно централізоване. Незалежно від того, чи це соціальні зв’язки Facebook, чи торгові дані Amazon, суть полягає в тому, що ці дані контролюються компанією. Користувачі, хоча й "використовують" їх, насправді ніколи не "володіють" ними. Компанії безсоромно заробляють на даних, в той час як користувачі залишаються безсилими, мов ягнята: коли особистий акаунт блокується, дані також зникають; коли компанії знімають контент через нормативні чи політичні тиски, ця інформація миттєво зникає з публічного простору.
Оттак, з'явився заклик до децентралізованого зберігання. У 2015 році проект IPFS запропонував новий підхід: шукати файли за допомогою "контентного хешу". Це означає, що будь-який вузол, який зберігає цей файл, може відповісти на запит, що вирішує проблему "ризику єдиного пункту зберігання". Але дуже швидко люди зрозуміли, що однієї технології недостатньо, без економічних стимулів вузли не будуть готові довго зберігати дані. Так з'явився Filecoin, який на основі IPFS додав токеноміку: майнери надають простір для зберігання, щоб отримати $FIL, протокол Filecoin використовує складні алгоритми доказу часу і простору, щоб перевірити, чи дані дійсно зберігаються. З точки зору дизайну, його основна ідея полягає в тому, щоб "перетворити зберігання на відкритий ринок", що дійсно спрацювало з боку пропозиції: лише за наявності токенових винагород можна організувати велику кількість майнерів для участі в екосистемних заходах. Але вони не врахували, що на ринку є не лише пропозиція, але й попит. У цей момент з'явилася велика кількість тих, хто використовує ситуацію. Стимул Filecoin в основному полягає в "наданні потужності та своєчасному наданні доказів", тому майнери природно більше піклуються про економічні вигоди, а не про те, як обслуговувати користувачів. Таким чином, знову з'явилася велика кількість тих, хто використовує ситуацію. Ви побачите структурну розрив: пропозиція надзвичайно активна, тоді як попит не зростає синхронно. Цей розрив швидко передається на рівень продукту. Команда, якій потрібно стабільне читання та запис, оцінюючи Filecoin, спочатку запитає три питання: що потрібно підготувати перед записом, в якому діапазоні знаходиться невизначеність затримки пошуку, і хто відповідає, якщо щось піде не так. З іншого боку, на стороні запису справжні бізнес-дані зазвичай супроводжуються постійними оновленнями, а семантика Filecoin природно схиляється до "фіксованого терміну, періодичного, з продовженням" холодного зберігання, розробники повинні додатково налаштувати індексацію, версії та стратегію продовження. А коли йдеться про пошук, виникає нова проблема: якщо вирішити зробити CDN та кешування самостійно, гранична вигода від використання Filecoin буде безмежно знижена; якщо покладатися на шлюзи або постачальників послуг третьої сторони, сервісні відносини знову стають "напівцентралізованими", а відповідальні особи ставлять під сумнів, чому не перейти на хмару. Останній етап - це межі відповідальності: докази на ланцюзі не можуть прямо відповідати за досвід використання продукту. Для корпоративних клієнтів навіть 1% невизначеності достатньо, щоб виключити Filecoin з ключових ланцюгів. Залежність від шляху, викликана дизайном стимулів, також проявляється у платниках. У ідеальному відкритому ринку платники повинні бути користувачами. Але коли на початку справжній попит був недостатнім, екосистема мусила використовувати стимули для залучення попиту (наприклад, надаючи певним наборам даних більш вигідні умови для запису). Це може короткочасно збільшити кількість угод, але важко довести, що "спонтанний, готовий продовжувати платити" попит дійсно існує. З часом фінансова модель з боку пропозиції обертається навколо "блокових субсидій, застави та конфіскації", тоді як бажання платити з боку попиту коливається навколо "чи є субсидії та ліміти", і ці дві системи не з'єднані насправді. Ось чому ви побачите новини про "великий обсяг даних на ланцюзі" в багатьох успішних випадках, але рідко побачите закінчену розповідь про "високочастотний пошук, постійне повторне використання та прибутковість верхнього рівня продукту".
Майже одночасно Arweave запропонував інше рішення: користувачі одноразово сплачують плату за зберігання, а мережа обіцяє довготривале збереження. Натхнення засновника Сема Вільямса походить з історії та соціології: якщо минуле можна стерти, то соціальна пам'ять більше не буде надійною. Цінність цього шляху очевидна: якщо певна цінність буде змінена або видалена, довіра суспільства буде підриватися.
Arweave конвертує "зберігання майбутнього" в одноразову оплату, мережа протягом тривалого часу безперервно копіює та зберігає дані, саме в цьому її привабливість. Але коли ви ставите це в контекст продуктів та бізнесу, виникає інша група питань. Перше — це напруга між "вічністю" та "ітерацією". Абсолютна більшість додатків не є одноразовим записом, який ніколи не оновлюється, а постійно переглядається, повертатиметься назад, A/B. Правильне використання Arweave полягає в тому, щоб розглядати кожну зміну як новий контент, записуючи його, а через індексацію вказувати на останню версію. Технічно це можливо, інженерно це також не складно, але проектування на рівні застосування завжди є проблемою: користувачі хочуть бачити лише останню версію, а не витрачати час на розуміння незмінного ланцюга часу. Друге — етичні проблеми, пов’язані з постійним зберіганням. Відкриті мережі неминуче міститимуть сіру та незаконну інформацію, протокол Arweave не може видаляти, лише покладається на "самодисципліну" та фільтрацію на рівнях шлюзу, фронтенду та індексації, що ускладнює ситуацію для розробників у питанні "відповідальності": як тільки ви берете на себе відповідальність за фільтрацію, ви стаєте суб’єктом відповідальності; якщо ж ви не візьмете на себе, ви втратите клієнтів. Третє — ідеалізація економічної системи. Обіцянка Arweave залежить від двох простих довгострокових припущень: постійного зниження вартості одиниці зберігання та підтримання сили копіювання в мережі протягом достатньо тривалого часу. Вони мають високу ймовірність справдження на макрорівні, але для окремого продуктового менеджера тиск на грошовий потік є дуже складним для вирішення, адже це означає одноразові великі витрати на запис, і навіть відсотки можуть налякати. З часом бізнес Arweave виявився обмеженим дуже маленьким сегментом ринку, оцінка так і не зуміла прорватися.
Розділ 3: AI та хмарне сховища, дані танцюють
Після того, як Filecoin і Arweave відкрили двері до Web3 хмарного зберігання, тривалий час цю галузь ніхто не цікавив. І саме в цей період виникла Irys. Її основне питання: чому дані не можуть рухатися самі? Оскільки момент запису в сховище за своєю суттю є "подією", чому ця подія не може негайно викликати логіку? Якщо сама мережа може виконувати функції середовища виконання, дані більше не є просто сплячими архівами, а стають одиницями, що керують додатками. Дизайн Irys базується саме на цьому. Вона більше не зосереджується на "логіці видобутку" Filecoin і "постійного зберігання" Arweave, а об'єднує зберігання та обчислення, пропонуючи концепцію "програмованого ланцюга даних". Запис даних автоматично викликає подію, дані несуть логіку в мережу, де вони безпосередньо виконуються в середовищі виконання Irys (IrysVM). Для розробників це означає перехід від "двухетапної" операції до "одинетапної" — запис означає виклик.
У попередньому тексті згадувалося, що за останнє півстоліття кожна еволюція зберігання відбулася через створення нових потреб. Тому я вважаю, що проактивність Irys особливо важлива в епоху ШІ. Моделі ШІ потребують великої кількості даних, а також надійних джерел і перевірених виконань. Традиційне зберігання блокує дані в холодних сховищах, а потім передає їх для обробки оффлайн-логікою, що є не тільки громіздким, але й залишає прогалини в надійності. А концепція даних Irys полягає в самостійності даних: вони можуть автоматично "підживлювати моделі", мають вбудовані правила обліку та доступу, здатні співпрацювати між організаціями без потреби у третій стороні.
З іншого боку, крутість Irys полягає в інтеграції зберігання, виконання та перевірки в одному базовому протоколі. Це означає, що дані, записані в різні протоколи, можуть бути безпосередньо зчитані та повторно використані один одним, навіть забезпечуючи більш складну логіку додатків. Тож, коли кількість вузлів зростає, загальна цінність мережі природним чином зростає, оскільки виявлення та комбінування даних постійно посилюється. Щоб зрозуміти це, можна подумати про Ethereum. Коли він впровадив смарт-контракти, багато людей не розуміли, чим це відрізняється від звичайних транзакцій на блокчейні, поки не з'явилися фінансові додатки, такі як Uniswap, Aave, Compound, і люди не усвідомили, що смарт-контракти – це насіння безмежного оповідання. Irys насправді робить щось подібне, лише об'єкт змінився з "фінансів" на "дані". Хоча дані занадто абстрактні, щоб бути такими ж очевидними, як гроші, як тільки екосистема накопичиться, розробники виявлять: я можу безпосередньо будувати на виходах даних інших, не покладаючись на зовнішні оракули чи повторне збори. Таке оповідання насправді дуже нагадує шлях AWS в ті часи. AWS не перемагав лише завдяки "дешевому зберіганню", а через цілий набір SDK, консолей, API, повністю закріплюючи розробників у своїй екосистемі. Якщо ви використовували один або два сервіси AWS, ви швидко будете залучені до зручності всієї системи AWS. Якщо Irys правильно реалізує співпрацю, наприклад, "високоякісні дані" будуть доступні лише при запису в Irys, це також створить подібну ціннісну блокування. У той час дані на Irys будуть не лише активами певного протоколу, а паливом для всієї екосистеми, і цей позитивний цикл врешті решт повернеться до самої мережі даних та цінності токенів.
Розділ 4: Оцінка Irys та ринок
Слід знати, що ідеали хоч і гарні, але реальність часто жорстока. Мати перспективний проєкт не означає неминучий успіх. Перша проблема, з якою стикається Irys, — це холодний старт. Якщо немає реального попиту, тобто достатньо додатків, готових споживати ці "програмовані дані", він перетвориться на ще одне дешеве рішення для зберігання. Другою проблемою є сумісність. Розробники вже глибоко залежать від інтерфейсів EVM, IPFS, AWS та інших, тому будь-яка нова парадигма підвищить витрати на навчання. Щоб Irys змогла зрушити ситуацію з мертвої точки, їй потрібно зробити "нульовий поріг використання" достатньо плавним. Третьою проблемою є управління. Як тільки дані можуть активувати логіку, це створює нові вектори атак: шахрайство з фальшивими даними, зловмисне активування ресурсів, суперечки з приводу авторських прав та конфіденційності. Централізоване хмарне сховище покладається на законодавство та повноваження, а децентралізовані протоколи повинні дати відповідь на питання механізму та управління, інакше їм буде важко отримати рівень впровадження в організаціях. Таким чином, чи є Irys богом чи дияволом, стане зрозуміло лише після запуску в основній мережі. Давайте сподіватися, що він зможе, як колись AWS, зробити абстракцію достатньо елегантною, а шаблонні сценарії - достатньо привабливими, щоби розробники захотіли замінити свої існуючі рішення на нього. З історичної точки зору, це ключовий момент, чи зможе вся інфраструктура позбутися старшого партнера і стати "наступним лідером".
Якщо б я був автором, я б звернув увагу на такі три шляхи:
Так само Irys має продемонструвати один-два вражаючі сценарії, такі як система реального часу стимулювання здоров'я або автоматичний механізм розрахунків для пристроїв DePIN.
Знизити поріг міграції. Звички розробників - це найважче, що можна змінити. Чому EVM став фактичним стандартом? Тому що він дозволяє людям використовувати старі інструменти та мови в новому середовищі. Irys повинна уникати "перепідготовки ринку", а натомість максимально сумісно працювати з існуючими звичками на рівні інтерфейсу, SDK та досвіду розробки.
Встановлення інструментів управління або екологічних правил. Як тільки дані можуть викликати логіку, це обов'язково призведе до атак і суперечок: фальшиві дані для отримання винагороди, злочинне спонукання до витрат ресурсів, сірі зони авторських прав. Якщо Irys зможе на механічному рівні надати інструменти "перевірка джерела даних", "обмеження злочинного спонукання", "вбудована логіка авторських прав та конфіденційності", то вона зможе завоювати довіру в сценаріях ToB та ToG. Інтенсивність війни на ринку хмарних технологій не можна недооцінювати. Хмарні постачальники все ще є величезними гігантами, зібрані рішення все ще гнучкі та дешеві, а поза ланцюгом моделі доказів є особливо дешевими. Але історія знову і знову доводить, що справжній прорив не відбувається через боротьбу в старій системі, а тоді, коли створюється певна нова звичка, яка стає стандартом, система лише тоді переформатовується. Irys має вирішити це основне питання, щоб стати лідером.
Щодо оцінки, на момент написання цієї статті, ринкова капіталізація $FIL становить 2 мільярди, а FDV досягає 4,7 мільярда; ринкова капіталізація $AR становить 400 мільйонів, практично повністю обігові. У той же час, ринкова капіталізація $Prove, інфраструктури ZK rolldown Succinct, що запустилася одночасно з BN, становить 200 мільйонів, а FDV - 1,1 мільярда. Враховуючи, що Irys має два великих концепти AI+хмарне зберігання, хоча концепція AI на ринку наразі процвітає, через величезну невизначеність з макроекономіки ринок важко надає премію.
Я вважаю, що оцінка після IrysTGE така:
2、нормально: 8 мільярдів - 12 мільярдів FDV
Враховуючи, що автор має низький ризик-профіль:
Якщо бізнес буде розвиватися успішно, і зможе утворити замкнуте коло з Tokenomics, а рівень оцінки буде нижче 300 мільйонів FDV, я куплю напряму. Якщо FDV досягне близько 500 мільйонів, я куплю маленьку позицію; вище 500 мільйонів буду спостерігати.
Якщо бізнес буде розвиватися неуспішно, або токеноміка не зможе співпрацювати з бізнесом, я залишуся в очікуванні і перенесу вагу індикаторів для оцінки тенденцій з фундаментальних на технічні.