疑問を抱えたまま座っている――Dusk のドキュメントは、ハードな数値で直接は答えていない。2つの異なる Phoenix ノートが、同じ nullifier を生成し得るのだろうか。
私が正確に確認できたこと：Dusk 自身の Phoenix リポジトリでは、nullifier は外部の観測者が、それがどのノートに由来するかを結び付けられないように計算されると明記されています。各ノートは、ノートの Merkle 木の葉にハッシュ化され、1つのノートを支払う（spendingする）と、その特定のノートのデータに紐づいた決定論的な nullifier 値が生成されます。
この下で行われるハッシング――Dusk の Merkle 木の構造と、より広範な暗号学的操作全般において――は Poseidon で動作します。これは Dusk の自チームが設計した、SNARK に適したハッシュ関数であり、ゼロ知識回路内での衝突耐性ハッシングのために、まさにその目的で用意されたものです。汎用的な既製品ハッシュを流用したものではありません。まさに、この種の ZK ネイティブなコミットメント作業のために作られています。
ただし「衝突耐性」は「衝突防止」と同義ではありません。Poseidon を含む任意のハッシュ関数には、2つの異なる入力が同じ出力を生む理論上の（天文学的に小さい）確率が伴います。これは Dusk 固有の弱点ではなく、ハッシングという仕組みそのものの性質です。
Dusk 自身の資料の中で私が見つけられていないのは、彼らの Poseidon パラメータそのものに特化した衝突確率の公開された数値、あるいは、一般に Poseidon が備えるセキュリティ特性に基づく以上の専用の衝突テストに関するドキュメントです。
もし、Dusk の実装にこの特性を対象にした監査レポートを見た方がいれば、それを公開情報に対して比較したいです。
#dusk $DUSK @Dusk
私が正確に確認できたこと：Dusk 自身の Phoenix リポジトリでは、nullifier は外部の観測者が、それがどのノートに由来するかを結び付けられないように計算されると明記されています。各ノートは、ノートの Merkle 木の葉にハッシュ化され、1つのノートを支払う（spendingする）と、その特定のノートのデータに紐づいた決定論的な nullifier 値が生成されます。
この下で行われるハッシング――Dusk の Merkle 木の構造と、より広範な暗号学的操作全般において――は Poseidon で動作します。これは Dusk の自チームが設計した、SNARK に適したハッシュ関数であり、ゼロ知識回路内での衝突耐性ハッシングのために、まさにその目的で用意されたものです。汎用的な既製品ハッシュを流用したものではありません。まさに、この種の ZK ネイティブなコミットメント作業のために作られています。
ただし「衝突耐性」は「衝突防止」と同義ではありません。Poseidon を含む任意のハッシュ関数には、2つの異なる入力が同じ出力を生む理論上の（天文学的に小さい）確率が伴います。これは Dusk 固有の弱点ではなく、ハッシングという仕組みそのものの性質です。
Dusk 自身の資料の中で私が見つけられていないのは、彼らの Poseidon パラメータそのものに特化した衝突確率の公開された数値、あるいは、一般に Poseidon が備えるセキュリティ特性に基づく以上の専用の衝突テストに関するドキュメントです。
もし、Dusk の実装にこの特性を対象にした監査レポートを見た方がいれば、それを公開情報に対して比較したいです。
#dusk $DUSK @Dusk