(57)【要約】      （修正有）【課題】ブロックチェーン内でスマートコントラクトをセキュア化する。【解決手段】ブロックチェーン内で、生成対象のスマートコントラクトの制御フローグラフ（CFG）およびコントラクトコードを有するコントラクト生成トランザクションを受け取る。コントラクト生成トランザクションはスマートコントラクトのクリエイタの署名を確認し、コントラクトコードに基づいてCFGの正当性を判断することによって検証される。検証されたコントラクト生成トランザクションはブロックチェーンの分散型台帳にブロックとして含められる。【選択図】図３
2019083013.tif 000002
【特許請求の範囲】
【請求項１】
ブロックチェーン内で、生成されるスマートコントラクトの制御フローグラフ（CFG）およびコントラクトコードを有するコントラクト生成トランザクションを受け取り、
前記スマートコントラクトのクリエイタの署名を確認し、前記コントラクトコードに基づいて前記CFGの正当性を判断することによって前記コントラクト生成トランザクションを検証し、
検証された前記コントラクト生成トランザクションを前記ブロックチェーンの分散型台帳にブロックとして含める、
ブロックチェーン内でスマートコントラクトをセキュア化する方法。
【請求項２】
前記スマートコントラクト、または、前記スマートコントラクトと同様に生成され、検証され、前記ブロックチェーンに含まれる別のスマートコントラクト、を呼び出すブロックチェーントランザクションを受け取り、
前記ブロックチェーントランザクションによって呼び出される実行パスを決定し、
前記ブロックチェーントランザクションの前記実行パスを前記CFGと比較し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致する場合は、前記ブロックチェーントランザクションを検証し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致しない場合は、悪意のあるトランザクションの証明を前記ブロックチェーンにブロードキャストする、
ことをさらに含む請求項１に記載の方法。
【請求項３】
前記CFG、前記コントラクトコード、および前記スマートコントラクトの実行の状態を、前記ブロックチェーンの前記分散型台帳の前記ブロックに格納する、
請求項２に記載の方法。
【請求項４】
前記ブロックチェーントランザクションを検証した上で、前記ブロックチェーンの前記分散型台帳に格納される前記スマートコントラクトの前記実行の後に前記状態を更新する、
ことをさらに含む請求項３に記載の方法。
【請求項５】
ダイナミック入力を与えられた予期される実行パスに条件をマークするために前記CFGにラベルを追加する、
ことをさらに含む請求項１に記載の方法。
【請求項６】
前記ブロックチェーンにおいて、前記コントラクト生成トランザクションを、前記スマートコントラクトの前記クリエイタからのトランザクションコールとして受け取る、
請求項１に記載の方法。
【請求項７】
前記スマートコントラクトの前記クリエイタが、ダイナミック入力および状態を与えられた前記コントラクトコードに基づいて前記CFGを作成する、
ことをさらに含む請求項１に記載の方法。
【請求項８】
単独又は組み合わせられた１つまたは複数のプロセッサを備えた、ブロックチェーン内でスマートコントラクトをセキュア化するためのシステムであって、
前記ブロックチェーン内で、生成されるスマートコントラクトの制御フローグラフ（CFG）およびコントラクトコードを有するコントラクト生成トランザクションを受け取り、
前記スマートコントラクトのクリエイタの署名を確認し、前記コントラクトコードに基づいて前記CFGの正当性を判断することによって前記コントラクト生成トランザクションを検証し、
検証された前記コントラクト生成トランザクションを前記ブロックチェーンの分散型台帳にブロックとして含める、
処理を実行するシステム。
【請求項９】
前記スマートコントラクト、または、前記スマートコントラクトと同様に生成され、検証され、前記ブロックチェーンに含まれる別のスマートコントラクト、を読み出すブロックチェーントランザクションを受け取り、
前記ブロックチェーントランザクションによって呼び出される実行パスを決定し、
前記ブロックチェーントランザクションの前記実行パスを前記CFGと比較し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致する場合は、前記ブロックチェーントランザクションを検証し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致しない場合は、悪意のあるトランザクションの証明を前記ブロックチェーンにブロードキャストする、
処理をさらに実行する請求項８に記載のシステム。
【請求項１０】
前記CFG、前記コントラクトコード、および前記スマートコントラクトの実行の状態を、前記ブロックチェーンの前記分散型台帳の前記ブロックに格納する、
ことをさらに実行する請求項９に記載のシステム。
【請求項１１】
前記ブロックチェーントランザクションを検証した上で、前記ブロックチェーンの前記分散型台帳に格納される前記スマートコントラクトの実行の後に前記状態を更新する、
処理をさらに実行する請求項１０に記載のシステム。
【請求項１２】
ダイナミック入力を与えられた予期される実行パスに条件をマークするために前記CFGにラベルを追加することを実行する、前記スマートコントラクトの前記クリエイタと関連付けられた単独又は組み合わせられた１つまたは複数のプロセッサをさらに備えた、
請求項８に記載のシステム。
【請求項１３】
ダイナミック入力および状態を与えられた前記コントラクトコードに基づいて前記CFGを作成することを実行する、前記スマートコントラクトの前記クリエイタと関連付けられた単独又は組み合わせられた１つまたは複数のプロセッサをさらに備えた、
請求項８に記載のシステム。
【請求項１４】
ブロックチェーン内で、生成されるスマートコントラクトの制御フローグラフ（CFG）およびコントラクトコードを有するコントラクト生成トランザクションを受け取り、
前記スマートコントラクトのクリエイタの署名を確認し、前記コントラクトコードに基づいて前記CFGの正当性を判断することによって前記コントラクト生成トランザクションを検証し、
検証された前記コントラクト生成トランザクションを前記ブロックチェーンの分散型台帳にブロックとして含める、
処理を１つまたは複数のプロセッサに実行させる指示を記憶したコンピュータにて読み取り可能な記憶媒体。
【請求項１５】
前記スマートコントラクト、または、前記スマートコントラクトと同様に生成され、検証され、前記ブロックチェーンに含まれる別のスマートコントラクト、を呼び出すブロックチェーントランザクションを受け取り、
前記ブロックチェーントランザクションの実行パスを決定し、
前記ブロックチェーントランザクションの前記実行パスを前記CFGと比較し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致する場合は、前記ブロックチェーントランザクションを検証し、前記ブロックチェーントランザクションの前記実行パスが前記CFGと一致しない場合は、悪意のあるトランザクションの証明を前記ブロックチェーンにブロードキャストする、
処理を１つまたは複数のプロセッサに実行させる指示を記憶した請求項１４に記載のコンピュータにて読み取り可能な記憶媒体。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本出願は、2017年10月30日に出願された米国仮特許出願第62/578,581号の優先権を主張し、その全開示は参照により本明細書に組み込まれる。
【技術分野】
【０００２】
本発明は、ブロックチェーン内でスマートコントラクトをセキュア化する方法およびシステムに関する。
【背景技術】
【０００３】
ビットコインの大規模な導入により、イノベーションが真に促進され、現在では500を超えるブロックチェーンが存在するが、その大部分はビットコインの単純な変形である。ビットコインを通して、ブロックチェーンというシステムの鍵となる実現技術とその潜在力が明らかとなった。実際に、ブロックチェーンによって、中央一元管理を必要とすることなくトランザクションやその他のデータをセキュアに格納および検証できる。本発明者らによると、ブロックチェーンコミュニティが、これまでに相当の時間をかけて拡張性のある分散型コンセンサスプロトコルを探し続けてきたことがわかった。
【０００４】
現在、イーサリアムなど複数のブロックチェーンは、スマートコントラクトと呼ばれる任意のアプリケーションをブロックチェーン上で実行できるようにするチューリング完全なプログラミング言語を提供している。例えば、イーサリアムのブロックチェーンのためのネームコインの基本バージョンは数行のコードで書くことができる。また、スマートコントラクトの概念を適用することにより、最低限のプログラミングの労力で補助通貨を作成することができる。イーサリアムの別の具体的な使用例としては、自律分散型組織（DAO）の構築がある。
【０００５】
スマートコントラクトを正しく実行することが、スマートコントラクトの有効性を保つための必要条件である。この数年で、ブロックチェーンコミュニティは、スマートコントラクトの深刻な脆弱性や重大なバグを数多く目にしてきた。脆弱性には、リエントランシの問題、スマートコントラクト内の配列／ループ、変数名／関数名の混同などが含まれる。これらの脆弱性により、ブロックチェーンコミュニティは、スマートコントラクトのセキュリティ強化のための専用のソリューションについての研究に対する関心を強めている。既存のソリューションは、より良い開発環境や専用のプログラミング言語、形式的検証、シンボリック実行など広範囲にわたる。しかしながら、本発明者らは、これらの既存のソリューションには依然として脆弱性があり、十分なセキュリティを提供できていないことを認識している。
【発明の概要】
【０００６】
一実施形態において、本発明は、ブロックチェーン内でスマートコントラクトをセキュア化する方法を提供する。ブロックチェーンにおいて、制御フローグラフ（CFG）および生成されるスマートコントラクトのコントラクトコードを含むコントラクト生成トランザクションが受け付けられる。このコントラクト生成トランザクションは、スマートコントラクトのクリエイタの署名を確認することおよびコントラクトコードに基づいてCFGが正当であるかを判断することによって検証される。検証済のコントラクト生成トランザクションは、ブロックチェーンの分散型台帳にブロックとして含まれる。
【図面の簡単な説明】
【０００７】
本発明は、以下の例示的な図面においてさらに詳細に説明される。本発明は、例示的な実施形態に限定されない。本明細書において説明および／または図示されたすべての特徴は、本発明の実施形態において単独で使用されてもよく、または異なる組み合わせで組み合わせられてもよい。本発明の様々な実施形態の特徴および利点は、添付の図面の以下の詳細な説明によって、以下の図の例示とともに明らかになるであろう。
【０００８】
【図１】図１は、DAOへの攻撃を図示している。
【０００９】
【図２】図２は、スマートコントラクトのCFGとともにコントラクトバリデータが配置されている、本発明の一実施形態によるブロックチェーンアーキテクチャを概略的に示す図である。
【００１０】
【図３】図３は、本発明の一実施形態による方法のフローチャートである。
【発明を実施するための形態】
【００１１】
一実施形態において、本発明は、制御フローの整合性（CFI）を利用してスマートコントラクトのセキュリティを強化する新しいソリューションを提供する。このソリューションは、CFIを利用することにより、スマートコントラクトの実行時モニタリングを可能にする。このような本発明のソリューションにより、CFIベースのスマートコントラクトの実行は、スマートコントラクトの脆弱性の悪用を防止し、制御フローグラフ（CFG）に基づく状態確認の手段により効果的なトランザクションの検証を可能にする。このアプローチは、スマートコントラクトの実行時検証を行うために適用できるので、スマートコントラクトの実際の実行フローをカバーする。一方、オフラインの静的または動的解析方法に基づくスキームは、スマートコントラクトの実行時動作のすべてをカバーせず、また実行時動作の予測もできないため、限定的なカバレッジしかない。
【００１２】
本発明の実施形態は、スマートコントラクトのロジックをCFGと置き換えることにより、スマートコントラクトの実行時における動的解析を可能にする。これに対して、形式的検証および静的解析には、セキュリティに関しては厳しい限界がある。
【００１３】
以下に、イーサリアムにおけるスマートコントラクトについての背景情報を提供し、関連研究について述べる。次に、本発明の例示的な実施形態によるシステムモデルおよびCFIに基づくソリューションについても述べる。
【００１４】
イーサリアムは、スマートコントラクトを介して、一般的な演算のための分散プラットフォームを提供する。スマートコントラクトは、イーサリアム仮想マシン（EVM）コードの疑似チューリング完全プログラムである。スマートコントラクトは、（ブロックチェーン）トランザクションを介してイーサリアムノードに配置され、複製される。コントラクト生成中に、新しいアカウントがコントラクトコードに関連付けられ、内部ストレージで初期化される。そのアカウントの仮想通貨の残高が「Ether」である。
【００１５】
トランザクションがコントラクトアカウントに送られると、スタックベースの仮想マシンであるローカルEVMにおいてノードがコントラクトを実行する。コントラクトを実行するとGasが消費される。Gasは、ブロックチェーン上で各命令を実行するためのコストを定義している。何らかの例外が発生した場合（「アウトオブガス」例外を含む）には、コントラクトの状態が元に戻される。
【００１６】
イーサリアムブロックチェーンのリリース以降、ブロックチェーンネットワークにおいて、決済アプリケーションやゲーム、クラウドファンディングのプロジェクトなど、多くのサービスが行われている。これらのサービスは、公衆参加を成功させることによりその透明性を確保したが、同時にスマートコントラクトの脆弱性の悪用（例えば、資金の盗難）への関心を高めた。例えば、https://blog.slock.it/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5 （最終アクセス日は2017年10月10日）にて公開されているC. Jentzsch, “The History of the DAO and Lessons Learned”は、2016年6月に6000万米ドルに近い額の盗難に至った悪名高いDAO攻撃について説明している。
【００１７】
K. Delmolino, et al., “Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab,” International Conference on Financial Cryptography and Data Security, pp. 79-94, Springer (2016) は、スマートコントラクトを導入する際に失敗しやすい点をいくつか指摘している。この論文では、コントラクトプログラムのいくつかの論理エラーにより、分散システムでホストされているコントラクトの同時実行処理機能を利用することができなくなることが示された。例えば、コントラクトのプログラミングを行う際には、ネットワーク上のトランザクションを監視したり、自分の利益のためだけにブロックを確保したりする能力を攻撃者が有するかもしれないということを考慮する必要がある。この研究では、コントラクト間の内部トランザクションコール中に発生する、イーサリアム仮想マシン（EVM）レベルでのコールスタックバグについても説明している。EVMコールスタックは1024の固定サイズであるため、send()関数を用いたイーサの転送など、それ以降のコールは無視される。この機能は、ターゲットのコントラクトの特定のコールがサイレント障害を起こすこと（つまり、例外をスローしないこと）を狙っている攻撃者によって悪用される可能性がある。攻撃者は、はじめに自身が管理しているコントラクトを繰り返し呼び出すことで、ターゲットコールがコールスタックで1025に達し、無視されるように仕向け、サイレント障害を引き起こすことができる。
【００１８】
さらに、C. Reitwiessner, “Smart Contract Security,” https://blog.ethereum.org/2016/06/10/smart-contract-security （最終アクセス日は2017年10月10日）およびConsenSys, “Ethereum Contract Security Techniques and Tips,” https://github.com/ConsenSys/smart-contract-best-practices （最終アクセス日は2017年10月10日）では、コントラクトをEVMコードにコンパイルするための高水準プログラミング言語であるSolidityでコントラクトをプログラミングする場合、イーサリアムコミュニティは多くの一般的な落とし穴やベストプラクティスの対象となることが述べられている（“Solidity,” http://solidity.readthedocs.io/en/latest/index （最終アクセス日は2017年10月10日）を参照のこと）。資金を送るためのプロセスでさえ、いろいろな方法で悪用される可能性があることが示されている。落とし穴についての議論には、後にDAO攻撃で悪用されたバグについての議論が含まれている。関数send（）には受取人のコントラクトのフォールバック機能をコールするという副作用があるため、悪意のあるコントラクトは、このフォールバック機能において資金移動の機能を再度呼び出すことができる。この副作用はかなり隠されており、慎重に取り扱わなければコントラクトはリエントランシコールに陥る可能性がある。実際、L. Breidenbach、et al., http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug （最終アクセス日は2017年10月10日）に記されるように、EVMのこの暗黙のフォールバック機能は、Parityと呼ばれる有名なウォレットコントラクトにおいても最近悪用され、600万米ドルが盗難された。この攻撃では、基礎となるライブラリコントラクトの機能がウォレットコントラクトからのフォールバック機能により突然トリガされるのである。
【００１９】
DAO攻撃の後、V. Buterin, “Thinking About Smart Contract Security,” https://blog. ethereum.org/2016/06/19/thinking-smart-contract-security （最終アクセス日は2017年10月10日）、N. Atzei, et al., “A survey of attacks on ethereum Online” International Conference of Principles of Security and Trust, pp. 164?186, Springer (2017)、およびL. Luu, et al., “Making smart contracts smarter,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 254?269, ACM (2016) において、発行済のスマートコントラクトにおける既存の脆弱性が調査された。発見されたバグは、基盤となるプラットフォームの分散意味論に対する理解の微妙なずれを示唆している。このずれを修正するために、L. Luuら（ここに本明細書の一部を構成するものとしてこの内容を援用する）は、イーサリアムコントラクトの操作的意味論の強化を以下とおりに提案している。
−  保護されたトランザクション：トランザクションは実行条件を定義することができ、検証ノードの現在のグローバル状態が条件を満たした場合にのみ実行される。この条件は、並行トランザクションの分散環境におけるトランザクション順序依存性による一貫性のない実行を防止することができる。
−  決定論的タイムスタンプ：この修正案では、コントラクトのデータソースとしてブロックタイムスタンプの代わりにブロックインデックスを提供する。これにより、コントラクトの実行結果に影響を及ぼすために容認できるウィンドウ内に攻撃者がタイムスタンプを操作することを防ぐ。
−  一貫性がある明示的な例外処理：アトミック性を強化するために、Solidityでは、呼び出し命令の違いにかかわらず、EVMのレベルでのすべての例外を、呼び出し先から呼び出し元へ自動的に伝搬させることが推奨されている。さらに、すべての例外を明示的に処理して、プログラマの意に沿わないサイレント障害を回避する必要がある。
【００２０】
さらに、Luuらは、コントラクトの潜在的なセキュリティ上のバグを見つけるためのツール"Oyente"も提供している。Oyenteは、J. C. King, “Symbolic execution and program testing,” Communications of the ACM, vol. 19, no. 7, pp. 385-394 (1976) にて述べられているシンボリック実行を適用しており、コントラクトバイトコードおよびイーサリアムの現在のグローバル状態から実行パスを評価し、特定された脆弱性との一致を見つけることを試みる。
【００２１】
さらに、「変わりやすい」コントラクトにも新たな課題がある。配置されたコントラクトの不変性はコントラクトの更新やバグ修正への制限となるが、新しいコントラクトはリンクされたライブラリの複合体として構成されている。エントリポイントコントラクトは固定アドレスを持ち、公開アプリケーションプログラミングインターフェイス（API）のみを定義し、ライブラリコントラクトのアドレスを格納する。トランザクション呼び出しは、実際の機能が実装されているライブラリコントラクトに転送される。したがって、コントラクトの更新は、新しいライブラリを配置し、そのアドレスを更新することによって達成される。このアプローチはコントラクトの更新における問題を解決するが、制御フローが変化するために困難ももたらす。M. Froewis, et al., “In code we trust?,” Data Privacy Management, Cryptocurrencies and Blockchain Technology, pp. 357-372, Springer (2017)によると、コントラクトの87％が他のコントラクトに依存し、コントラクトの54％がミュータブルであることがわかった。つまり、ハードコーディングされたアドレスを持たない他のコントラクトを呼び出すため、制御フローは、ブロックチェーンの現在のグローバル状態だけでなく入力トランザクションにも依存して変化する。
【００２２】
DAO（C. Jentzsch, “Decentralized autonomous organization to automate governance,” https://download.slock.it/public/DAO/WhitePaper.pdf （最終アクセス日2016年10月10日）を参照のこと）は、Solidityで書かれたイーサリアムのコントラクトである。これにより、DAOのステークホルダーはプロジェクトを提案し、その提案に投票し、実行することができる。生成段階では、コントラクトはまずイーサと引き換えに「DAOトークン」を発行することによりステークホルダーから資金を調達する。トークンの所有者は、DAOの枠組みの下で、（他のイーサリアムコントラクトに代表される）提案されたプロジェクトに対する投票権と所有権を与えられる。提案が承認されると、トークンの所有者は提案に投票することができ、提案期間が過ぎた時点で十分な投票数があれば、提案が実行される。
【００２３】
コントラクトにおいて、DAOは任意のステークホルダーが新しいDAOコントラクトであるchildDAOを提案し、そのコントラクトにトークンを転送することも可能にする。この仕組みは、少数のステークホルダーの権利を保護し、DAOを離れることを可能にすることを目的としている。しかし、コード化されたコントラクトにこのプロセスを実装する関数は注意深く書かれていないため、攻撃者によって悪用され、その結果、2016年6月18日にDAOから350万イーサが流出した。
【００２４】
攻撃者はDAOにおいてトークンを所有するステークホルダーである。攻撃者はまず悪意のあるコントラクトであるchildDAOAをDAOに提案した。この提案は、１週間の討論期間が設けられたにもかかわらず、他のステークホルダーによる精査を受けることなく、容易に承認された。プロトコルに従ってsplit-DAO機能が呼び出され、攻撃者のトークンがDAOからchildDAOAに転送された。この資金送金プロセスは、childDAOAにおいてフォールバック機能を自動的にトリガする。コントラクトのフォールバック機能は、コントラクトが資金を受け取るたびにコールされる。攻撃者はこの特性を利用して、childDAOAのフォールバック機能内でsplitDAOに再び入ることにより再帰呼び出しを引き起こし、攻撃者のトークンをDAOコントラクトから攻撃者のchildDAOAコントラクトへ繰り返し転送した。DAOにおける攻撃者のアカウントの残高は悪用された再帰呼び出しの後にはじめてリセットされるため、DAOは一定量のトークンを攻撃者（すなわち、攻撃者が所有するchildDAOAコントラクト）に継続的に送信し続ける。図1は、特殊なchildDAOコントラクトを作成することによって攻撃者が行った攻撃を示す。イーサリアムの無限ループを防ぐためのgasリミットがあるが、攻撃者は許容されているリエントランシコールの数を計算できる。さらに、トランザクションを悪用するために攻撃者が支払うgasのコストは、攻撃者がDAOから過剰に引き出すことができる資金に比べると無視できる程度である。
【００２５】
実際、堅実でセキュアなスマートコントラクトを書くことは、非常に困難であり、直観的ではない。その結果、スマートコントラクトはしばしば、プログラマが予想しないような動作をする。C. Reitwiessner, “Smart contract security,” (2016), https://blog.ethereum.org/2016/06/10/smart-contract-security （最終アクセス日2017年10月10日）は、スマートコントラクトを書く際に陥りやすい失敗について述べている。例えば、プロシージャ内のアカウントにイーサを送ることは大抵の場合バッドプラクティスである。なぜならば、攻撃者はいつでも決済エラーを起こすことができ、したがってコントラクトの動きを操ることができるからである。例えば、攻撃者が決済エラーを起こさせることにより、オークションコントラクトにおいて他者が攻撃者よりも高い値をつけないようにすることができ、攻撃者が利益を得ることになる。これを回避するには、受取人が別のコールで支払いを開始させるべきである。さらに、ブロックへの再入を防ぐために相互排除を使用するべきである。そうではない場合には、イーサを送る前に残高を更新するべきである。V. Buterinは、イーサリアムの非常に一般的なコントラクトのうち実際に脆弱性を持つものをいくつか挙げている。もう一つの課題は、コントラクトが一度ブロックチェーンに配置されると、変更不可能であるため更新することが難しいということである。実際、攻撃が実行される前に、DAOの脆弱性が発見され、公に議論されていた。プログラマが問題の修正に取り組んでいた間に、攻撃者は発見されていた脆弱性に対する攻撃を先に開始した。
【００２６】
ソフトウェアの悪用は、依然としてソフトウェアプログラムに対する最も一般的な攻撃ベクトルの1つである。これらの攻撃が成功し続けているのは、ソフトウェアプログラムの大部分が、入力データへの境界チェックを行わない、型アンフェース言語で実装されているからである。ソフトウェア攻撃に対する最も有望な防御メカニズムの1つに、CFIの適用がある。CFIの趣旨は、アプリケーションを実行する前にアプリケーションのCFGを取得し、アプリケーションの実行時動作をモニタリングすることにより、制御フローがCFGの正当なパスをたどることを保証することである。基本的にCFGとは、実行中のプログラムがたどり得る有効な実行パスを表すものである。CFGは、基本ブロック（BBL）、単一エントリの命令シーケンス、およびExit命令（例えば、リターン、コール、またはジャンプ）からなり、Exit命令は、あるBBLから別のBBLへの移動を可能にする。CFGからの逸脱は、CFI例外を発生させ、続いてアプリケーションを終了させる。これは、BBLの分岐命令を確認することによって達成される。確認された分岐命令は、その分岐命令がCFG内の正当な実行経路を対象とするかどうかを検証する新しい命令ブロックで上書きされる。
【００２７】
M. Abadi, et al., “Control-flow integrity: Principles, implementations, and applications,” ACM Trans. Inf. Syst. Secur., vol. 13, no. 1 (2009) （ここに本明細書の一部を構成するものとしてこの内容を援用する）では、アプリケーションの実行フローが常にそのアプリケーションのCFGの正当なパスをたどるようにするソフトウェアセキュリティの概念であるCFIについて述べられている。N. Burow, et al., “Control-flow integrity: Precision, security, and performance,” ACM Comput. Surv., vol. 50, pp. 16:1-16:33 (April 2017) には、CFIが最新の研究テーマであり、過去数年間に多くのスキームが提唱されていることが示されている。しかし、本発明以前には、例えば、ブロックチェーンなどの分散プログラミングネットワークにおいて、スマートコントラクトの実行をセキュアにするためのCFIの適用については検討されてこなかった。
【００２８】
特に、本発明の実施形態によれば、スマートコントラクトの実行に対する攻撃を検知するためにスマートコントラクトのCFGを活用する新規なソリューションが提供される。ブロックチェーンのコンテクストにおいてCFIを適用するために、本発明の実施形態は、コンテクスト依存型モニタリングをサポートする。具体的には、CFIの適用ではCFGパスの正当性を判断するために、ブロックチェーンの状態および現在のトランザクションが考慮されるものとする。例えば、DAO攻撃の際には、攻撃者は、前エントリが終了しアカウント残高が更新される前にsplitDAO関数に繰り返しリエントリする。したがって、スマートコントラクトの実行のCFGおよび現在のCFG状態（例えば、splitDAO関数内での実行状態）により、このような攻撃の検出および防止が可能になる。
【００２９】
以下の例示的な実施形態の説明では、イーサリアムに類似した分散型ブロックチェーンネットワークが想定される。すなわち、トランザクションは、基礎となるコンセンサスプロトコルを介して、ブロックチェーンノード中の分散型台帳上で順序付けられ、複製されると仮定される。同様に、スマートコントラクトはコントラクト生成トランザクションを介してノードに複製され、トランザクションコールによってコントラクトが呼び出され、状態が更新される。コントラクトコードCは、関連アドレスAddrcおよび状態Scの内部ストレージを有すると仮定する。コントラクトは複数のインタフェース（f0c, f1c,…, fmc）も提供する。ここで、f0cは、呼び出しトランザクションにおいて関数シグネチャが一致しない場合にコールされるフォールバック関数である。コントラクト実行中に、コントラクト間コールNの数が限られた数に達するまで、コントラクトは台帳にある別のコントラクトを呼び出し続けることができる。
【００３０】
コントラクトの配置および呼び出しの観点から、ブロックチェーンノードの役割は、「コントラクトクリエイタ」および「コントラクトバリデータ」として定義される。ブロックチェーンのノードは、各々、例えば、サーバ、コンピュータプロセッサ、メモリデバイスなどを１つまたは複数含むコンピュータデバイスまたはシステムである。コントラクトクリエイタは、コントラクトのオリジネータであり、コントラクトの正当な実行パスを定義する。コントラクトのバイトコードが与えられると、基本ブロック間の各（調整された）ジャンプまたはコールのCFGを得ることができる。この静的グラフは、攻撃者によって実行フローが乗っ取られること（例えば、ブロックAからCFG内に存在しないブロックBへの無効なジャンプ）をすでに防止できている。これに加えて、ダイナミック入力データにより、コントラクトクリエイタは予想される実行フローのパスを得ることができ、その条件をマークするためにCFGにラベルを追加することができる（例えば、ブロックXへのジャンプは常にブロックYへのジャンプより先に行われる。実行時にこのような条件が確認されない場合、脆弱性が悪用されていると判断することができる）。コントラクトバリデータは、分散型台帳を維持し、トランザクションコールに応じてコントラクトを実行する検証ノードである。
【００３１】
本発明の実施形態は、分散環境におけるコントラクトの実行に対する新しいアプローチを提供する。ブロックチェーンの目的は、コントラクトの実行ではなく、トランザクションの順序付けと検証およびそれに応じた状態の更新である。コントラクトの実行は、この目的を達成するための単なる１つの方法に過ぎない。
【００３２】
したがって、本発明の実施形態のソリューションでは、悪意のあるトランザクションにより予期せぬ状態が生じる可能性があるネットワーク内で各コントラクトバリデータがコントラクトを実行することはしない。代わりに、コントラクトバリデータは、コントラクトのトリガされた実行パスを評価することによってトランザクションの検証のみを行う。コントラクトクリエイタは、コントラクトの正当なCFGをまず定義し、このCFGをスマートコントラクトとともにブロックチェーンに配置する。受け取り時に、コントラクトバリデータは、コントラクトコードに基づいてCFGの正当性を検証し、スマートコントラクトのインスタンスを適切に作成する。これ以降の入力トランザクションについては、コントラクトバリデータは、これらがCFG内のすべての予定チェックポイントを通過するかどうかの確認によってのみ検証する。そうでない場合、コントラクトバリデータは、トランザクションを無効にするために実行違反の証明を他のノードにブロードキャストする。
【００３３】
図２は、ソリューションを実行するための本発明の実施形態による方法およびシステムを概略的に示す。具体的には、スマートコントラクト20のCFG 22と共にコントラクトバリデータ12が配置されているブロックチェーンアーキテクチャ10が示されている。コントラクトクリエイタ14は、トランザクションコール16を介してコントラクトコードとその正当なCFG 22の両方をブロックチェーンに配置する。ブロックチェーンネットワーク内のすべてのコントラクトバリデータ12は、署名が有効でCFG 22が正当な場合にのみこのデプロイメントトランザクションを受け入れる。なお、本明細書において、デプロイメントトランザクションはコントラクト生成トランザクションとも呼ばれる。その後、コントラクトアカウントが生成され、コントラクト生成トランザクションを分散型台帳24に追加することによって、検証済のCFG 22はコントラクトアカウントおよび元のコントラクトコードに関連付けられる。あるいは、一部のアプリケーションでは、コントラクトクリエイタ14は、（実際のコントラクトを送信することなく）検証済のCFG 22を分配するだけでよい。ここで、CFG 22は、悪意のあるトランザクションによる攻撃によってトリガされる予期しない実行パスを防止するために使用される。具体的には、CFG 22は、スマートコントラクト20の有効な実行フローを表し、スマートコントラクト20内の機能を呼び出す後続のトランザクションコール26期間中にスマートコントラクト20の現在の実行状態がCFGと一致するかどうかをコントラクトバリデータ12に判断させることができる。これによって悪意または異常のあるスマートコントラクトの実行フローを検出する。
【００３４】
図３に示される、一実施形態によるブロックチェーン内でスマートコントラクトをセキュア化する方法では、以下のステップが実行される。
１．コントラクトクリエイタがスマートコントラクトコードを書く。
２．コントラクトクリエイタは、特定の実行パスを規定するコントラクトコードにダイナミック入力および状態を与えて、コントラクトのCFGを生成する。
３．コントラクトクリエイタは、署名済のトランザクション内に、コントラクトコードをCFGと共に発行する。
４．コントラクトバリデータは、前のステップで生成されたコントラクト生成トランザクションを受け取り、クリエイタの署名を確認し、CFGの派生元であるコントラクトコードによりCFGの正当性を検証することによって、このコントラクト生成トランザクションを検証する。試験済みの入力および状態により、特定の条件を指定するために静的CFGにラベルを追加することもできる。
５．上記の検証が成功すると、コントラクトはブロックに含まれ、台帳に保存される。その後、コントラクトバリデータによって、ブロックチェーン上にコントラクトアカウントが、関連付けられているコントラクトコード、CFG、状態およびその他のコントラクトアカウント情報とともに生成される。状態は、各トランザクションがスマートコントラクトを呼び出した後にコントラクトバリデータによって更新される。
６．コントラクトの機能を呼び出すためにトランザクションがコントラクトアカウントに送信される度に、コントラクトバリデータがそのトランザクションの実行パスを計算し、関連付けられているCFGと比較することによってトランザクションを検証する。
７．実行パスがCFGと一致する場合、そのトランザクションは検証済となり、ブロックに含まれる。そうでない場合、無効な実行パスが悪意のあるトランザクションの証明としてブロックチェーンにブロードキャストされる。コントラクトバリデータが最初にトランザクションを受け取ると、上記のステップを実行する。コントラクトバリデータが最初に悪意のあるトランザクション証明を受け取ると、検証し、証明を転送する。
【００３５】
本発明の実施形態によるソリューションの実現可能性を評価するために、コントラクトコード（ソースコードとオペコードの両方の行）の平均サイズを推定するために既存のコントラクトに基づく統計値を用いた。なぜならば、大規模なプログラム用にCFGを生成することが通常難しいためである。すべての検証済コントラクトは、Etherscan.ioを介してイーサリアム内でクロールされた。すべての検証済コントラクトのソースコードは公開されており、台帳に含まれる、デプロイされたコントラクトのバイトコードと照合される。2017年9月26日までに照合された4,515件のコントラクトにおいて、コードの平均サイズは324行であり、最大のコントラクトは2,524行であった。オペコードの数に関しては、本発明の実施形態では、平均2,389個のオペコードおよび最大13,290個のオペコードを有することが可能である。具体的には、JUMPやCALLなど、CFGのサイズに影響を与えるオペコードがチェックされる。以下の表1に示した結果から、コントラクトに含まれる命令のうち、平均36.9％がJUMPまたは条件ジャンプJUMPI命令であることがわかる。これらの命令のうち、3.5％未満がコントラクト間コールを呼び出す。
【表１】
2019083013.tif 000003
表１：イーサリアムにおいて現在検証されているコントラクトから抽出された統計値。
【００３６】
したがって、初期段階の結果によると、現在のスマートコントラクトのサイズはCFGベースの解析に適している。コールおよびジャンプによって生成される分岐の数が数千程度までならばCFGベースの解析が適している。
【００３７】
本発明は、図面および前述の説明において詳細に図示され説明されてきたが、これらの図示および説明は、例示的または代表的であり、限定的ではないとみなされるべきである。本発明の趣旨または添付クレームの範囲を逸脱せずに変更および修正を加えうることは当業者には明らかなところである。特に、上記および下記の異なる実施形態の特徴の任意の組み合わせも本発明の実施形態に含まれる。さらに、本明細書で述べた本発明を特徴づける記述は、本発明の実施形態を指し、必ずしもすべての実施形態を指すものではない。
【００３８】
特許請求の範囲で使用される用語は、前述の説明と一致する最も広い合理的な解釈を有すると解釈されるべきである。例えば、要素を導入する際に冠詞「a」または「the」を使用することは、複数の要素を除外するものとして解釈されるべきではない。同様に、「または」の列挙は、「AまたはB」の記載が「AおよびB」を除外しないように包括的であると解釈されるべきである。ただし、文脈または上記の説明から、AおよびBのうちの1つのみが意図されていることが明らかである場合はこの限りではない。さらに、「A、BおよびCのうち少なくとも1つ」の記載は、A、BおよびCが区分またはその他において関連しているかどうかにかかわらず、A、BおよびCからなる要素群の1つまたは複数として解釈されるべきであり、列挙された要素A、BおよびCのそれぞれを少なくとも1つずつ必要とすると解釈されるべきではない。さらに、「A、Bおよび／またはC」または「A、BまたはCの少なくとも1つ」の記載は、列挙された要素から任意の単数の実体（例えば、A）、列挙された要素の一部（例えば、AとB）、または要素A、B、Cのすべてを含むものとして解釈されるべきである。
【図１】
2019083013.tif 000004
【図２】
2019083013.tif 000005
【図３】
2019083013.tif 000006
【外国語明細書】
2019083013000001.pdf