passei esta manhã revisando como uma transação do duskevm realmente se move pelo sistema e, honestamente? 😂 eu assumi que, quando ela aparecesse em um bloco, eu já estava feito de acompanhar — acontece que não é bem assim.
então, o duskevm é a camada compatível com a evm na dusk, o que significa que você escreve em solidity, usa carteiras evm normais e ferramentas padrão como foundry ou hardhat, e paga gas em dusk durante tudo isso. mas a transação não fica só vivendo e morrendo no duskevm por conta própria. ela passa por um ciclo de vida estilo rollup. primeiro ela é submetida ao sequenciador do duskevm e depois é incluída em um bloco de l2 relativamente rápido. depois disso, um batcher publica os dados da transação para o duskds, que é o verdadeiro layer de settlement e disponibilidade de dados da dusk. as committments de estado e as fault proofs é que conectam aquele estado resultante de volta ao duskds, então de fato fica liquidado, não apenas “parado” em algum bloco de l2 esperando.
o que eu continuo voltando é uma linha nos docs que destaca inclusão e settlement como estágios genuinamente diferentes — e que apps que movimentam valor entre o duskevm e o dusk l1 deveriam checar status de protocolo ou da carteira em vez de só assumir que algo é final porque passou algum tempo. essa distinção é real, não é um detalhe técnico. eu não encontrei em lugar nenhum que explique quanto tempo, tipicamente, esse intervalo costuma ser na prática: inclusão rápida claramente não significa settlement instantâneo, mas eu não sei qual é a janela real que alguém deveria esperar.
mesmo assim, a escolha de design faz sentido pra mim. em vez de construir uma cadeia evm totalmente separada, flutuando sozinha, o duskevm fica ancorado no duskds para settlement e disponibilidade de dados — então você tem toda a praticidade das ferramentas de solidity sem perder as garantias base das camadas sobre finalidade.
honestamente não sei se essa lacuna de inclusão até settlement é pequena o suficiente pra ignorar no dia a dia ou se builders precisam considerar ativamente??
🤔
#dusk @Dusk $DUSK
então, o duskevm é a camada compatível com a evm na dusk, o que significa que você escreve em solidity, usa carteiras evm normais e ferramentas padrão como foundry ou hardhat, e paga gas em dusk durante tudo isso. mas a transação não fica só vivendo e morrendo no duskevm por conta própria. ela passa por um ciclo de vida estilo rollup. primeiro ela é submetida ao sequenciador do duskevm e depois é incluída em um bloco de l2 relativamente rápido. depois disso, um batcher publica os dados da transação para o duskds, que é o verdadeiro layer de settlement e disponibilidade de dados da dusk. as committments de estado e as fault proofs é que conectam aquele estado resultante de volta ao duskds, então de fato fica liquidado, não apenas “parado” em algum bloco de l2 esperando.
o que eu continuo voltando é uma linha nos docs que destaca inclusão e settlement como estágios genuinamente diferentes — e que apps que movimentam valor entre o duskevm e o dusk l1 deveriam checar status de protocolo ou da carteira em vez de só assumir que algo é final porque passou algum tempo. essa distinção é real, não é um detalhe técnico. eu não encontrei em lugar nenhum que explique quanto tempo, tipicamente, esse intervalo costuma ser na prática: inclusão rápida claramente não significa settlement instantâneo, mas eu não sei qual é a janela real que alguém deveria esperar.
mesmo assim, a escolha de design faz sentido pra mim. em vez de construir uma cadeia evm totalmente separada, flutuando sozinha, o duskevm fica ancorado no duskds para settlement e disponibilidade de dados — então você tem toda a praticidade das ferramentas de solidity sem perder as garantias base das camadas sobre finalidade.
honestamente não sei se essa lacuna de inclusão até settlement é pequena o suficiente pra ignorar no dia a dia ou se builders precisam considerar ativamente??
🤔
#dusk @Dusk $DUSK