イーサリアムバーチャルマシン(EVM)の欠陥と欠点(後)

2018-10-16

本記事は全3回イーサリアムバーチャルマシン(EVM)の欠陥と欠点の第3回です。

第1回、第2回はこちら。
イーサリアムバーチャルマシン(EVM)の欠陥と欠点(前)

 

標準ライブラリの欠如

あなたがSolidityスマートコントラクトを開発したことがあるなら、おそらく問題として遭遇した最初のものがこれでしょう。まったく標準ライブラリがありません。

2つの文字列が等しいかどうかを調べるには、strcmpやmemcmpなどがないので、自分でコードを書くか、インターネットからコードをコピーする必要があります。Zepplinプロジェクトは、コントラクトが使用できる標準ライブラリを提供することによって(このコントラクト自体に含めるか、外部コントラクトを呼び出すことによって)、このような状況に耐えられるようにしています。

しかし、上記アプローチの限界は、2つのSHA3操作を使用し、結果のハッシュを比較する方が、文字列のバイト(一度に32バイト)をループするよりも安価であると考えるとき、明らかになります。

設定された合理的なガス価格でネイティブコードを使用するプリコンパイルされたコントラクトの標準ライブラリを持つことは、スマートコントラクトのエコシステム全体に非常に有益です。

しかし、これがなければ、人々は代わりにオープンソースコードのコードをコピーして貼り付けます。未知のセキュリティの意味があります。これらの人々に加えて、コントラクトのセキュリティプロファイルを潜在的に損なうリスクがあっても、コードを最適化し、ガス使用量の短縮と削減を見出そうとします。

 

ガスの経済学とゲーム理論

私はこのトピックについては別途記事にしたいと思いますが、EVMは単にベストプラクティスをハードにし、高価にするだけではありません。

たとえば、ブロックチェーンにデータを格納するにはかなりの費用がかかります。つまり、スマートコントラクト内にデータの量をキャッシュするのは信じられないほど高額になる可能性があります。

したがって、代わりのことが各コントラクト実行とともに計算されます。時間の経過とともに、より多くのガスが消費され、ブロックチェーンノードは、同じデータを計算するために同じコードを実行するのにより多くの時間を無駄にします。

さらに、ブロックチェーンに格納されるデータには実際のコストはほとんどかかりません。ブロックチェーンのサイズを直接的には増加させません(EthereumまたはQtumのいずれにおいても)。

実際のコストは、ブロックチェーンのサイズを直接的に増加させるため、コントラクトに送信されるデータの形でブロックチェーンに入るデータです。 Etheruemではトランザクション(23176ガス)の形でブロックチェーンに32バイトのデータを入力するのがコントラクト(20,000)で32バイトを格納するコストよりも安く、64バイトのデータをスケーリングするとかなり安くなります(格納=80,000ガスと比較してトランザクション=29704ガス)。

コントラクトに格納されるデータには「仮想」コストがありますが、ほとんどの人が想定するよりもはるかに少ないです。基本的に、ブロックチェーン全体のデータを格納するデータベースを反復するコストです。 QtumとEthereumの両方で使用されているRLPとLevelDBデータベースシステムは、これを処理するのに非常に効率的ですが、進行中のコストは直線に近い場所ではありません。

非効率なコードを奨励するEVMの別の問題点は、スマートコントラクトで特定の機能を呼び出すことができないということです。これはERC20の契約でwithdraw()のような関数を直接呼び出すことができないため、セキュリティ上問題です。

これは効率的であるためには標準ライブラリが必要です。外部コントラクトから特定のコードをロードするだけではなく、コードの最初のバイトで実行が開始されるため、Solidity ABIブートストラップコードをすべてスキップする方法はありません。したがって、最終的には、これは小さな関数が重複することを奨励し(外部から呼び出す方が高価であるため)、できるだけ多くの関数をコントラクト内に展開するようにします。

コードをすべてメモリにロードする必要があるにもかかわらず、100バイトのコントラクトまたは10,000バイトのコントラクトを呼び出す場合には、コストの差はありません。

最後に、コントラクトのストレージに直接アクセスすることはできません。コントラクトコードはディスクから完全にロードされ、実行され、コードは要求されたストレージからデータをロードしてから、可変サイズの配列を使用しないようにしながら呼び出し元のコントラクトに戻す必要があります。ああ、あなたが必要とする正確なデータを知らなかったために前後に必要なものがあれば、少なくともキャッシュに入っているのでノードには安いですが、外部コントラクトを2回目に呼び出すためのガス価格の値引きはありません。

外部コントラクトのストレージにアクセスするには、コードを完全にロードする必要はありません。実際には、現在のコントラクトのストレージにアクセスするのと同じくらい計算的に安価なので、なぜそんなに高価にして効率を落とすのか私には理解できません。

デバッグとテスト容易性の欠如

この問題はEVMの設計の欠陥だけでなく、その実装にもあります。もちろん、Truffleのように、これをできるだけ簡単にするように努力しているプロジェクトもあります。

しかし、EVMの設計はこれを簡単にするものではありません。利用できる唯一の例外は “ガスを使わないこと”です。ロギング機能はなく、外部ヘルパーコード(テストヘルパーやデータを擬似するなど)を呼び出す簡単な方法もなく、Ethereumブロックチェーン自体は、専用テストネットを作成するのが難しく、プライベートブロックチェーンには異なるパラメータと動作があります。

Qtumは少なくとも “regtest”モードのおかげで発展しましたが、模擬データなどを使ってEVMをテストすることは、実装が本当に独立していないので、まだ難しいです。Solidityレベルで私が知っているデバッガーはありませんが、わたしが知っている少なくとも1つのEVMアセンブリデバッガーはユーザーフレンドリーではありません。

EVMやSolidityのためにシンボルフォーマットやデバッグデータフォーマットが全く確立されておらず、DWARFのような標準化されたデバッグフォーマットに向けて作業を開始するEIPやその他の努力がないことがわかったのです。

 

浮動小数点数の欠如

浮動小数点サポートの欠如が現れたときに人々が言う共通のことは、「浮動小数点数を使って通貨値を処理する必要はない」ということです。しかし、これは信じられないほど浅い考えです。リスクモデリング、科学計算、正確な値よりも範囲や近似が重要な場合など、浮動小数点数の実際的な使用例がたくさんあります。スマートコントラクトの潜在的なアプリケーションを通貨価値のみを扱うようにすることは、現実的ではなく、不必要に制限しています。

 

変更不能なコード

コントラクトの変更が必要かどうかという問題ではなく、むしろコントラクトの変更が必要であるため、コントラクトを設計する必要がある主なものの1つはアップグレード可能性です。

EVMコードは完全に変更不可能であり、ハーバード・アーキテクチャのコンピューティングを使用しているため、メモリにコードをロードして実行することはできません。コードとデータは、別々に扱われる完全に別個のものです。したがって、コントラクトをアップグレードする唯一のオプションは、完全に新しいコントラクトを展開し、すべてのコードを複製し、古いコントラクトをそのコントラクトにリダイレクトさせることです。

コントラクトの一部にパッチを当て、コードを部分的に(または完全に)置き換えることはできません。

 

結論

ビールを飲みながら綴ってきました(いまは強炭酸サイダーを飲んでいます)が、私の暴言もこれで終わりにしたいと思います。現時点でEVMは必要悪です。

この世界で初めて生まれたものでしたから。

Javascriptのように最初に作られるものは多くの問題があります。デザインが非常に異なるので、従来のプログラミング言語がEVMに移植されるとは思えません。

EVMのデザインは、過去50年以上にわたって確立された多くの共通言語パラダイムに積極的に敵対しています。これには、JUMPDESTのようなジャンプテーブルの最適化が難しい、テール再帰のサポートがない、奇妙で柔軟性のないメモリモデル、難解な外部メモリモデル、ビット単位のシフトなどの一般的に使用されるオペコードの欠如、柔軟性のないスタックサイズの制限、256ビットの整数などが含まれます。

これらの諸問題は、EVMへの伝統的な言語の移植を非効率的にするどころか、最悪の場合不可能にします。これこそがすべてのEVM言語が現在EVM用に特別に構築されており、そのすべてが非従来のモデルを念頭に置いている理由です。本当に悲しいことです。

EVMのデザイナーに襲われるのでもなく、EVMのデザイナーになるのでもありません。私はEVMの設計の特定の側面について多くの後悔を見てきました。それらを攻撃したいわけではなく(私の皮肉な調子が時々そのように感じさせるかもしれませんが)、これらの欠陥をブロックチェーンの開発者コミュニティに注目させて、繰り返さないようにしたいのです。

同時に、「Solidityでこれを行うことはできないのですか?」という質問をすべて入力してください。 EVMには今も恩恵と落とし穴を学んでいるという信じられないほどのデザインがあります。スマートコントラクトがすべて可能な限り効率的かつ強力なものになるためには、長い道のりが必要なことは明らかです。

EVMはこの分野で初めての候補者であり、究極的にはスマートコントラクトのすべてのユースケースを発見し、どのようなデザインが最も有益なのかを発見しています。私たちは長い道のりを歩んできましたが、まだまだ道のりは遠いのです。

スポンサーリンク