子どもが眠りについたのがもう十一時半で、あと半時間はスマホをいじりたくなくて、しばらくDuskの実行層（実行レイヤー）のドキュメントをめくっていました。適当に見てから寝ようと思ったのに、ある細部が引っかかって眠れませんでした。

PiecrustはDuskのスマートコントラクト用の仮想マシンで、WASMベース——これは多くの新しいパブリックチェーンと同じで、特別なところは特にありません。特別なのは、暗号演算をどう扱うかです。ハッシュやゼロ知識証明の検証のような計算量が大きい操作を、WASMバイトコードに丸投げして実行するのではなく、ホスト関数として用意し、基盤となるRustの実装を直接呼び出して計算します。つまり、コントラクトのコードは仮想マシンのサンドボックス内で通常ロジックを走らせる一方で、重い暗号計算にぶつかるとサンドボックスから飛び出してネイティブコードで処理し、計算結果を戻してもらう形です。

この分割は一見すると単なるエンジニアリング上の最適化に見えますが、よく考えると「そうせざるを得ない」ものです。ゼロ知識証明の検証をインタプリタ型の仮想マシンで実行したら、性能の損耗は桁違いになります。特にDuskのようにデフォルトで機密取引のルートを通るチェーンでは、ほぼ毎取引でこの証明検証を通過します。ここが足を引っ張れば、チェーン全体のスループットがそのまま押しつぶされます。最もリソースを食う部分をサンドボックスから外してネイティブコードで走らせることは、本質的に「『コントラクトのチューリング完全性』」と「『プライバシー計算は性能を壊してはならない』」という2つの目標の間に、中間的な解を見つけることです。

引っかかったのはここです。こうしたホスト関数の呼び出しインターフェースは誰が定義するのか？今後拡張はできるのか？もし新しい暗号プリミティブが1種類増えるたびに、仮想マシンの基盤コードを改修しなければならないのだとしたら、開発者が使えるプライバシー用のプリミティブの種類は、ある程度はコアチームのアップデート頻度に首を締められることになります。エコシステムが自由に拡張できる形にはなりません。これは「チューリング完全で、開発者が自由に工夫できる」というパブリックチェーンの物語と、実は少し矛盾している気がします。矛盾は下層に隠れていて、普段は感じにくいだけです。

そう考えると、続けてページをめくる気が失せました。ひとまずメモしておき、あとでチャンスがあればホスト関数がどこまでオープンなのか検証したいと思います。

みなさんはどう思いますか？コアの暗号計算をサンドボックスから切り出してネイティブコードで走らせる、いわゆる「性能優先」の判断——その代償は、見えている以上に大きくなる可能性はありますか？

@Dusk_Foundation #dusk $DUSK