DuskEVMはソリディティのコントラクトをデフォルトでプライベートにするのか？
DuskEVMは、ある簡単な前提を生み出します。すなわち、アプリケーションがDusk上で動作していれば、自動的にDuskのプライバシーモデルを継承するはずだ、というものです。

しかし、アーキテクチャはそれよりも正確なことを述べています。

DuskEVMはOP StackベースのEVM実行環境です。そこでは、Solidityコントラクトが馴染みのあるEthereumの開発ツールで実行されます。一方、バッチやステートのコミットはDuskDSを通じて決済され、DuskDSがコンセンサス、決定的なファイナリティ、データ可用性を提供します。

この分離が重要なのは、実行の互換性とプライバシー能力が同じ保証ではないからです。

Dusk自身のドキュメントでは、DuskVMはL1資産への直接アクセス、トランザクションモデル、プライバシーまたはゼロ知識能力を必要とするコントラクトのための道だと位置づけています。これに対してDuskEVMは、まず別の課題を解決します。つまり、EVM同等の実行と開発者の互換性です。プライバシー志向のワークフローは、より広いDuskのスタックに接続できますが、それでも最終的には、アプリケーションがどのように設計されているかに依存します。

したがって、有用な問いは「イーサリアムの開発者はDuskにデプロイできるのか？」ではありません。できます。

難しい問いは次のとおりです。EVMレイヤーから得られる保証は何で、どの保証はDuskDSまたはDuskネイティブのプリミティブから意図的に組み立てる必要があるのか？

これは、メンタルモデルを変えます。Duskは単にEVMの周りにプライバシーを包むだけではありません。実行、決済、プライバシー対応インフラを分離し、開発者がそれぞれの保証がどこから来るのかを選べるようにしているのです。

規制のある金融分野では、このモジュール性は強力です。しかし同時に、アーキテクチャ選択がコンプライアンスと機密性のモデルの一部にもなってしまいます。

@Dusk_Foundation $DUSK #dusk $HEMI $ACE