Eu esperava uma transação. Contabilizei três.
Isso é um saque de ponte do DuskEVM, direto do próprio guia do Dusk:
1. Iniciar o saque no DuskEVM
2. Comprovar no Dusk L1
3. Finalizar no Dusk L1
Três ações on-chain, e taxas dos dois lados: a transação de origem, depois mais duas no L1.
O detalhe que eu mais respeito é o que fala sobre timing. A documentação diz que a prontidão do saque depende do estado de rede publicado, da maturidade da prova e das checagens do dispute-game, e que o campo de status da carteira é autoritativo — não deduza prontidão a partir de tempo decorrido. Essa frase existe porque as janelas de saque de rollup não são relógios; são máquinas de estado. Toda integração que fixou "aguarde N minutos e então finalize" eventualmente quebra: uma proposta cai tarde, uma checagem roda por mais tempo e seu finalizador envia para um estado que não está pronto.
O segundo detalhe diz mais do que a contagem de passos. O guia manda manter DUSK suficiente sem ser protegido (unshielded) no L1 para pagar tanto a prova quanto a transação de finalização. Leve isso em consideração em uma cadeia cujo argumento central é transferências confidenciais: a rota de saída da própria camada EVM é denominada em saldo transparente. Atenção, e isso importa — este é o guia de testnet; o DuskEVM ainda está rotulado como Testnet, então o formato do mainnet pode mudar.
Para ser justo, nada disso é uma invenção do Dusk. É um design padrão de optimistic rollup herdado do OP Stack, e toda cadeia OP exige exatamente as três ações de você. Então a pergunta não é se o Dusk fez algo errado. É o que o UX padrão de rollup faz com uma cadeia cuja diferenciação inteira é privacidade.
Cadeias que priorizam privacidade precisam de um design de ponte fundamentalmente diferente? Ou o gas transparente na camada de settlement é um preço justo a pagar por uma stack de desenvolvimento familiar?
#dusk $DUSK @Dusk
Isso é um saque de ponte do DuskEVM, direto do próprio guia do Dusk:
1. Iniciar o saque no DuskEVM
2. Comprovar no Dusk L1
3. Finalizar no Dusk L1
Três ações on-chain, e taxas dos dois lados: a transação de origem, depois mais duas no L1.
O detalhe que eu mais respeito é o que fala sobre timing. A documentação diz que a prontidão do saque depende do estado de rede publicado, da maturidade da prova e das checagens do dispute-game, e que o campo de status da carteira é autoritativo — não deduza prontidão a partir de tempo decorrido. Essa frase existe porque as janelas de saque de rollup não são relógios; são máquinas de estado. Toda integração que fixou "aguarde N minutos e então finalize" eventualmente quebra: uma proposta cai tarde, uma checagem roda por mais tempo e seu finalizador envia para um estado que não está pronto.
O segundo detalhe diz mais do que a contagem de passos. O guia manda manter DUSK suficiente sem ser protegido (unshielded) no L1 para pagar tanto a prova quanto a transação de finalização. Leve isso em consideração em uma cadeia cujo argumento central é transferências confidenciais: a rota de saída da própria camada EVM é denominada em saldo transparente. Atenção, e isso importa — este é o guia de testnet; o DuskEVM ainda está rotulado como Testnet, então o formato do mainnet pode mudar.
Para ser justo, nada disso é uma invenção do Dusk. É um design padrão de optimistic rollup herdado do OP Stack, e toda cadeia OP exige exatamente as três ações de você. Então a pergunta não é se o Dusk fez algo errado. É o que o UX padrão de rollup faz com uma cadeia cuja diferenciação inteira é privacidade.
Cadeias que priorizam privacidade precisam de um design de ponte fundamentalmente diferente? Ou o gas transparente na camada de settlement é um preço justo a pagar por uma stack de desenvolvimento familiar?
#dusk $DUSK @Dusk
