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

Почнемо з двовимірної схеми стирання кодів RedStuff. Ця система у статтях справді виглядає елегантно: дані представляються матрицею символів n×m, спочатку робиться RaptorQ кодування по стовпцях для створення основних фрагментів, потім Reed-Solomon кодування по рядках для створення допоміжних фрагментів. Кожен вузол зберігає пару основного та допоміжного фрагментів, і третини вузлів достатньо для відновлення повних даних. Надлишковість контролюється на рівні 4-5 разів, що справді краще за 3-5 разівне копіювання деяких провідних бірж і економить місце порівняно з повним резервним копіюванням мережі деяких універсальних платформ.

Але висока ефективність має свою ціну, яка істотно зростає в умовах високих навантажень.

По-перше, це обчислювальні витрати на кодування та декодування. Хоча RaptorQ визнаний галузевим стандартом фонтанних кодів, складність матричних операцій незначна. Особливо при обробці файлів розміром в гігабайти — під час тестування завантаження 5ГБ AI-моделі процес кодування споживає більше 90% ресурсів процесора клієнта та займає понад 2 хвилини. Якщо вашому додатку потрібно часто завантажувати файли, ці витрати стають явним вузьким місцем продуктивності. Довгий час кодування — це одне, але витрати ресурсів при декодуванні та відновленні даних рівні чудовищні.