O primeiro aviso veio de uma linha sob um diagrama de ciclo de vida, fácil de ignorar.
Um explicador da comunidade sobre o DuskEVM afirmou de forma direta: não há uma janela de falha de 7 dias, ~15 min para finalizar saques, e o pré-verificador MIPS elimina o atraso da prova de fraude. Número bem limpo; achei que eu planejava um saque em cima disso.
Suposição: a documentação oficial confirmaria esse número.
Não foi o que encontrei. A própria documentação da Dusk descreve o ciclo de vida do DuskEVM em quatro etapas: tx para o sequenciador, incluída em um bloco do L2, o publicador (bater/“batcher”) envia para o DuskDS e, então, compromissos de estado e provas de falha conectam esse estado ao settlement. As provas de falha ainda são nomeadas explicitamente. Não existe nada sobre 15 minutos. Em vez disso, há uma linha dizendo para não inferir finalidade pelo tempo decorrido; verifique o protocolo ou o status da carteira.
Esse é o verdadeiro problema. A inclusão é rápida; os docs dizem isso por conta própria. O settlement é separado, condicionado a algo em que ninguém colocou um relógio.
Então a etapa de prova de falha não desapareceu; só não foi documentada do jeito do sistema de desafio permissionless da Optimism, em que qualquer pessoa pode executar o prover e observar a contestação acontecer.
Não sei se isso foi comprimido e resolvido de forma privada, ou se simplesmente ainda não está público.
Fico feliz por ter checado antes de agendar um saque usando o número de outra pessoa.
O que acontece com aquele número de 15 minutos na primeira vez que uma prova de falha precisa ser contestada durante uma corrida de settlement no meio do processo? 👍
#dusk $DUSK @Dusk
Um explicador da comunidade sobre o DuskEVM afirmou de forma direta: não há uma janela de falha de 7 dias, ~15 min para finalizar saques, e o pré-verificador MIPS elimina o atraso da prova de fraude. Número bem limpo; achei que eu planejava um saque em cima disso.
Suposição: a documentação oficial confirmaria esse número.
Não foi o que encontrei. A própria documentação da Dusk descreve o ciclo de vida do DuskEVM em quatro etapas: tx para o sequenciador, incluída em um bloco do L2, o publicador (bater/“batcher”) envia para o DuskDS e, então, compromissos de estado e provas de falha conectam esse estado ao settlement. As provas de falha ainda são nomeadas explicitamente. Não existe nada sobre 15 minutos. Em vez disso, há uma linha dizendo para não inferir finalidade pelo tempo decorrido; verifique o protocolo ou o status da carteira.
Esse é o verdadeiro problema. A inclusão é rápida; os docs dizem isso por conta própria. O settlement é separado, condicionado a algo em que ninguém colocou um relógio.
Então a etapa de prova de falha não desapareceu; só não foi documentada do jeito do sistema de desafio permissionless da Optimism, em que qualquer pessoa pode executar o prover e observar a contestação acontecer.
Não sei se isso foi comprimido e resolvido de forma privada, ou se simplesmente ainda não está público.
Fico feliz por ter checado antes de agendar um saque usando o número de outra pessoa.
O que acontece com aquele número de 15 minutos na primeira vez que uma prova de falha precisa ser contestada durante uma corrida de settlement no meio do processo? 👍
#dusk $DUSK @Dusk