ストレージプロトコルについて話すとき、多くの人は価格、速度、TPSを口にしますが、実際に1年以上稼働しているシステムでは、これらは決して最も深刻な問題ではありません。

プロジェクト側が本当に頭を悩ませているのは、シンプルで荒っぽい問題です：私のデータは長期的に生き続けられるのか？

これは空虚な言葉ではありません。例を挙げると、中規模のオンチェーンアプリケーションでは、1日に3〜6回の状態更新を行い、各回のデータ量は30〜80KBです。1年でこれらの履歴状態データは30GBに達します。さらにログ、検証、バージョン記録などを加えると、データ量はこの数字の2倍になることもあります。

重要なのは、これらのデータは冷データのようにただそこに横たわって眠るわけではないということです。常に遡って検証したり、取り出して再利用したりする必要があります。これが継続的な負担となるのです。

現在のWalrusのアイデアは非常に面白いです。これは「更新」を例外的なケースとして扱うのではなく、日常運用の常態として直接捉えています。言い換えれば、このシステムでは、オブジェクトは置き換えられるのではなく、常に進化し続けるのです——参照は常に変わらず、内容は随時更新され、全履歴も検証可能です。

現行のテストネットのデータからは、いくつかの目を引く特徴が見て取れます：MB級の大きなオブジェクトをサポートし、無限に更新してもオブジェクトIDは変わらず、多ノード冗長性の下で可用性は99%以上を維持しています。

この方向性に対する私の見解は非常にストレートです：これは短期的なパフォーマンス最適化を遊びとしているのではなく、長期的な可用性という本当の痛点を狙ったものです。

ただし、懸念もあります——もしノードのインセンティブメカニズムが十分に健全でなければ、これら長期にわたる蓄積データは逆にシステムの負担になり得るということです。最終的にはエコシステム自体が証明しなければなりません。