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.
* beacon/blsync: proceed with empty finalized hash if proof is not expected soon
* Update beacon/blsync/block_sync.go
Co-authored-by: Felix Lange <fjl@twurst.com>
* beacon/blsync: fixed linter warning
* Update beacon/blsync/block_sync.go
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
