mirror of
https://github.com/ethereum/go-ethereum.git
synced 2026-07-29 08:03:48 +00:00
e0af166ffa
With this change, the full gas loop of a transaction can be tracked going from initial balance (`gasLimit`) back down to 0. I validated on my regression test suite that those conditions applied to all transactions I have: - First `OnGasConsumed` is always going from 0 -> `trx.gasLimit` - Last `OnGasConsumed` "new value" is always 0 - trx.gasLimit - last balance of last `OnGasConsumed` is equal to `trx.gasUsed` The addition of `reason` make it possible for a logger to filter out unwanted signal, for example one could want to drop all OpCode related gas change and only cares about "transaction" level. The reason is also a good thing for visibility and for creating powerful debug tools for Ethereum transaction execution. Also, I would like that we change the `OnGasConsumed` logic from `OnGasConsumed(actual, cost uint64, reason)` to `OnGasConsumed(old, new uint64, reason)`. With the new tracing I've done, we now have negative `cost` that needs to be passed around but the `cost` is `uint64` so it creates overflow. Everything works fine if you record the new/old value `gas-cost` as the final value goes back to a valid range. But it's weird for consumer that would log `cost` that it's `18127127187219...`. An alternative would be to accept a `int64` for the cost which is also valid, not full coverage theorically but I don't see why an operation would cost more than i64 max value. Maybe it make more sense than to have signature `OnGasConsumed(gas uint64, cost int64, reason)`, I'm fine with it also, I leave the decision to you. |
||
|---|---|---|
| .. | ||
| 4byte.go | ||
| call.go | ||
| call_flat.go | ||
| gen_account_json.go | ||
| gen_callframe_json.go | ||
| gen_flatcallaction_json.go | ||
| gen_flatcallresult_json.go | ||
| mux.go | ||
| prestate.go | ||