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>
This PR updates the bls contracts from our internal implementation which is an unmaintained fork of the kilic library to the gnark-crypto library that is actively maintained by consensys.
It also updates the gas-costs according to the EIP
This pull request defines a gentrie for snap sync purpose.
The stackTrie is used to generate the merkle tree nodes upon receiving a state batch. Several additional options have been added into stackTrie to handle incomplete states (either missing states before or after).
In this pull request, these options have been relocated from stackTrie to genTrie, which serves as a wrapper for stackTrie specifically for snap sync purposes.
Further, the logic for managing incomplete state has been enhanced in this change. Originally, there are two cases handled:
- boundary node filtering
- internal (covered by extension node) node clearing
This changes adds one more:
- Clearing leftover nodes on the boundaries.
This feature is necessary if there are leftover trie nodes in database, otherwise node inconsistency may break the state healing.
time.After is equivalent to NewTimer(d).C, and does not call Stop if the timer is no longer needed. This can cause memory leaks. This change changes many such occations to use NewTimer instead, and calling Stop once the timer is no longer needed.
Matthieu Vachon
Chris Ziogas
Mario Vega
Felföldi Zsolt
haoran
Aaron Chen
HAOYUatHZ
Martin HS
rjl493456442
Ryan Schneider
Péter Szilágyi
Felix Lange
xiaodong
bugmaker9371
Marius van der Wijden
ids
ucwong
Devon Bear
persmor
law wang
Darioush Jalali
Marcus Baldassarre
Seungbae Yu
yudrywet
Abirdcfly
forestkeeperio.eth
Newt6611
Sina M
Bin
cui