Batching of transactions

[mikera]

It has been noted in cloud tests that Peers are often creating blocks with small number of transactions, which is likely to be suboptimal for throughput and consensus efficiency (we want many transactions per block)

Most promising design solution is likely to be to have a Peer avoid publishing blocks when an existing block from that Peer is already in flight (either until final confirmation, or to some advanced consensus stage.

[mikera]

Various improvements in latest develop to help towards this goal.

[helins]

To be confirmed once the issue with syncing the genesis state is resolved

[helins]

Unfortunately no improvement: Block size quartiles = {:min 1.0, :q1 2.0, :median 4.0, :q3 25.609669161725154, :max 200.0, :iqr 23.609669161725154}

[helins]

Looking better in one run: Block size quartiles = {:min 1.0, :q1 10.0, :median 37.666666666666664, :q3 65.0, :max 200.0, :iqr 55.0}

But could be luck. Runs are still unstable so I have a hard time confirming.

[helins]

Clearly improved as of 80589055.
The median block size is now closer to 50.

[mikera]

OK leaving open because I still want to improve this.

Ideally Peers wait until their last published Block is sufficiently advanced in consensus before publishing another. Might need some empirical testing to determine what is optimal. Also probably should be a per-peer configuration option.