JP2022522895A - 暗号通貨用チューリング完全型スマートコントラクト - Google Patents

Abstract

本発明は、暗号通貨において、暗号通貨のブロックチェーン（３）に状態が格納されるスマートコントラクトを実行する方法である。この方法は、スマートコントラクト作成者（１）が、サービスプロバイダー（２）の分散セットを決定し、サービスプロバイダー（２）の分散セットの予め設定された又は設定可能なクォーラムがトランザクションの有効性を保証する場合に、スマートコントラクトを展開して、サービスプロバイダー（２）の分散セットがスマートコントラクトの状態遷移を生じさせるトランザクションを実行できるようにする信頼モデルを定義し、コントラクト実行をサービスプロバイダー（２）の分散セットにオフロードし、クォーラムを得た場合に、トランザクションによって生じた状態遷移をブロックチェーン（３）に含める。【選択図】図１

Description

本発明は、暗号通貨において、暗号通貨のブロックチェーンに状態が格納されるスマートコントラクトを実行するための方法およびシステムに関連する。

２００８年にビットコインが創造されて以来（S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system”を参照）、デジタル通貨の開発は多くの革新をもたらし、ブロックチェーン技術に対する他の潜在的なユースケースへの関心に拍車をかけている。提案されている多くのユースケースは、ブロックチェーンの使用から利益を得られない可能性があるが（K .Wust and A. Gervais, “Do you need a blockchain ? ”,IACR Cryptology ePrint Archive 2017（2017）,375を参照）、汎用スマートコントラクト（N. Szabo, “Formalizing and securing relationships on public networks”, in First Monday 2, 9 (1997)を参照）は、ブロックチェーン技術によって実現された最も有望な技術の１つである。

依然として最も人気のある暗号通貨であるビットコイン（および同様の暗号通貨）は、スクリプト言語を通じてシンプルなスマートコントラクトをすでにサポートしているが、イーサリアム（G. Wood “Ethereum: A secure decentralized generalized transaction ledger” in Ethereum project yellow paper, 2014,を参照)は、ブロックチェーン上で準チューリング完全なコード実行をサポートする最初のブロックチェーンであり、ほぼすべての種類のスマートコントラクトを可能としている。ビットコインを用いてこのような多様なスマートコントラクトを可能とするには、現在ではルートストックなどのサイドチェーン（S. D. Lerner, RSK White paper overview, 2015を参照）が使用されなければならない。つまり、多様なスマートコントラクトは、ビットコインブロックチェーンに状態を記憶したり、ビットコインファンドと直接やり取りしたりすることはできない。

このため、本発明の目的は、多様なスマートコントラクトがいくつかの最小要件を提供するブロックチェーン上で直接有効になるよう、上述したタイプの方法とシステムを改善してさらに改良することにある。さらに、スマートコントラクトの実行が、さまざまな信頼要件に適合するよう柔軟性を有する必要があり、信頼できるサードパーティやその他の単一障害に依存しない必要がある。

本発明では、上記の目的は、暗号通貨において、暗号通貨のブロックチェーンに状態が格納されるスマートコントラクトを実行するための方法によって達成される。その方法は、スマートコントラクト作成者によって、サービスプロバイダーの分散セットを決定し、スマートコントラクトを展開して、サービスプロバイダーの分散セットが、サービスプロバイダーの分散セットにおけるサービスプロバイダーの所定の又は設定されたクォーラムがトランザクションの有効性を保証する場合に、スマートコントラクトの状態遷移を生じさせるトランザクションを実行できるようにする信頼モデルを定義し、サービスプロバイダーの分散セットに対してコントラクト実行をオフロードし、クォーラムに達した場合にトランザクションによって生じた状態遷移をブロックチェーンに含める。

さらに、上記の目的は、暗号通貨において、暗号通貨のブロックチェーンに状態が記憶されるスマートコントラクトを実行するためのシステムによって達成される。このシステムは、複数のサービスプロバイダーを含み、各サービスプロバイダーは、単独又は組み合わせられて、以下のステップを実行するよう設けられた少なくとも１つのプロセッサーを備える。

スマートコントラクト作成者から、スマートコントラクトコード、スマートコントラクト実行パラメーター、および場合によってはスマートコントラクトに送信される資金を含む追加の出力、を含む現在のコントラクトの状態出力を受信し、
受信した現在のコントラクト状態が与えられ、スマートコントラクトを実行して、スマートコントラクトコードのハッシュ、コントラクト実行によって転送された量に応じて更新された値のスマートコントラクト資金、及び新しいコントラクト状態の情報、を含む新しいコントラクトの状態出力を作成し、
スマートコントラクト作成者から受信した現在の状態出力を入力として使用して、新しいコントラクトの状態出力を有するトランザクションを作成し、
トランザクションに署名し、トランザクションと署名との両方をスマートコントラクトの作成者に返送する。

本発明によると、コントラクト実行をスマートコントラクト作成者によって選択されたプロバイダーのセットにオフロードすることによって、多様なスマートコントラクトの実行モデルが使用可能となる得ることがわかる。スマートコントラクトの状態は、コントラクト資金も含むマルチシグ出力（プロバイダーのしきい値数によって使用可能となる）に格納されうる。スマートコントラクトのプログラムロジックに基づいて、プロバイダーは、新しい状態のトランザクション出力を作成し、前の状態を使用するマルチシグトランザクションに署名するように構成されうる。プロバイダーは、ブロックチェーンに含まれているかどうかに関係なく、有効な状態に基づいてスマートコントラクトを実行できるため、ひとたびトランザクションがネットワークにブロードキャストされてブロックチェーンに含まれると、実行に副次的影響がある。これにより、すべてのコントラクトの呼び出しがアトミックに実行され、他のトランザクションとの競合が存在しない場合にのみ、結果がチェーンにコミットされるため、競合状態による誤った結果を引き起こすことなく、複数のスマートコントラクトの高速に独立した並列実行が可能となる。

すでに多様なスマートコントラクトを提供しているイーサリアムなどの暗号通貨の場合においても、本発明による方法とシステムを使用することで、追加の利点を提供することができる。つまり、スマートコントラクトは、ネットワーク内のすべてのノードではなく、少数のノードセットによってのみ実行される必要がある。加えて、実行はオフチェーンで行われるため、イーサリアムにおけるブロックのガスリミットのような制限に伴う計算の複雑さによる制約とは無関係である。スマートコントラクトの実行はブロック間隔に拘束されず、独立したコントラクトに対して完全に非同期で並列に実行できる。これにより、複雑なスマートコントラクトに対するスループットを大幅に向上させることができる。

本発明の実施形態によれば、サービスプロバイダーの分散セットは、Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔｓ（ＴＥＥ）のサポートの有無にかかわらず展開することができる。このようは状況においては、さまざまなプロバイダーが、ビジネスまたは一般のいずれかに関連するコントラクトを実行するサービスを提供できる。信頼性とセキュリティを向上させるために、複数のサービスプロバイダーがスマートコントラクトを実行し、それによって単一障害点を回避することが提供されうる。セキュリティを強化するため、またはサービスプロバイダーが匿名で動作する場合に信頼を提供するために、サービスプロバイダーは、Ｉｎｔｅｌ ＳＧＸなどの信頼できる実行環境内でスマートコントラクトを実行するように構成できる。ただし、本発明によるソリューションは、その展開方法は限定されない。

ある実施形態では、スマートコントラクト作成者が、受け入れ可能な状態遷移の要件を選択できる柔軟な信頼モデルが検討される。例えば、スマートコントラクト作成者は、サービスプロバイダーのセットＥと、必要な署名のしきい値tを選択できる。結果をコミットするトランザクションが実行セットＥのうち少なくともt個のメンバーによって署名された場合には、状態遷移は有効であると見なされる。その延長で考えると、スマートコントラクトの参加者は、選択した信頼モデルに同意する場合のみ、つまりＥのメンバーのうちt未満のメンバーに悪意があるという仮定に同意する場合のみ、その実行に参加する。これにより、ユースケースの要件に応じた柔軟性が得られる。例えば、高い整合性の保証が必要であるが、高可用性は重要ではない場合、スマートコントラクト作成者は、tが｜Ｅ｜に近い大きなＥを選択できる。一方、メンバーの全てに信頼され、高可用性が必要となるようにＥが選択された場合は、ｔ＝１を選択することもできる。

多様なスマートコントラクトの実行を可能にすることについて、実施形態における暗号通貨は、以下の特性（ｉ）－（ｉｖ）を備えるよう構成されてもよい。
（ｉ）補助情報の保存：この特性では、暗号通貨はトランザクションに補助（つまり非資産）情報を保存することを可能にする。一例としては、ビットコインスクリプトにデータを保存する機能である。
（ｉｉ）マルチシグニチャ認証：この特性では、暗号通貨は、例えば、ビットコインのマルチシグ出力のように、一連の参加者に、しきい値数の署名によってトランザクションを集団で認証できるようにするメカニズムを提供する。
（ｉｉｉ）状態依存トランザクションの有効性：トランザクションの有効性は、トランザクションの状態参照に依存されるべきである。つまり、トランザクションは、前のトランザクションがチェーンに含まれ、現在の有効状態になった場合及びその場合にのみ、有効とされるために前のトランザクションを参照すべきである。例えば、ビットコインでは、すべての入力が前のトランザクションの出力であり（つまり、チェーンに含まれている）、入力が使用されていない（つまり、現在の状態を表す）場合にのみ、トランザクションが有効である。
（ｉｖ）アトミックトランザクション：この特性では、暗号通貨は複数の送信元と送信先を有するトランザクションのアトミック性をサポートする。これにより、送信者がコントラクトに送金するコントラクトコールが可能となる。この場合、資産はコントラクトが履行された場合にのみ送金されるべきである。ビットコインなどのＵＴＸＯ（Ｕｎｓｐｅｎｔ Ｔｒａｎｓａｃｔｉｏｎ Ｏｕｔｐｕｔ）ベースの暗号通貨では、トランザクションへの入力として複数のＵＴＸＯを使用し、複数の出力を作成することによって実現される。

実施形態よると、セキュリティを強化して信頼の前提を強化するために、スマートコントラクトが展開され、その実行をＴｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔｓ（ＴＥＥ）内で行うことができる。一般的に、ＴＥＥは、処理、メモリ、およびストレージ機能で構成される安全で整合性が保証された環境である。ＴＥＥを使用して、システムを強化し、匿名のサービスプロバイダーに独自性を提供できる。ＴＥＥは、プロセッサーによって提供される、厳密に定義された入口および出口のメカニズムを備えた独立した環境に実装できる。プロセッサーは、機密性と整合性に関して、ＴＥＥ内にロードされたコードとデータを保護する。実施形態において、ＴＥＥはインテル（登録商標）のソフトウェアガードエクステンションプラットフォームを使用する場合がある。つまり、インテル（登録商標）ソフトウェアガードエクステンション（ＳＧＸ）対応プラットフォームが実行プラットフォームとして使用される。

使用されるＴＥＥが完全に信頼されている場合、リモート認証を使用することによって、スマートコントラクトを実行するための正しい環境が、期待された整合性保護環境で実行されていることを確認できるため、単一のサービスプロバイダーを使用してスマートコントラクトを実行することができる。可用性の理由から、または一部のＴＥＥが危険にさらされる可能性があると想定される場合は、トランザクションを有効として受け入れるためにt-out-of-nサービスプロバイダーが必要とされる上記と同様のクォーラムベースの設計を実装できる。

本発明によるシステムへのサービスプロバイダーの参加を奨励するために、様々な報酬モデルが実装されうる。例えば、サービスプロバイダーが十分に確立されたエンティティである場合、既存のクラウドプロバイダーと同様に、スマートコントラクトを実行するためのサブスクリプションモデルを提供できる。この場合、スマートコントラクトを実行する責任を補償するために、例えばスマートコントラクト作成者などから任意の手段で定期的な支払いを受け取ることができる。このことは、サービス内容合意書に組み込むこともできる。

代替的または追加的に、報酬サービスプロバイダーは、固有のトランザクション手数料に基づいて実行されうる。この場合、システムは、スマートコントラクト言語における各運用が計算の複雑さに基づいて何らかの値が割り当てられるイーサリアムのガスモデルと同様に、固定（つまり、計算量ごと）のトランザクション料金で展開することができる。このシナリオでは、イーサリアムと同様に、クライアントは「計算単位あたりの価格」（イーサリアムのガスに相当）を規定することができる。これにより、計算の複雑さの合計が基礎となる暗号通貨の金額に変換され、実行の結果として生じるトランザクションに対してサービスプロバイダーに支払われる。

さらに別の代替案では、サービスプロバイダーの柔軟な報酬を伴うモデルを実装することができる。スマートコントラクトは多様な言語で書かれているため、手数料はコントラクト自体の中で実装することができる。つまり、実行条件自体がスマートコントラクトの一部となる。サービスプロバイダーは、これらの条件を調べて、結果として生じる料金が納得できる場合は、スマートコントラクトを実行できる。スマートコントラクトは、結果として生じるトランザクションの一部として、サービスプロバイダーへの支払いを開始する場合がある。

本発明における教示内容を設計し、さらに発展させる好適な方法はいくつかある。このため、一方では、従属請求項を参照し、他方では、図面によって示されるような例示の方法による本発明の実施形態の説明を参照する必要がある。図面を用いた本発明の好ましい実施形態の説明に関連して、一般的に好ましい実施形態と教示内容のさらなる改良が説明されうる。

本発明の実施形態におけるコントラクトコール中に交換されたメッセージを表すシーケンス図である。

ビットコイン（および同様の暗号通貨）は、スマートコントラクトの作成を可能としているが、イーサリアムなどのスマートコントラクトプラットフォームによって提供される表現力に欠けている。ルートストックなどのプロジェクトは、ビットコインでより多様なスマートコントラクトを可能にすることを目的としている。しかしながら、そのようなプロジェクトでは、ビットコインのメインチェーンからサイドチェーンへの資金の移動が必要であり、つまり、ビットコインの資金と直接やり取りすることはできない。

このため、本発明の実施形態では、ほぼ任意の暗号通貨において多様なスマートコントラクトの実行を可能にすることを目的とする。これに関連して、汎用スマートコントラクトを使用して暗号通貨システムを拡張し、そのような拡張を提供するために必要な最小構成を、以下に詳しく説明する。一例としては、ＵＴＸＯベースであり、あるメカニズム（ビットコインのスクリプトへのデータ保存など）で任意のデータを保存できるほか、マルチシグ出力を作成する可能性を提供する、ビットコインおよび同様の暗号通貨がある。本発明の実施形態によれば、これらの特性を利用することにより、例えば、他のアドレスに送金したりオンチェーンに状態を格納するというように、スマートコントラクトがオンチェーン資金と直接やり取りすることが可能となる。

本発明の実施形態は、いくつかの最低限の構成を備えており、いかなる暗号通貨においてもスマートコントラクトの実行を可能とするシステムおよび方法に関する。暗号通貨が備えていなければならないこれら最低限の構成は、以下に詳しく説明する。ある実施形態では、スマートコントラクトは、サービスプロバイダーのセットによって実行され、そのクォーラムは、ブロックチェーンに状態変更をコミットするために必要とされる。サービスプロバイダーは、コントラクト作成者によって選択され、すべての参加者に知られている。スマートコントラクトに参加することにより、参加者は、サービスプロバイダーの十分大きな一部が正当な行動をとることを暗黙のうちに信頼している。

スマートコントラクトの実行では、サービスプロバイダー間で合意プロトコルを実行する必要はない。代わりに、十分な数の責任あるサービスプロバイダーがコントラクトの署名をした場合、コントラクトの状態を変更するトランザクションは有効であるとすべきである。ある実施形態においては、スマートコントラクトは、入力状態が前のオンチェーン状態であった場合に、ブロックチェーンの有効性ルールによって受け入れられる状態遷移として実行されるべきである。このようにして、サービスプロバイダーは完全にステートレスで実行されるため、相互間で合意プロトコルを実行することで一貫性を保つ必要はない。

永続記憶装置を提供するスマートコントラクトを備えたシステムをサポートするために、サービスプロバイダーがステートレスであることが望ましい場合、暗号通貨はデータの記憶をサポートする必要がある。コントラクトの状態をチェーンに記憶することで、すべてのコントラクト参加者が最新の状態を受け取り、スマートコントラクトとの対話を継続できるよう保証される。

さらに、サービスプロバイダーのクォーラムが遷移の有効性を保証する場合に、サービスプロバイダーの分散セットが状態遷移を実行できるようにするには、暗号通貨がマルチシグネチャーの形式をサポートする必要がある。これにより、十分な数のサービスプロバイダーが状態遷移に署名した場合にのみ、スマートコントラクトの状態変更がチェーンにコミットされることが保証される。

サービスプロバイダーはステートレスである必要があるため、暗号通貨のトランザクション有効性ルールでは、トランザクションの有効性を前の状態で条件付けできるようにする必要がある。たとえば、トランザクションは、あるアカウントまたはアドレスからの最新のトランザクションは固有のハッシュを有することが必要となりうる。ビットコインおよび同様の通貨では、トランザクションは、すべての入力が以前に未使用の出力である場合にのみ有効であるため、ＵＴＸＯモデルを通じて明らかにサポートされる。これらの出力の１つがスマートコントラクトの状態を記憶するために使用される場合、これに基づく状態遷移を含むトランザクションは、対立しない状態遷移がコミットされている場合にのみ有効になる。

最後に、スマートコントラクトは、スマートコントラクトコールで資金を送受信できる必要がある。これには、複数の送信元と複数の送信先を持つアトミックトランザクションが可能でなければならないことが必要である。ＵＴＸＯベースの暗号通貨では、さまざまな参加者から入力としてＵＴＸＯを使用するトランザクションを作成し、複数の出力を作成することで、簡単に実行することができる。他の暗号通貨では、他のメカニズムによってアトミック性が保証されている複数のトランザクションを作成する必要がありうる。

図１は、本発明の実施形態における暗号通貨でスマートコントラクトを実行するためのシステムを示す。図示されたシステムは、スマートコントラクトを実行することができる、プロバイダセットＰと呼ばれるサービスプロバイダー２のセットを含む。

初期化時には、各プロバイダー２は、トランザクションを送受信するためのキーペアを作成し、公開キーを公開することができる。これはいくつかの方法で行うことができる。例えば、プロバイダー２は、公開キーを暗号通貨のブロックチェーン３で公開したり、公開されている有効なウェブサイトで公開キーにアクセスできるようにしたり、あるいは、プロバイダー２がすべてのエンティティにサービスを利用できるようにするつもりがない場合には、スマートコントラクト作成者１（図１では「クライアント」と示す）に公開キーを直接送信することもできる。サービスプロバイダー２のセットＰが与えられると、クライアント1が展開でき、後にスマートコントラクトと対話することができる。

以下では、簡単で読みやすくするために、特に明記されていない限り、システムは、ＵＴＸＯモデルを使用した暗号通貨に基づいて記載される。ただし、上記で規定された必要なプロパティが提供されている場合、本発明におけるシステムおよび方法は、アカウントベースモデルにも同様に適用可能である。例えば、アカウントモデルでは、状態出力に相当するものはデータ（トランザクションなど）の保存場所であり、結果として生じるトランザクションに入力として前の状態出力を含める代わりに、例えば、ハッシュを使用して以前のトランザクションを参照することによって、トランザクションの有効性は前の状態が条件とされうる（例えば、"https：//developers.ripple.com/transaction-common-fields.html#accounttxnid"で参照される AccountTxnIDin Rippleなどのメカニズムを使用する）。

本発明の実施形態では、スマートコントラクトは、任意の言語で書かれたコードの一部と、ブロックチェーンに格納されたコントラクト状態とで構成されうる。スマートコントラクトコードのハッシュ、資金、およびコントラクトの状態は、サービスプロバイダーのクォーラムが使用できるいわゆる状態出力に格納されうる。この出力では、コントラクトの状態をKey-Valueストアとして格納でき、これにより、コントラクトの実行中に状態を容易に検索することができる。

スマートコントラクトを展開するために、クライアント１（またはスマートコントラクト作成者）は、任意のサイズｎの実行サブセットＥ⊆Ｐと、セットＥのうちスマートコントラクトの実行が正しいことを保証する必要があるプロバイダーの数ｔを記述するt-out-of-n信頼モデルと、を選択することができる。クライアント１は、その後、出力の１つがセットＥ内のｔ個のサービスプロバイダー２からの署名とともに使用されたt-out-of-nマルチシグ出力であるトランザクションを作成することができる。

この出力には、コントラクトコードのハッシュ、初期コントラクト状態、初期資金が含まれる場合がある。この出力は、スマートコントラクトの初期状態の出力である。クライアント１は、その後、トランザクションをブロードキャストし、スマートコントラクトと対話できるはずの他の参加者にコードを利用できるようにすることができる。コントラクトがいずれかのエンティティで利用可能である必要がある場合、クライアント１は、コントラクト作成トランザクションの個別のトランザクション出力でコントラクトコードを公開することもできる。あるいは、クライアント１は、公開されている有効なウェブサイトでコードを公開することもできる。

サブセットＥ⊆Ｐとt-out-of-n信頼モデルは、スマートコントラクトの作成者１が、ニーズに合わせて選択できる。信頼の仮定、整合性、および可用性の間にはトレードオフの関係がある。非常に保守的な仮定、つまり、セットＰ内の１つのプロバイダー２を除くすべてが悪意ある可能性がある場合、クライアント１はn-out-of-n信頼モデルでＥ＝Ｐを選択できる。これにより、少なくとも１つの悪意あるプロバイダー２が与えられた場合、誤った実行結果がコミットされないことが保証される。ただし、１つ以上のプロバイダー２がオフラインになると操作が停止するため、可用性が犠牲になる（ｎが大きい場合、トランザクションが大きいために効率が犠牲になる）。

もう一方の極端な例として、クライアント１はＥ＝Ｐで1-out-of-n信頼モデルを選択できる。これにより、整合性を失うために悪意あるプロバイダー２が１つだけ必要となるが、高可用性が許容されうる。最終的に、作成者１とスマートコントラクト参加者は、ユースケースに適したバランスを見つける必要がある。

スマートコントラクトを実行するには、クライアント１はセットＥのうちｎ個のプロバイダー２の少なくともt個に接続してスマートコントラクトを実行する必要がある。接続先のプロバイダー２の１つが応答しない場合、クライアント１は追加のプロバイダーに接続する必要がある。

本発明の実施形態における、コントラクトの呼び出し及び実行のシーケンス図を図１に示す。実施形態では、クライアント1は最初にブロックチェーン３からコントラクトの現在の状態出力（Out_i）をフェッチする。クライアント１は、接続先のプロバイダー２のそれぞれに、スマートコントラクトコード、スマートコントラクト実行のパラメーター、およびスマートコントラクトに送信される資金を含む追加の出力とともに、現在の状態出力を送信する（要約された補助入力（InAux）として）。

次に、プロバイダー２は以下のように作動する。
（１）プロバイダー２は、コントラクトコードをハッシュし、状態出力に格納されているハッシュ値と比較する。値が一致する場合、プロバイダー２は続行し、一致しない場合は中止する。
（２）次に、プロバイダー２は、状態出力から状態をロードする。
（３）状態、パラメーター、および追加の入力が与えられると、プロバイダー２はスマートコントラクトを実行する。このコントラクトの実行により、コントラクトの状態が変更され、他のアドレスへの資金の転送が開始される。
（４）スマートコントラクトの実行により資金が別のアドレスに転送されると、プロバイダー２は、対応する値を使用して、そのアドレスによって使用できるトランザクション出力を作成する。
（５）プロバイダー２は、コントラクトコードのハッシュ、受信された／使用された量に応じて更新された値を持つスマートコントラクト資金、および新しい状態情報を含む、新しい状態出力（Ｅからｔ個のプロバイダー２によって再び使用できる）を作成する。
（６）プロバイダー２は、最終的に、上述したようにクライアント１によって与えられた入力と共に古い状態出力を入力として使用された上記出力と共にトランザクションを作成する。そして、プロバイダー２は、その後、トランザクションに署名し、トランザクション（Ｔ）と署名（σ_Pk（Ｔ））の両方をクライアント１に送り返す。

クライアント１は、各プロバイダー２から上記トランザクションを受信する。コントラクトの実行は決定論的であるため、各プロバイダー２は同じトランザクションを作成し、そのトランザクションに署名を提供する。ｔ個のプロバイダー２から署名が与えられると、クライアント１はトランザクションをブロードキャストでき、トランザクションはブロックチェーン３に含められうる。

実施形態では、ＴＥＥが使用される場合、サービスプロバイダー２は、ＴＥＥ内にスマートコントラクトのインタプリタとして機能するよう構成されたハードウェアまたはソフトウェアにより実装されたコンポーネントを実行し、クライアント１に正しいコードが実行されていることを証明する証明ステートメントを提供する。ＴＥＥ内で、サービスプロバイダー２は、最初に秘密鍵／公開鍵のペアを作成することができる（秘密鍵はＴＥＥにのみ知られている）。証明の際に、公開鍵をステートメントに含めてもよく、これにより、クライアント１は、鍵が正しく作成されたことを確認できる。公開鍵のセットが与えられると、クライアント１は、上記のようにスマートコントラクトの展開を続行する。

スマートコントラクトの実行がＴＥＥ内で実行される場合、コントラクトの実行、結果として生じるトランザクションの作成、およびトランザクションへの署名が、各サービスプロバイダー２のＴＥＥ内で実行される差異があるものの、スマートコントラクトの呼び出しは、上述したプロトコルに類似して開始される。

実施形態におけるシステムは、スマートコントラクトの依存関係を処理するよう構成されている。他のスマートコントラクトを呼び出すスマートコントラクトの場合、（ｉ）コール全体（サブコールを含む）がアトミックに実行され、（ｉｉ）各コントラクトの選択された信頼モデルが与えられて実行の整合性が保証される、ことが保証されなければならない。これは、全てのコントラクトの状態変更が、全ての関連するスマートコントラクトのプロバイダー２からのクォーラムによって署名されたトランザクション（またはアトミックに実行されるトランザクションのシーケンス）でコミットされる方法で実現できる。

サブコールを使用してコントラクトコールを実行するためには、クライアント１は、状態出力とすべての関連するコントラクトのコードを、補助入力とともにすべてのサービスプロバイダー２に送信する必要がある。次に、サービスプロバイダー２は、上記と同様にステップ（１）～（６）を実行し、すべての関係するコントラクトのコードハッシュをチェックし、完全なコールチェーンを実行する。すべての関連するコントラクトのマルチシグ条件を満たしている場合にのみ、その結果のトランザクションがブロックチェーン３に含められるため、これにより、すべてのクォーラムに達した場合にのみすべての状態変更が適用される。

本発明の多くの変形例および実施形態は、上述した説明および関連する図面に記載された説明により、本発明が関係する当業者には実施可能であろう。従って、本発明は、開示された特定の実施形態に限定されるものではなく、変形例および実施形態は添付の特許請求の範囲内に含まれることが意図されていることを理解されたい。本明細書では特定の用語が使用されているが、それらは一般的かつ説明的な意味でのみ使用されており、限定の目的では使用されていない。

Claims (15)

1. 暗号通貨において、暗号通貨のブロックチェーン（３）に状態が格納されるスマートコントラクトを実行する方法であって、
   スマートコントラクト作成者（１）が、
   サービスプロバイダー（２）の分散セットを決定し、
   前記サービスプロバイダー（２）の分散セットの予め設定された又は設定可能なクォーラムがトランザクションの有効性を保証する場合に、スマートコントラクトを展開して、前記サービスプロバイダー（２）の分散セットがスマートコントラクトの状態遷移を生じさせるトランザクションを実行できるようにする信頼モデルを定義し、
   コントラクト実行を前記サービスプロバイダー（２）の分散セットにオフロードし、前記クォーラムを得た場合に、トランザクションによって生じた状態遷移をブロックチェーン（３）に含める、
   ことを特徴とする方法。
2. スマートコントラクトを展開する際に、前記スマートコントラクト作成者（１）が、
   前記サービスプロバイダー（２）の分散セットから、任意の数ｎのサービスプロバイダー（２）を含むコントラクト実行サブセットを選択し、
   トランザクションによるそれぞれのコントラクトの状態遷移が有効と見なされるようなトランザクションに署名する必要があるコントラクト実行サブセットのうちのサービスプロバイダー（２）の数をｔとするt-out-of-n信頼モデルを決定する、
   ことを含むことを特徴とする請求項１に記載の方法。
3. スマートコントラクトを展開する際に、前記スマートコントラクト作成者（１）が、
   トランザクションを作成して、スマートコントラクトの初期状態出力を生成し、
   前記サービスプロバイダー（２）の分散セットを構成するサービスプロバイダー（２）に、トランザクションとスマートコントラクトコードを通知する、
   ことを特徴とする請求項２に記載の方法。
4. 前記サービスプロバイダー（２）の分散セットを構成するサービスプロバイダー（２）は、相互に合意プロトコルを実行することなくステートレス機能が実装されている、
   ことを特徴とする請求項１乃至３のいずれかに記載の方法。
5. スマートコントラクトの状態が、スマートコントラクトの資金も含むマルチシグネチャー出力に格納される、
   ことを特徴とする請求項１乃至４のいずれかに記載の方法。
6. スマートコントラクトは、入力状態が前のオンチェーン状態であった場合に、ブロックチェーン（３）の有効性ルールによって受け入れられるコントラクトの状態遷移として実行されるように構成される、
   ことを特徴とする請求項１乃至５のいずれかに記載の方法。
7. スマートコントラクトが、Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ（ＴＥＥ）内で実行される、
   ことを特徴とする請求項１乃至から６のいずれかに記載の方法。
8. 前記ＴＥＥが、ソフトウェアガードエクステンションプラットフォームを使用する、
   ことを特徴とする請求項７に記載の方法。
9. 前記サービスプロバイダー（２）の分散セットを構成するサービスプロバイダー（２）は、スマートコントラクト実行に対するサブスクリプションモデルを提供する、
   ことを特徴とする請求項１乃至８のいずれかに記載の方法。
10. 前記サービスプロバイダー（２）の分散セットを構成するサービスプロバイダー（２）は、実行されたトランザクションに対して単位計算量当たりに割り当てられた金額を得る、
    請求項１から９のいずれかに記載の方法。
11. スマートコントラクトトランザクション実行の条件がスマートコントラクト内に実装されている、
    ことを特徴とする請求項１乃至１０のいずれかに記載の方法。
12. スマートコントラクトが少なくとも１つの他のスマートコントラクトを呼び出すサブコールを含むスマートコントラクトコールが、全ての関連するスマートコントラクトに対して、全ての関連するスマートコントラクトに対するサービスプロバイダー（２）のクォーラムによってアトミックに署名が実行されたトランザクション又は一連のトランザクションを伴うコミット状態トランザクションによって実行される、
    ことを特徴とする請求項１乃至１１のいずれかに記載の方法。
13. 暗号通貨において、暗号通貨のブロックチェーン（３）に状態が格納されるスマートコントラクトを実行し、請求項１乃至１２のいずれかに記載の方法を実行するシステムであって、
    複数のサービスプロバイダー（２）を備え、
    サービスプロバイダー（２）のそれぞれは、単独または組み合わせられた少なくとも１つのプロセッサーを備えており、
    さらに、サービスプロバイダー（２）のそれぞれは、
    スマートコントラクト作成者（１）から、スマートコントラクトコード、スマートコントラクト実行のパラメーター、およびスマートコントラクトに送信される資金を含む追加の出力、を含む現在のコントラクトの状態出力を受信し、
    受信した現在のコントラクト状態を前提として、スマートコントラクトを実行し、スマートコントラクトコードのハッシュ、コントラクトの実行によって転送された量に応じて更新された値のスマートコントラクト資金、及び新しいコントラクトの状態情報、を含む新しいコントラクトの状態出力を作成し、
    スマートコントラクト作成者（１）から受信した現在の状態出力を入力として使用する新しいコントラクトの状態出力を有するトランザクションを作成し、
    トランザクションに署名して、トランザクションとトランザクションの署名との両方をスマートコントラクト作成者（１）に返送する、
    ことを特徴とするシステム。
14. サービスプロバイダー（２）の少なくとも１つ以上のプロセッサーは、
    スマートコントラクト作成者（１）から受信した現在のコントラクトの状態出力からスマートコントラクトコードをハッシュし、当該ハッシュされたスマートコントラクトコードをサービスプロバイダー（２）によって格納された状態出力内のハッシュ値と比較し、
    両方の値が一致する場合にのみ、スマートコントラクトの実行を続行する、
    ことを特徴とする請求項１３に記載のシステム。
15. サービスプロバイダー（２）の少なくとも１つ以上のプロセッサーは、
    スマートコントラクト実行により資金が別のアドレスに転送された場合に、対応する値のアドレスによって使用可能なトランザクション出力を作成する、
    ことを特徴とする請求項１３又は１４に記載のシステム。

Images