Firehose: In previous versions of the EVM, there was no `evm.StateDB.Exist` above and the `CreateAccount` was always called. This was leading to always get a `OnNewAccount` event in the tracer as we were not checking previous existence of the account.
With the introduction of the `Exist` method, there is now cases where `CreateAccount` is not called if it was previously existing.
To keep the same tracing behavior as before, we call the `OnNewAccount` manually here if the account was previously existing.
The StateDB SelftDestruct6780 must not record a balance change since the `opSelfdestruct6780` instruction implementation already calls `StateDB.SubBalance` to deduce the suicide refund.
The second test case show case a new account creations in 2.3 but that doesn't appear when running in backward compatibility mode using 3.0 version of the tracer.
Geth 1.14.12 introduced new `OnCodeChange` emitting which breaks Firehose tracing which is not recording those.
Changed a big how we record call suicide and ignore `CodeChange` that makes the contract empty when a call is suicided.
Now `trace` alone will not print the opcodes which makes it much harder to track log lines and usually is not that useful.
The `trace_full` is same as `trace` but logs `OpCode`.
I think this cannot happen in the wild while syncing block, otherwise it would mean the transaction would have no receipt which is impossible.
However in testing conditions or when doing "speculative exeuction", it's possible to get that condition.
This is just to better deal with a potential `nil pointer exception`.
The EVM does memory expansion **after** notifying us about OnOpcode which we use to compute Keccak256 pre-images now. This creates problem when we want to retrieve the preimage data because the memory is not expanded yet but in the EVM is going to work because the memory is going to be expanded before the operation is actually executed so the memory will be of the correct size.
In this situation, we must pad with zeroes when the memory is not big enough.
This change adds a testcase and fixes a corner-case in the skeleton sync.
With this change, when doing the skeleton cleanup, we check if the filled header is acually within the range of what we were meant to backfill. If not, it means the backfill was a noop (possibly because we started and stopped it so quickly that it didn't have time to do any meaningful work). In that case, just don't clean up anything.
---------
Co-authored-by: Péter Szilágyi <peterke@gmail.com>
The beacon root when applied in `state_processor.go` is performed right before executing transaction. That means that contract reliying on this value would query the same value found in the block header.
In that spirit, it means that any tracing/operation relying on state data which touches transaction must have updated the beacon root before any transaction processing.
This PR adds an extra mechanism to sync.HeadSync that tries to retrieve the latest finality update from every server each time it sends an optimistic update in a new epoch (unless we already have a validated finality update attested in the same epoch).
Note that this is not necessary and does not happen if the new finality update is delivered before the optimistic update. The spec only mandates light_client_finality_update events when a new epoch is finalized. If the chain does not finalize for a while then we might need an explicit request that returns a finality proof that proves the same finality epoch from the latest attested epoch.
This change fixes three flaky tests `TestEth2AssembleBlock`,`TestEth2NewBlock`, `TestEth2PrepareAndGetPayload` and `TestDisable`.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This change removes support for subscribing to pending logs.
"Pending logs" were always an odd feature, because it can never be fully reliable. When support for it was added many years ago, the intention was for this to be used by wallet apps to show the 'potential future token balance' of accounts, i.e. as a way of notifying the user of incoming transfers before they were mined. In order to generate the pending logs, the node must pick a subset of all public mempool transactions, execute them in the EVM, and then dispatch the resulting logs to API consumers.
