Usou o Walrus durante vários meses e recentemente tem uma preocupação que não sai da cabeça — a segurança e a proteção de privacidade deste sistema são realmente confiáveis? A documentação oficial enfatiza repetidamente características técnicas como descentralização, armazenamento verificável e tolerância a falhas bizantinas, o que soa muito impressionante, mas na prática, ao usar o sistema, percebi que há algumas vulnerabilidades evidentes no design relacionadas à proteção de privacidade e à resiliência do sistema. Pode não parecer um problema a curto prazo, mas a longo prazo, esses são riscos embutidos que precisam ser discutidos cuidadosamente.
Primeiro, falando sobre a proteção de privacidade. O comportamento padrão do Walrus é que todos os blobs carregados sejam completamente públicos; qualquer pessoa que obtenha o ID do blob pode ler os dados imediatamente. Do ponto de vista técnico, isso não está errado — a codificação Red Stuff em si não inclui mecanismos de criptografia, ela é responsável por redundância e recuperação de dados, não por criptografar. Mas, para o usuário, as consequências podem ser graves: informações sensíveis não podem ser simplesmente enviadas assim, é necessário criptografar localmente antes de fazer o upload do ciphertext. Parece razoável, mas o problema é que todo esse processo de criptografia é inteiramente responsabilidade do usuário, e o protocolo em si não possui suporte embutido para isso.
Mais tarde, a equipe lançou o Seal para preencher essa lacuna. O Seal pode fazer gerenciamento de chaves na cadeia e controle de acesso, permitindo que você controle precisamente quem pode decifrar quais dados. A solução técnica em si é bastante completa, mas essa ferramenta é um produto de terceiros independente, não faz parte do protocolo Walrus. Para usar o Seal, você precisa integrar SDKs adicionais, gerenciar o ciclo de vida das chaves e lidar com a lógica de criptografia e descriptografia. Para desenvolvedores que não têm muita familiaridade com criptografia, o custo de aprendizado e integração não é baixo, e um pequeno erro pode facilmente levar a falhas de segurança.
Ver original
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.
14 gostos
Recompensa
14
8
Republicar
Partilhar
Comentar
0/400
MissingSats
· 8h atrás
A conceção de privacidade padrão totalmente pública é realmente absurda, parece que simplesmente deixa a questão da privacidade para o utilizador resolver...
O sistema Seal é realmente irritante de usar, o custo de integração é demasiado alto, os desenvolvedores comuns simplesmente não conseguem suportar.
A falta de suporte de encriptação incorporada na camada de protocolo é realmente preocupante, usar isto a longo prazo apresenta riscos consideráveis.
Parece que a equipa oficial lança primeiro um produto incompleto e depois depende de terceiros para preencher as lacunas, esta abordagem tem alguns problemas.
Mas, voltando ao assunto, projetos que têm coragem de expor e discutir estas falhas de design são melhores do que aqueles que escondem os problemas...
Ver originalResponder0
DataChief
· 01-11 11:40
Que mentira confiável, na verdade é só passar a questão da privacidade para o usuário, se o desenvolvedor não cuidar, os dados ficam expostos.
Ver originalResponder0
SolidityStruggler
· 01-10 12:59
Para ser honesto, o modelo de privacidade Walrus realmente deixa a desejar, quem foi que projetou essa história de tornar público por padrão?
Tem que contar com o Seal para salvar a situação, mas o Seal é uma ferramenta externa, isso não é criar um buraco e depois preenchê-lo, os desenvolvedores estão exaustos.
Ver originalResponder0
GweiWatcher
· 01-10 12:57
Resumindo, é basicamente passar a questão da privacidade para o usuário, deveria ter sido considerado na concepção do protocolo.
Ver originalResponder0
NeverPresent
· 01-10 12:57
A configuração padrão de visibilidade total é realmente arriscada. É preciso criptografar por conta própria, mas o Seal é uma ferramenta independente, o que torna a integração muito difícil; os desenvolvedores podem facilmente cometer erros se não forem cuidadosos.
Ver originalResponder0
HashBard
· 01-10 12:51
então o walrus deixou escapar as configurações padrão de privacidade e agora todos nós devemos ser criptógrafos amadores? a energia de "aplique você mesmo a criptografia" está dando vibes de remendo, para ser honesto... então o seal aparece como um salvador, exceto que está preso por fora, rs. parece que estamos assistindo alguém construir uma casa sem portas e depois vender uma porta separadamente
Ver originalResponder0
AirdropSweaterFan
· 01-10 12:41
Caramba, concordo totalmente, o design padrão de acesso aberto do Walrus realmente é bastante frustrante.
O ID do blob pode ser lido só de copiar? Parece que não há criptografia, é preciso que o usuário se preocupe em fazer criptografia local para ficar tranquilo, isso não é mais do que passar a responsabilidade para nós.
Depois de lançar o Seal, fica um pouco melhor, mas ainda assim temos que lidar com SDKs e gerenciar chaves... nem todo desenvolvedor consegue dominar esse sistema.
A longo prazo, realmente há riscos, no momento não sentimos nada, mas quando acontecer algo, será tarde demais. Acho que deveria haver uma solução padrão unificada para isso.
Ver originalResponder0
GovernancePretender
· 01-10 12:32
Resumindo, o design de privacidade do Walrus é basicamente passar a responsabilidade para os usuários, o protocolo não se preocupa com nada
A solução de reparo do Seal é realmente um pouco absurda, os desenvolvedores ainda precisam lidar com criptografia por conta própria, se não tomarem cuidado podem acabar se dando mal
A configuração padrão de ser público, felizmente eu já estava atento desde o início, senão teria caído na armadilha
A gestão do ciclo de vida da chave é uma dor de cabeça, parece que o oficial nunca pensou em como as pessoas comuns vão usar
Usou o Walrus durante vários meses e recentemente tem uma preocupação que não sai da cabeça — a segurança e a proteção de privacidade deste sistema são realmente confiáveis? A documentação oficial enfatiza repetidamente características técnicas como descentralização, armazenamento verificável e tolerância a falhas bizantinas, o que soa muito impressionante, mas na prática, ao usar o sistema, percebi que há algumas vulnerabilidades evidentes no design relacionadas à proteção de privacidade e à resiliência do sistema. Pode não parecer um problema a curto prazo, mas a longo prazo, esses são riscos embutidos que precisam ser discutidos cuidadosamente.
Primeiro, falando sobre a proteção de privacidade. O comportamento padrão do Walrus é que todos os blobs carregados sejam completamente públicos; qualquer pessoa que obtenha o ID do blob pode ler os dados imediatamente. Do ponto de vista técnico, isso não está errado — a codificação Red Stuff em si não inclui mecanismos de criptografia, ela é responsável por redundância e recuperação de dados, não por criptografar. Mas, para o usuário, as consequências podem ser graves: informações sensíveis não podem ser simplesmente enviadas assim, é necessário criptografar localmente antes de fazer o upload do ciphertext. Parece razoável, mas o problema é que todo esse processo de criptografia é inteiramente responsabilidade do usuário, e o protocolo em si não possui suporte embutido para isso.
Mais tarde, a equipe lançou o Seal para preencher essa lacuna. O Seal pode fazer gerenciamento de chaves na cadeia e controle de acesso, permitindo que você controle precisamente quem pode decifrar quais dados. A solução técnica em si é bastante completa, mas essa ferramenta é um produto de terceiros independente, não faz parte do protocolo Walrus. Para usar o Seal, você precisa integrar SDKs adicionais, gerenciar o ciclo de vida das chaves e lidar com a lógica de criptografia e descriptografia. Para desenvolvedores que não têm muita familiaridade com criptografia, o custo de aprendizado e integração não é baixo, e um pequeno erro pode facilmente levar a falhas de segurança.