Dusk の公式ドキュメントを読んでいて、ある一文を2回読んでようやく意味が分かりました。DuskEVM の実行層は OP Stack アーキテクチャで、sequencer が op-geth を動かして EVM トランザクションを実行し、batcher がトランザクションデータを blob として DuskDS に公開し、proposer がこれらの実行済みバッチへの状態コミットメントを改めて公開する、という仕組みです。要するに DuskEVM は本質的に Layer 2 で、DuskDS（Dusk 自身の L1 決済層）がデータ可用性と最終決済の土台です。
このアーキテクチャの選択はなかなか賢いです。Dusk ネイティブのスマートコントラクト環境は DuskVM で、Piecrust という Rust で書かれた WASM 仮想マシン上で動きます。これは、Rust/WASM をそのまま使いたい人や、プロトコルレベルの資産とゼロ知識の能力を活用したい開発者向けです。一方で DuskEVM は、既存の Solidity ツールチェーンを使いたい、学び直しはしたくないというチーム向け。二足のわらじで、全員に言語を変えさせるわけではありません。Piecrust は最近のバージョンでも memory64 の対応を進めたり、基盤のランタイムを wasmer から wasmtime に置き換えたりしており、より大規模なコントラクトの状態と実行性能に備えているわけです。
本当に考えるべきなのは料金構造です。DuskEVM ではトランザクションに2種類の支払いが必要で、1つ目は EIP-1559 形式の L2 実行費、2つ目はバッチデータを DuskDS に公開するためのデータ可用性（DA）費用です。つまり、DuskEVM の実際のスループットとコストは、最終的には DuskDS という L1 のデータ可用性容量に首を絞められます。実行層（L2）がどれだけ速くても、基盤の決済層が詰まっていれば、上がっていけません。これは大部分の「L2 がイーサリアムを DA として使う」パブリックチェーンと本質的に同じで、違いはイーサリアムを Dusk 自身の L1 に置き換えただけです。
DuskEVM にコントラクトをデプロイしようとしている開発者にとって、このアーキテクチャの細部は無関係な背景知識ではありません。Gas コストモデルにおいて、DA 費用が実行費よりも大きな支出になり得るかどうかを直接左右し、特に高頻度かつ大量データを扱う金融アプリケーションでは重要になります。
@Dusk $DUSK #dusk
このアーキテクチャの選択はなかなか賢いです。Dusk ネイティブのスマートコントラクト環境は DuskVM で、Piecrust という Rust で書かれた WASM 仮想マシン上で動きます。これは、Rust/WASM をそのまま使いたい人や、プロトコルレベルの資産とゼロ知識の能力を活用したい開発者向けです。一方で DuskEVM は、既存の Solidity ツールチェーンを使いたい、学び直しはしたくないというチーム向け。二足のわらじで、全員に言語を変えさせるわけではありません。Piecrust は最近のバージョンでも memory64 の対応を進めたり、基盤のランタイムを wasmer から wasmtime に置き換えたりしており、より大規模なコントラクトの状態と実行性能に備えているわけです。
本当に考えるべきなのは料金構造です。DuskEVM ではトランザクションに2種類の支払いが必要で、1つ目は EIP-1559 形式の L2 実行費、2つ目はバッチデータを DuskDS に公開するためのデータ可用性（DA）費用です。つまり、DuskEVM の実際のスループットとコストは、最終的には DuskDS という L1 のデータ可用性容量に首を絞められます。実行層（L2）がどれだけ速くても、基盤の決済層が詰まっていれば、上がっていけません。これは大部分の「L2 がイーサリアムを DA として使う」パブリックチェーンと本質的に同じで、違いはイーサリアムを Dusk 自身の L1 に置き換えただけです。
DuskEVM にコントラクトをデプロイしようとしている開発者にとって、このアーキテクチャの細部は無関係な背景知識ではありません。Gas コストモデルにおいて、DA 費用が実行費よりも大きな支出になり得るかどうかを直接左右し、特に高頻度かつ大量データを扱う金融アプリケーションでは重要になります。
@Dusk $DUSK #dusk