イスラマバードの自宅ノートPCで、サイドプロジェクトのために重いハッシュ処理を行う小さなPythonスクリプトを動かしています。あるとき、それをサンドボックス化された環境に移せば、ロジックが変わらないなら同じくらい速く動くだろうと思って試したんですが、実際には明らかに遅くなりました。そしてDuskのPiecrust VMについて調べるまで、技術的にどうしてそうなるのかを本当のところ理解できていませんでした。
私は、WASM仮想マシン内でのスマートコントラクトの実行は、ネイティブとほぼ同等の速度で動くと考えていました。WASMは通常、ニアネイティブな性能として売り出されているからです。
しかし、暗号処理に関してはそれは正確ではありません。ホワイトペーパーに引用されている調査によると、WASMの実行は複雑なアプリケーションにおいてネイティブコードより45〜255%遅くなる可能性があります。主な要因は、サンドボックス内での仮想化メモリ管理と、追加の命令処理です。
Piecrustがまさにそういう理由で、WASMサンドボックスの中ではZK証明の検証、ハッシュ、署名チェックのような処理を一切実行しないのはそのためです。代わりにホスト関数を公開します。ハッシュ、verify_plonk、verify_groth16_bn254、verify_schnorr、verify_blsのような処理については、ホストから直接ネイティブ呼び出しを行います。コントラクトは高コストな暗号処理をネイティブコードに委ねて、そこからWASM側に戻って残りの処理を行います。これは回避策ではなく、意図したアーキテクチャ上の分割です。
ホワイトペーパーが直接認めているのは、Duskがこの構成による実際の電力削減量をまだ定量化できていないということです。したがって、Dusk自身が公表していない以上、私は本当の効率数をあなたに提示できません。
DUSKにとって本当の試験は、このホスト関数方式がメインネット上でコントラクトの複雑さが増していくにつれても、維持され続けるかどうかです。
Piecrustのホスト関数呼び出しを、純粋なWASM実行と比べてベンチマークした人はいますか?
@Dusk #dusk $DUSK
私は、WASM仮想マシン内でのスマートコントラクトの実行は、ネイティブとほぼ同等の速度で動くと考えていました。WASMは通常、ニアネイティブな性能として売り出されているからです。
しかし、暗号処理に関してはそれは正確ではありません。ホワイトペーパーに引用されている調査によると、WASMの実行は複雑なアプリケーションにおいてネイティブコードより45〜255%遅くなる可能性があります。主な要因は、サンドボックス内での仮想化メモリ管理と、追加の命令処理です。
Piecrustがまさにそういう理由で、WASMサンドボックスの中ではZK証明の検証、ハッシュ、署名チェックのような処理を一切実行しないのはそのためです。代わりにホスト関数を公開します。ハッシュ、verify_plonk、verify_groth16_bn254、verify_schnorr、verify_blsのような処理については、ホストから直接ネイティブ呼び出しを行います。コントラクトは高コストな暗号処理をネイティブコードに委ねて、そこからWASM側に戻って残りの処理を行います。これは回避策ではなく、意図したアーキテクチャ上の分割です。
ホワイトペーパーが直接認めているのは、Duskがこの構成による実際の電力削減量をまだ定量化できていないということです。したがって、Dusk自身が公表していない以上、私は本当の効率数をあなたに提示できません。
DUSKにとって本当の試験は、このホスト関数方式がメインネット上でコントラクトの複雑さが増していくにつれても、維持され続けるかどうかです。
Piecrustのホスト関数呼び出しを、純粋なWASM実行と比べてベンチマークした人はいますか?
@Dusk #dusk $DUSK
