取引が拒否されるという失敗モードよりも、DUSKにはさらに厄介な挙動が見つかった。つまり、同じ取引バイト列が受理されたのに、Ruskのどの部分がそれに触れるかによって解釈が変わってしまうのだ。

それを片付ける必要があったのが、Boreasが閉じるべきだった“混乱”だ。ライブ取引はアクティブなプロトコルバージョンに基づいてデコードされる。古いAegisのエンベロープでもネットワーク境界に到達し得るが、Ruskはそれらをより深い層へ進む前に正規化する。ローカルで封印された取引は、台帳にコミットされる前にもう一度正規化される。

厄介なのは履歴だ。DUSKはアップグレード後に、古いルールを単純に削除することはできない。ノードは依然として、Aegis以前およびBoreas以前のブロックを再生（リプレイ）する必要があるからだ。したがって現在のノードは、昨日の形式を理解しつつ、それが今日のブロック生成に“漏れない”ようにしなければならない。

運用者にとっての結論は、残酷なくらい単純だ。再起動、アーカイブの再構築、あるいは完全なリプレイでは、ライブノードが到達したのと同じチェーン状態を再現しなければならない。メンプールの読み取りが一つの意味を返し、過去のリプレイが別の意味を返すと、インデックス、残高、または状態遷移が食い違うまで、すべてが健全に見えることさえある。

私は、アップグレードによって取引ルールが変わること自体よりも、DUSKが過去を変えることなくそれらを変更できるかどうかを重視している。

#dusk $DUSK @Dusk