Дорога еволюції Децентралізованого зберігання: від FIL до Shelby
Зберігання колись було одним з популярних напрямків у сфері блокчейну. Filecoin як провідний проект минулого бичачого ринку, його ринкова вартість на деякий час перевищила 10 мільярдів доларів. Arweave завдяки концепції постійного зберігання досягла максимальної ринкової вартості 3,5 мільярда доларів. Однак, з огляду на те, що практичність холодного зберігання даних була поставлена під сумнів, необхідність постійного зберігання також була оскаржена, перспективи децентралізованого зберігання на деякий час стали невизначеними.
Нещодавно поява Walrus принесла нову енергію в давно затихлу сферу зберігання. А проект Shelby, запущений спільно Aptos і Jump Crypto, має на меті підняти децентралізоване зберігання в області гарячих даних на новий рівень. Чи може децентралізоване зберігання знову відродитися та підтримати широкий спектр застосувань? Чи це лише ще один раунд спекуляцій на основі концепцій? У цій статті ми проаналізуємо розвиток чотирьох проектів: Filecoin, Arweave, Walrus і Shelby, щоб дослідити еволюцію децентралізованого зберігання та можливості його популяризації.
FIL: поверхневе зберігання, насправді видобуток
Filecoin є одним з перших децентралізованих проектів, його розвиток зосереджений на децентралізації, що є загальною характеристикою ранніх блокчейн-проектів. Filecoin поєднує зберігання з децентралізацією, намагаючись вирішити проблему довіри до централізованих постачальників послуг зберігання даних. Проте, деякі аспекти, які були принесені в жертву для досягнення децентралізації, стали болючими точками, які пізніше намагалися вирішити такі проекти, як Arweave або Walrus.
IPFS:Обмеження децентралізованої архітектури
IPFS(Міжгалактична файлова система)з'явилася ще в 2015 році, з метою перевернути традиційний протокол HTTP через адресацію вмісту. Однак, найбільшим недоліком IPFS є надзвичайно повільна швидкість отримання. У часи, коли традиційні дані можуть досягати мілісекундної реакції, для отримання файлу через IPFS все ще потрібно кілька секунд, що ускладнює його впровадження в реальних застосуваннях.
P2P-протокол, що лежить в основі IPFS, в основному підходить для "холодних даних", тобто для статичного контенту, який рідко змінюється. Але при обробці гарячих даних, таких як динамічні веб-сторінки, онлайн-ігри або AI-додатки, P2P-протокол не має помітних переваг у порівнянні з традиційними CDN.
Хоча IPFS сам по собі не є блокчейном, його спрямована ациклічна графічна структура (DAG) та концепція дизайну тісно пов'язані з багатьма публічними блокчейнами та протоколами Web3, що робить його природно придатним для використання як базової конструкційної основи для блокчейну. Тому, навіть якщо йому не вистачає практичної цінності, як базової основи для наративу блокчейну його вже достатньо.
Суть майнінгу під зовнішньою оболонкою зберігання
Дизайн IPFS був задуманий, щоб користувачі, зберігаючи дані, також ставали частиною мережі зберігання. Проте без економічних стимулів користувачам важко добровільно використовувати цю систему, не кажучи вже про те, щоб стати активними вузлами зберігання. Це означає, що більшість користувачів просто зберігатимуть файли в IPFS, але не надаватимуть свій простір для зберігання або не зберігатимуть файли інших. Саме в такому контексті виник FIL.
В економічній моделі токенів Filecoin основними є три ролі: користувачі відповідають за оплату витрат на зберігання даних; майнери зберігання отримують токен-інцентиви за зберігання даних користувачів; майнери пошуку надають дані, коли вони потрібні користувачам, і отримують винагороду.
Ця модель має потенційний простір для шахрайства. Майнери зберігання можуть заповнювати сміттєвими даними після надання простору для зберігання, щоб отримати винагороду. Оскільки ці сміттєві дані не підлягають запиту, навіть якщо вони втрачені, це не викликає механізм покарання. Це дозволяє майнерам зберігання видаляти сміттєві дані та повторювати цей процес. Консенсус на основі доказу копій у Filecoin може лише гарантувати, що дані користувача не були видалені без дозволу, але не може запобігти заповненню сміттєвими даними.
Запуск Filecoin значною мірою залежить від постійних вкладень майнерів у токеноміку, а не від реального попиту кінцевих користувачів на дистрибутивне зберігання. Хоча проект все ще продовжує ітерації, на даному етапі побудова екосистеми Filecoin більше відповідає визначенню "логіки видобутку", ніж "додаток, що керує" проектом зберігання.
Arweave: Переваги та обмеження довгострокового підходу
Порівняно з тим, що Filecoin намагається побудувати стимулюючу, підтверджену Децентралізацію "хмару даних", Arweave йде в іншому напрямку зберігання до крайності: забезпечуючи можливість постійного зберігання даних. Arweave не намагається побудувати розподілену обчислювальну платформу, вся її система розгортається навколо однієї основної гіпотези — важливі дані повинні зберігатися один раз і залишатися в мережі назавжди. Цей крайній довгостроковий підхід робить Arweave, від механізму до моделі стимулювання, від вимог до апаратного забезпечення до наративного аспекту, зовсім іншим від Filecoin.
Arweave, як об'єкт навчання, намагається постійно оптимізувати свою мережу постійного зберігання в довгостроковій перспективі, що вимірюється роками. Arweave не переймається маркетингом, не зважає на конкурентів і розвиток ринку. Воно просто продовжує вдосконалювати архітектуру мережі, навіть якщо ніхто не звертає на це уваги, адже це суть команди розробників Arweave: довгостроковий підхід. Завдяки довгостроковому підходу, Arweave отримала велику популярність під час минулого бичачого ринку; і через довгостроковий підхід, навіть впавши на дно, Arweave може пережити кілька раундів бичачих і ведмежих ринків. Лише майбутня Децентралізація зберігання покаже, чи має Arweave своє місце в цьому просторі. Цінність постійного зберігання може бути доведена лише часом.
Головна мережа Arweave з версії 1.5 до останньої версії 2.9, хоча й втратила ринкову увагу, продовжує працювати над тим, щоб дати можливість більшій кількості майнерів брати участь у мережі з мінімальними витратами та стимулювати майнерів максимально зберігати дані, що постійно підвищує міцність усієї мережі. Arweave усвідомлює, що не відповідає ринковим уподобанням, тому обрала консервативний шлях, не приймаючи майнерські спільноти, екосистема повністю застигла, з мінімальними витратами оновлює головну мережу, постійно знижуючи апаратні бар'єри, не завдаючи шкоди безпеці мережі.
Огляд шляху оновлення 1.5-2.9
Версія Arweave 1.5 виявила вразливість, яка дозволяє майнерам покладатися на стекування GPU, а не на реальне зберігання, щоб оптимізувати шанси на створення блоку. Щоб стримати цю тенденцію, у версії 1.7 впроваджено алгоритм RandomX, який обмежує використання спеціалізованих обчислювальних потужностей, вимагаючи замість цього участі загальних ЦП в майнінгу, що послаблює централізацію обчислювальної потужності.
У версії 2.0 Arweave використовує SPoA, перетворюючи доказ даних на компактний шлях структури Меркла, і впроваджує транзакції формату 2 для зменшення навантаження на синхронізацію. Ця архітектура зменшує тиск на мережеву пропускну спроможність, що значно підвищує здатність вузлів до співпраці. Однак деякі майнери все ще можуть уникати відповідальності за фактичне зберігання даних за допомогою централізованих стратегій швидкого зберігання.
Щоб виправити цю схильність, у 2.4 було впроваджено механізм SPoRA, який вводить глобальний індекс та повільний хеш-рандомний доступ, що змушує майнерів дійсно володіти блоками даних для участі у ефективному видобутку, що механічно послаблює ефект накопичення обчислювальної потужності. В результаті майнери почали звертати увагу на швидкість доступу до зберігання, що сприяло використанню SSD та високошвидкісних пристроїв для читання та запису. У 2.6 було введено контроль за ритмом видобутку за допомогою хеш-ланцюга, що забезпечує баланс між граничною вигодою високопродуктивних пристроїв і надає справедливий простір для участі малих та середніх майнерів.
Подальші версії подальшої зміцнюють мережеву співпрацю та різноманітність зберігання: 2.7 додає механізм спільного видобутку та майнінгових пулів, підвищуючи конкурентоспроможність малих майнерів; 2.8 запроваджує механізм композитного пакування, що дозволяє великим об'ємним повільним пристроям гнучко брати участь; 2.9 вводить новий процес пакування у форматі replica_2_9, значно підвищуючи ефективність та зменшуючи залежність від обчислень, завершуючи цикл моделі видобутку, орієнтованої на дані.
В цілому, шлях оновлення Arweave чітко демонструє його довгострокову стратегію, орієнтовану на зберігання: постійно протистоячи тенденції концентрації обчислювальної потужності, знижуючи бар'єри для участі, що забезпечує можливість тривалої роботи протоколу.
Walrus: нова спроба зберігання гарячих даних
Дизайнерська концепція Walrus абсолютно відрізняється від Filecoin та Arweave. Вихідна точка Filecoin полягає у створенні децентралізованої перевіряємого сховища, ціною якої є зберігання холодних даних; вихідна точка Arweave полягає у створенні онлайнової бібліотеки Олександра, яка може постійно зберігати дані, ціною якої є недостатня кількість сценаріїв; вихідна точка Walrus полягає в оптимізації витрат на зберігання протоколу для гарячих даних.
RedStuff: Інноваційні застосування коду корекції помилок
У дизайні витрат на зберігання Walrus вважає, що витрати на зберігання Filecoin та Arweave є нерозумними. Обидва вони використовують архітектуру повного копіювання, основною перевагою якої є те, що кожен вузол має повну копію, що забезпечує високу стійкість до збоїв і незалежність між вузлами. Така архітектура гарантує, що навіть якщо частина вузлів виходить з ладу, мережа все ще має доступність даних. Однак це також означає, що системі потрібні кілька копій для підтримання надійності, що підвищує витрати на зберігання. Особливо в дизайні Arweave механізм консенсусу сам по собі заохочує вузли до резервного зберігання, щоб підвищити безпеку даних. У порівнянні, Filecoin більш гнучкий у контролі витрат, але ціною цього є те, що деяке дешеве зберігання може мати вищий ризик втрати даних. Walrus намагається знайти баланс між обома, його механізм контролює витрати на копіювання, одночасно підвищуючи доступність за рахунок структурованого резервування, що дозволяє встановити новий компроміс між доступністю даних і ефективністю витрат.
RedStuff, створений Walrus, є ключовою технологією для зменшення надмірності вузлів, він походить з кодування Reed-Solomon ( RS ). Код RS є дуже традиційним алгоритмом кодування з корекцією помилок, кодування з корекцією помилок — це технологія, яка дозволяє подвоїти обсяг даних за рахунок додавання надмірних фрагментів, що може бути використано для відновлення оригінальних даних. Від CD-ROM до супутникового зв'язку та QR-кодів, вона часто використовується в повсякденному житті.
Код корекції дозволяє користувачам отримати блок, наприклад, розміром 1MB, а потім "розширити" його до 2MB, де додатковий 1MB є спеціальними даними, відомими як код корекції. Якщо будь-який байт у блоці втрачається, користувачі можуть легко відновити ці байти за допомогою коду. Навіть якщо втрачається до 1MB блоку, можна відновити весь блок. Така ж технологія дозволяє комп'ютерам зчитувати всі дані з CD-ROM, навіть якщо він пошкоджений.
Наразі найпоширенішим є кодування RS. Спосіб реалізації полягає в тому, щоб почати з k інформаційних блоків, побудувати відповідний багаточлен і оцінити його в різних x-координатах, щоб отримати закодовані блоки. Використовуючи RS коди виправлення помилок, ймовірність випадкової вибірки втрати великих обсягів даних є дуже малою.
Головною особливістю RedStuff є те, що завдяки вдосконаленню алгоритму кодування з виправленням помилок, Walrus може швидко та надійно кодувати неструктуровані блоки даних у менші фрагменти, які зберігаються в мережі зберігання вузлів. Навіть якщо втрачається до двох третин фрагментів, можна швидко відновити оригінальний блок даних, використовуючи частину фрагментів. Це стає можливим при збереженні фактора копіювання лише на рівні від 4 до 5.
Отже, визначити Walrus як легкий протокол надмірності та відновлення, перепроектований навколо Децентралізації, є розумним. На відміну від традиційних кодів корекції втрат (, таких як Reed-Solomon ), RedStuff більше не прагне до суворої математичної узгодженості, а натомість робить реалістичні компроміси щодо розподілу даних, перевірки зберігання та витрат на обчислення. Ця модель відмовляється від механізму миттєвого декодування, необхідного для централізованого планування, і замість цього здійснює перевірку Proof на ланцюгу, щоб підтвердити, чи має вузол конкретні копії даних, що дозволяє адаптуватися до більш динамічної, маргіналізованої мережевої структури.
Основна концепція дизайну RedStuff полягає в розділенні даних на два типи: основні шматки та додаткові шматки. Основні шматки використовуються для відновлення оригінальних даних, їх генерація та розподіл підлягають строгим обмеженням, поріг відновлення становить f+1, а також потрібні підписи 2f+1 як підтвердження доступності; додаткові шматки генеруються простими обчисленнями, такими як XOR-комбінації, і їх роль полягає в забезпеченні еластичної відмовостійкості та підвищенні загальної надійності системи. Така структура суттєво знижує вимоги до узгодженості даних — дозволяючи різним вузлам короткочасно зберігати різні версії даних, підкреслюючи практичний шлях «кінцевої узгодженості». Хоча це схоже на м’які вимоги до зворотних блоків у системах, таких як Arweave, і досягнуто певного ефекту в зменшенні навантаження на мережу, але одночасно ослаблює гарантії миттєвої доступності даних та цілісності.
Не можна ігнорувати, що RedStuff, хоча і реалізував ефективне зберігання в умовах низької обчислювальної потужності та низької пропускної здатності, все ж таки є своєрідним "варіантом" системи кодів для виправлення помилок. Він жертвує частиною визначеності читання даних заради контролю витрат і масштабованості в децентралізованому середовищі. Але на рівні застосування залишається відкритим питання, чи може така архітектура підтримувати великомасштабні, часті взаємодії даних. Ще далі, RedStuff насправді не подолав довгострокові обчислювальні проблеми кодів для виправлення помилок.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
4
Поділіться
Прокоментувати
0/400
DeFiDoctor
· 08-01 08:13
Клінічне спостереження: гарячі дані - це лише старі хвороби в новому вбранні.
Переглянути оригіналвідповісти на0
AirdropCollector
· 08-01 08:12
Старий fil, напевно, буде вилучений.
Переглянути оригіналвідповісти на0
TokenAlchemist
· 08-01 08:10
виявлено неефективний вектор... все ще бичачий щодо fil, але наратив холодного зберігання мертвий fr
Від холодних даних до гарячих даних: шлях еволюції децентралізованого сховища
Дорога еволюції Децентралізованого зберігання: від FIL до Shelby
Зберігання колись було одним з популярних напрямків у сфері блокчейну. Filecoin як провідний проект минулого бичачого ринку, його ринкова вартість на деякий час перевищила 10 мільярдів доларів. Arweave завдяки концепції постійного зберігання досягла максимальної ринкової вартості 3,5 мільярда доларів. Однак, з огляду на те, що практичність холодного зберігання даних була поставлена під сумнів, необхідність постійного зберігання також була оскаржена, перспективи децентралізованого зберігання на деякий час стали невизначеними.
Нещодавно поява Walrus принесла нову енергію в давно затихлу сферу зберігання. А проект Shelby, запущений спільно Aptos і Jump Crypto, має на меті підняти децентралізоване зберігання в області гарячих даних на новий рівень. Чи може децентралізоване зберігання знову відродитися та підтримати широкий спектр застосувань? Чи це лише ще один раунд спекуляцій на основі концепцій? У цій статті ми проаналізуємо розвиток чотирьох проектів: Filecoin, Arweave, Walrus і Shelby, щоб дослідити еволюцію децентралізованого зберігання та можливості його популяризації.
FIL: поверхневе зберігання, насправді видобуток
Filecoin є одним з перших децентралізованих проектів, його розвиток зосереджений на децентралізації, що є загальною характеристикою ранніх блокчейн-проектів. Filecoin поєднує зберігання з децентралізацією, намагаючись вирішити проблему довіри до централізованих постачальників послуг зберігання даних. Проте, деякі аспекти, які були принесені в жертву для досягнення децентралізації, стали болючими точками, які пізніше намагалися вирішити такі проекти, як Arweave або Walrus.
IPFS:Обмеження децентралізованої архітектури
IPFS(Міжгалактична файлова система)з'явилася ще в 2015 році, з метою перевернути традиційний протокол HTTP через адресацію вмісту. Однак, найбільшим недоліком IPFS є надзвичайно повільна швидкість отримання. У часи, коли традиційні дані можуть досягати мілісекундної реакції, для отримання файлу через IPFS все ще потрібно кілька секунд, що ускладнює його впровадження в реальних застосуваннях.
P2P-протокол, що лежить в основі IPFS, в основному підходить для "холодних даних", тобто для статичного контенту, який рідко змінюється. Але при обробці гарячих даних, таких як динамічні веб-сторінки, онлайн-ігри або AI-додатки, P2P-протокол не має помітних переваг у порівнянні з традиційними CDN.
Хоча IPFS сам по собі не є блокчейном, його спрямована ациклічна графічна структура (DAG) та концепція дизайну тісно пов'язані з багатьма публічними блокчейнами та протоколами Web3, що робить його природно придатним для використання як базової конструкційної основи для блокчейну. Тому, навіть якщо йому не вистачає практичної цінності, як базової основи для наративу блокчейну його вже достатньо.
Суть майнінгу під зовнішньою оболонкою зберігання
Дизайн IPFS був задуманий, щоб користувачі, зберігаючи дані, також ставали частиною мережі зберігання. Проте без економічних стимулів користувачам важко добровільно використовувати цю систему, не кажучи вже про те, щоб стати активними вузлами зберігання. Це означає, що більшість користувачів просто зберігатимуть файли в IPFS, але не надаватимуть свій простір для зберігання або не зберігатимуть файли інших. Саме в такому контексті виник FIL.
В економічній моделі токенів Filecoin основними є три ролі: користувачі відповідають за оплату витрат на зберігання даних; майнери зберігання отримують токен-інцентиви за зберігання даних користувачів; майнери пошуку надають дані, коли вони потрібні користувачам, і отримують винагороду.
Ця модель має потенційний простір для шахрайства. Майнери зберігання можуть заповнювати сміттєвими даними після надання простору для зберігання, щоб отримати винагороду. Оскільки ці сміттєві дані не підлягають запиту, навіть якщо вони втрачені, це не викликає механізм покарання. Це дозволяє майнерам зберігання видаляти сміттєві дані та повторювати цей процес. Консенсус на основі доказу копій у Filecoin може лише гарантувати, що дані користувача не були видалені без дозволу, але не може запобігти заповненню сміттєвими даними.
Запуск Filecoin значною мірою залежить від постійних вкладень майнерів у токеноміку, а не від реального попиту кінцевих користувачів на дистрибутивне зберігання. Хоча проект все ще продовжує ітерації, на даному етапі побудова екосистеми Filecoin більше відповідає визначенню "логіки видобутку", ніж "додаток, що керує" проектом зберігання.
Arweave: Переваги та обмеження довгострокового підходу
Порівняно з тим, що Filecoin намагається побудувати стимулюючу, підтверджену Децентралізацію "хмару даних", Arweave йде в іншому напрямку зберігання до крайності: забезпечуючи можливість постійного зберігання даних. Arweave не намагається побудувати розподілену обчислювальну платформу, вся її система розгортається навколо однієї основної гіпотези — важливі дані повинні зберігатися один раз і залишатися в мережі назавжди. Цей крайній довгостроковий підхід робить Arweave, від механізму до моделі стимулювання, від вимог до апаратного забезпечення до наративного аспекту, зовсім іншим від Filecoin.
Arweave, як об'єкт навчання, намагається постійно оптимізувати свою мережу постійного зберігання в довгостроковій перспективі, що вимірюється роками. Arweave не переймається маркетингом, не зважає на конкурентів і розвиток ринку. Воно просто продовжує вдосконалювати архітектуру мережі, навіть якщо ніхто не звертає на це уваги, адже це суть команди розробників Arweave: довгостроковий підхід. Завдяки довгостроковому підходу, Arweave отримала велику популярність під час минулого бичачого ринку; і через довгостроковий підхід, навіть впавши на дно, Arweave може пережити кілька раундів бичачих і ведмежих ринків. Лише майбутня Децентралізація зберігання покаже, чи має Arweave своє місце в цьому просторі. Цінність постійного зберігання може бути доведена лише часом.
Головна мережа Arweave з версії 1.5 до останньої версії 2.9, хоча й втратила ринкову увагу, продовжує працювати над тим, щоб дати можливість більшій кількості майнерів брати участь у мережі з мінімальними витратами та стимулювати майнерів максимально зберігати дані, що постійно підвищує міцність усієї мережі. Arweave усвідомлює, що не відповідає ринковим уподобанням, тому обрала консервативний шлях, не приймаючи майнерські спільноти, екосистема повністю застигла, з мінімальними витратами оновлює головну мережу, постійно знижуючи апаратні бар'єри, не завдаючи шкоди безпеці мережі.
Огляд шляху оновлення 1.5-2.9
Версія Arweave 1.5 виявила вразливість, яка дозволяє майнерам покладатися на стекування GPU, а не на реальне зберігання, щоб оптимізувати шанси на створення блоку. Щоб стримати цю тенденцію, у версії 1.7 впроваджено алгоритм RandomX, який обмежує використання спеціалізованих обчислювальних потужностей, вимагаючи замість цього участі загальних ЦП в майнінгу, що послаблює централізацію обчислювальної потужності.
У версії 2.0 Arweave використовує SPoA, перетворюючи доказ даних на компактний шлях структури Меркла, і впроваджує транзакції формату 2 для зменшення навантаження на синхронізацію. Ця архітектура зменшує тиск на мережеву пропускну спроможність, що значно підвищує здатність вузлів до співпраці. Однак деякі майнери все ще можуть уникати відповідальності за фактичне зберігання даних за допомогою централізованих стратегій швидкого зберігання.
Щоб виправити цю схильність, у 2.4 було впроваджено механізм SPoRA, який вводить глобальний індекс та повільний хеш-рандомний доступ, що змушує майнерів дійсно володіти блоками даних для участі у ефективному видобутку, що механічно послаблює ефект накопичення обчислювальної потужності. В результаті майнери почали звертати увагу на швидкість доступу до зберігання, що сприяло використанню SSD та високошвидкісних пристроїв для читання та запису. У 2.6 було введено контроль за ритмом видобутку за допомогою хеш-ланцюга, що забезпечує баланс між граничною вигодою високопродуктивних пристроїв і надає справедливий простір для участі малих та середніх майнерів.
Подальші версії подальшої зміцнюють мережеву співпрацю та різноманітність зберігання: 2.7 додає механізм спільного видобутку та майнінгових пулів, підвищуючи конкурентоспроможність малих майнерів; 2.8 запроваджує механізм композитного пакування, що дозволяє великим об'ємним повільним пристроям гнучко брати участь; 2.9 вводить новий процес пакування у форматі replica_2_9, значно підвищуючи ефективність та зменшуючи залежність від обчислень, завершуючи цикл моделі видобутку, орієнтованої на дані.
В цілому, шлях оновлення Arweave чітко демонструє його довгострокову стратегію, орієнтовану на зберігання: постійно протистоячи тенденції концентрації обчислювальної потужності, знижуючи бар'єри для участі, що забезпечує можливість тривалої роботи протоколу.
Walrus: нова спроба зберігання гарячих даних
Дизайнерська концепція Walrus абсолютно відрізняється від Filecoin та Arweave. Вихідна точка Filecoin полягає у створенні децентралізованої перевіряємого сховища, ціною якої є зберігання холодних даних; вихідна точка Arweave полягає у створенні онлайнової бібліотеки Олександра, яка може постійно зберігати дані, ціною якої є недостатня кількість сценаріїв; вихідна точка Walrus полягає в оптимізації витрат на зберігання протоколу для гарячих даних.
RedStuff: Інноваційні застосування коду корекції помилок
У дизайні витрат на зберігання Walrus вважає, що витрати на зберігання Filecoin та Arweave є нерозумними. Обидва вони використовують архітектуру повного копіювання, основною перевагою якої є те, що кожен вузол має повну копію, що забезпечує високу стійкість до збоїв і незалежність між вузлами. Така архітектура гарантує, що навіть якщо частина вузлів виходить з ладу, мережа все ще має доступність даних. Однак це також означає, що системі потрібні кілька копій для підтримання надійності, що підвищує витрати на зберігання. Особливо в дизайні Arweave механізм консенсусу сам по собі заохочує вузли до резервного зберігання, щоб підвищити безпеку даних. У порівнянні, Filecoin більш гнучкий у контролі витрат, але ціною цього є те, що деяке дешеве зберігання може мати вищий ризик втрати даних. Walrus намагається знайти баланс між обома, його механізм контролює витрати на копіювання, одночасно підвищуючи доступність за рахунок структурованого резервування, що дозволяє встановити новий компроміс між доступністю даних і ефективністю витрат.
RedStuff, створений Walrus, є ключовою технологією для зменшення надмірності вузлів, він походить з кодування Reed-Solomon ( RS ). Код RS є дуже традиційним алгоритмом кодування з корекцією помилок, кодування з корекцією помилок — це технологія, яка дозволяє подвоїти обсяг даних за рахунок додавання надмірних фрагментів, що може бути використано для відновлення оригінальних даних. Від CD-ROM до супутникового зв'язку та QR-кодів, вона часто використовується в повсякденному житті.
Код корекції дозволяє користувачам отримати блок, наприклад, розміром 1MB, а потім "розширити" його до 2MB, де додатковий 1MB є спеціальними даними, відомими як код корекції. Якщо будь-який байт у блоці втрачається, користувачі можуть легко відновити ці байти за допомогою коду. Навіть якщо втрачається до 1MB блоку, можна відновити весь блок. Така ж технологія дозволяє комп'ютерам зчитувати всі дані з CD-ROM, навіть якщо він пошкоджений.
Наразі найпоширенішим є кодування RS. Спосіб реалізації полягає в тому, щоб почати з k інформаційних блоків, побудувати відповідний багаточлен і оцінити його в різних x-координатах, щоб отримати закодовані блоки. Використовуючи RS коди виправлення помилок, ймовірність випадкової вибірки втрати великих обсягів даних є дуже малою.
Головною особливістю RedStuff є те, що завдяки вдосконаленню алгоритму кодування з виправленням помилок, Walrus може швидко та надійно кодувати неструктуровані блоки даних у менші фрагменти, які зберігаються в мережі зберігання вузлів. Навіть якщо втрачається до двох третин фрагментів, можна швидко відновити оригінальний блок даних, використовуючи частину фрагментів. Це стає можливим при збереженні фактора копіювання лише на рівні від 4 до 5.
Отже, визначити Walrus як легкий протокол надмірності та відновлення, перепроектований навколо Децентралізації, є розумним. На відміну від традиційних кодів корекції втрат (, таких як Reed-Solomon ), RedStuff більше не прагне до суворої математичної узгодженості, а натомість робить реалістичні компроміси щодо розподілу даних, перевірки зберігання та витрат на обчислення. Ця модель відмовляється від механізму миттєвого декодування, необхідного для централізованого планування, і замість цього здійснює перевірку Proof на ланцюгу, щоб підтвердити, чи має вузол конкретні копії даних, що дозволяє адаптуватися до більш динамічної, маргіналізованої мережевої структури.
Основна концепція дизайну RedStuff полягає в розділенні даних на два типи: основні шматки та додаткові шматки. Основні шматки використовуються для відновлення оригінальних даних, їх генерація та розподіл підлягають строгим обмеженням, поріг відновлення становить f+1, а також потрібні підписи 2f+1 як підтвердження доступності; додаткові шматки генеруються простими обчисленнями, такими як XOR-комбінації, і їх роль полягає в забезпеченні еластичної відмовостійкості та підвищенні загальної надійності системи. Така структура суттєво знижує вимоги до узгодженості даних — дозволяючи різним вузлам короткочасно зберігати різні версії даних, підкреслюючи практичний шлях «кінцевої узгодженості». Хоча це схоже на м’які вимоги до зворотних блоків у системах, таких як Arweave, і досягнуто певного ефекту в зменшенні навантаження на мережу, але одночасно ослаблює гарантії миттєвої доступності даних та цілісності.
Не можна ігнорувати, що RedStuff, хоча і реалізував ефективне зберігання в умовах низької обчислювальної потужності та низької пропускної здатності, все ж таки є своєрідним "варіантом" системи кодів для виправлення помилок. Він жертвує частиною визначеності читання даних заради контролю витрат і масштабованості в децентралізованому середовищі. Але на рівні застосування залишається відкритим питання, чи може така архітектура підтримувати великомасштабні, часті взаємодії даних. Ще далі, RedStuff насправді не подолав довгострокові обчислювальні проблеми кодів для виправлення помилок.