O protocolo de armazenamento Walrus no ecossistema Sui parece muito sofisticado, mas quando se trata de usá-lo na prática, há muitos problemas. Como técnico que trabalha há muito tempo com armazenamento distribuído, preciso ser honesto — a documentação oficial apenas descreve cenários ideais, mas durante a implementação real surgem vários problemas.

Começando pelo esquema de código de apagamento bidimensional do RedStuff. Este sistema é realmente engenhoso no papel: trata os dados como uma matriz de símbolos n×m, primeiro faz codificação RaptorQ nas colunas para gerar fragmentos principais, depois codificação Reed-Solomon nas linhas para gerar fragmentos secundários. Cada nó armazena um par de combinações de fragmentos principais e secundários, e apenas um terço dos nós é necessário para recuperar os dados completos. A redundância é controlada em 4 a 5 vezes, um número que é de facto mais eficiente que a replicação de 3 a 5 vezes de algumas exchanges líderes, e poupa mais espaço que o backup em toda a rede de algumas plataformas all-in-one.

Mas essa eficiência não é gratuita — o custo é amplificado várias vezes em cenários de alta carga.

Em primeiro lugar está o overhead computacional da codificação e descodificação. Embora o RaptorQ seja o padrão de código fonte reconhecido pela indústria, a complexidade das operações matriciais não é baixa. Especialmente ao lidar com ficheiros em escala GB, nos testes práticos ao enviar um ficheiro de modelo de IA de 5GB, o processo de codificação consome mais de 90% dos recursos de CPU do cliente, demorando mais de 2 minutos. Se a sua aplicação exigir uploads frequentes, este overhead torna-se um gargalo de desempenho óbvio. Além do tempo de codificação longo, o consumo de recursos durante a reconstrução de descodificação é igualmente assustador.