私が最初にDuskEVMを見たとき、明らかなストーリーは「EVM互換性」でした。Solidityの開発者は、馴染みのあるツールを使って作業できるため、新しいネットワークでの開発に伴う摩擦が下がります。

しかし、より面白いのは、トランザクションがEVMの外に出た後に始まる部分です。

DuskEVMは単独で動いているわけではありません。その実行環境は、決済とネットワーク基盤を担う基盤レイヤーであるDuskDSの上に位置しています。この分離は、私たちが問いとして投げるべきことを変えてしまうのだと思います。

「Duskで、Ethereum型のアプリケーションを開発者がどれだけ簡単にデプロイできるのか？」と単に問うのではなく、私はそれらのアプリが、下にあるアーキテクチャから何を引き継ぐのかにこそ関心があります。

馴染みのある実行は役に立ちます。でも、異なる決済モデルにつながった馴染みのある実行は、別の設計空間を生み得ます。

さらに、それがプライバシーによって一段と面白くなります。DuskはHedgerを通じて、秘匿化されたEVMワークフローへ向けて取り組んでいます。そこでは、準同型暗号やゼロ知識証明といった技術が組み合わされています。つまり、開発者体験は見慣れたまま保てる一方で、トランザクションの可視性や決済をめぐる前提は、典型的なパブリックEVM環境とは必ずしも同じではない、ということです。

そこでこそ、私が考えるDuskEVMのストーリーはさらに深くなります。

価値は単に「Solidityを別のチェーンに持ち込む」ことではありません。規制された金融活動のために、特別に設計されたインフラへ、馴染みのあるアプリケーションがアクセスできるようになる可能性があります。そこでは、秘匿性、検証可能性、そして決定論的な決済のすべてが重要になります。

私が異議を唱えたいのは、「EVM互換性は主に採用の近道である」という前提です。

もしかすると、それより有用なのはブリッジとしての役割です。フロントエンドでは馴染みのある実行、そしてその下には別の金融インフラ。

そして、@Dusk wonの本当の試金石は、開発者がコントラクトをデプロイできるかどうかではありません。

それは、開発者がそれらのコントラクトの下に何があるのかを理解したとき、何を作りたいと思うか—その選択にあります。

@Dusk_Foundation $DUSK #dusk