Increase BlockRequest range

[raychu86]

Motivation

This PR increases MAXIMUM_NUMBER_OF_BLOCKS from 1 to 5. This increases the number of blocks requested per BlockRequest and should reduce the number of messages being sent while syncing.

[howardwu]

You'll want to do the same for the Message type as well.

[howardwu]

Note for future readers: Setting to 5 blocks (from 1 block) would improve sync times, however if a range of blocks contain several large transactions, this could cause a spillover in the buffer codec when transmitting the blocks because the blocks exceed the buffer capacity. The side effect here is that this would break syncing.

This PR will increase the buffer capacity, however this decision should be revisited by future implementers as the protocol changes to support different transaction types and/or larger transaction data.

[howardwu]

@raychu86 we could further improve the design:

We could allow BlockRequest to send say 100 to 200.

The receiver could choose to send say 3 chunks of BlockResponse (i.e. 100-121, 121-130, 130-200) based on how full the codec buffer is.

I believe the BlockSync module is compatible for this already.

[howardwu]

At 5 block chunks, I can confirm that 1000 blocks (i.e. 3 hours of blocks) syncs in 30 minutes. So 24 hours of blocks syncs in 4 hours based on the design up to the current commit.

[zomico]

Are there any benchmark testing that we can perform before doing this change?

[howardwu]

Are there any benchmark testing that we can perform before doing this change?

Yes, this PR is far from ready in my view.

We still need to expand BlockResponse handling for both Message and Event, which should allow us to increase throughput more.

Profiling can be performed by running the devnet scripts folder, enabling 1 new node into the network of nodes, and timing its block sync frequency. Our tests are performed on automated systems using 50 nodes.