[Alphanet] Transactions do not roll over to the next block

[MaksymZavershynskyi]

It seems like when transactions get into proposal and this proposal gets rejected in favor of another proposal the transactions are not re-attempted on the next proposal. As the result we need to submit transactions to all nodes to ensure they ending up in the block.

To reproduce behavior checkout #658 then set

let num_nodes = 2;
let num_trials = 10;

in test_multiple_nodes

Replace

for k in 0..num_nodes {
                nodes[k]

with

nodes[i]

and run test_multiple_nodes. Observe that some of the transactions are not making it into the blocks.

[mfornet]

This is partially fixed by #656! Changing tie-breaker allow blocks with transactions win consensus.

Other problem still exists, because after a transaction is posted to one node, it should propagate to every node, so at some point, the transaction will be in every proposal, and this is not happening.

[mfornet]

@david-stolp Is Cryptohash::default() less than every other value (when compared)? If not, this is a problem, for a block with some transactions competing against an empty block (empty block is preferred in the consensus, because of the tie-breaker).

[MaksymZavershynskyi]

You could probably fix the issue with default hash by removing derived PartialOrd on BareState and implement our own, where default hash loses to other hashes.

[mikhailOK]

Empty hash already loses the tie breaker but it can't fix the problem because the empty proposal can still propagate faster and reach confidence 1

[mfornet]

This was already solved by #649