Nakamoto Miner[3.0] - Miners should produce frequent and smaller blocks across different cost dimensions

[saralab]

Current Miner behavior: Build the biggest block it can

This should be updated to produce: Frequent blocks that are smaller

Whilst the change itself is smaller, determining the optimal block size that needs be fine tuned with E2E Testing and profiling.

E2E Testing and Profiling: XL
Actual fix: XS

[saralab]

• Set a default target of 20s and find ways to make that happen
• Run an E2E test with 20s worth of transactions

[314159265359879]

Does determining the optimal block-size also take into account the rate at which the blockchain database is allowed to grow?

Should storing the whole blockchain history be allowed to grow at a maximum rate that would keep the minimum (total?) cost of storing it relatively stable or rather within certain pre-determined bounds?

This paper describes a framework that can be used to determine the total cost of storage. (Total cost not just the cost of the SSD): https://www.researchgate.net/publication/295399942_How_Much_Does_Storage_Really_Cost_Towards_a_Full_Cost_Accounting_Model_for_Data_Storage