Piecrustの価値は「WASM対応」だけではない
「WASM対応」をPiecrustの価値のすべてだと捉えるのは、車を理解して「車輪を載せられる」と言っているのに少し似ています。ホワイトペーパーとDusk公式のアーキテクチャ記事を照合すると、境界は主に2つあります。すなわち、コントラクトは再現可能で隔離された環境で動作する必要があること、そして重い暗号計算は普通のWASMに延々と任せて済ませるわけにはいかないことです。

PiecrustはRustで書かれ、WASM runtimeであるWasmerを中心に構築され、軽量でモジュール化されたコントラクト実行環境を提供します。WASMは移植性、サンドボックス隔離、モジュール化による拡張性をもたらします。piecrustクレートはVMを担い、piecrust-uplinkはコントラクトのコンパイル、デプロイ、テスト、管理を支援します。

しかし、暗号の重労働をすべてWASMに任せているわけではありません。ホワイトペーパーでは、Blake2b、Poseidon、Plonk検証、Groth16 BN254検証、ならびにSchnorr、BLS署名検証をhost functionsに入れ、VMの外部でネイティブ実装が処理します。コントラクトは実行フローを制御し、ネイティブライブラリがコストの高い計算を扱います。この方針には性能面・安全性の境界における利点がありますが、インターフェース、入出力、エラー処理、そして決定性が厳密に固定されていないと、ノードごとに異なる結果が算出され得ます。

@Dusk $DUSK #dusk

データの読み方も慎重に。ホワイトペーパーに引用されている比較によれば、複雑なアプリケーションではWASM実行がネイティブコードより約45%〜255%遅い可能性があります。これは「すべてのWASMコントラクトがこの程度遅い」という意味ではありませんし、Duskメインネットのスループット向上にそのまま換算もできません。さらに、ホワイトペーパーは、host functionsによる消費電力削減の効果について、当時は具体的に量化されていなかったことも認めています。

また、現在の公式ドキュメントでは、Rust/WASMコントラクトを直接実行する環境をDuskVMと呼び、Wasmtimeに基づくものとして説明しています。Piecrustは、ホワイトペーパーや初期のアーキテクチャ資料における命名との対応がより強いようです。ここまで調べて分かったことは、Piecrustの価値は「WASM対応」という一言ではなく、再現可能な実行と高コストな暗号計算を分けて管理する点にある、ということです。