Ao falar de protocolos de armazenamento, todos falam em preço, velocidade, TPS, mas na verdade, após mais de um ano de operação, esses não são os maiores problemas.

O que realmente preocupa as equipes de projeto é uma questão simples e direta: meus dados podem permanecer vivos a longo prazo?

Isso não é conversa fiada. Vamos pegar um exemplo qualquer: uma aplicação de médio porte na cadeia, que precisa fazer de 3 a 6 atualizações de estado por dia, cada uma com entre 30 a 80KB de dados. Ao longo de um ano, esses dados históricos de estado acumulam-se até atingir 30GB. Além disso, logs, verificações, registros de versões, esses itens geralmente dobram esse volume.

O mais importante é que esses dados não são como dados frios que podem ficar lá descansando. Você precisa estar sempre preparado para retroceder, verificar, e até reutilizar esses dados. Isso se torna uma carga contínua.

A abordagem do Walrus é bastante interessante. Ela não trata "atualizações" como exceções, mas as incorpora como parte da operação diária. Em outras palavras, neste sistema, um objeto não é substituído, mas está sempre evoluindo — a referência permanece a mesma, o conteúdo é atualizado a qualquer momento, e todo o histórico ainda pode ser verificado.

Com os dados da rede de testes atual, já podemos observar algumas características marcantes: suporte a objetos grandes de até MBs, atualizações ilimitadas sem alterar o ID do objeto, e uma disponibilidade estável acima de 99% com redundância em múltiplos nós.

Minha opinião sobre essa direção é bem direta: não estamos brincando de otimização de desempenho de curto prazo, mas mirando na verdadeira dor da usabilidade a longo prazo.

Mas também é preciso dizer que há um risco pendente — se o mecanismo de incentivo dos nós não for saudável, esses dados acumulados a longo prazo podem se transformar em um fardo para o sistema. No final, tudo depende de a própria ecologia provar seu valor.