Overview

Context

Epochs have a fixed length, measured in views. The actual view rate of the network varies depending on network conditions (eg. load, # of available replicas, etc), which requires periodic manual oversight and adjustment of view rate to maintain consistent epoch timing.

We would like for consensus nodes to observe the actual view rate of the committee, and adjust their proposal speed (by adjusting block-rate-delay) accordingly, to target a desired weekly epoch switchover time.

High-Level Design

Introduce a new component BlockRateController. It observes the current view rate and adjusts the actual block-rate-delay it introduces when proposing blocks.

In practice, we are observing the past and present output of a system (view rate), updating a compensation factor (block rate delay) to influence the future output of the system in order to achieve a target system output value.

A common tool for solving this class of problem is a PID controller. The essential idea is to take into account the current error, the rate of change of the error, and the cumulative error, when determining how much compensation to apply. The compensation function $u[v]$ has three terms:

<aside> 📚 This document uses ideas from:

Choice of Process Variable: Targeted Epoch Switchover Time

The process variable is the variable which:

<aside> 👉 The BlockRateController controls the progression through views, such that the epoch switchover happens at the intended point in time. We define:

The error, which the controller should drive towards zero, is defined as:

$$ e := \gamma - \Gamma $$

</aside>

From our definition it follows that: