Community bug hunt contribution - Testnet V1.0.5

[LucianMincu]

Bugs

1. Fork choice detected (After more than 12 sec of latency in which one proposer tried to write on disk and then to broadcast the valid block with nonce n, the network already proposed another block with the same nonce n, and also the next proposer broadcast the block with nonce n + 1. Before the rest of the network to sync this block with nonce n + 1, they also received the block with nonce n from the slow proposer. Because they didn't sync yet the block with nonce n + 1 and the final block is still n - 1 (as k finality is 1) they will start a fork choice on the block with nonce n (as they have now two block with nonce n but with different round inside). As the rule is that when two VALID blocks have the same nonce, the one with the lower round will be selected, they will try to request the first block with nonce n. The problem is that the only one who got this block is the slower proposer, but because he also received the new block with nonce n + 1 which has been broadcast by the proposer of that round, this caused a fail of validity when it verified it against his own block with nonce n, and for this reason he considered that he is also on the fork and rolled back to the final block with nonce n - 1, and removed its own proposed block with nonce n. From now nobody will have this block anymore and all the consensus group from that specific shard is stuck, as nobody can resolve the request of this first block with nonce n. The solution for this case is that nobody from network should accept blocks, even they are valid, with the round inside them, lower than the current round - k finality. In this case any slow proposer has time (its round + next one) to broadcast the block to the network as this block to be taken into consideration.
   Note on k finality

Block finality: block N is final only if block N-1, block N-2 … block N-K are signed. Metachain only notarized final blocks. Currently we have chosen K = 1;
You can read more about the K-finality here

2. Problem with the meta blocks which are added into node's shard pool but not notarised until the first cross shard transaction will happen. (this will cause that if there are many meta headers not notarised between two cross shard transactions with destination in node's shard, there is no enough time (in 4 seconds) to compute the validity checks for all of them and for this reason no more cross shard txs could be validated form that point (all will remain in state pending). The solution is that all the hashes from the validated metablocks, until that point, to be added in the creation of each shard block even if there are no cross shard transactions with destination in self shard. In this way the pool is emptied each round and the validation of the next cross shard transaction has to be fast as there are no many meta headers remained to be validated.

Enhancements

1. When a boostrap from storage starts it should feed again the elastic from the first block if the node is launch with a specific flag in this sense

2. Change "Insufficient founds" print on transaction validation process from info to debug

Join the validator community chat on Riot: https://riot.im/app/#/room/#elrond:matrix.org

[sasurobert]

Resovled by: 3c72d66