#dusk $DUSK @Dusk 今週は「Dusk」のPhoenixの取引モデルに関する論文（CitadelのやつでPhoenixについて特定の章がある）を一通り読んだ。最初は、他のUTXOベースのプライバシー方式と本質的には大差ないと思っていたが、読んでみると細部の設計が想像以上に凝っていることに気づいた。
Phoenixでは、各取引の「資産」はUTXOとは呼ばれず、noteという。ネットワークはnote自体を直接保存せず、noteのハッシュ値だけをMerkleツリーの葉ノードに格納する。noteを消費（支払い）する際、ユーザーはtx_proofという名前のゼロ知識証明を提出する。この証明は同時に2つのことを行う。1つ目は、消費対象となるnoteを「無効化」すること（重複して同じお金を2回使われるのを防ぐための一意なnullifierを生成する）。2つ目は、新しく生成されるnoteの合計額が、無効化されたnoteの合計額と一致しており、勝手にお金が増えていないことを証明すること。外部から見えるのは「古いnoteが1つ無効化され、新しいnoteが1つ作成された」という事実だけで、具体的な金額や参加者は外部からは分からない。
本当に巧いと感じたのは鍵分割だ。noteを1つ消費するにはSecret Keyが必要で、その鍵はnoteの所有者だけが知っている。しかし、監査者や規制当局に「どのnoteを持っているか」や「暗号化された金額がいくらか」を見せたいだけであって、資金を実際に動かせる権限までは渡す必要がない場合は、View Keyを個別に共有すればよい。つまり「見える」と「動かせる」はまったく独立した2つの鍵であり、この分割自体が「選択的開示」という言葉に対して、単なるマーケティング文句ではなく暗号学的な実装基盤を与えている。
加えてTransferコントラクトには見落とされがちな細部がある。複数の小額noteを自動的に結合（combine）して、Merkleツリーの葉ノードが際限なく膨張してネットワーク性能を押し下げるのを防ぐのだ。この「基盤の台帳が自分でゴミ回収を行う」ような設計から、チームが初期の段階で、長期運用におけるストレージや証明コストの増大に対して、工学的な予測をしていたことが分かる。木が伸びきって動かなくなってから対処するのではなく、最初から見越していたわけだ。
開発者にとって、この仕組みは、Phoenix上でアプリを構築するならView Keyの配布と管理が、避けて通れないプロダクト設計上の課題になることを意味する。これは「誰が、どの条件で、ユーザーの保有状況を見られるか」を決定する工程であり、ここがうまく設計されていないと「プライバシー」という2文字はウォレットUI上のスイッチに過ぎず、実際の制約としては機能しない。