Duskのヘッジャー・モジュールが、EVMを壊さずにプライバシーを実現する方法
同型暗号は、先に復号せずにデータを計算できるようにします。
その一文は抽象的に聞こえますが、スマートコントラクトの中で何を意味するのかを考えると具体的になります。
標準的なEVMコントラクトは公開状態(パブリック・ステート)で動作します。
すべての入力、すべての残高、すべての関数呼び出しがネットワークに見えるのです。
ほとんどのDeFiユースケースではそれで問題ありません。
しかし、規制のある金融アプリケーションでは設計上の課題になります。相手方のポジションを機密のまま保持する必要があるためです。
私は特に、dusk_foundationのHedgerモジュールを掘り下げ始めました。なぜなら、このギャップこそが「EVMを金融に使う」問題で最も難しい部分だと感じたからです。
EVM向けのプライバシー手法の多くは、次のどちらかを行います。
取引を完全に隠す(機密性は満たせますが、規制上の監査可能性が壊れます)。
または、計算をオフチェーンに移す(コンプライアンス部門が受け入れない信頼の前提が生まれます)。
Hedgerは別の道を選びます。
同型暗号を使って、EVM実行環境内で機密状態を処理します。コントラクトロジックは暗号化された入力に対して実行されます。ネットワークは基になる値を決して見ることはありません。
しかし、権限を持つ当事者、具体的には適切な復号鍵を持つ規制当局は、取引を監査できます。
ZKレイヤーが検証を担当します。暗号化された入力をネットワークに開示せずに、計算が正しく実行されたことを示す証明を生成します。
この設計は、これまで私が見てきた多くのEVM向けプライバシー提案とは、意味のある点で異なります。
輸送レイヤーだけでなく、実行レベルで見直し可能な機密性。
まだ分かっていないのは、実際の取引量のもとでどれだけ性能が出るかという点です。同型暗号は計算コストが高い。動作する実装と、実際の金融市場が求めるレイテンシ要件を満たすものの間にあるギャップこそが、これまで多くのプライバシー保護型スマートコントラクトシステムがぶつかってきた問題のまさにその場所です。
$DUSK #dusk @Dusk $BTC
同型暗号は、先に復号せずにデータを計算できるようにします。
その一文は抽象的に聞こえますが、スマートコントラクトの中で何を意味するのかを考えると具体的になります。
標準的なEVMコントラクトは公開状態(パブリック・ステート)で動作します。
すべての入力、すべての残高、すべての関数呼び出しがネットワークに見えるのです。
ほとんどのDeFiユースケースではそれで問題ありません。
しかし、規制のある金融アプリケーションでは設計上の課題になります。相手方のポジションを機密のまま保持する必要があるためです。
私は特に、dusk_foundationのHedgerモジュールを掘り下げ始めました。なぜなら、このギャップこそが「EVMを金融に使う」問題で最も難しい部分だと感じたからです。
EVM向けのプライバシー手法の多くは、次のどちらかを行います。
取引を完全に隠す(機密性は満たせますが、規制上の監査可能性が壊れます)。
または、計算をオフチェーンに移す(コンプライアンス部門が受け入れない信頼の前提が生まれます)。
Hedgerは別の道を選びます。
同型暗号を使って、EVM実行環境内で機密状態を処理します。コントラクトロジックは暗号化された入力に対して実行されます。ネットワークは基になる値を決して見ることはありません。
しかし、権限を持つ当事者、具体的には適切な復号鍵を持つ規制当局は、取引を監査できます。
ZKレイヤーが検証を担当します。暗号化された入力をネットワークに開示せずに、計算が正しく実行されたことを示す証明を生成します。
この設計は、これまで私が見てきた多くのEVM向けプライバシー提案とは、意味のある点で異なります。
輸送レイヤーだけでなく、実行レベルで見直し可能な機密性。
まだ分かっていないのは、実際の取引量のもとでどれだけ性能が出るかという点です。同型暗号は計算コストが高い。動作する実装と、実際の金融市場が求めるレイテンシ要件を満たすものの間にあるギャップこそが、これまで多くのプライバシー保護型スマートコントラクトシステムがぶつかってきた問題のまさにその場所です。
$DUSK #dusk @Dusk $BTC
