PhoenixとMoonlightが同時に存在し、あるプライバシーチェーンには隠さない部分の“口”が残っている。私はかなり醒めていると思います

プライバシー系のプロジェクトをやっている人は極端に走りがちです。つまり、すべてを隠し切って「絶対的なプライバシー」をうたうか、手間を省いてそのままプライバシーを捨てて効率を取るか。ここ2年で、プライバシーを掲げるプロジェクトがこの二択で最後は行き詰まる例を少なからず見てきました。監査や規制にはそもそも触れられないか、プライバシー機能が実質的に形骸化してしまうか。私は$DUSK のドキュメントを読んで、その設計が極端に走っていないことに気づきました。PhoenixはUTXOモデルで、転送の秘匿（シールドトランザクション）を行い、残高と取引の関係を両方とも覆い隠します。Moonlightはアカウントモデルで、公開ルートを通り、残高と転送はいずれも明けて見えるようにしています。2つの経路が並存していて、どちらもDUSKを転送でき、gasも支払え、スマートコントラクト実行の入口にもなれる。どちらを使うかは各自で選べます。

最初はこれが妥協だと思いました。でもあとで分かってきたのは、これは結局「逃げ道」を残しているということです。機関はコンプライアンスに従う必要があり、監査や追跡も求められるので、すべての資金の流れをブラックボックス化することは不可能です。規制のサンドボックスで最初にやることは、お金がどこへ行ったかを見えるようにすることです。一般のユーザーはプライバシーを望み、毎回の送金が丸裸にされるのは嫌です。1つのモデルで2つの要求を無理に満たそうとすると、たいていはどちら側にも好かれません。これは、家を建てて前門と裏口を残すのと同じ理屈です。前門は戸籍を確認しに来る人が通り、裏口は近所に見られたくない人が通る。家は同じ建物で、どの扉が余計だとは誰も思いません。

私の@Dusk のような設計に対する印象は、「自分はすべての人の要求は解決できない」と認めたうえで、万能な解決策を無理にこしらえるよりも、むしろ正直だということです。技術の世界の最後は、往々にして誰の理想がより純粋かではなく、まず現実の骨を自分が先にかじり切る覚悟があるかどうかで決まります。#dusk