eth.blockNumber is 0 while syncing

jurajpetrik commented 7 years ago

System information

Geth version: 1.6.0-stable-facc47cb OS & Version: OSX El Capitan Started with: geth --testnet --rpc console

Expected behaviour

eth.blockNumber should return the latest synced block number at all times

Actual behaviour

eth.blockNumber returns 0 while eth.syncing doesn't return false. Once synced eth.blockNumber returns the expected result again.

Steps to reproduce the behaviour

eth.syncing { currentBlock: 290584, highestBlock: 891836, knownStates: 465886, pulledStates: 361434, startingBlock: 0 } eth.blockNumber 0 //wait to sync... eth.syncing false eth.blockNumber 759556

karalabe commented 7 years ago

Geth 1.6.0 uses fast sync by default. The block states are unavailable for intermediate blocks and are downloaded only for the recent state. As such, up to the point that sync completes, the latest complete block is zero, since all newer blocks are incomplete during sync. When fast sync finishes, it downloads the associated state for the head, so the head block becomes complete and the latest block can be bumped to the current head.

aaressinfomedia commented 6 years ago

Even after geth is sync still getting at block:0 and not able to fetch wallet balance please help

cryptomonk commented 6 years ago

@aaressinfomedia Same

bobomurod commented 6 years ago

@aaressinfomedia same too

aaressinfomedia commented 6 years ago

@bobomurod , Issue resolved, Solution is to wait till all state entries complete download after all blocks sync, There are around 300 million state entries which could take anything between 3 to 4 hour or more depending on net speed.

mnd999 commented 6 years ago

That sounds more like a description of the bug than an resolution

karalabe commented 6 years ago

The definiton of eth.blockNumber is the latest available block. During sync the latest fully available block is the genesis, since no other block has the necessary state available to do anything. As such, the current behavior is the correct one.

On Jan 21, 2018 14:54, "Mark Dixon" notifications@github.com wrote:

That sounds more like a description of the bug than an resolution

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/14338#issuecomment-359246300, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH6GXywPHQ8-q0raVviB1VQpX9KmcX3ks5tMzNrgaJpZM4M-pPl .

mbaddar commented 6 years ago

I am certain I am doing a full sync and yet still get 0. Geth constantly fetches new blocks so not sure if waiting makes sense in that context.

aaressinfomedia commented 6 years ago

Hi,

you are almost done, Keep paticence if your block have sync now you have to wait for Register entries to sync which are almost 2 million which will take some time.

On 18 Mar 2018 3:45 pm, "Mohamed Baddar" notifications@github.com wrote:

I am certain I am doing a full sync and yet still get 0. Geth constantly fetches new blocks so not sure if waiting makes sense in that context.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/14338#issuecomment-373986537, or mute the thread https://github.com/notifications/unsubscribe-auth/AMu22cVKuTNLOKniF69kTc_UhfNQaTFfks5tfjOtgaJpZM4M-pPl .

niksmac commented 6 years ago

Solution

Solution is to wait till all state entries complete download after all blocks sync, There are around 300 million state entries which could take anything between 3 to 4 hour or more depending on net speed.

thanks @aaressinfomedia

nandubatchu commented 6 years ago

Where can we see the status of these state entries?

HektorCyC commented 6 years ago

@nandubatchu eth.syncing

nandubatchu commented 6 years ago

but it does not tell what is the total number of states that needs to be synced! What is the current number for Ropsten chain?

aaressinfomedia commented 6 years ago

State entries are incresing always last when we did there were more then 300 million state entries

On Thu, 19 Apr 2018, 11:44 Yadunandan Batchu, notifications@github.com wrote:

but it does not tell what is the total number of states that needs to be synced! What is the current number for Ropsten chain?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/14338#issuecomment-382622301, or mute the thread https://github.com/notifications/unsubscribe-auth/AMu22fGfZiOqqyItaYGw8jYOiw_KjySeks5tqCs5gaJpZM4M-pPl .

nandubatchu commented 6 years ago

is there no other faster way to sync the Ropsten chain?

aaressinfomedia commented 6 years ago

no wait till it is syn, there is no other fasterway.

On Thu, 19 Apr 2018, 12:10 Yadunandan Batchu, notifications@github.com wrote:

is there no other faster way to sync the Ropsten chain?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/14338#issuecomment-382627358, or mute the thread https://github.com/notifications/unsubscribe-auth/AMu22Y6_aKPhYHFAyYS9hOYDtHUNPQrmks5tqDFjgaJpZM4M-pPl .

guoxingx commented 6 years ago

Hi, I got the same in main network(geth), but in testnet(geth --testnet), eth.blockNumber is the latest synced blocknumber, equals to eth.syncing.currentBlock.

# running in geth --testnet

> eth.blockNumber
226961
> eth.syncing
{
  currentBlock: 226961,
  highestBlock: 3098241,
  knownStates: 5691995,
  pulledStates: 5691995,
  startingBlock: 190267
}
> web3.version
{
  api: "0.20.1",
  ethereum: "0x3f",
  network: "3",
  node: "Geth/v1.8.4-unstable-5909482f/darwin-amd64/go1.10.1",

In my opinion the situation in testnet could be better, but why they are different?

karalabe commented 6 years ago

Please update to 1.8.6. There was a bug in 1.8.4 that caused the sync to occasionally lock up.

3mrsh commented 6 years ago

With Geth 1.8.13, the eth.syncing returns a JSON object with keys: {currentBlock, highestBlock, knownStates, pulledStates, startingBlock}. Unless the eth.blockNumber variable is itself needed for some reason, the information wanted is found in eth.syncing.

tksavov commented 6 years ago

How high do the pulledStates go i.e. what is the current number?

yumingvvv111 commented 5 years ago

In this case, I still get the error: `> eth.blockNumber 0

eth.syncing { currentBlock: 3359252, highestBlock: 3359332, knownStates: 43001886, pulledStates: 42996490, startingBlock: 3357868 } `

senzacionale commented 5 years ago

Me too

eth.syncing { currentBlock: 7088155, highestBlock: 7088274, knownStates: 101932665, pulledStates: 101930811, startingBlock: 7085869 } eth.blockNumber 0

MohseniBigBoy commented 5 years ago

Me too

eth.syncing { currentBlock: 7187639, highestBlock: 7187749, knownStates: 71249322, pulledStates: 71245731, startingBlock: 5855341 } eth.getBlock("latest").number 0 I tested everything in testnet(Ropsten) is OK, problem accrued in mainnet.

FishDawg commented 5 years ago

Same here. I can't get account balance even though everything seems to be synced.

{ currentBlock: 7201006, highestBlock: 7201091, knownStates: 136188889, pulledStates: 136179317, startingBlock: 7200950 }

Yoge-Code commented 5 years ago

Same here.

blockNumber: 0,
syncing: {
    currentBlock: 7247681,
    highestBlock: 7247749,
    knownStates: 267513141,
    pulledStates: 267510933,
    startingBlock: 7247626
  },

arkoc commented 5 years ago

Same here

  blockNumber: 0,
  syncing: {
    currentBlock: 7710468,
    highestBlock: 7710596,
    knownStates: 304848341,
    pulledStates: 304843138,
    startingBlock: 7707841
  }

karalabe commented 5 years ago

Syncing Ethereum is a pain point for many people, so I'll try to detail what's happening behind the scenes so there might be a bit less confusion.

The current default mode of sync for Geth is called fast sync. Instead of starting from the genesis block and reprocessing all the transactions that ever occurred (which could take weeks), fast sync downloads the blocks, and only verifies the associated proof-of-works. Downloading all the blocks is a straightforward and fast procedure and will relatively quickly reassemble the entire chain.

Many people falsely assume that because they have the blocks, they are in sync. Unfortunately this is not the case, since no transaction was executed, so we do not have any account state available (ie. balances, nonces, smart contract code and data). These need to be downloaded separately and cross checked with the latest blocks. This phase is called the state trie download and it actually runs concurrently with the block downloads; alas it take a lot longer nowadays than downloading the blocks.

So, what's the state trie? In the Ethereum mainnet, there are a ton of accounts already, which track the balance, nonce, etc of each user/contract. The accounts themselves are however insufficient to run a node, they need to be cryptographically linked to each block so that nodes can actually verify that the account's are not tampered with. This cryptographic linking is done by creating a tree data structure above the accounts, each level aggregating the layer below it into an ever smaller layer, until you reach the single root. This gigantic data structure containing all the accounts and the intermediate cryptographic proofs is called the state trie.

Ok, so why does this pose a problem? This trie data structure is an intricate interlink of hundreds of millions of tiny cryptographic proofs (trie nodes). To truly have a synchronized node, you need to download all the account data, as well as all the tiny cryptographic proofs to verify that noone in the network is trying to cheat you. This itself is already a crazy number of data items. The part where it gets even messier is that this data is constantly morphing: at every block (15s), about 1000 nodes are deleted from this trie and about 2000 new ones are added. This means your node needs to synchronize a dataset that is changing 200 times per second. The worst part is that while you are synchronizing, the network is moving forward, and state that you begun to download might disappear while you're downloading, so your node needs to constantly follow the network while trying to gather all the recent data. But until you actually do gather all the data, your local node is not usable since it cannot cryptographically prove anything about any accounts.

If you see that you are 64 blocks behind mainnet, you aren't yet synchronized, not even close. You are just done with the block download phase and still running the state downloads. You can see this yourself via the seemingly endless Imported state entries [...] stream of logs. You'll need to wait that out too before your node comes truly online.

Q: The node just hangs on importing state enties?!

A: The node doesn't hang, it just doesn't know how large the state trie is in advance so it keeps on going and going and going until it discovers and downloads the entire thing.

The reason is that a block in Ethereum only contains the state root, a single hash of the root node. When the node begins synchronizing, it knows about exactly 1 node and tries to download it. That node, can refer up to 16 new nodes, so in the next step, we'll know about 16 new nodes and try to download those. As we go along the download, most of the nodes will reference new ones that we didn't know about until then. This is why you might be tempted to think it's stuck on the same numbers. It is not, rather it's discovering and downloading the trie as it goes along.

Q: I'm stuck at 64 blocks behind mainnet?!

A: As explained above, you are not stuck, just finished with the block download phase, waiting for the state download phase to complete too. This latter phase nowadays take a lot longer than just getting the blocks.

Q: Why does downloading the state take so long, I have good bandwidth?

A: State sync is mostly limited by disk IO, not bandwidth.

The state trie in Ethereum contains hundreds of millions of nodes, most of which take the form of a single hash referencing up to 16 other hashes. This is a horrible way to store data on a disk, because there's almost no structure in it, just random numbers referencing even more random numbers. This makes any underlying database weep, as it cannot optimize storing and looking up the data in any meaningful way.

Not only is storing the data very suboptimal, but due to the 200 modification / second and pruning of past data, we cannot even download it is a properly pre-processed way to make it import faster without the underlying database shuffling it around too much. The end result is that even a fast sync nowadays incurs a huge disk IO cost, which is too much for a mechanical hard drive.

Q: Wait, so I can't run a full node on an HDD?

A: Unfortunately not. Doing a fast sync on an HDD will take more time than you're willing to wait with the current data schema. Even if you do wait it out, an HDD will not be able to keep up with the read/write requirements of transaction processing on mainnet.

You however should be able to run a light client on an HDD with minimal impact on system resources. If you wish to run a full node however, an SSD is your only option.

arkoc commented 5 years ago

@karalabe Thank you for explanation. How we can know approx number of states for now? So we can estimate how much it will take.

arkoc commented 5 years ago

Btw our node got synced, it was about 330 million states.

FishDawg commented 5 years ago

Btw our node got synced, it was about 330 million states.

Is this the "knownStates" number from the eth.syncing command? I'm wondering how to tell how much progress has been made with the state trie download.

arkoc commented 5 years ago

Btw our node got synced, it was about 330 million states.

Is this the "knownStates" number from the eth.syncing command? I'm wondering how to tell how much progress has been made with the state trie download.

Yes. Its approx number, I get it like 4-5 hours before getting sync. After getting sync it didn't show that number anywhere.

ankita-p17 commented 5 years ago

Btw our node got synced, it was about 330 million states.

Is this the "knownStates" number from the eth.syncing command? I'm wondering how to tell how much progress has been made with the state trie download.

Yes. Its approx number, I get it like 4-5 hours before getting sync. After getting sync it didn't show that number anywhere.

Hi, I am syncing from last 11 hours and not yet completed.

aaressinfomedia commented 5 years ago

It takes another 2 to 3 hours after 100% syn is complete so just wait for it to download all states

On Tue, 9 Jul 2019, 02:11 ankita-p17, notifications@github.com wrote:

Btw our node got synced, it was about 330 million states.

Is this the "knownStates" number from the eth.syncing command? I'm wondering how to tell how much progress has been made with the state trie download.

Yes. Its approx number, I get it like 4-5 hours before getting sync. After getting sync it didn't show that number anywhere.

Hi, I am syncing from last 11 hours and not yet completed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/14338?email_source=notifications&email_token=ADF3NWM3UE34KX4NHVXVLU3P6OQ73A5CNFSM4DH2SPS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOJDDI#issuecomment-509383053, or mute the thread https://github.com/notifications/unsubscribe-auth/ADF3NWMWHAHYFOJWTDW36VDP6OQ73ANCNFSM4DH2SPSQ .

Jorgeadverd commented 3 years ago

Hi All,

We have been setup new node on our server and after sync almost complete it stuck almost 100 blocks behind. And we wait for 6-7 hours but it's always showing the BlockNumber : 0

Also if we have removed old mainnet node and setup new node again, what are the major steps we need to follow ?

we have been following these article to setup node and it's working fine on testner rinkeby but on mainnet it's not able to sync completely.

https://www.quiknode.io/guides/infrastructure/how-to-install-and-run-a-geth-node instance: Geth/v1.8.2-stable/linux-amd64/go1.9.4 blockNumber: 0,

Could you please suggest us what we are missing here, Thanks in Advance.

karalabe commented 3 years ago

@Jorgeadverd Use a latest release and wait. See https://github.com/ethereum/go-ethereum/issues/14338#issuecomment-490054375

Jorgeadverd commented 3 years ago

Hi @karalabe ,

Yes, we are using updated one as mentioned below

instance: Geth/v1.9.13-stable-cbc4ac26/linux-amd64/go1.14.2

eth.syncing { currentBlock: 11659351, highestBlock: 11659432, knownStates: 626823455, pulledStates: 626815961, startingBlock: 11654085 }

And we are still in syncing mode from almost last 18 hours, also below are the specifications of Hardware>

 *-memory
      description: System memory
      physical id: 0
      size: 15GiB
 *-cpu
      product: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
      vendor: Intel Corp.
      physical id: 1
      bus info: cpu@0
      width: 64 bits

And SSD with 1.5 T

Jorgeadverd commented 3 years ago

Hi All,

Thanks for you support and right direction provided, Finally we had wait till around 48 Hours and Sync has been completed. Also we are able to fetch all operations now from the private node.

Many thanks for your support @karalabe

c1scok1d commented 3 years ago

States are sync'd, block behind by 89 (has never been totally sync'd) latest version, blockNumer still at 0. I've been going at this for weeks and am starting to believe Ethereum is an urban legend as getting a full sync seems impossible.

eth.syncing.pulledStates - eth.syncing.knownStates 0 eth.syncing.highestBlock - eth.syncing.currentBlock 89 eth.syncing { currentBlock: 11881855, highestBlock: 11881944, knownStates: 145393670, pulledStates: 145393670, startingBlock: 11881791 } web3.version { api: "0.20.1", ethereum: "0x41", network: "1", node: "Geth/v1.9.25-stable-e7872729/linux-amd64/go1.15.6", whisper: undefined, getEthereum: function(callback), getNetwork: function(callback), getNode: function(callback), getWhisper: function(callback) } eth.blockNumber 0

log outputs

INFO [02-18|10:39:21.184] Initializing fast sync bloom items=28926365 errorrate=0.000 elapsed=8m25.427s INFO [02-18|10:39:29.273] Initializing fast sync bloom items=29564379 errorrate=0.000 elapsed=8m33.516s INFO [02-18|10:39:32.529] Imported new block headers count=1 elapsed=60.146ms number=11881950 hash="6333d2…65d011" age=1m15s WARN [02-18|10:39:35.559] Checkpoint challenge timed out, dropping id=54d34305b66cada6 conn=inbound addr=178.192.62.49:59564 type=Geth/v1.9.25-stable-... INFO [02-18|10:39:36.551] Imported new block headers count=1 elapsed=5.577ms number=11881951 hash="5bd198…c8cf04" INFO [02-18|10:39:37.276] Initializing fast sync bloom items=30082157 errorrate=0.000 elapsed=8m41.520s INFO [02-18|10:39:41.416] Imported new block headers count=1 elapsed=6.380ms number=11881952 hash="0dc98a…e648d6" INFO [02-18|10:39:45.293] Initializing fast sync bloom items=30895897 errorrate=0.000 elapsed=8m49.536s WARN [02-18|10:39:53.156] Dropping unsynced node during fast sync id=a43887d9a62229bd conn=inbound addr=212.51.146.252:37258 type=besu/v20.10.4/linux-... INFO [02-18|10:39:53.304] Initializing fast sync bloom items=31485225 errorrate=0.000 elapsed=8m57.547s INFO [02-18|10:39:57.508] Imported new block headers count=1 elapsed=4.627ms number=11881953 hash="81874c…18bbd5" INFO [02-18|10:40:01.003] Imported new block headers count=1 elapsed=5.776ms number=11881954 hash="2d534f…43fc22" INFO [02-18|10:40:01.304] Initializing fast sync bloom items=32025643 errorrate=0.000 elapsed=9m5.547s INFO [02-18|10:40:09.340] Initializing fast sync bloom items=32528966 errorrate=0.000 elapsed=9m13.583s

holiman commented 3 years ago

@c1scok1d are you stopping and starting it over and over again, by any chance? It looks like it's been up ~8 minutes on that log snippet ?

karalabe commented 3 years ago

@c1scok1d If your node reliably enters this state after a restart, I'd be super keen to see trace logs from the downloader, it might tell us what goes wrong: You can run geth with --vmodule=downloader=5.

c1scok1d commented 3 years ago

@holiman the service was restarted as the only time it syncs the block is when it restarts. As soon as it gets close it stops getting Blocks and states...quite frustrating!!!!! **> eth.syncing { currentBlock: 11883707, highestBlock: 11884198, knownStates: 218063895, pulledStates: 218063894, startingBlock: 11884106 }

eth.syncing.knownStates - eth.syncing.pulledStates 1 eth.syncing.highestBlock - eth.syncing.currentBlock 491 eth.syncing.highestBlock - eth.syncing.currentBlock 494 eth.syncing.highestBlock - eth.syncing.currentBlock 509 eth.syncing.knownStates - eth.syncing.pulledStates 3121 eth.syncing.highestBlock - eth.syncing.currentBlock 511 eth.syncing { currentBlock: 11883707, highestBlock: 11884220, knownStates: 218067210, pulledStates: 218064089, startingBlock: 11884106 }**

@karalabe Here are tracelog snippets from the INFO [02-18|18:58:47.002] Initializing fast sync bloom TRACE[02-18|18:58:47.439] Fetching full headers TRACE[02-18|18:58:47.604] All headers delayed, waiting TRACE[02-18|18:58:50.604] Fetching full headers TRACE[02-18|18:58:50.793] All headers delayed, waiting TRACE[02-18|18:58:52.227] Unregistering sync peer TRACE[02-18|18:58:53.793] Fetching full headers TRACE[02-18|18:58:53.954] All headers delayed, waiting INFO [02-18|18:58:55.067] Initializing fast sync bloom TRACE[02-18|18:58:56.954] Fetching full headers TRACE[02-18|18:58:57.098] Scheduling new headers TRACE[02-18|18:58:57.098] Fetching full headers INFO [02-18|18:58:57.173] Imported new block headers TRACE[02-18|18:58:57.176] Requesting new batch of data TRACE[02-18|18:58:57.176] Requesting new batch of data TRACE[02-18|18:58:57.296] All headers delayed, waiting TRACE[02-18|18:58:57.349] Peer throughput measurements updated TRACE[02-18|18:58:57.374] Peer throughput measurements updated TRACE[02-18|18:58:57.374] Delivered new batch of data TRACE[02-18|18:58:57.349] Delivered new batch of data DEBUG[02-18|18:58:58.704] Recalculated downloader QoS values TRACE[02-18|18:59:00.297] Fetching full headers TRACE[02-18|18:59:00.432] All headers delayed, waiting TRACE[02-18|18:59:01.372] Registering sync peer TRACE[02-18|18:59:02.358] Unregistering sync peer INFO [02-18|18:59:03.069] Initializing fast sync bloom TRACE[02-18|18:59:03.432] Fetching full headers TRACE[02-18|18:59:03.557] All headers delayed, waiting TRACE[02-18|18:59:06.557] Fetching full headers TRACE[02-18|18:59:06.682] All headers delayed, waiting TRACE[02-18|18:59:08.495] Registering sync peer TRACE[02-18|18:59:09.682] Fetching full headers TRACE[02-18|18:59:09.826] All headers delayed, waiting downloader items=49163532 errorrate=0.000 elapsed=8m41.782s peer=55d8d808c0df1b71 count=192 from=11884213 peer=55d8d808c0df1b71 peer=55d8d808c0df1b71 count=192 from=11884213 peer=55d8d808c0df1b71 peer=5294e07d4af0f296 peer=55d8d808c0df1b71 count=192 from=11884213 peer=55d8d808c0df1b71 items=50048569 errorrate=0.000 elapsed=8m49.847s peer=55d8d808c0df1b71 count=192 from=11884213 peer=55d8d808c0df1b71 count=1 from=11884213 peer=55d8d808c0df1b71 count=192 from=11884214 count=1 elapsed=74.011ms number=11884213 hash="8ddb66…3964f7" age=1m55s peer=131c10bca2053630 type=receipts count=1 from=11884213 peer=131c10bca2053630 type=bodies count=1 from=11884213 peer=55d8d808c0df1b71 peer=131c10bca2053630 hps=0.000 bps=5.456 rps=5.819 sps=1.213 miss=0 rtt=183.306331ms peer=131c10bca2053630 hps=0.000 bps=5.423 rps=5.819 sps=1.213 miss=0 rtt=184.477127ms peer=131c10bca2053630 type=bodies count=1:1 peer=131c10bca2053630 type=receipts count=1 rtt=16.227560317s confidence=1.000 ttl=48.682729632s peer=55d8d808c0df1b71 count=192 from=11884214 peer=55d8d808c0df1b71 peer=5294e07d4af0f296 peer=0b35a5f34b763473 items=50935278 errorrate=0.000 elapsed=8m57.849s peer=55d8d808c0df1b71 count=192 from=11884214 peer=55d8d808c0df1b71 peer=55d8d808c0df1b71 count=192 from=11884214 peer=55d8d808c0df1b71 peer=0b35a5f34b763473 peer=55d8d808c0df1b71 count=192 from=11884214 peer=55d8d808c0df1b71

c1scok1d commented 3 years ago

12+ hours later, worse now than before. Chewing up massive amounts of bandwidth and CPU for what looks like a futile effort. **> eth.syncing { currentBlock: 11887778, highestBlock: 11887896, knownStates: 292334233, pulledStates: 292096313, startingBlock: 11883083 }

eth.syncing.highestBlock - eth.syncing.currentBlock 118 eth.syncing.knownStates - eth.syncing.pulledStates 237072**

karalabe commented 3 years ago

There are over 700M trie nodes

c1scok1d commented 3 years ago

Is there a clear absolute way to check progress. States being sync'd isn't proof, block count being sync'd isn't proof, now I'm reading trie nodes, how do I check those. I'm sure the third time is a charm and if all 3 some how miraculously sync my life should get better. I don't mean to come off as a jerk and appreciate the support but it's like I'm chasing my tail.

pavlovdog commented 3 years ago

There are over 700M trie nodes

Could you tell, what at is the average expected sync speed in states per hour for example? As I see, my node is already processed ~60% of the states

> eth.syncing
{
  currentBlock: 12358106,
  highestBlock: 12358180,
  knownStates: 454904139,
  pulledStates: 454716961,
  startingBlock: 12350600
}

But the speed is ~5.000 states per minute which is 300.000 states per hour. I have measured it manually as a difference between pulledState values. So based on ~700m states I have to wait for

> (700-450) * 10**6 / 5000 / 60 / 24
34.72222222222222 // days

Is there a way to speed up the state sync?

Geth run command (as a systemd service)

ExecStart=/usr/bin/geth --nousb --cache 32000 --ws --http --http.api eth,net,web3,txpool --ws.api eth,net,web3,txpool --maxpeers 512

The VPS has 60 Gb RAM, 10 cores CPU and 1.2 Tb SSD

superstar-lab commented 1 year ago

web3.version { api: "0.20.1", ethereum: undefined, network: "1", node: "Geth/v1.10.23-stable-d901d853/linux-amd64/go1.18.5", whisper: undefined, getEthereum: function(callback), getNetwork: function(callback), getNode: function(callback), getWhisper: function(callback) }

eth.syncing { currentBlock: 2523059, healedBytecodeBytes: 0, healedBytecodes: 0, healedTrienodeBytes: 0, healedTrienodes: 0, healingBytecode: 0, healingTrienodes: 0, highestBlock: 16439804, startingBlock: 361774, syncedAccountBytes: 3422543313, syncedAccounts: 14671550, syncedBytecodeBytes: 442364860, syncedBytecodes: 80955, syncedStorage: 62997140, syncedStorageBytes: 13700741210 } eth.blockNumber 0

Geth run command (as a systemd service)

ExecStart=/usr/bin/geth --syncmode snap --gcmode archive --txlookuplimit=0 --cache=8192 --http --http.api personal,eth,net,web3,txpool --http.addr "0.0.0.0" --http.corsdomain "" --http.port "8545" --authrpc.jwtsecret=/secrets/jwtsecret --authrpc.vhosts="" --mainnet --override.terminaltotaldifficulty 58750000000000000000000 --authrpc.addr localhost --authrpc.port 8551

I am very thankful if anybody can let me know when syncing the eth network into local eth network why eth.blockNumber is 0. I run this command by attaching this command: geth attach http://localhost:8545/ but I can get the eth.blockNumber is 0.

ethereum / go-ethereum