Rusk のちょっとした変更は、Dusk がプロトコルのアップグレードをまたいだ暗号検証をどのように扱うかをよく物語っています。
キャッシュされた結果は、もはや証明とその入力にだけ紐づけられていません。Dusk は、その結果を、チェックが行われた時点で有効だった検証ルールにも結びつけています。
これは重要です。まったく同一の証明データでも、常に同一の検証コンテキストとは限らないからです。プロトコルのアップグレードによって、証明そのもののバイト列を変えなくても、検証者や実行ポリシーが変更されることがあります。
Dusk ネットワークでは、特に規制市場向けのプログラマブルなプライバシーを構築していく中で、暗号的な証明がプロトコルのアップグレードをまたいでも信頼できる状態を保つ必要があるため、この点がより重要になります。
私がまだ分かっていないのは、Dusk がバージョン固有のルールを、キャッシュされた結果が有効だった意味論を越えて生き延びることが決してないほどに厳密に隔離できているかどうかです。
注目すべき詳細は、キャッシュキーに含まれる実行ポリシーのコンテキスト、PLONK V3 の有効化といった検証者の変更、そして今後のアップグレードで検証挙動が再び変わったときに何が起こるのかです。
一致する証明バイトは、2 つのチェックが同じに見えることの有力な証拠です。ただし、同じキャッシュ結果を再利用して安全であることを示す証拠としては弱いものです。
私が気にするのは、Dusk がどれだけ検証作業をキャッシュできているかよりも、アクティブな検証者コンテキストが依然として一致しているかどうかです。
より本質的には、決定論的な検証は「入力を固定する」だけでは成り立ちません。その入力を解釈するために用いられるルールも固定されている必要があります。
問題は、Dusk が、キャッシュを通じて古いプロトコル意味論がアップグレード境界を越えてしまうことを許さずに、検証の最適化を継続できるかどうかです。
私は、今後の検証者変更がその実行ポリシーのコンテキストにどう反映されるかを注視しています。

#dusk $DUSK @Dusk