We removed the `precompile` check on `OnNewAccount` and moved it to the Firehose tracer directly. This way, we can remove our custom logic that toggle the check at the tracing code level and we can instead move the logic of backward compatibility back `FirehoseTracer`.
Refactored a bit also how precompiles are check. We moved the precompiles checker up to the block level now that `chainConfig` is available on `OnBlockStart` meaning we can extract the list of active precompiles. However, to make it work, we had to modify `OnGenesisBlock` to also receive `chainConfig` parameter, I've ask to add it to the geth codebase directly.
This change makes use of uin256 to represent balance in state. It touches primarily upon statedb, stateobject and state processing, trying to avoid changes in transaction pools, core types, rpc and tracers.
* core/vm: set basefee to 0 internally on eth_call
* core: nicer 0-basefee, make it work for blob fees too
* internal/ethapi: make tests a bit more complex
* core: fix blob fee checker
* core: make code a bit more readable
* core: fix some test error strings
* core/vm: Get rid of weird comment
* core: dict wrong typo
* Experimental: EVMLogger fixed error code
* First pass of review
* Move error to `core/vm/errors.go`, ensure also we strictly implement `rpc.Error` (without depending on it)
This way, we avoid having a `cost` that is negative which does not make sense for a `uint64`. Having the `old, new` also yields correct value and the delta can then be negative and be holded in a `int64`.
# Conflicts:
# core/vm/evm.go
This way, we avoid having a `cost` that is negative which does not make sense for a `uint64`. Having the `old, new` also yields correct value and the delta can then be negative and be holded in a `int64`.
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.
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.
