$DUSK @Dusk #dusk
以前は「EVM互換」と言えば、ただEVMを動かしてそれで終わり、という意味だと思っていました。
Duskは違います。
DuskVMが実際に何かを調べました。DuskVMはWasmtimeベースで、DuskのL1上でRust/WASMのコントラクトを直接実行します。これはDuskEVMとは完全に別物です。つまりEVMに後付けされた互換レイヤーではなく、並んで動く2つ目の独立した実行環境なんです。
なるほど。
じゃあ、EVM対応だけを提供するのではなく、なぜわざわざ別のVMを丸ごと作ったのでしょう?
さらに掘り下げました。DuskVMは、L1アセットへの直接アクセスが必要なコントラクト、Duskのネイティブなトランザクションモデル、プライバシー、あるいはゼロ知識(ZK)機能を必要とするコントラクトのために存在します。EVMの実行モデルは、それらをネイティブに公開するようには設計されていなかったからです。Piecrust(その下で動くエンジン)は、前身よりおよそ10倍高速で、ZKに適したホスト関数を備えています。PLONK、Groth16、BLSが、ランタイムに直接組み込まれているんです。
代わりに、DuskEVMがカバーする範囲も確認しました。EVMの完全な同等性、標準ツールチェーン、DuskDS(DuskDSを介した決済)まで。Dusk EVMは、プライバシーにネイティブなプリミティブを必要とせずに、馴染みのあるSolidityのワークフローで開発したい開発者向けのレイヤーです。
つまり、「EVMの代わりにネイティブVM」というのは、EVMを拒否しているわけではないんです。Duskがしているのは、プライバシーとZKネイティブなコントラクトを、それらを効率よく扱うようには作られていなかった実行モデルに通すことを拒んでいる、ということです。
2つの別々の実行環境を動かすことで、Duskはより強力になるのか。それとも、重複する役割を持つ2つのシステムに開発者の注意が分散されるだけなのか?
#dusk $DUSK