Dynamically adjust PoH hashes per tick based on cluster participants

[mvines]

As of #4292, the number of hashes per tick to achieve the cluster's target tick duration is set statically in the genesis block. But hardware will vary, generally should get faster over time, so that same hashes-per-tick value should cause tick durations to decrease (or otherwise vary) over time.

The underlying assumption is that we would prefer the wallclock duration of each tick to remain as constant as possible throughout the life of the cluster.

This means that:

1. Periodically (perhaps within a vote-like transaction), validators should report their actual tick duration
2. Periodically (perhaps at the end of an epoch), the hashes-per-tick value for the next epoch should be computed based on the stake weighted average of the reported tick durations from the previous epoch.

NB: Congestion-driven fees are likely to require a similar mechanism to agree on a value, see
#4167 (comment)

As a part of fixing this issue enable real PoH on (eg. 20b2be6)

• The testnet testnet
• The TdS testnet

[aeyakovenko]

Dynamic measurement is a big attack surface.

1. Add a wallclock to the vote instruction
2. Gossip/leaders should honor the wallclock and drop old votes. This puts pressure on nodes to give an honest wallclock.
3. Compute the stake weighted median from all the deltas between votes. That should be set as a network constant for the next epoch.

[aeyakovenko]

And make sure the rate doesn’t adjust by more than 33% per epoch

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.