今日私の注意を引いたのは、Duskのドキュメントを読んでいる最中に、ほとんど見落としそうになっていたある点でした。それは、Boreasのアップグレードに伴うPhoenixトランザクションの引退です。
最初は、これは通常のプロトコル保守だと思いました。しかしよく見ると、金融ユースケースに焦点を当てたネットワークにとって、トランザクション・モデルの変更がどれほど重要かが分かりました。
Duskは、価値を移すさまざまな方法を支援しており、公開アカウントベースの送金にはMoonlight、秘匿送金にはPhoenixがあります。Boreasは、その設計を見直し、ネットワークレベルでPhoenixトランザクションを廃止することで変更しています。
それで疑問に思いました。Duskにとってプライバシーがこれほど重要なら、単に改善するのではなく、ネイティブの秘匿トランザクション・モデルをなぜ取り除くのか？
答えは、Duskのアーキテクチャがどのように進化しているかに関係しているようです。単一の汎用的なプライベート・トランザクション型に頼るのではなく、ドキュメントは現在、機密アセットのフロー、ゼロ知識機能、選択的開示、そしてDuskEVM上のHedgerといった、アプリケーション・レベルのプライバシー・ツールを強調しています。
この変化は興味深いです。というのも、ブロックチェーンの設計について、より大きな問いを提起するからです。
プライバシーは、すべての基本トランザクションに組み込むべきでしょうか。それとも、必要としているプライバシー機構をアプリケーション側が選ぶべきでしょうか？
後者のアプローチなら、開発者はより柔軟に対応できる一方で、アプリケーション設計により大きな責任が生じます。
私はいまも、Duskの長期的なプライバシー・アーキテクチャにとってそれが何を意味するのかを理解しようとしています。もしプライバシーがさらにアプリケーション固有の仕組みに寄っていくのなら、開発者は、システムを不必要に複雑にせずに、それらのツールを正しく使うにはどうすればいいのでしょう？
私にとっては、単にBoreasをプロトコルのアップグレードだと呼ぶ以上に、こちらのほうが関心深いです。
それは、Duskがまだ難しい問題に取り組んでいることを示しています。つまり、ネットワークを使いづらくしないまま、プライバシーを実用的なものにするにはどうすればよいのか、という問題です。
どちらのアプローチのほうが理にかなっていると思いますか？ #dusk $DUSK @Dusk