eWASMについて
EWASM
EVMに変わる新しいEthereumの仮想マシン。
ドキュメントはまとめられてるみたい: https://ewasm.readthedocs.io/en/mkdocs/
ParityはWASMで実装済み。
→https://github.com/paritytech/parity-wasm
EOSはWASMでの実装を目指している。
■概要
EVMコードをEVMで動かす
→ eWASM（ETH用のWebAssemblyのサブセット）をeWASM VMで動かすように変えようというプロジェクト。
■WebAssembly（WASM）
WASMはWebブラウザ上で実行できるバイナリのことを意味する。
「Webアプリケーションの高速化」を目的としている。
2015年に発表され、主要ブラウザベンダーが協力して策定している。
ゲームや画像処理などの複雑なブラウザアプリでの活用が期待されている。
■WASMの歴史
JSは動的言語(型が決まっていない)
→コンパイル言語ではなくインタプリタ言語（逐次実行）だから遅い
→asm.jsで静的型付けをして事前コンパイル（AOTコンパイル）できるように
→これによって実行速度自体は高くなった
→Unityなどのゲームに採用される
→ファイルサイズの増大により「通信量の増加」「パーシング（構文解析）の時間増加」という課題が残る
→WASMを用いるとJSのコードでなくバイナリコードを用いるので、ファイルサイズを大幅に削減。これらの課題を解決している
■結局、eWASMって？
"Ethereum flavored WebAssembly"の略で、Ethereumのために作られたWASMのサブセットのこと。
「WASMのサブセット（一部）」なので、WASMをEthereumで使えるように制約を加えたものと考えるのがわかりやすい。
■既存のEVMの悪い点
一言でまとめると独自の仕様を盛り込みすぎて、それがボトルネックになってしまっている。
1. 256bitのスタックアイテム
EVMはスタックマシンという計算モデルが採用されている。（メモリがスタック形式になっている計算モデル）
EVMではスタックアイテムが256bitに設計されているため、EVMを動かす物理CPU（大抵64bit）の命令にシンプルに対応できない。
→その結果、一般的な命令セットよりも複雑になってしまう
→さらにクライアントがEVMの命令をどう実装するかによって計算コストが変わってしまい、gasコストあたりの処理の重さが変わってしまう
2. EVM独自の仕様
EVMはブロックチェーンと疎通するために独自のオペコードがたくさんある。（CALL, CREATE, SSTORE etc...）
→複雑さをさらに増し、汎用言語からのコンパイルを難しくし、Solidityなどの独自言語に頼る必要が出てくる
3. ランタイムでのgas計算
EVMはインタプリタ言語なので、1ステップごとにgasを計算している。
→これも仮想マシンの実行速度を遅くしている。
■eWASMのメリット
1. パフォーマンス向上
WASMは元々機械語に近い速度で動くように設計されている。
gas計算のロジックも改善が入っている。（これは技術仕様を追わないとわからないので後日）
2. WebAssemblyのエコシステム
EVMは自分たちで開発コミュニティを築きメンテナンスをする必要があった
→WASMはApple. Google, MS, Mozillaなどの企業が開発に参加している
3. コントラクト開発にc/c++, go, rustといった言語が使えるようになる
→多くの人がコントラクト開発に参加しやすくなる
■VM Semantics
1. Whenever a contract is loaded from the state it must be checked for the ewasm signature.
If the signature is present, it must be executed as an ewasm contract, otherwise it must be executed as an EVM1 contract.
1. ステートからコントラクトが読み込まれるときはいつでもeWASM署名がチェックされます。
署名が存在する場合、eWASMコントラクトとして実行されます。もしそうでなければEVMコントラクトとして実行されることになります。
2. If there's no native EVM1 support in the client, it can use the EVM Transcompiler to translate the code.
2. クライアントがネイティブEVMのサポートをしていない場合、EVMトランスコンパイルを用いてコードを変換することができます。
3. When deploying an ewasm contract, the bytecode must be verified and annotated by the Sentinel Contract.
3. eWASMコントラクトをデプロイするときは、バイトコードを検証し、Sentinel Contractによって注釈付を行う必要があります。
■Ewasm Contract Interface（ECI）仕様
全てのコントラクトはWASMバイトコードに格納する必要がある
→ トランスコンパイルを行うか、WASMで書くかをする必要がある
・インポート周り
Ethereum Environment Interface（EEI）で指定されたモジュールのみがインポート可能で、他のモジュールは対応していない
・デバッグモード
debugネームスペースからのモジュールを用いて、デバッグを行うことが可能
ただし、これはEEIで指定されていないので、本番VMに残したままデプロイしようとするとコケる
・エクスポート
2つのシンボルをエクスポートする必要がある
memory: EEIが書き込むために利用可能な共有メモリ空間（EEIのモジュールが書き込むメモリスペース）
main: パラメータと結果値のない関数（VMが実行する関数）
■Ethereum Environment Interface（EEI）仕様
EEIとは、eWASMコントラクトがEthereumにアクセスするためのAPIのこと
WASMのモジュールとして実装されていて、eWASMの中でインポートして使われる
例）getBlockHash(), call() etc...
https://github.com/ewasm/design/blob/master/eth_interface.md
■System Contract（https://github.com/ewasm/design/blob/master/system_contracts.md）
コントラクトとして定義されたインターフェイスのこと
VMの外で実装したいロジックをコントラクトの形で定義しておき、VMがCallすることで使う仕組み
→ EVMでいうPrecompiled Contractと同じような仕組みらしい
■Sentinel Contract（https://github.com/ewasm/design/blob/master/sentinel.md）
コントラクトをデプロイするときにVMが呼び出し、3つの処理を行う
→ eWASMとして正しく動くかを検証する
→ gas計量コードを注入する（https://github.com/ewasm/design/blob/master/metering.md）
→ deployer preambleに結果をラッピングする（デプロイ準備OKの印づけ）
■EVM Transcompiler（https://github.com/ewasm/design/blob/master/evm_transcompiler.md）
EVMのバイトコードをeWASMバイトコードにトランスコンパイルする
→ EVMをサポートしていないクライアントの場合のみ、VMが呼び出す
→ トランスコンパイラーを内蔵していることで、クライアントはeWASMだけをサポートしておけば既存のEVMコードのコントラクトも実行できる
https://blockchain.gunosy.io/entry/2018/06/20/155726
-----------------------------------------------------------------------------------------
読むべし
https://ethresear.ch/search?q=eWASM
https://github.com/ewasm/design