3

I am learning blockchain technology. I executed this command to retrieve the blockchain on a Mac using the Terminal with the fast option:

geth --testnet **--syncmode "fast"** --rpc --rpcapi db,eth,net,web3,personal --cache=1024  --rpcport 8545 --rpcaddr 127.0.0.1 --rpccorsdomain "*" --bootnodes "enode://20c9ad97c081d63397d7b685a412227a40e23c8bdc6688c6f37e97cfbc22d2b4d1db1510d8f61e6a8866ad7f0e17c02b14182d37ea7c3c8b9c2683aeb6b733a1@52.169.14.227:30303,enode://6ce05930c72abc632c58e2e4324f7c7ea478cec0ed4fa2528982cf34483094e9cbc9216e7aa34969124257[email protected]:30303"

and I noticed when it started it was retrieving a relatively large number of blocks per call:

INFO [09-29|16:01:59] Imported new block headers
count=384 elapsed=171.830ms number=1720000 hash=23fd03…de2a49 ignored=0

But now as it reaches the end, the retrieval processes going a block at a time with a rate of about 2 blocks per minute:

INFO [09-30|04:50:36] Imported new chain segment
blocks=1 txs=0 mgas=0.000 elapsed=7.284ms mgasps=0.000
number=1735148 hash=7a06bf…826cf1 INFO [09-30|04:50:59] Imported new chain segment blocks=1 txs=0 mgas=0.000
elapsed=7.813ms mgasps=0.000 number=1735149 hash=23dc26…83d45c INFO [09-30|04:51:09] Imported new chain segment
blocks=1 txs=0 mgas=0.000 elapsed=8.678ms mgasps=0.000
number=1735150 hash=7bb1e0…85eb48 INFO [09-30|04:51:22] Imported new chain segment blocks=1 txs=0 mgas=0.000
elapsed=9.371ms mgasps=0.000 number=1735151 hash=8497a0…1c3cc6

Could someone explain why it takes so long for the more recent blocks to be retrieved?

Right now, according to this site: I still have many more blocks to be retrieved (Block 1775887) versus my most recent retrieved block: 1735151 (1775887 - 1735151) = 40736.

Also, is there a way to keep my Mac awake to process the blocks when I step away from it awhile? It stops the block retrieval if the Mac isn't active.

Thanks for your help.

2 Answers 2

4

Could someone explain why it takes so long for the more recent blocks to be retrieved?

This is simply because more recent blocks are fuller - they contain more transactions. When your node imports a block, it has to re-run all the transactions in the block in order to "validate" it.

In the early days, there were many empty blocks or only partially full blocks. These are very quick to import.

More recently, the block gas limit has increased, yet still, most blocks are full. These blocks take much longer to process.

In addition, there was a series of network attacks about a year ago that took advantage of some mis-pricing of certain opcodes (amount of gas used). This was fixed by changing the gas costs (EIP-150), but the historical transactions are still there and those blocks remain very slow to process.

Some nodes/clients have a "light" or "warp" mode for syncing which allows past blocks either not to be validated fully or to be downloaded and validated later. This brings you up to date more quickly. Worth looking into if your node is struggling.

[Edit - comments above relate to mainnet, but testnet is likely similar.]

0

Geth not syncing for ages on Macs is an old issue, which has been around for over a year now. A more recent issue on github is this, for example. But you can find many more on google, with a plethora of solutions. But there is no perfect solution around yet as far as i know. Generally speaking, I recommend running a node on a Linux virtual machine, where these problems don't seem to appear.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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