#dusk $DUSK @Dusk
Eu me aprofundei num “buraco de coelho” de Khovratovich enquanto pesquisava o Dusk Argon2 Equihash PLONK e a criptografia que sustenta tudo por trás da rede. Tudo isso é interessante.
Mas então eu olhei para o que aconteceu de fato recentemente, e o detalhe mais importante não foi a matemática.
Em 16 de agosto, a Dusk pausou os serviços de bridge após monitorar uma atividade que não correspondia ao comportamento normal das pontes. O que chamou a atenção é que o próprio DuskDS continuou produzindo blocos, então o incidente foi tratado nas operações do bridge, em vez de se transformar numa paralisação em nível de protocolo.
Depois veio a parte sobre a qual eu continuei pensando.
A mitigação não foi outro sistema de provas nem uma mudança de consenso. A Web Wallet adicionou uma lista de destinatários bloqueados que avisa os usuários antes de enviar fundos para um endereço sinalizado.
Isso é um tipo de segurança bem diferente.
Ela protege o usuário padrão exatamente no ponto em que uma transação arriscada está prestes a acontecer. E, como resposta prática, faz sentido: um aviso de carteira pode chegar rapidamente aos usuários, sem precisar esperar por uma mudança de protocolo mais profunda.
Mas existe um trade-off.
Alguém usando ferramentas personalizadas pela CLI ou outra interface talvez não receba o mesmo aviso. A proteção depende de onde essa pessoa interage com a Dusk.
Isso me fez enxergar o modelo de segurança da Dusk de forma diferente. Uma criptografia forte pode proteger o sistema subjacente, mas o risco operacional ainda pode aparecer nas bordas.
Para uma rede voltada a mercados financeiros regulados, a pergunta que eu observaria é simples
Mais controles de segurança vão acabar chegando mais perto do protocolo, ou a proteção no nível de aplicação continuará sendo a camada preferida?
Eu me aprofundei num “buraco de coelho” de Khovratovich enquanto pesquisava o Dusk Argon2 Equihash PLONK e a criptografia que sustenta tudo por trás da rede. Tudo isso é interessante.
Mas então eu olhei para o que aconteceu de fato recentemente, e o detalhe mais importante não foi a matemática.
Em 16 de agosto, a Dusk pausou os serviços de bridge após monitorar uma atividade que não correspondia ao comportamento normal das pontes. O que chamou a atenção é que o próprio DuskDS continuou produzindo blocos, então o incidente foi tratado nas operações do bridge, em vez de se transformar numa paralisação em nível de protocolo.
Depois veio a parte sobre a qual eu continuei pensando.
A mitigação não foi outro sistema de provas nem uma mudança de consenso. A Web Wallet adicionou uma lista de destinatários bloqueados que avisa os usuários antes de enviar fundos para um endereço sinalizado.
Isso é um tipo de segurança bem diferente.
Ela protege o usuário padrão exatamente no ponto em que uma transação arriscada está prestes a acontecer. E, como resposta prática, faz sentido: um aviso de carteira pode chegar rapidamente aos usuários, sem precisar esperar por uma mudança de protocolo mais profunda.
Mas existe um trade-off.
Alguém usando ferramentas personalizadas pela CLI ou outra interface talvez não receba o mesmo aviso. A proteção depende de onde essa pessoa interage com a Dusk.
Isso me fez enxergar o modelo de segurança da Dusk de forma diferente. Uma criptografia forte pode proteger o sistema subjacente, mas o risco operacional ainda pode aparecer nas bordas.
Para uma rede voltada a mercados financeiros regulados, a pergunta que eu observaria é simples
Mais controles de segurança vão acabar chegando mais perto do protocolo, ou a proteção no nível de aplicação continuará sendo a camada preferida?
