Neo: After dBFT 2.0, block time gets longer,why so?
trading volume is small, but block time gets longer, the average is more than 20 seconds. What happened?
i359
All 11 comments
i359
on 6 Jun 2019
@vncoelho what do you think?
I guess this is the same average time that testnet has been showing in past months as well, so it's not surprising for me. To know the precise causes, it's necessary catch all consensus messages and see step by step the network progressing. In my opinion, it was expected to have higher times, as another layer was introduced, and delays can be huge in a global network (even with not much messages exchanged). The focus of dBFT 2.0 was two things hard to achieve: guarantee block finality in a definitive manner; and to provide greater stability to the network. Achieving a fixed 15 seconds average can also be done, in the future, as it has never been the focus of the last months of research and development.
igormcoelho
on 6 Jun 2019
I agree.
But I believe that this printscreen refers to a specific time frame.
For example, in the day of the implementation, block times were lower, on a average of 16-17s.
The network is decentralized and CN are spread around the globe. There is also a global delay influence if we analyze specific time windows.
vncoelho
on 6 Jun 2019
I will close this issue because I believe that the question has been answered.
With a detailed statistical analyses we could extend the discussion.
Thanks for wondering and investigating this @i359.
Fell free to keep the discussion and open any future issue or question.
vncoelho
on 6 Jun 2019
Those times are based on times in the block headers also, not necessarily actual wall clock times between blocks.
jsolman
on 6 Jun 2019
However, if they are consistently longer it is likely network latency along with the additional commit phase. The important thing is that the block times are stable and the graph of maximum block times is much lower on average.
jsolman
on 6 Jun 2019
But are they stable? They seem to be steadily creeping higher, at least compared to shortly after the dBFT 2.0 deployment where they were around 16 seconds.
I think this warrants monitoring.
PBSJ
on 7 Jun 2019
It needs to be examined to find the root cause.
jsolman
on 7 Jun 2019
This seems to be happening again.
sector420
on 13 Jun 2019
Looks like it's not an issue in dbft 2.0 afterall... it can work just fine, see it right now (average slightly over 16 seconds):
The other issue does not seem to be dbft-related, but more like p2p related.
igormcoelho
on 16 Jun 2019
True, brother, lets focus on discussion on #803.
vncoelho
on 16 Jun 2019
Related issues
doubiliu
路
3Comments
canesin
路
3Comments
csmuller
路
3Comments
igormcoelho
路
3Comments
igormcoelho
路
3Comments
Most helpful comment
@vncoelho what do you think?
I guess this is the same average time that testnet has been showing in past months as well, so it's not surprising for me. To know the precise causes, it's necessary catch all consensus messages and see step by step the network progressing. In my opinion, it was expected to have higher times, as another layer was introduced, and delays can be huge in a global network (even with not much messages exchanged). The focus of dBFT 2.0 was two things hard to achieve: guarantee block finality in a definitive manner; and to provide greater stability to the network. Achieving a fixed 15 seconds average can also be done, in the future, as it has never been the focus of the last months of research and development.