#dusk $DUSK @Dusk ずっと一つのことが分からなかった：Dusk は独自のネイティブなスマートコントラクト実行環境を持っていて、Rust で書かれたコントラクトを専用に動かす。それに加えてイーサリアム互換の実行層も用意していて、慣れたあの言語でコントラクトを書けるようにしている。二つの環境を同時に保守するのは、自分に保守負担を増やしているようにも感じる。今回は、いったいこの選択が何を狙っているのかを特に解明したかった。\n調べた結果、これが実は、同時に配慮されている二種類のまったく異なる開発者層だというふうに理解できた。ネイティブ側の環境は、直接 Rust を学び、プロトコルの最下層の能力（例えば、その暗号化で隠されたアカウントを直接操作するようなもの）を手に入れたいチーム向けで、性能と柔軟性は高いが、習得のハードルも高い。そもそも市場に出回っているのは、イーサリアム側の言語で書く人より Rust のスマートコントラクトを書く人のほうがずっと少ない。\nイーサリアム互換の層が狙っているのは「既存（ストック）だ」――外の世界にはすでに大量の開発者と大量の既成ツールチェーンがあり、そのエコシステムはイーサリアム側のやり方の周りに組み立てられている。もし Dusk が互換の入口を提供しなければ、この大量の人々は基本的に新しいチェーンのためにツールチェーンを一から学び直すことには消極的で、別のより互換性の高い場所で開発することを選ぶだろう。\n最初は、これは「欲張り（どっちも）で、両方に媚びようとして、結果としてどちらも中途半端になりそう」だと思った。でも公式がこの二つの層に対してどう位置付けているかを読み返したところ、そもそも両者を完全に同等の機能として提供するつもりはないことが分かった。ネイティブ側は、プロトコル級のレベルで、プライバシーや決済能力に深く結びつくようなシナリオのためのもので、イーサリアム互換の側は、外部エコシステムや既成のアプリに素早く接続するためのものだ。こう分担すると、重複して同じものを作っているとは言えず、むしろニーズの違う人それぞれに適した扉を用意しているだけで、同じことを二度やっているわけではない。\nとはいえ、具体的な開発者の分布データは見つからなかった。つまり、現在実際にデプロイされているアプリのうち、ネイティブ側のルートと、イーサリアム互換側のルートがどのくらいの割合かは、現時点では検証できる数字がない。だから言えるのは、このアーキテクチャの設計思想は筋が通っているということだけで、ではその考え方が実際に落ちて、どのルートが本当に使われているのかは、今後の実デプロイされたアプリの数次第だ。