16 de agosto, a equipe Dusk detectou novamente uma atividade anômala relacionada a carteiras de ponte. Suspendeu emergencialmente o serviço de ponte, recuperou os endereços relacionados e adicionou bloqueio em lista negra à carteira web para interceptar. A confirmação oficial posterior foi que não houve prejuízo para os fundos dos usuários. Ao terminar de ler, minha primeira reação não foi “mais uma vez escapamos ilesos”; foi “já é a segunda vez em meio ano”.
Naquela de janeiro, eu me lembro bem: também era uma carteira de assinatura do tipo usada pela equipe na camada operacional que deu problema. A própria mainchain não tinha nada; a questão estava naquele “trabalho gerenciado por pessoas” ao redor do funcionamento do protocolo. Desta vez, em agosto, os detalhes foram quase moldados no mesmo molde — o sistema de monitoramento detectou a anomalia, o serviço foi pausado, as exchanges coordenaram o bloqueio dos fluxos suspeitos de fundos e, depois, a lista negra foi adicionada. Em ambos os incidentes, os procedimentos de resposta foram profissionais e a velocidade de reação não foi baixa, mas o que mais me preocupa é outra coisa: repetir esse mesmo tipo de problema duas vezes em meio ano indica que o “reforço” após o primeiro incidente talvez tenha sido apenas um remendo, sem resolver a raiz.
Nesses anos em que estou nesse setor, vi equipes colocarem o foco de segurança em “quanto foi a perda desta vez” e “quão rápido conseguimos estancar o sangramento”, mas muito poucas pessoas querem responder uma pergunta ainda mais constrangedora: por que uma vulnerabilidade de natureza semelhante reaparece pela segunda vez dentro do mesmo sistema operacional? Dizer “a camada do protocolo não tem problemas” uma vez ainda pode convencer; dizer duas vezes já deveria levantar dúvidas. Não é dúvida sobre a capacidade técnica da Dusk, e sim sobre toda a disciplina operacional que envolve a gestão de chaves, aprovação por multisig e resposta de monitoramento para o funcionamento do serviço de ponte.
Não houve perda de fundos desta vez — foi sorte ou o processo realmente foi corrigido? Ainda não dá para saber. Mas, para uma cadeia que tenta atrair capital institucional, o que o departamento de conformidade dessas instituições olha nunca é “se aconteceu um incidente”, e sim “quantas vezes o mesmo buraco foi pisado”. Vou manter esse registro para sempre.
Você acha que dois reaparecimentos desse tipo de evento de segurança em meio ano devem ser considerados apenas uma oscilação normal de “operações em reforço contínuo”, ou isso serve como um alerta para agir com mais seriedade?
@Dusk $DUSK #dusk
Naquela de janeiro, eu me lembro bem: também era uma carteira de assinatura do tipo usada pela equipe na camada operacional que deu problema. A própria mainchain não tinha nada; a questão estava naquele “trabalho gerenciado por pessoas” ao redor do funcionamento do protocolo. Desta vez, em agosto, os detalhes foram quase moldados no mesmo molde — o sistema de monitoramento detectou a anomalia, o serviço foi pausado, as exchanges coordenaram o bloqueio dos fluxos suspeitos de fundos e, depois, a lista negra foi adicionada. Em ambos os incidentes, os procedimentos de resposta foram profissionais e a velocidade de reação não foi baixa, mas o que mais me preocupa é outra coisa: repetir esse mesmo tipo de problema duas vezes em meio ano indica que o “reforço” após o primeiro incidente talvez tenha sido apenas um remendo, sem resolver a raiz.
Nesses anos em que estou nesse setor, vi equipes colocarem o foco de segurança em “quanto foi a perda desta vez” e “quão rápido conseguimos estancar o sangramento”, mas muito poucas pessoas querem responder uma pergunta ainda mais constrangedora: por que uma vulnerabilidade de natureza semelhante reaparece pela segunda vez dentro do mesmo sistema operacional? Dizer “a camada do protocolo não tem problemas” uma vez ainda pode convencer; dizer duas vezes já deveria levantar dúvidas. Não é dúvida sobre a capacidade técnica da Dusk, e sim sobre toda a disciplina operacional que envolve a gestão de chaves, aprovação por multisig e resposta de monitoramento para o funcionamento do serviço de ponte.
Não houve perda de fundos desta vez — foi sorte ou o processo realmente foi corrigido? Ainda não dá para saber. Mas, para uma cadeia que tenta atrair capital institucional, o que o departamento de conformidade dessas instituições olha nunca é “se aconteceu um incidente”, e sim “quantas vezes o mesmo buraco foi pisado”. Vou manter esse registro para sempre.
Você acha que dois reaparecimentos desse tipo de evento de segurança em meio ano devem ser considerados apenas uma oscilação normal de “operações em reforço contínuo”, ou isso serve como um alerta para agir com mais seriedade?
@Dusk $DUSK #dusk
A. 该敲警钟,复现本身就是信号
50%
B. 算正常,只要没损失就不算大问题
50%
C. 得看具体加固措施有没有真落地,不能只看有没有复现
0%
4 Votos • Votação encerrada