Neo: increase tps

[erikzhang]

Optimize network protocol, consensus algorithm and IO mechanism to improve TPS.

[shargon]

I think that something like this:

https://github.com/neo-project/neo/pull/93/commits/ab1e26987d2a8e6c394a6ea9d8b31fd83efc4bcc

And maybe read the magic, only the first time:

https://github.com/shargon/neo/blob/ab1e26987d2a8e6c394a6ea9d8b31fd83efc4bcc/neo/Network/Message.cs#L40

Could save bytes and improve the network protocol

Perhaps, we could check the version to act one way or another, to make it compatible

[erikzhang]

See #282

[anthdm]

@erikzhang Are we keep using the dBFT algorithm? Or should I implement HBBFT in neo-go to get a real-world use case for it?

[erikzhang]

Are we keep using the dBFT algorithm? Or should I implement HBBFT in neo-go to get a real-world use case for it?

This needs to be researched to determine. I haven't got a good understanding of hbbft.

[fabwa]

For sake of completeness: https://github.com/anthdm/hbbft

[jsolman]

See #546 as one thing that can help support increased TPS

[vncoelho]

Part of it has already been achieved, let's write that scientific paper all together now, @fabwa (@igormcoelho, @shargon, @belane, @PeterLinX, @erikzhang, @jsolman, NGD team), and put it on arxiv.org as we are currently discussing! :)

From our readings and studies, we are not fully convinced that hbbft is really the best direction. I have been seeing interesting studies following pBFT principles (as master Yoda @erikzhang did).

Check these ones here:
* Scalable Byzantine Consensus via Hardware-assisted
Secret Sharing: https://arxiv.org/pdf/1612.04997v1.pdf https://ieeexplore.ieee.org/document/8419336
* BEAT: Asynchronous BFT Made Practical: https://www.csee.umbc.edu/~hbzhang/files/beat.pdf

Check this part, extracted from here https://daily-ai.com/beat-asynchronous-bft-made-practical/:
"The best performing asynchronous BFT protocol, HoneyBadger, still lags behind the partially synchronous PBFT protocol in terms of throughput and latency. BEAT is actually a family of five different asynchronous BFT protocols that start from the HoneyBadger baseline and make improvements targeted at different application scenarios."

Furthermore, dBFT 2.0 is surely now a global standard both to the industry and the academic literature, let's explore our current results and move on!

[erikzhang]

I will present a simplified validation model to significantly improve tps.

[Qiao-Jin]

Maybe some changes to actor system could evaluate TPS performance?
In current code consensus & transaction messages are processed by the same Akka actor and, as a result, transaction messages are given low priority (plz see Blockchain.cs) so as to ensure consensus and other MORE IMPORTANT messages processed in time ---- but as a side effect, that could potentially deteriorate TPS.
Would it be possible to arrange a seperate actor for transaction transmission, to enhance TPS? Thx!

[erikzhang]

This won't be a bottleneck unless there are a lot of fake consensus messages blocking the actor's processing.

[Qiao-Jin]

What I saw in local private-net test is that, in single consensus mode, with transactions being sent to validator node continously at a high speed (2000+ per second), average transaction number within a block is approximately 1500. If I change the priority of transaction messages to high, accordingly transaction number will rise gradually to 7000+ or more, before consensus fails due to high transaction pressure. I think it might be a good idea trying to seperate transaction & consensus messages to enhance TPS..

[erikzhang]

This is not normal, isn't it? We should find out the problem instead of thinking about ways to work around.

[vncoelho]

@erikzhang, if you want to close this issue.
I think that increase tps is a consequence of everything that has been merged in these recent weeks.
This will be achieved together with other issues that are already listed for improving performance, simplify and optimize.

[erikzhang]

No. We must test and ensure the tps is increased before closing this issue.

[vncoelho]

A benchmark against latest 2.X will be great, @erikzhang.
Let's do it when the time comes.

[lock9]

@erikzhang I created an issue to create the performance metrics we are using to measure these improvements.
I will replace this issue with it(#920), in order to make our issues "more clear and concise", unfortunately, this issue is too broad. Since you want to "test" before, I created a issue to define the numbers we need to measure.

And obviously, feel free to reopen it if you think this was a mistake.
Thanks.

[vncoelho]

@lock9, I do not know if it is really worth to adjust master-2x for a deep benchmark.
We need to analyse this with careful when we finish NEO3 and design the possibilities for monitoring it.