node-real / bsc-erigon

Ethereum implementation on the efficiency frontier
GNU Lesser General Public License v3.0
118 stars 44 forks source link

Some blocks are lost. #395

Closed bigjoker007 closed 2 weeks ago

bigjoker007 commented 1 month ago

I used the v1.2.5 and the 20240416 snapshot to start the node, now it has synchronized to the block #38696368. But the blocks between #36500000 and #37806999 are lost, all APIs return None. These blocks exist when the node is first started, but disappear after running for a while.

The flag:

--log.dir.path /hdd/app/BscNode/logs --datadir /ssd/data/erigon --chain=bsc --http --http.port=6666 --http.addr 0.0.0.0 --http.api=web3,net,eth,debug,trace,txpool --maxpeers=5000 --db.pagesize=16k

And the hard drive still has 1.3TB of available space.

blxdyx commented 1 month ago

Use latest release

make integration
./integration stage_headers --reset --chain=bsc --datadir=./data
wtdcode commented 2 weeks ago

@blxdyx I'm having the same issue with two bsc-erigon nodes.

Is it possible that bsc-erigon wrongly determine the max block in snapshots? As https://github.com/node-real/bsc-erigon-snapshot suggests, the snapshots should be way beyond 36500000.

blxdyx commented 2 weeks ago

Yes, header reset will fix

wtdcode commented 2 weeks ago

Yes, header reset will fix

No, not exactly. For my local setup, my local snapshots files indicates more than 36500000 blocks but bsc-erigon just recognizes the 36500000 blocks. For instance, I have 39000000 in snapshots:

-rw-r--r--  1 erigon erigon   86M Jun  9 17:32 v1-039000-039100-transactions.idx
-rw-r--r--  1 erigon erigon  4.2G Jun 10 22:53 v1-039000-039100-transactions.seg
-rw-r--r--  1 erigon erigon   42K Jun 10 22:50 v1-039000-039100-transactions.seg.torrent
-rw-r--r--  1 erigon erigon   48M Jun  9 17:32 v1-039000-039100-transactions-to-block.idx

but erigon seems ignoring these snapshots and thinks the highest block in snapshots is 36500000.

Therefore, when erigon syncs another 500000 blocks after stage_reset, the blocks within will be lost AGAIN.

blxdyx commented 2 weeks ago
  1. use the latest branch, it update the snapshots between [0, 38700000)
  2. which range block your have lost.
wtdcode commented 2 weeks ago
  1. use the latest branch, it update the snapshots between [0, 38700000)
  2. which range block your have lost.

Yes, I noticed you have updated the hashes to https://github.com/node-real/bsc-erigon-snapshot and I have tried both master branch and v1.2.9.

I'm losing the blocks after 36000000 although I have all snapshots according to the latest hashes in the repo.

wtdcode commented 2 weeks ago

@blxdyx Specially, I'm repeatlly suffering from:

erigon-1  | [WARN] [06-11|10:54:35.752] [1/15 Snapshots] Some blocks are not in snapshots and not in db max_in_snapshots=35999999 min_in_db=36874500

even though I have snapshots containing blocks after 35999999

blxdyx commented 2 weeks ago

Reset headers don't work?

wtdcode commented 2 weeks ago

One thing while I'm debugging code is that, the preverified hashes are empty here:

https://github.com/node-real/bsc-erigon/blob/30b23c9d75dabe486d2f87cdfea3ae3af436a2ad/turbo/snapshotsync/snapshotsync.go#L102

I can debug a bit further later.

wtdcode commented 2 weeks ago

Reset headers don't work?

It works for first a few days. After syncing another a few blocks (more than 0.5M so that erigon will produce snapshots), the blocks within will be lost again.

wtdcode commented 2 weeks ago

From my understanding of erigon code base, the issue should be fixed by #405 but I will continue monitoring my node status and report in case something is wrong.

For other guys getting this error, simply apply #405 and remove prohibit_new_downloads.lock under the snapshots/ directory. If this still doesn't work, it means a stage_headers reset is probably required.

blxdyx commented 2 weeks ago

The issue was introduce with this pr: https://github.com/node-real/bsc-erigon/pull/399. Thank you for your good job.