The genesis flush do set the logger, but we receive the genesis block allocs via `OnGenesisBlock` meaning it's not necessary to have the logger in the flush.
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.
* core/types: add data gas fields in Receipt
* core/types: use BlobGas method of tx
* core: fix test
* core/types: fix receipt tests, add data gas used field test
---------
Co-authored-by: Péter Szilágyi <peterke@gmail.com>
* core/blobpool: implement txpool for blob txs
* core/txpool: track address reservations to notice any weird bugs
* core/txpool/blobpool: add support for in-memory operation for tests
* core/txpool/blobpool: fix heap updating after SetGasTip if account is evicted
* core/txpool/blobpool: fix eviction order if cheap leading txs are included
* core/txpool/blobpool: add note as to why the eviction fields are not inited in reinject
* go.mod: pull in inmem billy form upstream
* core/txpool/blobpool: fix review commens
* core/txpool/blobpool: make heap and heap test deterministic
* core/txpool/blobpool: luv u linter
* core/txpool: limit blob transactions to 16 per account
* core/txpool/blobpool: fix rebase errors
* core/txpool/blobpool: luv you linter
* go.mod: revert some strange crypto package dep updates
EIP-6780: SELFDESTRUCT only in same transaction
> SELFDESTRUCT will recover all funds to the caller but not delete the account, except when called in the same transaction as creation
---------
Co-authored-by: Martin Holst Swende <martin@swende.se>
This updates the reference tests to the latest version and also adds logic
to process EIP-4844 blob transactions into the state transition. We are now
passing most Cancun fork tests.
Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
Co-authored-by: Felix Lange <fjl@twurst.com>
