PoH ticks are generated at a specific Hz, need to be generated at a specific hash-loop count

[rob-solana]

Problem:

PoH ticks are generated at a specific Hz, so the "difficultly" (in Bitcoin terms) is implicitly and dynamically adjusted by the leader. This creates a problem when validators are attempting to create "virtual ticks" that they'd all synchronize on if the leader entry doesn't get its 2/3+1 vote.

Proposed solution:

Fullnodes could plan to use the same PoH count for each Tick. This may be problematic if processing transactions takes longer than that count. The leader effectively stalls PoH in that scenario. It also raises the question, how should "difficulty" be upgraded such that PoH Ticks continue to estimate "Hz"?

[garious]

@rob-solana, I reverse-engineered the problem your solving as best I could, and used it to write a description for this ticket. If it's accurate, can you please update the title of this ticket to specify the problem and not a potential solution?

[rob-solana]

duplicate of #1428

the problem is that the network protocol to support the TDMA-style leader rotation, forking is not implementable if nodes do not agree on a num-hashes-per-tick hyper parameter

[rob-solana]

all of the code is in place for generating ticks at a specific hash count except for a network hyper-parameter config for it and the default of turning it on