Subscribing to newBlockHeaders, many blocks are received 20+ seconds after their timestamp

I’m subscribing to newBlockHeaders through web3.

I’m logging the block timestamps and the time I’m receiving them from Infura.

The average delay is about 16 seconds, often it’s 20+ seconds, sometimes much more. My internet connection is fine. I receive responses from other web3 requests within a second.

Is this normal? I’m no expert on how fast blocks get propagated through the ethereum network but I would assume that Infura has solid peer connections such as big miners. Shouldn’t blockheaders be received much faster?

From my understanding, the timestamp field in a block is actually when the miner started to mine that block, not when it actually made it to the network. Mining a block typically takes about 15sec, so that lag makes sense. newBlockHeaders is a bit of a different beast from other web3 methods, as it notifies you when a new block gets added to the blockchain, hence the lag.

Ah, that explains it. Thanks a lot. I was wrongly assuming that the timestamp is when the block has been fully mined, but now I understand that wouldn’t make much sense because the timestamp can’t be changed anymore after starting the mining (although a miner could of course set the timestamp ahead a bit before starting mining, but probably there wouldn’t be much incentive for doing this).

1 Like