0

There are a lot of similar questions like this, but I could not find satisfactory answers specific to my questions.

1.Purely from a single node's perspective, how does it know that the block it received is the one selected by the majority of the consensus, since all it knows is the existence of the immediately neighbouring nodes? There is no tally saying out of 10,000 nodes 6000 agreed on this block.

Let's say Node A receives the following blocks as the latest block from its neighbouring nodes (all with the same block number):

Node B Node C Node D Node E
Block 1 Block 2 Block 1 Block 3

So, in total, Node A received 2 Block 1's, 1 Block 2 and 1 Block 3. Does Node A just go ahead and determine that Block 1 is the majority? Do Block 2 and Block 3 both become Ommer blocks?

2.Will there ever be discrepancies among nodes, like Node B receives 3 of Block 2's, instead of 1? If so, how are they reconciled? Do nodes use CRDTs (Conflict-free Replicated Data Types)?

1 Answer 1

1

Purely from a single node's perspective, how does it know that the block it received is the one selected by the majority of the consensus, since all it knows is the existence of the immediately neighbouring nodes?

It doesn't. PoW is a probabilistic consensus and a node may not receive some information, becoming out of sync with the majority of the network. Nodes will simply mine on what fits the consensus rule according to their local view of the blockchain. The collective view of the blockchain is just the aggregation of many individual views.

Also, blocks and transactions propagations are made on a best effort basis in a P2P network. You directly interact with your immediate neighborhood (peers), but their set of peers is not the same as yours, meaning that every node is either directly or indirectly connected to any other. The network is the medium where information is going to propagate, eventually reaching one of your peer who will forward it to its remaining peers, including you.


For the situation that you are describing, assuming that Block 1, 2 and 3 share a common parent Block 0, this is a fork situation. The way it is resolved has nothing to do with how many times you received that block. Technically, a block is fully received only once, a node requests an unknown block when it is advertised with an unknown block header.

The chain would actually look like this (again, assuming they share the same parent block):

                                               enter image description here

Every single one of those blocks (1, 2 and 3) is a valid candidate as head of the chain. While you might have some selection rule applied based on block difficulty, let's assume that they share the same difficulty too to see how that inconsistent state is eventually solved.

Miners will randomly select one of those block and start mining on it. At some point, a new block (Block 4) will be created and propagated through the network. It doesn't matter if that block extends Block 1, 2 or 3. Following the longest / heaviest chain rule selection, other miners will join in and continue to mine on top of it.

The choice of the head block would be random in that case, and any of those 3 blocks has roughly 33% chances of ending up in the main chain, as 100% of the computing power is uniformly divided across those blocks.

Eventually leading back to a coherent state such as this one when the new blocks is propagated:

                                               enter image description here

This has nothing to do with how many times you received Block X. And both Block 1 and 2 had the same chances of ending up in the main chain, here it just happened to be Block 2.


If your example didn't implied that they all shared a common parent, it's similar in the sense that whatever block is viewed as the head by a majority of the computing power has the greatest probability of being part of the main chain as the majority will be dedicated to mine on top of it since that fits with their local view of the blockchain.


2.Will there ever be discrepancies among nodes ?

Yes, this happens fairly often... Networks can be unreliable, delay messages or drop others, plus you must acknowledge the possibility of faulty / malicious nodes. Just remember that the way this is solved has nothing to do with how many times you received a block and everything with following the chain selection rule if applicable, and the way computing power is allocated across time. PoW ensures that such a situation will eventually be solved.

I purposely simplified several points, but I suppose that's enough to get the idea.

I hope that answers your question.


5
  • Thank you for the detailed answer. So in the case of diverging chains, do they get reconciled to a single chain after just a few blocks or can they go on for many blocks? If latter, does that mean some transactions from 5, 6 blocks ago could be cancelled if that chain doesn't get selected as the one?
    – Kevvv
    Feb 4 at 22:27
  • It gets resolved after the next block in practice but there is a possibility that it goes on longer, the probability is extremely small though. For your second question, yes it is possible even though 5 / 6 blocks is already quite a lot... There are some PoW adversarial attacks that aim to do exactly that, check out "selfish mining" if you want more informations.
    – hroussille
    Feb 4 at 23:35
  • Plus you should check the GHOST chain selection rule that accounts for uncle blocks when deciding the main chain. In simple terms it essentially puts more weight on a chain that had a fork but resolved it, making it even harder to be rewritten.
    – hroussille
    Feb 4 at 23:37
  • Could you explain what you meant by Technically, a block is fully received only once, a node requests an unknown block when it is advertised with an unknown block header? Does a node have to request its neighbouring nodes for a new block when a new one is propagated?
    – Kevvv
    Feb 4 at 23:59
  • I beleive this explanation is very clear (github.com/ethereum/devp2p/blob/master/caps/…) and is official, let me know if anything is still fuzzy for you. It's only to save bandwith as block headers are lighter than full blocks, you announce a new block via its header github.com/ethereum/devp2p/blob/master/caps/… and peers respond whether they want to full block or not, thus the heavy transfers (full blocks) are (mostly) only done when necessary (i.e., requested)
    – hroussille
    Feb 5 at 9:22

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.