Request of clarifications

Questions about the final project

Questions about the final project

by Laura Ricci -
Number of replies: 2

I report below here some questions which I have received about the final project and mu answers:

1.

  • Q: What does it happen if a miner M receives a confirmed block B from the network containing some transactions belonging to the block it is currently mining? 
  • A: M modifies its copy of the blockchain by adding  B, stops the mining of the current block and discards all the transactions belonging to B. Then it starts a new mining process (the new block will not contain the discarded transactions). In the project, a block is only a list of transactions chosen by the miner (no PoW), so it is sufficient that the miner deletes from the transaction list the confirmed transactions.
2. 

  • Q: Let us suppose that a node N receives a mined block B, with an identifier different from the identifier of the previous block. This may happen because N has not yet received the previous mined block, due to network latency.
  • A: N stores B in a temporary buffer till the previous block of the blockchain is received, the blockchain remains unchanged. N does not notify B to the neighbors because it does not know whether the block is valid.
3.

  • Q: from the text of the project "The Oracle performs its choice of the next miner at regular intervals of
    time whose frequency is defined by a probability distribution". What does this mean?
  • A: this means that the Oracle picks a value for the interval of time from a distribution (for instance a Gaussian distribution)  to decide the next instant of time when a block is mined.



In reply to Laura Ricci

Re: Questions about the final project

by GIANLUCA MARASCHIO -

In the second question, let us suppose that a node N received a mined block B, with an identifier different from the identifier of the previous block. Then N stores B in temporary buffer till the previous block chain is received, the blockchain remains unchanged. N does not notify B to its neighbours. When will N notify B to neighbours eventually? when received a previous block that belongs to a blockchain??
Let us suppose that there will be a chain with forking in which the last element has not a parent node in the blockchain. then this chain will be stored in temporary buffer. Then we doesn't notify each element of the chain to neighbours until the last element of the chain will have a parent in blockChain??If yes, it is complicated to implement.
 You could do that for each received block, we notify it to neighbours also if it has not parent??  
Or another Hybrid solution(for example send only the last element)

In reply to GIANLUCA MARASCHIO

Re: Questions about the final project

by DAMIANO DI FRANCESCO MAESA -

You only always notify valid blocks of your "officially deemed" branch of the chain. This means that if if you come to know of valid side branches you never propagate those to the other nodes.

In your example where you know of a more recent "unlinked" piece of a chain with forks you remember it but ignore it, keeping mining on the last valid block on the longest chain you know of (that cannot be in the "unlinked" chain). If at a subsequent time you receive the missing block(s) to link the more recent piece of the chain (and everything is valid) AND this new piece of the chain is LONGER than the old longest branch then:

1) you start mining on the latest valid block (on the new branch under the previous assumption its longest);

2) you communicate the new longest branch to the other nodes as usual (this means the linking block(s) and the entire branch until the block you're currently mining on).

Always remember the rule that a COMPLIANT miner notifies only new blocks on the branch it think is the official one (which is the same that it's mining on). The previous explained behavior is just an application of such rule.

IMPORTANT NOTE:

A lot of students have been asking questions about this and deep forks in the chain, especially regarding the amount of memory required from every node to remember all the forked or "unlinked" branches. TO SOLVE THE PROJECT MORE EASILY YOU CAN EMULATE A REAL BITCOIN FEATURE CALLED "CHECKPOINTS". THIS SIMPLY MEANS THAT YOU ASSUME THAT A BLOCK IN YOUR CURRENT CHAIN AT DEPTH MORE THAN k THAN THE LATEST OFFICIAL BLOCK IS NOT MODIFICABLE. IN CASE OF FORKS THE DEPTH EVALUATION SHOULD TAKE INTO ACCOUNT NOT SIMPLY THE BLOCK HEIGHT BUT ALSO THE DIFFERENCE BTEWEN THE LATEST BLOCK AND ALL THE OTHER BRANCHES. For example if k==3 and the blockchain looks like this:

b90---b91---b92---b93---b94---b95

        \b91''--b92''--b93''--b94''

The last block is b95, but the last "checkpoint" is b90 and NOT b95 (that would be the block at distance 3 from the last block). This is because the b94'' has only a 1 height difference from b95 branch that is smaller than 3. To better understand if you consider the case:

b90---b91---b92---b93---b94---b95--b96

        \b91''--b92''

Then b93 is the correct checkpoint.

THE VALUE OF k SHOULD BE A GOOD COMPROMISE BETWEEN USAGE AND MEMORY CONSUMPTION, BUT MOSTT IMPORTANTLY SHOULD GUARANTEE A REASONABLY MINIMAL IMPACT ON FORKS. DO CONSIDER THAT THIS SOLUTION MAY CAUSE THE CHAIN TO DIVERGE BETWEEN DIFFERENT NODES, LEADING TO NETWORK SEGMENTATION. THIS SHOULD BE AVOIDED AS MUCH AS POSSIBLE BY CHOOSING AN HIGH ENOUGH k, AND RERUNNING THE EXPERIMENTS WHEN IT RANDOMLY HAPPENS.

IMPORTANT IS TO NOTE THAT SELFHIS (OR OTHER KINDS OF MALEVOLENT) MINERS SHOULD TAKE IT INTO ACCOUNT RELEASING PRIVATE CHAINS IF THEY GET CLOSE IN LENGTH TO THE k VALUE, TO AVOID USELESS FORKS. FINALLY WE NOTE THAT THIS TRICK COULD HELP IN THE "SELFISH MINERS ONLY" SCENARIO TO TRIGGER EVENTUAL BLOCKS PUBLICATION.