Because access lists use maps with the `StorageKey` as the key, they are
subject to inconsistent ordering in the results of the `.accessList()`
method.
To get around this, an `accessListSorted` method has been added, and
exposed with the same name. The `equal` method has also been exposed to
allow for equality checks at this level outside of this module.
Co-authored-by: 3commascapital <8562488-3commascapital@users.noreply.gitlab.com>
Newly introduced `t.logGaps` was being set to `nil` and still accessed
within `clearFailedLogs`. This PR changes the ordering, moving the nil
setting to `CaptureTxEnd`.
This builds upon #3453 and #3524, which previously implemented gas
optimizations for the access lists generated by Erigon's implementation
of the `eth_createAccessList` RPC call.
Erigon currently optimizes inclusion of the recipient address based on
how many storage keys are accessed, but does not perform the same
optimization for sender address and precompiled contract addresses.
These changes make the same optimization available for all of these
cases.
Additionally, this handles the cases of block producer address and
created smart contract addresses. If these cases were omitted on purpose
since they heavily rely on state, it may still make sense to offer them
to users but disable them by default.
First posted [here](https://github.com/ledgerwatch/erigon/pull/8195)
with bugs, which fixed in this PR.
When we call the debug_traceXXX API provided by Erigon, the withLog
option in tracerConfig is very helpful.
However, currently, the tracer cannot guarantee that the order of logs
output is consistent with the event logs returned in the transaction
receipt. This may make it difficult to use the output of the APIs. If
you need to access event logs in order, it is recommended to use the
event logs returned in the transaction receipt.
Here is an example to illustrate the reason why the order of callTracer
logs and receipt eventlogs can be inconsistent:
In a call trace tree, if a call has multiple logs and this call has
multiple child calls, and logs are also output in the child calls, the
logs of the child calls may be output between the logs of the parent
call in receipt.
I add an index field of log to identify log index of the logs in tracer
result, and it helps me a lot.
When we call the debug_traceXXX API provided by Erigon, the withLog
option in tracerConfig is very helpful.
However, currently, the tracer cannot guarantee that the order of logs
output is consistent with the event logs returned in the transaction
receipt. This may make it difficult to use the output of the APIs. If
you need to access event logs in order, it is recommended to use the
event logs returned in the transaction receipt.
Here is an example to illustrate the reason why the order of callTracer
logs and receipt eventlogs can be inconsistent:
In a call trace tree, if a call has multiple logs and this call has
multiple child calls, and logs are also output in the child calls, the
logs of the child calls may be output between the logs of the parent
call in receipt.
I add an index field of log to identify log index of the logs in tracer
result, and it helps me a lot.
Blob transactions are SSZ encoded, so it had to be added to decoding.
There are 2 encoding forms: `network` and `minimal` (usual). Network
encoded blob transactions include "wrapper data" which are `kzgs`,
`blobs` and `proofs`, and decoded by `DecodeWrappedTransaction`. For
previous types of transactions the network encoding is no different.
Execution-payloads / blocks use the minimal encoding of transactions. In
the transaction-pool and local transaction-journal the network encoding
is used.
Concerns:
1. Possible performance reduction caused by these changes, not sure if
streams are better then slices. Go slices in this modifications are
read-only, so they should be referred to the same underlying array and
passed by a reference.
2. If `DecodeWrappedTransaction` and `DecodeTransaction` will create
confusion and should be merged into one function.
Created to handle #6758.
Just takes the parameters and passes them down the pipe. A local test
against mainnet showed the trace size varied accordingly when passing
true/false values for `onlyTopCall`.
In v2.36.0 we correctly trace this transaction, however due to a code
ordering issue in previous releases, there was an 'out of gas' response,
because we fell through to the code here where
ErrContractAddressCollision will be returned as such. This change isn't
the fix, but ensures the actual error is returned.
Cherry-pick https://github.com/ethereum/go-ethereum/pull/24017.
* core/vm: Define 0xfe opcode as INVALID
* core/vm: Remove opInvalid as opUndefined handles it
Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
Co-authored-by: Andrei Maiboroda <andrei@ethereum.org>
Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
Moved some of the tracers to `eth/tracers/logger` to make it more
similar to go-ethereum.
Removed Erigon-specific `Capture-` functions
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
Remove `callType` argument from `CaptureStart`, and change `callType
vm.CallType` to `typ vm.OpCode` in `CaptureEnter` and move to the first
position (as it is in geth)
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
Splitting function `CaptureStart` into `CaptureStart` (when depth == 0)
and `CaptureEnter` (when depth > 0), while removing argument `depth`.
Same with splitting `CaptureEnd` into `CaptureEnd` and `CaptureExit`
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
In this first step, the new functions `CaptureTxStart` and
`CaptureTxEnd` are introduced to all tracers
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>