@Dusk_Foundation Estaba mirando una transacción de Phoenix en la que el límite de gas estaba cómodamente por encima de lo que la ejecución realmente necesitaba, y la parte interesante no era la tarifa en sí. Era lo que le sucedió a DUSK que nunca se consumió.
Al principio lo traté como un gas sobrante normal. Bastante aburrido. Luego empecé a pensar en la ruta de reembolso. Phoenix todavía tiene que demostrar que la transacción podía pagar el costo máximo de ejecución, dejar que la VM consuma lo que realmente necesita y luego devolver el valor restante al propietario correcto. Esa última parte es donde el diseño se vuelve menos trivial.
Un reembolso no es solo “enviar la diferencia de vuelta”. La aritmética tiene que mantenerse consistente, el valor restante no puede exceder lo que se reservó legítimamente y el destino del reembolso en sí tiene que estar protegido. Los cambios de AEGIS de Dusk hicieron eso más claro al estrechar la relación entre el límite de gas, el precio del gas, la tarifa máxima y la dirección oculta del reembolso.
Lo extraño es que un pequeño error contable aquí realmente no es pequeño. Puede convertirse en un problema de conservación del valor, un problema de propiedad o incluso un problema de ejecución.
Principalmente estoy observando lo que ocurre a medida que las transacciones de Phoenix se vuelven más complejas. Las transferencias simples son una cosa. La ejecución intensiva en contratos será una mejor prueba de si este modelo de reembolso sigue siendo predecible bajo presión.
#dusk
$DUSK
$ACE
$ROBO
Al principio lo traté como un gas sobrante normal. Bastante aburrido. Luego empecé a pensar en la ruta de reembolso. Phoenix todavía tiene que demostrar que la transacción podía pagar el costo máximo de ejecución, dejar que la VM consuma lo que realmente necesita y luego devolver el valor restante al propietario correcto. Esa última parte es donde el diseño se vuelve menos trivial.
Un reembolso no es solo “enviar la diferencia de vuelta”. La aritmética tiene que mantenerse consistente, el valor restante no puede exceder lo que se reservó legítimamente y el destino del reembolso en sí tiene que estar protegido. Los cambios de AEGIS de Dusk hicieron eso más claro al estrechar la relación entre el límite de gas, el precio del gas, la tarifa máxima y la dirección oculta del reembolso.
Lo extraño es que un pequeño error contable aquí realmente no es pequeño. Puede convertirse en un problema de conservación del valor, un problema de propiedad o incluso un problema de ejecución.
Principalmente estoy observando lo que ocurre a medida que las transacciones de Phoenix se vuelven más complejas. Las transferencias simples son una cosa. La ejecución intensiva en contratos será una mejor prueba de si este modelo de reembolso sigue siendo predecible bajo presión.
#dusk
$DUSK
$ACE
$ROBO