本稿について
ÆTERNITYのメインネットリリース前から行われているセキュリティ監査報告のv0.5について見ていきます。今回の範囲は「4. Protocol」の「4.3 Smart Constracts」です。
原文はこちらになります。
スポンサードサーチ
今回のまとめ
- スマートコントラクトについて
- コントラクトの作成
- ユーザは新規コントラクトを作成できる。コントラクトのサイズに基づいて計算される手数料が必要である。また、そのコントラクトに対する初期呼び出しを行う必要がある。
- コントラクトの呼び出し
- ユーザはコントラクトを呼び出すことができる。呼び出しに用いるトランザクションのサイズに基づいて計算される手数料が必要となる。また、トランザクション実行に十分なgasを出さなければならない。gas量は命令ごとに予め定義されている。
- コントラクトの実行
- スマートコントラクトはバイトコードプログラムにコンパイルされてからAEVM内で実行される。このバイトコードプログラムはAEVMにより命令方式で解釈される。バイトコードプログラムはOPコードとデータからなり順序通りに実行される。
- スマートコントラクトはバイトコードプログラムにコンパイルされてからAEVM内で実行される。このバイトコードプログラムはAEVMにより命令方式で解釈される。バイトコードプログラムはOPコードとデータからなり順序通りに実行される。
- コントラクトの作成
- Sophia（Sofia）について
- cnlabは、Sophia（ÆTERNITYのスマートコントラクト用の言語）を関数型言語としたことは適切な選択であると考えている。
- 関数型言語であることで開発者のミスが少なく、正当性の証明も容易な点でも優れているため。
- ビルド再現性を考慮してコンパイルプロセスを設計すべきである。
- 現在のバイトコード表現だと可読性や分析のしやすさが大きく損なわれているため。
- コンパイラの更新においては旧バージョンとの互換性も考慮すべきである。
- コンパイル方法の最新化によってgas量の削減などの効果がある一方、同じコントラクトから別のバイトコードが生成されるといった問題が出てくる可能性があるため。
- cnlabは、Sophia（ÆTERNITYのスマートコントラクト用の言語）を関数型言語としたことは適切な選択であると考えている。
※以下、今回まとめた範囲の和訳になりますので詳細をご覧になりたい方は読み進めてください。
4. プロトコル（続き）
4.3 スマートコントラクト
ÆTERNITYの中心的機能の一つがスマートコントラクトだ。これはBitcoinトランザクションの一般化や拡張としてEthereumプロジェクトで初めて開発されたものである。
実装レベルでは、実際のところBitcoinトランザクションはコンピュータ言語の小規模なプログラムであり、値（お金）を利用するのに満たさなくてはならない条件をエンコードする。このコンピュータ言語はバリデートしやすいようスクリプトをシンプルに保つ方法で制限されている。言語にはループが含まれていないので、チューリング完全ではない。
スマートコントラクトはチューリング完全な言語を用いたアイデアの拡張である。これはトランザクション（今ではコントラクトとも呼ばれる）のバリデートにかかる計算時間に上限がないという問題につながる。ユーザがループや条件付き飛び越しを使ってトランザクションを作ることができるということは、ある入力に対してプログラムが終了するかどうかをバリデートできないということであり、これはコンピュータサイエンスの分野では停止性問題として知られる問題である。さらにプログラムが停止する場合であっても、バリデートするのに大量のオペレーションを実行しなけばならないということになりかねない。ブロックチェーンの文脈においてこのことはノードに大きなバリデーションコストをかけることにつながる。
この問題を解決するために、コントラクトを呼び出すユーザは計算時間に対してお金を支払わなくてはならない。コントラクト呼び出しにかかる計算時間は"gas"で測定される。
コントラクトに関して以下のオペレーションが存在する。
コントラクトの作成
ユーザは新規コントラクトをブロックチェーンに送信できる。このオペレーションについて、他のあらゆる種類のトランザクションと全く同じようにコントラクトのサイズに基づいて計算される手数料が必要だ。さらに、そのコントラクトに対する初期呼び出しを行う必要がある。
コントラクトの呼び出し
ユーザはコントラクトを呼び出すことができる。このオペレーションについて、呼び出しトランザクションのサイズに基づいて計算される手数料が必要だ。さらに、ユーザはトランザクション実行に十分なgasを出さなければならない。コントラクト言語の命令ごとに予め定義された量のgasが必要となる。
4.3.1 AEVM（ÆTERNITY仮想マシン）
ÆTERNITYブロックチェーン上でスマートコントラクトはテキストプログラムの形式で保存されているわけではない。バイトコードプログラムにコンパイルされてからAEVM内で実行される。このバイトコードプログラムはAEVMにより命令方式で解釈される。バイトコードプログラムはOPコードとデータからなり順序通りに実行される。
ユーザによりコントラクトが呼び出される場合、各オペレーションには一定量の"gas"が必要である。このことはノードやマイナーがコントラクトをバリデートし対応する結果を計算するのにかかるコストを限定する。
計算時間についてはAEトークンの代わりにgasを使って支払われる。これにはマイナーがネットワークのキャパシティを反映したgas価格を求めることができるというアドバンテージがある。コントラクトのバリデートに要するコストはマイニングのディフィカルティとは無縁であるのでgas価格は調整できる。
ブロックをバリデートする必要があるノードの計算時間を限定するため、あらゆる呼び出しに関して"gas"リミットが全てのマイクロブロックにある。
4.3.2 Sofia（Sophia）
ÆTERNITYではスマートコントラクトを書くために高級プログラミング言語を定義した。この言語はSophiaと呼ばれる。
Sophiaは関数型プログラミング言語として設計されている。そのお陰で命令型プログラミング言語にありがちなミスは少ない傾向にある。さらに、容易にコントラクトのセマンティクスを分析し正当性を証明できる。
cnlabは、Sophiaを関数型言語としたことは適切な選択であると考えている。
Sophiaプログラムからバイトコードのコントラクトを生成するためにコンパイルが必要だ。コントラクトが行っていることをユーザが理解できるというのは重要なことである。Sophiaのコントラクトの表現は（筆者注：バイトコード表現よりも）読んで分析するのにずっと簡単であるので、ブロックチェーン上の特定のコントラクトが特定のSophiaプログラムからビルドされたものであるかを確認する手段をユーザが持っている方が好ましいと考えている。
推奨案3：コンパイルのプロセスはビルド再現性を考慮した方法で設計されるべきである。
Sophiaコンパイラは時間とともに変更することが予期される。コントラクトサイズの最小化だけでなく呼び出しで消費するgas量の最小化も望まれるので、先駆的な最適化手法がコンパイラの開発で大きな役割を果たすだろう。これは別バージョンのコンパイラを利用すると全く同じSophiaプログラムから別のバイトコード表現が生成されるということにつながる可能性がある。ブロックチェーン上のコントラクトが特定のSophiaプログラムからビルドされたものであるかをバリデートしたいとすると、このユーザは正しいバージョンのコンパイラを使う必要があるだろう。
推奨案4：古いバージョンのコンパイラでコンパイルされたコントラクトもユーザが再現できるような方法でコンパイラの更新がなされるべきである。
（ÆTERNITYのセキュリティ監査報告を読んでみる5 ←← 前）｜（次 →→ ÆTERNITYのセキュリティ監査報告を読んでみる6）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。