2026-01-07 19:25:37

Muitas pessoas, ao conhecerem o Walrus pela primeira vez, pensam imediatamente em "mais uma solução de armazenamento descentralizado".

Mas, se você olhar de outro ângulo, com os olhos de um desenvolvedor ou de um designer de protocolo, verá algo mais profundo: o que este protocolo precisa resolver não é apenas um problema de armazenamento, mas como fazer com que os dados, mantendo sua confiabilidade, possam evoluir de forma flexível ao longo do sistema.

Vamos começar com um fenômeno contraintuitivo.

No mundo on-chain, há uma paradoxo: os dados mais seguros costumam ser os mais difíceis de usar. Por quê? Porque, uma vez que os dados recebem a etiqueta de "imutável", qualquer modificação, adição ou correção precisa ser reescrita do zero. Isso não é um problema para o livro-razão, mas para a camada de aplicação, torna-se uma grande fricção.

No mundo real, os dados nunca são fixos. Conteúdos gerados pelos usuários precisam ser editados, conjuntos de treinamento de modelos de IA precisam ser continuamente otimizados, o estado de jogos deve ser atualizado em tempo real, e resultados de cálculos off-chain também precisam ser constantemente validados. Bancos de dados centralizados resolvem elegantemente esse problema com mecanismos de controle de versões, mas em sistemas descentralizados, essa área permanece há muito tempo vazia.

A inovação do Walrus está aqui. Ele não nega a imutabilidade, mas redefine o que deve permanecer inalterado. A abordagem específica é separar a "identidade do objeto de dado" da "situação do objeto de dado" — o mesmo objeto de dado pode manter uma identidade estável, enquanto permite múltiplas iterações de seu estado, cada uma podendo ser validada de forma independente.

O efeito mais direto dessa mudança é na forma de trabalhar dos desenvolvedores. Antes, toda vez que os dados mudavam, era preciso replanejar o armazenamento e ajustar a lógica de acesso. Agora, isso não é mais necessário.

Ver original

Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.

13 Curtidas

Recompensa
13
9
Repostar
Compartilhar

Comentário

0/400

WhaleWatcher

· 11h atrás

Hmm… a ideia de separar identidade e estado é realmente genial, finalmente alguém entendeu esse ponto sensível.

Ver originalResponder0

MaticHoleFiller

· 01-08 02:13

Oh esta abordagem de design é interessante, a separação de identidade e estado realmente resolve várias dores --- A parte de controle de versão tem razão, bases de dados centralizadas já foram gastas faz tempo, esta abordagem descentralizada realmente ficou travada por muito tempo --- Espera, dessa forma como garantir a consistência dos dados? Parece que ainda há risco --- Resumindo, é querer tornar os dados on-chain também capazes de versionar como git, boa ideia mas a implementação? --- A melhoria na experiência do desenvolvedor é real, mas isso não vai virar uma nova desculpa para certos projetos ceifarem agricultores? --- A ideia de separar identidade e estado já vi algo similar, não é particularmente nova --- Parece estar resolvendo problemas reais, mas precisa ver quem realmente usa no ecossistema para saber se é confiável

Ver originalResponder0

DefiSecurityGuard

· 01-07 19:53

ok então estão a apresentar isto como um padrão de design genial mas... separação de identidade vs estado? isso é literalmente apenas versionamento com passos extras. já vi este vetor de exploração antes—o que acontece quando alguém sequestra a camada de "identidade"? o relatório de auditoria não diz nada sobre controlo de acesso aqui. DYOR antes de tocar nisso, não é conselho financeiro.

Ver originalResponder0

BrokenDAO

· 01-07 19:52

嗯...identidade estável pode ser iterada, essa lógica realmente é mais clara do que a maioria das soluções descentralizadas. Mas o ponto-chave ainda é como estabelecer o mecanismo de incentivo — quem vai manter essa cadeia de versões? Falando sério, toda vez que ouço a parte do protocolo dizer "resolvemos o atrito", no final quem realmente trava são as questões de equilíbrio de jogo. Esse design de separação soa bem na teoria, mas na prática, os nós vão ficar preguiçosos na validação? Todo dia uma nova solução, só quero ver como o modelo econômico do Walrus realmente previne esse tipo de coisa. Mas realmente tocou na dor da camada de aplicação do Web3 — a imutabilidade por si só é uma armadilha de centralização disfarçada. Parece interessante, mas ainda estou esperando para ver se algum projeto realmente vai usar isso antes de tirar conclusões. Aquelas campanhas exageradas de antes, no final, eram só uma festa de distorção de incentivos. Essa vez, a ideia de design não é tão ingênua quanto eu esperava, mas se me pedissem para apostar, ainda apostaria que, ao enfrentar problemas reais de governança, ela vai ruir.

Ver originalResponder0

NFTDreamer

· 01-07 19:49

Oh, realmente não tinha pensado nesse ângulo, a ideia de separar identidade e estado é bastante engenhosa.

Ver originalResponder0

mev_me_maybe

· 01-07 19:44

Estado de separação de identidade, essa é a ideia, finalmente alguém explicou bem essa questão --- Espera aí, isso significa que as aplicações na cadeia finalmente não precisam reescrever toda a lógica só para alterar um dado? Como é que aguentaram antes --- Acho que essa é a forma correta de armazenamento, não apenas uma pilha de descentralização --- Portanto, o Walrus essencialmente resolve o problema de gestão de versões de contratos inteligentes, ninguém tinha feito isso direito antes --- Essa ideia de identidade estável, estado iterável, é genial, os desenvolvedores de jogos na cadeia de jogos devem dizer que é uma verdadeira expertise --- Falando sério, após entender a essência da imutabilidade e as diferenças nas necessidades reais, de repente percebo que muitas soluções de armazenamento são muito superficiais

Ver originalResponder0

HypotheticalLiquidator

· 01-07 19:27

Parece bom, mas a questão é: uma vez que essa mecânica de separação de identidade atinge escala, o custo de validação não vai ficar fora de controle? --- A iteração de dados ficou mais flexível, mas e o fator de saúde? Quanto mais versões, mais fácil é aparecerem vulnerabilidades na validação, isso é um risco sistêmico. --- Resumindo, é como colocar a culpa do "imutável" em outro lugar, ainda é difícil dizer se o limite de controle de risco realmente foi reduzido. --- Parece que estão usando mecanismos mais complexos para compensar as falhas de outros, no final, o risco fica ainda mais escondido. --- A experiência de desenvolvimento ficou melhor, mas o mais importante é se o preço de liquidação será preciso ou não. --- Inacreditável, mais uma "solução inovadora", no final das contas, é só mais uma peça no dominó. --- Então, como será a mudança na taxa de empréstimo? Essa é a verdadeira questão.

Ver originalResponder0

AirdropHunter007

· 01-07 19:27

Ah, isto é que é uma ideia, a separação de identidade e estado é uma técnica que eu gosto... finalmente alguém preencheu o buraco do controlo de versões

Ver originalResponder0