O que chamou minha atenção na documentação da Dusk não é a camada de privacidade — é como ainda é pequeno o átomo da unidade de uma transação em um L1.
O modelo atual de transações da Dusk carrega uma única ação opcional: uma transferência, um memo, uma chamada de contrato, um deployment (implantação) ou um blob. Uma issue de Rusk de junho de 2026 propõe transações em lote porque intenções do usuário com múltiplas etapas atualmente precisam ser divididas em transações separadas, cada uma assinada independentemente e sujeita à inclusão.
Isso importa mais para infraestrutura financeira do que parece.
Pense em emissão → pagamento → entrega, ou em uma regra de liquidação multi-etapas. Se essas etapas forem separadas, o protocolo atualmente não garante que elas cheguem juntas. Uma pode ter sucesso enquanto outra falha, potencialmente deixando um estado intermediário.
Há uma nuance importante: a DuskVM suporta chamadas entre contratos, então a composição em nível de aplicação já é possível. A lacuna que estou observando é a atomicidade em nível mais baixo da transação, não se a Dusk consegue executar contratos complexos.
Para mim, é um compromisso interessante: a Dusk está avançando em direção a finanças regulamentadas e programáveis, enquanto uma primitiva central de transação ainda é deliberadamente simples.
Estou curioso para saber se o batching nativo se torna parte do protocolo — ou se a Dusk mantém essa complexidade dentro de contratos e camadas de execução.
@Dusk $DUSK #dusk
O modelo atual de transações da Dusk carrega uma única ação opcional: uma transferência, um memo, uma chamada de contrato, um deployment (implantação) ou um blob. Uma issue de Rusk de junho de 2026 propõe transações em lote porque intenções do usuário com múltiplas etapas atualmente precisam ser divididas em transações separadas, cada uma assinada independentemente e sujeita à inclusão.
Isso importa mais para infraestrutura financeira do que parece.
Pense em emissão → pagamento → entrega, ou em uma regra de liquidação multi-etapas. Se essas etapas forem separadas, o protocolo atualmente não garante que elas cheguem juntas. Uma pode ter sucesso enquanto outra falha, potencialmente deixando um estado intermediário.
Há uma nuance importante: a DuskVM suporta chamadas entre contratos, então a composição em nível de aplicação já é possível. A lacuna que estou observando é a atomicidade em nível mais baixo da transação, não se a Dusk consegue executar contratos complexos.
Para mim, é um compromisso interessante: a Dusk está avançando em direção a finanças regulamentadas e programáveis, enquanto uma primitiva central de transação ainda é deliberadamente simples.
Estou curioso para saber se o batching nativo se torna parte do protocolo — ou se a Dusk mantém essa complexidade dentro de contratos e camadas de execução.
@Dusk $DUSK #dusk