Go-ethereum: eth.blockNumber is 0 while syncing

[jurajpetrik]

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]

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]

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

[cryptomonk]

@aaressinfomedia Same

[bobomurod]

@aaressinfomedia same too

[aaressinfomedia]

@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]

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

[karalabe]

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" [e-mail] 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]

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]

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" [e-mail] 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]

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]

Where can we see the status of these state entries?

[HektorCyC]

@nandubatchu eth.syncing

[nandubatchu]

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]

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, [e-mail]
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]

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

[aaressinfomedia]

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

On Thu, 19 Apr 2018, 12:10 Yadunandan Batchu, [e-mail]
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]

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]

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

[3mrsh]

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]

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

[yumingvvv111]

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

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

[senzacionale]

Me too

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

[MohseniBigBoy]

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]

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]

Same here.

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

[arkoc]

Same here

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

[karalabe]

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]

@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]

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

[FishDawg]

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]

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]

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]

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, [e-mail] 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
.