[DBFT] Optimize dBFT Consensus Timing Mechanism

[Jim8y]

As we plan to reduce the block time in future updates, network latency issues will have a more pronounced impact on block generation speed. This could potentially slow down the block production rate and, consequently, affect the GAS generation rate. Therefore, we need to implement a mechanism to minimize these latency effects and maintain a stable gas generation rate across the network.

[roman-khimov]

1. This has nothing to do with hardforks. At all.
2. This doesn't make any sense as a NEP to me. dBFT stays the same, timer management is deeply internal to it and 3.7 will be compatible with 3.8 wrt this even if they slightly deviate.
3. The description is insufficient for any kind of implementation. What is T(n) really? It will be different on different machines. What is Tc, when consensus is considered to be started and when is it considered to be finished wrt dBFT cycle?

[Jim8y]

1. This has nothing to do with hardforks. At all.

It needs hardfork to ensure all consensus node works the same.

2. This doesn't make any sense as a NEP to me. dBFT stays the same, timer management is deeply internal to it and 3.7 will be compatible with 3.8 wrt this even if they slightly deviate.

Its OK if you dont think it should be this way, its not required to merge a draft.

3. The description is insufficient for any kind of implementation. What is T(n) really? It will be different on different machines. What is Tc, when consensus is considered to be started and when is it considered to be finished wrt dBFT cycle?

I can update for better description.

[Jim8y]

I am trying to make everything standardized, may make many mistakes, not intentional mistakes, but appologize for those in advance.

I have no idea what should be an NEP, what should not be an NEP, its up to the team to decide and i accept the team decision,

[roman-khimov]

It needs hardfork to ensure all consensus node works the same.

Nope. This adjustment is backwards-compatible, for most networks the difference won't affect correctness.

I am trying to make everything standardized

@Jim8y, don't get me wrong, this is what I totally support and I will help with any protocol formalization efforts. It's just that this particular case is arguable for two reasons: we don't have dBFT NEP and this doesn't change the algorithm itself in any way. It's an implementation detail which has some importance, but maybe not requiring NEP. At the same time, I agree that

its up to the team to decide

And if the majority find this NEP useful then it should be explained in dBFT terms, so that it could be understood and implemented.

[shargon]

This is already merged in HF_Echidna should we move on?