かつて、Dusk におけるエポック境界は主にタイミングの出来事だと思っていました。——1つのエポックが終わり、別のエポックが始まる。

しかしよく見てみると、その捉え方には重要なシステム上の制約を見落としている気がします。

エポックは、プロビジョナーの適格性（eligibility）を評価する際の状態を切り替えます。一方でコンセンサスは、計算量の上限の範囲内で動作しなければなりません。つまりこの境界は、単なるカレンダー上の目印以上のものです。参加状態が変化し得る一方で、コンセンサスの作業が際限なく増えていくことを許さない地点なのです。

私が面白いと感じたエンジニアリング上のつながりは次のとおりです：

epoch transition → eligibility state changes → consensus evaluates the new state → computation remains bounded.

そこには微妙なトレードオフがあります。

もし、ステークや適格性の変化が即座に、かつ明確な境界なしにコンセンサスへ影響できるなら、ノードはより複雑な状態遷移に直面し得ます。逆に、変化がエポック条件によって制約されるなら、プロトコルはより整った状態モデルを得られる一方で、参加の変化はそれほど即時には反映されなくなります。

驚いたのは、時間のセグメンテーションと計算上の制限が、それぞれ別の問題を解決しながら互いに補強し合えることです。

エポックは、「コンセンサスの状態がいつ変わるべきか」を答えます。

上限付きの反復プロセスは、「コンセンサスが許される作業量がどれだけか」を答えます。

未解決の問いは次のことです。——ネットワークのプロビジョナー集合がより急速に変化するほど、エポック長は、状態の安定性と応答性のバランスをどう取るべきなのでしょうか？

@Dusk_Foundation $DUSK #dusk