夕暮れが、ネイティブ・チェーンに加えてEVM互換レイヤーを展開しつつある。そして説明されているロジックは至ってシンプルだ。つまり、開発者の参入障壁を下げ、既存のSolidity

ツールが、すべてのビルダーに新しいスタックを最初から学ばせる代わりに、

そのまま組み込めるようにする。
一見するとこれが最も明白な選択だ。EVM

への馴染みが、暗号領域で最大の開発者プールであり、

それを半分も満たさずに拒むことこそが、有望なL1を永遠にニッチなままにしてしまう方法だからだ。

ただ、私が引っかかっているのは、より絞られた問いです。

EVM互換レイヤーは、Duskの実際のプライバシー保証を継承するのか？
それとも、EVMのデフォルトの透明性を継承し、Duskのプライバシーレイヤーの隣に“並んで”存在するだけで、互いに干渉せずに据え置かれるのか？

これらは同じことではない。そして、

ほとんどのL1であればEVM互換性を追加する際に重要になりにくい

ところよりも、ここでの違いの方がはるかに重要です。

なぜなら、プライバシーとコンプライアンスを意識した開示こそが、Duskが存在する唯一の理由だからです。

もしEVMレイヤー上にデプロイされたコントラクトが

他のどのEVMコントラクトと同様に振る舞う——公開状態、公開

カラーデータ、標準的な透明性モデル——のであれば、「DuskはEVMをサポートしている」と「DuskのプライバシーモデルがEVMにも拡張される」は

別々の主張であり、マーケティングだけが両方同時に言いがちです。

このトレードオフの正直なところは、

EVM互換性とネイティブな機密計算とは、構造的にある程度相反するということです。

EVMの実行モデルは、選択的開示を前提に作られていません。
Duskのコアとなる価値提案は、それを明確に念頭に置いて構築されました。

両者をうまく橋渡しする——馴染みのある

ツールを使えるまま、なおかつ機密

トランザクションや、コンプライアンスを意識したスマートコントラクトを手に入れる——のは、
本当に難しい統合問題であって、チェックボックスではありません。

Duskがそれを見事に解決している可能性はあります。

しかし、「EVM互換」とは静かに「チェーンの透明な側に対してだけEVM互換」という意味で、

実際のプライバシーを守るコントラクトは
ネイティブのスタックであるXSCと、
EVM互換性が取り除くはずだった学習コストが
それでも必要、ということもあり得ます。

@Dusk #dusk $DUSK