私はゼロ知識証明そのものの外側で、最も示唆に富むAEGISの不具合を見つけました。隣にある値は、完全には制御されていませんでした。

Dusk NetworkのPhoenixの取引経路では、ユーザーは正当なmax_feeにコミットできる一方で、実行は同じセキュリティの物語に組み込まれていない手数料フィールドを消費し得ます。敵対的なガスパラメータによって、返金のインフレーションやオーバーフローを引き起こすことができます。変更可能な返金アドレスが、値を別の先へ振り向ける可能性がありました。

その証明は有効でした。しかし、取引のセマンティクスはそれに十分に結び付いていませんでした。

返金経路が値を作り出したりリダイレクトしたりできる場合、手数料は無害なメタデータではありません。

これは、あらゆるプライバシープロトコルにとって有用な警告です。1つの主張を完璧に証明しても、後で実行が信頼する隣接フィールドは安全になりません。システムは、証明、署名、手数料計算、宛先、返金経路を1つの不変条件に結び付ける必要があります。

AEGISは、gas_limitにgas_priceを掛けた計算の検証（チェック付き乗算）を追加し、その結果が証明されたmax_feeに等しいことを要求しました。Duskはこのチェックを2度行いました。メンプールへの受け入れ時と、VM実行の内部で再度行う時です。また、返金のステルスアドレスも結び付けたため、改ざんすれば取引は無効になります。

2つ目のチェックが、私が特に注目している点です。悪意のあるブロック提案者は、正直なメンプールの前提を守る必要がありません。不変条件がネットワーク境界でしか存在しないなら、コンセンサスはその境界を回避している取引をなおも実行できてしまいます。

これからは、Dusk全体で同じ防御パターンがあるかを監視したいと思います。つまり、受け入れ前の安価な拒否、実行時の権威あるバリデーション、そして、証明の周囲にあるあらゆるフィールドを変異させる回帰テストです。

AEGISは既知の重要なクリティカルパスを塞ぎました。より大きな疑問は、他のDuskのコントラクトにおいて、ある層では「checked（検証済み）」でも、次の層では「trusted（信頼済み）」になっている値がないか、ということです。

暗号は、求められた通りに“まさに何を”証明することもできます。セキュリティは、Duskが完全な主張を求めているかどうかに依存します。

#dusk $DUSK @Dusk