(57)【要約】      （修正有）【課題】既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことを可能とする分散台帳システムを提供する。【解決手段】分散台帳システム１０における、分散台帳ノード３（ｐｅｅｒ１）が保持する分散台帳の内容が、分散台帳ノード３群（ｐｅｅｒ２１、２２）が保持する分散台帳の内容よりも少ない場合に、当該分散台帳ノード３群（ｐｅｅｒ２１、２２）が持つ分散台帳から、分散台帳ノード３（ｐｅｅｒ１）が持つ分散台帳にデータをコピーするに際し、分散台帳ノード３（ｐｅｅｒ１）が、コピー元となる分散台帳ノード３群（ｐｅｅｒ２１、２２）および分散台帳ノード３群（ｐｅｅｒ２１、２２）が含む各分散台帳ノード３における分散台帳のコピー箇所を、分散台帳ノード３に関する所定属性に関して予め定めた所定基準に基づき決定する。【選択図】図１
2020204898.tif 000002
【特許請求の範囲】
【請求項１】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーするに際し、
前記第一の分散台帳ノードが、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する、
ことを特徴とする分散台帳システムの運用管理方法。
【請求項２】
前記第一の分散台帳ノードが、
前記分散台帳システムにおける分散台帳ノードが保持するデータの改竄可能性について、所定アルゴリズムで規定した信頼度に基づき判定し、当該判定の結果に応じて、コピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を決定する、
ことを特徴とする請求項１に記載の分散台帳システムの運用管理方法。
【請求項３】
前記第一の分散台帳ノードが、
前記信頼度を規定する所定アルゴリズムとして、各分散台帳ノードを所有する各組織の組織名を用いた論理積および論理和による演算を含む論理式を保持し、
前記判定の対象となる前記データが、正しい生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を真に設定し、前記判定の対象となる前記データが、誤った生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を偽に設定し、
前記設定を経た前記論理式を演算することで、前記改竄可能性について判定する、
ことを特徴とする請求項２に記載の分散台帳システムの運用管理方法。
【請求項４】
前記第一の分散台帳ノードが、
前記論理式における論理積の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードから分散台帳の内容を取得して、前記取得した前記内容が同一である場合、前記改竄可能性が無いと判定する、
ことを特徴とする請求項３に記載の分散台帳システムの運用管理方法。
【請求項５】
前記第一の分散台帳ノードが、
前記論理式における論理和の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードからコピーすべき分散台帳の内容を分割し、それぞれの前記組織群に、前記分割した分散台帳の内容を対応させ、前記組織群の各分散台帳ノードから、前記対応させた分散台帳の内容を取得する、
ことを特徴とする請求項３に記載の分散台帳システムの運用管理方法。
【請求項６】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードであって、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する分散台帳ノードを含む、
ことを特徴とする分散台帳システムの運用管理システム。
【請求項７】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードに、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する処理を、
実行させることを特徴とする分散台帳システムの運用管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラムに関するものである。
【背景技術】
【０００２】
従来、各種取引の多くは、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた。ところが近年では、従来の取引形態と異なる、利用者間のＰ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）取引が提案され、その取引の実装手段として分散台帳技術が存在する。
【０００３】
こうした分散台帳技術の例として、ビットコインと呼ばれる仮想通貨を用いて、銀行などの中央集権機関を必要とせずに決済取引を行う技術（非特許文献１参考）がある。ビットコインでは、Ｐ２Ｐネットワーク上における取引データ（以下、トランザクションとも称する）について、マイナーと呼ばれるノードがその正当性を判定後、プルーフオブワークと呼ばれる特定の作業（ハッシュ値を算出）で確定処理を行っている。
【０００４】
上述のように確定処理されたトランザクションは、１つのブロックにまとめられ、各ノードにおいてブロックチェーン（以下、ＢＣとも称する）と呼ばれる分散台帳に記載される。
一方、上記のビットコイン技術で実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術も更に提案され、進化を続けている。
【０００５】
現状のＢＣの主な特徴としては、（１）ビジネスネットワーク上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、これを数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、などが挙げられる。
【０００６】
このような分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）。ここで、分散台帳に参加する参加者（およびそのノード）によって構成されるネットワークのことをビジネスネットワークと呼ぶ。
【０００７】
上述のＢＣをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。
【０００８】
例えば、ビットコインのような単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくロジックも管理できるようになってきている。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。
【０００９】
一方、ＳＣの実行機能を有する分散台帳基盤（非特許文献２および非特許文献３参照）では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも
する）を受け入れて、各ノードでＴＸを実行することにより、複数ノード上で情報（台帳）を共有する。また、ＴＸに対して予め決めたロジックを実行するスマートコントラクト（ＳＣ）実行機能を備える。
新たに別の組織が分散台帳ノードを追加するときは、既存の分散台帳ノードから分散台帳をコピーする必要がある。
【００１０】
複数のサーバでネットワークを構成し、論理的に同一のデータを各サーバが保持しあうブロックチェーンシステムにおいて、新たなサーバをブロックチェーンネットワークに参加させ、トランザクション処理可能な状態とするには、新規サーバが事前にネットワーク上の全てのデータをコピーすることが必要となる。
しかし、ネットワーク上のデータが大容量である場合、全てのデータのコピーが完了するまでに時間を要する。
【００１１】
そこで、分散コンピューティングシステムにおけるデータのコピー時間を短縮する方法としては、例えば、特許文献１の技術が知られている。この特許文献１においては、新たなサーバが全データ（全ファイル）を予め取得するのではなく、アクセスがあったタイミングでオンデマンドに、ストレージシステムが既存サーバから該当データを取得する技術が開示されている。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】“Ａ  Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ  Ｅｌｅｃｔｒｏｎｉｃ  Ｃａｓｈ  Ｓｙｓｔｅｍ”，  ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆ＞
【非特許文献２】“Ｅｔｈｅｒｅｕｍ  Ｗｈｉｔｅ  Ｐａｐｅｒ”，  ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ｗｉｋｉ／ｗｉｋｉ／［Ｅｎｇｌｉｓｈ］−Ｗｈｉｔｅ−Ｐａｐｅｒ＞
【非特許文献３】“Ｈｙｐｅｒｌｅｄｇｅｒ  Ｆａｂｒｉｃ”，  ［ｏｎｌｉｎｅ］、［平成３１年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ−ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞
【特許文献】
【００１３】
【特許文献１】特表２０１３−５３２３１４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
上述の特許文献１における技術は、ある１つのデータを１つのコピー元から取得するものである。そのため、当該技術を、信頼しうるものとして実装、運用するには、コピー元サーバが正しいデータを返す場合に限られる。
【００１５】
その理由は、分散台帳ノードを使う環境では、複数組織に跨って分散台帳ノードが構築され、コピー元の分散台帳ノードが、信頼できるとは限らない組織により運用されるケースが存在しうるためである。その場合、コピー時に悪意を持って誤ったデータが送付されるケースが起こりうる。
【００１６】
こうした、コピー元の組織が信頼できるとは限らない場合の対処方法として、全ての分散台帳ノードから一時的に全データをコピーし、一時的にコピーしたデータ同士が同一かどうか比較する事が考えられる。
【００１７】
しかしながら、データ量が膨大になる場合は、コピーに時間がかかる、膨大な一時コピー場所が必要になる、他の分散台帳ノードやネットワークの負荷を増大させトランザクション処理に悪影響を与える、といった別の課題が生じる。
そこで本発明の目的は、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことを可能とする技術を提供することにある。
【課題を解決するための手段】
【００１８】
上記課題を解決する本発明の分散台帳システムの運用管理方法は、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーするに際し、前記第一の分散台帳ノードが、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する、ことを特徴とする。
【００１９】
また、本発明の分散台帳システムの運用管理システムは、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードであって、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する分散台帳ノードを含む、ことを特徴とする。
【００２０】
また、本発明の分散台帳システムの運用管理プログラムは、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードに、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する処理を、実行させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本実施形態における分散台帳システムの運用管理方法における基本概念を示す図である。
【図２】本実施形態における運用管理システムを模式的に示す図である。
【図３】本実施形態における分散台帳ノードの物理的な構成を示すブロック図である。
【図４】本実施形態における分散台帳上のブロックチェーンのデータ構造例を示す図である。
【図５】本実施形態における分散台帳上のステート情報のデータ構造例を示す図である。
【図６】本実施形態における、参加メンバー管理情報のデータ構造を示す図である。
【図７】本実施形態におけるビジネスネットワークのメンバー新規登録処理の例を示すフロー図である。
【図８】本実施形態における、トランザクション処理例を示すフロー図である。
【図９】本実施形態における、新規分散処理ノード追加時に分散台帳をコピーする処理例を示すフロー図である。
【図１０】本実施形態における、複数の分散台帳からコピーしてきたブロックチェーンの内容が正しいか検証する処理例を示すフロー図である。
【図１１】本実施形態における、分散処理ノードからブロックをコピーする際のブロックの分割方法の例を示す。
【図１２】本実施形態における、分散処理ノードからブロックをコピーする際のブロックの分割方法の例を示す。
【発明を実施するための形態】
【００２３】
−−−実施例１−−−
＜運用管理方法の基本概念＞
【００２４】
図１に本実施形態における分散台帳システム１０の運用管理方法における基本概念を示す。本実施形態では、ｐｅｅｒ４を新規の分散台帳ノード３（すなわち第一の分散台帳ノード）として追加する場合を考える。
【００２５】
この場合、新規の分散台帳ノード３におけるコピー箇所決定部５０が、保証方針５４および参加メンバー管理情報３８を元に、分散台帳システム１０に含まれるどの分散台帳ノード３（すなわち第二の分散台帳ノード群）から、ブロックチェーン３７２中のどのブロック群を取得するか決定することとなる。分散台帳システム１０は、運用管理システムであるとも言える。
【００２６】
また、上述の新規の分散台帳ノード３におけるコピー処理部５１は、コピー箇所決定部５０で決定したコピー方針に従い、それぞれの分散台帳ノード３（第二の分散台帳ノード群）から、ブロック群を取得し、コピーバッファ５３に置く。
【００２７】
また、上述の新規の分散台帳ノード３における同一性確認部５２は、複数の分散台帳ノード３（第二の分散台帳ノード群）から取得した、同一箇所のブロックの内容が同一であるか比較、検証する。同一性確認部５２は、この検証の結果、各ブロックの内容が同一であると判明した場合、コピーバッファ５３からブロック５３１をコピーして、ブロックチェーン３７２を構築する。
＜運用管理システムの構成例＞
【００２８】
続いて、上述の基本概念を実装するコンピュータシステム、すなわち運用管理システム１０の構成例について説明する。図２は、実施例１における運用管理システム１０を模式的に示す図である。
【００２９】
例示する運用管理システム１０は、１台以上の分散台帳ノード３、１台以上のクライアントノード４によって構成される（分散台帳システムとも言える）。これらの機器は、物理的な通信回線２を通してネットワーク１に接続される。
【００３０】
上述の構成のうち分散台帳ノード３は、コンセンサス管理部３１、スマートコントラクト実行／管理部３２（以下、ＳＣ実行／管理部３２とも称する）、メンバー管理部３３、トランザクション管理部３４、分散台帳３７、参加メンバー管理情報３８、コピー箇所決定部５０、コピー処理部５１、同一性確認部５２、コピーバッファ５３、および保証方針５４によって構成される。
【００３１】
こうした構成を備える分散台帳ノード３は、トランザクション管理部３４の機能によりＴＸを受け付けて、コンセンサス管理部３１の機能によって、他のノードとの間でＴＸを受け入れてよいかの合意形成を行う。
【００３２】
また、この分散台帳ノード３は、上述の合意形成がなされたら、ＳＣ実行／管理部３２の機能を介して、ＳＣのデプロイ、デプロイ済みのＳＣに対する実行を行い、ＴＸの履歴とその実行結果を分散台帳３７に記録する。
【００３３】
なお、分散台帳ノード３の各間の通信は、コンセンサス管理部３１の機能によって行う。また、分散台帳ノード３のトランザクション管理部３４は、クライアントノード４等の各ノードからの要求に対して、ＴＸを受け付けたり、ＴＸの履歴情報を取得・閲覧したりする機能／インタフェースを提供する。
【００３４】
また、分散台帳ノード３のメンバー管理部３３は、ビジネスネットワークに参加するメンバーの新規発行や認証機能を提供する。こうしたメンバー管理では、秘密鍵と公開鍵のペアを用いて、参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。なお、メンバー管理に関する鍵情報は、参加メンバー管理情報３８上に格納・管理される。
【００３５】
また、トランザクション管理部３４は、ＴＸを受け付けた際に、適宜、メンバー管理部３３の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認するが、こうした構成自体は適宜な公知技術を採用すればよく、詳細説明は省略する。
【００３６】
また、分散台帳３７では、スマートコントラクト（ＳＣ）３７１およびブロックチェーン（ＢＣ）３７２、ステート情報３７３を格納・管理する。そのデータ構造としては、本実施例では、ＴＸの履歴をＢＣとして、ＴＸの実行結果に基づくステート情報をテーブル上で保持することを想定する。
一方、クライアントノード４は、トランザクション発行部３５および業務アプリ４１、によって構成される。
【００３７】
ＳＣの利用者もしくは提供者は、クライアントノード４のトランザクション発行部３５を介して各種ＴＸを発行し、これをそれぞれの分散台帳ノード３に対して送信する。なお、ＴＸには発行者情報を付与するが、この情報としては参加メンバー管理情報３８によって発行された認証情報（秘密鍵）を利用する。
【００３８】
また、業務アプリ４１は、トランザクション発行部３５を介して、スマートコントラクト３７１に関するＴＸを発行することで、業務処理を実行／管理するアプリである。
【００３９】
本実施例では、例えば、それぞれ異なる主体によって管理される、複数台の分散台帳ノード３の存在を想定する。上述の主体は、例えば、事業者、組織、ベンダである。同様に、クライアントノード４も複数台存在し、複数のＳＣ利用者がそれぞれ別のクライアントノード４を利用することを想定する。
なお、クライアントノード４に関しては、ＴＸに付与する認証情報をユーザ毎に切り替えることにより、複数のＳＣ利用者が共用することも可能である。
＜分散台帳ノードの物理的構成＞
【００４０】
続いて、実施例１における分散台帳ノード３の物理的な構成について説明する。図３は、実施例１における分散台帳ノード３の物理的な構成例を示すブロック図である。
【００４１】
本実施例における分散台帳ノード３は、インタフェース（Ｉ／Ｆ）１００、演算装置た
るプロセッサ１０１、および、記憶装置たるメモリ１０２を備える計算機である。なお、これらＩ／Ｆ１００、プロセッサ１０１、および、メモリ１０２は、データバス１０３によって接続されている。
【００４２】
このような構成を備える分散台帳ノード３は、Ｉ／Ｆ１００を介して、ネットワーク１と通信する。プロセッサ１０１は、ＣＰＵ等の演算装置である。メモリ１０２は、プログラムおよびデータを保持するための記憶装置である。プロセッサ１０１は、メモリ１０２からデータバス１０３を介してプログラム１１０（コピー箇所決定部５０、コピー処理部５１、および同一性確認部５２に対応したプログラム）を読み出し、実行することで必要な機能を実装する。
＜分散台帳の構成＞
【００４３】
次に、分散台帳３７の構成例について説明する。図４および図５は、分散台帳３７に格納するデータ構造の一例を示す図である。このうち図４は、分散台帳３７上で管理するデータ構造の一つであるＢＣ３７２の例を示す図である。
【００４４】
ＢＣを用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。こうした構成において前段のブロックの値が１ビットでも変わると、後続の全ブロックのハッシュ値が変化する。そのため改ざんを困難にすることができる。なお、本実施例では説明をシンプルにするために、１つのＴＸにつき１ブロックとするが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。
図４におけるブロック３７２１、ブロック３７２２、およびブロック３７１３は、一連のブロックの連なり、すなわちＢＣとなる。
【００４５】
各ブロックは、それぞれＳＣのデプロイ、実行いずれかのＴＸ情報を含む。また各ブロックはそのブロックの生成に関するタイムスタンプ情報を含む。さらに各ブロックは、前ブロックのハッシュ値を含み、後述のステート情報から生成したハッシュ値を含む。
上記のようなデータ構造により、ＳＣのデプロイ、実行ＴＸがＢＣの中でデータの連鎖として管理されることとなる。
【００４６】
こうしたＢＣを構成するブロックのうちブロック３７２１は、ＳＣ３７１のデプロイＴＸを格納したブロックの一例である。この例では、貨物輸送に関するビジネスコントラクトの例を示している。
【００４７】
本実施例のデプロイＴＸは、コントラクトを一意に識別するコントラクトＩＤ、コントラクトの実態（例えば実行可能なバイナリ）を含む。また、コントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。
【００４８】
さらに、デプロイ時に指定した入力引数にしたがって決めたパラメータ（例えばコントラクトの利用者や各種定義情報等）であるコントラクトメタ定義を含む。また、このデプロイＴＸの発行元、すなわち、提供者を識別するためのＩＤ情報（発行者ＩＤ）を含む。
【００４９】
さらに発行元とデータに改ざんが無いことを検証するために用いる電子署名を含む。この電子署名はメンバー管理部３３が発行した各ネットワーク参加メンバー（すなわちＳＣ提供者や利用者）の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。
【００５０】
また、ブロック３７２２、ブロック３７２３はＳＣ３７１の実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸは、呼び出し対象となるコントラクトのコントラク
トＩＤ、呼び出し対象となるコントラクトの関数名と入力する引数の情報を含む。
【００５１】
さらにこの本番実行ＴＸの発行元、すなわち、利用者を識別するためのＩＤ情報（実行者ＩＤ）を含む。さらに発行元とデータに改ざんがないことを検証するために用いる利用者署名を含む。なお、発行元だけでなく、合意形成に関わったネットワーク参加者の情報も管理／保持してもよい。
【００５２】
図５は、本実施例の分散台帳３７上で管理するステート情報３７３を示す図である。ＢＣを用いた分散台帳管理では、通常、（最新の）ステート（例えば、仮想通貨の場合にはアカウントの残高）を取得するためには、ＢＣを辿らなければならない。これでは処理効率が悪いため、ＢＣとは別に、最新のステート情報をキャッシュしておく方法が存在する（非特許文献３等）。よって本実施例でも最新のステート情報を保持することを想定する。
本実施例では、コントラクト毎にステートのデータ領域が用意されることとする。ステート情報は、コントラクトＩＤとそのコントラクトの実態を保持する。
【００５３】
これにより、分散台帳ノード３のＳＣ実行／管理部３２は、コントラクトＩＤをキーにして、コントラクトの実態を取得して実行することができる。また、ステート情報はＳＣの実行結果を保持するための内部テーブルを備える。ＴＸが実行される度にこの内部テーブルの内容を更新する。
【００５４】
図６は、本実施例における参加メンバー管理情報３８の一例である。参加メンバー管理情報３８は表形式となっており、一つ以上の行から成る。全ての行は、２つの列を含んでいる。ここで２つの列とは、組織名３８１、分散台帳ノード名３８２である。
【００５５】
参加メンバー管理情報３８の各行は、これ以外の不図示の列を含んでいても良いし、幾つかの列が存在しなくても良い。参加メンバー管理情報３８に格納された情報は、システム管理者などが手作業で作成しても、あるいは何らかのツールやユーティリティを用いて作成しても良い。
【００５６】
こうした参加メンバー管理情報３８には、分散台帳ノード３を運営する組織の名称３８１と、その組織が持つ分散台帳ノードの名称３０２情報が格納されている。
＜フロー例：メンバー新規登録＞
【００５７】
図７は、ビジネスネットワークに参加するメンバーの新規登録処理の例を示すフローチャートである。この場合、分散台帳ノード３のメンバー管理部３３は、クライアントノード４等の他ノードからメンバー登録要求を受け付ける（Ｓ１０１）。このメンバー登録要求には、要求メンバーを一意に識別するメンバーＩＤが含まれることとする。
【００５８】
続いて、メンバー管理部３３は、適宜なアルゴリズムにて秘密鍵と公開鍵の組を生成し、この組みを、上述のステップＳ１０１で受け取ったメンバーＩＤと紐付ける（Ｓ１０２）。
【００５９】
次に、メンバー管理部３３は、上述のステップＳ１０１で得た、新規登録対象となるメンバーＩＤと、上述のステップＳ１０２で生成した公開鍵とを、他のノードにブロードキャストする（Ｓ１０３）。
ここでブロードキャストされたメンバーＩＤおよび公開鍵の情報は、各ノード上で参加メンバー管理情報３８として保管する。
【００６０】
さらに、メンバー管理部３３は、メンバー登録要求を行ったノード（Ｓ１０１の契機と
なったノード）に対し、ステップＳ１０２で生成した秘密鍵を返す（Ｓ１０４）。一方、この秘密鍵を受け取ったノードは、参加メンバー管理情報３８に自身の秘密鍵として保管する。
【００６１】
本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、ネットワーク参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。
【００６２】
具体的には、例えば、クライアントノード４側は、発行された秘密鍵で電子署名したＴＸを発行し、検証ノード側が公開鍵を用いて電子署名を検証することで、本人確認を実現できる。
【００６３】
なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法、鍵とＩＤを紐付ける手法については、公知または周知の技術を適用すれば良い。よって本実施例１では詳述しない。また本実施例では、メンバー管理部３３の機能を分散台帳ノード３中に機能として示したが、外部にメンバー管理専用のノードを立て、そのノードがメンバー管理部３３と同等の機能を提供するとしてもよい。
＜フロー例：ＴＸ実行処理＞
【００６４】
続いて、ＴＸ実行処理について説明する。図８は、ＴＸ実行処理の例を示すフローチャートである。この場合、分散台帳ノード３のトランザクション管理部３４が、クライアントノード４等のＴＸ発行元からＴＸを受け取り（Ｓ２０１）、これをコンセンサス管理部３１に渡すことで実行処理を行う。
【００６５】
コンセンサス管理部３１は、他の分散台帳ノード３との間で、受け取ったＴＸを実行してよいか、ブロックとしてＢＣの末尾に追加してよいかの合意形成処理を行う（Ｓ２０４）。
具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。ここでは保証方針５４に従い、合意形成するものとする。
【００６６】
上述の保証方針５４を用いた合意形成を簡単に説明すると、コンセンサス管理部３１は、保証条件５４で指定されたそれぞれの組織に対して、参加メンバー情報３８を参照して分散台帳ノード３を一つ選択する。
【００６７】
また、当該分散台帳ノード３上で、ＴＸに対する署名検証を行って、改ざんされていないことやＴＸの内容の正当性を確認し、その確認結果をコンセンサス管理部３１に送付する。
【００６８】
コンセンサス管理部３１は、それぞれの組織が合意したか、或いは却下したかという結果を使って、保証方針５４に従った論理演算を行い、合意形成が完了したか却下されたかを判断する（Ｓ２１０）。保証方針５４を使った合意形成の方法は後述する。
上述の判断の結果、合意形成が却下された場合（Ｓ２１０：Ｎ）、コンセンサス管理部３１は、クライアントにエラーを返し（Ｓ２１１）処理を終了する。
【００６９】
一方、合意形成が完了した場合（Ｓ２１０：Ｙ）、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、ＳＣを実行して分散台帳３７の内容を更新する（Ｓ２０８）。
【００７０】
具体的には、実行ＴＸ内で指定されたコントラクトＩＤを持つＳＣ（登録済みであることを前提とする）に対して、実行ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳３７の内容を更新する。また、コンセンサス管理部３１は、実行結果に基づいて、本コントラクトに関するステート情報５０２を更
新し、ＢＣの末尾のブロックとして実行ＴＸを追加する。
最後に、コンセンサス管理部３１は、この実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返し（Ｓ２０９）、処理を終了する。
【００７１】
ここで、上述の保証方針５４を使った合意形成方法について説明する。保証方針５４は、Ｈｙｐｅｌｅｄｇｅｒ  Ｆａｂｒｉｃ（非特許文献３等）で使われるＥｎｄｏｒｓｅｍｅｎｔ  Ｐｏｉｃｙに相当する。保証方針５４は、条件文と条件要素からなる。また、保証方針５４は、合意形成時に真または偽として評価される。
【００７２】
保証方針５４における条件文は、Ｏｒ／Ａｎｄ／ＯｕｔＯｆのいずれかである。ただし、これら以外の条件文を用いても良い。なお、条件分がＯｕｔＯｆの場合は、追加で一つの引数ｋを持つ。追加の引数ｋは条件要素ではなく条件文の一部とみなす。
【００７３】
また、保証方針５４における条件要素は、組織名４００または条件文からなる。合意形成とともに、条件要素は真または偽で評価される。条件要素が組織名４００の場合、当該組織が合意形成で合意したならば、真と評価される。また、合意形成で却下したときは偽と評価される。合意も却下もまだしていないときは、合意または却下の結果が出るまで当該条件要素は未評価となる。
【００７４】
上述の条件要素が条件文の場合、当該条件文の値（真または偽）がそのまま評価される。条件文がＯｒの場合、少なくとも一つの条件要素が真であれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
【００７５】
また、条件文がＡｎｄの場合、全ての条件要素が真と評価されるのであれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
【００７６】
また、条件文がＯｕｔＯｆの場合、少なくともｋ個の条件要素が真と評価されていれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
こうした保証方針５４の例と、その評価結果の例を以下に示す。ここでＯｒｇ１，Ｏｒｇ２，Ｏｒｇ３は、図１で示した組織４００であるとする。
・Ｏｒ（Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３）：Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３の少なくとも１つの組織の分散台帳ノード３が合意したときに、真と評価される。
・Ａｎｄ（Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３）：Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３の全ての組織の分散台帳ノード３が合意したときに、真と評価される。
【００７７】
・ＯｕｔＯｆ（２，Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３）：Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３のうち、少なくとも２つの組織の分散台帳ノード３が合意したときに、真と評価される。
【００７８】
・Ｏｒ（Ａｎｄ（Ｏｒｇ１，Ｏｒｇ２），Ｏｒｇ３）：Ｏｒｇ１，Ｏｒｇ２の両方が、またはＯｒｇ３が、またはＯｒｇ１、Ｏｒｇ２、Ｏｒｇ３の全てが合意したときに真と評価される。
＜フロー例：コピー処理＞
【００７９】
続いて、新規分散処理ノード３を追加する際に、複数の既存の分散処理ノード３から、当該新規の分散処理ノード３に分散台帳３７２をコピーする処理について説明する。図９は、分散台帳をコピーする処理例を示すフロー図である。
【００８０】
この場合、例えば新規の分散台帳ノード３におけるコピー箇所決定部５０は、保証方針
５４および参加メンバー管理情報３８に基づき、コピー元となる分散台帳ノード３を決定する（Ｓ３０１）。
【００８１】
図１の場合を例に説明すると、保証方針５４より、ｏｒｇ１，ｏｒｇ２，ｏｒｇ３の各組織が運用する分散台帳ノード３から、それぞれブロックチェーン３７２をコピーする。ここでは、ｏｒｇ１の分散台帳ノード３であるｐｅｅｒ１、ｏｒｇ２の分散台帳ノード３であるｐｅｅｒ２１、ｐｅｅｒ２２、ｏｒｇ３の分散台帳ノード３であるｐｅｅｒ３からコピーする。
【００８２】
一つの組織に複数の分散台帳ノード３があるときは、１ないし全ての分散台帳ノード３からコピーする。例えば、ＣＰＵ負荷やＩ／Ｏ負荷、ネットワーク帯域使用量が一番少ない分散台帳ノード３からコピーしても良いし、ＣＰＵ負荷やＩ／Ｏ負荷、ネットワーク帯域使用量の幾つかが、指定された閾値以下となる分散台帳うノード３からコピーしても良いし、全ての分散台帳ノード３に分散させて分散台帳ノード３からコピーしても良い。
なお、図８の合意形成で使う保証方針５４と、図９のコピー元分散台帳ノード３の決定に使われる保証方針５４は、同一であっても、異なる物であっても良い。
【００８３】
続いて、コピー箇所決定部５０は、ステップＳ３０１で決定した分散台帳ノード３から、個々のブロックを識別する識別子を取得する（Ｓ３０２）。識別子としては、各ブロックのタイムスタンプや前ブロックハッシュ値、ステートハッシュ値、当該ブロックのハッシュ値、それらの組み合わせが考えられる。
【００８４】
続いて、コピー箇所決定部５０は、ブロックチェーン３７２のどの箇所を、どこの組織４００から取得するか決定する（Ｓ３０３）。この処理は図１０で詳しく説明する。この処理には、ブロックの識別子と、保証方針５４を引数として渡す。
【００８５】
続いて、コピー処理部は、ステップＳ３０３で決まった取得方針に従い、Ｓ３０１で決定した分散台帳ノート３からブロックを取得し、コピーバッファ５３にコピーする（Ｓ３０４）。
【００８６】
上述のコピー後に、同一性確認部５２は、異なる組織にある分散台帳ノード３から取得した、同じ識別子を持つ複数のブロックのデータが同一であるか確認する（Ｓ３０５）。ある識別子を持ったブロックが高々一つしかないときは比較しない。
【００８７】
なお、全てのブロックのコピーが終了してから、上述のステップＳ３０５を処理しても良いし、同一ブロックの情報を全ての分散台帳ノード３から取得が完了した時点で、当該ブロックの同一性を確認しても良い。
【００８８】
上述のステップＳ３０５の結果、同一の内容でないブロックがある場合（Ｓ３０６：Ｙ）、同一性確認部５２は、コピー元の分散台帳ノード３がデータが改竄している可能性があるため、図９の処理を呼び出した管理者（のクライアントノード４など）にエラーを返し（Ｓ３０９）処理を終了する。
【００８９】
ただし、ある識別子を持つブロックを対象に、同じ内容を持つブロックの数が一番多いものを、正しいブロックの値とみなし、Ｓ３０７に遷移し処理を継続しても良い。
【００９０】
一方、上述のステップＳ３０５の結果、同じ識別子を持つブロックの内容が全て同一であった場合（Ｓ３０６：Ｎ）、例えば、コピー処理部５１は、コピーバッファ５３にあるブロックから、分散台帳３７２を構築する（Ｓ３０７）。
【００９１】
続いて、コピー処理部５１は、ステップＳ３０７で分散台帳３７２を構築した結果、ブロック同士の接続関係が正しいか、前ブロックハッシュ値やタイムスタンプを元に検証する（Ｓ３０８）。
【００９２】
上述の検証の結果、接続関係が正しい場合（Ｓ３０８：Ｙ）、コピー処理部５１は、処理をＳ３１０に進める。一方、接続関係に誤りがある場合（Ｓ３０８：Ｎ）、コピー処理部５１は、エラーとみなして処理をＳ３０９に遷移させる（Ｓ３０９）。
最後に、例えば、コピー処理部５１は、クライアントノード４から、新規追加する分散台帳３へのアクセスを許可する（Ｓ３１０）
＜フロー例：取得方法決定＞
【００９３】
続いて、分散台帳３７２をコピーする際に、コピー元となる分散台帳３７２について、そのどの部分を、どの組織４００にある、既存の分散処理ノード３から取得するのか決める処理について説明する。図１０は、取得方法決定の処理例を示すフロー図である。
【００９４】
この場合、コピー箇所決定部５０は、図１０の処理が呼び出されたときの引数から保証方針５４を取得し、その条件文を変数ＯＰに、また条件要素を変数Ｐに格納する。また、条件要素Ｐの要素数を変数ｎに格納する（Ｓ４０１）。
続いて、コピー箇所決定部５０は、上述の引数に渡された、ブロックチェーンを構成する個々のブロックの識別子をｎ個に分割し、変数Ｃに格納する。
【００９５】
この分割は、どのような分割方法で行っても良いが、本実施例では、ブロックチェーンに接続されているブロックの順序を維持したまま、個々の分割要素が、（ブロックの全体数÷ｎ）になるよう切断する方式を例示する。
【００９６】
なお、分割した要素の要素数は等しくなくても良い。割り算の余りがあるときは、分割したいずれかの要素の要素数に＋１しても良い。ブロックの数ではなく、ブロックのサイズを元に、サイズがほぼ等しくなるように分割しても良い。変数Ｃの各要素に、異なる組織が署名したブロックが数多く入るように分割しても良い。変数Ｃの各要素に、なるべく少ない組織が署名したブロックが入るように分割しても良い。
【００９７】
続いて、コピー箇所決定部５０は、上述の条件文を判定する。条件文ＯＰがＯｒの場合（Ｓ４０３：Ｙ）、コピー箇所決定部５０は、Ｐの各要素に、Ｃの要素をそれぞれ対応させ、変数Ｒに格納する（Ｓ４０４）。
【００９８】
それぞれの要素に対応させる方法は、どのような方法でも良い。例えばランダムに対応させても良いし、各組織が持つ分散台帳ノード３の数や総合性能、最大性能、これまでの性能統計情報、各組織４００の分散台帳ノード３へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、対応方法を決めても良い。
【００９９】
一方、条件文ＯＰがＡｎｄの場合（Ｓ４０５：Ｙ）、コピー箇所決定部５０は、Ｐの各要素に対して、引数で指定されたブロックチェーンの全要素を対応させ、変数Ｒに格納する（Ｓ４０６）。
【０１００】
なお、Ｐの要素数が、例えば１０以上と多いときには、何らかの条件を元にＰの数を減らしても良い。例えばランダムに減らしても良いし、各組織が持つ分散台帳ノード３の数や総合性能、最大性能、これまでの性能統計情報、各組織４００の分散台帳ノード３へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、減らす組織を決めても良い。
【０１０１】
他方、条件文ＯＰがＯｕｔＯｆ（ｋ，．．．）の場合（Ｓ４０７：Ｙ）、コピー箇所決定部５０は、変数Ｃからｋ個の要素を取り出す全ての組み合わせを列挙し、変数Ｕに格納する（Ｓ４０８）。
【０１０２】
例えばＯｕｔＯｆ（２，Ａ，Ｂ，Ｃ）のときは、（Ａ，Ｂ，Ｃ）の３要素中の２要素を取り出す組み合わせを列挙するので、結果は（Ａ，Ｂ），（Ｂ，Ｃ），（Ａ，Ｃ）の３つとなる。
【０１０３】
続けて、コピー箇所決定部５０は、Ｕの各要素に、Ｃの要素をそれぞれ対応させ、変数Ｒに格納する（Ｓ４０４）。それぞれの要素に対応させる方法は、どのような方法でも良い。例えばランダムに対応させても良いし、各組織が持つ分散台帳ノード３の数や総合性能、最大性能、これまでの性能統計情報、各組織４００の分散台帳ノード３へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、対応方法を決めても良い。
上述の判定の結果、いずれの条件文にも合致しなければ（Ｓ４０７：Ｎ）、コピー箇所決定部５０は、処理を終了する。
【０１０４】
一方、いずれかの条件文に合致した場合（Ｓ４０３：Ｙ、Ｓ４０５：Ｙ、Ｓ４０７：Ｙ）、コピー箇所決定部５０は、参加メンバー管理情報３８を元に、各組織４００が持つ分散台帳ノード３の数に応じて、ブロックを更に分割し、分散台帳ノード３の名称と、分割したブロックを対応付けて変数Ｒに格納する（Ｓ４１０）。
また、コピー箇所決定部５０は、上述の変数Ｒに含まれる要素に条件文が含まれていなければ（Ｓ４１１：Ｎ）、処理を終了する。
【０１０５】
一方、コピー箇所決定部５０は、上述の変数Ｒに含まれる要素に条件文が含まれている場合（Ｓ４１１：Ｙ）、当該条件文を解析するために、再帰的に図１０の処理を呼び出し（Ｓ４１２）、その結果を変数Ｒに追記し（Ｓ４１３）、処理を終了する。
＜分散台帳の分割形態について＞
【０１０６】
続いて、図１０の取得方法の決定処理により、分散台帳３７２がどのように分割され、ある分割箇所のデータをどのノードから取得するかを決めた具体例について説明する。図１１、図１２は、分散台帳の分割方法の具体例を示す図である。
【０１０７】
図１１において、１２個のブロック９００から成る分散台帳ノード３７２を、図６の参加メンバー管理情報３８と保証方針５４を元に分割した例が、分割形態９１０、９２０、９３０、９４０である。
【０１０８】
また、こうした分割形態における、保証方針９１１、９２１、９３１、９４１を元に、各組織が持つ分散台帳ノード３７２ごとに分割したのが、ブロック９１２、９２２、９３２、９４２である。
【０１０９】
このうち分割形態９１０では、条件文がＯｒであるため、各組織から均等な数のブロックを取得する。組織Ｏｒｇ２には分散台帳ノード３が２つあるため、ｐｅｅｒ２１とｐｅｅｒ２２に分けて取得する。
【０１１０】
また、分割形態９２０では、条件文がＡｎｄであるため、各組織から同じ数のブロックを取得する。組織Ｏｒｇ２には分散台帳ノード３が２つあるため、ｐｅｅｒ２１とｐｅｅｒ２２に分けて取得する。
【０１１１】
また、分割形態９３０では、条件文がＯｕｔＯｆ（２であるため、ブロック全体を３分割し、各組織から分割したものうち２つを取得する。組織Ｏｒｇ２には分散台帳ノード３が２つあるため、ｐｅｅｒ２１とｐｅｅｒ２２に分けて取得する。
【０１１２】
なお、ＯｕｔＯｆの条件は、ＡｎｄとＯｒの組み合わせに変換できるため、保証方針５４の内容をＡｎｄとＯｒの組み合わせに変換しても良い。例えば９３０の内容は、Ｏｒ（Ａｎｄ（ｏｒｇ１，ｏｒｇ２），Ａｎｄ（ｏｒｇ２，ｏｒｇ３），Ａｎｄ（ｏｒｇ１，ｏｒｇ３）と同等である。
【０１１３】
また、分割形態９４０では、ＯｒとＡｎｄの複合条件であるため、ブロックを２分割し、前半部分を組織ｏｒｇ１と組織ｏｒ２から重複して取得し、後半を組織ｏｒ３から取得する。組織Ｏｒｇ２には分散台帳ノード３が２つあるため、ｐｅｅｒ２１とｐｅｅｒ２２に分けて取得する。
以上の処理により、新規の分散台帳ノード３の追加処理が高速化され、当該新規の分散台帳ノード３が使用可能になるまでの時間を短縮できる。
−−−実施例２−−−
【０１１４】
実施例２では、新たに追加した分散台帳ノード３に、実施例１の処理によるコピー処理が終了する前に、新たに追加した分散台帳ノード３を使用可能するための実施形態について説明する。基本処理は実施例１と同じである。
【０１１５】
図９のフローにおけるステップＳ３１０での、クライアントノード４から、新規追加する分散台帳３へのアクセスを許可する処理を、図８のフローにおけるステップＳ２０１より先に実行する。
【０１１６】
そこで、図９の処理を実行中、トランザクション管理部３４に対してクライアントノード４からブロックへの参照要求があった場合、コピー処理部５１は、当該ブロックを既存の分散台帳ノード３から取得し、コピーバッファ５３にコピーする。そして、上述のクライアントノード４へ取得したブロックを返す。
これにより、新規の分散台帳ノード３の追加処理中であっても、クライアントノード４からのブロックチェーンへのデータ参照が行えるようになる。
【０１１７】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【０１１８】
こうした本実施形態によれば、分散台帳システムにおいて、新規分散台帳ノードを追加した際や、既存分散台帳ノードが故障した際などに、信頼できるとは限らない複数の分散台帳ノードから、正しいデータのコピーを、コピー時間や他の分散処理ノード、ネットワークの負荷を低減しつつ行うことができる。
すなわち、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことが可能となる。
【０１１９】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記分散台帳システムにおける分散台帳ノードが保持するデータの改竄可能性について、所定アルゴリズムで規定した信頼度に基づき判定し、当該判定の結果に応じて、コピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を決定する、としてもよい。
【０１２０】
これによれば、各組織の信頼度をもとに、データコピー箇所を決定することが可能とな
る。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【０１２１】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記信頼度を規定する所定アルゴリズムとして、各分散台帳ノードを所有する各組織の組織名を用いた論理積および論理和による演算を含む論理式を保持し、前記判定の対象となる前記データが、正しい生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を真に設定し、前記判定の対象となる前記データが、誤った生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を偽に設定し、前記設定を経た前記論理式を演算することで、前記改竄可能性について判定する、としてもよい。
【０１２２】
これによれば、Ｅｎｄｏｒｓｅｍｅｎｔ  Ｐｏｌｉｃｙ等の保証方針に基づき、データコピー方法を効率的に決定できる。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【０１２３】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記論理式における論理積の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードから分散台帳の内容を取得して、前記取得した前記内容が同一である場合、前記改竄可能性が無いと判定する、としてもよい。
【０１２４】
これによれば、改竄可能性の有無についてより効率的に確認可能となる。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【０１２５】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記論理式における論理和の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードからコピーすべき分散台帳の内容を分割し、それぞれの前記組織群に、前記分割した分散台帳の内容を対応させ、前記組織群の各分散台帳ノードから、前記対応させた分散台帳の内容を取得する、としてもよい。
【０１２６】
これによれば、分散台帳ノードを信頼できるとみなしたデータの取得を可能とし、ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【符号の説明】
【０１２７】
１  ネットワーク
２  通信回線
３  分散台帳ノード
１０  運用管理システム
１００  Ｉ／Ｆ
１０１  プロセッサ
１０２  メモリ
１０３  データバス
１１０  プログラム
３１  コンセンサス管理部
３１１  ネットワークプロトコル部
３２  スマートコントラクト実行／管理部（ＳＣ実行／管理部）
３３  メンバー管理部
３４  トランザクション管理部
３５  トランザクション発行部
３７  分散台帳
３７１  スマートコントラクト
３７２  ブロックチェーン
３８  参加メンバー管理情報
４  クライアントノード
４１  業務アプリ
５０  コピー箇所決定部
５１  コピー処理部
５２  同一性確認部
５４  保証方針
【図１】
2020204898.tif 000003
【図２】
2020204898.tif 000004
【図３】
2020204898.tif 000005
【図４】
2020204898.tif 000006
【図５】
2020204898.tif 000007
【図６】
2020204898.tif 000008
【図７】
2020204898.tif 000009
【図８】
2020204898.tif 000010
【図９】
2020204898.tif 000011
【図１０】
2020204898.tif 000012
【図１１】
2020204898.tif 000013
【図１２】
2020204898.tif 000014