o detalhe da transação do Crepúsculo em que eu ficava travado é que uma execução de contrato pode ser revertida sem fazer a própria transação desaparecer.
minha primeira reação foi colapsar isso em um único resultado.
chamada tem sucesso = a transação aconteceu.
chamada reverte = a transação não aconteceu.
a Moonlight não funciona de forma tão limpa.
antes da aceitação, a rede verifica se o remetente consegue cobrir o valor, qualquer depósito do contrato e o gás máximo: gas_limit × gas_price.
ela verifica a assinatura e depois checa se o nonce é exatamente um acima do nonce atual da conta.
justo.
a parte interessante vem depois da execução.
a whitepaper diz que, se a execução do smart contract for revertida, o valor correspondente é reembolsado. o gás não utilizado também é reembolsado.
mas o nonce é incrementado na aceitação.
então “o contrato desfez a mudança de estado” e “a rede consumiu essa tentativa de transação” não são o mesmo estado.
uma reversão pode desfazer o efeito do lado do contrato enquanto o mecanismo de ordenação do lado da conta ainda avança.
gás cria outra fronteira.
ao usuário precisa cobrir o gás máximo antes da execução, mesmo que no fim ele possa pagar menos porque o gás não usado volta.
assim, existem três valores em jogo:
o que você precisa conseguir cobrir,
o que a execução consome,
o que é devolvido depois.
é fácil confundir se o gas_limit parece uma taxa em vez de um limite máximo de gasto.
agora imagine uma aplicação preparando várias transações da Moonlight em sequência.
a transação N chama um contrato e reverte.
o efeito do contrato desaparece.
mas se N foi aceita, o nonce do remetente avançou.
a transação N+1 não consegue raciocinar a partir de “a chamada anterior falhou” como se nada tivesse acontecido.
a falha mudou algo fora do contrato.
essa é a distinção que eu gosto aqui:
rollback da execução é local.
histórico de transações não é.
e isso muda a questão de integração.
quando um app diz a um usuário “esta transação falhou”, o que exatamente falhou?
a transição de estado pretendida?
ou a própria transação?
no Dusk, essas podem ser duas respostas diferentes.
@Dusk #Dusk $DUSK $GPS $TUT
minha primeira reação foi colapsar isso em um único resultado.
chamada tem sucesso = a transação aconteceu.
chamada reverte = a transação não aconteceu.
a Moonlight não funciona de forma tão limpa.
antes da aceitação, a rede verifica se o remetente consegue cobrir o valor, qualquer depósito do contrato e o gás máximo: gas_limit × gas_price.
ela verifica a assinatura e depois checa se o nonce é exatamente um acima do nonce atual da conta.
justo.
a parte interessante vem depois da execução.
a whitepaper diz que, se a execução do smart contract for revertida, o valor correspondente é reembolsado. o gás não utilizado também é reembolsado.
mas o nonce é incrementado na aceitação.
então “o contrato desfez a mudança de estado” e “a rede consumiu essa tentativa de transação” não são o mesmo estado.
uma reversão pode desfazer o efeito do lado do contrato enquanto o mecanismo de ordenação do lado da conta ainda avança.
gás cria outra fronteira.
ao usuário precisa cobrir o gás máximo antes da execução, mesmo que no fim ele possa pagar menos porque o gás não usado volta.
assim, existem três valores em jogo:
o que você precisa conseguir cobrir,
o que a execução consome,
o que é devolvido depois.
é fácil confundir se o gas_limit parece uma taxa em vez de um limite máximo de gasto.
agora imagine uma aplicação preparando várias transações da Moonlight em sequência.
a transação N chama um contrato e reverte.
o efeito do contrato desaparece.
mas se N foi aceita, o nonce do remetente avançou.
a transação N+1 não consegue raciocinar a partir de “a chamada anterior falhou” como se nada tivesse acontecido.
a falha mudou algo fora do contrato.
essa é a distinção que eu gosto aqui:
rollback da execução é local.
histórico de transações não é.
e isso muda a questão de integração.
quando um app diz a um usuário “esta transação falhou”, o que exatamente falhou?
a transição de estado pretendida?
ou a própria transação?
no Dusk, essas podem ser duas respostas diferentes.
@Dusk #Dusk $DUSK $GPS $TUT