Eu assumi que, se eu quisesse fazer três coisas on-chain — aprovar, trocar e então fazer stake —, a cadeia trataria isso como uma única coisa acontecendo ou não acontecendo. Uma issue aberta no próprio repositório do Rusk, da Dusk, diz que não é assim que funciona hoje.
Uma transação da Dusk hoje carrega uma única operação opcional: uma chamada de contrato, um deploy ou um memo, com um valor, um destinatário, um nonce e uma assinatura. Então, aprovar, trocar e fazer stake viram três transações separadas, cada uma incluída ou descartada de forma independente. A issue da Dusk afirma isso diretamente: não há garantia de atomicidade entre elas. Faça o approve e o swap mas não o stake, e você fica no meio do fluxo, sem rollback no nível de protocolo.
O problema não é apenas que fluxos de múltiplas etapas podem parar no meio. Corrigir isso muda quem precisa absorver o custo de compatibilidade.
Um contrato batcher torna toda a sequência atômica, porque uma subchamada que falha reverte a transação externa. Mas um contrato alvo que verifica quem está chamando diretamente veria o batcher, não você, a menos que esse contrato já esteja escrito para ir além do chamador imediato. Uma transação em lote no nível de protocolo mantém você como o chamador em cada etapa, mas não vem sem um novo formato de transação, mudanças de consenso, um hard-fork e todos os SDKs de carteiras acompanhando.
Adicionar batching não elimina o tradeoff. Ele decide se a carga de compatibilidade fica na autorização da aplicação ou na pilha do protocolo.
“Corrigir a atomicidade não remove o tradeoff; decide para onde a carga de compatibilidade e a fronteira de confiança se movem.”
O que eu realmente gostaria de observar: se a Dusk escolhe o batcher no nível da aplicação ou a transação no nível do protocolo, e quais premissas existentes de autorização essa escolha força os desenvolvedores a mudar.
#dusk $DUSK @Dusk
Uma transação da Dusk hoje carrega uma única operação opcional: uma chamada de contrato, um deploy ou um memo, com um valor, um destinatário, um nonce e uma assinatura. Então, aprovar, trocar e fazer stake viram três transações separadas, cada uma incluída ou descartada de forma independente. A issue da Dusk afirma isso diretamente: não há garantia de atomicidade entre elas. Faça o approve e o swap mas não o stake, e você fica no meio do fluxo, sem rollback no nível de protocolo.
O problema não é apenas que fluxos de múltiplas etapas podem parar no meio. Corrigir isso muda quem precisa absorver o custo de compatibilidade.
Um contrato batcher torna toda a sequência atômica, porque uma subchamada que falha reverte a transação externa. Mas um contrato alvo que verifica quem está chamando diretamente veria o batcher, não você, a menos que esse contrato já esteja escrito para ir além do chamador imediato. Uma transação em lote no nível de protocolo mantém você como o chamador em cada etapa, mas não vem sem um novo formato de transação, mudanças de consenso, um hard-fork e todos os SDKs de carteiras acompanhando.
Adicionar batching não elimina o tradeoff. Ele decide se a carga de compatibilidade fica na autorização da aplicação ou na pilha do protocolo.
“Corrigir a atomicidade não remove o tradeoff; decide para onde a carga de compatibilidade e a fronteira de confiança se movem.”
O que eu realmente gostaria de observar: se a Dusk escolhe o batcher no nível da aplicação ou a transação no nível do protocolo, e quais premissas existentes de autorização essa escolha força os desenvolvedores a mudar.
#dusk $DUSK @Dusk
