(57)【要約】スマートコントラクトの実行を検証するための方法及びシステムは、少なくとも１つの一次ブロックを有するブロックチェーン内にスマートコントラクトを格納することを備える。スマートコントラクトは、電子的に定義された契約条項のセットを有し、各条項は、少なくとも１つの満足度値によって定義され、契約条項のセットの満足度値の組合せは、コントラクトの満足度ハッシュ値を有する。１つ又は複数の実行値のサブセットを各々有する１つ又は複数の電子的に格納された二次トランザクションのセットが読み取られ、契約条項に対応するトランザクションのサブセットが選択される。トランザクションのサブセットの実行値の組合せの実行ハッシュ値が決定される。トランザクションのサブセットの実行値の組合せの実行ハッシュ値がスマートコントラクトの満足度ハッシュ値に一致する場合、スマートコントラクトは完全に実行されたと見なされる。【選択図】  図７
2021535668.tif 000002
【特許請求の範囲】
【請求項１】
スマートコントラクトの実行を検証するための方法であって、
少なくとも１つの一次ブロックを有するブロックチェーン内に前記スマートコントラクトを格納することと、ここで、前記スマートコントラクトは、電子的に定義された契約条項のセットを有し、各条項は、少なくとも１つの満足度値によって定義され、契約条項の前記セットの前記満足度値の前記組合せは、前記スマートコントラクトの満足度ハッシュ値を有する、
１つ又は複数の実行値のサブセットを各々有する１つ又は複数の電子的に格納された二次トランザクションのセットを読み取ることと、
電子的に格納された二次トランザクションの前記セットから、前記スマートコントラクトの前記契約条項に対応するトランザクションのサブセットを選択することと、
トランザクションの前記サブセットの実行値の前記組合せの実行ハッシュ値を決定することと、
トランザクションの前記サブセットの実行値の前記組合せの前記実行ハッシュ値が前記スマートコントラクトの前記満足度ハッシュ値に一致する場合、前記スマートコントラクトが完全に実行されていると決定することと
を備える方法。
【請求項２】
満足度値は、
実行値で表すことができる条件の存在、及び
実行値で表すことができる変数の値
のうちの１つを定義する、請求項１に記載の方法。
【請求項３】
前記二次トランザクションは、少なくとも１つのイベントコンポーネントを各々有するトランザクションイベントエントリとして格納され、
各二次トランザクションは、１つ又は複数のイベントコンポーネントによって表される、
請求項１又は２に記載の方法。
【請求項４】
各実行値は、少なくとも１つのイベントコンポーネントから決定される、請求項３に記載の方法。
【請求項５】
前記トランザクションイベントエントリは、ブロックチェーンの１つ又は複数の二次ブロック内に格納される、請求項３又は４に記載の方法。
【請求項６】
前記二次ブロックは、前記少なくとも１つの一次ブロックを有する前記ブロックチェーン内に格納され、前記二次ブロックは、前記少なくとも１つの一次ブロックと区別可能である、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記二次ブロックは、前記少なくとも１つの一次ブロックを有する前記ブロックチェーンから独立している追加のブロックチェーン内に格納される、請求項１乃至５のいずれか一項に記載の方法。
【請求項８】
前記スマートコントラクトの各契約条項の前記少なくとも１つの満足度値は、前記契約条項が満たされていると見なされるための前記契約条項の少なくとも１つの必要値に対応する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記スマートコントラクトの前記契約条項に対応する二次トランザクションの前記サブセットは、前記スマートコントラクトを形成する契約条項の前記セットに一致する実行値を有するトランザクションから本質的に構成される、請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記スマートコントラクトの前記満足度ハッシュ値に一致する二次トランザクションの前記サブセットの実行値の前記組合せの前記実行ハッシュ値は、前記スマートコントラクトの満足度値の前記組合せに一致する実行値の組合せを前記二次トランザクションが有する状態を表し、それによって、前記スマートコントラクトの前記契約条項のすべてが満たれていることを更に示す、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記少なくとも１つの一次ブロックの各々は、前記スマートコントラクトを形成する前記契約条項のサブセットを格納する、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記１つ又は複数の一次ブロックの少なくとも１つの新たなブロック内に前記スマートコントラクトに対する改訂を格納すること
を更に備える、請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
前記スマートコントラクトに対する前記改訂は、
前記スマートコントラクトの所与の契約条項に対する修正、これによって、前記少なくとも１つの新たなブロックは、前記所与の契約条項の少なくとも１つの満足度値の更新を示す、及び
契約条項の前記セットへの少なくとも１つの新たな契約条項の追加、これによって、前記少なくとも１つの新たなブロックは、前記少なくとも１つの新たな契約条項の各々の少なくとも１つの新たな満足度値を示す、
のうちの１つ又は複数を備える、請求項１２に記載の方法。
【請求項１４】
前記改訂されたスマートコントラクトは、電子的に定義された契約条項の更新されたセットを有し、契約条項の前記更新されたセットの満足度値の前記組合せは、更新された満足度ハッシュ値を有し、
前記方法は、
電子的に格納された二次トランザクションの前記セットから、前記改訂されたスマートコントラクトの電子的に定義された契約条項の前記更新されたセットに対応するトランザクションの更新されたサブセットを選択することと、
トランザクションの前記更新されたサブセットの実行値の前記組合せの更新された実行ハッシュ値を決定することと、
前記更新された実行ハッシュ値が前記改訂されたスマートコントラクトの前記更新された満足度ハッシュ値に一致する場合、前記改訂されたスマートコントラクトが完全に実行されていると決定することと
を更に備える、請求項１２又は１３に記載の方法。
【請求項１５】
前記ブロックチェーンのブロック内で当事者初期化トランザクションを発行すること
を更に備え、前記当事者初期化トランザクションは、
所与の当事者に関連する一意識別子と、
前記当事者に関連する第１の秘密鍵から導出された第１の公開鍵と、
前記当事者に関連する第２の秘密鍵から導出された第２の公開鍵と
を備え、
トランザクションの前記サブセットの少なくとも１つの所与のトランザクションは、前記一意識別子をその実行値のうちの１つとして備える、
請求項１乃至１４のいずれか一項に記載の方法。
【請求項１６】
前記少なくとも１つの所与のトランザクションは、前記所与のトランザクションが、前記第１の秘密鍵を提供する前記当事者から暗号的に生成された前記第１の公開鍵を含んでいることに基づいて、有効なトランザクションとして検証される、請求項１５に記載の方法。
【請求項１７】
認証更新ブロックを発行することを更に備え、前記認証更新ブロックは、
前記一意識別子と、
前記第２の秘密鍵を提供する前記当事者から暗号的に生成された前記第２の公開鍵と、
前記当事者に関連する第３の秘密鍵から導出された第３の公開鍵と
を備え、
前記認証更新トランザクションの後に発生するトランザクションの前記サブセットの所与のトランザクションは、前記第３の秘密鍵を提供する前記当事者から暗号的に生成された前記第３の公開鍵を含んでいる場合、有効なトランザクションであると決定され、
前記認証更新トランザクションの後に発生するトランザクションの前記サブセットの別の所与のトランザクションは、前記第３の公開鍵を含んでいない場合、無効なトランザクションであると決定される、
請求項１５又は１６に記載の方法。
【請求項１８】
ブロックチェーントランザクションの当事者のアイデンティティを検証する方法であって、
ブロックチェーン内で当事者初期化ブロックを発行すること
を備え、前記当事者初期化ブロックは、
所与の当事者に関連する一意識別子と、
前記当事者に関連する第１の秘密鍵から導出された第１の公開鍵と、
前記当事者に関連する第２の秘密鍵から導出された第２の公開鍵と
を備える、方法。
【請求項１９】
前記ブロックチェーン内でイベントトランザクションブロックを発行すること
を更に備え、前記イベントトランザクションブロックは、
イベントに関する実行値と、
前記所与の当事者に関連する前記一意識別子と、
前記第１の秘密鍵を提供する前記当事者から暗号的に生成された前記第１の公開鍵と
を備える、請求項１８に記載の方法。
【請求項２０】
前記イベントトランザクションブロックは、前記ブロックが前記第１の公開鍵を含んでいることに基づいて有効であると決定される、請求項１９に記載の方法。
【請求項２１】
認証更新ブロックを発行することを更に備え、前記認証更新ブロックは、
前記一意識別子と、
前記第２の秘密鍵を提供する前記当事者から暗号的に生成された前記第２の公開鍵と、
前記当事者に関連する第３の秘密鍵から導出された第３の公開鍵と
を備える、請求項１８乃至２０のいずれか一項に記載の方法。
【請求項２２】
前記認証更新トランザクションの後に発行される所与のイベントトランザクションブロックは、前記第３の秘密鍵を提供する前記当事者から暗号的に生成された前記第３の公開鍵を含んでいる場合、有効なトランザクションであると決定され、
前記認証更新トランザクションの後に発行される別のイベントトランザクションブロックは、前記第３の公開鍵を含んでいない場合、無効なトランザクションであると決定される、
請求項２１に記載の方法。
【請求項２３】
スマートコントラクトの実行を検証するためのコンピュータ実装システムであって、
少なくとも１つのデータ格納デバイスと
前記少なくとも１つの格納デバイスに結合された少なくとも１つのプロセッサと
を備え、前記少なくとも１つのプロセッサは、
少なくとも１つの一次ブロックを有するブロックチェーン内に前記スマートコントラクトを格納することと、ここで、前記スマートコントラクトは、電子的に定義された契約条項のセットを有し、各条項は、少なくとも１つの満足度値によって定義され、契約条項の前記セットの前記満足度値の前記組合せは、前記スマートコントラクトの満足度ハッシュ値を有する、
１つ又は複数の実行値のサブセットを各々有する１つ又は複数の電子的に格納された二次トランザクションのセットを読み取ることと、
電子的に格納された二次トランザクションの前記セットから、前記スマートコントラクトの前記契約条項に対応するトランザクションのサブセットを選択することと、
トランザクションの前記サブセットの実行値の前記組合せの実行ハッシュ値を決定することと、
トランザクションの前記サブセットの実行値の前記組合せの前記実行ハッシュ値が前記スマートコントラクトの前記満足度ハッシュ値に一致する場合、前記スマートコントラクトが完全に実行されていると決定することと
を行うように構成される、システム。
【請求項２４】
満足度値は、
実行値で表すことができる条件の存在、及び
実行値で表すことができる変数の値
のうちの１つを定義する、請求項２３に記載のシステム。
【請求項２５】
前記二次トランザクションは、少なくとも１つのイベントコンポーネントを各々有するトランザクションイベントエントリとして格納され、
各二次トランザクションは、１つ又は複数のイベントコンポーネントによって表される、
請求項２３又は２４に記載のシステム。
【請求項２６】
各実行値は、少なくとも１つのイベントコンポーネントから決定される、請求項２５に記載のシステム。
【請求項２７】
前記トランザクションイベントエントリは、ブロックチェーンの１つ又は複数の二次ブロック内に格納される、請求項２５又は２６に記載のシステム。
【請求項２８】
前記二次ブロックは、前記少なくとも１つの一次ブロックを有する前記ブロックチェーン内に格納され、前記二次ブロックは、前記少なくとも１つの一次ブロックと区別可能である、請求項２３乃至２７のいずれか一項に記載のシステム。
【請求項２９】
前記二次ブロックは、前記少なくとも１つの一次ブロックを有する前記ブロックチェーンとは無関係の追加のブロックチェーン内に格納される、請求項２３乃至２７のいずれか一項に記載のシステム。
【請求項３０】
前記スマートコントラクトの各契約条項の前記少なくとも１つの満足度値は、前記契約条項が満たされていると見なされるための前記契約条項の少なくとも１つの必要値に対応する、請求項２３乃至２９のいずれか一項に記載のシステム。
【請求項３１】
前記スマートコントラクトの前記契約条項に対応する二次トランザクションの前記サブセットは、前記スマートコントラクトを形成する契約条項の前記セットに一致する実行値を有するトランザクションから本質的に構成される、請求項２３乃至３０のいずれか一項に記載のシステム。
【請求項３２】
前記スマートコントラクトの前記満足度ハッシュ値に一致する二次トランザクションの前記サブセットの実行値の前記組合せの前記実行ハッシュ値は、前記スマートコントラクトの満足度値の前記組合せに一致する実行値の組合せを前記二次トランザクションが有する状態を表し、それによって、前記スマートコントラクトの前記契約条項のすべてが満たれていることを更に示す、請求項２３乃至３１のいずれか一項に記載のシステム。
【請求項３３】
前記少なくとも１つの一次ブロックの各々は、前記スマートコントラクトを形成する前記契約条項のサブセットを格納する、請求項２３乃至３２のいずれか一項に記載のシステム。
【請求項３４】
前記プロセッサは、
前記１つ又は複数の一次ブロックの少なくとも１つの新たなブロック内に前記スマートコントラクトに対する改訂を格納する
ように更に構成される、請求項２３乃至３３のいずれか一項に記載のシステム。
【請求項３５】
前記スマートコントラクトに対する前記改訂は、
前記スマートコントラクトの所与の契約条項に対する修正、これによって、前記少なくとも１つの新たなブロックは、前記所与の契約条項の少なくとも１つの満足度値の更新を示す、及び
契約条項の前記セットへの少なくとも１つの新たな契約条項の追加、これによって、前記少なくとも１つの新たなブロックは、前記少なくとも１つの新たな契約条項の各々の少なくとも１つの新たな満足度値を示す、
のうちの１つ又は複数を備える、請求項３４に記載のシステム。
【請求項３６】
前記改訂されたスマートコントラクトは、電子的に定義された契約条項の更新されたセットを有し、契約条項の前記更新されたセットの満足度値の前記組合せは、更新された満足度ハッシュ値を有し、
前記プロセッサは、
電子的に格納された二次トランザクションの前記セットから、前記改訂されたスマートコントラクトの電子的に定義された契約条項の前記更新されたセットに対応するトランザクションの更新されたサブセットを選択することと、
トランザクションの前記更新されたサブセットの実行値の前記組合せの更新された実行ハッシュ値を決定することと、
前記更新された実行ハッシュ値が前記改訂されたスマートコントラクトの前記更新された満足度ハッシュ値に一致する場合、前記改訂されたスマートコントラクトが完全に実行されていると決定することと
を行うように更に構成される、請求項３４又は３５に記載のシステム。
【請求項３７】
前記プロセッサは、
前記ブロックチェーンのブロック内で当事者初期化トランザクションを発行する
ように更に構成され、前記当事者初期化トランザクションは、
所与の当事者に関連する一意識別子と、
前記当事者に関連する第１の秘密鍵から導出された第１の公開鍵と、
前記当事者に関連する第２の秘密鍵から導出された第２の公開鍵と
を備え、
トランザクションの前記サブセットの少なくとも１つの所与のトランザクションは、前記一意識別子をその実行値のうちの１つとして備える、
請求項２３乃至３６のいずれか一項に記載のシステム。
【請求項３８】
前記少なくとも１つの所与のトランザクションは、前記所与のトランザクションが、前記第１の秘密鍵を提供する前記当事者から暗号的に生成された前記第１の公開鍵を含んでいることに基づいて、有効なトランザクションとして検証される、請求項３７に記載のシステム。
【請求項３９】
認証更新ブロックを発行することを更に備え、前記認証更新ブロックは、
前記一意識別子と、
前記第２の秘密鍵を提供する前記当事者から暗号的に生成された前記第２の公開鍵と、
前記当事者に関連する第３の秘密鍵から導出された第３の公開鍵と
を備え、
前記認証更新トランザクションの後に発生するトランザクションの前記サブセットの所与のトランザクションは、前記第３の秘密鍵を提供する前記当事者から暗号的に生成された前記第３の公開鍵を含んでいる場合、有効なトランザクションであると決定され、
前記認証更新トランザクションの後に発生するトランザクションの前記サブセットの別の所与のトランザクションは、前記第３の公開鍵を含んでいない場合、無効なトランザクションであると決定される、
請求項３７又は３８に記載のシステム。
【請求項４０】
ブロックチェーントランザクションの当事者のアイデンティティを検証するためのコンピュータ実装システムであって、
少なくとも１つのデータ格納デバイスと
前記少なくとも１つの格納デバイスに結合された少なくとも１つのプロセッサと
を備え、前記少なくとも１つのプロセッサは、ブロックチェーン内で当事者初期化ブロックを発行するように構成され、前記当事者初期化ブロックは、
所与の当事者に関連する一意識別子と、
前記当事者に関連する第１の秘密鍵から導出された第１の公開鍵と、
前記当事者に関連する第２の秘密鍵から導出された第２の公開鍵と
を備える、システム。
【請求項４１】
前記プロセッサは、
前記ブロックチェーン内でイベントトランザクションブロックを発行する
ように更に構成され、前記イベントトランザクションブロックは、
イベントに関する実行値と、
前記所与の当事者に関連する前記一意識別子と、
前記第１の秘密鍵を提供する前記当事者から暗号的に生成された前記第１の公開鍵と
を備える、請求項４０に記載のシステム。
【請求項４２】
前記イベントトランザクションブロックは、前記ブロックが前記第１の公開鍵を含んでいることに基づいて有効であると決定される、請求項４１に記載のシステム。
【請求項４３】
前記プロセッサは、認証更新ブロックを発行するように更に構成され、前記認証更新ブロックは、
前記一意識別子と、
前記第２の秘密鍵を提供する前記当事者から暗号的に生成された前記第２の公開鍵と、
前記当事者に関連する第３の秘密鍵から導出された第３の公開鍵と
を備える、請求項４０乃至４２のいずれか一項に記載のシステム。
【請求項４４】
前記認証更新トランザクションの後に発行される所与のイベントトランザクションブロックは、前記第３の秘密鍵を提供する前記当事者から暗号的に生成された前記第３の公開鍵を含んでいる場合、有効なトランザクションであると決定され、
前記認証更新トランザクションの後に発行される別のイベントトランザクションブロックは、前記第３の公開鍵を含んでいない場合、無効なトランザクションであると決定される、
請求項４３に記載のシステム。
【発明の詳細な説明】
【関連特許出願】
【０００１】
本出願は、２０１８年８月３０日に出願された「SYSTEM AND METHOD FOR IMPROVED BLOCKCHAIN-IMPELMENTED SMART CONTRACT」と題する米国仮特許出願第６２／７２４，６８８号からの優先権を主張し、その開示は、参照によりその全体が本明細書に組み込まれる。
【技術分野】
【０００２】
本開示は、一般にブロックチェーン技術に関し、より詳細には、ブロックチェーン技術上でスマートコントラクトを実装するためのシステム及び方法に関する。
【背景技術】
【０００３】
ブロックチェーンは、順次追加専用データベースフォーマットに組み込まれた一連の動作又はトランザクションである。ブロックチェーンを可能にする重要な技術は、ハッシュ化アルゴリズムである。暗号学的ハッシュとは、任意の入力値をとり、各一意の入力値に対して常に一意の出力を作り出すアルゴリズムである。同じ入力は常に同じ出力を作成するが、異なる入力が同じ出力を作成することはない。このように、ハッシュは、特定のコンテンツに対して一意識別子を作成する方法であり、このハッシュを作り出した元のコンテンツが、結果として得られたハッシュだけから推定されることはないであろう。
【０００４】
新たなコンテンツは各々、ブロックに含まれることによってブロックチェーンデータベースに確認される。各ブロックは、暗号的に有効であると確認された１つ又は複数のコンテンツを含む。新たなブロックが作成されると、そのコンテンツは、チェーンにおける前のブロックのハッシュを組み合わせてハッシュ化される。これは、ブロックのチェーンを形成しながらブロックチェーンが成長するつれ、延々と行われる。アタッカがブロックチェーンにおいて何も変更することができないため、この技術は興味深い。コンテンツデータを破壊しようとしてそれを改ざんすると、最小の桁であってもハッシュ化チェーンの和を完全に変えてしまい、リンクを破損させる。ハッシュのチェーンを合計することによって、インターネット上の信頼性のないコンピュータから受信されたデータが有効であることを確実にすることができるため、これは重要なことである。
【０００５】
ブロックチェーンデータベースは、ハッシュのその暗号チェーンにより、データの改ざんが不可能であることを確実する。このように、いくらかランダムに互いに接続されたコンピュータは、自己回復式のピアツーピアネットワークを作成することができる。各コンピュータはネットワーク上の他のノードに接続し、それら自身が他のノードに接続して、通信メッシュを形成する。万一１つのピアが応答しなくなっても、ネットワークは、他の接続を使用して自然にバランスを取り直すため影響を受けることはない。このネットワーク上のピアは、互いを一度も信頼することなくブロックチェーンデータを交換して同期させる。暗号学的ハッシュにより、各ピアは、データを合計し、それが目的どおりに送受信されたことを確認することができる。
【０００６】
ピアツーピアネットワークによって確立されたネットワークトポグラフィの上にはゴシップメッセージングプロトコルが構築されている。このプロトコルは、メッセージ反復（エコー）を最小限に抑えつつ、すべてのノードがネットワーク上で送られたメッセージのコピーを受信することを確実にするように、ｐ２ｐネットワーク上の各ピア間でメッセージが交換される方法を決定する。ブロックチェーンに挿入すべき新たなトランザクションが作成されると、ノードは、それが接続されている複数のピアにこのトランザクションをゴシップメッセージとして送り、次に、それらのピアがそれを自身のピアに転送し、ネットワーク全体がメッセージを受信するまでこれが続く。新たなトランザクションは、各アクタによって検証されて、一時的なトランザクションプールに追加され、確認ブロックによって確認されるまで無期限に滞在する。確認されると、それはトランザクションプールから除かれ、永遠に最後のブロックチェーンに追加される。
【発明の概要】
【０００７】
一態様によれば、スマートコントラクトの実行を検証するための方法が提供され、この方法は、以下を備える：
少なくとも１つの一次ブロック／トランザクションを有するブロックチェーン内にスマートコントラクトを格納／受信すること、ここで、スマートコントラクトは、電子的に定義された契約条項のセットを有し、各条項は、少なくとも１つの満足度値によって定義され、契約条項のセットの満足度値の組合せは、スマートコントラクトの満足度ハッシュ値を有する、
１つ又は複数の実行値のサブセットを各々有する１つ又は複数の電子的に格納された二次トランザクションのセットを読み取ること、
電子的に格納された二次トランザクションのセットから、スマートコントラクトの契約条項に対応するトランザクションのサブセットを選択すること、
トランザクションのサブセットの実行値の組合せの実行ハッシュ値を決定すること、
トランザクションのサブセットの実行値の組合せの実行ハッシュ値がスマートコントラクトの満足度ハッシュ値に一致する場合、スマートコントラクトが完全に実行されていると決定すること。
【０００８】
別の態様によれば、ブロックチェーントランザクションの当事者のアイデンティティを検証する方法が提供され、この方法は、ブロックチェーン内で当事者初期化ブロックを発行することを備え、当事者初期化ブロックは、以下を備える：
所与の当事者に関連する一意識別子、
当事者に関連する第１の秘密鍵から導出された第１の公開鍵、及び
当事者に関連する第２の秘密鍵から導出された第２の公開鍵。
【０００９】
別の態様によれば、スマートコントラクトの実行を検証するためのコンピュータ実装システムが提供され、このシステムは、少なくとも１つのデータ格納デバイスと、少なくとも１つの格納デバイスに結合された少なくとも１つのプロセッサとを備え、少なくとも１つのプロセッサは、以下を行うように構成される：
少なくとも１つの一次ブロックを有するブロックチェーン内にスマートコントラクトを格納すること、ここで、スマートコントラクトは、電子的に定義された契約条項のセットを有し、各条項は、少なくとも１つの満足度値によって定義され、契約条項のセットの満足度値の組合せは、スマートコントラクトの満足度ハッシュ値を有する、
１つ又は複数の実行値のサブセットを各々有する１つ又は複数の電子的に格納された二次トランザクションのセットを読み取ること、
電子的に格納された二次トランザクションのセットから、スマートコントラクトの契約条項に対応するトランザクションのサブセットを選択すること、
トランザクションのサブセットの実行値の組合せの実行ハッシュ値を決定すること、及び
トランザクションのサブセットの実行値の組合せの実行ハッシュ値がスマートコントラクトの満足度ハッシュ値に一致する場合、スマートコントラクトが完全に実行されていると決定すること。
【００１０】
更に別の態様によれば、ブロックチェーントランザクションの当事者のアイデンティティを検証するためのコンピュータ実装システムが提供され、このシステムは、少なくとも１つのデータ格納デバイスと、少なくとも１つの格納デバイスに結合された少なくとも１つのプロセッサとを備える。少なくとも１つのプロセッサは、ブロックチェーン内で当事者初期化ブロックを発行するように構成され、ブロックチェーン内の当事者初期化ブロックは、以下を備える：
所与の当事者に関連する一意識別子、
当事者に関連する第１の秘密鍵から導出された第１の公開鍵、及び
当事者に関連する第２の秘密鍵から導出された第２の公開鍵。
【００１１】
本明細書で説明される実施形態をより良く理解し、それらがどのように実施され得るかをより明確に示すために、ほんの一例として、少なくとも１つの例示的な実施形態を示す添付図面が参照される。
【図面の簡単な説明】
【００１２】
【図１】１つの例となる実施形態による、スマートコントラクトを格納するためのデータ構造の図式的な表示を例示する。
【図２】１つの例となる実施形態による、トランザクションイベントエントリのデータ構造の図式的な表示を例示する。
【図３】１つの例となる実施形態による、電子的に定義された契約条項を格納するための一次ブロックチェーンと、電子的に定義されたトランザクションイベントエントリを格納するための二次ブロックチェーンとの概略図を例示する。
【図４】１つの例となる実施形態による、電子的に格納されたトランザクションイベントエントリから導出されたトランザクションの様々な状態及びステータスの視覚表現を例示する。
【図５】１つの例となる実施形態による、満足度値の第１のバイナリハッシュツリー及び対応する実行値の第２のバイナリハッシュツリーの視覚表現を例示する。
【図６】１つの例となる実施形態による、契約条項の複数の満足度値に対応する拡張バイナリハッシュツリーの視覚表現の視覚表現を例示する。
【図７】１つの例示的な実施形態による、スマートコントラクトの実行を検証するための方法の動作ステップのフローチャートを例示する。
【図８】１つの例となる実施形態による、コンピュータ実装の実行検証システムの動作モジュールの概略図を例示する。
【図９】１つの例となる実施形態による、自然言語を使用して構築及び表現することもできる、機械で実証可能なスマートコントラクトを構築するために使用される契約条項スニペットの視覚表現を例示する。
【図１０Ａ】契約条項スニペット及び改訂（amendment）の複合層の視覚表現と、この複合層を「フラット化」することから生成されたスマートコントラクトの提示とを例示する。
【図１０Ｂ】層状に配列され、ブロックに格納されたテキストオーバーレイの例の視覚表現を例示する。
【図１０Ｃ】条項の修正又は条項の追加によって改訂が行われたときのスマートコントラクトの進行の視覚表現を例示する。
【図１１Ａ】１つの例となる実施形態による、ブロックのチェーン内に格納されたコントラクトスニペット（contract snippet）の視覚表現を例示する。
【図１１Ｂ】１つの例となる実施形態による、他の既に格納されたスニペットを参照するスニペットの視覚表現を例示する。
【図１２Ａ】例となる実施形態による、アイデンティティ検証を有するブロックチェーンの当事者初期化ブロック及びトランザクションブロックの視覚表現を例示する。
【図１２Ｂ】例となる実施形態による、ブロックチェーンの当事者初期化ブロック、認証更新ブロック、及び後続トランザクションブロックの視覚表現を例示する。
【図１３】例となる実施形態による、マルチシグネチャアプリケーションを実装するブロックチェーンのブロックの視覚表現を例示する。
【発明を実施するための形態】
【００１３】
説明を簡単かつ明瞭にするために、図に示される要素は必ずしも縮尺通りに描かれていないことが認識されるであろう。例えば、要素のうちのいくつかの寸法は、明瞭性のために他の要素に対して誇張され得る。
【００１４】
説明を簡単かつ明瞭にするために、適切であると考えられる場合には、対応する又は類似の要素又はステップを示すために参照番号が複数の図の間で繰り返され得ることが認識されるであろう。加えて、本明細書で説明される例示的な実施形態の完全な理解を提供するために、多数の具体的な詳細が示される。しかしながら、当業者であれば、本明細書で説明される実施形態がこれらの具体的な詳細なしに実施され得ることを理解するであろう。他の事例では、本明細書で説明される実施形態を曖昧にしないために、周知の方法、手順、及び構成要素は詳細には説明されない。更に、この説明は、本明細書で説明される実施形態の範囲を何らかの方法で限定するものではなく、本明細書で説明される様々な実施形態の実装形態を単に説明しているものと考えられるべきである。
【００１５】
本明細書における「スマートコントラクト」は、コンピュータ実装のブロックチェーンの一次ブロックに格納されるスマートコントラクト条項（smart contract clause）のセットを指す。
【００１６】
本明細書におけるスマートコントラクトの「契約条項」は、実行義務を定義する電子的に格納されたコード化されたルールを指す。スマートコントラクトの契約条項の履行は、契約条項によって定義された１つ又は複数の満足度値が、格納されたトランザクションイベントエントリから導出されたトランザクションの実行値に存在することを決定することによって、コンピュータシステム内で自動的に実証され得る。
【００１７】
本明細書における「トランザクションイベントエントリ」は、当事者が実行するアクションのような、発生した現実のイベントに関する情報を格納するデータエントリを指す。トランザクションイベントエントリは、イベントの電子的に定義されたプロパティ及び／又は情報変数とその変数の値のような、１つ又は複数の電子的に定義されたイベントコンポーネントを格納し得る。
【００１８】
本明細書における「トランザクション」は、１つ又は複数のトランザクションイベントエントリからの１つ又は複数のイベントコンポーネントから導出又は決定される情報を指す。より詳細には、１つ又は複数の実行値が、１つ又は複数のイベントコンポーネントから決定又は導出され得、各トランザクションは実行値のサブセットから構成される。
【００１９】
ここで図１を参照すると、１つの例となる実施形態による、スマートコントラクト１を格納するためのデータ構造の図式的な表示が例示されている。スマートコントラクト１は、１つ又は複数のコントラクトインスタンス（contract instance）として電子的に格納される。各コントラクトインスタンスは、少なくとも１つの電子的に定義された契約条項を含む。各契約条項は、少なくとも１つの電子的に定義された満足度値によって更に定義される。各満足度値は、現実のイベントを追跡する格納されたトランザクションイベントエントリから決定することができる可能な実行値で表すことができる値に対応する。所与の契約条項の所与の満足度値に等しい、トランザクションイベントエントリから決定される実行値の存在は、その満足度値に対応する契約条項の部分の履行を示す。すなわち、契約条項の満足度値は、契約条項が履行されていると見なすためのターゲット値を定義する。
【００２０】
満足度値は、可能な実行値で表すことができる条件の存在を定義することができる。そのようなケースでは、満足度値は単に、存在しなければならない条件を定義し、条件が真であれば満足度値が満たされる。
【００２１】
満足度値は、変数と、その変数のターゲット値とを定義することができる。実行値が所与の変数を有し、かつ、その変数がターゲット値を有する場合、満足度値が満たされる。変数は、特定のタイプと変数値とを有する電子情報の一部分であり得る。代替的に、変数は電子文書のタイプであり得、その値は電子文書内で示される電子情報である。例えば、変数は、以下のいずれか１つであり得る：
・  数値（実数、整数、浮動小数点など）
・  日付／時刻
・  文字列
・  合計金額
・  視聴覚デジタルファイル（例：デジタル画像、オーディオファイル又はビデオ）
・  デジタル文書
・  デジタル暗号署名
・  ウェブアドレス（ＩＰアドレス、ＵＲＬなど）
・  コンピュータプログラム
・  プログラムスクリプト
・  データブロック
・  デジタルに検証され得る任意の他のタイプのコンピュータデータ
・  人間のユーザによって検証され、人間のデジタル署名を使用して確認され得る任意の他のタイプのコンピュータデータ。
【００２２】
図１に例示される例では、スマートコントラクト１の第１のインスタンス２４ａは、２つの電子的に定義された契約条項８ａ及び８ｂのセットを有する。第１の条項８ａ（「条項１」）は、２つの満足度値１２ａ及び１２ｂを定義する。第１の満足度値１２ａは条件タイプであり、満足度値は単に、第１の条項８ａが実行されたと見なされるために、トランザクションイベントエントリから導出される実行値に存在すべきターゲット条件を定義する。第２の満足度値１２ｂもまた条件タイプである。第３の満足度値は変数タイプであり、このケースでは、トランザクションイベントエントリから導出される実行値において識別されるべき変数１６ａが定義され、その変数１６ａの満足度値１２ｃも定義される。
【００２３】
第２の条項８ｂ（「条項２」）は、単一の満足度値１２ｄを定義し、これは、トランザクションイベントエントリから導出される実行値において識別されるべき第２の変数１６ｂと、その変数１６ｂのターゲット値とによって更に定義される。
【００２４】
スマートコントラクト１において定義された契約条項は、時間の経過とともに（over time）改訂され得る。例えば、新たな条項の追加や既存の条項の修正という形で改訂が行われ得る。スマートコントラクトは、最初に１つ又は複数のルート契約条項のセットによって定義され、時間の経過とともにこのセットに改訂が行われ得ることが理解されるであろう。契約条項のセットに対する改訂により、スマートコントラクトは、電子的に定義された契約条項の更新されたセットを有することが更に理解されるであろう。
【００２５】
続いて図１に例示された例では、新たな条項の追加という形での第１の改訂が提供される。この改訂は、第３の変数１６ｃとその満足度値１２ｄとを有する新たな条項を定義する。この新たな条項８ｃは、例示的なスマートコントラクトの第３の条項であり、これにより、スマートコントラクトを定義する条項のセットが更新される。
【００２６】
図１の例はまた、スマートコントラクトの既存の条項の修正という形での第２の改訂を例示する。この改訂は、第１の変数１６ａの修正された満足度値１２ｃ’を定義することによって、第１の条項８ａに対する変更を定義する。これは、スマートコントラクトを形成する条項のセットに対する更なる改訂をもたらす。
【００２７】
様々な例となる実施形態に従って本明細書で説明されるスマートコントラクトは、ブロックチェーン内に格納され得る。そのような例となる実施形態によれば、スマートコントラクトを格納するブロックは、ブロックチェーンの一次ブロックに対応する。これらのブロックは、本明細書の他の箇所で説明されるように、様々な例示的な実施形態に従ってトランザクションイベントを格納するために使用される二次ブロックとは区別されるべきである。
【００２８】
例えば、ブロックチェーンの１つ又は複数の一次ブロックの初期セットがルート契約条項を格納することができる。スマートコントラクトを形成する現在の契約条項の任意のセットに対する１つ又は複数の改訂は、ブロックチェーンの前のブロックに付加された後続の一次ブロックに格納され得る。スマートコントラクトに対する各改訂は、改訂されたコントラクト全体を付加ブロック内に格納することによって格納され得る。代替的に、スマートコントラクトに対する各改訂は、付加ブロックに対する漸進的変更を格納することによって格納され得る。例えば、図１において、スマートコントラクトの第１のインスタンスを形成するルート契約条項８ａ及び８ｂは、第１の一次ブロック２４ａに格納される。第１の改訂は、新たな契約条項８ｃだけを示す第２の一次ブロック２４ｂに格納される。第２の改訂は、第１の条項８ａに対する改訂だけを示す第３の一次ブロック２４ｃに格納される。契約条項を表す電子的に格納されたデータは、当技術分野で知られている他の方法に従ってブロックチェーンの一次ブロックにわたって分散され得る。
【００２９】
一次ブロックに格納されているスマートコントラクトが完全に実行されたか（すなわち、契約条項のすべての満足度値が満たされたか）部分的に実行されたかは、一次ブロックの外部に格納された情報に基づいて決定される。従って、スマートコントラクトは、スマートコントラクトが（完全に又は部分的に）実行されたかどうかを決定するために現実世界のイベントを追跡するために生成される情報が時間の経過とともに進化し得る一方で、スマートコントラクトを定義するために一次ブロックに格納されるデータコンテンツが変わらないままであるという点で、実質的に不変であると考えられる。現実世界のイベントに関する情報が進化してもスマートコントラクトの条件は変更されないが、一次ブロックを変更するとスマートコントラクトが改訂され得ることが理解されるであろう。
【００３０】
本明細書の他の箇所で説明されるように、現実世界のイベントに関する情報を提供するデータは、トランザクションイベントエントリのセットに格納され得、これは、ブロックチェーンの二次ブロックのセットに更に格納され得る。次に図２を参照すると、トランザクションイベントエントリを格納するためのデータ構造の図式的な表示が例示されている。値の実行は、電子的に格納されたトランザクションイベントエントリから決定又は導出され得る。１つ又は複数の実行値のセットは、イベントエントリ内で追跡されるトランザクションを定義することができる。進行中のトランザクションのプロパティは、新たな現実世界のイベントが発生して、トランザクションイベントエントリ内に格納されるため、時間の経過とともに進化し得ることが認識されるであろう。トランザクションのプロパティは、トランザクションイベントによって提供される情報から決定される実行値によって定義され得る。新たな現実世界のイベントの発生は、実行値を変更し、それによって、進行中のトランザクションのパラメータを変更し得る。
【００３１】
図２に例示される例は、一連１００のトランザクションイベントエントリを例示し、これは、これらのイベントエントリが組み合わされると進化中のトランザクションを表すことができるように格納され得る。各イベントエントリは、現実世界で発生したイベントを表す。各トランザクションイベントエントリは、トランザクションイベントに関する情報を格納する１つ又は複数のイベントコンポーネントを含むことができる。
【００３２】
例えば、第１のトランザクションイベントエントリ１０４ａは、プロパティタイプの第１のイベントコンポーネント１０８ａと、プロパティタイプの第２のイベントコンポーネント１０８ｂとを含む。プロパティタイプの第１のイベントコンポーネント１０８ａ及び第２のイベントコンポーネント１０８ｂは、発生したイベントのプロパティを定義する。
【００３３】
第２の例示的なトランザクションイベントエントリ１０４ｂは、プロパティタイプの第３のイベントコンポーネント１０８ｃと、プロパティタイプの第４のイベントコンポーネント１０８ｄと、変数タイプの第５のイベントコンポーネント１０８ｅとを含む。変数タイプは、スマートコントラクト条項内で定義される変数タイプに対応することができる。変数タイプのイベントコンポーネントは、所与の変数の値１１２ａを含む。
【００３４】
第３の例示的なトランザクションイベントエントリ１０４ｃは、変数タイプの第６のイベントコンポーネント１０８ｆと、変数タイプの第７のイベントコンポーネント１０８ｇとを含む。イベントコンポーネント１０８ｆ及び１０８ｇの各々は、それぞれの値１１２ｂ及び１１２ｃを有する。
【００３５】
１つ又は複数の格納されたトランザクションイベントエントリにわたる１つ又は複数のイベントコンポーネントは、実行値を定義することができる。実行値は、一次ブロック内に格納されたスマートコントラクトにおいて定義された契約条項のうちの１つの契約条項の満足度値に一致する値を有することができる。
【００３６】
例えば、１つ又は複数のトランザクションイベントエントリにわたる１つ又は複数のプロパティは、現実世界のイベントに起因する条件の存在を示すことができ、これは実行値を与える。トランザクションイベントエントリによって示されている条件の存在、そしてそれによる実行値の存在は、契約条項が満たされるかどうかを、実行値がその条項の満足度値に一致するかどうかに基づいて決定するために使用され得る。
【００３７】
１つ又は複数のトランザクションイベントにわたる１つ又は複数のプロパティは、特定の値を有する変数を示すことができ、これもまた実行値を与える。トランザクションイベントにおいて示されている変数の値も、契約条項が満たされているかどうかを、実行値から定義された変数の値がその条項の満足度値に一致するかどうかに基づいて決定するために使用され得る。
【００３８】
実行値は、トランザクションイベントエントリのイベントコンポーネントにおいて定義された値に等しくてもよい。実行値はまた、１つ又は複数のトランザクションイベントエントリにわたって１つ又は複数のイベントコンポーネントにおいて定義された値から決定又は導出され得る。
【００３９】
本明細書の他の箇所で説明されるように、格納されたトランザクションイベントエントリは、現実世界で発生したイベントを表す情報を格納する。１つ又は複数の実行値は、トランザクションイベントエントリを格納することから追跡されるトランザクションを定義する。従って、トランザクションは、スマートコントラクトにおいて定義された１つ又は複数の契約条項に対応する１つ又は複数の実行値のサブセットであり、これにより、契約条項が満たされているかどうかを決定するために、実行値と契約条項の満足度値との比較を使用することができる。従って、トランザクションを形成するための実行値を適切に決定することは、スマートコントラクトが全体として満たされているかどうか決定するために使用され得る。
【００４０】
様々な例となる実施形態に従って本明細書で説明される電子的に格納されたトランザクションイベントエントリは、少なくとも１つのブロックチェーン内に格納され得る。各トランザクションイベントエントリは、当技術分野で知られている方法に従ってブロックチェーンの１つ又は複数のブロックに格納され得る。例えば、図２に例示されるように、各トランザクションイベントエントリがそれぞれのブロック内に格納される。
【００４１】
トランザクションイベントエントリは、スマートコントラクトを格納する一次ブロックのブロックチェーンから独立している少なくとも１つのブロックチェーン内に格納され得る。すなわち、一次ブロックから形成されるブロックチェーンは、トランザクションイベントエントリを格納する少なくとも１つの他のブロックチェーンから独立している。
【００４２】
代替的に、トランザクションイベントエントリは、一次ブロックと同じブロックチェーン内に格納され得る。このようなブロックチェーンでは、スマートコントラクトを格納するために使用されるブロックは、トランザクションイベントエントリを格納するブロックとは論理的に異なる。これにより、実行値を決定すること及びトランザクションイベントエントリを格納するブロックからトランザクションを導出することから切り離して、一次ブロックからスマートコントラクトを構築することができる。
【００４３】
ここで図３を参照すると、電子的に定義された契約条項を格納するための一次ブロックチェーンと、電子的に定義されたトランザクションイベントエントリを格納するための二次ブロックチェーンとの概略図が例示されている。第１のブロックチェーン１２０は、１つ又は複数のスマートコントラクトを格納する一次ブロックチェーンのように機能する。第２のブロックチェーンを形成することができるブロック１２４の第２のセットは、トランザクションイベントエントリを格納する。トランザクションは、ブロック１２４に格納されたエントリから決定又は導出された実行値の二次的な「意味」又はサブセットである。例示される例では、２つのトランザクション（トランザクション１及び２）が、格納されたトランザクションイベントエントリから決定される。所与のスマートコントラクトが満たされるかどうかを決定するために、これらのトランザクションの実行値は、一次ブロックチェーンの対応する満足度値と比較される。
【００４４】
１つ又は複数の更なる次数（例：三次、四次など）のデータも格納され得ることが理解されるであろう。そのような高次のデータは、特徴的なブロックを使用して、他のブロックチェーン内又は同じブロックチェーン（例：第１のブロックチェーン１２０又は第２のブロックチェーン１２４と同じブロックチェーン）内に格納され得る。例えば、二次トランザクションイベントエントリのイベントコンポーネント内に情報を直接格納するのではなく、そのような情報を高次データとして格納することができ、二次トランザクションイベントエントリのイベントコンポーネントがこの高次データにリンクすることができる。
【００４５】
ここで図４を参照すると、１つの例となる実施形態による、電子的に格納されたトランザクションイベントエントリから導出されたトランザクションの様々な状態及びステータスと、スマートコントラクトの対応する契約条項の満足度値との比較との視覚表現２００が例示されている。
【００４６】
所与の契約条項の満足度値は、この例では「期待値」として示される。例示される例では、これらは、変数「Ａ」及び「Ｂ」であり、それぞれ値「１」及び「２」を有する。これらは、ボックス２０４で図式的に表されている。すなわち、変数「Ａ」が値「１」で変数「Ｂ」が値「２」である（それによって、定義された満足度値に一致する）実行値を含むトランザクションイベントから導出されたトランザクションは、契約条項が履行されたことを示す。
【００４７】
契約条項は、所与の満足度ハッシュ値によって定義され、これは、契約条項について定義された満足度値にハッシュ関数を適用することによって生成されるハッシュ値に対応する。
【００４８】
１つの例となる実施形態によれば、満足度値は、バイナリハッシュツリー構造に格納され、満足度ハッシュ値は、契約条項に対応するバイナリハッシュツリーの所与のレベルにあるハッシュ値を表し、その所与のレベルの子であるすべての満足度値を適切にハッシュすることによって取得される。例示される例では、所与の条項の満足度ハッシュ値２０８は「ＡＡＢＢＣＣ」である。満足度値２０８は、同じ満足度値を有する実行値がトランザクションイベントエントリに存在するかのように決定されることが認識されるであろう。満足度値を格納するためのバイナリハッシュツリー構造は、ブロックチェーン内にスマートコントラクトの満足度値を格納するのに適していることが更に認識されるであろう。
【００４９】
これまでに生成されたトランザクションイベントエントリから決定された現在の実行値も例示されている。トランザクションイベントエントリから決定され、所与の契約条項の満足度値と比較されるべきトランザクションの実行値は、その契約条項の満足度値のバイナリハッシュツリーと同じ論理配列を有するように、バイナリハッシュツリー配列に配列される。従って、実行値が満足度値に一致する場合、満足度値のバイナリハッシュツリーから及び実行値のバイナリハッシュツリーから同じハッシュ値が生成される。
【００５０】
図４の例示的なトランザクションの第１の状態では、表２１６ａに示すように、トランザクションイベントエントリから導出された実行値は、ボックス２１２ａに示すように、変数「Ａ」及び変数「Ｂ」の値が欠落していることを示す。この欠落した値により、実行ハッシュ値「ＸＹＺ」が生成される（ボックス２２０ａ）。満足度ハッシュ値と実行ハッシュ値とが一致しないため、契約条項は、満たされていないと決定される。
【００５１】
欠落した値は、これらの値を有する変数を示すトランザクションイベントエントリの格納を引き起こすこととなる現実世界のイベントが発生していない状況に対応し得る。例えば、契約条項において定義された満足度値は、写真ＩＤであり、満足度値が「Ｊｏｈｎ Ｓｍｉｔｈ」である変数「Ａ」と、ピンコードであり、満足度値が「ＡＢＣ１２３」である変数「Ｂ」とから構成され得る。対応するトランザクションは、受信した写真ＩＤ及び受信したピンコードの値を示すためにトランザクションイベントエントリから決定される実行値のサブセットである。不完全な部分トランザクション状態２１６ａでは、写真ＩＤ及びピンコードが現実世界のイベント（複数を含む）において未だ提供されていないため、これらの値が欠落している。
【００５２】
同じトランザクションの第２の状態では、トランザクションの実行値は、変数「Ａ」に対して値「１」を有し、変数「Ｂ」に対して値「３」を有する。これにより、実行ハッシュ値「ＣＣＦＦＧＧ」が生成される（ボックス２１２ｂ及び２２０ｂ）。この実行ハッシュ値は満足度ハッシュ値「ＡＡＢＢＣＣ」に一致しないため、第２の状態２１６ｂのトランザクションは、所与の契約条項を履行していないと見なされる。例えば、ユーザが「Ｊｏｈｎ Ｓｍｉｔｈ」の写真ＩＤを提供したが正しいピンコードを提供しなかったという現実世界のイベントを反映するために、追加のトランザクションイベントエントリが格納される。トランザクションの現在の状態は、これらの追加のイベントエントリから決定された実行値を反映する。
【００５３】
同じトランザクションの第３の状態では、トランザクションの実行値は、変数「Ａ」に対して値「１」を有し、変数「Ｂ」に対して値「２」を有する。これにより、実行ハッシュ値「ＡＡＢＢＣＣ」が生成される（ボックス２１２ｃ及び２２０ｃ）。この実行ハッシュ値は、満足度ハッシュ値「ＡＡＢＢＣＣ」に一致するため、第３の状態２１６ｃにおけるトランザクションは、所与の契約条項を履行したと見なされる。例えば、ユーザが「Ｊｏｈｎ Ｓｍｉｔｈ」の写真ＩＤを提供し、正しいピンコードも提供したという現実世界のイベントを反映するために、追加のトランザクションイベントエントリが格納される。
【００５４】
ここで図５を参照すると、契約条項のグループ（例：条項及び様々な副条項（sub-clause））の満足度値の第１のバイナリハッシュツリー２４０と、この条項のグループが満たされるかどうかを決定するための対応する実行値の第２のバイナリハッシュツリー２４８との視覚表現が例示されている。第１のバイナリハッシュツリー２４０の右側分岐の満足度値が定義される。例えば、第１のバイナリハッシュツリー２４０の右側分岐の満足度値は、以下のように、図１の例に例示されるスマートコントラクトの部分に対応する。
【表１】
2021535668.tif 000003
【００５５】
バイナリハッシュツリーの所与のレベルにある各ノードは、そのノードの１つ下のレベルの子ノードによって生成されたハッシュ値と、そのノードの満足度値からのハッシュ値との連結である、それぞれのハッシュ値を定義することが認識されるであろう。これにより、各レベルにおいて、そのレベル及びすべての子ノードの満足度値が１つ又は複数のトランザクションの実行値に存在するかどうかを決定することができる。
【００５６】
第２のバイナリハッシュツリー２４８は、満足度値に対応し、同じバイナリハッシュツリー配列に配列された実行値を有する。例示される例では、右側分岐は、１つ又は複数のトランザクションからの実行値を有する。更に、これらの実行値は、第１のバイナリハッシュツリー２４０の右側分岐の満足度値に等しい。従って、二次バイナリハッシュツリー２４８の右側分岐の中間ノード２５２は、対応するノード２５６と同じハッシュ値「ＢＢ＋ＣＣ＋Ｈ：ＤＤ」を有する。しかしながら、二次バイナリハッシュツリー２４８の左側分岐の実行値が一次バイナリハッシュツリー２４０の左側分岐に未だ一致していないため、二次バイナリハッシュツリー２４８全体のルート実行ハッシュ値２６０は、一次バイナリハッシュツリー２４０の満足度ハッシュ値２６４に一致しない。
【００５７】
一次バイナリハッシュツリー２４０の右側分岐の満足度値を最終的に満たすトランザクションを定義する実行値を生成するトランザクションイベントエントリは、図２の例示的なトランザクションイベントエントリによって以下のように表され得る：
【表２】
2021535668.tif 000004
【表３】
2021535668.tif 000005
【表４】
2021535668.tif 000006
【表５】
2021535668.tif 000007
【表６】
2021535668.tif 000008
【表７】
2021535668.tif 000009
【００５８】
ここで図６を参照すると、１つの例となる実施形態による、契約条項の複数の満足度値に対応することができる拡張バイナリハッシュツリー２７２の視覚表現が例示されている。例えば、所与の契約条項は、最上位の満足度値のセットを有することができる。これらの最上位の満足度値は、最上位ツリー２７６内に表される。所与の契約条項はまた、その契約条項の副条項に対応する下位レベルの満足度値を有することができる。例示される例では、各副条項は、マイルストーン又は部分トランザクションを表す。第１の副条項は第１の下位ツリー２８０によって表され、第２の副条項は第２の下位ツリー２８４によって表される。各下位ツリーは、それぞれの満足度ハッシュ値（第１のツリー２８０については「ＤＥＦ」、第２のツリー２８４については「ＸＹＺ」）を有する。格納されたトランザクションイベントエントリからの１つ又は複数のトランザクションの実行ハッシュ値が第１の下位ツリー２８０の第１の満足度ハッシュ値に一致することは、第１の副条項が満たされている（第１のマイルストーンが完了している）ことを示す。同様に、格納されたトランザクションイベントエントリからの１つ又は複数のトランザクションの実行ハッシュ値が、第２の下位ツリー２８４の第２の満足度ハッシュ値に一致することは、第２の副条項が満たされている（第２のマイルストーンが完了している）ことを示す。条項全体が履行されたと決定しなくても副条項のうちのいずれか１つの完了が決定され得ることが認識されるであろう。更に、両方の下位ツリーの実行ハッシュ値を最上位ツリーの実行ハッシュ値と組み合わせることによって、条項全体が実行されたと決定され得る。
【００５９】
次に図７を参照すると、１つの例示的な実施形態による、スマートコントラクトの実行を検証するための方法３００の動作ステップのフローチャートが例示されている。
【００６０】
ステップ３０４において、スマートコントラクトが生成される。スマートコントラクトを生成するための様々な例示的な方法は、本明細書の他の箇所で説明される。スマートコントラクトを生成することは、本明細書の他の箇所で説明されるように、スマートコントラクトを反復的に改訂すること（修正すること又は新たな契約条項を追加すること）を含むことができる。スマートコントラクトは、スマートコントラクトの実行を検証するための方法を実行するシステムとは別個のシステム上で生成され得、スマートコントラクトを生成するステップは、スマートコントラクトの実行を検証するための方法の一部ではないと見なされ得ることが理解されるであろう。
【００６１】
ステップ３０８において、その実行を決定するために分析されるスマートコントラクトが受信される。受信されたスマートコントラクトは、スマートコントラクトの現在のバージョンに対応し、これは、スマートコントラクトの初期バージョン又は現在改訂されたバージョンであり得る
ステップ３１２において、スマートコントラクトの満足度ハッシュ値が決定される。これは、スマートコントラクトのすべての条項（及びすべての満足度値）のグローバル満足度ハッシュ値を決定することを含み得る。これはまた、スマートコントラクト内の個々の条項又は副条項の中間満足度ハッシュ値を決定することを含み得る。
【００６２】
ステップ３１６において、所与のスマートコントラクトの満足度値に対応するトランザクションを形成する実行値が、トランザクションイベントエントリから決定又は導出される。本明細書の他の箇所で説明されるように、トランザクションイベントエントリは、ブロックチェーンの二次ブロック内に格納され得る。
【００６３】
ステップ３２０において、満足度値に対応するトランザクションの実行ハッシュ値が決定される。本明細書の他の箇所で説明されるように、実行値は、満足度値のバイナリハッシュツリーに対応する方法で、バイナリハッシュツリー配列で配列され得る。グローバル実行ハッシュ値が決定され得る。個々の条項又は副条項に対応する中間実行ハッシュ値も決定され得る。
【００６４】
ステップ３２４において、ステップ３１６からの満足度ハッシュ値（複数を含む）が、ステップ３２０からの実行ハッシュ値（複数を含む）と比較される。これにより、スマートコントラクトが全体として実行されたかどうかを決定することができる。決定することはまた、スマートコントラクトが部分的に実行されていることを示すことができ、実行されたそれらの条項と、実行されなかった他の条項とを識別することもできる。スマートコントラクトが完全に実行された場合、方法はステップ３２８に進み、スマートコントラクトが実行されたことを示す。
【００６５】
スマートコントラクトが実行されていない（又は部分的にのみ実行された）場合、方法はステップ３１６に戻り、新たに格納されたトランザクションイベントエントリに基づいてトランザクションの実行値を更新する。代替的に、いくつかの例示的な実施形態によれば、方法は、ステップ３０８に戻り、スマートコントラクトの更新されたバージョンを受信し得る。
【００６６】
ブロックチェーンは、本質的に、暗号学的ハッシュのチェーンによってリンクされ、保護されている一連の不変のブロックである。本明細書で説明される様々な例示的な実施形態は、不変のコンピュータ実装可能なスマートコントラクトを定義するための機構を提供する。更に、スマートコントラクトの実行ステータスは、トランザクションイベントエントリ内の現実世界のイベントを追跡し、スマートコントラクトに対応するトランザクションの実行値を導出することによって、時間の経過とともに進化することができる。すなわち、トランザクションの実行値は、時間の経過とともに変化し得る。従って、トランザクションは、不変のスマートコントラクトとは別個の二次的な意味を持つ。
【００６７】
このアプローチでは、条件及び変数が、部分トランザクションに対する遡及的な修正を伴うイベントによって、時間の経過とともに修正され、それによってコントラクトの実行を漸進的に確認することを可能にしつつ、構造的に不変で暗号的に履行されるコントラクトを構築することができる。これにより、完全に不変的な方法でマイルストーンの複数のセットを有する複雑なスマートコントラクトの作成が可能になる。このアプローチにより更に、不変のスマートコントラクトを格納する一次ブロックチェーンの構造的及び暗号的な完全性を壊すことなく、二次的な意味として、時間の経過に伴うトランザクションのステータス（例：トランザクションは不完全であるか、部分的に完了しているか、又は完全に実行され得る）を追跡する能力が可能になる。
【００６８】
本明細書で説明される様々な例となる実施形態によれば、一次スマートコントラクト及び二次トランザクションの概念が導入される。スマートコントラクト及びトランザクションの両方がブロックチェーン（複数を含む）内で表され得る。一次契約条項は、ブロックチェーンにおいて完全に不変であるように格納され、永続的な暗号学的ハッシュを通して互いにリンクされる。二次トランザクション（部分トランザクション）は、一次契約条項から独立している可変の第２のレベルの解釈である。例えば、現実世界のイベントを表すトランザクションイベントエントリは、ブロックチェーンに不変的な方法で格納され得るが、（二次的な意味を持つ）トランザクションを定義する実行値は、イベントエントリから導出される。そのため、トランザクションの実行値及びステータスは可変である。スマートコントラクトの実行を示すのに必要なスマートコントラクトのターゲット満足度値は、この満足度値に一致する実行値を有する確認された二次トランザクションを通して、時間の経過とともに提供され得る。次いで、完了したトランザクションは、ブロック間のハッシュ関係及びスマートコントラクトを格納する一次ブロックチェーンの暗号的な完全性を壊すことなく、一次ブロックチェーンに遡及的に書き込まれ得る。
【００６９】
本明細書の他の箇所で説明されるように、現実世界のイベントは、トランザクションイベントエントリの形態でブロックのチェーン内に不変的な方法で格納され得る。本明細書の他の箇所、例えば図４の例の中、でも説明されるように、トランザクションイベントエントリは、トランザクションの状態を更に定義する実行値を導出又は決定することを可能にする。新たなイベントエントリが付加されると、トランザクションの状態も更新される。そのような可変のトランザクションは、本明細書では部分トランザクションとも呼ばれ、トランザクションエントリとして格納され得る。そのようなエントリは、トランザクションイベントエントリから導出又は決定された特定の実行値を格納するためのメモリスロットを含むことができる。代替的に、メモリスロットは、実行値から生成された特定のハッシュ値を格納することができる。メモリスロットに格納された実行値（又は実行ハッシュ値）は更に、実行検証システム内に一時的に格納され得る。代替的に、これらの値は、新たなイベントが発生するにつれて、時間の経過に伴う部分トランザクションの状態を追跡するために、ブロックチェーン内に格納されることができる。任意の所与の時間にメモリスロットに格納される実行値（又は実行ハッシュ値）の各セットは、部分トランザクションの状態を定義する。
【００７０】
従って、電子的に格納されたスマートコントラクトは、より下位の「Ｎ」次トランザクションであると考えられ得る（例：一次について本明細書で説明される例ではＮ＝１である）。スマートコントラクトの契約条項は、決定又は導出される必要がある（満足度値の形の）実行値を定義し、部分トランザクションを格納するためにトランザクションエントリにおいて割り当てられるメモリスロットを更に示す。イベントエントリから決定又は導出され、トランザクションエントリのメモリスロット内で追跡される実行値によって定義される部分トランザクションは、「Ｎ＋１」次トランザクションであると考えられ得る（例：二次について本明細書で説明される例ではＮ＋１＝２である）。新たなイベントが発生し、実行値が変わると、部分トランザクションの状態も変化する。ブロックチェーンの暗号化された保証によって提供される付加のみの不変の性質は、契約関係を定義するのに適していることが観察された。しかしながら、コントラクトの実行状態は変化するため、すなわち時間における実行状態は可変であるため、コントラクトの実行を決定する際には可変性が望まれ得る。１つの解決策は、（例：現実世界のイベントの結果として）トランザクションのステータスが変更されるたびにブロックチェーン内にエントリを作成することである。これは不変性を提供するが、この解決策は、ブロックチェーン上でのトランザクションデータの余分な反復を引き起こし、より多くのディスクスペース及び帯域幅を使用する。本明細書で説明される様々な例示的な実施形態は、ブロックチェーンの不変性を維持し、かつ、追跡されるトランザクションの実行値の可変性を可能にしつつ、この欠点を克服する。
【００７１】
本明細書で説明される様々な例示的な実施形態は、ハッシュ値を利用する。満足度ハッシュ値は、一次スマートコントラクトから生成され、スマートコントラクトが履行されたと見なされるときに存在するハッシュ値を表す。実行ハッシュ値は、二次トランザクションイベントエントリから導出されたトランザクションの実行値に対して生成される。不完全な、不正確な、又は無効な実行値は、満足度ハッシュ値に一致しない実行ハッシュ値を作り出し、それによってコントラクトが実行されていないことを示す。本明細書の他の箇所で述べたように、トランザクションのステータスは、時間の経過とともに修正され得る。新たな現実世界のイベントが発生すると、トランザクションの実行値は、実行ハッシュ値が満足度ハッシュ値に一致するまで進化する。この時点で、スマートコントラクト（コントラクトの条項又は副条項）が実行されたと見なされる。そうではなく、ハッシュ値が異なる場合、コントラクトは完全には実行されていないと見なされる。
【００７２】
セキュリティに関して、様々な例示的な実施形態に従って二次ブロックチェーン内にトランザクションイベントエントリを格納することによって、コントラクトが実行されたと決定することを可能にする二次トランザクションの実行値を改ざんすることは非常に困難になる。イベントエントリから導出される実行値は時間的に可変であるが、これらの進化する値は、不変である格納されたトランザクションイベントエントリの暗号的な有効性によってサポートされている。トランザクションの実行値が時間的に可変であるように見えるのは、トランザクションイベントエントリをリプレイすることによるものである。従って、トランザクションイベントエントリは、トランザクションの実行値の進化を検証する。
【００７３】
コントラクトに関しており、それを解釈するために必要とされるすべての情報を含む中間の圧縮されたバイナリフォーマットにコントラクトをコンパイルした後、スマートコントラクトの契約条項は、一次ブロックチェーンに挿入されるターゲット部分トランザクションであると理解され得る。従って、スマートコントラクトは、コントラクトの完了に必要とされるすべての一次ターゲットトランザクションの完全な構造を表す。実行値がターゲットトランザクションに一致する現実世界のトランザクションを定義すると完了が発生する。格納されたターゲットトランザクションは、マイルストーンの複数のチェーンを含むことができ、各々が、先行するものの成功に依存して範囲に入る。コントラクトが永続的である場合、後のマイルストーンは、前のマイルストーンが成功裏に完了した後に動的に追加され得る。
【００７４】
これらの一次ターゲットトランザクション（すなわち、契約条項）は、理想的なハッシュを使用して互いにリンクして、ブロックチェーンに追加され、一次は不変のままである。これらのターゲットトランザクションはすべて、部分トランザクションであり、従って、二次的な意味を提供する。
【００７５】
スマートコントラクトを定義し、トランザクションの実行値を決定又は導出するための本明細書で説明される様々な例示的な実施形態は、スマートコントラクトの実行のコンピュータ実装の解釈及び検証を可能にする。
【００７６】
スマートコントラクト及び契約条項を定義及び検証するための本明細書で説明される例は、当事者間で実行義務の満足度を決定するために容易に適用可能であるが、本明細書で説明するシステム及び方法は、１つ又は複数の条件及び／又は１つ又は複数の変数値のセットの存在の追跡を伴う任意の使用事例で適用可能であり得ることが理解されるであろう。条件（複数を含む）又は変数値（複数を含む）が一次トランザクションにおいて定義されるのと同時に、二次トランザクションの構築を可能にするためにイベントが追跡され、ここにおいて、一次条項及び二次部分トランザクションは、１つ又は複数のブロックチェーンに格納され得る。例えば、それは、レビュー及び解説システム内、例えば電子商取引プラットフォーム内のステータス及び結果を追跡するために使用され得る。ここで図８を参照すると、スマートコントラクトの実行を検証するためのコンピュータ実装の実行検証システム４００の動作モジュールの概略図が示されている。本明細書で説明されるシステム４００は、一連のコンピュータ実装モジュールとして提示される。
【００７７】
本明細書で説明されるシステムは、本明細書では、プログラマブルコンピュータ上で実行されるコンピュータプログラムに実装され得るモジュールとして説明され、各々が、少なくとも１つのプロセッサと、データ格納システム（揮発性及び不揮発性メモリ及び／又は格納要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを備える。例えば、限定するものではないが、プログラマブルコンピュータは、プログラマブル論理ユニット、メインフレームコンピュータ、サーバ、パーソナルコンピュータ、相互接続されたコンピュータのネットワーク、クラウドベースのプログラム又はシステム、ラップトップ、パーソナルデータアシスタンス、携帯電話、スマートフォン、又はタブレットデバイスであり得る。
【００７８】
各プログラムは、好ましくは、コンピュータシステムと通信するために、高水準の手続き型の又はオブジェクト指向プログラミング及び／又はスクリプト言語で実装される。しかしながら、望まれる場合は、プログラムは、アセンブリ言語又は機械語で実装され得る。いずれの場合も、言語は、コンパイラ型言語又インタープリタ型言語であり得る。
【００７９】
本明細書の他の箇所で説明されるように、コンピュータ実装の一次ブロックチェーン１２０は、一次ブロック内に１つ又は複数のスマートコントラクトの契約条項を格納する。本明細書の他の箇所でも説明されるように、コンピュータ実装の二次ブロックチェーン１２４は、二次ブロック内にトランザクションイベントエントリを格納するために提供され得る。
【００８０】
システム４００は、第１のブロックチェーン１２０に格納された電子データを取り出して解釈するように構成された第１のブロックチェーンエンジン４０４を含む。取り出されたデータは、１つ又は複数のスマートコントラクトの格納された契約条項に関するデータを含むことができる。第１のブロックチェーンエンジン４０４はまた、データブロックを第１のブロックチェーン１２０に書き込むように構成され得る。書き込まれたデータは、１つ又は複数のスマートコントラクトの契約条項に対する改訂に関するデータを含むことができる。
【００８１】
システム４００は、第２のブロックチェーン１２４に格納された電子データを取り出して解釈するように構成された第２のブロックチェーンエンジン４０８を含む。取り出されたデータは、格納されたトランザクションイベントエントリに関するデータを含むことができる。第２のブロックチェーンエンジン４０８はまた、データブロックを第２のブロックチェーン１２４に書き込むように構成され得る。書き込まれたデータは、現実世界のイベントを追跡する新たなトランザクションイベントエントリに関するデータを含むことができる。様々な例示的な実施形態によれば、互いに取引を行う様々な第三者が、トランザクションイベントエントリを二次ブロックチェーンに書き込むことができる。
【００８２】
システム４００は、第１のブロックチェーンエンジン４０４によって一次ブロックチェーン１２０から取り出されたデータから関連スマートコントラクトを抽出するように構成された第１のコントラクトアセンブラモジュール４１２を含む。第１のコントラクトアセンブラモジュール４１２は、所与のスマートコントラクトに関するデータを格納するそれらの特定のブロックを、取り出されたブロックから識別することができる。例えば、時間の経過とともに行われる改訂（条項の修正又は条項の新たな追加）により、スマートコントラクトが複数のブロックにわたって格納される場合、第１のコントラクトアセンブラモジュール４１２は、スマートコントラクトの一部をアセンブルして、検証のための完全なスマートコントラクトを生成するように動作可能である。
【００８３】
システム４００は、第１のコントラクトアセンブラモジュール４１２によって抽出された関連スマートコントラクトに対応する関連トランザクションイベントエントリを抽出するように構成された第２のコントラクトアセンブラモジュール４１６を含む。第２のコントラクトアセンブラモジュール４１６は、第１のコントラクトアセンブラモジュール４１２によってアセンブルされたスマートコントラクトを受信し、そのスマートコントラクトに関するトランザクションイベントエントリを格納するそれらの特定のブロックを、二次ブロックチェーン１２４から取り出されたデータから識別する。適切なトランザクションイベントエントリは、スマートコントラクトの契約条項に対応するトランザクションの実行値を決定又は導出することを可能にする現実世界のイベントに関する情報を格納するものであり得る。本明細書の他の箇所で説明されるように、実行値により、スマートコントラクトが満たされているたかどうかを決定することが可能になる。
【００８４】
システム４００は、スマートコントラクトが実行されたかどうかをトランザクションイベントエントリに格納された情報に基づいて自動的に決定するように構成されたインタプリタモジュール４２０を含む。インタプリタモジュール４２０は、第２のコントラクトアセンブラモジュール４１６によってアセンブルされたスマートコントラクトの満足度値を抽出することができる。満足度値が１つ又は複数のバイナリツリーで配列される場合、インタプリタモジュール４２０は、満足度値から１つ又は複数の満足度ハッシュ値（例：コントラクト全体のグローバル満足度ハッシュ値及び／又は契約条項又は副条項の部分ハッシュ値）を生成することができる。
【００８５】
インタプリタモジュール４２０はまた、第２のコントラクトアセンブラモジュール４１６によって抽出されたトランザクションイベントエントリから実行値を決定又は導出することができる。本明細書の他の箇所で説明されるように、実行値は、１つ又は複数のイベントコンポーネントから決定又は導出され得る。実行値のサブセットは、スマートコントラクトの契約条項に対応する。
【００８６】
１つの例となる実施形態によれば、図８に例示されるように、実行値の決定又は導出は、トランザクションイベントエントリのイベントコンポーネントから実行値を決定又は導出するためのコンテキストを提供するように構成されたコンテキスト提供モジュール４２４からの入力に基づくことができる。コンテキストは、法的な制定法及び／又は判例法に基づいてイベントコンポーネントがどのように解釈されるべきかを更に定義する電子的に定義されたルールを格納するルールライブラリ４２８に基づき得る。ルールライブラリ４２８は、法律の改正に基づいて時間の経過とともに更新され得る。解釈ルールの例は、週末又は休日に当たる締め切りをどのように扱うかであり得る（例：締め切りは、前に平日であるか、又は次の平日に延期される）。別の例は、建物が建築基準法を満たすかどうかを決定するために使用される建築基準法のセットであり得る。
【００８７】
インタプリタモジュール４２０は、アセンブルされたスマートコントラクトの満足度値を、トランザクションイベントエントリから決定又は導出された実行値と比較し、この比較から、スマートコントラクトが実行されたかどうか（又はスマートコントラクトの少なくとも一部が実行されたかどうか）を決定するように更に構成される。本明細書の他の箇所で説明されるように、実行値は、対応する満足度値と比較され、両方の値のセットが一致する場合、スマートコントラクトは実行されたと見なされる（又はその満足度値のセットに対する条項が実行されたと見なされる）。
【００８８】
様々な例となる実施形態によれば、インタプリタモジュール４２０は、スマートコントラクトの対応する満足度値の１つ又は複数のバイナリツリーと同じ配列で１つ又は複数のバイナリツリーに実行値を配列するように構成される。インタプリタモジュール４２０は更に、実行値から１つ又は複数の実行ハッシュ値（例：すべてのトランザクションの実行値のためのグローバル実行ハッシュ値及び／又はトランザクションもしくはサブトランザクションの実行値のセットのための部分実行ハッシュ値）を生成することができる。
【００８９】
スマートコントラクトの満足度値（満足度ハッシュ値）と、トランザクションイベントエントリから決定又は導出された実行値（実行ハッシュ値）との比較に基づいて、インタプリタモジュール４２０は、スマートコントラクトが完全に実行されたか部分的に実行されたかを示すスマートコントラクトのステータスを出力するように構成される。出力はまた、スマートコントラクトの契約条項又は副条項のステータスを示すことができる（例：特定の条項は完全に実行されたが、コントラクトが全体としては実行されていないかどうか）。
【００９０】
いくつかの例となる実施形態では、インタプリタモジュール４２０は更に、コントラクトのステータスを未解決であると示すことができる。いくつかの状況では、インタプリタモジュール４２０は、コントラクトを解決するために必要なスマートコントラクトの関連条項及び関連トランザクションイベントエントリのような関連情報を論争解決モジュール４３２に出力することができる。論争解決モジュール４３２は更に、実行検証システム４００の外部でコントラクトを解決することができるように、この情報をスマートコントラクトの当事者に提供することができる。
【００９１】
ここで図９を参照すると、自然言語を使用して構築及び表現することもできる、機械で実証可能なスマートコントラクトを構築するために使用される契約条項スニペットの視覚表現５００が例示されている。契約条項スニペットを使用することにより、ユーザは、自然言語を使用しても表現可能であると同時に、本明細書で説明される様々な方法及びシステムに従って検証され得る電子的に格納されたスマートコントラクトを構築することができる。
【００９２】
コントラクトスニペットライブラリ５０４は、複数の事前定義された契約条項テンプレート（以下では「コントラクトスニペット」とも呼ばれる）を格納する。ユーザは、事前定義された契約条項テンプレートのセットを選択することによってコントラクトを構築することができる。事前定義された契約条項テンプレートは、以下のうちの１つ又は複数を定義することができる：
・  自然言語で契約条項を表現するための自然言語フレーズ；
・  変数タイプ及び変数値を各々有する満足度値を定義するための１つ又は複数の変数フィールドと及び対応する値フィールド；
・  条件を有する１つ又は複数の満足度値を定義するための１つ又は複数の条件フィールド。
【００９３】
コントラクトスニペットは、スニペットから作成された契約条項のコンピュータ実装検証のためにスニペットの論理的意味を示す様々な情報を含むことができる。スニペットから作成された条項の解釈は、基本的にマシンスクリプトの形で挙動を説明するカスタムプログラマチックマークアップ言語の助けを借りて実行され得る。これらのスクリプトはまた、コントラクトの当事者、期待される時間フレーム、及びユーザによって追加されるか又はコントラクトによって必要とされる任意の他の関連変数のような、格納されたイベントエントリ内のイベントコンポーネントにどのようにアクセスするかを定義する。スクリプトはまた、トランザクションイベントエントリに格納されたデータから実行値又は実行ハッシュ値をどのように導出又は決定するかを定義することができる。例えば、スクリプトは、実行値を決定するためにトランザクションイベントエントリのイベントコンポーネント内のデータに適用される関数又はアルゴリズムを定義することができる。スクリプトはまた、スマートコントラクトの契約条項の実行を決定するための満足度ハッシュ値と比較可能な実行ハッシュ値を生成するための実行値の構造を定義することができる。例えば、スクリプトを含むスニペットは、それ自体がバイナリツリーに編成され得、トランザクションイベントエントリ内のデータに適用される各スクリプトの出力は、スニペットのそのツリーの実行ハッシュ値を生成するために使用され得る。
【００９４】
ブロックチェーンの継承システム及びリンクされた性質を利用するように構築されているため、カスタムマークアップ言語は、前に構築された要素のスニペットから、人間が読めるステートメントを構築することができるように設計される。各ステートメントは、人間が読めるテキストの生成をどのように確立するかを定義するテキスト生成マークアップ要素と、機械のための手続き的意味をテキストに持たせるサポートプログラムスクリプトという２つの主要部分から構築される。テキストマークアップ言語により、テキストのセクションに異なる識別子及び変数をタグ付けすることができ、次いで、これらが、サポートプログラムスクリプトにリンクされ得る。
【００９５】
これらのコードスニペットの重要な特徴は、それらが完全にオーバーライド可能である点であり、スニペットの任意の部分を別の部分でオーバーレイして、元の意味を変え、両方を新しいものへとマージすることができる。システム４００は、オーバーライドが結合した後に、結果として得られる意味が依然として有効であることを検証することができるだけでなく、健全性を確保するためにそれを文書上の他のものと関連させることができる。
【００９６】
スニペットはまた、システムがテキスト構造の法的意図を解釈するのを助けるプログラムコードキューに加え、他のスニペットの入力及び出力に対するその挙動を含むことができる。このコンピューティングヒント言語は、ステートメントの任意の部分が新たな層でオーバーライドされることを確実にするため、意図された挙動が依然として法的に期待されるものに一致することをシステムが確認するのを依然として助けつつ、新たな意味を与えることができる。このステートメントスタックは、スマートコントラクトのマージされた条項を決定するために、システムによってフラット化され、コンパイルされ、利用され得る。
【００９７】
各スニペットは、コンパイルされ、英語、フランス語、スペイン語、中国語、又は任意の他の適切な言語のような自然言語で表されるように設計される。
【００９８】
言語は、フレーズの任意の部分をコードのスニペットによって構成することができるようにフォーマットされる。例えば、疑似コードでは、スニペットが単語[define:snippet1- “let there be”]及び別の単語[define:snippet2- “light”]を作り出すと決定されると、スニペット[define:snippet3--[snippet1] [snippet2]]は、フレーズ「Let there be light」を作り出すこととなる。
【００９９】
ブロックのコンテンツが、例えば[define:snippet4--[snippet3], [replace:snippet2- “peace on earth”]]でオーバーライドされると、このオーバーレイの結果は、「Let there be peace on earth」となる。スニペット３を参照する任意の他のブロックは、依然として、同じフレーズ「let there be light」を作り出す。そのため、スニペット４は、それが継承した前のブロックの前のスニペットの意味及びコンテンツに依存して、オーバーレイになる。プログラミングコードが独自の実行可能な挙動を提供する一般関数を含むことができるのと同様に、これらのスニペットも他のスニペットを組み込むことができる。従って、スニペットは、単純なフレーズから始まって最終的には複雑なパラグラフ及び文書を形成するスニペットの階層に構築され得る。
【０１００】
スクリプト言語はまた、契約書（contractual statement）の解釈及びフローによりよく適合し得るマシンのための高次の動作、ステートメント、及び意味の作成を可能にする。より高水準の法的言語構造及び解釈で動作するために特別な命令が作成され得る。条件、ループ、関数などの通常のプログラムステートメントもまた、意味を補うために使用され、このカスタムプログラムスクリプト言語に埋め込まれ得る。これらの特別な動作は、理解され、カスタムビルドの仮想マシンエンジン内で実行することができる。
【０１０１】
コントラクトスニペットはまた、スニペットから作成された契約条項の自然言語テキスト構造を示すことができる。これらのスニペットは、スクリプト言語を理解するシステム（例：コントラクトアセンブラモジュール４１２）がコントラクトスニペット内で定義されたステートメントの人間が読めるバージョンを生成することを可能にする言語翻訳命令も含む。
【０１０２】
コントラクトスニペットは、スマートコントラクト内で層状にされ得る。例えば、コントラクトスニペットの自然言語表現の場合、すべての内側スニペットは、独自の言語を生成し、それは、完全な言語パラグラフが形成されるまで親に注入される。この言語生成層は、基礎となるスクリプトのプログラム上の意味と翻訳命令とに基づいて、世界中のあらゆる言語でテキストを生成することができる。ユーザがユーザインターフェース上でコントラクトを作るとき、ユーザは、（そうするようにも構成されていない限り）プログラムステートメントではなく、スニペットの人間が読める結果言語をユーザの好ましい通信言語で見ることとなる。
【０１０３】
コントラクトワークベンチ５０８は、ユーザが事前定義された契約条項テンプレートを選択し、テンプレートのフィールドに所望の満足度値を入力してスマートコントラクトをポピュレートすることができるユーザインターフェースである。従って、ユーザインターフェースは、ユーザが、契約条項のセットを選択し、満足度値を定義することによってスマートコントラクトを構築することを可能にする。コントラクトワークベンチ５０８は、ユーザがカスタムコントラクトスニペットを作成することを可能にすることもできる。
【０１０４】
そのため、システムは、コントラクトをプログラム形式で解釈し、コントラクトをテキスト形式で生成することができるようになり、その結果、人間のユーザは、背後にある言語を実証するプログラミングを見なくても、言語を読んでその意味を理解することができる。スニペットの階層のプログラム上の意味を解釈することによって、システムは、コントラクト構造及び時間の経過、条件の分岐のようなユーザに対する様々な視覚的補助の生成、論理的な誤りの検出、矛盾するステートメントの検出、及びコードから推論することができる任意の他の動作を行うことができるようになる。
【０１０５】
例示される例では、ユーザが見る情報に対応するコントラクトワークベンチ５０８は、ユーザが変数「当事者」及び「完了日」を定義したことを示す。ユーザはまた、スニペット「契約（Agreement）」、「補償」、及び「ウィットネス」を選択しており、「契約」スニペット内の「文書」フィールドの値と、「補償」スニペットの競合条件とを定義している。
【０１０６】
スクリプト化コントラクト表現５１２は、コントラクトワークベンチ５０８を介してユーザによって選択されたスニペット及び定義された値から構築されたスマートコントラクトについての電子的に定義された契約条項と関連満足度値とを例示する。例えば、変数タイプであり、値「文書Ｘ２」を有する文書を必要とする満足度値が条項のうちの１つに定義されている。作業コストがコスト案の値よりも低いという条件が、契約条項「補償」の満足度値として定義されている
自然言語表現５１６は、同じスマートコントラクトの自然言語表現を示す。
【０１０７】
ユーザがスマートコントラクトの構築を完了すると、スマートコントラクトは、ブロックチェーンの一次ブロック内への格納のためにコンパイルされ得る。スマートコントラクトは、バイナリ形式５２０でコンパイルされ得る。コントラクトの満足度値は、契約条項の各々がそれぞれの満足度ハッシュ値を有し、スマートコントラクト全体のルートハッシュ値も生成されるように、ハッシュツリー５２４に配列され得、
１つの例示的な実施形態によれば、ブロックチェーンの一次ブロックは、法的意味を確立するために互いの上に構築されるプログラムステートメントのリンクされたリストを構築するために使用される。コンパイルされると、ステートメントは最終的に、ブロックチェーンを構文解析して人間が読める意味のある法律文書を生成するシステムによってフラット化される。
【０１０８】
オーバーライド可能な連動ステートメントの重複する層が作成される。これらのステートメントは、ブロックチェーン上で互いにリンクする。より新しいブロックは、前の親ブロックにリンクし、これは、事前にフォーマットされ、実証され、言語条項の構造化ライブラリにパッケージ化された永続的な法的ステートメントの特定のセットを含む。より新しいブロックは、前のブロックにリンクすることによって、前のブロックのすべてのステートメント及び参照を自動的に継承する。次に、それは、前のブロックを独自の変更で自由にオーバーライドすることができ、ステートメント又は契約条項の新たな「バージョン」を効果的に作成する。ステートメントの任意の部分は、修正とそれらの意味への影響とを成文化する表現に富んだスクリプト言語を使用してオーバーライドされ得る。任意の将来のブロックは、オーバーレイされた変更が新たなブロックにリンクするブロックに対してのみ有効であるため、依然として元の状態のままである前のブロックにリンクすることとなる。
【０１０９】
法的コントラクト記述言語は、非常に精巧であり、機械に優しい設計である。人間が読めるフォーマットを作り出すために、参照のリンクされたリストに継承されるブロックチェーンからのすべてのブロックを構文解析し、各層をフラット化して、拘束力のある契約の準備が整っている、人間が読める最終的な法的コントラクトを作り出す特別なレンダラ（又はインタプリタ）が使用される。層をまとめてフラット化することによって、意味及び成文化された解釈もフラット化され、意味の結果に影響を及ぼす。
【０１１０】
図１０Ａは、契約条項スニペット及び改訂の複合層の視覚表現と、この複合層を「フラット化」することから生成されたスマートコントラクトの表現とを例示する。左側の表現は、３つの複合層を示し、右側の表現は、これらの複合層がフラット化されて最終的なレンダリングされた文書が作り出されている様子を示す。
【０１１１】
図１０Ｂは、層状に配列され、ブロックに格納されたテキストオーバーレイの例の視覚表現を例示する。前のコントラクトスニペットに対する修正は、後に付加されたブロックに格納されることが認識されるであろう。
【０１１２】
図１０Ｃは、条項の修正又は条項の追加によって改訂が行われたときのスマートコントラクトの進行の視覚表現を例示する。図１０Ｃの例は、テキスト文字列に対する改訂を例示しているが、そのような改訂は、契約条項／コントラクトスニペットの任意の部分にも適用され得ることが理解されるであろう。
【０１１３】
前のステートメントに基づいて構築するこの能力を使用することによって、既存のスニペット及びユーザが実証したスニペットのライブラリが作成され得る。最終的には、コントラクトを作るユーザは、既存のスニペットを再利用するだけでよくなり、これは、前のブロック参照への単純なリンクに帰着する。これは、反復を制限することでディスクスペースを節約し、やがて、新たなコントラクトの大部分は、最小限のディスクスペースをとり、代わりに単純な参照で構築されるようになる。これにより、大幅にディスクスペースを節約することができ、更に結果として、より環境に配慮したアプリケーションとなる。
【０１１４】
説明されたブロックチェーンの継承システムの有益な効果は、完全な法律文書セクションとして、又は単に特別なパラグラフ及びセクションとして、コントラクトスニペットにリンクする能力である。異なる法的スニペットは、ブロックチェーン上で前に定義されリンクされたブロックにおいて定義された文書の任意のセクションを表すことができる。これらの個別の法的構成要素は、完全かつ全体的な法的テキストを作成するためにアセンブルされ得る。
【０１１５】
公表されている層のブロックにおいてステートメントを編成するブロックチェーンの能力はまた、公表され得る参照用のスニペットライブラリの作成を可能にする。次いで、人間の請求代理人（claims agent）、弁護士、判例法、又は裁判所の判決によって実証された各ブロックステートメントは、このブロックにリンクするために別のユーザに渡され得る。
【０１１６】
全く同じ理由で、法律文書の層は、リンクするため及び構築を開始するためのテンプレートとして利用可能になる。一次ブロックチェーンの不変の性質のため、ユーザは、ユーザが継承するコントラクトが決して変わることがないことを確信することができる。これにより、法的コントラクトテンプレートに対する堅固な基盤が確保される。
【０１１７】
図１１Ａは、ブロックのチェーン内に格納されたコントラクトスニペットの視覚表現を例示し、ここにおいて、後のブロック（ブロック５２）は、前のブロックに格納されたスニペットを参照して、結果のコントラクト５４０を形成する。
【０１１８】
図１１Ｂは、他の既に格納されたスニペットを参照し、スマートコントラクトの契約条項を定義するために満足度値を更に定義するスニペットの視覚表現を例示する。結果として得られるスニペットの自然言語表現も例示されている。
【０１１９】
再び図８を参照すると、実行検証システム４００は、ユーザがスマートコントラクトを構築することを可能にする様々なモジュールを更に含む。所定のスニペットライブラリ５０４は、ユーザにとってアクセス可能な１つ又は複数の所定のスニペットを格納する。ユーザは、編集モジュール５０８を介して、スニペットライブラリ５０４及び一次ブロックチェーン上に格納された前に作成されたスニペットにアクセスすることができる。コンパイラは更に、コントラクトスニペットを使用して編集モジュール５０８を介してユーザによって作成された契約条項に対応するブロックを作成することができる。コンパイラは更に、第１のブロックチェーンエンジン４０４を介してブロックを一次ブロックチェーンに書き込むことができる。
【０１２０】
様々な例となる実施形態によれば、ブロックチェーンは更に、トランザクションイベントエントリ１００のようなトランザクションをブロックチェーンに発行するときに所与の当事者が身元を明かす（identify themselves）ことを可能にするように構成され得る。トランザクションイベントエントリの追加の実行値は、トランザクションを実行する当事者、例えば、写真をアップロードした当事者のアイデンティティ（例：図４のボックス２１２ａに対応する）であり得る。
【０１２１】
更に、この識別は、その所与の当事者に属する単一の一意の公開暗号鍵に一体的にリンクされることなく提供され得る。従って、これは、当事者のアイデンティティをその一意の発行暗号鍵から「切り離す」ことを可能にする。様々なブロックチェーンにおける重要なセキュリティ問題は、ブロックチェーンに発行されたブロックに使用される公開鍵と、このブロックチェーンにアクセスするときに公開鍵を暗号的に生成するために使用される当事者の秘密鍵との完全性であることが認識されるであろう。当事者の秘密鍵が盗難されたり紛失したりして漏洩し、元の当事者に深刻な影響を与えるケースが多く見られる。例えば、その当事者が所有する資産（例：暗号通貨）に、他の誰かがアクセスしたり（秘密鍵が盗難された場合）、全くアクセスできなくなったり（秘密鍵を紛失した場合）する。
【０１２２】
ブロックチェーントランザクションの当事者のアイデンティティを検証するための例となる実施形態によれば、一意識別子は、ブロックチェーン上の当事者又はアクタに帰属させることができ、それによって、一意識別子は、単一の一意の公開鍵に関連付けられない。例えば、一意識別子は、当事者に関連する公開鍵、作成日時など、当事者に関する様々な情報の一意のハッシュから取得される一意のアカウント番号であり得る。信頼性のないユーザによる新たな一意識別子の作成に対するレート制限要因（rate limiting factor）を確実にするためのプルーフ・オブ・ワーク及びナンスを実装することができる。ブロックチェーン上で取引したいと望む当事者のための新たな識別子の作成を制御するために、中央識別機関を実装することもできる。
【０１２３】
各一意識別子は、複数の公開鍵に更に関連付けられる。各公開鍵は、一意の秘密鍵から導出可能である。当事者初期化トランザクション中、一意識別子とその一意識別子に関連する複数の公開鍵とは、ブロックチェーンのブロック内で発行される。従って、一意識別子及び関連公開鍵は、ブロックチェーン上で動作するすべての当事者に見える。例えば、当事者初期化トランザクションブロックは、所与の当事者に関連する一意識別子と、当事者に関連する（例：当事者が所有している）第１の秘密鍵から導出された第１の公開鍵と、当事者に関連する（例：当事者が所有している）第２の秘密鍵から導出された第２の公開鍵とを含むことができる。
【０１２４】
当事者初期化トランザクションを発行した後、当事者は、ブロックチェーン内の任意の後続のブロックにおいてその一意識別子及びその公開鍵のうちの１つを提供することができる。当然、その公開鍵は、その当事者に属する関連する秘密鍵から暗号的に生成される。
【０１２５】
別のデバイスのような別のアクタは、一意識別子及び公開鍵の存在を実証することによって、後続のトランザクションを実証及び検証することができる。実証を行うアクタは、後続のトランザクションブロックの一意識別子及び公開鍵を、当事者初期化トランザクションにおいて最初に発行された識別子及び公開鍵のセットと比較することができる。両方の情報が後続のトランザクションブロックに含まれている場合、このトランザクションは検証される。
【０１２６】
ここで図１２Ａを参照すると、例示的なブロックチェーンの２つのブロックの視覚表現が例示されている。第１のブロック６００は、当事者初期化ブロックである。上述したように、当事者初期化ブロックは、第１の公開鍵６０２（「ＡＡＡ」）と、第２の公開鍵６０４（「ＢＢＢ」）と、一意のハッシュＩＤ（「ＡＡＢＢＣＣ」）の形の一意識別子６０６とを含み、すべてが初期化当事者に関連付けられている。
【０１２７】
第２のブロック６１０は、後続のトランザクションブロックである。このブロックは、第１の公開鍵６０２と、初期化当事者に関連する一意識別子６０６とを含む。このブロックはまた、本明細書の他の箇所で説明されるように、トランザクション実行値であり得るブロックコンテンツ２１２を含む。
【０１２８】
上で説明したように、第２のブロック６１０を検証するとき、当事者初期化ブロック６００において発行された一意識別子６０６及び公開鍵６０２、６０４が参照される。
【０１２９】
当事者は、認証更新ブロックを更に発行して、当事者初期化ブロックにおいて発行された識別情報を更新及びオーバーライドすることができる。特に、当事者初期化ブロックは、初期の一意識別子と、当事者初期化ブロックにおいて発行された少なくとも１つの公開鍵と、少なくとも１つの鍵変更エントリとを含む。鍵変更エントリは、当事者初期化ブロックに提示された少なくとも公開鍵の値を変更する。例えば、第１の公開鍵は、その値が変更され得、従って、当事者に関連する第３の秘密鍵から導出された第３の公開鍵となる。当事者初期化ブロックにあるものと同じである第２の公開鍵は、認証更新ブロックを発行する当事者のアイデンティティを検証するために提示される。
【０１３０】
認証更新ブロックを発行した後、当事者は、次いで、その一意識別子と、変更された値を有するその公開鍵（すなわち、第３の公開鍵）とを提供することによって、追加のトランザクションブロックを発行することができる。従って、値変更を持っていた当事者初期化ブロックの公開鍵（すなわち、第１の公開鍵）は、もはや、後続のトランザクションブロックにおいて当事者のアイデンティティを検証するために使用することはできない。
【０１３１】
認証更新ブロックの後に発行されたトランザクションブロックを検証するとき、検証を行う当事者は、一意識別子と、変更された値を有する公開鍵（第３の公開鍵）の存在とを実証する。後続のトランザクションは、値が変更された公開鍵を含んでいない場合、無効のトランザクションであると決定される。
【０１３２】
ここで図１２ｂを参照すると、当事者初期化ブロック６００と、認証更新ブロック６２０と、認証更新ブロック６２０に続いて発行されるトランザクションブロック６１０’とを含む例示的なブロックチェーンの３つのブロックの視覚表現が示されている。当事者初期化ブロック６００は、ブロックチェーンに永続的に発行され、従って、図１２ａにおけるその表現から変更されない。認証更新ブロック６２０は、所与の当事者の一意識別子と、アイデンティティを検証するために使用される第２の公開鍵６０４とを含む。この検証は、当事者初期化ブロック６００に戻って参照することによって行われ得る。認証更新ブロック６２０はまた、第３の公開鍵にも対応する値（「ＣＣＣ」）を有する値変更鍵（change-value key）６２２を含む。この鍵は、ブロック６１０’のような後続のトランザクションブロックで使用することができる。ここで、後続のトランザクションブロック６１０’は第３の公開鍵６２２を含むこと及び検証中に認証更新ブロック６２０を参照してそのトランザクションを検証することが認識されるであろう。
【０１３３】
複数の認証更新ブロック６２０は、時間の経過とともに連鎖され得、各認証更新ブロックは、一意識別子と、前の認証更新ブロックの少なくとも１つの公開鍵と、少なくとも１つの値変更公開鍵とを含むことが理解されるであろう。前の認証更新ブロックの公開鍵は、現在の認証更新ブロックを検証するために使用される。値変更公開鍵は、後続のトランザクションブロックを検証するために使用される新たな公開鍵を追加する。値変更公開鍵はまた、前の公開鍵に置き換わることができ、その結果、その鍵は、後続のトランザクションブロックを検証するためにもはや使用することができない。
【０１３４】
当事者初期化ブロック及び後続の認証更新ブロックの上述の連鎖により、当事者は、その一意識別子を使用してトランザクションブロックを発行することができることが認識されるであろう。更に、識別及び検証は、単一の一意の公開鍵に依存しない。代わりに、認証更新ブロックの連鎖により、ブロックを検証するために使用される公開鍵を時間の経過とともに変更することができる。従って、当事者のアイデンティティは、当事者が使用する公開鍵から切り離される。
【０１３５】
この切離しは更に、単一の一意の公開鍵を使用することと比べて、追加のセキュリティレベルを提供する。例えば、当事者が特定の公開鍵（例：第１の公開鍵６０２）をもはや所有していない場合、例えば、関連秘密鍵が漏洩（紛失又は盗難）した場合、その当事者は、依然として所有しているバックアップ鍵（例：第２の公開鍵６０４）を使用して、バックアップ鍵及び値変更鍵を含む認証更新ブロックを発行することができる。バックアップ鍵は当事者初期化ブロックで発行されたものであるため、ブロックチェーン上のすべてのアクタに知られており、そこにはコンセンサスがあり、検証に有用である。値変更鍵も広く知られるものとなり、後続のトランザクションブロックを検証するのに有用であり得る。更に、必要に応じて、追加の値変更鍵が、後続の認証更新ブロックにおいて発行され得る。
【０１３６】
トランザクションの検証は、上で説明したスマートコントラクトの実行を検証するための方法及びシステムと組み合わせて使用され得る。例えば、実行値を有する各二次トランザクションは、一意識別子及び発行された公開鍵を使用して必要に応じて検証され得る。更に、二次トランザクションに含まれる一意識別子は、スマートコントラクトの満足度を決定するために使用されるトランザクションの実行値のうちの１つであり得る。
【０１３７】
ブロックチェーン上で発行されたトランザクションブロックの当事者を有効に識別する能力は、ブロックチェーン上で追加の機能を提供するためにも使用され得る。
【０１３８】
１つの例となる適用例では、一意識別子が公開鍵から切り離されていることで、当事者は、ブロックチェーン上で一意に識別されつつ動作することができるため、システムがこのチェーン上のいくつかのデバイスに対して特別な役割を割り当てることも可能にする。例えば、特別な集中型モデレータデバイスは、それら自体及びそれらの公開鍵を提示し、それら自体をチェーンの信頼性のあるノードとして識別することによって作成され得る。それ以降、チェーン上でこのアイデンティティによって実行され、その約束された公開鍵によって署名された任意のアクションは、ネットワークの残りの部分に対して、それが常にこの特定のアカウントから供給されたものであることを確実にする。そのため、これらの特別な信頼性のあるノードは、コンセンサス確立に参加すること、ブロック確認をリリースすること、悪意のあるデバイスに関する警告メッセージを送ることなど、他者がオンチェーンで行うことができないそれらの役割に関する特別な動作を実行することができる。
【０１３９】
別の例となる適用例では、変化値公開鍵とともにブロックチェーン上の不変の一意識別子を使用することにより、システムは、時間の経過とともにブロックチェーン上のこれらのユーザの活動を相関させ、評価することができる。これにより、システムは、特定のアカウントに関する統計を確立し、それらの挙動に基づいて、それらに特別な信頼値を割り当てることができる。ノードがチェーン上で動作し、ルールを尊重するため、その信頼レベルが高められ得、これは、他者が利用できない特権を与える。アカウントが誤動作した場合、その信頼レベルは、ネットワークから完全に追放され得る点まで下げられ得る。ネットワーク上のノードは、トランザクションが信頼されているアカウントから受信された場合とそうでないアカウントから受信された場合とで異なる挙動をし得る。
【０１４０】
別の例となる適用例では、様々な当事者のオンチェーン挙動が監視され得る。ブロックチェーン上で特定のルール（例えば、（ＩＰアドレスによって識別される）デバイスは３つを超えるアカウント番号を操作しないものとし、毎日１０を超えるトランザクションを投稿しないものとする）を確立することによって、良好に行動する当事者と不良に行動する当事者とが決定され得る。これらのルールを遵守するデバイスは、ネットワーク上で妨害されずに動作する。しかしながら、これらのルールを破るアカウント、例えばユーザのために複数のウォレットを操作する潜在的に信頼性のない第三者ウェブサイトは、最終的にシステムから追放される。この方法論により、高容量プロバイダのネットワークを動作させ飽和させること又は信頼性のないバルクサービスを提供することを適切に制御することができる。
【０１４１】
ブロックチェーンルールは、これらのルールを特別な命令トランザクションで更新するために、特定の役割を有するノードによって周期的に発行される。パブリックノードがこれらのルール更新を受信すると、新たな命令を反映するようにそれらの挙動を修正する。
【０１４２】
第三者パートナーの厳選されたセットが大量のトランザクションを操作することができるように、十分に信頼性があると決定された当事者は、他のユーザに代わって大量の操作を実行するためのオペレーティングライセンスを事実上与える特別な高容量証明書がブロックチェーン上で供給され得る。信頼性のあるノードは、ライセンスが適用されるアカウントと、代わりに動作することが許可されるアカウントとを識別する特別な証明書トランザクションをブロックチェーン上で発行する。このライセンス証明書は、有効日付、満了日などの他の関連情報も含み、モデレータのような特別に認識された役割を有するアイデンティティによって署名される。
【０１４３】
そのようなライセンスされたオペレータが動作するとき、それらは、ピアツーピアネットワーク上でそれらを送る前に、それらの証明書ライセンス識別子をそれらのトランザクションに付加する。トランザクションをネットワークに転送する他のノードは、これらのトランザクションを受信し、含まれるライセンス証明書番号に気付き、それをチェーンで発行された証明書で検証する。証明書が有効であると見なされた場合、トランザクションを許可し、それをネットワークに中継することになり、そうでなければ、そのような証明書のないアカウント及びＩＰアドレスを禁止することになる。
【０１４４】
この実証は、発行されたアカウント番号を参照することによって可能になる。証明書は、例えば、アカウント番号ＡＡＡがアカウントＢＢＢ、ＣＣＣ、及びＤＤＤの代わりに動作することを可能にする。
【０１４５】
隠された方法で（in an ulterior manner）発行された公開鍵への参照及び署名により、ノードは、このトランザクションの所有者が本当にＡＡＡであることを知ることができ、次いで証明書を検証する。それらがアカウント、例えばＢＢＢ、の代わりに動作している場合、ＢＢＢ署名も含まれることとなり、オペレータがＢＢＢのために動作することを可能にするそのライセンス証明書により、オペレータがＢＢＢのためのオペレータとして動作することができることを確認する。
【０１４６】
以下は、付与され得るライセンスの例である：
{
"CertificateId": "033bd16d-1dda-4410-96eb-1d47f730063e",
"CertificateVersion": "1.0.0",
"ModeratorUuid": "28900372-717b-4de7-a1c9-ae6ca482ecc8",
"KeyDeclarationBlockUuid": "6dcc410c-878d-4121-9662-7d8b733e90de",
"PartnerAccountUuid": "cf0b25cc-7523-4401-bcfa-d6f6ee2d29ae",
"PartnerWebsiteUrl": "https://*.partnersite.com",
"EmissionDate": "2018-05-12T14:32:40.0547143Z",
"ValidUntil": "2019-05-12T14:32:40.0566328Z",
"PermittedAccounts" : ["596ecc59-5597-44bb-b2c9-881ef52a3e6d","e0861fa8-2fde-4e73-92d1- 839ca00d50ef","8a1a7475-8a3f-446d-b178-848c4cca74f9"],
"Hash": "25mHph9dhgGQQTCqdEUKSB15VkuxjHatc1RoLCt2DK1FYqJrk3DWmyFgHERu4WM96",
"Signature": "111LZ5rX7p7q22hN6HqjF3gfMvNU6hfYa7EZvL4pG7PhDvVq2XDA3pcAViEEEbJKUut"
}
【０１４７】
更に別の適用例では、新たな一意識別子が当事者のために作成されると、共同署名者としてそれを他のアカウントとリンクすることが可能である。このアカウントに対して新たなトランザクションが作成されると、それは、ブロック発信デバイスによってインターセプトされ、余分なイベントがトランザクションと相関されるのを待つため、所定の猶予期間の間、保留されることとなる。この集中型デバイスは、このアカウント内の他のアカウントリストからの他の二次トランザクションが、それらの署名を確認するのを待つ。必要な署名が割り振られた時間フレーム内に受信されないと、トランザクションは、タイムアウトに伴って、削除され、無効にされる。すべての必要な署名が受信されると、中央デバイスは、このトランザクションを有効であると宣言し、それ自体の署名を用いてそれを確認する。図１３は、第１の当事者初期化ブロック６００ａ及び第２の当事者初期化ブロック６００ｂが２つの当事者に対して提示され、共同当事者初期化ブロック６００ｃも提示されるマルチ署名アプリケーションの例となる実施形態を例示する。１つの署名（１つの一意識別子）だけを有するトランザクションブロック６１０ａは無効と見なされる。両方の署名（両方の一意識別子）を有する第２のトランザクションブロック６１０ｂが有効であると見なされる。
【０１４８】
別のアプリケーションでは、このアカウントが特別に登録され、特別な方法で扱われなければならないことを決定するために、集中型ノードが使用することができる相関番号を当事者初期化ブロックに追加することが可能である。集中型ノードがこのアカウントからトランザクションを受信し、例えば多要素認証を必要とすることを認識した場合、中央デバイスは、アカウントの所有者が本当にこのトランザクションを送るよう意図されていることを確認するために行われる必要があることをブロックチェーン外で実行することができるように、特定の期間の間トランザクションを保持する。所有者がブロックチェーン外でトランザクションを確認すると、中央デバイスはトランザクションを確認することとなる。何も確認されなかった場合、トランザクションはタイムアウトし、削除され、無効にされることとなる。この機構は、鍵の盗難を防止するのに非常に有用であり得る。
【０１４９】
上記説明は実施形態の例を提供するが、説明された実施形態のいくつかの特徴及び／又は機能は、説明された実施形態の動作の趣旨及び原理から逸脱することなく修正が行われやすいことが認識されるであろう。従って、上述したものは、実例となり非限定的であることが意図されており、当業者であれば、添付の特許請求の範囲に定義される本発明の範囲から逸脱することなく、他の変形及び修正が行われ得ることを理解するであろう。
【図１】
2021535668.tif 000010
【図２】
2021535668.tif 000011
【図３】
2021535668.tif 000012
【図４】
2021535668.tif 000013
【図５】
2021535668.tif 000014
【図６】
2021535668.tif 000015
【図７】
2021535668.tif 000016
【図８】
2021535668.tif 000017
【図９】
2021535668.tif 000018
【図１０Ａ】
2021535668.tif 000019
【図１０Ｂ】
2021535668.tif 000020
【図１０Ｃ】
2021535668.tif 000021
【図１１Ａ】
2021535668.tif 000022
【図１１Ｂ】
2021535668.tif 000023
【図１２Ａ】
2021535668.tif 000024
【図１２Ｂ】
2021535668.tif 000025
【図１３】
2021535668.tif 000026
【国際調査報告】
2021535668.tif 000027
2021535668.tif 000028
2021535668.tif 000029
2021535668.tif 000030