プライバシーチェーンを十分長く見てきたので、実際の摩擦が「金額を隠すこと」だけではないと分かっています。チェーンがEVMの互換性を追い始めたときに何が起きるか、その部分です。多くのプロジェクトはそれを純粋なプラス――より多くの開発者、馴染みのあるウォレット、既存のツール――と捉えています。しかし、その利便性がどれほど早くプライバシー設計そのものを形作り始めるのかを私は見てきました。

Duskが興味深いのは、2つのモデルを無理に一体化させられるふりをしていない点です。DuskDSは、ネイティブのシールド転送にはPhoenixのUTXOアプローチを維持しています。ノート、nullifier、実際にグラフを秘匿するゼロ知識証明です。一方EVM側では、彼らはHedgerを組み立てています。値を隠すための同型暗号と、計算がちゃんと成立していることを示すための証明です。公式ドキュメントが驚くほど正直なのは、その制限についてで――EVMのアカウントモデルでは、Phoenixが持つのと同じ匿名性セットを提供できない、と明確に述べています。

この正直さは稀です。ほとんどのチームはトレードオフを紙の上で覆い隠します。Solidity、MetaMask、そしてその全スタックが欲しいために、トランザクションの完全なグラフプライバシーは失われることを受け入れ、暗号化された残高や選択的開示で取り戻そうとします。問題は、プライバシーの基準が両方の実行環境にまたがって維持されるのか、それとも、どちらかがこっそり弱い兄弟になってしまうのかです。

まだ確信はありません。「プライバシーを保つEVM」といった主張をしているのに、結局は数字だけを隠して、アドレスややり取りのパターンは公開されたまま、というものを見すぎました。難しいのは、入力を漏らさずに結果が正しいことを証明することです。Phoenixはそのやり方を一つ示しています。Hedgerは別の方法です。どちらも、あらゆるサイクルの後に必ず現れる同じ静かな問題――チェーンを誰にとっても便利にし始めたとき、どれくらいプライバシーが残るのか――に答えなければなりません。@Dusk #dusk $DUSK