Як працює Walrus: ролі користувачів, вузлів і рівня Sui

Перший раз, коли ви намагаєтеся передати великий файл через крипто-стек, ви помічаєте щось, про що рідко говорять відкрито трейдери — блокчейни чудово доводять дрібні факти, але справжні продукти живуть і вмирають на переміщенні хаотичних важких даних. Зображення, відео, контрольні точки моделей, архіви аудиту, дослідницькі PDF, навчальні набори та журнали — це те, що люди фактично генерують. Якщо система ускладнює збереження цих даних, робить їх дорогими для отримання або незрозумілими для власності, користувач тихо зникає. Walrus існує саме у цьому практичному проміжку. Він не намагається бути ще одним загальним ланцюгом. Його мета — зробити великі неструктуровані дані схожими на щось, про що ринки можуть раціонально думати, перевіряти та торгувати, не приписуючи цим даним самостійно належати базовому рівню реєстру.
На високому рівні Walrus розподіляє відповідальність між трьома ролями, які важливі для інвесторів, оскільки вони визначають, де знаходиться ризик і хто отримує оплату: користувачі, вузли зберігання та рівень Sui. Користувачі — це ті, хто створює попит. У термінах Walrus, користувач може бути автором, який зберігає об’єкт (blob), читачем, який його отримує, або власником токену, який ставить WAL для допомоги у забезпеченні системи без роботи обладнання. Вузли зберігання забезпечують ємність і доступність. Рівень Sui виступає як контрольна площина, тобто він зберігає авторитетний запис метаданих, власності та подій у мережі, що робить зобов’язання щодо зберігання виконуваними. Walrus називає себе площею даних (data plane), а Sui — контрольною площею (control plane), оскільки дані рухаються і живуть у вузлах, але права та правила залишаються на Sui.
Найпростіший спосіб зрозуміти, як це працює, — простежити один файл від моменту його завантаження. Автор кодує об’єкт у частини, розроблені для стійкості, потім реєструє його на Sui, щоб існував об’єкт у мережі, що його представляє, і закріплює його метадані. Власність на цей об’єкт Sui відповідає власності та контролю над об’єктом. Потім автор завантажує закодовані частини, часто звані «шматками» (slivers), на вузли зберігання, які отримали зобов’язання їх зберігати. Кожен вузол перевіряє отримане і повертає підписане підтвердження. Коли автор збирає достатньо підтверджень, ці підписи формують сертифікат, який публікується у мережі. Це публікація у мережі позначає Точку Доступності (Point of Availability), тобто момент, коли мережа може вважати об’єкт надійно доступним у визначеному часовому вікні, і автор може навіть перейти в офлайн, оскільки зобов’язання перейшли до набору вузлів.
Читання навмисно простіше за запис. Читач може запитати вузли про зобов’язання щодо об’єкта та достатню кількість «шматків» для відновлення оригінальних даних, а потім перевірити відновлення проти зобов’язань, щоб переконатися, що результат не лише доступний, а й правильний. Мета дизайну — щоб читання не залежало від довіри до одного вузла, і відновлення було можливим навіть якщо деякі вузли недоступні або зловмисні. У базовому дослідженні також зазначається, що вузли стежать за ланцюгом для подій PoA і можуть відновити відсутні «шматки» після факту, що важливо, оскільки зменшує крихкість при зміні комітету вузлів з часом.
Саме тут роль Sui перестає бути абстрактною і стає ядром системи. Sui не зберігає об’єкт, він забезпечує виконання реєстру власності, визначає, скільки його потрібно зберігати, і які переходи стану вважаються валідними. Команда Walrus просто формулює це так: кожен збережений об’єкт — це комодітабельний об’єкт у мережі Sui, і Sui є канонічним джерелом правди щодо цих метаданих. Такий дизайн дає розробникам можливість програмувати проти нього. Замість того, щоб казати «файл десь», смарт-контракт може посилатися на власний об’єкт, існування та стан якого можна перевірити, і цей об’єкт може стати частиною логіки додатку.
Для трейдерів і інвесторів економіка розташована посередині історії, а не на початку, оскільки ринок має значення лише тоді, коли робочий процес є надійним. У основній мережі Walrus користувачі платять дві окремі витрати: WAL за операції зберігання та SUI за транзакції у мережі, необхідні для реєстрації та сертифікації об’єктів. Документація чітко зазначає, що збереження об’єкта може включати до трьох транзакцій у мережі, і метадані об’єкта Walrus зберігаються як об’єкти Sui, що прив’язує деякі витрати до механіки фонду зберігання Sui і знижок. Також чітко зазначено, що закодований розмір, використовуваний для розрахунку вартості, може бути суттєво більшим за оригінальний об’єкт, приблизно у п’ять разів більшим плюс накладні витрати на метадані, і що метадані на об’єкт можуть бути достатньо великими, щоб дрібні об’єкти були непропорційно дорогими, якщо користувачі не групують їх. Walrus навіть постачає нативний інструмент для пакетної обробки під назвою Quilt, а SDK зазначає, що пакування файлів разом наразі рекомендується для підвищення ефективності.
WAL — це платіжний токен, і Walrus заявляє, що його механізм оплати розроблений так, щоб зберігати витрати на зберігання стабільними у фіатних термінах, розподіляючи попередньо оплачений WAL з часом між вузлами та стейкерами, при цьому делеговане стейкінг підкріплює безпеку. Офіційна сторінка токена також розкриває 10-відсоткове виділення для субсидій, спрямованих на раннє впровадження, і описує зниження штрафів і часткове згоряння комісій як стимули проти низької продуктивності та зловмисної поведінки. Це важливі довгострокові зобов’язання, оскільки вони встановлюють очікування щодо того, як протокол має підтримувати надійність пропозиції вузлів, поки попит зростає нерівномірно.
Станом на сьогодні ринкова ціна свідчить, що токен торгується у низьких десятках цента США, агрегатори показують приблизно $0.12 за WAL, близько $20 до $25 мільйонів у 24-годинному обсязі, і ринкова капіталізація у високих сотнях мільйонів залежно від методології джерела та припущень щодо циркулюючого запасу. Це той момент, коли тверезий інвестор має зупинитися і відокремити функцію протоколу від продуктивності токена. Протокол зберігання може бути технічно надійним і все одно стикатися з труднощами, якщо він не зможе тримати платоспроможних користувачів протягом кількох платіжних циклів.
Це проблема утримання, і вона не є теоретичною. Зберігання за своєю природою є повторюваним, але поведінка користувачів — ні. Люди один раз завантажують, один раз тестують, а потім повертаються до того, що здається найзручнішим. Утримання зазнає невдачі, коли робочі процеси заплутані, коли витрати важко передбачити, коли гаманці та підписи створюють тертя, або коли розробники не можуть зробити зберігання нативним у додатку. Walrus явно це усвідомлює. SDK чітко розбиває процес запису на кроки для браузерних середовищ, оскільки спливаючі вікна гаманця можуть бути заблоковані, якщо вони не прив’язані до дій користувача, що саме по собі є маленькою UX-деталлю, яка вбиває повторне використання. Документація також надає калькулятор витрат і рекомендації щодо оптимізації, оскільки несподіванки під час оплати — ще один надійний тригер відтоку.
Реальний приклад робить компроміси конкретними. Уявіть невелику дослідницьку команду, яка записує коментарі трейдерів, скріншоти та нотатки щодо виконання як докази для післяторгового огляду, а потім ділиться частиною з ними з клієнтами. Централізоване зберігання легко, поки не потрібно довести, що існувало у конкретний час, або потрібно портативне володіння між інструментами, або потрібно зупинити платформу від ставання мовчазним воротарем. З Walrus команда може зберігати архів у вигляді об’єктів, власність яких представлена Sui-об’єктами, а доступ ділитися, передаючи власність об’єкта або контрольовані посилання на рівні додатку. Цінність не в тому, що файли чарівні, а в тому, що існування, власність і зобов’язання щодо доступності можна перевірити без довіри до одного постачальника. Вартість у тому, що тепер потрібно керувати двома токенами, підписами користувачів, рішеннями щодо життєвого циклу, наприклад, коли згоряти об’єкти для знижок, і операційною дисципліною для розумного пакування.
Якщо ви оцінюєте Walrus як трейдер або інвестор, ставтеся до нього як до інфраструктури, а не до наративу. Стежте за тим, чи зростає попит на зберігання у спосіб, що виглядає стабільним, чи стимулює продуктивність вузлів стабільну доступність, і чи розробники створюють досвід, що приховує основний церемоніал від кінцевих користувачів. Використовуйте публічну документацію і калькулятор витрат для моделювання того, скільки справжній додаток заплатить при різних розмірах і тривалості об’єктів, і перевірте, чи ці цифри конкурують з альтернативами для сегментів, що фактично платять.
Не покладайтеся лише на графіки цін. Читайте документацію Walrus, проведіть невеликий експеримент із збереженням і отриманням даних, які справді генерує ваш робочий процес, і простежте шлях користувача від першого завантаження до другого місяця оновлень. Якщо система зможе зробити цей другий місяць беззусильним, утримання слідує, а у зберіганні — це вся справа.
@WalrusProtocol $WAL #Walrus