el detalle de la transacción del Crepúsculo con el que me quedaba atascado era que una ejecución de contrato puede revertirse sin que la propia transacción desaparezca.
mi primera intuición fue colapsarlas en un solo resultado.
llamada tiene éxito = la transacción ocurrió.
devuelve = la transacción no ocurrió.
Moonlight no funciona de esa manera tan limpia.
antes de la aceptación, la red comprueba que el remitente puede cubrir el valor, cualquier depósito de contrato y el gas máximo: gas_limit × gas_price.
verifica la firma y luego comprueba que el nonce sea uno por encima del nonce actual de la cuenta.
bastante justo.
lo interesante viene después de la ejecución.
el whitepaper dice que si la ejecución de un contrato inteligente se revierte, el monto correspondiente se reembolsa. el gas no utilizado también se reembolsa.
pero el nonce se incrementa al aceptarse.
así que “el contrato mantuvo el cambio de estado” y “la red consumió este intento de transacción” no son el mismo estado.
una reversión puede deshacer el efecto del contrato mientras el mecanismo de orden en el lado de la cuenta sigue avanzando.
el gas crea otra frontera.
el usuario tiene que cubrir el gas máximo antes de la ejecución, aunque al final pueda pagar menos porque el gas no usado vuelve.
así que hay tres montos en juego:
lo que debes poder cubrir,
lo que consume la ejecución,
lo que se devuelve después.
fácil de pasar por alto si gas_limit suena como una tarifa en lugar de un límite máximo de gasto.
ahora imagina una aplicación preparando varias transacciones de Moonlight en secuencia.
la transacción N llama a un contrato y se revierte.
efecto del contrato: desaparece.
pero si N fue aceptada, el nonce del remitente ha avanzado.
la transacción N+1 no puede razonar a partir de “la llamada anterior falló” como si no hubiera pasado nada.
el fallo cambió algo fuera del contrato.
esa es la distinción que me gusta aquí:
el rollback de la ejecución es local.
el historial de transacciones no.
y eso cambia la pregunta de la integración.
cuando una app le dice a un usuario “esta transacción falló”, ¿qué exactamente falló?
¿la transición de estado pretendida?
¿o la transacción en sí?
en Dusk, esas pueden ser dos respuestas diferentes.
@Dusk #Dusk $DUSK $GPS $TUT
mi primera intuición fue colapsarlas en un solo resultado.
llamada tiene éxito = la transacción ocurrió.
devuelve = la transacción no ocurrió.
Moonlight no funciona de esa manera tan limpia.
antes de la aceptación, la red comprueba que el remitente puede cubrir el valor, cualquier depósito de contrato y el gas máximo: gas_limit × gas_price.
verifica la firma y luego comprueba que el nonce sea uno por encima del nonce actual de la cuenta.
bastante justo.
lo interesante viene después de la ejecución.
el whitepaper dice que si la ejecución de un contrato inteligente se revierte, el monto correspondiente se reembolsa. el gas no utilizado también se reembolsa.
pero el nonce se incrementa al aceptarse.
así que “el contrato mantuvo el cambio de estado” y “la red consumió este intento de transacción” no son el mismo estado.
una reversión puede deshacer el efecto del contrato mientras el mecanismo de orden en el lado de la cuenta sigue avanzando.
el gas crea otra frontera.
el usuario tiene que cubrir el gas máximo antes de la ejecución, aunque al final pueda pagar menos porque el gas no usado vuelve.
así que hay tres montos en juego:
lo que debes poder cubrir,
lo que consume la ejecución,
lo que se devuelve después.
fácil de pasar por alto si gas_limit suena como una tarifa en lugar de un límite máximo de gasto.
ahora imagina una aplicación preparando varias transacciones de Moonlight en secuencia.
la transacción N llama a un contrato y se revierte.
efecto del contrato: desaparece.
pero si N fue aceptada, el nonce del remitente ha avanzado.
la transacción N+1 no puede razonar a partir de “la llamada anterior falló” como si no hubiera pasado nada.
el fallo cambió algo fuera del contrato.
esa es la distinción que me gusta aquí:
el rollback de la ejecución es local.
el historial de transacciones no.
y eso cambia la pregunta de la integración.
cuando una app le dice a un usuario “esta transacción falló”, ¿qué exactamente falló?
¿la transición de estado pretendida?
¿o la transacción en sí?
en Dusk, esas pueden ser dos respuestas diferentes.
@Dusk #Dusk $DUSK $GPS $TUT