Tuning Flow's Block Rate

[AlexHentschel]

Context

In a long-running work, Tarak has replaced the previously used relic cryptography library with BLST. As a result we are seeing notable block-rate increases in model networks. At the moment, it is unclear to which extend these speedups translate to Flow mainnet. Nevertheless, we should see this as an opportunity for improving mainnet performance.

Overview of required work

Step 1: Determine block delay that Cruise control injects before the HCU (using the prior relic crypto stack)

This can be done using the consensus telemetry:

• the TelemetryConsumer's OnOwnProposal method ingests the OnOwnProposal notification from the EventHandler exactly the same way as the MessageHub, which applies the delay before broadcasting.

We can collect the needed data from the Consensus Telemetry via the following Loki query:

{network="mainnet24", app="consensus"} |= "\"component\":\"hotstuff.telemetry\"" |= "OnOwnProposal"

We can use the logging time stamp as an accurate approximator for the time when the MessageHub receives the proposal. Hence, the temporal delay $d$ that the MessageHub waits before broadcasting is $$d = \max (\texttt{targetPublicationTime} - \texttt{time}, 0)$$ The $\max$ function is important, because the targetPublicationTime might be earlier than the current time. In this case, the MessageHub broadcasts immediately, i.e. $d$ is zero.

Step 2: Determine block delay that Cruise control injects after the HCU (using BLST crypto stack)

• same process as Step 1.

Step 3: Data analysis

see Cruise-Control headroom for speedups (notion)

Step 4: Adjust number of views per Epoch in system smart contract controlling Epoch

see Cruise-Control headroom for speedups (notion) for details how to compute the number of views $V'$ that we can maximally choose without reducing the temporal buffer to compensate for slow or offline nodes below the current buffer with the relic stack.