#dusk $DUSK @Dusk 昨日、私は自分の小さな$DUSK のことを眺めていて、以前はほとんど無視していたある点に気づいてしまいました。つまり、Duskは実際にどうやって開発者を惹きつけて維持できるのか、ということです。

その視点で見ると、2つの実行環境がより納得できるものになりました。

DuskEVMは、チームにとっておなじみのSolidity/Ethereumのルートを提供します。これにより、デプロイ、テスト、既存ツールをエコシステムに取り込む際の摩擦が下がります。ですがDuskVMは、Rust/WASMを使いたい、そしてDuskのネイティブ実行環境により近い形で開発したい開発者のための第二の道を作ります。

面白いのは、単に2つの環境を用意することではありません。

それは、進歩（段階的な移行）の可能性です。

チームは、まず自分たちがすでに知っているところから始めて、アプリケーションを動かし、その上で本当に移行する理由ができたときに、特定のワークロードをネイティブ機能へ徐々に寄せていけます。

それはただ「EVMをサポートしています」と言うだけとは違う、開発者の定着（リテンション）メカニズムです。

私の結論はかなりシンプルでした：

互換性は開発者を呼び込みます。能力（Capability）は、彼らが留まる理由を与えます。

そして、これは@Dusk周りで私が注目するものを変えると思います。

以前よりも、生のコントラクトのデプロイ数にはあまり興味がありません。既存のアプリケーションがより活発になるのか、意味のある資産が動くのか、そして時間の経過とともにDuskネイティブの機能を実際に使い始めるのか——そこを見たいです。

加えて、無視したくないリスクもあります。

2つの実行環境が、2つの別々のエコシステムになり得ます。流動性、ユーザー、そして開発者がそれぞれに分断されると、柔軟性は断片化にもっと似たものになってしまいます。

そこで私のDuskに関する仮説（thesis）では、環境間の移行、環境をまたいだ資産の流れ、そして継続的なアプリの活動を追っています。

新しいコントラクトの数を数えるよりも、定着のより良いテストになりそうです。

#dusk $DUSK
@Dusk_Foundation
$Cow
$TUT

2つのVMは定着率を押し上げますか？