Implementing CN timeout bonifications

[vncoelho]

Closes #664

[igormcoelho]

This idea is very good and will probably remove most of the existing change views, in situations where the nodes are clearly evolving.

[vncoelho]

[igormcoelho]

Added some extra protections, and better parametrization based on M.
This is the most stable version until now on our private network.

[erikzhang]

Why do we change timer everywhere?

[vncoelho]

Change timer were inserted in 4 different places, ensuring that all payload checks were done correctly and no attacks would be possible for increasing a node timer:

• When prepreq is received with sucess;
• When prepresp are received with sucess;
• When commits are received with sucess;

It looked like to be the simplest way to implement.
Do you recommend another way, @erikzhang?

It will not affect liveness.

[igormcoelho]

Why do we change timer everywhere?

@erikzhang , we can rename it to IncreaseTimer, perhaps it's a better name.

[erikzhang]

Can anyone review this PR? However, I am worried that if we continue to optimize the consensus, dBFT2.0 may never be able to go to the mainnet.

[igormcoelho]

@erikzhang this is not just optimization... we designed this in order to prevent common change views, that we thought could help avoiding the last stall on test net.
But now, after reviewing the logs, we found an actual fix, on #706 / #707

My suggestion is to ask NGD for a report over this... if network behaves so much better, we advise putting this on TestNet together with the pending fix. If it's not deemed too great, then it can be kept for later. It looks like an arbitrary change, but we thought about that from a long time, this was the only way to make our priv net work "perfectly".

[igormcoelho]

@jsolman @shargon can you check this, if you agree on the logic?

[vncoelho]

These guys have no limits, @erikzhang...aheuaheuaea
It is going to be an endless journey of optimization :D Let's make science !! 💃
I am joking, @erikzhang....aehauheuaea

This is a nice feature/mechanism. The performance improved considerably as @igormcoelho highlighted.
Several unnecessary changeview are being avoided with this.
Let's move it forward as soon as possible. There are no negative impacts for real-world operation and it also represents a good step towards scalability.

[Qiao-Jin]

Excuse me, but will this have negative effect upon onchain TPS (Transactions per second)? Thx!

[jsolman]

Excuse me, but will this have negative effect upon onchain TPS (Transactions per second)? Thx!

No, in general it would probably improve TPS. These extensions only apply when the protocol is making progress, which in the case of a working network should be coming to consensus without needing a view change.

[jsolman]

My suggested changes are just naming and comment text. The code implementation seems reasonable to me.

[vncoelho]

Travis problems, how to re-run Travis? Sometime ago I saw that button on their system.

[shargon]

Restarted

[vncoelho]

I just noticed I was not logged in there, @shargon. Thanks,

My concerns were addressed.

[shargon]

travis is not working on neo-vm too...

[vncoelho]

Thanks everybody.
Byzantine is byzantine, agreement is agreement, fly we go.