-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix inconsistent latest_block_hash
#1424
Fix inconsistent latest_block_hash
#1424
Conversation
@ahmadkaouk @librelois @koushiro @sorpaas Please help take a review. |
@boundless-forest the overall design seems good, but we need a migration and/or a breaking change section in this PR's description to indicate that there is a migration to run or that node operators should resync the sql backend after the upgrade |
I have deleted the broken db operation. Let's focus on fixing only one issue in this PR. |
* Add `best_hash` method * Update earliest tag matched value * Fix CI tests * Code clean * Fix review comments * Update comment * Fix compile after solving conflicts * Remove the broken changes * Update trait bound * Simplify trait bound
* Add `best_hash` method * Update earliest tag matched value * Fix CI tests * Code clean * Fix review comments * Update comment * Fix compile after solving conflicts * Remove the broken changes * Update trait bound * Simplify trait bound
* Fix inconsistent `latest_block_hash` (polkadot-evm#1424) * Add `best_hash` method * Update earliest tag matched value * Fix CI tests * Code clean * Fix review comments * Update comment * Fix compile after solving conflicts * Remove the broken changes * Update trait bound * Simplify trait bound * FIX ci
We(Darwinia) have noticed that there are some unexpected cases when indexing evm logs with the third party tools, like ponder. After some investment, I found out that the root cause is the latest block hash is sometimes inconsistent when using different RPC methods. For instance, the indexing tool generally first queries the latest block number with
eth_getBlockNumber(latest)
, which returns theclient.info().best_hash
in the current implementation, then it tries to fetch the block data witheth_getBlockByHash(hash)
, but the block data isn't sync to the kv/sql db in time, so the indexing tool misunderstands that the block doesn't have any logs. But in fact it does. Of course, the indexing tool will track the finalize tag and fetch these blocks data again and compared to the previously stored data, it would find the same block hash but with different block data information. We have found that this can be easily reproduced with the frontier sql backend. Some discussion can be found moonbeam-foundation/moonbeam#2788.This PR changes the
latest_block_hash
response from the underlying substrate clientbest_hash
to dblatest_block_hash()
. This only applies to the sql db now.