O dusk tem dois ambientes de contrato, mas a parte interessante não é que existam dois.

duskvm roda diretamente na L1; a execução do contrato e o settlement do dusk acontecem no mesmo lugar. O duskevm

parece separado à primeira vista: Solidity, carteiras EVM, seu próprio RPC. mas uma transação do duskevm na verdade passa por quatro etapas antes de realmente estar liquidada. ela vai primeiro para o sequenciador, é incluída em um bloco da L2, então.

o batcher publica esses dados de transação no duskds e, só então, os compromissos de estado e as provas de falha conectam o estado resultante de volta ao settlement do duskds.
É fácil perder que inclusão e settlement são.

explicitamente duas etapas diferentes aqui, não uma. uma transação pode aparecer rapidamente em um bloco da L2 enquanto a etapa de settlement real ainda está se ajustando atrás dela.
essa distinção importa mais do que parece.

os documentos especificamente alertam contra inferir finalidade a partir do tempo decorrido e dizem que apps movendo valor entre o duskevm e a L1 devem verificar o protocolo ou o status da carteira, em vez disso. eu não esperava essa lacuna entre inclusão e.

setlement ser chamada de forma tão direta; parece exatamente o tipo de lugar em que bugs se esconderiam se uma equipe assumisse que uma transação rápida já estava final.

se você estivesse construindo no duskevm, você verificaria o status de settlement antes ou depois de mostrar ao usuário uma tela de sucesso??

#dusk @Dusk $DUSK