私は、Duskが高コストな処理のためにネイティブのホスト関数を使うことについて、ずっと考え続けています。
紙の上ではロジックは単純です。重い計算をWebAssemblyの外に出し、ホスト環境でより効率的に実行して、そのついでにいくつかのオーバーヘッドを減らす。
しかし、実行経路の一部を速くしたからといって、同じ割合で全体の作業負荷が速くなるとは限りません。これは、DuskがEUライセンスの機関とともに金融市場をオンチェーン化しようとする中で、最終的に設計が“紙の上で効率的に見える”だけでなく、実際の負荷の下で動作しなければならないことに関わってきます。私がまだ分からないのは、Duskのホスト関数の設計が、実際の負荷を支配するボトルネックを本当に取り除いているのか、それとも全体の実行時間のうちの小さな割合を占める作業だけを主に高速化しているのかという点です。
注目すべき詳細は、どの操作がWASMの外へ移されるのか、それがどれだけ速くなるのか、そしてそれらの操作が、代表的なDuskのワークロードの中でどれほどの割合を占めるのかです。
このアーキテクチャには改善を期待できる根拠があります。ただしそれは、同種のワークロードで、実際の場で“物質的で再現可能な”利益が得られるのを見ることよりも、弱い証拠です。
私は、あるプリミティブの理論上の高速化そのものよりも、Duskが実際に動かしているワークロードの性能がどれだけ変わるかを重視しています。
要は、Duskが本当のシステムのボトルネックを取り除いたのか、それとも経路の一部を単に前倒しで加速しただけで、全体のパフォーマンスは大きくは動いていないのか、ということです。
私は、ホスト関数による効果を切り分けて示し、ワークロード単位でどれほど重要かを分かるようにする、Dusk固有のベンチマークに注目しています。

#dusk $DUSK @Dusk