私は技術的な修正があるのを見つけました。それがDuskのPLONKメインブランチにマージされました。対象は圧縮回路ファイルの逆シリアライズ処理です。本体の解析が終わった後も余分なバイトが残っている場合、compile_with_compressedはInvalidCompressedCircuitを返します。公式の回帰テストでは、正当なMessagePackの末尾値を特別に追加して、修正前は受け入れられ、修正後は拒否されることを確認しました。

同じ圧縮回路であっても、本体はまったく同一、末尾に無関係な1バイトだけ余計に詰め込む場合があります。元のバイト列でハッシュを取る不正対策やキャッシュの仕組みは、それを別のファイルだと認識します。一方、旧版PLONKはそのまま正常に読み込めてしまう可能性があります。

ここで私は少し心配になりました。ファイルが変わっているのに、ツールは「変わっていない」と言うわけです。金融システムでは、エラーで済むより厄介です。つまり“同じものに二枚の身分証”が付くような状態になるからです。

まず対象を確認します。今回変更されたのは、証明生成に使う圧縮回路ファイルであり、今回はチェーン上ですでに生成済みの証明は範囲外です。Duskの最新のマージはかなり明快です。回路本文を読み終えたあと、後ろに余計なバイトがあれば、ファイル全体を即座に無効判定します。

正直に言うと、私は最初、それが几帳面すぎると感じました。旧ツールは動くのだから、数バイトの末尾のために互換性を切る必要があるのか？しかしそれを取引システムに入れるとなると、考えが変わりました。元のファイルが監査やキャッシュ、バージョン管理によって“バイト単位”で識別されるのに、コンパイラは2つの異なるファイルを同一のルールセットとして扱ってしまう。問題が起きた場合、結局どのバージョンを使ったのか説明しにくくなります。

そこで、役に立つ判断材料がひとつあります。アップグレード後に一部のZKアプリが突然失敗したら、まずInvalidCompressedCircuitを確認し、ツールのバージョンと、再エクスポートしたファイルで復旧できるかを見てください。旧ファイルは失敗し、新ファイルは正常、というパターンなら、より多くの場合は“フォーマット移行”に近いです。一方で、規格準拠のファイルでも広範に失敗するなら、証明ロジックやネットワーク障害をより深く掘る必要があります。2種類のリスクを一本のK線に混ぜないでください。

$DUSK について言えば、この引き締めは短期的には成功呼び出しを減らし、旧ツールがしばらく止まる可能性もあります。長期的な価値は、下流での移行後に、証明の故障、バージョンに関する論争、機関の再確認コストが下がるかどうかにかかっています。パーサは買い注文を直接生み出しません。できるのは、各回路が“1枚の身分証”だけを認識するようにすることです。

取引において、私は「できるだけ読めること」をフレンドリーだとは思いません。金融台帳には、合法的な一意性がより必要だと考えています。DYOR！
#dusk $DUSK @Dusk