#dusk $DUSK @Dusk 私の弟のワカスが、ダスクのプライバシー設計について考え直させるような質問をしてきたんだ。ユーザーが公開する情報の量を選べるなら、開発は難しくならないのか?
率直に言って、その質問が明らかにしたことには驚かされた。根本的な問題は、隠された取引そのものではない。問題は、開発者がパブリックな台帳をアプリケーション状態の完全な情報源として扱えないことだ。
この前提は、インフラ層のすぐそこで重要になる。ウォレット、インデクサー、そして金融システムは、通常は発見・復旧・会計のために使っている情報が、公には利用できないケースを考慮しなければならない。
私の関心を引いたのは、その一段上で起きることだ。開発者は、取引レベルの詳細を本当に必要とする機能と、それなしで動作できる機能を区別しなければならない。
最大限のデータ可視性を前提に作って後からプライバシーを追加するのではなく、アプリケーションはプライバシーを最初から織り込んだ形でデータ依存関係を定義する必要がある。私がダスクで最も興味深いと感じるのは、そのアーキテクチャ上のトレードオフだ。プライバシーは、デフォルトで金融ソフトウェアが把握できることを変え、ひいてはそのソフトウェアがどう設計されるべきかを変える。
もし、開発の単純さを少し犠牲にして、プライバシーが初日から土台の前提として組み込まれたアプリケーションモデルを選ぶなら、どうする? 🤔
率直に言って、その質問が明らかにしたことには驚かされた。根本的な問題は、隠された取引そのものではない。問題は、開発者がパブリックな台帳をアプリケーション状態の完全な情報源として扱えないことだ。
この前提は、インフラ層のすぐそこで重要になる。ウォレット、インデクサー、そして金融システムは、通常は発見・復旧・会計のために使っている情報が、公には利用できないケースを考慮しなければならない。
私の関心を引いたのは、その一段上で起きることだ。開発者は、取引レベルの詳細を本当に必要とする機能と、それなしで動作できる機能を区別しなければならない。
最大限のデータ可視性を前提に作って後からプライバシーを追加するのではなく、アプリケーションはプライバシーを最初から織り込んだ形でデータ依存関係を定義する必要がある。私がダスクで最も興味深いと感じるのは、そのアーキテクチャ上のトレードオフだ。プライバシーは、デフォルトで金融ソフトウェアが把握できることを変え、ひいてはそのソフトウェアがどう設計されるべきかを変える。
もし、開発の単純さを少し犠牲にして、プライバシーが初日から土台の前提として組み込まれたアプリケーションモデルを選ぶなら、どうする? 🤔