Протокол хранения Walrus в экосистеме Sui выглядит очень впечатляюще, но когда начинаешь его использовать, появляется множество проблем. Как технолог, долгое время работающий в области распределённого хранения, должен сказать правду — официальная документация описывает только идеальные сценарии, а при реальном развёртывании возникают всевозможные проблемы.

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

Но такая эффективность приходит по цене, которая многократно возрастает при высоких нагрузках.

Во-первых, это вычислительные затраты на кодирование и декодирование. RaptorQ, хотя и признан отраслевым стандартом фонтанного кодирования, требует сложных матричных операций. Особенно при работе с файлами гигабайтного размера — практическое тестирование загрузки 5 ГБ файла модели искусственного интеллекта показало, что процесс кодирования потребляет свыше 90% ресурсов процессора клиента и занимает более 2 минут. Если приложение требует частой загрузки, эти затраты становятся явным узким местом производительности. Длительное время кодирования — это ещё полдела, потребление ресурсов при декодировании и восстановлении данных столь же впечатляющи.