Depois de ficar um tempo demais na cadeia, percebi um detalhe bem fácil de enganar as pessoas: quanto mais rápida for a confirmação de uma transação, mais fácil é a pessoa confundir “já entrou no bloco” com “o dinheiro já caiu na conta”. Eu chamo isso de “paradoxo da finalização”.
O fluxo de transações do DuskEVM deixa isso bem claro: a transação primeiro é enviada ao sequencer, entra no bloco da L2 e, em seguida, o batcher publica os dados no DuskDS. Depois, é com os compromissos de estado e as fault proofs que o resultado fica ancorado de volta na camada de liquidação. Em outras palavras, aparecer no bloco é apenas o primeiro passo; o que realmente faz a rede assumir responsabilidade por esse resultado são os passos seguintes. A sequência @Dusk é como um serviço de entrega: gerar um código de rastreio não é o mesmo que assinar o recebimento, e a encomenda dar entrada no depósito não significa que você já conferiu e abriu a caixa.
A própria documentação até alerta diretamente: não use “há quanto tempo aconteceu” para inferir finalização, especialmente quando você precisa transportar valor entre o DuskEVM e o L1.
$DUSK aqui desempenha dois papéis ao mesmo tempo: é o combustível que paga o gas na camada de execução e também é o próprio valor que fica sendo transferido de um lado para o outro. Quando os usuários veem o saldo DUSK mudar na cadeia, talvez seja apenas a camada de execução registrando a conta primeiro; a ponte e a liquidação de fato ainda não terminaram. Então, para quem faz transações e para quem organiza a consolidação de fundos, o que importa é o estado do protocolo ou o estado da carteira — não ficar olhando o cronômetro.
Acho que é exatamente aqui que essa categoria de infraestrutura de privacidade e conformidade fica realmente difícil: #dusk ela não pode apenas entregar “velocidade”; também precisa permitir que o usuário diferencie “o que está acontecendo” de “o que já está confirmado”. Se a camada do produto também borrar esse limite, o usuário acaba assumindo um risco em nível de minutos através de uma interface que parece agir em milissegundos. Faça a lição de casa; não confie só no que eu disse.
O fluxo de transações do DuskEVM deixa isso bem claro: a transação primeiro é enviada ao sequencer, entra no bloco da L2 e, em seguida, o batcher publica os dados no DuskDS. Depois, é com os compromissos de estado e as fault proofs que o resultado fica ancorado de volta na camada de liquidação. Em outras palavras, aparecer no bloco é apenas o primeiro passo; o que realmente faz a rede assumir responsabilidade por esse resultado são os passos seguintes. A sequência @Dusk é como um serviço de entrega: gerar um código de rastreio não é o mesmo que assinar o recebimento, e a encomenda dar entrada no depósito não significa que você já conferiu e abriu a caixa.
A própria documentação até alerta diretamente: não use “há quanto tempo aconteceu” para inferir finalização, especialmente quando você precisa transportar valor entre o DuskEVM e o L1.
$DUSK aqui desempenha dois papéis ao mesmo tempo: é o combustível que paga o gas na camada de execução e também é o próprio valor que fica sendo transferido de um lado para o outro. Quando os usuários veem o saldo DUSK mudar na cadeia, talvez seja apenas a camada de execução registrando a conta primeiro; a ponte e a liquidação de fato ainda não terminaram. Então, para quem faz transações e para quem organiza a consolidação de fundos, o que importa é o estado do protocolo ou o estado da carteira — não ficar olhando o cronômetro.
Acho que é exatamente aqui que essa categoria de infraestrutura de privacidade e conformidade fica realmente difícil: #dusk ela não pode apenas entregar “velocidade”; também precisa permitir que o usuário diferencie “o que está acontecendo” de “o que já está confirmado”. Se a camada do produto também borrar esse limite, o usuário acaba assumindo um risco em nível de minutos através de uma interface que parece agir em milissegundos. Faça a lição de casa; não confie só no que eu disse.
