#dusk $DUSK

「ホスト関数」というフレーズがDuskのホワイトペーパーで何度も出てきて、私はそれを実装上の詳細として扱い続けていました。ところが実際にパフォーマンスの章を読んでみると、それはその程度のものではなく、より意図的なアーキテクチャ上の判断だったのです。

WASM VMの中でZKを動かす：ホワイトペーパーでは、WASMの実行は複雑なアプリケーションにおいてネイティブコードと比べて45〜255%遅くなり得るという研究が引用されています。オーバーヘッドは、仮想化されたメモリ管理や、サンドボックス環境内での追加的な命令処理に起因します。ハッシュや署名検証のような処理ではそれが厄介です。さらに、毎トランザクションで動くZKの証明検証では、45〜255%遅いことは重大なスループット問題になります。

ホスト関数：Duskは、WASMサンドボックスの外、ホストマシン上でネイティブに実行される一連の関数を公開しています。verify_plonk、verify_groth16_bn254、verify_schnorr、verify_bls、そしてhashです。スマートコントラクトはそれらを直接呼び出し、重い暗号計算はネイティブ速度で実行されます。その結果は、他の計算と同じようにノード間で複製されます。

では、なぜすべてのZKを扱うチェーンがこれをやらないのでしょう。

VMの外へ計算を移すことで、サンドボックスによる保証が弱まります。純粋なWASM実行モデルでは、バグのある、あるいは悪意のあるコントラクトはVM境界内に隔離されます。そこにホスト関数を追加すると、特定の操作に対してネイティブ・レベルのアクセスを公開することになります。そして、ホスト関数層でのバグや誤設定は、サンドボックス化されたコントラクト単体では生み出せないような結果を招き得ます。つまり、隔離と引き換えにスループットを得ているのです。

私は、スピード以上に「エネルギー効率」の議論のほうが興味深いと感じました。ホワイトペーパーでは、ホスト関数をレイテンシーだけでなく、ノードごとのエネルギーコストを下げるための手段として部分的に位置づけています。これはブロックチェーン設計文書としては珍しい切り口です。

一方で、Duskがホスト関数のバージョニングをどう扱うのかについては説明を見かけていません。ホスト関数の挙動を変えることが、合意（コンセンサス）を必要とするプロトコル変更に当たるのか、それとも運用者が実装を個別に更新できるのか、という点です。@Dusk

$DUSK #dusk