#dusk $DUSK
Eu voltei e reli a documentação @Dusk esta noite. Percebi que estava tratando “finalizado” como um único momento. Eu presumi que, uma vez que uma transação do Dusk estivesse final, os fundos deveriam existir imediatamente no DuskEVM. A documentação também simplificou essa suposição demais.
No DuskEVM Testnet, um depósito é enviado e finalizado na Dusk L1 e, depois disso, é processado antes que o saldo fique disponível no DuskEVM. Um saque tem mais etapas: inicia no DuskEVM, aguarda uma saída, prova na Dusk L1, passa nas verificações de maturidade e de dispute-game necessárias e, por fim, finaliza na L1. A documentação alerta que inclusão, execução e finalidade não são o mesmo status, e que a prontidão deve vir do estado do protocolo e não do tempo decorrido.
Isso me fez olhar para tudo de forma diferente.
Minha interpretação: a ponte não é um “atraso oculto”; ela tenta transformar uma máquina de estados entre camadas em algo que uma carteira consiga explicar. A tensão é segurança versus dependência operacional. Retentativas mais seguras, recuperação por rollback e verificações de desafio reduzem uma classe de falhas, mas os caminhos de recuperação também concentram responsabilidades em algum lugar.
Minha incerteza: durante um rollback junto com a falha do relayer, o que um usuário consegue verificar de forma independente antes que os fundos sejam liberados ou retentados? Quem pode pausar ou retomar as operações da ponte, e quais são os limites dessa autoridade se a emergência durar mais do que o esperado?
Quero observar isso na prática.
Eu voltei e reli a documentação @Dusk esta noite. Percebi que estava tratando “finalizado” como um único momento. Eu presumi que, uma vez que uma transação do Dusk estivesse final, os fundos deveriam existir imediatamente no DuskEVM. A documentação também simplificou essa suposição demais.
No DuskEVM Testnet, um depósito é enviado e finalizado na Dusk L1 e, depois disso, é processado antes que o saldo fique disponível no DuskEVM. Um saque tem mais etapas: inicia no DuskEVM, aguarda uma saída, prova na Dusk L1, passa nas verificações de maturidade e de dispute-game necessárias e, por fim, finaliza na L1. A documentação alerta que inclusão, execução e finalidade não são o mesmo status, e que a prontidão deve vir do estado do protocolo e não do tempo decorrido.
Isso me fez olhar para tudo de forma diferente.
Minha interpretação: a ponte não é um “atraso oculto”; ela tenta transformar uma máquina de estados entre camadas em algo que uma carteira consiga explicar. A tensão é segurança versus dependência operacional. Retentativas mais seguras, recuperação por rollback e verificações de desafio reduzem uma classe de falhas, mas os caminhos de recuperação também concentram responsabilidades em algum lugar.
Minha incerteza: durante um rollback junto com a falha do relayer, o que um usuário consegue verificar de forma independente antes que os fundos sejam liberados ou retentados? Quem pode pausar ou retomar as operações da ponte, e quais são os limites dessa autoridade se a emergência durar mais do que o esperado?
Quero observar isso na prática.
