DuskEVMについての要約を十分に読んでいくと、繰り返し出てくるある決まった文言が見つかります。つまり、開発者がSolidityのコントラクトをデプロイすると、Dusk Networkの基盤となるコンセンサスが提供するプライバシーとセキュリティを“自動的に”享受できる、というものです。ですが、私は“自動的に”という言葉を一度立ち止まって見直したいのです。必要以上のことを含んでしまっているからです。

コンセンサスのセキュリティは、確かに移転します。Succinct AttestationはDuskDSを保護し、DuskEVMはその層へと戻って処理を行うため、最終性（ファイナリティ）の保証は設計上そのまま受け継がれます。プライバシーは話がまったく別です。DuskEVMの実際のプライバシー機構はHedgerで、ゼロ知識証明とホモモルフィック暗号を組み合わせたモジュールですが、DuskEVMが最初に発表された時点ではまだ存在していませんでした。パブリックなテストは2025年11月にのみ開始され、公的なテストネット上で動作し、チームはそれを「初期ビルド」であると明示し、問題があればユーザーに報告してほしいと求めていました。アルファ自体も設計上かなり限定的で、シールディング、アンシールディング、プライベートな送金に対応するのみです。そしてDuskの研究者自身が、プライベート送金フローがどのように機能するかを、各ユーザーが通常のEVMアドレスに加えて必要とする別個のHedgerアドレスまで含めて、まさにその通りに説明しています。

この時系列は重要です。DuskEVMの初期のかなり長い期間、そこにデプロイされたコントラクトは、他のどのEVMチェーンのコントラクトと同じくらい“まったく同様に”プライベートではなかった、ということになります。Hedgerがアルファ段階を過ぎて成熟した後、チームが意図的にそれを統合した場合に限り、はじめてプライバシーが付与されます。DuskEVMにおけるプライバシーは、開発者が選んで自分で組み込むオプトイン機能であって、チェーンがプライバシー重視のLayer 1とインフラを共有しているからといって、勝手にバックグラウンドで自動的に現れる性質のものではありません。

私は、それが不誠実なマーケティングだというよりも、ソフトウェアの出荷に先んじて走ってしまっているマーケティングだと言いたいです。これはこの業界ではよくあることです。とはいえ、そもそもプライバシーが理由でDusk Networkに興味を持っているのなら、デフォルトで全コントラクトに最初から組み込まれているものだと決めつける前に、Hedgerが実際にはどの段階にあるのか確認してください。

#dusk $DUSK @Dusk