DuskEVMが本番稼働すると何が起きるのか？誰も対応を地図に描かなかったプライバシースタック

私がEVM上で準拠したブロック（債券）取引アプリケーションを構築するのに必要なことを考えていた時期がありました。

最初はロジックは単純に見えました。

スマートコントラクトをデプロイする。決済ロジックはオンチェーンで扱う。センシティブな部分はオフチェーンのコンプライアンスレイヤーに接続する。

しかし問題に気づきました。標準的なEVMコントラクトのあらゆる関数呼び出しは、公開されたステート上で動作します。取引相手のポジション、取引規模、担保額—それらすべてが、実行中にネットワーク上のあらゆるノードから見えるのです。計算をオフチェーンへ移しても、信頼の前提を置き換えるだけで、それを取り除くわけではありません。

そのとき私は、DuskEVMとHedgerが@Dusk どんなものを構築しているのかを、真剣に調べ始めました。

Hedgerは、EVM互換レイヤーの下にあるプライバシーモジュールです。準同型暗号を用いて、スマートコントラクトの実行内で暗号化されたステートを処理します。関数呼び出しへの入力は、計算の間ずっと暗号化されたままです。ネットワークは、基になるデータを一切見ずに、出力に対するZK証明を検証します。

私が思い描いていた債券取引のシナリオでは、これはアーキテクチャを大きく変えます。

決済コントラクトは、実行中に基礎となるポジションデータを公開せずに、コンプライアンス検証コントラクトを呼び出せます。コンプライアンス確認が実行されます。決済が実行されます。取引の詳細を、取引相手は誰も見ません。規制当局はZKで検証された監査証跡を受け取ります。

これが、機密EVMと、プライバシーを後付けした標準EVMの実務上の違いです。

私が本当に不確かに思っているのは、実際の取引量における性能です。実行時の準同型暗号は、標準のEVMチェーンには存在しない計算オーバーヘッドを追加します。DuskEVMが狙っている取引タイプに対して、レイテンシーのプロファイルが機能するかどうかは、はっきりした答えを持てていません。

DuskEVMは、開発者が機密性のある金融アプリを作る方法を変えるのでしょうか？

$DUSK #dusk