Como solução de armazenamento na ecossistema Sui, o acoplamento técnico estreito do Walrus significa que a sua estabilidade depende não só da rede de nós distribuídos, mas também do estado de funcionamento da rede principal Sui.
Precisamos considerar seriamente uma situação extrema: e se a rede Sui parar de produzir blocos devido a uma vulnerabilidade no mecanismo de consenso ou a um ataque DDoS em grande escala?
Durante o período em que a rede principal Sui estiver parada, embora os nós de armazenamento do Walrus continuem a funcionar e os dados no disco estejam íntegros, o centro de controlo do sistema perderá a capacidade de resposta. Não será possível solicitar novas quotas de armazenamento, ajustar as políticas de acesso ou até mesmo verificar a propriedade e o acesso aos dados através de contratos na cadeia Sui. O resultado é que os dados entram num estado de "zombie" — existem fisicamente, mas do ponto de vista lógico, tornam-se inacessíveis ou incontroláveis.
Especialmente problemáticos são os cenários que dependem de validações instantâneas na cadeia. Por exemplo, aplicações que exigem "posse de um NFT específico para decifrar o arquivo de armazenamento". Se a rede Sui cair, todo o mecanismo de autenticação entrará em colapso, mesmo os usuários com permissões legítimas não conseguirão acessar os dados.
Com base nesta compreensão, ao projetar negócios que exigem alta disponibilidade, não assumo que a L1 estará sempre estável e online. Em vez disso, implemento uma "solução de fallback" — cacheando metadados essenciais e instantâneos de permissões na aplicação. Quando a rede Sui apresentar falhas, a aplicação pode temporariamente mudar para um modo de validação local, solicitando dados aos nós do Walrus usando credenciais em cache — desde que os nós do Walrus ofereçam alguma capacidade de validação offline, ou que a camada de aplicação tenha métodos de decifração de reserva.
Resumindo, sem um plano de contingência que permita "manter a operação básica mesmo fora da cadeia principal", todos os esquemas de armazenamento que se autodenominam descentralizados serão vulneráveis diante de falhas na cadeia principal.
Aviso legal: Os pontos acima representam opiniões de pesquisa pessoal, destinados apenas a discussões técnicas, e não constituem qualquer conselho de investimento.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
22 gostos
Recompensa
22
10
Republicar
Partilhar
Comentar
0/400
GateUser-5854de8b
· 8h atrás
Para ser honesto, a arquitetura Walrus depende demasiado do Sui; se a cadeia principal falhar, tudo fica inútil.
Ver originalResponder0
Ser_Liquidated
· 01-12 12:03
Os dados ainda estão no disco, mas a cadeia está quebrada... Não é exatamente uma memória de Schrödinger, haha
---
Portanto, no final das contas, é preciso criar um plano de backup por conta própria, não se pode apenas confiar que o L1 não vai falhar
---
A arquitetura do Walrus tem um risco um pouco elevado, acho que é preciso adicionar um mecanismo de validação offline para ser mais confiável
---
Mais um caso de "descentralização" sendo controlada pela cadeia principal, nem a complexidade de uma matriosca chega a esse ponto
---
A ideia de armazenar metadados em cache é boa, mas atualmente há algum projeto que realmente esteja fazendo isso?
Ver originalResponder0
EyeOfTheTokenStorm
· 01-12 07:53
Isto é a verdade, quando o L1 fica fora do ar, ninguém consegue te salvar.
---
A metáfora do estado "zumbi" dos dados é demasiado dura, mas a realidade é tão cruel.
---
Por isso, o mais importante é ter um plano de fallback offline, caso contrário, descentralização é apenas uma piada.
---
O risco do Walrus não está na tecnologia em si, mas na ligação ao Sui. Este é um problema sistêmico.
---
Do ponto de vista da quantificação, esse acoplamento forte na verdade aumenta bastante o peso do risco de falha geral.
---
A estratégia de cache de permissões e snapshots realmente tem potencial, mas depende se os nós do Walrus vão colaborar.
---
Mais uma vulnerabilidade de centralização disfarçada de descentralização?
---
Quando o sistema fica fora do ar, o mecanismo de autenticação fica completamente inoperante, mesmo com permissões válidas, não é possível acessar o banco de dados, o que é constrangedor.
Ver originalResponder0
GasBandit
· 01-11 06:20
Mais uma vez a mesma questão, o problema na L1 faz o Walrus ficar inoperante? Já devia ter pensado nisso antes
Ver originalResponder0
SybilSlayer
· 01-10 16:51
Mais uma vez surge uma contradição de "descentralização mas sem poder sair da cadeia principal", risível
---
Realmente é pegar no nome de distribuído para fazer coisas centralizadas, Sui uma vez e todo o Walrus acaba por seguir o mesmo caminho
---
Por isso, por mais bonito que seja, no momento crucial ainda temos que confiar em cache e validação local para garantir a segurança, então talvez seja melhor simplesmente fazer upload para o IPFS
---
É isso que eu sempre quis perguntar, os nós de armazenamento estão vivos, os dados estão vivos, mas a validação de permissões morreu, isso é realmente distribuído ou pseudo-distribuído?
---
Capacidade de validação offline... aliás, quantos projetos realmente pensaram nesta camada? A maioria ainda está só a gritar slogans de descentralização
---
Dá para perceber que o autor realmente pensou nesta questão, a ideia de um plano de fallback e downgrade não é má, mas na prática, quem quer gastar mais custos para fazer esse sistema?
Ver originalResponder0
MetadataExplorer
· 01-10 16:50
Isto é o típico dilema de "parece descentralizado, mas na verdade não é", o Sui se ficar fora do ar os dados ficam congelados
Parece que estão a aconselhar-nos a fazer backups por conta própria, não podemos depender demasiado da validação na cadeia
Sinto que este problema é mais grave do que imaginávamos, muitos projetos podem nem ter considerado este cenário
Uma verdadeira solução de armazenamento descentralizado deve ter capacidade de tolerância a falhas offline, senão é só um sonho
A estratégia de cache de credenciais parece mais uma solução paliativa do que uma solução definitiva
Ver originalResponder0
GasWhisperer
· 01-10 16:49
não, a coisa do estado zumbi é diferente... os dados existem, mas não podem tocá-los lmao
Ver originalResponder0
SwapWhisperer
· 01-10 16:40
Os dados ainda estão armazenados no disco rígido, mas se a cadeia estiver inativa, não pode ser usada. Essa é a verdadeira paradoxo da descentralização.
Ver originalResponder0
EthMaximalist
· 01-10 16:30
Mais uma vez, o mesmo problema antigo... Se o L1 falha, o Walrus fica inútil. Para ser sincero, é uma questão da cadeia, não é? Qualquer camada de armazenamento tem que colocar a culpa na cadeia principal.
Ver originalResponder0
SchrödingersNode
· 01-10 16:28
Mais uma vez, essa armadilha de acoplamento, uma queda do L1 e todo o ecossistema vai por água abaixo
É por isso que eu nunca acreditei nessa história de "descentralização total", no final das contas, acaba sendo controlado pela cadeia principal
Ter um plano de backup offline é o caminho certo, do contrário, armazenar dados de nada adianta
Como solução de armazenamento na ecossistema Sui, o acoplamento técnico estreito do Walrus significa que a sua estabilidade depende não só da rede de nós distribuídos, mas também do estado de funcionamento da rede principal Sui.
Precisamos considerar seriamente uma situação extrema: e se a rede Sui parar de produzir blocos devido a uma vulnerabilidade no mecanismo de consenso ou a um ataque DDoS em grande escala?
Durante o período em que a rede principal Sui estiver parada, embora os nós de armazenamento do Walrus continuem a funcionar e os dados no disco estejam íntegros, o centro de controlo do sistema perderá a capacidade de resposta. Não será possível solicitar novas quotas de armazenamento, ajustar as políticas de acesso ou até mesmo verificar a propriedade e o acesso aos dados através de contratos na cadeia Sui. O resultado é que os dados entram num estado de "zombie" — existem fisicamente, mas do ponto de vista lógico, tornam-se inacessíveis ou incontroláveis.
Especialmente problemáticos são os cenários que dependem de validações instantâneas na cadeia. Por exemplo, aplicações que exigem "posse de um NFT específico para decifrar o arquivo de armazenamento". Se a rede Sui cair, todo o mecanismo de autenticação entrará em colapso, mesmo os usuários com permissões legítimas não conseguirão acessar os dados.
Com base nesta compreensão, ao projetar negócios que exigem alta disponibilidade, não assumo que a L1 estará sempre estável e online. Em vez disso, implemento uma "solução de fallback" — cacheando metadados essenciais e instantâneos de permissões na aplicação. Quando a rede Sui apresentar falhas, a aplicação pode temporariamente mudar para um modo de validação local, solicitando dados aos nós do Walrus usando credenciais em cache — desde que os nós do Walrus ofereçam alguma capacidade de validação offline, ou que a camada de aplicação tenha métodos de decifração de reserva.
Resumindo, sem um plano de contingência que permita "manter a operação básica mesmo fora da cadeia principal", todos os esquemas de armazenamento que se autodenominam descentralizados serão vulneráveis diante de falhas na cadeia principal.
Aviso legal: Os pontos acima representam opiniões de pesquisa pessoal, destinados apenas a discussões técnicas, e não constituem qualquer conselho de investimento.