#dusk $DUSK @Dusk estou sentado com a tarefa no movimento da OP Stack do Dusk há um tempo, com um lanche na mão, e tem uma coisa que fica me incomodando.
O DuskEVM roda na OP Stack agora, voltando a ser DuskDS em vez de ficar ali com a clássica janela de desafio otimista de 7 dias que todo mundo já está acostumado. O Dusk enquadra isso como uma finalidade determinística, sem esperar uma semana, sem “purgação” de prova de fraude. Parece limpo no papel.
Aí, acontece 16 de agosto de 2026.
A própria equipe do Dusk flagra atividade suspeita em uma carteira gerenciada pela equipe ligada a operações de bridge. Resposta? Não é alguma prova de fraude on-chain que entra automaticamente. A equipe desativou e reciclou os endereços de bridge afetados, pausou os serviços de bridge manualmente e implementou uma blocklist de Web Wallet para destinatários sinalizados.
Isso... é uma equipe humana puxando alavancas, e não a camada de liquidação fazendo algo de forma trustless.
Hmm. Não estou desacreditando a correção — foi rápida, razoável, exatamente o que você esperaria. Mas é um lembrete de que uma janela sem falhas é uma afirmação sobre a matemática de finalidade da camada de execução, e não sobre quem realmente intervém quando algo dá errado no upstream.
A rede de segurança que importou naquele dia foi uma equipe com acesso de admin, não a arquitetura da OP Stack.
Fez eu pausar no meio da tarefa. Na verdade, eu nem cheguei a anotar que “não há janela de 7 dias é trustless”, e então risquei.
Onde é que a liquidação determinística realmente reduz a dependência de uma equipe responsiva — em vez de apenas mover a confiança para algum lugar menos visível?
O DuskEVM roda na OP Stack agora, voltando a ser DuskDS em vez de ficar ali com a clássica janela de desafio otimista de 7 dias que todo mundo já está acostumado. O Dusk enquadra isso como uma finalidade determinística, sem esperar uma semana, sem “purgação” de prova de fraude. Parece limpo no papel.
Aí, acontece 16 de agosto de 2026.
A própria equipe do Dusk flagra atividade suspeita em uma carteira gerenciada pela equipe ligada a operações de bridge. Resposta? Não é alguma prova de fraude on-chain que entra automaticamente. A equipe desativou e reciclou os endereços de bridge afetados, pausou os serviços de bridge manualmente e implementou uma blocklist de Web Wallet para destinatários sinalizados.
Isso... é uma equipe humana puxando alavancas, e não a camada de liquidação fazendo algo de forma trustless.
Hmm. Não estou desacreditando a correção — foi rápida, razoável, exatamente o que você esperaria. Mas é um lembrete de que uma janela sem falhas é uma afirmação sobre a matemática de finalidade da camada de execução, e não sobre quem realmente intervém quando algo dá errado no upstream.
A rede de segurança que importou naquele dia foi uma equipe com acesso de admin, não a arquitetura da OP Stack.
Fez eu pausar no meio da tarefa. Na verdade, eu nem cheguei a anotar que “não há janela de 7 dias é trustless”, e então risquei.
Onde é que a liquidação determinística realmente reduz a dependência de uma equipe responsiva — em vez de apenas mover a confiança para algum lugar menos visível?
