特開2020-204898(P2020-204898A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧
特開2020-204898分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム
<>
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000003
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000004
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000005
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000006
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000007
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000008
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000009
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000010
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000011
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000012
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000013
  • 特開2020204898-分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム 図000014
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2020-204898(P2020-204898A)
(43)【公開日】2020年12月24日
(54)【発明の名称】分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム
(51)【国際特許分類】
   G06F 16/182 20190101AFI20201127BHJP
   G06Q 20/38 20120101ALI20201127BHJP
【FI】
   G06F16/182
   G06Q20/38 310
【審査請求】未請求
【請求項の数】7
【出願形態】OL
【全頁数】20
(21)【出願番号】特願2019-112150(P2019-112150)
(22)【出願日】2019年6月17日
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000176
【氏名又は名称】一色国際特許業務法人
(72)【発明者】
【氏名】飯塚 大介
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055AA71
(57)【要約】      (修正有)
【課題】既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことを可能とする分散台帳システムを提供する。
【解決手段】分散台帳システム10における、分散台帳ノード3(peer1)が保持する分散台帳の内容が、分散台帳ノード3群(peer21、22)が保持する分散台帳の内容よりも少ない場合に、当該分散台帳ノード3群(peer21、22)が持つ分散台帳から、分散台帳ノード3(peer1)が持つ分散台帳にデータをコピーするに際し、分散台帳ノード3(peer1)が、コピー元となる分散台帳ノード3群(peer21、22)および分散台帳ノード3群(peer21、22)が含む各分散台帳ノード3における分散台帳のコピー箇所を、分散台帳ノード3に関する所定属性に関して予め定めた所定基準に基づき決定する。
【選択図】図1
【特許請求の範囲】
【請求項1】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーするに際し、
前記第一の分散台帳ノードが、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する、
ことを特徴とする分散台帳システムの運用管理方法。
【請求項2】
前記第一の分散台帳ノードが、
前記分散台帳システムにおける分散台帳ノードが保持するデータの改竄可能性について、所定アルゴリズムで規定した信頼度に基づき判定し、当該判定の結果に応じて、コピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を決定する、
ことを特徴とする請求項1に記載の分散台帳システムの運用管理方法。
【請求項3】
前記第一の分散台帳ノードが、
前記信頼度を規定する所定アルゴリズムとして、各分散台帳ノードを所有する各組織の組織名を用いた論理積および論理和による演算を含む論理式を保持し、
前記判定の対象となる前記データが、正しい生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を真に設定し、前記判定の対象となる前記データが、誤った生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を偽に設定し、
前記設定を経た前記論理式を演算することで、前記改竄可能性について判定する、
ことを特徴とする請求項2に記載の分散台帳システムの運用管理方法。
【請求項4】
前記第一の分散台帳ノードが、
前記論理式における論理積の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードから分散台帳の内容を取得して、前記取得した前記内容が同一である場合、前記改竄可能性が無いと判定する、
ことを特徴とする請求項3に記載の分散台帳システムの運用管理方法。
【請求項5】
前記第一の分散台帳ノードが、
前記論理式における論理和の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードからコピーすべき分散台帳の内容を分割し、それぞれの前記組織群に、前記分割した分散台帳の内容を対応させ、前記組織群の各分散台帳ノードから、前記対応させた分散台帳の内容を取得する、
ことを特徴とする請求項3に記載の分散台帳システムの運用管理方法。
【請求項6】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードであって、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する分散台帳ノードを含む、
ことを特徴とする分散台帳システムの運用管理システム。
【請求項7】
分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードに、
前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する処理を、
実行させることを特徴とする分散台帳システムの運用管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラムに関するものである。
【背景技術】
【0002】
従来、各種取引の多くは、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた。ところが近年では、従来の取引形態と異なる、利用者間のP2P(Peer to Peer)取引が提案され、その取引の実装手段として分散台帳技術が存在する。
【0003】
こうした分散台帳技術の例として、ビットコインと呼ばれる仮想通貨を用いて、銀行などの中央集権機関を必要とせずに決済取引を行う技術(非特許文献1参考)がある。ビットコインでは、P2Pネットワーク上における取引データ(以下、トランザクションとも称する)について、マイナーと呼ばれるノードがその正当性を判定後、プルーフオブワークと呼ばれる特定の作業(ハッシュ値を算出)で確定処理を行っている。
【0004】
上述のように確定処理されたトランザクションは、1つのブロックにまとめられ、各ノードにおいてブロックチェーン(以下、BCとも称する)と呼ばれる分散台帳に記載される。
一方、上記のビットコイン技術で実装されたBCをベースにして、BCおよび分散台帳に関して様々な派生技術も更に提案され、進化を続けている。
【0005】
現状のBCの主な特徴としては、(1)ビジネスネットワーク上の参加者間の取引において、中央集権機関ではなく(任意ないしは特定の)参加者による合意形成や承認によって取引を確定させること、(2)複数のトランザクションをブロックとしてまとめ、これを数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、(3)参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、などが挙げられる。
【0006】
このような分散台帳を提供する基盤(以下、分散台帳基盤)を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる(例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等)。ここで、分散台帳に参加する参加者(およびそのノード)によって構成されるネットワークのことをビジネスネットワークと呼ぶ。
【0007】
上述のBCをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理/共有や、契約に基づく取引の執行/管理を行う仕組みとして、金融分野やIoT(Internet of Thing)等、幅広い分野での応用が検討されている。
【0008】
例えば、ビットコインのような単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で(取引)データだけでなくロジックも管理できるようになってきている。このロジックはスマートコントラクト(以下、SCとも称する)と呼ばれる。
【0009】
一方、SCの実行機能を有する分散台帳基盤(非特許文献2および非特許文献3参照)では、ノード間で所定の合意水準で合意形成しながらトランザクション(以下、TXとも
する)を受け入れて、各ノードでTXを実行することにより、複数ノード上で情報(台帳)を共有する。また、TXに対して予め決めたロジックを実行するスマートコントラクト(SC)実行機能を備える。
新たに別の組織が分散台帳ノードを追加するときは、既存の分散台帳ノードから分散台帳をコピーする必要がある。
【0010】
複数のサーバでネットワークを構成し、論理的に同一のデータを各サーバが保持しあうブロックチェーンシステムにおいて、新たなサーバをブロックチェーンネットワークに参加させ、トランザクション処理可能な状態とするには、新規サーバが事前にネットワーク上の全てのデータをコピーすることが必要となる。
しかし、ネットワーク上のデータが大容量である場合、全てのデータのコピーが完了するまでに時間を要する。
【0011】
そこで、分散コンピューティングシステムにおけるデータのコピー時間を短縮する方法としては、例えば、特許文献1の技術が知られている。この特許文献1においては、新たなサーバが全データ(全ファイル)を予め取得するのではなく、アクセスがあったタイミングでオンデマンドに、ストレージシステムが既存サーバから該当データを取得する技術が開示されている。
【先行技術文献】
【非特許文献】
【0012】
【非特許文献1】“A Peer−to−Peer Electronic Cash System”, [online]、[平成29年3月31日検索]、インターネット<URL:https://bitcoin.org/bitcoin.pdf>
【非特許文献2】“Ethereum White Paper”, [online]、[平成29年3月31日検索]、インターネット<URL:https://github.com/ethereum/wiki/wiki/[English]−White−Paper>
【非特許文献3】“Hyperledger Fabric”, [online]、[平成31年3月31日検索]、インターネット<URL:http://hyperledger−fabric.readthedocs.io/en/latest/>
【特許文献】
【0013】
【特許文献1】特表2013−532314号公報
【発明の概要】
【発明が解決しようとする課題】
【0014】
上述の特許文献1における技術は、ある1つのデータを1つのコピー元から取得するものである。そのため、当該技術を、信頼しうるものとして実装、運用するには、コピー元サーバが正しいデータを返す場合に限られる。
【0015】
その理由は、分散台帳ノードを使う環境では、複数組織に跨って分散台帳ノードが構築され、コピー元の分散台帳ノードが、信頼できるとは限らない組織により運用されるケースが存在しうるためである。その場合、コピー時に悪意を持って誤ったデータが送付されるケースが起こりうる。
【0016】
こうした、コピー元の組織が信頼できるとは限らない場合の対処方法として、全ての分散台帳ノードから一時的に全データをコピーし、一時的にコピーしたデータ同士が同一かどうか比較する事が考えられる。
【0017】
しかしながら、データ量が膨大になる場合は、コピーに時間がかかる、膨大な一時コピー場所が必要になる、他の分散台帳ノードやネットワークの負荷を増大させトランザクション処理に悪影響を与える、といった別の課題が生じる。
そこで本発明の目的は、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことを可能とする技術を提供することにある。
【課題を解決するための手段】
【0018】
上記課題を解決する本発明の分散台帳システムの運用管理方法は、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーするに際し、前記第一の分散台帳ノードが、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する、ことを特徴とする。
【0019】
また、本発明の分散台帳システムの運用管理システムは、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードであって、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する分散台帳ノードを含む、ことを特徴とする。
【0020】
また、本発明の分散台帳システムの運用管理プログラムは、分散台帳システムにおける、第一の分散台帳ノードが保持する分散台帳の内容が、第二の分散台帳ノード群が保持する分散台帳の内容よりも少ない場合に、当該第二の分散台帳ノード群が持つ分散台帳から、前記第一の分散台帳ノードが持つ分散台帳にデータをコピーする、前記第一の分散台帳ノードに、前記分散台帳システムにおいてコピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を、分散台帳ノードに関する所定属性に関して予め定めた所定基準に基づき決定する処理を、実行させることを特徴とする。
【発明の効果】
【0021】
本発明によれば、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことが可能となる。
【図面の簡単な説明】
【0022】
図1】本実施形態における分散台帳システムの運用管理方法における基本概念を示す図である。
図2】本実施形態における運用管理システムを模式的に示す図である。
図3】本実施形態における分散台帳ノードの物理的な構成を示すブロック図である。
図4】本実施形態における分散台帳上のブロックチェーンのデータ構造例を示す図である。
図5】本実施形態における分散台帳上のステート情報のデータ構造例を示す図である。
図6】本実施形態における、参加メンバー管理情報のデータ構造を示す図である。
図7】本実施形態におけるビジネスネットワークのメンバー新規登録処理の例を示すフロー図である。
図8】本実施形態における、トランザクション処理例を示すフロー図である。
図9】本実施形態における、新規分散処理ノード追加時に分散台帳をコピーする処理例を示すフロー図である。
図10】本実施形態における、複数の分散台帳からコピーしてきたブロックチェーンの内容が正しいか検証する処理例を示すフロー図である。
図11】本実施形態における、分散処理ノードからブロックをコピーする際のブロックの分割方法の例を示す。
図12】本実施形態における、分散処理ノードからブロックをコピーする際のブロックの分割方法の例を示す。
【発明を実施するための形態】
【0023】
−−−実施例1−−−
<運用管理方法の基本概念>
【0024】
図1に本実施形態における分散台帳システム10の運用管理方法における基本概念を示す。本実施形態では、peer4を新規の分散台帳ノード3(すなわち第一の分散台帳ノード)として追加する場合を考える。
【0025】
この場合、新規の分散台帳ノード3におけるコピー箇所決定部50が、保証方針54および参加メンバー管理情報38を元に、分散台帳システム10に含まれるどの分散台帳ノード3(すなわち第二の分散台帳ノード群)から、ブロックチェーン372中のどのブロック群を取得するか決定することとなる。分散台帳システム10は、運用管理システムであるとも言える。
【0026】
また、上述の新規の分散台帳ノード3におけるコピー処理部51は、コピー箇所決定部50で決定したコピー方針に従い、それぞれの分散台帳ノード3(第二の分散台帳ノード群)から、ブロック群を取得し、コピーバッファ53に置く。
【0027】
また、上述の新規の分散台帳ノード3における同一性確認部52は、複数の分散台帳ノード3(第二の分散台帳ノード群)から取得した、同一箇所のブロックの内容が同一であるか比較、検証する。同一性確認部52は、この検証の結果、各ブロックの内容が同一であると判明した場合、コピーバッファ53からブロック531をコピーして、ブロックチェーン372を構築する。
<運用管理システムの構成例>
【0028】
続いて、上述の基本概念を実装するコンピュータシステム、すなわち運用管理システム10の構成例について説明する。図2は、実施例1における運用管理システム10を模式的に示す図である。
【0029】
例示する運用管理システム10は、1台以上の分散台帳ノード3、1台以上のクライアントノード4によって構成される(分散台帳システムとも言える)。これらの機器は、物理的な通信回線2を通してネットワーク1に接続される。
【0030】
上述の構成のうち分散台帳ノード3は、コンセンサス管理部31、スマートコントラクト実行/管理部32(以下、SC実行/管理部32とも称する)、メンバー管理部33、トランザクション管理部34、分散台帳37、参加メンバー管理情報38、コピー箇所決定部50、コピー処理部51、同一性確認部52、コピーバッファ53、および保証方針54によって構成される。
【0031】
こうした構成を備える分散台帳ノード3は、トランザクション管理部34の機能によりTXを受け付けて、コンセンサス管理部31の機能によって、他のノードとの間でTXを受け入れてよいかの合意形成を行う。
【0032】
また、この分散台帳ノード3は、上述の合意形成がなされたら、SC実行/管理部32の機能を介して、SCのデプロイ、デプロイ済みのSCに対する実行を行い、TXの履歴とその実行結果を分散台帳37に記録する。
【0033】
なお、分散台帳ノード3の各間の通信は、コンセンサス管理部31の機能によって行う。また、分散台帳ノード3のトランザクション管理部34は、クライアントノード4等の各ノードからの要求に対して、TXを受け付けたり、TXの履歴情報を取得・閲覧したりする機能/インタフェースを提供する。
【0034】
また、分散台帳ノード3のメンバー管理部33は、ビジネスネットワークに参加するメンバーの新規発行や認証機能を提供する。こうしたメンバー管理では、秘密鍵と公開鍵のペアを用いて、参加メンバーの認証やTXへの署名、SC実行権限の制御等を行うことを想定する。なお、メンバー管理に関する鍵情報は、参加メンバー管理情報38上に格納・管理される。
【0035】
また、トランザクション管理部34は、TXを受け付けた際に、適宜、メンバー管理部33の機能を介して、TXの発行者が権限を持った正しい参加者かどうかを確認するが、こうした構成自体は適宜な公知技術を採用すればよく、詳細説明は省略する。
【0036】
また、分散台帳37では、スマートコントラクト(SC)371およびブロックチェーン(BC)372、ステート情報373を格納・管理する。そのデータ構造としては、本実施例では、TXの履歴をBCとして、TXの実行結果に基づくステート情報をテーブル上で保持することを想定する。
一方、クライアントノード4は、トランザクション発行部35および業務アプリ41、によって構成される。
【0037】
SCの利用者もしくは提供者は、クライアントノード4のトランザクション発行部35を介して各種TXを発行し、これをそれぞれの分散台帳ノード3に対して送信する。なお、TXには発行者情報を付与するが、この情報としては参加メンバー管理情報38によって発行された認証情報(秘密鍵)を利用する。
【0038】
また、業務アプリ41は、トランザクション発行部35を介して、スマートコントラクト371に関するTXを発行することで、業務処理を実行/管理するアプリである。
【0039】
本実施例では、例えば、それぞれ異なる主体によって管理される、複数台の分散台帳ノード3の存在を想定する。上述の主体は、例えば、事業者、組織、ベンダである。同様に、クライアントノード4も複数台存在し、複数のSC利用者がそれぞれ別のクライアントノード4を利用することを想定する。
なお、クライアントノード4に関しては、TXに付与する認証情報をユーザ毎に切り替えることにより、複数のSC利用者が共用することも可能である。
<分散台帳ノードの物理的構成>
【0040】
続いて、実施例1における分散台帳ノード3の物理的な構成について説明する。図3は、実施例1における分散台帳ノード3の物理的な構成例を示すブロック図である。
【0041】
本実施例における分散台帳ノード3は、インタフェース(I/F)100、演算装置た
るプロセッサ101、および、記憶装置たるメモリ102を備える計算機である。なお、これらI/F100、プロセッサ101、および、メモリ102は、データバス103によって接続されている。
【0042】
このような構成を備える分散台帳ノード3は、I/F100を介して、ネットワーク1と通信する。プロセッサ101は、CPU等の演算装置である。メモリ102は、プログラムおよびデータを保持するための記憶装置である。プロセッサ101は、メモリ102からデータバス103を介してプログラム110(コピー箇所決定部50、コピー処理部51、および同一性確認部52に対応したプログラム)を読み出し、実行することで必要な機能を実装する。
<分散台帳の構成>
【0043】
次に、分散台帳37の構成例について説明する。図4および図5は、分散台帳37に格納するデータ構造の一例を示す図である。このうち図4は、分散台帳37上で管理するデータ構造の一つであるBC372の例を示す図である。
【0044】
BCを用いた分散台帳管理では、複数のTXをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。こうした構成において前段のブロックの値が1ビットでも変わると、後続の全ブロックのハッシュ値が変化する。そのため改ざんを困難にすることができる。なお、本実施例では説明をシンプルにするために、1つのTXにつき1ブロックとするが、本発明は、複数TXをまとめて1ブロックに格納した場合にも適用可能である。
図4におけるブロック3721、ブロック3722、およびブロック3713は、一連のブロックの連なり、すなわちBCとなる。
【0045】
各ブロックは、それぞれSCのデプロイ、実行いずれかのTX情報を含む。また各ブロックはそのブロックの生成に関するタイムスタンプ情報を含む。さらに各ブロックは、前ブロックのハッシュ値を含み、後述のステート情報から生成したハッシュ値を含む。
上記のようなデータ構造により、SCのデプロイ、実行TXがBCの中でデータの連鎖として管理されることとなる。
【0046】
こうしたBCを構成するブロックのうちブロック3721は、SC371のデプロイTXを格納したブロックの一例である。この例では、貨物輸送に関するビジネスコントラクトの例を示している。
【0047】
本実施例のデプロイTXは、コントラクトを一意に識別するコントラクトID、コントラクトの実態(例えば実行可能なバイナリ)を含む。また、コントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。
【0048】
さらに、デプロイ時に指定した入力引数にしたがって決めたパラメータ(例えばコントラクトの利用者や各種定義情報等)であるコントラクトメタ定義を含む。また、このデプロイTXの発行元、すなわち、提供者を識別するためのID情報(発行者ID)を含む。
【0049】
さらに発行元とデータに改ざんが無いことを検証するために用いる電子署名を含む。この電子署名はメンバー管理部33が発行した各ネットワーク参加メンバー(すなわちSC提供者や利用者)の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。
【0050】
また、ブロック3722、ブロック3723はSC371の実行TXを格納したブロックの一例である。本実施例の実行TXは、呼び出し対象となるコントラクトのコントラク
トID、呼び出し対象となるコントラクトの関数名と入力する引数の情報を含む。
【0051】
さらにこの本番実行TXの発行元、すなわち、利用者を識別するためのID情報(実行者ID)を含む。さらに発行元とデータに改ざんがないことを検証するために用いる利用者署名を含む。なお、発行元だけでなく、合意形成に関わったネットワーク参加者の情報も管理/保持してもよい。
【0052】
図5は、本実施例の分散台帳37上で管理するステート情報373を示す図である。BCを用いた分散台帳管理では、通常、(最新の)ステート(例えば、仮想通貨の場合にはアカウントの残高)を取得するためには、BCを辿らなければならない。これでは処理効率が悪いため、BCとは別に、最新のステート情報をキャッシュしておく方法が存在する(非特許文献3等)。よって本実施例でも最新のステート情報を保持することを想定する。
本実施例では、コントラクト毎にステートのデータ領域が用意されることとする。ステート情報は、コントラクトIDとそのコントラクトの実態を保持する。
【0053】
これにより、分散台帳ノード3のSC実行/管理部32は、コントラクトIDをキーにして、コントラクトの実態を取得して実行することができる。また、ステート情報はSCの実行結果を保持するための内部テーブルを備える。TXが実行される度にこの内部テーブルの内容を更新する。
【0054】
図6は、本実施例における参加メンバー管理情報38の一例である。参加メンバー管理情報38は表形式となっており、一つ以上の行から成る。全ての行は、2つの列を含んでいる。ここで2つの列とは、組織名381、分散台帳ノード名382である。
【0055】
参加メンバー管理情報38の各行は、これ以外の不図示の列を含んでいても良いし、幾つかの列が存在しなくても良い。参加メンバー管理情報38に格納された情報は、システム管理者などが手作業で作成しても、あるいは何らかのツールやユーティリティを用いて作成しても良い。
【0056】
こうした参加メンバー管理情報38には、分散台帳ノード3を運営する組織の名称381と、その組織が持つ分散台帳ノードの名称302情報が格納されている。
<フロー例:メンバー新規登録>
【0057】
図7は、ビジネスネットワークに参加するメンバーの新規登録処理の例を示すフローチャートである。この場合、分散台帳ノード3のメンバー管理部33は、クライアントノード4等の他ノードからメンバー登録要求を受け付ける(S101)。このメンバー登録要求には、要求メンバーを一意に識別するメンバーIDが含まれることとする。
【0058】
続いて、メンバー管理部33は、適宜なアルゴリズムにて秘密鍵と公開鍵の組を生成し、この組みを、上述のステップS101で受け取ったメンバーIDと紐付ける(S102)。
【0059】
次に、メンバー管理部33は、上述のステップS101で得た、新規登録対象となるメンバーIDと、上述のステップS102で生成した公開鍵とを、他のノードにブロードキャストする(S103)。
ここでブロードキャストされたメンバーIDおよび公開鍵の情報は、各ノード上で参加メンバー管理情報38として保管する。
【0060】
さらに、メンバー管理部33は、メンバー登録要求を行ったノード(S101の契機と
なったノード)に対し、ステップS102で生成した秘密鍵を返す(S104)。一方、この秘密鍵を受け取ったノードは、参加メンバー管理情報38に自身の秘密鍵として保管する。
【0061】
本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、ネットワーク参加メンバーの認証やTXへの署名、SC実行権限の制御等を行うことを想定する。
【0062】
具体的には、例えば、クライアントノード4側は、発行された秘密鍵で電子署名したTXを発行し、検証ノード側が公開鍵を用いて電子署名を検証することで、本人確認を実現できる。
【0063】
なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法、鍵とIDを紐付ける手法については、公知または周知の技術を適用すれば良い。よって本実施例1では詳述しない。また本実施例では、メンバー管理部33の機能を分散台帳ノード3中に機能として示したが、外部にメンバー管理専用のノードを立て、そのノードがメンバー管理部33と同等の機能を提供するとしてもよい。
<フロー例:TX実行処理>
【0064】
続いて、TX実行処理について説明する。図8は、TX実行処理の例を示すフローチャートである。この場合、分散台帳ノード3のトランザクション管理部34が、クライアントノード4等のTX発行元からTXを受け取り(S201)、これをコンセンサス管理部31に渡すことで実行処理を行う。
【0065】
コンセンサス管理部31は、他の分散台帳ノード3との間で、受け取ったTXを実行してよいか、ブロックとしてBCの末尾に追加してよいかの合意形成処理を行う(S204)。
具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。ここでは保証方針54に従い、合意形成するものとする。
【0066】
上述の保証方針54を用いた合意形成を簡単に説明すると、コンセンサス管理部31は、保証条件54で指定されたそれぞれの組織に対して、参加メンバー情報38を参照して分散台帳ノード3を一つ選択する。
【0067】
また、当該分散台帳ノード3上で、TXに対する署名検証を行って、改ざんされていないことやTXの内容の正当性を確認し、その確認結果をコンセンサス管理部31に送付する。
【0068】
コンセンサス管理部31は、それぞれの組織が合意したか、或いは却下したかという結果を使って、保証方針54に従った論理演算を行い、合意形成が完了したか却下されたかを判断する(S210)。保証方針54を使った合意形成の方法は後述する。
上述の判断の結果、合意形成が却下された場合(S210:N)、コンセンサス管理部31は、クライアントにエラーを返し(S211)処理を終了する。
【0069】
一方、合意形成が完了した場合(S210:Y)、コンセンサス管理部31は、SC実行/管理部32を介して、SCを実行して分散台帳37の内容を更新する(S208)。
【0070】
具体的には、実行TX内で指定されたコントラクトIDを持つSC(登録済みであることを前提とする)に対して、実行TX内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳37の内容を更新する。また、コンセンサス管理部31は、実行結果に基づいて、本コントラクトに関するステート情報502を更
新し、BCの末尾のブロックとして実行TXを追加する。
最後に、コンセンサス管理部31は、この実行TXの実行結果(例えば、関数の戻り値)をTX発行元に返し(S209)、処理を終了する。
【0071】
ここで、上述の保証方針54を使った合意形成方法について説明する。保証方針54は、Hypeledger Fabric(非特許文献3等)で使われるEndorsement Poicyに相当する。保証方針54は、条件文と条件要素からなる。また、保証方針54は、合意形成時に真または偽として評価される。
【0072】
保証方針54における条件文は、Or/And/OutOfのいずれかである。ただし、これら以外の条件文を用いても良い。なお、条件分がOutOfの場合は、追加で一つの引数kを持つ。追加の引数kは条件要素ではなく条件文の一部とみなす。
【0073】
また、保証方針54における条件要素は、組織名400または条件文からなる。合意形成とともに、条件要素は真または偽で評価される。条件要素が組織名400の場合、当該組織が合意形成で合意したならば、真と評価される。また、合意形成で却下したときは偽と評価される。合意も却下もまだしていないときは、合意または却下の結果が出るまで当該条件要素は未評価となる。
【0074】
上述の条件要素が条件文の場合、当該条件文の値(真または偽)がそのまま評価される。条件文がOrの場合、少なくとも一つの条件要素が真であれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
【0075】
また、条件文がAndの場合、全ての条件要素が真と評価されるのであれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
【0076】
また、条件文がOutOfの場合、少なくともk個の条件要素が真と評価されていれば、条件文は真と評価される。未評価の条件要素があれば未評価となる。それ以外のときは偽と評価される。
こうした保証方針54の例と、その評価結果の例を以下に示す。ここでOrg1,Org2,Org3は、図1で示した組織400であるとする。
・Or(Org1,Org2,Org3):Org1,Org2,Org3の少なくとも1つの組織の分散台帳ノード3が合意したときに、真と評価される。
・And(Org1,Org2,Org3):Org1,Org2,Org3の全ての組織の分散台帳ノード3が合意したときに、真と評価される。
【0077】
・OutOf(2,Org1,Org2,Org3):Org1,Org2,Org3のうち、少なくとも2つの組織の分散台帳ノード3が合意したときに、真と評価される。
【0078】
・Or(And(Org1,Org2),Org3):Org1,Org2の両方が、またはOrg3が、またはOrg1、Org2、Org3の全てが合意したときに真と評価される。
<フロー例:コピー処理>
【0079】
続いて、新規分散処理ノード3を追加する際に、複数の既存の分散処理ノード3から、当該新規の分散処理ノード3に分散台帳372をコピーする処理について説明する。図9は、分散台帳をコピーする処理例を示すフロー図である。
【0080】
この場合、例えば新規の分散台帳ノード3におけるコピー箇所決定部50は、保証方針
54および参加メンバー管理情報38に基づき、コピー元となる分散台帳ノード3を決定する(S301)。
【0081】
図1の場合を例に説明すると、保証方針54より、org1,org2,org3の各組織が運用する分散台帳ノード3から、それぞれブロックチェーン372をコピーする。ここでは、org1の分散台帳ノード3であるpeer1、org2の分散台帳ノード3であるpeer21、peer22、org3の分散台帳ノード3であるpeer3からコピーする。
【0082】
一つの組織に複数の分散台帳ノード3があるときは、1ないし全ての分散台帳ノード3からコピーする。例えば、CPU負荷やI/O負荷、ネットワーク帯域使用量が一番少ない分散台帳ノード3からコピーしても良いし、CPU負荷やI/O負荷、ネットワーク帯域使用量の幾つかが、指定された閾値以下となる分散台帳うノード3からコピーしても良いし、全ての分散台帳ノード3に分散させて分散台帳ノード3からコピーしても良い。
なお、図8の合意形成で使う保証方針54と、図9のコピー元分散台帳ノード3の決定に使われる保証方針54は、同一であっても、異なる物であっても良い。
【0083】
続いて、コピー箇所決定部50は、ステップS301で決定した分散台帳ノード3から、個々のブロックを識別する識別子を取得する(S302)。識別子としては、各ブロックのタイムスタンプや前ブロックハッシュ値、ステートハッシュ値、当該ブロックのハッシュ値、それらの組み合わせが考えられる。
【0084】
続いて、コピー箇所決定部50は、ブロックチェーン372のどの箇所を、どこの組織400から取得するか決定する(S303)。この処理は図10で詳しく説明する。この処理には、ブロックの識別子と、保証方針54を引数として渡す。
【0085】
続いて、コピー処理部は、ステップS303で決まった取得方針に従い、S301で決定した分散台帳ノート3からブロックを取得し、コピーバッファ53にコピーする(S304)。
【0086】
上述のコピー後に、同一性確認部52は、異なる組織にある分散台帳ノード3から取得した、同じ識別子を持つ複数のブロックのデータが同一であるか確認する(S305)。ある識別子を持ったブロックが高々一つしかないときは比較しない。
【0087】
なお、全てのブロックのコピーが終了してから、上述のステップS305を処理しても良いし、同一ブロックの情報を全ての分散台帳ノード3から取得が完了した時点で、当該ブロックの同一性を確認しても良い。
【0088】
上述のステップS305の結果、同一の内容でないブロックがある場合(S306:Y)、同一性確認部52は、コピー元の分散台帳ノード3がデータが改竄している可能性があるため、図9の処理を呼び出した管理者(のクライアントノード4など)にエラーを返し(S309)処理を終了する。
【0089】
ただし、ある識別子を持つブロックを対象に、同じ内容を持つブロックの数が一番多いものを、正しいブロックの値とみなし、S307に遷移し処理を継続しても良い。
【0090】
一方、上述のステップS305の結果、同じ識別子を持つブロックの内容が全て同一であった場合(S306:N)、例えば、コピー処理部51は、コピーバッファ53にあるブロックから、分散台帳372を構築する(S307)。
【0091】
続いて、コピー処理部51は、ステップS307で分散台帳372を構築した結果、ブロック同士の接続関係が正しいか、前ブロックハッシュ値やタイムスタンプを元に検証する(S308)。
【0092】
上述の検証の結果、接続関係が正しい場合(S308:Y)、コピー処理部51は、処理をS310に進める。一方、接続関係に誤りがある場合(S308:N)、コピー処理部51は、エラーとみなして処理をS309に遷移させる(S309)。
最後に、例えば、コピー処理部51は、クライアントノード4から、新規追加する分散台帳3へのアクセスを許可する(S310)
<フロー例:取得方法決定>
【0093】
続いて、分散台帳372をコピーする際に、コピー元となる分散台帳372について、そのどの部分を、どの組織400にある、既存の分散処理ノード3から取得するのか決める処理について説明する。図10は、取得方法決定の処理例を示すフロー図である。
【0094】
この場合、コピー箇所決定部50は、図10の処理が呼び出されたときの引数から保証方針54を取得し、その条件文を変数OPに、また条件要素を変数Pに格納する。また、条件要素Pの要素数を変数nに格納する(S401)。
続いて、コピー箇所決定部50は、上述の引数に渡された、ブロックチェーンを構成する個々のブロックの識別子をn個に分割し、変数Cに格納する。
【0095】
この分割は、どのような分割方法で行っても良いが、本実施例では、ブロックチェーンに接続されているブロックの順序を維持したまま、個々の分割要素が、(ブロックの全体数÷n)になるよう切断する方式を例示する。
【0096】
なお、分割した要素の要素数は等しくなくても良い。割り算の余りがあるときは、分割したいずれかの要素の要素数に+1しても良い。ブロックの数ではなく、ブロックのサイズを元に、サイズがほぼ等しくなるように分割しても良い。変数Cの各要素に、異なる組織が署名したブロックが数多く入るように分割しても良い。変数Cの各要素に、なるべく少ない組織が署名したブロックが入るように分割しても良い。
【0097】
続いて、コピー箇所決定部50は、上述の条件文を判定する。条件文OPがOrの場合(S403:Y)、コピー箇所決定部50は、Pの各要素に、Cの要素をそれぞれ対応させ、変数Rに格納する(S404)。
【0098】
それぞれの要素に対応させる方法は、どのような方法でも良い。例えばランダムに対応させても良いし、各組織が持つ分散台帳ノード3の数や総合性能、最大性能、これまでの性能統計情報、各組織400の分散台帳ノード3へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、対応方法を決めても良い。
【0099】
一方、条件文OPがAndの場合(S405:Y)、コピー箇所決定部50は、Pの各要素に対して、引数で指定されたブロックチェーンの全要素を対応させ、変数Rに格納する(S406)。
【0100】
なお、Pの要素数が、例えば10以上と多いときには、何らかの条件を元にPの数を減らしても良い。例えばランダムに減らしても良いし、各組織が持つ分散台帳ノード3の数や総合性能、最大性能、これまでの性能統計情報、各組織400の分散台帳ノード3へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、減らす組織を決めても良い。
【0101】
他方、条件文OPがOutOf(k,...)の場合(S407:Y)、コピー箇所決定部50は、変数Cからk個の要素を取り出す全ての組み合わせを列挙し、変数Uに格納する(S408)。
【0102】
例えばOutOf(2,A,B,C)のときは、(A,B,C)の3要素中の2要素を取り出す組み合わせを列挙するので、結果は(A,B),(B,C),(A,C)の3つとなる。
【0103】
続けて、コピー箇所決定部50は、Uの各要素に、Cの要素をそれぞれ対応させ、変数Rに格納する(S404)。それぞれの要素に対応させる方法は、どのような方法でも良い。例えばランダムに対応させても良いし、各組織が持つ分散台帳ノード3の数や総合性能、最大性能、これまでの性能統計情報、各組織400の分散台帳ノード3へ接続するネットワーク帯域の余裕量、分割したブロックの要素数、分割したブロックのサイズなどをもとに、対応方法を決めても良い。
上述の判定の結果、いずれの条件文にも合致しなければ(S407:N)、コピー箇所決定部50は、処理を終了する。
【0104】
一方、いずれかの条件文に合致した場合(S403:Y、S405:Y、S407:Y)、コピー箇所決定部50は、参加メンバー管理情報38を元に、各組織400が持つ分散台帳ノード3の数に応じて、ブロックを更に分割し、分散台帳ノード3の名称と、分割したブロックを対応付けて変数Rに格納する(S410)。
また、コピー箇所決定部50は、上述の変数Rに含まれる要素に条件文が含まれていなければ(S411:N)、処理を終了する。
【0105】
一方、コピー箇所決定部50は、上述の変数Rに含まれる要素に条件文が含まれている場合(S411:Y)、当該条件文を解析するために、再帰的に図10の処理を呼び出し(S412)、その結果を変数Rに追記し(S413)、処理を終了する。
<分散台帳の分割形態について>
【0106】
続いて、図10の取得方法の決定処理により、分散台帳372がどのように分割され、ある分割箇所のデータをどのノードから取得するかを決めた具体例について説明する。図11図12は、分散台帳の分割方法の具体例を示す図である。
【0107】
図11において、12個のブロック900から成る分散台帳ノード372を、図6の参加メンバー管理情報38と保証方針54を元に分割した例が、分割形態910、920、930、940である。
【0108】
また、こうした分割形態における、保証方針911、921、931、941を元に、各組織が持つ分散台帳ノード372ごとに分割したのが、ブロック912、922、932、942である。
【0109】
このうち分割形態910では、条件文がOrであるため、各組織から均等な数のブロックを取得する。組織Org2には分散台帳ノード3が2つあるため、peer21とpeer22に分けて取得する。
【0110】
また、分割形態920では、条件文がAndであるため、各組織から同じ数のブロックを取得する。組織Org2には分散台帳ノード3が2つあるため、peer21とpeer22に分けて取得する。
【0111】
また、分割形態930では、条件文がOutOf(2であるため、ブロック全体を3分割し、各組織から分割したものうち2つを取得する。組織Org2には分散台帳ノード3が2つあるため、peer21とpeer22に分けて取得する。
【0112】
なお、OutOfの条件は、AndとOrの組み合わせに変換できるため、保証方針54の内容をAndとOrの組み合わせに変換しても良い。例えば930の内容は、Or(And(org1,org2),And(org2,org3),And(org1,org3)と同等である。
【0113】
また、分割形態940では、OrとAndの複合条件であるため、ブロックを2分割し、前半部分を組織org1と組織or2から重複して取得し、後半を組織or3から取得する。組織Org2には分散台帳ノード3が2つあるため、peer21とpeer22に分けて取得する。
以上の処理により、新規の分散台帳ノード3の追加処理が高速化され、当該新規の分散台帳ノード3が使用可能になるまでの時間を短縮できる。
−−−実施例2−−−
【0114】
実施例2では、新たに追加した分散台帳ノード3に、実施例1の処理によるコピー処理が終了する前に、新たに追加した分散台帳ノード3を使用可能するための実施形態について説明する。基本処理は実施例1と同じである。
【0115】
図9のフローにおけるステップS310での、クライアントノード4から、新規追加する分散台帳3へのアクセスを許可する処理を、図8のフローにおけるステップS201より先に実行する。
【0116】
そこで、図9の処理を実行中、トランザクション管理部34に対してクライアントノード4からブロックへの参照要求があった場合、コピー処理部51は、当該ブロックを既存の分散台帳ノード3から取得し、コピーバッファ53にコピーする。そして、上述のクライアントノード4へ取得したブロックを返す。
これにより、新規の分散台帳ノード3の追加処理中であっても、クライアントノード4からのブロックチェーンへのデータ参照が行えるようになる。
【0117】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【0118】
こうした本実施形態によれば、分散台帳システムにおいて、新規分散台帳ノードを追加した際や、既存分散台帳ノードが故障した際などに、信頼できるとは限らない複数の分散台帳ノードから、正しいデータのコピーを、コピー時間や他の分散処理ノード、ネットワークの負荷を低減しつつ行うことができる。
すなわち、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつ効率的に行うことが可能となる。
【0119】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記分散台帳システムにおける分散台帳ノードが保持するデータの改竄可能性について、所定アルゴリズムで規定した信頼度に基づき判定し、当該判定の結果に応じて、コピー元となる第二の分散台帳ノード群、および当該第二の分散台帳ノード群が含む各分散台帳ノードにおける分散台帳のコピー箇所を決定する、としてもよい。
【0120】
これによれば、各組織の信頼度をもとに、データコピー箇所を決定することが可能とな
る。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【0121】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記信頼度を規定する所定アルゴリズムとして、各分散台帳ノードを所有する各組織の組織名を用いた論理積および論理和による演算を含む論理式を保持し、前記判定の対象となる前記データが、正しい生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を真に設定し、前記判定の対象となる前記データが、誤った生成元たる組織により生成されたことを確認した場合、前記論理式における当該組織名の箇所を偽に設定し、前記設定を経た前記論理式を演算することで、前記改竄可能性について判定する、としてもよい。
【0122】
これによれば、Endorsement Policy等の保証方針に基づき、データコピー方法を効率的に決定できる。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【0123】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記論理式における論理積の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードから分散台帳の内容を取得して、前記取得した前記内容が同一である場合、前記改竄可能性が無いと判定する、としてもよい。
【0124】
これによれば、改竄可能性の有無についてより効率的に確認可能となる。ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【0125】
また、本実施形態の分散台帳運用管理方法において、前記第一の分散台帳ノードが、前記論理式における論理和の項に含まれる組織名を持つ組織群に関し、当該組織群の各分散台帳ノードからコピーすべき分散台帳の内容を分割し、それぞれの前記組織群に、前記分割した分散台帳の内容を対応させ、前記組織群の各分散台帳ノードから、前記対応させた分散台帳の内容を取得する、としてもよい。
【0126】
これによれば、分散台帳ノードを信頼できるとみなしたデータの取得を可能とし、ひいては、既存分散台帳ノードからのブロックチェーンのコピーを、改ざんを防ぎつつより効率的に行うことが可能となる。
【符号の説明】
【0127】
1 ネットワーク
2 通信回線
3 分散台帳ノード
10 運用管理システム
100 I/F
101 プロセッサ
102 メモリ
103 データバス
110 プログラム
31 コンセンサス管理部
311 ネットワークプロトコル部
32 スマートコントラクト実行/管理部(SC実行/管理部)
33 メンバー管理部
34 トランザクション管理部
35 トランザクション発行部
37 分散台帳
371 スマートコントラクト
372 ブロックチェーン
38 参加メンバー管理情報
4 クライアントノード
41 業務アプリ
50 コピー箇所決定部
51 コピー処理部
52 同一性確認部
54 保証方針
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12