0

I built geth from a fairly new release 1.8.12, when running on testnet (ropsten) it is executing contracts, however when running on the real net it is not, any idea why this is happening? I am using fastsync and not mining - I did start miner but that does not make any difference.

Edit:August 5th 15:14 PDT Did more debugging and here's where I am at:

In downloader.processFastSyncContent(), the downloader will keep trying to get blocks, and process those after pivot point, in importBlockResults() those blocks after pivot point will be processed and the contracts inside them will be executing. My geth is never passing the pivot point on main net, the afterP list of blocks is always empty. Not sure why tho, my eth.syncing shows: {currentBlock: 6094815, highestBlock: 6094940, knownStates: 84201854, pulledStates: 84159136, startingBlock: 6094466 }

On ropsten testnet my evm almost starts evaluating contracts immediately when it is syncing. Now I'm thinking maybe the testnet has something different from the main net that triggers this behavior?

|improve this question|||||
  • What do you mean with "executing contracts"? – Lauri Peltonen Aug 5 '18 at 7:28
  • @LauriPeltonen when I ran the instance on ropsten, while syncing, it downloaded each transaction in history and verified the transaction by running the byte code. However, on real net it stopped doing so - I do not have the trace of executing each transaction. I am now only a few hundred blocks away from the highest, but still not seeing any executing trace of the past transactions. – haloblock Aug 5 '18 at 13:15
  • Did more debugging and here's where I am at: in downloader.processFastSyncContent(), the downloader will keep trying to get blocks, and process those after pivot point, in importBlockResults() those blocks after pivot point will be processed and the contracts inside them will be processed. My geth is never passing the pivot point, the afterP list of blocks is always empty. Not sure why tho, my eth.syncing shows: { currentBlock: 6094815, highestBlock: 6094940, knownStates: 84201854, pulledStates: 84159136, startingBlock: 6094466 } – haloblock Aug 5 '18 at 22:09
  • Well, at least you're not synced with the network. But don't know if that's a cause or effect – Lauri Peltonen Aug 6 '18 at 5:29
  • yes, always ~100 blocks away from sync, running for 3 days now – haloblock Aug 6 '18 at 14:17
-1

Turns out if I use --syncmode=full then this problem goes away. This can be a bug in the fast sync mode.

Edit: Checked with various users of geth 1.8.XX, several of them share the fact that their geth, when running with --fast, would stuck some blocks away from reaching the top, range from 3 blocks to a few hundreds.

Reading the geth code shows --fast uses much complicated algorithm than full sync mode to do it. In my case the fast sync mode will try to accumulate the blocks after the pivot point, but would fail before it can insert the blocks into the DB.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.