昨夜、@Dusk のトランザクションモデルについてドキュメントを読み返して、Moonlight と Phoenix が実際にどのように組み合わさっているのかをマッピングしようと、数時間ほどただ試行錯誤していました。
最初は、その違いはきれいに分かれて見えました。Moonlight は、透明で口座ベースの側であり、各口座は公開状態を保持していて、その状態が残高と nonce を記録します。Phoenix はノートベースのシールド側です。ノートは受取人の公開鍵、値 v、そして追加のランダムなスカラー群を中心に構造化されており、ノートは Merkle ツリーの中にインデックスされることで、支払者がノート自体を明かさずに包含を証明できます。支払いにはゼロ知識証明が必要で、さらに nullifier を公開することで、ネットワークが二重支払いを拒否できるようになります。ドキュメントには、ノートの値は 2^{64}-1 によって上限があるとも記載されています。
2 つのモデル間の変換パス（Phoenix のノートへの入金、Moonlight の口座への引き出し）については説明されていますが、その受け渡しの間に成立する厳密なセキュリティ仮定については、どうしても引っかかってしまいました。回路は妥当性を保証すると言われているのですが、単一の不正な変換が、グローバルな nullifier 集合や、スマートコントラクトが依拠する透明な残高に影響し得るのかどうか、明確な記述を見つけられませんでした。
それは私にとって、分散化に関するより広い疑問も投げかけました。もし価値の大半が Phoenix のノートとして保持されるのだとしたら、コントラクトやオラクルが実際に見る透明な口座レイヤーに、どれほどの実務上のガバナンス権限が残るのでしょうか。
現在の回路設計や 2^{64}-1 の値上限は最終的なものと考えられているのでしょうか。それとも、コミュニティがまだ検討・反復している、ノート生成、Merkle ツリーの深さ、そして nullifier の一意性に関する未解決のパラメータが残っているのでしょうか。
証明の理解を深めた方から、何か手がかりをいただけると嬉しいです。
#dusk $DUSK
最初は、その違いはきれいに分かれて見えました。Moonlight は、透明で口座ベースの側であり、各口座は公開状態を保持していて、その状態が残高と nonce を記録します。Phoenix はノートベースのシールド側です。ノートは受取人の公開鍵、値 v、そして追加のランダムなスカラー群を中心に構造化されており、ノートは Merkle ツリーの中にインデックスされることで、支払者がノート自体を明かさずに包含を証明できます。支払いにはゼロ知識証明が必要で、さらに nullifier を公開することで、ネットワークが二重支払いを拒否できるようになります。ドキュメントには、ノートの値は 2^{64}-1 によって上限があるとも記載されています。
2 つのモデル間の変換パス（Phoenix のノートへの入金、Moonlight の口座への引き出し）については説明されていますが、その受け渡しの間に成立する厳密なセキュリティ仮定については、どうしても引っかかってしまいました。回路は妥当性を保証すると言われているのですが、単一の不正な変換が、グローバルな nullifier 集合や、スマートコントラクトが依拠する透明な残高に影響し得るのかどうか、明確な記述を見つけられませんでした。
それは私にとって、分散化に関するより広い疑問も投げかけました。もし価値の大半が Phoenix のノートとして保持されるのだとしたら、コントラクトやオラクルが実際に見る透明な口座レイヤーに、どれほどの実務上のガバナンス権限が残るのでしょうか。
現在の回路設計や 2^{64}-1 の値上限は最終的なものと考えられているのでしょうか。それとも、コミュニティがまだ検討・反復している、ノート生成、Merkle ツリーの深さ、そして nullifier の一意性に関する未解決のパラメータが残っているのでしょうか。
証明の理解を深めた方から、何か手がかりをいただけると嬉しいです。
#dusk $DUSK