Une transaction d’activation (Dusk) échouée peut quand même vous coûter du DUSK.
Le “revert” n’efface pas la facture.
J’ai supposé qu’en cas de transaction qui manque de gaz et se rétracte (revert), l’exécution échouée ne laisse essentiellement rien derrière.
Dusk sépare ces deux issues.
Vous définissez un `gas_limit` et un `gas_price`, mais les frais réels sont calculés sur la base de `gas_used * gas_price`. Si l’exécution manque de gaz, la transaction revient (revert), tandis que le gaz déjà consommé est tout de même payé.
Prenons un exemple construit : un appel a une limite de 50 000 de gaz et un `gas_price` de 2 LUX. S’il brûle tout 50 000 de gaz avant de manquer de gaz, la transaction échouée coûte encore 100 000 LUX, soit 0,0001 DUSK.
La modification d’état disparaît.
Les frais, non.
C’est le point que je n’avais pas anticipé.
Un mécanisme protège le registre (ledger) contre la validation d’une exécution qui n’a jamais abouti. L’autre facture tout de même le calcul que le réseau a déjà effectué. Les deux s’appliquent à la même transaction échouée, mais elles ne produisent pas le même résultat.
Ainsi, “échouée” ne veut pas dire “gratuite”. Cela signifie que le changement d’état est effacé, tandis que la facture des ressources peut rester.
Quelle part de la sécurité des transactions de Dusk vient du fait de revenir (revert) une exécution incomplète, et quelle part de sa discipline des ressources vient du fait de continuer à facturer le travail déjà effectué ?
@Dusk #dusk $DUSK
Le “revert” n’efface pas la facture.
J’ai supposé qu’en cas de transaction qui manque de gaz et se rétracte (revert), l’exécution échouée ne laisse essentiellement rien derrière.
Dusk sépare ces deux issues.
Vous définissez un `gas_limit` et un `gas_price`, mais les frais réels sont calculés sur la base de `gas_used * gas_price`. Si l’exécution manque de gaz, la transaction revient (revert), tandis que le gaz déjà consommé est tout de même payé.
Prenons un exemple construit : un appel a une limite de 50 000 de gaz et un `gas_price` de 2 LUX. S’il brûle tout 50 000 de gaz avant de manquer de gaz, la transaction échouée coûte encore 100 000 LUX, soit 0,0001 DUSK.
La modification d’état disparaît.
Les frais, non.
C’est le point que je n’avais pas anticipé.
Un mécanisme protège le registre (ledger) contre la validation d’une exécution qui n’a jamais abouti. L’autre facture tout de même le calcul que le réseau a déjà effectué. Les deux s’appliquent à la même transaction échouée, mais elles ne produisent pas le même résultat.
Ainsi, “échouée” ne veut pas dire “gratuite”. Cela signifie que le changement d’état est effacé, tandis que la facture des ressources peut rester.
Quelle part de la sécurité des transactions de Dusk vient du fait de revenir (revert) une exécution incomplète, et quelle part de sa discipline des ressources vient du fait de continuer à facturer le travail déjà effectué ?
@Dusk #dusk $DUSK