パブリック・ブロックチェーンは、金融市場にとって気まずい状況を生み出します。透明性は有用ですが、透明性が行き過ぎると取引する人物の戦略が露わになってしまうからです。
注文板(オーダーブック)を考えてみてください。
すべての注文、ポジション、残高が公に見える場合、市場参加者は取引が完了する前に、取引意図を推測できてしまう可能性があります。金融商品によっては、それが単なる些細な不便ではありません。実際に執行の品質に直接影響します。
そのため、私が「一般的な“プライベート・ブロックチェーン”」という言い方よりも、Duskの秘密(コンフィデンシャル)なEVMワークフローのアプローチのほうをより興味深いと感じる理由があります。
Hedgerは、同型暗号とゼロ知識証明を用いて、EVM環境内でのプライバシーをサポートするよう設計されています。考えられる応用例のひとつが機密の注文板(オーダーブック)活動です。つまり、市場がオンチェーンへ移行しただけでセンシティブな情報が完全に公開される必要はありません。
経済的な問いは、それが市場設計をどう変えるのか、です。
金融アプリケーションが、取引が必要なルールに従っていることを証明しつつ、センシティブ情報を保持できるなら、開発者にはもうひとつの設計選択肢が生まれます。すべてを公開状態に置くか、ワークフロー全体をオフチェーンへ移すかという二択に、もはや縛られなくてよくなるのです。
私は進歩を、実際の市場のメカニクスで測るべきだと思います:
• 処理された機密トランザクションの数。
• プライバシーを保護する実行を使うアプリケーションの数。
• テスト取引ではなく、金融資産を含む活動の増加。
これらは、言及回数を数えるよりも有用です。
もちろん、明白な限界もあります。暗号によるプライバシーは、自動的に機能する市場を生み出すわけではありません。流動性、法的な構造、カウンターパーティ、保管(カストディ)、そしてプロダクト設計は依然として重要です。
しかし、注文板の問題は現実です。
もしDuskが、権限のある監督に対しては見えないわけではないまま、センシティブな金融活動をプログラム可能にできるなら、単に「ブロックチェーンにはプライバシーが必要だ」と言うよりも、はるかに具体的な提案になります。#dusk $DUSK @Dusk
注文板(オーダーブック)を考えてみてください。
すべての注文、ポジション、残高が公に見える場合、市場参加者は取引が完了する前に、取引意図を推測できてしまう可能性があります。金融商品によっては、それが単なる些細な不便ではありません。実際に執行の品質に直接影響します。
そのため、私が「一般的な“プライベート・ブロックチェーン”」という言い方よりも、Duskの秘密(コンフィデンシャル)なEVMワークフローのアプローチのほうをより興味深いと感じる理由があります。
Hedgerは、同型暗号とゼロ知識証明を用いて、EVM環境内でのプライバシーをサポートするよう設計されています。考えられる応用例のひとつが機密の注文板(オーダーブック)活動です。つまり、市場がオンチェーンへ移行しただけでセンシティブな情報が完全に公開される必要はありません。
経済的な問いは、それが市場設計をどう変えるのか、です。
金融アプリケーションが、取引が必要なルールに従っていることを証明しつつ、センシティブ情報を保持できるなら、開発者にはもうひとつの設計選択肢が生まれます。すべてを公開状態に置くか、ワークフロー全体をオフチェーンへ移すかという二択に、もはや縛られなくてよくなるのです。
私は進歩を、実際の市場のメカニクスで測るべきだと思います:
• 処理された機密トランザクションの数。
• プライバシーを保護する実行を使うアプリケーションの数。
• テスト取引ではなく、金融資産を含む活動の増加。
これらは、言及回数を数えるよりも有用です。
もちろん、明白な限界もあります。暗号によるプライバシーは、自動的に機能する市場を生み出すわけではありません。流動性、法的な構造、カウンターパーティ、保管(カストディ)、そしてプロダクト設計は依然として重要です。
しかし、注文板の問題は現実です。
もしDuskが、権限のある監督に対しては見えないわけではないまま、センシティブな金融活動をプログラム可能にできるなら、単に「ブロックチェーンにはプライバシーが必要だ」と言うよりも、はるかに具体的な提案になります。#dusk $DUSK @Dusk