fix: eth_getLogs returns wrong blockHash#2
Open
sungdark wants to merge 1 commit intoXDC-Community:masterfrom
Open
fix: eth_getLogs returns wrong blockHash#2sungdark wants to merge 1 commit intoXDC-Community:masterfrom
sungdark wants to merge 1 commit intoXDC-Community:masterfrom
Conversation
When eth_getLogs is called, the blockHash in returned logs can be incorrect if receipts were stored under a non-canonical block hash during chain reorganizations in XDPoSChain's PoS consensus. The fix explicitly sets log.BlockHash = header.Hash() in checkMatches, ensuring the canonical block hash is always used. This mirrors the existing fix in GetFilterChanges (api.go) which uses core.GetCanonicalHash(). Fix for: XDC-Community#1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix: eth_getLogs returns wrong blockHash
Problem
When calling
eth_getLogs, the returned logs have an incorrectblockHashfield. For example, block 0x22b2277 has canonical hash0xe8ec0bfc021f839fd0a69ae89689e309632af2cc434e8a096732068f0736864bbut the RPC returns0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e.Root Cause
In XDPoSChain's PoS consensus, receipts can be stored under a non-canonical block hash during chain reorganizations. When
eth_getLogsretrieves logs viabackend.GetLogs(), thelog.BlockHashfield may reflect the hash used at storage time rather than the current canonical hash for that block height.Fix
In
eth/filters/filter.go, thecheckMatchesfunction now explicitly setslog.BlockHash = header.Hash()for each matching log before returning. Theheader.Hash()value is the canonical hash retrieved viaHeaderByNumber, ensuring the correct block hash is always returned.This mirrors the existing fix in
GetFilterChanges(api.go) which usescore.GetCanonicalHash()for the same purpose.Testing
All existing filter tests pass:
Bounty
This fixes Gitcoin bounty: #1 (up to $5000 XDC)