Suiエコシステム内のWalrusストレージプロトコルは非常に高性能に見えますが、実際に使用してみると多くの落とし穴があります。長年分散ストレージに取り組んできた技術者として正直に言うと——公式ドキュメントは理想的な状況のみを説明しており、実際の展開時にはさまざまな問題が浮上します。

まず、RedStuffの二次元リード・ソロモン符号方案について述べます。この技術は論文では確かに巧妙です：データをn×mの記号行列と見なし、まず列に対してRaptorQ符号化を行い主分片を生成し、その後行に対してReed-Solomon符号化を行い副分片を生成します。各ノードは主副分片のペアを一つずつ保持し、全ノードの三分の一で完全なデータを復元可能です。冗長性は4倍から5倍に抑えられており、この数字はある大手取引所の3〜5倍のコピー複製よりも優れており、また一体型プラットフォームの全ネットワークバックアップよりも空間を節約しています。

しかし、高効率はただでは得られず、高負荷シナリオではそのコストが何倍にも膨らみます。

まず、エンコードとデコードの計算負荷です。RaptorQは業界標準のフラウンホーファー符号（喷泉码）ですが、行列演算の複雑さは決して低くありません。特にGB級のファイルを処理する場合、実際のテストで5GBのAIモデルファイルをアップロードすると、エンコード処理にクライアントのCPUリソースの90%以上を消費し、所要時間は2分を超えます。頻繁にアップロードが必要なアプリケーションでは、このオーバーヘッドが明らかなパフォーマンスのボトルネックとなります。エンコードに長時間かかるだけでなく、デコードや再構築時のリソース消費も非常に高いです。