#dusk $DUSK @Dusk ......Eu esperava que o modelo de transação do Dusk fosse um detalhe de implementação menor. O problema mais profundo era mais difícil de perceber: uma única intenção de usuário ainda pode exigir várias transações independentes....
Pense em uma transação de blockchain como uma instrução selada. Se sua ação precisa de cinco instruções, assiná-las juntas não significa automaticamente que a rede as trate como uma única ação. Uma pode ser executada enquanto outra falha.
Esse é o problema que o Dusk está examinando na issue #4058.....
Hoje, uma transação Moonlight ou Phoenix carrega uma única operação opcional TransactionData. Então um fluxo como aprovar → trocar → apostar precisa ser dividido em várias transações, cada uma com sua própria assinatura, nonce e risco de inclusão.
Vai mais fundo....
O Dusk está considerando uma transação em lote em nível de protocolo que poderia executar várias chamadas de contrato de forma atômica sob a identidade do usuário. Isso também permitiria que cada operação carregasse seu próprio valor ou depósito, enquanto potencialmente abrange o Phoenix sem mudar seu circuito de transferência ou configuração confiável...
Mas existe outra rota.
Um contrato agregador poderia executar várias chamadas sem mudar o protocolo. A troca é a autorização: contratos que usam caller() poderiam ver o agregador em vez do usuário original, enquanto public_sender() pode preservar a conta original do Moonlight.
Essa distinção chamou minha atenção....
A parte difícil de agrupar não é colocar várias chamadas em um único contêiner. É definir o que significam identidade, gás, valor e falha quando essas chamadas viram uma única transição de estado.
E a #4058 ainda está aberta, com a implementação real e a especificação do protocolo explicitamente deixadas para trabalho futuro.....
Para uma cadeia voltada a fluxos financeiros, a execução atômica em múltiplas etapas deve se tornar um primitivo de protocolo, ou deve permanecer como algo que contratos compõem?
$ADA $TUT
Pense em uma transação de blockchain como uma instrução selada. Se sua ação precisa de cinco instruções, assiná-las juntas não significa automaticamente que a rede as trate como uma única ação. Uma pode ser executada enquanto outra falha.
Esse é o problema que o Dusk está examinando na issue #4058.....
Hoje, uma transação Moonlight ou Phoenix carrega uma única operação opcional TransactionData. Então um fluxo como aprovar → trocar → apostar precisa ser dividido em várias transações, cada uma com sua própria assinatura, nonce e risco de inclusão.
Vai mais fundo....
O Dusk está considerando uma transação em lote em nível de protocolo que poderia executar várias chamadas de contrato de forma atômica sob a identidade do usuário. Isso também permitiria que cada operação carregasse seu próprio valor ou depósito, enquanto potencialmente abrange o Phoenix sem mudar seu circuito de transferência ou configuração confiável...
Mas existe outra rota.
Um contrato agregador poderia executar várias chamadas sem mudar o protocolo. A troca é a autorização: contratos que usam caller() poderiam ver o agregador em vez do usuário original, enquanto public_sender() pode preservar a conta original do Moonlight.
Essa distinção chamou minha atenção....
A parte difícil de agrupar não é colocar várias chamadas em um único contêiner. É definir o que significam identidade, gás, valor e falha quando essas chamadas viram uma única transição de estado.
E a #4058 ainda está aberta, com a implementação real e a especificação do protocolo explicitamente deixadas para trabalho futuro.....
Para uma cadeia voltada a fluxos financeiros, a execução atômica em múltiplas etapas deve se tornar um primitivo de protocolo, ou deve permanecer como algo que contratos compõem?
$ADA $TUT
