0

I am writing a visualisation application; I need to get transactions from multiple blocks from the blockchain. However, I am not sure how the numbering of uncles and blocks works. Since Geth client is very slow to query 1000 blocks, I am slowly scrapping data from Geth client and caching it into MongoDB. I currently query the initial block using either its number or hash and then make subsequent queries using block.parentHash, recursively. For a large number of blocks queried in such fashion hurts MongoDB's performance. So if I could assume that block numbers are sequential in order, I could just request 1000 blocks straight away from MongoDB and speed up my application.

So could you please explain how the block number and uncle numbers differ and given 3,500,000 starting block, where I need 10,000 preceding blocks in the chain could I use the $gte and $lt operators to query blocks from 3,500,000 to 3,490,000 and be assured that no uncles will be present, or do I have to rely on block.parentHash?

2

For any given block, there is a single, direct line of ancestor blocks all the way back to the genesis block. If you are working backwards from somewhere that is already fairly deep in the history (say a block from a few hours ago or earlier) you can ignore the existence of uncle blocks: There shouldn't be any reorganizations that affect whether the blocks in the direct line you're following end up being normal blocks or uncle blocks, and the node you are talking to should only give you transactions from blocks that ended up in its main chain, rather than from uncle blocks.

If you need to handle recent blocks, there is always the possibility that there will be a reorg, and what your node previously told you was a block with height (aka "number") xxxxxx will be replaced by a different block with the same height. If you need to track this branching tree in real time, with different versions of history that may or may not end up as the final version, you will need to handle their relationships using block hashes. Alternatively it may be enough for you keep track of a single line, but delete transactions from orphaned blocks when they are orphaned and replace them with the blocks in the new history.

  • In summary, for old blocks, such as 3000000, must be the parent of 3000001 and so on. However, for recent blocks, I will have use block.parentHash do determine the chain until the block height/number is reorganised and become old. How would one detect a new block? – Athaheer May 24 '17 at 4:12
  • There are RPC calls to get your node to notify about new blocks that your node considers in the main chain. You should also be able to get your node to tell you when it reorgs things you were expecting to be there - see ethereum.stackexchange.com/questions/10586/… . I don't know of a way to get the node to tell you about orphans that it never considered part of the main chain, should you be interested in that. – Edmund Edgar May 24 '17 at 6:05
0

I do a similar caching thing.

Before I cache a block, I add a data field called final. Initially it's false, but over time I set it to true when its time stamp gets more than five or six minutes old.

As I do my analysis, I can choose to either include or exclude finalized blocks.

Also, as I scan the data, if the block is not final, I reread it from the chain instead of my cache.

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.