(57)【要約】  ブロックチェーン内のブロックを当該ブロックチェーンに追加するステップは、主体に一つ前のブロックに対応する情報を受信させるステップと、主体に所与の入力に対してスマート契約実行の宣言的発動を受信させ、宣言的発動が実行に関連する結果及び他の関連データを宣言するステップと、主体に発動の構文的有効性を検証させるステップと、主体に、発動の構文的有効性を検証したことに応答して宣言的発動をブロックに組み込ませるステップとを含んでいる。関連結果は、スマート契約実行の正味効果、スマート契約実行後に生じた状態、及び実行ステップ数を指定することができる。他の関連データは、宣言的発動の呼出者、時間情報、ブロック情報、及び／又は支払うべき対価を指定することができる。【選択図】図２
2020537391.tif 000002
【特許請求の範囲】
【請求項１】
複数の取引が複数のブロックに編成された取引システムにおいて、一連の以前のブロックＢ0，Ｂ1，．．．，Ｂr-1に対して新規ブロックＢr及びＢr+1を提供する方法であって、
前記ブロックＢrが前記ブロックＢr-1における取引の状態と整合する取引の初期状態を示すことを確認した後で前記ブロックＢrを構築するステップと、
前記ブロックＢr+1が前記ブロックＢrにおける取引の状態と整合する取引の初期状態を示すことを確認した後で前記ブロックＢr+1を構築するステップと、
複数の主体に、前記ブロックＢr+1が構築された後で前記ブロックＢrの未検証の取引を検証させるステップとを含む方法。
【請求項２】
前記複数の取引がスマート契約である、請求項１に記載の方法。
【請求項３】
ユーザーが、前記スマート契約のうち少なくとも１個に関する取引を前記ブロックＢrに記録する前提で前記ブロックＢrを構築する、請求項２に記載の方法。
【請求項４】
前記ユーザーが、前記スマート契約に関する取引結果も前記ブロックＢrに記録する、請求項３に記載の方法。
【請求項５】
前記ユーザーが、前記スマート契約に関する前記スマート契約の結果を得るのに要するステップ数も前記ブロックＢrに記録する、請求項４に記載の方法。
【請求項６】
前記ユーザーが、前記複数の主体が前記ブロックＢrの取引を検証することで受け取る対価も記録する、請求項５に記載の方法。
【請求項７】
前記複数の主体が、前記ブロックＢrの全てのユーザーの部分集合である、請求項１に記載の方法。
【請求項８】
前記複数の主体が無作為に選択されている、請求項７に記載の方法。
【請求項９】
前記複数の主体を無作為に選択するステップが、時間情報、１個以上のブロックに関する情報、前記１個以上のブロックに含まれるデータ、又は前記１個以上のブロックから推論されたデータのうち少なくとも１個を含むデータに暗号ハッシュ関数を適用するステップを含んでいる、請求項８に記載の方法。
【請求項１０】
ブロックチェーン内のブロックＢを前記ブロックチェーンに追加する方法であって、
主体に、一つ前のブロックに対応する情報を受信させるステップと、
前記主体に、所与の入力に対してスマート契約実行の宣言的発動を受信させ、前記宣言的発動が前記実行に関連する結果及び他の関連データを宣言するステップと、
前記主体に、前記発動の構文的有効性を検証させるステップと、
前記主体に、前記発動の前記構文的有効性を検証したことに応答して前記宣言的発動を前記ブロックＢに組み込ませるステップとを含む方法。
【請求項１１】
前記関連結果が、前記スマート契約実行の正味効果、前記スマート契約実行後に生じた状態、及び実行ステップ数のうち少なくとも１個を指定し、前記他の関連データが、前記宣言的発動の呼出者、時間情報、ブロック情報、及び支払うべき対価のうち少なくとも１個を指定する、請求項１０に記載の方法。
【請求項１２】
前記宣言的発動が構文的に有効であるのは、前記対価が前記実行ステップ数に相応であり、且つ前記対価の支払者が前記対価を支払うのに充分な資産を有している場合であり、前記宣言的発動が前記ブロックチェーンに出現したならば前記対価が支払われる、請求項１１に記載の方法。
【請求項１３】
ブロックチェーン内の検証者の集合を、所与の入力に対してスマート契約実行の１個以上の宣言的発動の集合Ｓを検証すべく割り当て、前記宣言的発動が前記スマート契約実行の関連結果を宣言する方法であって、
前記検証者が前記集合Ｓを受信するステップと、
前記検証者がＳ内の前記宣言的発動のどれが意味論的に有効であるかを判定するステップと、
前記検証者が意味論的に有効な前記１個以上の宣言的発動の認証された応答を提供するステップとを含む方法。
【請求項１４】
前記検証者の集合がＳに基づいて所与の暗号関数を介して疑似乱数的に選択される、請求項１３に記載の方法。
【請求項１５】
少なくとも一人の検証者が、前記少なくとも一人の検証者の秘密鍵を用いる計算を介して前記少なくとも一人の検証者が選択されていると判定し、前記少なくとも一人の検証者が、前記少なくとも一人の検証者が選択されたということを他者に対して証明することができる、請求項１４に記載の方法。
【請求項１６】
Ｓ内の発動Ｉが正しいと考えられるのは、Ｉが意味論的に正しいことを、Ｓに割り当てられた少なくとも所与の人数の検証者の応答が示している場合である、請求項１３に記載の方法。
【請求項１７】
宣言的スマート契約発動の集合Ｓが既に登録され、検証者の集合がＳに割り当てられていて、前記Ｓの発動のどれが意味論的に有効であるかに関する認証された応答を前記検証者が提供しているブロックチェーンにおいて、前記Ｓの発動の評決を前記ブロックチェーンに組み込む方法であって、
主体に、前記検証者の前記認証された応答を受信させるステップと、
前記主体に、前記Ｓの発動の正しさを推論させるステップと、
前記主体に、前記Ｓの発動の正しさに関する最終評決を前記ブロックチェーンに組み込ませるステップとを含む方法。
【請求項１８】
Ｓ内の発動Ｉの最終評決が、Ｓに割り当てられた少なくとも所与の人数の前記検証者の前記応答が、Ｉが意味論的に有効であることを示している場合Ｉが正しいことを示している、請求項１７に記載の方法。
【請求項１９】
Ｓの発動Ｉの最終評決が、Ｉが正しいことを示している場合、他のユーザーに前記スマート契約の状態を更新させ、前記スマート契約の実行の宣言された正味効果が発現したと思わせる、請求項１７に記載の方法。
【請求項２０】
ブロックチェーン内のブロックＢを前記ブロックチェーンに追加する方法であって、
主体に、一つ前のブロックに対応する情報を受信させるステップと、
所与の入力に対してスマート契約実行の確約された宣言的発動を受信させ、前記確約された宣言的発動が、前記実行の少なくともいくつかの関連結果、前記実行の他の関連結果の確約、及び他の関連データを宣言するステップと、
前記確約された宣言的発動の構文的有効性を確認させるステップと、
前記確約された宣言的発動の前記構文的有効性の検証に応答して前記確約された宣言的発動を前記ブロックＢに組み込むステップとを含む方法。
【請求項２１】
前記関連結果が、実行の正味効果、前記契約の実行後に生じた状態、及びステップ数のうち少なくとも１個を指定し、前記他の関連データが、前記発動の呼出者、時間情報、ブロック情報、及び支払うべき対価のうち少なくとも１個を指定する、請求項２０に記載の方法。
【請求項２２】
前記宣言的発動が構文的に有効なのは前記対価が前記ステップ数に相応であり、且つ前記対価の支払者が前記対価を支払うのに充分な資産をシステム内に有している場合であり、前記発動が前記ブロックチェーン内に出現したならば前記対価が支払われる、請求項２１に記載の方法。
【請求項２３】
ブロックチェーン内の検証者の集合を、所与の入力に対してスマート契約の実行ｅを指定する少なくとも１個の確約された宣言的発動Ｉを含む宣言的発動の集合Ｓを検証すべく割り当て、Ｉがｅの少なくともいくつかの関連結果ｒｒに対する確約を含む方法であって、
前記検証者が前記集合Ｓを受信するステップと、
前記検証者が前記関連結果ｒｒを計算すべく実行ｅを再構築するステップと、
前記検証者が、前記検証者のｒｒに対する個人化された確約を含む認証された応答を提供するステップとを含む方法。
【請求項２４】
割り当てられた検証者がＳに基づいて、所与の暗号関数を介して疑似乱数的に選択される、請求項２３に記載の方法。
【請求項２５】
少なくとも一人の検証者が、前記少なくとも１人の検証者の秘密鍵を用いる計算を介して前記少なくとも１人の検証者が選択されていることを判定することができ、前記少なくとも１人の検証者が他者に対して、前記少なくとも１人の検証者が選択されていることを証明することができる、請求項２３に記載の方法。
【請求項２６】
前記Ｓ内の確約された宣言的発動Ｉが正しいと考えられるのは、Ｓに割り当てられた少なくとも所与の人数の検証者の応答が、Ｉで確約された前記関連結果ｒｒに対する個人化された確約を含む場合だけである、請求項２３に記載の方法。
【請求項２７】
宣言的スマート契約発動の集合Ｓが既に登録され、検証者の集合がＳに割り当てられていて、前記集合Ｓが、所与の入力に対してスマート契約の実行ｅを指定する少なくとも１個の確約された宣言的発動Ｉを含み、Ｉがｅの少なくともいくつかの関連結果ｒｒに対する確約を含み、前記検証者が前記Ｓの発動に関する認証された応答を提供しているブロックチェーンにおいて、前記Ｓの発動の評決を前記ブロックチェーンに組み込む方法であって、
主体に、前記検証者の前記認証された応答を受信させるステップと、
前記主体に、前記Ｓの発動の正しさを推論させるステップと、
前記主体に、前記Ｓの発動の正しさに関する最終評決を前記ブロックチェーンに組み込ませるステップとを含む方法。
【請求項２８】
Ｓに割り当てられた少なくとも所与の人数の前記検証者の応答が、Ｉに対して確約されたものと前記同じ関連結果ｒｒに対する個人化された確約を含み、Ｓ内の前記確約された宣言的発動Ｉの最終評決が、Ｉが正しいことを示している、請求項２７に記載の方法。
【請求項２９】
前記Ｉの正しさの最終評決が、他のユーザーに前記スマート契約の状態を更新させ、前記スマート契約の実行ｅの正味効果が発現したと思わせる、請求項２８に記載の方法。
【請求項３０】
非一時的コンピュータ可読媒体で提供されるコンピュータソフトウェアであって、
請求項１〜２９のいずれか１項に記載の方法を実装する実行可能コードを含むコンピュータソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は電子取引の分野に関し、特に電子取引で用いる一連の取引ブロックの内容のセキュリティを確保する分野に関する。
【背景技術】
【０００２】
スマート契約とは、ユーザーと同様に、自身の資金を所有できるコンピュータプログラムであると考えてよい。このような契約Ｃは、恐らく毎回の発動後に変更される、自身の保持された（計算上の）状態、及び自身の識別子、例えばストリングＨ（Ｃ）、但しＨはハッシュ関数、を有していてよい。簡潔のため、当該識別子をそのままＣと表記する。読者は、Ｃがプログラム自体であるか又は識別子であるかを容易に判別することができる。好適には、スマート契約Ｃは通常のユーザーから容易に区別できる。プレーヤーは、スマート契約又は通常のユーザーのいずれかを意味する。
【０００３】
スマート契約Ｃの実行は、一人以上の適切なユーザーにより発動することができる。簡潔のため、但し一般性を一切失うことを意図することなく、本明細書ではＣが単一ユーザーｉにより発動されるものと仮定する（脚注１：要するに、Ｃが複数のユーザーにより発動できる場合、往々にして一人のユーザーが最初にＣを実行し、別の適切なユーザーがＣを発動する前に、Ｃの保持された状態を変更する。Ｃが無状態の場合、適切なユーザーの順序は重要ではない。そうでない場合、例えば二人の適切なユーザーが同時に独立にＣを発動したならば、一方が二つの実行の順序を選択して、第２の実行を開始する前に、第１の実行が「終了」するまで待つことができる。当業者には、複数のユーザーによりＣが発動された場合のみ、実際には「システムにより」実行されるようにＣを書くことができ、且つこれらの契約を発明者らの技術で扱えることが理解されよう。）
【０００４】
ｉを、Ｃのシステムの実行を発動できるユーザーとする。ユーザーｉはデジタル署名によりＣを発動する。そのようなｉの署名された発動は、Ｃに加え、入力（ｉｎｐｕｔ）、及び対価（ｆｅｅ）を指定することができる。以下に説明する。
【０００５】
・ｉｎｐｕｔは、Ｃ実行する際の特定の入力の詳細を示す。無論、既定値入力、例えば、Ｃの現在状態、γC（実際に入力と考えてよい）及びシステムの大域的状態（例えば、所与のブロックで各プレーヤーが所有する金額）等の追加的な入力があってよい。
・ｆｅｅは、「Ｃの実行に要した計算コストを補償するシステム」に対してｉが支払うべき金額を含んでいる。
【０００６】
ユーザーｉはまた、Ｃを発動する際に、何らかの追加的な情報を指定することができる。例えば、所与のブロック、従ってブロックチェーン内の所与の「スナップショット」を指定すること、又は契約Ｃの実行が所与のブロック又はブロックの間隔に影響を及ぼすことができる。また、Ｃがこれまでのブロックチェーンの履歴全体を考慮に入れることができると考えてもよい。要するに、追加的な（恐らくは暗示的）入力もあり得る。
【０００７】
対価は、ｉが、他の任意の取引と同様に、自身の発動をブロックチェーンに含めるために払う必要がある金額も含んでいてよい。しかし、新規な本発明により軽減される問題に注目すべく、後者の従来型対価を無視することにする。
【０００８】
Ｃの実行における計算ステップ数は、実行されるマシンに依存する。従って、固定された（仮想）マシンＭ上でＣ（ｉｎｐｕｔ）を計算する場合を考える。
【０００９】
Ｃの実行により一般に、新たに保持された状態
【数１】
2020537391.tif 000003
を生成し、数人のプレーヤー、ｘ，ｙ，．．．，が所有する、次式で表す金額を増減させる。
【数２】
2020537391.tif 000004
【００１０】
ユーザーｉにより署名されたＣの発動は、所与のブロック内のブロックチェーンに入ることができるのは、ｉが当該時点でｆｅｅ、すなわちｉの発動時に指定された対価以上の資金量を所有している場合だけである。
【００１１】
従来の（例えば、一時的な）方法は、発動が実際に一回の実行に対応するのを防止するために用いる。このような方法は、目下の問題及び発明にとって重要ではないため、一般性を一切失うことを意図することなく、本明細書では無視する。他のあらゆる種類の発明とは無関係な詳細事項についても同様である。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ｉの発動がブロックチェーンのあるブロックに入ったならば、ユーザーのクラスＵの各ユーザーｕは、ｆｅｅがカバーするステップの金額に対してＣを（仮想マシンＭ上で、Ｃが到達した最後の保持された状態を用いて）実行し、ｉが所有する金額から対価を減算することにより自身のブロックチェーンデータのバージョンを更新して、実行が適切に終了したならば、Ｃの実行に影響されたプレーヤーが所有する（Ｃ自体が所有する金額を恐らく含む）金額を（再び、ブロックチェーンの自身のバージョンで）変更する。そのような全てのユーザーによるＣの実行をＣのシステム実行と称する場合がある。典型的に、クラスＵは、全てのユーザー又は極めて多くのユーザー（例えば、ブロックチェーン内における新規の有効なブロックの生成に寄与したい全てのユーザー）を含んでいる。
【００１３】
ユーザー数が多い場合、ステップ数が若干少なくてもシステムの総コストが極めて大きくなる場合がある。これは、ステップ数は全く多くないにもかかわらず、発動者により支払うべき対価も極めて高いのに違いないことを示唆している。この状況において、ブロックチェーンシステムでは、必要とするステップ数が少ないスマート契約だけを実行することに意味がある。これは惜しむべきである。システム内のユーザーは、無視できない数の計算ステップを要する多くのスマート契約の実行を発動することで利点が得られるが、自身が払うべき対価が膨大なため発動が阻害される。
【課題を解決するための手段】
【００１４】
本明細書に記述するシステムによれば、複数の取引が複数のブロックに編成された取引システムにおいて、一連の以前のブロックＢ0，Ｂ1，．．．，Ｂr-1に対して新規ブロックＢr及びＢr+1を提供するステップは、ブロックＢrがブロックＢr-1における処理の状態と整合する取引の初期状態を示すことを確認した後でブロックＢrを構築するステップと、ブロックＢr+1がブロックＢrにおける処理の状態と整合する取引の初期状態を示すことを確認した後でブロックＢr+1を構築するステップと、複数の主体に、ブロックＢr+1が構築された後でブロックＢrの未検証の取引を検証させるステップとを含んでいる。これらの取引はスマート契約であってよい。ユーザーは、スマート契約のうち少なくとも１個に関する取引をブロックＢrに記録する前提でブロックＢrを構築することができる。ユーザーはまた、スマート契約に関する取引結果をブロックＢrに記録することができる。ユーザーはまた、スマート契約にスマート契約の結果を得るのに要する実行ステップ数をブロックＢrに記録することができる。ユーザーはまた、複数の主体がブロックＢrの取引を検証することで受け取る対価を記録することができる。複数の主体はブロックＢrの全てのユーザーの部分集合であってよい。複数の主体は、無作為に選択することができる。複数の主体を無作為に選択するステップは、時間情報、１個以上のブロックに関する情報、１個以上のブロックに含まれるデータ、又は１個以上のブロックから推論されたデータのうち少なくとも１個を含むデータに暗号ハッシュ関数を適用するステップを含んでいてよい。
【００１５】
本明細書に記述するシステムによれば更に、ブロックチェーン内のブロックＢを当該ブロックチェーンに追加するステップは、主体に一つ前のブロックに対応する情報を受信させるステップと、主体に所与の入力に対してスマート契約実行の宣言的発動を受信させ、宣言的発動が実行に関連する結果及び他の関連データを宣言するステップと、主体に発動の構文的有効性を検証させるステップと、主体に、発動の構文的有効性を検証したことに応答して宣言的発動をブロックＢに組み込ませるステップとを含んでいる。関連結果は、スマート契約実行の正味効果、スマート契約実行後の状態、及び実行ステップ数を指定することができる。他の関連データは、宣言的発動の呼出者、時間情報、ブロック情報、及び／又は支払うべき対価を指定することができる。宣言的発動が構文的に有効であるのは、対価が実行ステップ数に相応であり、且つ対価の支払者は対価を支払うのに充分な資産を有している場合であり、宣言的発動がブロックチェーンに出現したならば対価が支払われてよい。
【００１６】
本明細書に記述するシステムによれば更に、ブロックチェーン内の検証者の集合を、所与の入力に対してスマート契約実行の１個以上の宣言的発動の集合Ｓを検証すべく割り当て、当該宣言的発動が当該スマート契約実行の関連結果を宣言するステップにおいて、当該検証者が集合Ｓを受信するステップと、当該検証者がＳ内の宣言的発動のどれが意味論的に有効であるかを判定するステップと、当該検証者が意味論的に有効な１個以上の宣言的発動の認証された応答を提供するステップとを含んでいる。検証者の集合はＳに基づいて所与の暗号関数を介して疑似乱数的に選択されていてよい。少なくとも一人の検証者が、当該少なくとも一人の検証者の秘密鍵を用いる計算を介して当該少なくとも一人の検証者が選択されていると判定することができ、当該少なくとも一人の検証者が他の関係者に対して、当該少なくとも一人の検証者が選択されたことを証明することができる。Ｓ内の発動Ｉが正しいと考えられるのは、Ｉが意味論的に正しいことを、Ｓに割り当てられた少なくとも所与の人数の検証者の応答が示している場合である。
【００１７】
本明細書に記述するシステムによれば更に、宣言的スマート契約発動の集合Ｓが既に登録され、検証者の集合がＳに割り当てられていて、検証者がＳの発動のうちどれが意味論的に有効であるかに関する認証された応答を提供しているブロックチェーンにおいて、Ｓの発動の評決をブロックチェーンに組み込むステップが、主体に検証者の認証された応答を受信させるステップと、主体にＳの発動の正しさを推論させるステップと、主体にＳの発動の正しさに関する最終評決をブロックチェーンに組み込ませるステップとを含んでいる。Ｓ内の発動Ｉの最終評決は、Ｓに割り当てられた少なくとも所与の人数の検証者の応答が、Ｉが意味論的に有効であることを示している場合Ｉが正しいことを示していてよい。Ｓの発動Ｉの最終評決が、Ｉが正しいことを示している場合、他のユーザーにスマート契約の状態を更新させ、スマート契約の実行の宣言された正味効果が発現したと思わせることができる。
【００１８】
本明細書に記述するシステムによれば更に、ブロックチェーン内のブロックＢをブロックチェーンに追加するステップは、主体に一つ前のブロックに対応する情報を受信させるステップと、所与の入力に対してスマート契約実行の確約された宣言的発動を受信させ、確約された宣言的発動は、実行の少なくともいくつかの関連結果、実行の他の関連結果の確約、及び他の関連データを宣言するステップと、確約された宣言的発動の構文的有効性を確認させるステップと、確約された宣言的発動の構文的有効性の検証に応答して確約された宣言的発動をブロックＢに組み込むステップとを含んでいる。関連結果は実行の正味効果、契約の実行後に生じた状態、及び／又はステップ数を指定することができ、他の関連データは発動の呼出者、時間情報、ブロック情報、及び／又は支払うべき対価を指定することができる。宣言的発動は構文的に有効なのは対価がステップ数に相応であり、且つ対価の支払者が対価を支払うのに充分な資産をシステム内に有している場合であり、発動がブロックチェーン内に出現したならば対価が支払われてよい。
【００１９】
本明細書に記述するシステムによれば更に、ブロックチェーン内の検証者の集合を、所与の入力に対してスマート契約の実行ｅを指定する少なくとも１個の確約された宣言的発動Ｉを含む宣言的発動の集合Ｓを検証すべく割り当て、Ｉがｅの少なくともいくつかの関連結果ｒｒに対する確約を含んでいるステップは、検証者が集合Ｓを受信するステップと、検証者が関連結果ｒｒを計算すべく実行ｅを再構築するステップと、ある検証者が検証者のｒｒに対する個人化された確約を含む認証された応答を提供するステップとを含んでいる。割り当てられた検証者はＳに基づいて、所与の暗号関数を介して疑似乱数的に選択されてよい。少なくとも一人の検証者が、当該少なくとも１人の検証者の秘密鍵を用いる計算を介して当該少なくとも１人の検証者が選択されていると判定することができ、当該少なくとも１人の検証者が他の関係者に対して、当該少なくとも１人の検証者が選択されていることを証明することができる。Ｓ内の確約された宣言的発動Ｉが正しいと考えられるのは、Ｓに割り当てられた少なくとも所与の人数の検証者の応答が、Ｉで確約された関連結果ｒｒに対する個人化された確約を含む場合だけであってよい。
【００２０】
本明細書に記述するシステムによれば更に、宣言的スマート契約発動の集合Ｓが既に登録され、検証者の集合がＳに割り当てられていて、集合Ｓが、所与の入力に対してスマート契約の実行ｅを指定する少なくとも１個の確約された宣言的発動Ｉを含み、Ｉがｅの少なくともいくつかの関連結果ｒｒに対する確約を含み、検証者がＳの発動に関する認証された応答を提供しているブロックチェーンにおいて、Ｓの発動の評決をブロックチェーンに組み込むステップが、主体に検証者の認証された応答を受信させるステップと、主体にＳの発動の正しさを推論させるステップと、主体にＳの発動の正しさに関する最終評決をブロックチェーンに組み込ませるステップとを含んでいる。Ｓに割り当てられた少なくとも所与の人数の検証者の応答は、Ｉに対して確約されたものと同じ関連結果ｒｒに対する個人化された確約を含んでいてよく、Ｓ内の確約された宣言的発動Ｉの最終評決は、Ｉが正しいことを示していてよい。Ｉの正しさの最終評決は、他のユーザーにスマート契約の状態を更新させ、スマート契約の実行ｅの正味効果が発現したと思わせることができる。
【００２１】
本明細書に記述するシステムによれば更に、非一時的コンピュータ可読媒体で提供されるコンピュータソフトウェアは、本明細書に記述するステップの一部又は全てを実現する実行可能コードを含んでいる。
【００２２】
スマート契約の代替技術：ブロックチェーンでスマート契約を実行する新技術を提示する。当該新技術は、従来のものと並行して実装することができ、従来技術で扱うには高価過ぎる契約のクラスを効率的に扱うことができる。
【００２３】
契約の巨大なクラス：新技術は特に、
・実行毎に変化する内部／計算状態（簡潔に「状態」）
・正味効果  例えば、新たな状態、関係者間の送金等
を簡潔に記述できるスマート契約に有用である。発明者らの技術により、
・膨大な計算ステップ及び
・極めて大量のメモリ
を要するスマート契約が扱えることを強調しておく。
【００２４】
実際、実行に用いるメモリは極めて大きいのに対し、次の実行用に保持される、例えば数個の有界な変数を含む状態情報は極めて簡潔な場合がある。重要な点は、無状態スマート契約は明らかにこの特性を満たし、極めて強力である。
【００２５】
無論、いくつかのスマート契約は、所与の要望を実現すべく有状態であることが必要な場合がある。発明者らの新技術の観点から、しかし、保持された状態のサイズを縮小すべくそのような契約のアーキテクチャを考えることがアプリケーション設計者の関心対象となろう。
【００２６】
ブロックチェーン不可知技術：本技術は新たに、Ａｌｇｏｒａｎｄ技術の主な要素である暗号によりセキュリティ保証された自己選択技術である（秘密）暗号抽選を利用するものであり、Ａｌｇｏｒａｎｄ技術は２０１７年５月４日出願のＰＣＴ特許出願ＰＣＴ／ＵＳ２０１７／０３１０３７号明細書に記述されており、本明細書で引用している。Ａｌｇｏｒａｎｄ技術はまた、本明細書の別の節で引用している特許出願の全てではないにせよ大多数に記述されている。
【００２７】
しかし、他の利点にもかかわらず、スマート契約の新たなクラスを扱う発明者らの新技術を用いるために、Ａｌｇｏｒａｎｄを基礎となるブロックチェーンプラットフォームとして用いる必要はない。新技術はビットコイン、イーサラム等、他の任意のプラットフォームと合わせて用いることができる。
【００２８】
従って、以下で指摘するように、Ａｌｇｏｒａｎｄをブロックチェーンエンジンとして用いることでいくつかの追加的な利点がもたらされる。
【００２９】
本明細書に記述するシステムの実施形態について、以下に簡単に紹介する図面を参照しながらより詳細に説明する。
【図面の簡単な説明】
【００３０】
【図１】本明細書に記述するシステムの一実施形態によるネットワーク及び計算ステーションの模式図である。
【図２】本明細書に記述するシステムが組み込まれたブロックチェーンの模式的概念図である。
【発明を実施するための形態】
【００３１】
本明細書に記述するシステムは、スマート契約を含むブロックチェーンのブロックを検証するためにワークステーション（検証者）の効率を向上させ、必要とする計算量を減少させる機構を提供する。
【００３２】
図１を参照すると、インターネット等のデータネットワーク２４に接続された複数の計算ワークステーション２２ａ〜２２ｃを図示している。ワークステーション２２ａ〜２２ｃは、本明細書の他の箇所でより詳細に記述するように、ネットワーク２４を介して互いに通信して分散取引拡散及び検証を提供する。本システムは、ワークステーション２２ａ〜２２ｃが互いに通信可能である前提で、本明細書に記述する機能を提供可能な任意の数のワークステーションを含んでいてよい。各々のワークステーション２２ａ〜２２ｃは、本明細書の他の箇所でより詳細に説明するように、独立に処理を実行して、システム内の他のワークステーションの全てに取引を拡散し、取引／ブロックを検証して、検証者として動作することができる。
【００３３】
図２を参照すると、ブロックチェーン２００は複数のブロック２０２〜２０５を含んでいる。本明細書の他の箇所でより詳細に説明するように、各々のブロックは１個以上のスマート契約及び追加的情報を含んでいる。ブロック２０２はブロックチェーン２００の最も古いブロックであり、ブロック２０３は次に古く、以下同様である。ブロック２０５はブロックチェーン２００で最新のブロックである。ブロックチェーン２００には任意の数のブロックがあってよい。ブロック２０２〜２０５の各々は、一つ前のブロックを検査する情報を含んでおり、例えばブロック２０３はブロック２０２を検査する情報を含み、ブロック２０４はブロック２０３を検査する情報を含んでいる。従って、ブロックチェーン２００内のブロック２０２〜２０５のうち検査された最新のものは一つ前のブロックを直接検査し、他の全ての先行ブロックを間接的に検査する。本明細書の一実施形態において、ブロック２０２〜２０５の各々は、ブロック２０２〜２０５の一つ前の署名されたハッシュを含んでいるが、他の機構を用いて、当技術分野で公知の多くの従来型ブロックチェーン機構を含む先行ブロックを検査／確認することができる。また、ブロック２０２〜２０５の１個以上を検証して、本明細書の他の箇所でより詳細に説明するように、ブロックの真正性に関する評決を含んでいてよい。ブロック２０２〜２０５のうち１個以上の最新のものが最初は未検証であってよく、本明細書の他の箇所でより詳細に説明するように、その後検証及び認証されてもよい。
【００３４】
理想的には、スマート契約Ｃの実行を発動するための対価は、当該実行がシステムにもたらす計算の総コストに一致すべきである。しかし、
Ｃの実行にかかるシステムの総コストはいくらか？
【００３５】
ｎ人のユーザーがいて、且つ（所与のマシンＭでの）Ｃの実行が＃ｓｔｅｐｓを含んでいる場合、総システムコストは以下のように推定できる。
ｎ×＃ｓｔｅｐｓ（脚注２：ここでは全てのユーザーが新規ブロックの正しさを保証して当該ブロック含む全てのスマート契約を実行すると仮定している。いくつかのブロックチェーンプラットフォームにおいて、軽いノードではなく完全なノードだけがこの責任を有している。いずれにせよ、ｎは極めて大きくなり得る。）
【００３６】
従って、ｎが大きければ、たとえ＃ｓｔｅｐｓが若干小さくてもシステムの総コストが極めて高い場合がある。このことは、＃ｓｔｅｐｓが全く高くなくても、Ｃの発動者ｉが支払うべき対価も極めて高い筈であることを意味する。この状況でブロックチェーンシステムにおいて、数ステップしか必要としないスマート契約だけを実行することに意味がある。これは残念である。システム内のユーザーは、無視できない数の計算ステップを要する多くのスマート契約の実行を発動することで利益が得られるが、支払うべき対価が過大なためにこれらの発動が阻害される恐れがある。
【００３７】
発明者らは、本発明の技術を特定の部分を選択して記述するのが便利であることを見出した。しかし、各部分自体が新規であって独自に利用でき、且つ他の部分への分解の仕方も本発明の範囲に含まれ得ることを理解されたい。
【００３８】
１．発動
スマート契約Ｃの宣言的発動Ｉは、（所与の入力／入力群及び初期状態に）Ｃの実行ｅに関連する結果及び他の関連データを指定する。
【００３９】
関連結果は、ｅが到達した新たな状態及びｅに対応するプレーヤー／金額調整を含んでいる。
【００４０】
関連データは、契約、状態、及び対象入力群の指標、すなわち（参照マシンＭに関する）ｅのステップ数、又はそのようなステップ数の上限、発動がシステムにもたらすコスト、又はコストの上限を表す対価を含んでいてよい。（以下で分かるように、このコストは、全てのユーザーがｅを実行した際に生じたコストよりも顕著に小さい場合がある。）
【００４１】
関連データはまた、少なくとも発動に責任を負う適切なユーザーｉ、及びシステムにもたらすコストを含む当該発動の責任をｉが本当に引き受けることを示すｉのデジタル署名（又は別形式の認証）の指標を含んでいてよい。そのようなユーザーｉは実際に自身で、関連データを計算すべく実行したといえる。
【００４２】
関連データはまた、発動が公式に登録される、すなわちブロックチェーンに出現することが予想される１個のブロック又はブロックの集合の指標を含んでいてよい。（実際、ユーザーｉは、発動がｒでブロックチェーンに入らなければ責任を否認できる。）
【００４３】
簡潔のため、宣言的発動Ｉを単に発動と呼ぶ場合がある。
【００４４】
議論及び追加的詳細事項：上述のように、適切なユーザーｉは自身のデジタル署名を拡散することにより入力ｉｎｐｕｔに対してＣを実行すべくシステムを発動する。しかし今回は、Ｃ、ｉｎｐｕｔ、及び正しい対価に加え、ｉの署名もＣの実行の効果及び実行に要するステップ数を認証する。（脚注３：上述の情報は若干冗長であり得る点に注意されたい。これは明快さを目的としており、一切の限定を意図していない。例えば、全長（又は単に効果の持続期間等）及び／又はステップ数等、他の量から、システムの現在の「価格表」を介して対価を決定することができる。同様に、ステップ数は、対価により上限を設定することができる。以下同様。全体を通じて、他の量から推論／推定できる上述の量は明示的に出現しないが、推論／推定される。）
【００４５】
サンプル設定において、ｉは最初にＣ（ｉｎｐｕｔ）の実行ｅを計算するか、又は他の誰かが自分の代わりにｅを計算することにより、実行ｅがどの結果を得るかを推測し、次いでこれらの結果を確認するようシステムに要求する。実行ｅにおいて、Ｃは保持された状態γC、すなわちブロックチェーンに記録されたＣの実行シーケンスの後でＣが到達した最新の保持された状態から開始される。
【００４６】
例えば、但し一般性を失うことなく、ｉは次式を計算して拡散し始める。
【数３】
2020537391.tif 000005
ここに
・ｉは発動ユーザーの識別子であり、ｉの署名から推論できる場合に主に便宜的に含まれる。
・Ｃは対象契約である。
・ｒは、本例では、ｉが発動の登録を予想する特定の単一ブロックであり、ブロックｒに登録されていなければｉは発動の責任を否認する。
・ｒ’は恐らく将来のブロックの指標である。（例えば、発動された実行に関する最終評決がブロックｒ’によりブロックチェーンに出現した場合に、当該発動を破棄すべきであることを伝えるため。）
・ｉｎｐｕｔはｉがＣの実行の発動を選択する入力ｉである。
・＃ｓｔｅｐｓは（所与の参照マシンＭでの）ｅの数である。
・γCは初期状態であり、
【数４】
2020537391.tif 000006
はｅにより生じたＣの新たに保持された状態である。
・
【数５】
2020537391.tif 000007
はｅにより生じたプレーヤー／金額調整のペアである。
・ｆｅｅは（当該特定で）ｉが支払うべき金額である。
・ｎは（以下に述べる）発動に対する検証者の集合の（予想）サイズである。
・ｔは整数であり、恐らくは発動が正しい（以下に述べる概念）と考えるべき発動に関するコヒーレントな応答の数を示すべく含まれている。
【００４７】
ｉｎｖｏｋｅiをＣ（ｉｎｐｕｔ）のｉの発動と呼び、
【数６】
2020537391.tif 000008
を宣言された実行概要と呼ぶ。
【００４８】
支払うべき対価は、（一切の限定を意図することなく）＃ｓｔｅｐｓ、宣言された実行概要のサイズ、結果的に生じた状態
【数７】
2020537391.tif 000009
のサイズ等、何らかの選択された量に依存する場合がある。従って、状態が簡潔であるようにＣを設計して、正味効果を簡潔に記述できる契約に集中することが重要である。対価はまた、発動が量ｎ及びｔのような量を含んでいれば、そのような量に依存する場合がある。対価はまた、まもなく述べる最終評決のサイズのような他の量に依存する場合がある。対価が実際に選択された量に対応する金額を以上である場合、対価が充分であると言う。
【００４９】
要するに、ｉｎｖｏｋｅiは本質的に、宣言された実行概要の正しさを検証し、次いで（ａ）Ｃの新規に保持された状態を更新して、（ｂ）Ｃの実行に影響されたプレーヤーが所有する金額を調整することを求めるシステムに対するｉの要求である。
【００５０】
このような発動Ｉがどのように登録されるかについて以下に述べる。
【００５１】
２．登録
発動Ｉは、通常の支払いとほぼ同様にブロックチェーンに入ることができる。発動Ｉは、新規ブロックを生成する役割を果たすあるユーザーｕが発動Ｉをブロックに入れるまでユーザーからユーザーへ拡散されてよい。好適には、ｕはＩが構文的に有効であるか否かを確認すべきである。
【００５２】
構文的有効性の確認は何らかの観点な条件の確認を必要とする。例えば、Ｉに示されたＣの初期状態が、ブロックチェーンに登録されたＣの最後の発動に示された最終状態に一致すること、又は発動ユーザーが存在すれば実際に発動する資格を有していることの確認を含んでいてよい。従って、ブロックチェーンへの発動の登録はＣの実行を必要としない。
【００５３】
構文的有効性はまた、Ｉを発動するユーザーｉが、Ｉに指定された対価を支払うのに充分な資金を実際に所有していることの確認も含んでいてよい。実際、このような対価をｉが自動的に支払うこともある。（対価の支払いの責任を負う契約を考えることもできる。その理由は例えば、発動を指示した契約であるからである。このような契約が所有する資金から対価が支払われたならば、構文的有効性は、当該契約が対価の支払いに充分な資金を有しているか否かの確認を含んでいてよい。この場合、そのような対価はＩがブロックチェーンに入ったときに契約により自動的に支払うことができる。）
【００５４】
構文的有効性はまた、Ｉの対価が、Ｉが示すステップ数に対して充分であることの確認を含んでいてよい。
【００５５】
非構文的に有効なスマート契約発動を含むブロックは無効であると考えられる。従って、正直なｕは、新規ブロックに構文上の無効な発動を含むべきではない。
【００５６】
構文的有効性はまた、Ｉが拡散する間に確認することができる。実際に、非構文的に有効なＩを受信しているユーザーｘはこれを他のユーザーに転送することができない。
【００５７】
議論察及び追加的な詳細事項：発動Ｉの構文検証が典型的に、対応する意味論的検証よりもはるかに軽いことに注意されたい。後者の用語は、Ｉにより発動された実行ｅを行うことが実際に、宣言された実行概要の生成を検証することを意味する。スマート契約の実行が多くのステップ数を要する場合があるため、このような意味論的検証は極めて長い場合がある。
【００５８】
従って、好適な実施形態においてブロック構築者ｕがＩの意味論的有効性ではなく構文的有効性だけを検証することは主な利点である。典型的なブロックは数千個の取引を含み、例えば、それらのうち１，０００個がスマート契約発動であって、それら各々を実行するのに平均１秒間の計算を要するものと仮定する。すると、他の全ての計算を無視したとしても、生成する新規ブロックの発動の意味論的有効性を検証しなければならない場合、ｕが新規ブロックを生成するのに少なくとも１，０００秒（すなわち約１６分）要するであろう。これは実際に、ブロック契約者が従来のスマート契約モデルで行うことが求められるものである。しかし、１６分毎に１ブロックを生成するのは遅過ぎるであろう。新規ブロックを数秒で生成する方がはるかに好ましいであろう。
【００５９】
この遅さは、メッセージが拡散する間、ユーザーが他のユーザーへ転送する発動の意味論的有効性の確認を求められた場合、更に悪化する恐れがある。
【００６０】
好適な実施形態において、発動はブロックチェーンに入ったときに公式であると考えられ、システムが意味論的有効性を確認するために必要な労力を投入し始めるのはその時だけである。しかし、以下で分かるように、システムの全体的な効果は全く自己完結且つ実用的である。
【００６１】
３．割り当て
１個以上のブロックに登録された１個以上のスマート契約発動の集合Ｓがスマート契約の検証者の集合に割り当てられている。
【００６２】
例えば、Ｓは所与のブロックに含まれた全てのスマート契約発動を含んでいてよい。代替的に、Ｓは単一の発動を含んでいてよい。さらに代替的に、所与のブロックの発動は数個の集合に分割されていてもよい。例えば、第１の集合は、所与のある整数ｋに対して、最初のｋ個のスマート発動を含んでいてよく、第２の集合は次のｋ個を含んでいてよく、以下同様である。（例外的に最後の集合はｋ個より少ない発動を含んでいてよい。）別の例として、１ブロックのスマート契約発動は、各集合の実行概要で宣言された総ステップ数を制御すべく、（例えばある標準的な仕方で）多くの集合に分割されていてよい。例えば、自身の宣言された実行概要のステップ数の和Ｘが所与の数Ｎを上回らないのに対し、Ｘと次の発動の宣言された実行概要のステップ数との和がＮより大きければ、第１の集合はブロック内の最初のｋ個の発動を含んでいてよい。集合Ｓは、検証者の集合の（予想）サイズに依存する場合がある。例えば、Ｓは検証者集合の類似した（予想）サイズを指定する発動をグループ化することができる。
【００６３】
Ｓ、ＶSに割り当てられたスマート契約検証者の集合は充分に無作為且つ充分に多いため、ユーザーの所与の多数派が正直であると仮定して、選択された検証者の大多数が正直であることが高い確率で保証される。また、ＶSの検証者は、ブロックチェーンに従い、現在システムに所有する、又は所与の時点で所有する資金量に比例して選択することができる。この場合、より大きい重み、すなわち２票以上を有する意味でＶSに属するように検証者を選択することができ、投票の大多数が正直者によることを保証したいと望むであろう。
【００６４】
また、集合ＶSは好適には確認可能である。すなわち（ａ）ＳからＶSを計算可能である、又は（ｂ）ＶSの検証者は自分が実際にＶSのメンバーであることを判定可能であり、その場合、本当にそうであることを他人に対して証明することができる。
【００６５】
議論及び追加的詳細事項：本発明はスマート契約の各集合Ｓに比較的小さい検証者の集合ＶSを割り当て、当該検証者はＳ内の発動の宣言された実行概要の意味論的な正しさの検証に要する時間を投入して、システム内の他のユーザーが同じ仕事をする必要をなくす。ＶSが小さくて固定されている場合、時間経過に伴い敵対者が検証者の全員又は大多数を唆す可能性があるため、システムのセキュリティはあまり高くない。
【００６６】
上述の不測の事態を防ぐべく、各ＶSはＳ及び何らかの追加的な情報Ｐに基づいて無作為に又は疑似乱数的に選択される。例えば、ハッシュ関数又は別の適当な暗号関数Ｈ、例えばＶS＝Ｈ（Ｓ，Ｐ）を用いることができる。Ｐの可能な選択として、時間情報、Ｓが出現するかブロック又はブロック群に関する情報、これらのブロックに含まれるか又はこれらのブロックから、或いはより一般的には一切の情報を含まないブロックチェーン等から推論可能なデータが含まれていてよい。（Ｓが出現するブロック又はブロック群に基づいて選択されているため、ＶSがＳに基づいて選択できる点に注意されたい。例えば、ＳがブロックＢ又はブロック番号ｎの全ての発動の集合である場合、ＶSはＢ又はｎに基づいて選択されてよい。別の例として、Ｓが、何らかの所与のオーダーの、ブロック番号ｎの第２の発動の集合である場合、ＶSはペア（ｎ，２）を含む情報に基づいて選択することができる。Ｓに基づいて選択されることは、Ｓ及び他の情報に基づく選択を含む。）
【００６７】
ＶSの上述の無作為選択により、敵対者がＶSの検証者のうち何人かを唆すことが極めて難しくなる。実際、検証者の集合は毎回劇的に変化し得る。
【００６８】
理想的には、ＶSの検証者は秘密の抽選方法を介して選択される。そのような方法では、ユーザーｖは自身がＶSの検証者であるか否かを秘密裏に知るが、本当にそうであればこれを他人に対して証明することができる。例えば、ｖは自身の秘密鍵を用いて自身がＶSに属するか否かを計算することができる。例えば、ｖはＳＩＧｖ（Ｓ，Ｐ）を計算して、そのように計算されたデータストリングが所与の特性を満たすか否かを確認することができる。そのような特性の一つは、一切の限定を意図することなく、値ＳＩＧｖ（Ｓ，Ｐ）を有していてよく、又は自身のハッシュが所与の数ｔよりも小さくてもよい。実際、他の任意のデータストリングと同様にＳＩＧv（Ｓ，Ｐ）は一意に数と解釈することができ、当該数は「目標」数ｔと容易に比較できる。例えば、ｔ＝０．００１ならば、暗号関数Ｈがランダム関数として扱われる場合、Ｈ（ＳＩＧv（Ｓ，Ｐ））≦ｔである確率は１０００分の１である。従って、本例では、可能なユーザーの１０００人に１人はＶSの検証者である。本例の検証者集合ＶSは確認可能である点に注意されたい。実際、ｖがＶSに属する場合、ｖは自身の署名ＳＩＧv（Ｓ，Ｐ）を解除することにより、そうであることを証明することができる。実際、このデータストリングを与えられたならば、これがＶSに属すると判定する所望の特性を有しているか否かを誰でも判断できる。しかし、ｖがＳＩＧv（Ｓ，Ｐ）を開示するまでは、敵対者はｖが誰であるかを知らないため、ｖを唆すことは極めて困難である。実際、ｖがＶSに属するか否かを判定する秘密鍵（上例では秘密署名鍵）をｖだけが知っているため、ｖは秘密裏に選択される。実際、秘密抽選を介したＶSの選択は厳重にセキュリティ保証されている。
【００６９】
４．検証
スマート契約の集合Ｓがブロックチェーンに登録（出現）されたならば、ＶSの各検証者ｖはＳ内の各発動Ｉの意味論的な正しさを検証し、次いで自身の応答を認証して拡散する。
【００７０】
集合ＶSが秘密抽選を介して選択されたならば、ｖはまた自身が本当にＶSに属している証明を拡散する。
【００７１】
検証者ｖは、Ｓ内の各Ｉに関する自身の応答を、例えばＳＩＧv（ｉ，ｖａｌｉｄ）を計算して拡散することにより別々に認証してよい。
【００７２】
検証者ｖはまた、自身の全ての応答を一緒に認証して、どの発動が有効でどれが無効であるかを示すことができる。例えば、Ｓ内の発動がＩ1，Ｉ2，Ｉ3，Ｉ4，．．．，であって、発動Ｉ1，Ｉ3，．．．が有効且つ発動Ｉ2，Ｉ４，．．．が無効ならば、ｖは次式を計算して拡散することができる。
ＳＩＧi（（Ｉ1，ｖａｌｉｄ），（Ｉ2，ｉｎｖａｌｉｄ），（Ｉ3，ｖａｌｉｄ）（Ｉ4，ｉｎｖａｌｉｄ），．．．）
【００７３】
より簡潔には、ｖは１で有効を示し、０で無効を示すことができる。従って、上述の例の場合、ｖはＳＩＧi（（Ｉ1，１）、（Ｉ2，０）（Ｉ3，１），（Ｉ4，０），．．．）を拡散することにより、自身の全ての応答を認証することができる。更により簡潔に、Ｓ内の発動Ｉ1，Ｉ2，Ｉ3，Ｉ4，．．．，が実際に何らかの所定且つ明確な仕方で順序付けられている場合、上述のケースでｖはＳＩＧv（１，０，１，０，．．．）を拡散することができる。すなわち、第１の位置にある最初の１は、第１の取引すなわちＩ1が有効であることを示し、位置２にある最初の０は、第２の取引すなわちＩ2が無効であることを示し、以下同様である。
【００７４】
検証者ｖはまた、自身の応答をまとめて、但しＳ内の個別発動に関して認証された応答を抽出できるように認証することができる。例えば、ｖは、各々の葉がＳ内の別個の発動に関するｖの応答を保存するマークル木を構築し、次いでマークル木の根に保存された値を認証することができる。
【００７５】
ＶSの正直な検証者は、Ｓ内の各発動Ｉに関する正しい応答（従って単一の応答）を返すだけである。
【００７６】
ＶSの検証者が有効又は無効と考えるＳの発動を認証するために如何なる方法を用いるにせよ、ＶSで少なくとも所与の数Ｘの検証者によりＩが意味論的に有効と認証されたならばＳ内の発動Ｉは正しく、さもなければ誤っていると考えられる。代替的に、ＶSにおいて少なくとも所与の数Ｙの検証者によりＩが意味論的に誤っていると認証されたならばＩは誤っていると考えられる。有意味性を最大化すべく、ＶSの検証者の大多数が正直な場合、（ａ）意味論的に有効なＳの各発動Ｉが正しいと考えられ、誤っているとは考えられないように、及び同様に（ｂ）意味論的に無効なＳの各発動Ｉが誤っていると考えられ、正しいとは考えられないように、充分に大きいＸ及びＹを選択する。
【００７７】
議論及び追加的詳細事項：ＶSの検証者に、Ｓ内の発動の意味論的有効性に関する自身の認証された応答を拡散させるだけでは充分でない。例えば、最近システムに参加して、これまでブロックチェーン全体を学んだユーザーは、自身が参加する前に何が拡散されたかを全く知らないかもしれない。従って、発動Ｉがブロックチェーンに登録された状況を見たとしても、Ｉが正しいか否かは分からない。従ってブロックチェーン自体でのＩに関する最終的な「評決」を登録することが重要である。
【００７８】
マークル木が文献でよく知られていることを想起されたい。マークル木により、木の根に保存された値ｒに関して木のノードに保存された多くの情報項目を認証することができる。木のノードに保存されたいかなる値ｖも認証するために、根から値ｖを保存しているノードまでの認証経路を提供しなければならない。そのような経路は、木の範囲内で認証される一連の値よりもはるかに短い（例えば、対数的に短い）場合がある。値ｒが未知の場合、木のノードに保存された値ｖを認証するために、（例えばデジタル署名を介して）ｒを別々に認証し、次いでｒに相対的なｖの認証経路を提供することができる。
【００７９】
５．評決
新規ブロックを構築しているユーザーｕはこのようなブロックに、未だブロックチェーンに出現していない有効な通常の取引（例えば、有効な支払い）だけでなく、最終評決、すなわち以前チェーンに登録された発動の正誤いずれかに関する情報を含んでいてよい。好適には、そのような情報は、最終評決がチェーンに未だ出現していない取引に提供される。
【００８０】
Ｓを以前ブロックチェーンに登録された発動の集合、ｕを新規ブロックＢを構築しているユーザーとする。次いで、Ｓ内の各Ｉについて、Ｉが正しいか否かを知るためにＶSで充分に多くの検証者の応答を受信した後で、ｕはＳ内の発動に関する最終評決（例えば、Ｓ内の全ての発動）をＢに含めてよい。このような最終評決はまた、集合Ｓ自体を識別する情報を含んでいてよく、好適には認証されている。ｕがＢを認証したならば、そのような評決はｕにより自動的に認証される。代替的に、ｕはＳ内の発動に関する最終評決を別々に認証することができる。例えば、Ｓ内の発動に関する最終評決を指定すべく、ｕは、ＶSの検証者が用いた方法の一つを用いてＳ内の発動の意味論的有効性に関する自身の応答を伝達することができる。
【００８１】
代替的に、ｕは、ＶSの充分に多くの検証者の認証された応答をブロックに含めて、このように含まれた応答から、有効であるＳ内の発動及び有効ではないＳ内の発動を判定可能にすることができる。恐らく、ｕはまた、このような応答と共に、注目する検証者が実際にＶSに属することを証明する１個以上のデータストリングを含んでいてよい。
【００８２】
代替的に、ｕは、ＳVの一部の検証者、好適にはブロックチェーンに未だ記録されていない応答を有する検証者のＳに関する応答を自身のブロックに含めてよいが、Ｓ内の発動の正しさはこのように含まれた情報だけから推論することはできない。しかし、ユーザーは複数のブロックにまたがりＳの発動の正しさを推論することができる。Ｓの発動Ｉに関する最終評決は実際、チェーンに記録された充分に多くの応答がＩの正誤（ケースの如何に依らず）を証明した場合に到達され得る。
【００８３】
ユーザーｕは、Ｓ内の全ての、又は１個以上の発動の正しさに関する情報をＢに含めてよい。例えば、ｕは、Ｓ内の１個以上の発動Ｉに関するＶSの検証者の１個以上の応答をＢに含めてよい。或いは、ｕは、Ｓ内の少なくともいくつかの取引の正しさを推論できる情報を含んでいてよい。ＶSの検証者がＳ内の発動の有効性に関する自身の応答を、Ｓ内のいくつかの取引Ｉだけに関する認証された応答を抽出可能にするように認証したならば、ｕは、そのようにＩに関して抽出された認証を含んでいてよい。例えば、ＶSの検証者ｖが、マークル木の根ｒを認証することにより、Ｓ内の発動に関する自身の応答を認証したならば、Ｓ内の発動Ｉに対するｖの認証をＢに含めるべく、ｕはｒに対するｖの認証と、ｒからＩの有効性に関するｉの応答を含む値までの認証経路を含んでいてよい。
【００８４】
議論及び追加的詳細事項：ブロックＢは、自身の通常の取引が有効である場合だけでなく、以前に登録された発動に関する最終評決が有効である場合に有効であると考えられる。
【００８５】
新規ブロックの生成に際してプルーフオブワークに依存するブロックチェーンにおいて、正直な採掘者は無効なブロックに新規ブロックを紐付けることはしない。
【００８６】
Ａｌｇｏｒａｎｄ等のブロックチェーンでは、新規ブロックＢが提案され、次いで適切なユーザーの集合（例えば、検証者の適切な集合）によりチェーンへの追加が投票又は合意で決定されるが、無効なブロックは恐らく投票又は合意により追加されない。
【００８７】
プロトコルは、所与の契約の同時実行を許すか、又はＣの複数の実行を特定の順序で実行させることができ、このような実行のうちいくつかを無視することも含まれる。例えば、所与の契約Ｃの発動Ｉがブロックチェーンに登録されていれば、プロトコルは、Ｉに関する最終評決がブロックチェーンに出現するまでＣの別の発動をブロックチェーンに登録することを禁止できる。特に、新規ブロックＢを構築しているユーザーｕは、Ｃの２個以上の実行にＢを含めることはできない。代替的に、Ｃの２個以上の発動が出現し得るが、これらのうち１個が最初に実行されるように（例えば所定の何らかの仕方で）選択される。他の発動は決して実行されないか、又は第１の発動に関する最終評決に到達した後でしか実行できない。更に代替的に、契約の種類及び契約に内容に応じて、最初に実行する１個を選択し、次いで二番目を選択し、以下同様に選択していく。
【００８８】
契約Ｃの発動Ｉはまた、Ｉに関する一切の最終評決がブロックｒの後でブロックチェーンに入らないように、ブロック番号ｒを含んでいてよい。代替的に、このようなｒは、Ｉが登録されたブロック及びＩ内で宣言されたステップ数に基づいて自動的に決定することができる。これにより、最終評決無しで本来の発動が残っていれば、Ｃの新規な発動が可能になる。このような場合、発動Ｉに関してＩがブロックチェーンに登録された際に自身が支払った対価に対する責任を負うユーザーに自動的に弁済することが考えられる。
【００８９】
契約Ｃの発動Ｉの最終評決（の指標）がブロックチェーンに入った場合、当該評決は肯定的ならば、これを理解しているユーザーｘがＣの現在状態を適切に更新し、全ての関連する正味効果が発現したものと考える。（例えば、発動Ｉがあるユーザーから別のユーザーへの支払いを宣言したならば、そのようなユーザーが所有する資金は自動的に更新される。）最終評決が否定的な場合、Ｃの状態の更新は行われず、正味効果は一切発現しない。しかし、発動Ｉに責任を負うユーザーに対して追加的な対価が自動的に科され得る。
【００９０】
１  一般的解析
セキュリティ、効率、及びコスト：所与の集合Ｓの発動に関する単一の検証者ｖの応答は、ｖが正直であることが確実ならば充分であろう。しかし、無論、ブロックの契約者／提案者又は他の誰もが、どの検証者が正直であるかが分からない。しかし、大多数の検証者が正直であると確信することは容易である。従って、充分に多くの、好適には無作為に選択された検証者が他の全てのユーザーに、Ｓのどの発動が有効であり、どれが無効であるかを教えることで、ユーザーは自身でそれらの有効性を検証する必要無しにＳの発動が正しいことが分かる。これが、本発明のスキームがセキュリティ保証され且つ同時に効率的である理由である。
【００９１】
例えばユーザーの８０％が正直である場合、Ｓ内のＩの検証者数は約５００人であり、３００人の検証者の応答が実際に極めて高いセキュリティを確保することができる。同時に、Ｓが例えば１００個の発動を含んでいる場合、平均５人のユーザーだけが各発動の有効性を検証するため、システムは、極めて高いセキュリティに加え、極めて効率的になる。
【００９２】
宣言された実行の有効性を比較的少人数（特に平均）の検証者が直接確認するため、所与の実行の登録に要する対価を極めて低く抑えることができる。実際、例えばシステムの全ユーザーではなく、平均して単に５人のユーザーの上例において、極めて少人数のユーザーの計算コストを弁済する必要がある。スマート契約の発動に要する対価は往々にして「ガス」と呼ばれる。従って、本発明のシステムでは、
ガスは極めて多くの望ましい種類の契約においてはるかに安価である。
【００９３】
高いセキュリティと、高い効率及び低コストが相まって、本発明のシステムは、大規模なクラスのスマート契約にとって極めて魅力的であり、実際、そのような契約を大規模に使用することが可能になる。
【００９４】
実際、本発明のシステムにより、スマート契約は他のシステムよりもはるかに長い時間にわたり実行可能であるため、全体的な計算量を大幅に抑えることができる。
【００９５】
資金の重み付け：本出願を通じて、所与の発動の集合Ｓの検証者ＶSの集合を、何らかの形式のプルーフオブステーク少なくとも部分的に基づくＡｌｇｏｒａｎｄ又は他のブロックチェーンと同様に、所与の時点（例えば、Ｓがブロックチェーンに登録された時点）でシステム内に所有する資金量に基づいて選択することができる。実際、所与のユーザーは、１よりも大きい複数のＶSを入れることができる。実際、ＳVは、各検証者が自身の所有する資金量に応じてより多くの投票権を有するような検証者の集合の投票数を含んでいてよい。すなわち、本発明のシステムはまた、資金の大部分が正直な人の手元にあると仮定される場合にも適用できる。
【００９６】
計算効率：システム内のユーザーの数ｎは莫大（例えば、ｎ＝１００Ｍ）であり得るものの、Ｃ（ｉｎｐｕｔ）の実行に要する検証者の数はＴ人（例えば、Ｔ＝５００）に過ぎないことに注意されたい。従って、本発明の技術によるＣの実行の総計算コストは１００Ｍの＃ｓｔｅｐｓではなく５００の＃ｓｔｅｐｓ以下である。従って、Ａｌｇｏｒａｎｄにおけるスマート契約は他のシステムよりもはるかに長い時間にわたり実行可能であり、しかも完全な全体的な計算量を大幅に抑えることができる。換言すれば、新技術は、はるかに大きな柔軟性を発揮し、はるかに大規模なクラスのスマート契約の使用を可能にする。
【００９７】
コスト効率：新たなスマート契約技術の計算効率は自動的にコスト効率を示唆する。１００Ｍ人のユーザーを有するシステムで１時間の計算を要するスマート契約Ｃの実行の発動を考える。このようなシステムでは、本質的に１００Ｍ時間の計算の総コストをカバーする必要があるため、必然的にＣの従来の発動の対価を極めて高くせざるを得ない。対照的に、新た技術では、Ｃの同じ発動に対応する対価は、５００時間の計算だけをカバーするだけでよい。実際、後者のコストは適度であるだけでなく、システム内のユーザーの総数がたとえ１Ｂ以上であっても同じままである。換言すれば、本発明の新たなシステムでは、
「ガス」は極めて多くの望ましい種類の契約に対してはるかに安価である。
【００９８】
スループット効率：本発明の技術により、ブロックＢに登録された契約Ｃの発動Ｉは、「チェーン外」の適切な検証者の集合によるＣの実行を起動する。従って、このような実行に長い時間かかるとしても、ブロックＢの有効性の確認には長い時間を要しない。従って次のブロックの生成を直ちに始めることができる。換言すれば、本発明のシステムのスループットは極めて高い。Ｉの適切な検証者が実行を完了したならば、そのような実行に長い時間を要したとしても、全くチェーンを減速することなくＩに関する最終評決がブロックチェーンに入る。対照的に、従来の方法では、ＩがブロックＢに記録される場合、次のブロックを生成する前にｅの発動を終了しなければならない。従って、新たな技術では、個別又は全体の実行に１時間の計算を要するスマート契約をブロックが含んでいたとしても、新規ブロックを数秒で生成できる。
【００９９】
２  変型例及び追加
好適な実施形態を上に示した。当業者には他のいくつかの変型例及び代替策が可能であし、その全てが本発明の範囲に含まれることが理解されよう。以下ではそのいくつかだけを考える。
【０１００】
発動登録無しの最終評決：好適な実施形態において、発動Ｉは「システム実行」を起動するためにブロックチェーンに登録されなければならない。しかし、代替的には、Ｉはブロックチェーンに入らず、その最終評決（の指標）が入る場合がある。例えば、Ｉは単に、充分に多くの検証者に注目されて処理されるまで拡散され、検証者はＩに関する自身の個々の応答を拡散し、新規ブロックＢの構築者は、充分に多くのコヒーレントな応答を見た場合のみ、Ｉの最終評決に関する情報をＢに含める。（例えば、Ｉの少数の又は充分に多くの検証者の署名された個々の応答。）
【０１０１】
追加的尺度及び結果：スマート契約の発動において、実行されたステップ数は発動の複雑さの重要な尺度であり、最終的な支払い／効果はその重要な結果の一部である。しかし、追加的な尺度及び結果があり、その全てを本発明の範囲内で扱うことができる。以下で数例について詳述する。
【０１０２】
スマート契約は任意のプログラムであってよく、契約Ｃの実行はＣ自体、又は他のスマート契約の他の実行を自動的に起動することができる。（実際、スマート契約はチューリング完全言語で書かれている場合が多い。）この事実は利点であるが短所でもあり得るため、契約Ｃの発動Ｉが行い得る呼び出しの数を含めることが望まれる場合がある。
【０１０３】
例えば、呼び出しの数＃ｃａｌｌｓをｉｎｖｏｋｅi内に（別々の要素として、及び／又は他の要素の一部として）指定することができ、Ｉの対価ｆｅｅを＃ｃａｌｌｓに依存するように調整することができる。このような依存性は＃ｃａｌｌｓに単に比例していても、又は劇的に増加する場合もある。Ｉの検証者は従って、＃ｃａｌｌを含む全ての複雑さの尺度に関して＃ｃａｌｌｓが正しいこと、及びｆｅｅも正しいことを検証するよう求められる場合がある
【０１０４】
代替的に、又は追加的に、呼び出しの数を制限する場合がある。例えば、宣言された＃ｃａｌｌｓが所与の限界よりも大きい、又はＣが実際に行う呼び出しの数が＃ｃａｌｌｓより大きい場合、＃ｓｔｅｐｓ及びｆｅｅの値に依らず、発動は無効であると考えられる。個別且つ最終的な評決に関して上で述べた全ての機構は、複雑さのこの新たな尺度に直接適用できる。
【０１０５】
また、通常の呼び出しと「入れ子呼び出し」を区別することができる。例えば、Ｃの実行ｅが契約Ｃの実行ｅ’を生起させ、次いで後者が契約Ｃ”の実行ｅ”を生起させたならば、ｅ”は「レベル」２の入れ子呼び出しであると考えられる。同様に、レベル３、４等の入れ子呼び出しもあり得る。入れ子呼び出し及び／又はそれらのレベルもまた発動Ｉ内で宣言することができ、Ｉの対価、有効性、及び取扱いは、当該追加的に宣言された情報を含むように直接延長することができる。
【０１０６】
発動Ｉの直接的な正味効果に加え、その呼び出しの効果も考えることができる。例えば、Ｉが直接又は自身の呼び出しを介して送金させる総資金量をＩ内で明示的に示すことができる。再び、所与のレベルの呼び出しを禁止するか、又は通常の呼び出しよりも高価にすることができる。
【０１０７】
インセンティブ：１個の発動又は発動の集合の検証者には適切な報酬を介してインセンティブが与えられてよい。特に、発動Ｉの検証者は、Ｉに関する自身の応答がＩに関する最終評決と一致するならば、報酬を得る資格を有していてよい。
【０１０８】
そのような検証者の全員又は何人か（例えばサンプル）が報酬を得られる。報酬を得られる検証者は暗号により（例えば、暗号抽選により、及び／又はランダムビーコンの支援を介して）選択されてよい。（脚注４：そのようなサンプルは、自身が極めて頻繁に選択しなおされる専門的な関係者により選択することができる。特に、そのような関係者は、自身が暗号抽選により選択されていてよく、１個以上の検証者にデジタル署名して報酬を受けることができ、自身の署名がブロックに出現し得る。）代替的に、そのような検証者はブロック構築者により選択されてよい。発動Ｉ（又は発動の集合Ｓ）の報酬を得た検証者及びＩの（又はＳの）最終評決は同一ブロックに示すことができる。
【０１０９】
例えば、ブロック構築者ｕは、Ｉ（又はＳ）の最終評決Ｖ、並びに報酬を得るべき１人以上の検証者ｖを識別する情報を自身のブロックに挿入することができる。（代替的に、報酬を得た検証者を識別する情報を後続ブロックに挿入して、恐らくは別のブロック構築者／提案者により選択することができる。）例えば、ｕはまた、最終評決Ｖに加え、ｖの応答がＶに一致するか否かを確認可能にすべく、検証者ｖが本当にＩ（又はＳ）を検証すべく割り当てられたことの証明をブロックチェーンに含めてよい。代替的に、構築者はＶを自身のブロックに含めないようにしてもよい。例えば、Ｉの単一の検証者ｖ、又は応答がコヒーレントである複数のそのような検証者に対して、ｖ及びｖのデジタル署名された個々の評決だけを含めれば充分である。実際、そのような個々の応答から、最終評決Ｖが何を意味しているかを推論することができる。例えば、ブロックが、Ｉに関する単一の検証者ｖの個々の応答だけを含んでいる場合、この情報を用いて、Ｉに関する最終評決がＩの個々の評決に対応する（及び、恐らくは報酬のためにｖが目標とされたことを示す）ことを示すことができる。ブロック内で識別されたならば、報酬を得た検証者全員に自動的に支払うことができる。
【０１１０】
正直なブロック構築者は、報酬を与えるＩの検証者を無作為又は他の何らかの仕方で選択してよい。たとえ悪意のある構築者が異なる仕方（例えば悪意のある検証者を優先することにより）で検証者に選択したにせよ、Ｉの検証者は依然として自身の真の応答を報告するインセンティブを有している。実際、大多数の検証者は正直であると期待されていて、ブロック構築者も同様に期待されている。
【０１１１】
更に、１個以上の発動Ｉの検証者に報酬を与えるべく、又は検証者の個々の評決を考慮に入れるべく、当該検証者が本当にＣを正しく実行した証拠が必要になる場合がある。そのような証拠は何らかの種類のＣＳプルーフ、スナーク、又はスタークを含んでいてよい。そのような検証者が提供した証拠はまた、ブロック内で使用されてＩに関する最終評決の一部（又は証拠全体）として記録することができる。
【０１１２】
肯定的報酬に加え、ブロックチェーンはペナルティを科してもよい。例えば、自身の正しさに関する最終評決とは異なる発動（又は発動の集合）に関する応答を報告している検証者ｖには過料を科すことができる。そのような過料はｖが所有する資金から自動的に差し引くことができる。
【０１１３】
ブロックチェーンはまた、意味論的に無効な少なくとも１個の発動Ｉをブロックチェーンに意図的に登録することに想到し得る。これは意味論的に有効なＩを検証すべく割り当てられていて、Ｉが意味論的に有効であると悪意をもって（直接に、又はＩを含む発動の集合の有効性に関して報告する際に）報告する検証者を特定する（及び恐らくはペナルティを科す）のに役立ち得る。
【０１１４】
例えば、意図的に意味論的に無効とされた発動を登録するユーザーは悪意があってそうするのではなく、悪意のある検証者の特定を助けるために選択されているからである。従って好適には、これらの助力ユーザーの選択は秘密（意図的に意味論的に無効とされた発動の検証者には、当該発動がそのような目的で無効にされていることが分からないように）且つ無作為（少なくとも何人かの正直な助力ユーザーが確実に選択されているように）である。例えば、このような助力ユーザーの選択に用いる処理は、発動Ｉ又は発動の集合Ｓの検証者ｖを選択する処理と同様であってよく、助力ユーザーは、他のデータ（例えば、ストリング「ＨＥＬＰＩＮＧ  ＵＳＥＲ」）と共にブロックチェーンから推論可能な所与の量Ｑにデジタル署名し、当該署名をハッシングして所与の目標数値よりも小さいか否かを確認することにより選択されてよい。当該処理は、ｕが当人の選択の証拠（上例ではデジタル署名）を開示するまで、所与のユーザーｕが助力ユーザーとして選択されていることを他のユーザーに気付かれないことを保証する。この証拠は、ｕが登録した意図的に意味論的に無効とされた発動Ｉに関する最終評決がブロックチェーンに入れられた後で開示されてよい。このような証拠は有効な取引として極めて頻繁にブロックチェーンに挿入されてよい。このように、ｕがブロックチェーンでスマート契約が正直に機能するためのセキュリティを確保すべくプロトコルに従い行動したことを誰もが認識しているため、ｕに科された対価又は過料があれば自動的に（恐らく報酬に加えて）ｕに弁済することができる。
【０１１５】
３  確約された宣言的スマート契約
ここで特別な種類の宣言的スマート契約、すなわち確約された宣言的スマート契約（略してＣＤＳＣ）について述べる。このような契約の発動は一時的に、対応する実行の正味効果の少なくとも一部を隠蔽する。これらの発動は上述のように登録することができる。それらの構文的有効性も上述のように確認することができる。そのような発動の集合に上述のように検証者を割り当てることができる。次いで最終評決を上述のようにブロックチェーンに記録することができる。
【０１１６】
しかし、これらの新規な発動の検証者は上述のようにはそれらの意味論的有効性を確認しない。その理由は、これらの新規発動が一時的に、当該発動が指定する実行の正味効果の少なくとも一部を隠蔽するからである。これらの発動は実際、このような正味効果の確約を含んでいる。（このような確約はそのような正味効果を隠蔽するが、後のある時点で、本来確約された正味効果が何であったかを証拠をもって開示する扉は開いたままにしておく。）
【０１１７】
従って、そのような１個の発動Ｉを検証すべく割り当てられた検証者は、Ｉが指定した実行ｅの全ての正味効果が何であるか学びながらｅを再現することができるが、Ｉで確約された正味効果が検証者自身で計算したものであるか否かを判定することはできない。従って、このような検証者は自身の応答の中で、自身で計算してＩで確約されたｅの正味効果への自身の個人化された確約を、それらの値が一致するか否かを知らずに報告する。このように個人化された確約は、単にＩの対応する確約を複製するだけでは得られず、且つ後者の確約又は他の任意の個人化された確約から都合よく計算することもできない。実際、ＣＤＳＣの考えは、Ｉに隠蔽された正味効果が何であるかをＩの検証者に学ばせ、次いで、そのような効果に対する自身の確約を計算させて自身の応答に含めさせるものである。従って、ある意味で、Ｉの各検証者は独立に行動してＩに呼び出された実行ｅを実際に実行しなければならない。
【０１１８】
後の時点でのみ、本発明のシステムは、Ｉで確約された正味効果が、Ｉの充分に多くの検証者の応答で（個人化されて）確約された正味効果と一致するか否かを確認可能にすることにより、Ｉの正しさを検証可能にする情報を開示する。従って、ＣＤＳＣの個々の発動又は発動の集合に関する最終評決をブロックチェーンに記録することができ、上述と同様に、及び新たな方式でユーザーにインセンティブ及び／又はペナルティを科すことができる。
【０１１９】
一切の限定を意図することなく、以下にＣＤＳＣの追加的な詳細事項を説明する。
【０１２０】
１．確約された発動
スマート契約Ｃの確約された宣言的発動Ｉは、宣言的発動と極めてよく似ている（所与の入力／入力及び初期状態に対する）Ｃの実行ｅ及び他の関連データを指定するが、代わりにｓに対する確約を含めることによりｅの正味効果の集合ｓを隠蔽する。
【０１２１】
所与の値ｘの確約により所与の時点で秘密裏にｘを固定することができるが、固定された値ｘが何であったかが証明されるのは後の時点である。例えば、正味効果の集合ｓを確約すべく、Ｉは所与の（衝突耐性のある）ハッシュ関数Ｈに対してｈ＝Ｈ（ｓ）を含めることができる。実際、ｓを知らなければｈからｓを計算するのは難しい。同時に、最終的にｓを開示することで、開示されたｓが真に本来の確約された値であることを、ｈを知る誰もが納得する。その理由は、Ｈ（ｚ）＝Ｈ（ｓ）であるいかなる値ｚ≠ｓも計算するのは難しいからである。代替的に、これらの効果の各々のハッシュを別々に含めることにより、Ｉは正味効果の集合を確約することができる。例えば、ｓがｅ、γ’により生成されたＣの新たな状態及びｅ，ａ1，ａ2，．．．により生成されたプレーヤー金額調整を含んでいれば、ＩはΗ（γ’），Ｈ（ａ1），Ｈ（ａ2），．．．を含めることによりｓを確約することができる。更に代替的に、Ｉは、ノードが注目する正味効果を保存しているマークル木の根値を含むことにより、正味効果の集合ｓを確約することができる。より一般的には、本発明のシステムは他の確約方法を用いてＩの正味効果の一部を一時的に隠蔽することができる。
【０１２２】
スマート契約の（少なくとも部分的に）確約された宣言的発動の関連データは通常の宣言的発動と同様であってよい。
【０１２３】
簡潔のため、文脈が充分に明らかな場合、確約された宣言的発動Ｉをより簡素に宣言的発動、更に簡素に発動と呼ぶ場合がある。スマート契約の発動が確約された宣言的発動でないと強調したい場合、通常発動という用語を用いる場合がある。
【０１２４】
議論及び追加的詳細事項：確約された宣言的発動に適用可能な通常発動に関する議論及び追加的詳細が後続の発動に自動的に拡張される。
【０１２５】
適切な発動ユーザーによりデジタル署名された、確約された発動がＣの関連する実行の全ての正味効果を認証し続けるが、それらの集合ｓが間接的に、すなわちｓの確約を認証することにより認証される点に注意されたい。
【０１２６】
以下で分かるように、本発明のシステムにより、Ｉが指定する実行ｅを計算する負担を全てのユーザー又はあまりに多くのユーザーにかけることなく、ブロックチェーンを観察している全てのユーザーが契約Ｃの確約された発動Ｉが正しいか否かを判定することができる。
【０１２７】
そのような確約された発動Ｉがどのように登録されるかを以下に述べる。
【０１２８】
２．確約された発動の登録
確約された発動Ｉは、通常の発動と極めて同様な仕方でブロックチェーンに入ることができる。例えば、Ｉがブロックチェーンに入る条件としてＩの構文的有効性が充分であろう。
【０１２９】
このような構文的有効性の確認は、Ｉの対価がＩで宣言されたステップ数が指定された実行を行うのに充分であるか否かの確認を含んでいてよい。実際、対価及び宣言されたステップ数は、Ｉにより指定されてブロックチェーン内で生じる実行ｅの正味効果とは考えられない。従って、対価及び宣言されたステップ数は公然とＩに出現することができる。
【０１３０】
再び、構文的に無効な確約された発動を含むブロックは無効であると考えられ、Ｉが拡散する間に他のユーザーにＩを転送するために確約された発動の構文的有効性が必要とされる。
【０１３１】
確約された発動Ｉがブロックチェーンに登録されたならば、システムはその正しさを確認する処理を開始する。以下、当該処理の説明に移る。
【０１３２】
３．確約された発動の割り当て
１個以上のブロックに登録された、１個以上の確約されたスマート契約発動の集合Ｓが、通常の発動の割り当てについて記述された任意の方法に従い、検証者の集合Ｖsに割り当てられる。
【０１３３】
４．確約された発動の検証
確約された発動の集合Ｓがブロックチェーンに登録されたならば、ＶSの各検証者ｖは、適切な入力及び状態に対してＳ内の各発動Ｉの契約Ｃを実行し、次いで自身の応答を認証して拡散する。既に上で述べたように、このような応答は、Ｉで指定された実行ｅのいくつかの正味効果の個人化された確約だけを含んでいてよい。以下にそのような応答のいくつかの可能な例を挙げる。
【０１３４】
Ｉが露わに無効である（例えば、その発動ｅのステップ数がＩで宣言されたステップ数を上回る）場合、ｖは、例えば自身の応答にペア（Ｉ、無効）を含めることにより、これがＳに関する自身の応答であることを示す。
【０１３５】
第２の例において、ｅをＩに呼び出された（指定された）実行とし、Ｉにｅの正しいステップ数を宣言させ、ｎｅが所定の順序及び仕方で示すｅの全ての正味効果を含むようにし、確約Ｈ（ｎｅ）を含むことによりＩにｎｅを隠蔽させる。次いで、ｅ（従ってｎｅ）を再構築した後で、ｖはＩを識別する情報と、好適に個人化されたｎｅの確約とを認証することができる。ｎｅに対するｖの個人化された確約とは、（ａ）たとえｖがＩに含まれる確約Ｈ（ｎｅ）を知っていて、且つｎｅの他の確約も知っていたとしても、ｖがｎｅを知らずにｈvを計算するのは困難であり、（ｂ）ｎｅとｖを知っていればｎｅに対するｖの個人化された確約を誰でも簡単に計算できるようなｎｅに対する確約ｈvを意味する。
【０１３６】
例えば、ｎｅに対するｖの個人化された確約はＨv（ｎｅ）を含んでいてよく、ここにＨvはＨv（ｘ）＝Ｈ（ｖ，ｘ）で定義されるハッシュ関数である。従って、ｈ＝Ｈv（ｎｅ）＝Ｈ（ｖ，ｎｅ）は実際にｎｅに対するｖの確約である。実際、Ｈ（ｖ，ｎｅ’）＝ｈとなる別の値ｎｅ’を誰も見つけることができず、値ｎｅが開示されたならば、誰でも実際にｈ＝Ｈ（ｖ，ｎｅ）であることを検証できる。更に、ｖは当該確約を、Ｉで与えられる確約Ｈ（ｎｅ）から、且つｚ≠ｖならばＨ（ｚ，ｎｅ）からも容易に計算できないため、ｖの当該確約は個人化されている。
【０１３７】
ｖをｎｅと共にハッシングするのはｎｅに対するｖの個人化された確約の一例に過ぎず、一切の限定を意図していない点に注意されたい。例えば、Ｈ（ｖ，ｎｅ）のｖを好適にはｖに一意に依存する任意のデータで代替しても同様にうまくいく。ｎｅへの個人化された任意の形式の確約も本発明の範囲に含まれる。
【０１３８】
（通常の発動に関して、集合ＶSが秘密抽選を介して選択されたならば、ｖは、自身の応答に加え、自身が本当にＶSに属している証拠も拡散する。再び、ｖは、Ｓ内の各々の確約された発動Ｉに関する自身の応答を通常の発動の場合とほぼ同様に別々又は一緒に、認証することができる）（脚注５：例えば、Ｓ内の発動がＩ1，Ｉ2，Ｉ3，Ｉ4であり、発動Ｉ1，Ｉ3，．．．が有効（且つ各々正味効果ｎｅ1，ｎｅ3，．．．を有している）、発動Ｉ2，Ｉ4，．．．露わに無効であれば、ｖはＳＩＧv（（Ｉ1，Ｈv（ｎｅ1）），（Ｉ2，無効），（Ｉ3，Ｈv（ｎｅ3）），（Ｉ4，無効），．．．）を計算して拡散することができる。再び、より簡潔に，Ｉ1，Ｉ2，Ｉ3，Ｉ4、．．．が所与の順序でのＳの発動である場合、ｖは、シーケンス（Ｈv（ｎｅ1）），０，Ｈv（ｎｅ3），０，．．．）を認証して拡散することができ、ここに０は対応する発動が露わに無効であることを示す。検証者ｖはまた自身の応答を一緒に認証することができるが、Ｓ内の個々の発動に関するｖの認証された応答を抽出できるようにする。例えば、ｖは、各々の葉がＳ内の別々の発動に関するｖの応答を保存するマークル木を構築し、次いで当該マークル木の根に保存された値を認証することができる。）
【０１３９】
確約された発動の実行ｅの正味効果ｎｅに対して個人化された確約を用いることで、ＶSの検証者ｖには、例えばＩに呼び出された実行ｅを実際に実行することによりｎｅの値を知ることなしには、たとえ発動Ｉが適切に用意されたことをｖが確信していても、Ｉが有効であると認証することが困難になる。同時に、ｎｅを知ったならば、確約がＩに含まれている値ｎｅと、ｖにより個人化された確約がＩに関するｖの応答に含まれている値が同一であるか否かを誰でも検証することができる。
【０１４０】
確約された発動の正しさ：ＶSの正直な検証者は、Ｓ内の各々確約された発動Ｉに関する正しい応答だけ、従って単一の応答を提供する。そのような発動Ｉが正しいと考えられる（証明される）のは、Ｉで確約された隠蔽された正味効果が、ＶSの検証者の少なくとも所与の数Ｘの応答で確約された正味効果と同一の場合である。ＶSの検証者のうち少なくともＹ人の応答が、Ｉが無効であることを示す場合、発動Ｉは正しくないと考えてよい。代替的に、ブロックチェーンの所与の位置で未だ正しいことが証明されていない場合、Ｉは正しくないと考えてよい。
【０１４１】
しかし、ｎｅを知らなければ、Ｈ（ｎｅ）＝Ｈv（ｎｅ）であるか否かを判定するのは困難である点に注意されたい。従って、システムは確約された発動のいずれが正しいかを判定する何らかの方法を必要とする。そのような複数の方法について以下に述べる。
【０１４２】
４．５  隠蔽された正味効果の開示
Ｉを発動した適切な関係者をｉとし、Ｉにより指定され、且つ確約がＩに出現する実行ｅの正味効果をｎｅとする。一般性を失うことを意図することなく、Ｉ内でｎｅを確約する方法がｎｅのハッシュを含んでいるものとする。ｉが正直であると仮定すれば、恐らくｉは（１）値ｎｅを知っていて、（２）確約Ｈ（ｎｅ）を適切に計算してＩに含めており、（３）正味効果ｎｅが実際にブロックチェーン内で発現することを望んでいる。
【０１４３】
従って、ＶSでＸ人よりも多い検証者ｖがｎｅに対する個人化された確約、例えばＨv（ｎｅ）を自身の応答に含んでいることをｉが知ったならば、ｉは、好適には認証された仕方で、発動Ｉを識別する情報と共にｎｅを拡散する。
【０１４４】
ｎｅが開示されたならば、ブロックチェーンメッセージを観察している誰もが、値ｎｅが、Ｉ内で確約された値、及び検証者ＶSのうち少なくともＸ人の応答の個人化された確約における値と同じ値であることが分かる。換言すれば、観察者全員が、確約された発動Ｉが正しいことを知る。
【０１４５】
ｎｅを開示するのが発動者ｉである必要はない点に注意されたい。例えば、ｅを実行し，ｎｅを計算し、ｎｅがＩで確約された値、及びＶSの検証者のうち少なくともＸ人の応答の個人化された確約における値と本当に同じであることを理解した任意の主体（例えば、Ｉが属する確約された発動の集合Ｓに割り当てられた特別の検証者）であってよい。
【０１４６】
ここでブロックチェーン内での上の理解を公式なものとする。
【０１４７】
５．確約された発動に関する評決
Ｉを、ブロックチェーンに既に登録されているが、最終評決を有していない確約された発動とする。次いで、Ｉが正しいと理解している新規ブロックＢの構築者ｕは、Ｉが正しいことを示す情報をＢに含めることにより、Ｉに関する最終評決を提供する。
【０１４８】
本システムはまた、最終評決が未だ存在しないブロックチェーンに既に登録された確約された発動の集合Ｓに関する全ての確約された発動の最終評決を同時に提供することができる。
【０１４９】
例えば、Ｓのどの発動が正しいかを知っていて、新規ブロックＢを構築しているユーザーｕは、Ｓのそのような発動に関する最終評決をＢに含めてよい。このような最終評決はまた、集合Ｓ自体を識別する、好適には認証された情報も含んでいてよい。ｕがＢを認証する場合、そのような評決はｕにより自動的に認証される。代替的に、ｕはＳの発動に関する最終評決を別々に認証することができる。
【０１５０】
代替的に、ｕは、ＶSの充分に多くの検証者の認証された応答をブロックに含めてよく、そのように含まれた応答から、Ｓ内の有効な発動及びＳの有効でない発動を判定可能にする。その際、通常の発動のケースで述べた方法のいずれかを用いてよい。
【０１５１】
議論及び追加的詳細事項：ブロックＢが有効であると考えられるのは、通常の取引が有効である場合だけでなく、以前に登録された発動（通常又は確約された）に関する最終評決がこのような発動の正しさを適切に反映する場合もそうである。
【０１５２】
通常の発動について述べた他の議論及び追加的詳細事項も同様に確約された発動にあてはまる。通常の発動について提示された各種の変型例及び追加事項でも同じである。
【０１５３】
特に、一切の限定を意図することなく、資金運用技術用の重み付けも、確約された発動の検証者にあてはまる。従って、一人の検証者を、重みｎを付けてｎ人の別々の検証者として扱うことができる。
【０１５４】
確約された発動Ｉに関する応答が、Ｉの確立した正しさ及び／又はＩで確約された正味効果の確立した開示値と一致する検証者は、例えば、通常の発動又は新規の発動の検証者に関して既に記述したインセンティブ方法のいずれかにより報酬が与えられてよい。
【０１５５】
同様に、確約された発動Ｉに関する応答がＩの確立した正しさ及び／又はＩで確約された正味効果の確立した開示値と一致しない検証者は、例えば、通常の検証者に関して既に記述したインセンティブ方法のいずれかにより過料又はペナルティが科される場合がある。特に、他の少なくともいくつかの発動の検証への割り当てに不適格とされてよい。
【０１５６】
正しくない確約された発動Ｉの発動者もまた、特別な過料を科されるか又は何らかの方法でペナルティを科される場合がある。
【０１５７】
４  変型例及び追加事項
ｓをスマート契約Ｃの確約された発動Ｉにより指定された実行ｅの正味効果の集合とし、ｈ＝Ｈ（ｓ）をＩに含まれるｓに対する確約とする。ある関係者、例えばＩを含む発動の集合に割り当てられた検証者等、Ｉに割り当てられた検証者は、ｓ自体が充分に予測不可能ならば、Ｈ（ｓ）からｓを計算するのに苦労するであろう。しかし、ｓが例えば数ビットしか含んでいない場合、ある関係者が、ハッシュ値がｈとなるまでｓの全ての可能性を試すことは可能であろう。この可能性を阻止すべく、関係者が全部の正味効果を全体的に把握するのが困難になるように例えばｅの全ての正味効果を含むように極めて大きいｓを選択することができる。しかしこれでも充分でない場合がある。
【０１５８】
ｅの確約された正味効果を正しく推測するのが難しいことを保証すべく、予測が困難な特別に選択された量をこれらの正味効果に人為的に含めることができる。例えば、注目するｅの正味効果が新たな状態γ’及び少数のプレーヤー金額調整ａ1，．．．，ａkであるが、Ｉの適切な発動者はこのような正味効果に、実行ｅの終了時点でＣの特別な補助変数の内容ｘを人為的に追加して、ｓ＝（γ’，ａ1，．．．，ａk，ｘ）とすることができる。実際、ｅの正味効果が常に容易に予測できたとしても、ｅの計算は、その単純な効果を発現させるために全く予測不可能な可変内容を有していても、又は有するように設計されていてもよい。従って、ｘが予測困難である場合、たとえγ’，ａ1，．．．，ａkを予測するのが極めて容易としても、Ｈ（ｓ）からｓ＝（γ’，ａ1，．．．，ａk，ｘ）を予測するのは困難であろう。（当然、ｘは純粋に補助的な役割を有し、発動Ｉが正しければブロックチェーンで発現する正味効果とみなすべきではない。）
【０１５９】
代替的に、値ｘは、ｅ及び恐らくは全く別々に指定されたプログラムＰの実行、Ｉに含まれるか又はＩから推論可能な全く別々の指定された入力ｙに依存し得る。そのようなプログラムＰ及び入力ｙは、Ｐ及びｙからｘを予測することが困難になるように選択されていてよい。例えば、Ｐの計算は、時に応じて実行ｅから得られた量を含んでいてよい。代替的に、Ｐ（ｙ）の計算はｅとは全く無関係であってよい。
【０１６０】
再び、Ｉはｘに対する確約を含んでいてよく、Ｉの実行ｅを検証すべく（直接又は間接的に）割り当てられた検証者ｖもまた、ｘを計算して、ｘに対する個人化された確約を自身の応答に含めるよう求められる場合がある。Ｉが正しいと考えてよいのは、Ｉに割り当てられた充分に多くの検証者のこれらの個人化された確約の基礎となる値が互いに一致し、且つ基礎となる値ｘがＩで確約されている場合だけである。従って、Ｉに割り当てられた検証者は、Ｉに関する自身の応答を適切に考慮して欲しい場合にｘを適切に計算するよう奨励される。
【０１６１】
当業者が用いることができる上述の、及び他の可能な変型例のいずれにおいても、Ｉで宣言されたステップの総数が、ｘを計算するのに必要なステップ数も含んでいなければならず、従ってＩの支払うべき対価が増加し得る。しかしＩの適切な発動者は、Ｉの検証者が適切にｘを計算することをより確信できるよう、進んで高い対価を支払う場合がある。
【０１６２】
また、そのような値ｘがどのように使用するかに依らず、Ｉが正しいことが公開されていれば、Ｉがｅの真の正味効果、例えばブロックチェーン内で実際に発現すべきものを含めること、及びｘに対する個人化された確約をＩの唯一の確約とすることも可能であり得る。この場合、Ｉを含む集合Ｓに割り当てられた検証者ｖは、（１）ｅの公けに宣言された正味効果が正しいか否かを示していて、且つ（２）ｘに対する個人化された確約を含んでいる応答を生成するよう求められる。この場合、発動Ｉが正しいと考えられるのは、Ｉで確約されたｘの値が、Ｓに割り当てられた充分に多くの検証者ｖの応答で確約された値と一致する場合であり、そのような応答は公けに宣言されたＩの正味効果が正しいことを示している。
【０１６３】
本明細書に記述する機構が、一般に検証可能な方法での検証等の特定の目的でユーザーの部分集合を無作為に選択することが望ましい他のブロックチェーンシステムに適用できる点に注意されたい。従って、本明細書に記述するシステムは、イーサリアム又はライトコイン等の他のブロックチェーンスキーム、又は直接通貨に関係しないブロックチェーンスキームにも適合させることができる。
【０１６４】
本明細書に記述するシステムは、以下の米国及びＰＣＴ特許出願のいくつか又は全てに開示された機構に適用及び組み合わせるべく適合することができる。すなわち２０１５年２月１７日出願の第６２／１１７，１３８号明細書、２０１５年２月２６日出願の第６２／１２０，９１６号明細書、２０１５年４月２日出願の第６２／１４２，３１８号明細書、２０１５年９月１５日出願の第６２／２１８，８１７号明細書、２０１６年３月２９日出願の第６２／３１４，６０１号明細書、２０１６年２月１７日出願のＰＣＴ／ＵＳ２０１６／０１８３００号明細書、２０１６年４月２５日出願の第６２／３２６，８６５号明細書、２０１６年５月４日出願の第６２／３３１，６５４号明細書、２０１６年５月９日出願の第６２／３３３，３４０号明細書、２０１６年５月３１日出願の第６２／３４３，３６９号明細書、２０１６年６月２日出願の第６２／３４４，６６７号明細書、２０１６年６月７日出願の第６２／３４６，７７５号明細書、２０１６年６月１６日出願の第６２／３５１，０１１号明細書、２０１６年６月２２日出願の第６２／３５３，４８２号明細書、２０１６年６月２４日出願の第６２／３５４，１９５号明細書、２０１６年７月１９日出願の第６２／３６３，９７０号明細書、２０１６年８月１日出願の第６２／３６９，４４７号明細書、２０１６年８月２４日出願の第６２／３７８，７５３号明細書、２０１６年９月２日出願の第６２／３８３，２９９号明細書、２０１６年９月１３日出願の第６２／３９４，０９１号明細書、２０１６年９月２７日出願の第６２／４００，３６１号明細書、２０１６年１０月３日出願の第６２／４０３，４０３号明細書、２０１６年１０月２０日出願の第６２／４１０，７２１号明細書、２０１６年１１月３日出願の第６２／４１６，９５９号明細書、２０１６年１１月１６日出願の第６２／４２２，８８３号明細書、２０１７年２月６日出願の第６２／４５５，４４４号明細書、２０１７年２月１４日出願の第６２／４５８，７４６号明細書、２０１７年２月１６日出願の第６２／４５９，６５２号明細書、２０１７年３月１５日出願の第６２／４７１，５６２号明細書、２０１７年５月１６日出願の第６２／５０７，０７４号明細書、２０１７年５月２５日出願の第６２／５１０，９０５号明細書、２０１７年６月２１日出願の第６２／５２２，９２７号明細書、２０１７年７月２４日出願の第６２／５３６，０６１号明細書、２０１７年８月４日出願の第６２／５４１，５６８号明細書、２０１７年８月２１日出願の第６２／５４８，２０１号明細書、２０１７年５月４日出願のＰＣＴ／ＵＳ２０１７／０３１０３７号明細書、２０１７年８月１７日出願の第１５／５５１，６７８号明細書、２０１７年９月２８日出願の第６２／５６４，６７０号明細書、２０１７年１０月４日出願の第６２／５６７，８６４号明細書、２０１７年１０月１０日出願の第６２／５７０，２５６号明細書、２０１７年１１月２日出願の第６２／５８０，７５７号明細書、２０１７年１２月１９日出願の第６２／６０７，５５８号明細書、２０１８年２月２０日出願の第６２／６３２，９４４号明細書及び２０１８年３月１５日出願の第６２／６４３，３３１号明細書であり、これら全てを本明細書において引用している。
【０１６５】
本明細書に記述するシステムのソフトウェア実装は、計算機可読媒体に保存されていて、１個以上のプロセッサにより実行される実行可能コードを含んでいてよい。計算機可読媒体は非一時的でよく、コンピュータハードドライブ、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、フラッシュドライブ、ＳＤカード等の可搬コンピュータ記憶媒体、及び／又は例えばユニバーサルシリアルバス（ＵＳＢ）インターフェースを備えた他のドライブ、及び／又は実行可能コードを保存してプロセッサにより実行させることが可能な他の有形又は非一時的計算機可読媒体又はコンピュータメモリを含んでいてよい。本明細書に記述するシステムは任意の適切なオペレーティングシステムと組み合わせて用いることができる。
【０１６６】
本発明の他の実施形態は、本明細書に開示する本発明の仕様又実施を考慮することにより当業者には明らかになろう。仕様及び実施例が例示目的に過ぎず、本発明の真の範囲及び趣旨は以下の請求項により示される。
【図１】
2020537391.tif 000010
【図２】
2020537391.tif 000011
【国際調査報告】
2020537391.tif 000012
2020537391.tif 000013
2020537391.tif 000014
2020537391.tif 000015