@Dusk_Foundation Eu estava analisando uma transação da Phoenix em que o limite de gás estava confortavelmente acima do que a execução realmente precisava, e a parte interessante não era a taxa em si. Era o que aconteceu com o DUSK que nunca foi consumido.
No começo, tratei isso como gás excedente normal. Bem entediante. Então comecei a pensar no caminho do reembolso. A Phoenix ainda precisa provar que a transação conseguia arcar com o custo máximo de execução, deixar a VM consumir exatamente o que ela precisa e, em seguida, devolver o valor restante ao dono correto. É nessa última parte que o design fica menos trivial.
Um reembolso não é apenas “enviar a diferença de volta”. A aritmética tem de continuar consistente, o valor restante não pode exceder o que foi legitimamente reservado, e o próprio destino do reembolso tem de ser protegido. As mudanças do AEGIS do Dusk deixaram isso mais claro ao estreitar a relação entre limite de gás, preço do gás, taxa máxima e o endereço stealth do reembolso.
A parte mais estranha é que um pequeno erro de contabilidade aqui não é realmente pequeno. Ele pode virar um problema de conservação de valor, um problema de propriedade ou até um problema de execução.
Eu estou principalmente observando o que acontece conforme as transações da Phoenix ficam mais complexas. Transferências simples são uma coisa. A execução com contratos pesados será um teste melhor para saber se esse modelo de reembolso continua previsível sob pressão.
#dusk
$DUSK
$ACE
$ROBO
No começo, tratei isso como gás excedente normal. Bem entediante. Então comecei a pensar no caminho do reembolso. A Phoenix ainda precisa provar que a transação conseguia arcar com o custo máximo de execução, deixar a VM consumir exatamente o que ela precisa e, em seguida, devolver o valor restante ao dono correto. É nessa última parte que o design fica menos trivial.
Um reembolso não é apenas “enviar a diferença de volta”. A aritmética tem de continuar consistente, o valor restante não pode exceder o que foi legitimamente reservado, e o próprio destino do reembolso tem de ser protegido. As mudanças do AEGIS do Dusk deixaram isso mais claro ao estreitar a relação entre limite de gás, preço do gás, taxa máxima e o endereço stealth do reembolso.
A parte mais estranha é que um pequeno erro de contabilidade aqui não é realmente pequeno. Ele pode virar um problema de conservação de valor, um problema de propriedade ou até um problema de execução.
Eu estou principalmente observando o que acontece conforme as transações da Phoenix ficam mais complexas. Transferências simples são uma coisa. A execução com contratos pesados será um teste melhor para saber se esse modelo de reembolso continua previsível sob pressão.
#dusk
$DUSK
$ACE
$ROBO