[Nakamoto] Analysis of the Greatest Sources of Latency

[AshtonStephens]

This is a discussion post to analyze what we predict to be the greatest sources of latency on Nakamoto release. SIP-021 promises 5 second block times. This discussion is to research core aspects of the system that could cause delays and risk slower than promised.

"How long does it take to produce an empty block?"

Relevant Draft SIP: SIP-021 #155

[kantai]

This issue can be thought of as "how long does it take a miner to produce an empty stacks block"? This is something like the limit for how fast a block could be produced if Clarity VM / MARF interactions were infinitely fast.

This should measure the time it takes for:

1. A miner to be notified and process a new bitcoin block (an optional step: it's also worthwhile to measure the time it takes to produce an empty non-tenure changing block).
2. The miner to assemble the block proposal.
3. The miner to store the block proposal in the StackerDB
4. Stackers to receive the proposal from the StackerDB
5. Stackers to evaluate the block proposal
6. Stackers to coordinate on signing the block proposal
7. Stackers pass final signature to the miner via the StackerDB
8. Miner to finalize the block and propagate

This involves network latency (the StackerDB and stacker coordination) and will depend on the number of signers.

[jferrant]

To properly test stacker DB signing a block proposal, the testing environment must have a realistic number of signers distributed widely around the world to simulate latency delay due to geographic location. It also should be run with the full 4000 vote shares.