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

Найбільше головного болю проектним командам приносить просте і грубе питання: чи зможуть мої дані жити довго?

Це не порожні слова. Наприклад: середньомасштабний застосунок на блокчейні виконує від 3 до 6 оновлень стану за день, кожне з яких має обсяг від 30 до 80КБ. За рік ці історичні дані стану накопичуються до 30ГБ. До них додаються логи, перевірки, записи версій — і загалом обсяг даних часто вдвічі перевищує цю цифру.

Головне — ці дані не є холодними, їх не можна просто залишити і забути. Їх потрібно постійно мати під рукою для зворотнього відтворення, перевірки або повторного використання. Це стає безперервним навантаженням.

Зараз ідея Walrus досить цікава. Вона не вважає "оновлення" винятковою ситуацією, а сприймає його як норму щоденної роботи. Іншими словами, у цій системі об'єкт не замінюється, а постійно еволюціонує — посилання залишається незмінним, а вміст оновлюється в будь-який момент, при цьому вся історія залишається перевіреною.

З даних тестової мережі вже видно кілька помітних характеристик: підтримка великих об'єктів до МБ, можливість безкінечного оновлення без зміни ID об'єкта, стабільність доступності понад 99% за умов багатоядерної реплікації.

Моя думка щодо цього напрямку дуже проста: це не гра в короткострокову оптимізацію продуктивності, а орієнтація на довгострокову доступність — справжню проблему.

Але потрібно враховувати один ризик — якщо мотиваційний механізм вузлів буде недостатньо здоровим, ці довгострокові накопичені дані можуть навпаки стати тягарем для системи. І в кінцевому підсумку все залежить від екосистеми, яка має це довести.