Walrus як рішення для зберігання даних у екосистемі Sui означає глибоку технічну інтеграцію, що робить його стабільність залежною не лише від власної розподіленої мережі вузлів, але й безпосередньо від робочого стану основної мережі Sui.



Нам потрібно серйозно розглянути реальний екстремальний сценарій: що станеться з Walrus, якщо мережа Sui припинить генерувати блоки через вразливість механізму консенсусу або масований DDoS-атакування?

У період припинення роботи основної мережі Sui вузли зберігання Walrus продовжать працювати й дані на дисках залишатимуться цілісними, однак управління системи втратить можливість відповідати. Ви не зможете запросити нові квоти зберігання, не зможете змінити політику прав доступу, і навіть можете не мати змоги верифікувати право власності та права доступу до даних через смарт-контракти в мережі Sui. Результат — дані потрапляють у «зомбі-стан» — фізично вони існують, але логічно зроблені недоступними або неконтрольованими.

Особливо критично це для сценаріїв, де верифікація прав залежить від миттєвої перевірки в блокчейні. Наприклад, у випадку застосунків типу «розшифровка файлу доступна тільки власникам певного NFT» — при відмові Sui весь механізм верифікації паралізується, і навіть авторизовані користувачі не матимуть доступу до даних.

Виходячи з цього розуміння, при проектуванні критичних щодо доступності послуг я не припускаю, що L1 буде постійно стійко в мережі. Замість цього я розробляю «резервний план деградації»: кешування критичних метаданих і снімків прав доступу на стороні застосунку. При відмові мережі Sui застосунок може тимчасово перейти в режим локальної верифікації, використовуючи кешовані облікові дані для запиту даних прямо від вузлів Walrus — за умови, що вузли Walrus забезпечують якусь автономну верифікацію або застосунок має зарезервовані способи розшифрування.

Простіше кажучи, без такого «плану нештатної ситуації, що забезпечує базову роботу без залежності від основного ланцюга», всі системи децентралізованого зберігання даних виглядатимуть вразливими перед відмовою основного ланцюга.

Дdisclaimer: наведені вище — це особисті дослідницькі погляди, наведені виключно для технічного обговорення, і не становлять будь-яких інвестиційних рекомендацій.
SUI2,22%
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 10
  • Репост
  • Поділіться
Прокоментувати
0/400
GateUser-5854de8bvip
· 13год тому
Чесно кажучи, архітектура Walrus дуже залежить від Sui, і якщо основний ланцюг зламається, все стане марним.
Переглянути оригіналвідповісти на0
Ser_Liquidatedvip
· 01-12 12:03
Дані все ще зберігаються на жорсткому диску, але ланцюг обірвався... Це ж саме як шредінгерівське збереження, ха-ха --- Отже, в підсумку потрібно самостійно розробляти резервні копії, не можна покладатися лише на L1, щоб не втратити ланцюг --- Ризики архітектури Walrus досить високі, потрібно додати механізм офлайн-перевірки, щоб бути надійним --- Ще один випадок, коли "децентралізація" прив'язана до головного ланцюга, так глибоко ще не заглиблювалися --- Ідея кешування метаданих хороша, але чи є зараз проєкти, які дійсно це реалізували?
Переглянути оригіналвідповісти на0
EyeOfTheTokenStormvip
· 01-12 07:53
Це справжня правда, коли L1 виходить з ладу, ніхто тебе не врятує. --- Метафора "зомбі" стану даних занадто жорстка, але реальність саме така жорстока. --- Тому ключовим є наявність офлайн-режиму зниження рівня, інакше децентралізація — це просто сміховина. --- Ризик Walrus полягає не в самій технології, а у прив'язці до Sui. Це системна проблема. --- З точки зору кількісного аналізу, така сильна зв'язність значно підвищує загальний ризик збоїв. --- Кешування знімків дозволу — дійсно перспективна ідея, але залежить від того, чи погодяться вузли Walrus на це. --- Ще одна централізована прихована небезпека під прикриттям децентралізації? --- При виході з ладу механізм автентифікації повністю зупиняється, навіть легальні права не дозволять потрапити до бази даних, і це незручно.
Переглянути оригіналвідповісти на0
GasBanditvip
· 01-11 06:20
Знову стара проблема: збій L1, Walrus завис? Це вже давно слід було передбачити.
Переглянути оригіналвідповісти на0
SybilSlayervip
· 01-10 16:51
Знову з'явився парадокс "децентралізація, але без основного ланцюга", смішно
Переглянути оригіналвідповісти на0
MetadataExplorervip
· 01-10 16:50
Це саме типова ситуація "здається децентралізованим, але насправді не є" — проблема, яка виникає, коли Sui зупиняється, і дані просто заморожуються. Здається, нам радять самостійно придумати спосіб резервного копіювання і не покладатися занадто сильно на перевірку в мережі. Ця проблема, здається, більш серйозна, ніж ми думали — багато проектів можливо навіть не враховували цей сценарій. Справжнє рішення для децентралізованого зберігання має мати можливість офлайн-обробки помилок, інакше це лише ідеал. Техніка кешування сертифікатів звучить як тимчасове рішення, яке не вирішує основної проблеми.
Переглянути оригіналвідповісти на0
GasWhisperervip
· 01-10 16:49
ні, ситуація з зомбі-станом відчувається по-іншому... дані існують, але доторкнутися до них не можна, лол
Переглянути оригіналвідповісти на0
SwapWhisperervip
· 01-10 16:40
Дані все ще зберігаються на жорсткому диску, але якщо ланцюг мертвий, їх не можна використовувати — ось справжній парадокс децентралізації.
Переглянути оригіналвідповісти на0
EthMaximalistvip
· 01-10 16:30
Знову ця сама стара проблема... Відмова L1 Walrus — це провал, по суті, це проблема ланцюга, адже будь-який рівень зберігання мусить нести відповідальність за головний ланцюг.
Переглянути оригіналвідповісти на0
SchrödingersNodevip
· 01-10 16:28
Знову ця ж сама пастка з зчепленням, коли L1 падає на 1%, вся екосистема йде під укіс Ось чому я ніколи не вірив у цю ідею "повної децентралізації", в кінцевому підсумку все контролює основний ланцюг Має бути офлайн-резервний план — це правильний шлях, інакше будь-яка кількість даних зберігання буде марною
Переглянути оригіналвідповісти на0
Дізнатися більше
  • Закріпити