eWASMの疑問点

を参考にした考察です。

この記事の内容はあくまで僕の感想であり、何かしらの調査結果を記述したものではありません。

この記事は今後のeWASMの調査ポイントの提案としての位置付けで記述しております。

気になったところをコメント

■既存のEVMの悪い点

一言でまとめると独自の仕様を盛り込みすぎて、それがボトルネックになってしまっている。

1. 256bitのスタックアイテム

EVMはスタックマシンという計算モデルが採用されている。（メモリがスタック形式になっている計算モデル）

EVMではスタックアイテムが256bitに設計されているため、EVMを動かす物理CPU（大抵64bit）の命令にシンプルに対応できない。

これはkeccak256などのhash値をnativeに扱うための設計ではある

256bitの変数の取り扱いはそれぞれのnode自体がcompile時にnative CPUコードに変換してるわけで、対応できないってことはないと思う。

64bitしか扱わないように設計しなおすとして、HASH値が弱くなってしまうけどそれはどうなんだろう？

→その結果、一般的な命令セットよりも複雑になってしまう

→さらにクライアントがEVMの命令をどう実装するかによって計算コストが変わってしまい、gasコストあたりの処理の重さが変わってしまう

この問題はブラウザがeWASMをどう実装するか問題に変わるだけで解決はできなさそう。

2. EVM独自の仕様

EVMはブロックチェーンと疎通するために独自のオペコードがたくさんある。（CALL, CREATE, SSTORE etc...）

→複雑さをさらに増し、汎用言語からのコンパイルを難しくし、Solidityなどの独自言語に頼る必要が出てくる

3. ランタイムでのgas計算

EVMはインタプリタ言語なので、1ステップごとにgasを計算している。

→これも仮想マシンの実行速度を遅くしている。

■eWASMのメリット

1. パフォーマンス向上

WASMは元々機械語に近い速度で動くように設計されている。

ブラウザ上で動く以上、今のnative compileされている（？go言語はvmの上でうごくのかな）node実装よりも格段に早くなるとは思えない。多分今と同じかほんの少し速い程度と予想している。

gas計算のロジックも改善が入っている。（これは技術仕様を追わないとわからないので後日）

2. WebAssemblyのエコシステム

EVMは自分たちで開発コミュニティを築きメンテナンスをする必要があった

→WASMはApple. Google, MS, Mozillaなどの企業が開発に参加している

これについて、既存の言語を取り込むとその言語仕様の変更の影響を多分に受けてしまい、EVMの開発に専念できないのであえて独自言語で実装したとどこかで見た覚えがある。元々はそういう思想だった。今はどうかはわからない。既存の言語を使うのもいいけど、結局コンパイラもしくはライブラリが必要になる。EOSの現状を見たら大変さはわかるとおもう。

3. コントラクト開発にc/c++, go, rustといった言語が使えるようになる

→多くの人がコントラクト開発に参加しやすくなる

これは同意。でもどうせなら、関数型などのより「安全にかける」言語にした方が良いと思う。

総括

eWASMではEVMの問題点であげている問題についての解決策は１つも出てないと思う

eWASM側で64bit bandのEVMを作ったとしても、それを実行するためにはtransactionの処理部分から全て対応していかないといけないので、EVMのみではなくnodeを作る必要がある

複数の言語でcontractがかけるかどうかはコンパイラーの問題であり、WASMからEVM opcodeにはコンパイルできないので結局コンパイラ、もしくは中間コードに変換するためのライブラリをeWASMで作る必要がある。（トランスパイラ作ってるのがまさにそれ）

上記のことはなんでわざわざeWASM対応としてやるのか意味がわからない。GCCやgo, Ruby, RUSTなどで素直に作った方が良いと思うが・・？

仮にできたとして、eWASM -> WASM -> Binary -> ブラウザ上のみで動く実行ファイルとなるのだがこれを実行できるnodeも開発していかないといけない(Parityが対応中とのことで。。。うーん？既存nodeもアップデートが必要？）

と考えると、eWASMができたとしてもそれはブラウザの上で動くものではない

共通仕様であるWASMに準拠したVMをnodeが持つことになる。

今までnativeにEVMを実装していたものが、WASM上で動くEVMとなる？

今までは CPU -> (language specific VM) -> EVM だったものがCPU -> (language specific VM) -> WASM -> EVMってなるだけに見えるがこれは違うのだろうか？？

何れにしてもWASMをもっとよく知らないといけないけど、少なくともブラウザの上でnativeにcontractが実行されていくっていうものではなさそう

256bitデータバス扱うCPU作る方が数百万倍早く実行できると思うし、EVMだけでなく、nodeとしてもすごい速いものできそう。

https://qiita.com/kenju/items/3ec95aebd30bc95b862c#whyなぜwebassemblyかによると、「なお、この「早い」ということに関しては、ロードタイムを早くはするが実行時間を早くするわけではありません。」とのこと。