特許ウォッチ

公開番号2025155203
公報種別公開特許公報(A)
公開日2025-10-14
出願番号2024058879
出願日2024-04-01
発明の名称ノード、分散台帳システム、分散台帳移管方法、及び分散台帳移管プログラム
出願人京セラ株式会社
代理人弁理士法人キュリーズ
主分類G06F 21/60 20130101AFI20251006BHJP(計算;計数)
要約【課題】分散台帳のプログラムに合意形成の整合性がとれなくなるような仕様変更が生じた場合であっても、ノード数及び取引の連続性を維持することのできるノードを提供する。
【解決手段】ノードは、第1分散台帳を管理する第1分散台帳システムのノードであって、第1分散台帳システムの他の一部のノードと共に第2分散台帳を生成し、第1分散台帳に含まれる複数のブロックの内容を、ブロック高さの低い方から順番に、第2分散台帳のブロックとして合意形成を行って登録する制御部と、第1分散台帳に含まれるすべてのブロックの内容が、第2分散台帳に登録された後、第2分散台帳に登録されたブロックを、第1分散台帳システムの他の残りの一部のノードに同期する通信部と、を備える。
【選択図】図1
特許請求の範囲【請求項１】
第１分散台帳を管理する第１分散台帳システムのノードであって、
前記第１分散台帳システムの他の一部のノードと共に第２分散台帳を生成し、前記第１分散台帳に含まれる複数のブロックの内容を、ブロック高さの低い方から順番に、前記第２分散台帳のブロックとして合意形成を行って登録する制御部と、
前記第１分散台帳に含まれるすべてのブロックの内容が、前記第２分散台帳に登録された後、前記第２分散台帳に登録されたブロックを、前記第１分散台帳システムの他の残りの一部のノードに同期する通信部と、を備えるノード。
続きを表示（約 970 文字）【請求項２】
前記制御部は、前記第２分散台帳の生成から、前記第１分散台帳システムの前記他の残りの一部のノードに対する同期が完了するまでは、前記第２分散台帳に対して、前記第１分散台帳のブロック以外の新規のブロックの提案を行わない、請求項１に記載のノード。
【請求項３】
前記制御部は、前記第２分散台帳のブロックとして未登録である、前記第１分散台帳のブロックが所定数以下、又は前記第１分散台帳のブロック数に対して所定割合以下となった場合に、前記第１分散台帳における新規のブロックの提案を停止し、既に前記第１分散台帳において提案されているブロックについて合意形成して登録する、請求項１に記載のノード。
【請求項４】
前記制御部は、前記第２分散台帳にブロックを登録する前に、前記第１分散台帳に含まれる前記複数のブロックの内容をまとめて１つのブロックとして、前記第１分散台帳に登録するサマリー化処理を行う、請求項１に記載のノード。
【請求項５】
前記他の一部のノードの数は、少なくとも２である、請求項１に記載のノード。
【請求項６】
前記第１分散台帳及び前記第２分散台帳は、コンセンサスアルゴリズムにおいて互いに異なっている、請求項１に記載のノード。
【請求項７】
前記制御部は、前記第１分散台帳システムの前記他の残りの一部のノードに対する同期が完了した後、前記第１分散台帳を削除する、請求項１に記載のノード。
【請求項８】
第１分散台帳において新規のブロックの提案を停止する制御部と、
移管ノードにより、前記第１分散台帳に含まれるすべてのブロックの内容が、第２分散台帳に登録された後、前記移管ノードに保存された前記第２分散台帳を同期する通信部と、を備えるノード。
【請求項９】
前記制御部は、前記新規のブロックの提案を停止した後、既に前記第１分散台帳において提案されているブロックについて合意形成して前記第１分散台帳に書き込む、請求項８に記載のノード。
【請求項１０】
前記制御部は、前記第２分散台帳の同期が完了した後、前記第１分散台帳を削除する、請求項８に記載のノード。
（【請求項１１】以降は省略されています）
発明の詳細な説明【技術分野】
【０００１】
本発明は、ノード、分散台帳システム、分散台帳移管方法、及び分散台帳移管プログラムに関する。
続きを表示（約 1,800 文字）【背景技術】
【０００２】
近年、様々な分野で、分散台帳技術の一種としてのブロックチェーンが活用されている。ブロックチェーンでは、ブロックと呼ばれるデータの単位を生成し、各ブロックのハッシュ値を次のブロックが含むように構成することにより、ブロックを鎖のようにつなげた分散台帳としている。このような分散台帳においては、新規のブロックは、複数のノードによる合意形成により登録され、各ノードによりそれぞれ保管・管理されるため、データの改ざんが難しいと共に、取引の透明性がある台帳となっている。
【０００３】
特許文献１は、各ノードの保有データ量を少なくすることができ、取引履歴の肥大化によるノードの容量逼迫の問題を解消または軽減することができる取引記録システムについて開示している。
【先行技術文献】
【特許文献】
【０００４】
特開２０１８－６７１０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
このようなブロックチェーン等の分散台帳の運用において、例えばセキュリティリスク等の解消のために、コンセンサスアルゴリズムの変更等の大規模な仕様変更が行われる場合がある。このような仕様変更おいて、例えば仕様変更後の合意形成が、仕様変更前の合意形成と互換性がない場合等には、合意形成における整合性がとれなくなるため、仕様変更前の分散台帳（以下「旧分散台帳」という。）とは異なる、新分散台帳が別個に作成されることとなる（ハードフォーク）。
【０００６】
このように新分散台帳が作成された場合には、旧分散台帳から新分散台帳に乗り換えるノードも存在するが、旧分散台帳を継続して使うノードも存在することが考えられ、この場合には、それぞれの分散台帳に参加するノードの数が減少してしまうこととなる。また、合意形成における整合性がとれなくなることから、旧分散台帳と新分散台帳とで取引の連続性がなくなってしまうことが考えられる。このような分散台帳に参加するノード数の減少や取引の連続性がなくなることは、分散台帳に記録される資産価値の低下及び分散台帳自体の信用度の低下につながる恐れがある。
【０００７】
本発明は上記事情に鑑みてなされたものであり、分散台帳のプログラムに合意形成の整合性がとれなくなるような仕様変更が生じた場合であっても、ノード数及び取引の連続性を維持することのできる、ノード、分散台帳システム、分散台帳移管方法、及び分散台帳移管プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本開示のノードは、第１分散台帳を管理する第１分散台帳システムのノードであって、前記第１分散台帳システムの他の一部のノードと共に第２分散台帳を生成し、前記第１分散台帳に含まれる複数のブロックの内容を、ブロック高さの低い方から順番に、前記第２分散台帳のブロックとして合意形成を行って登録する制御部と、前記第１分散台帳に含まれるすべてのブロックの内容が、前記第２分散台帳に登録された後、前記第２分散台帳に登録されたブロックを、前記第１分散台帳システムの他の残りの一部のノードに同期する通信部と、を備えるノードである。
【０００９】
本開示のノードは、第１分散台帳において新規のブロックの提案を停止する制御部と、移管ノードにより、前記第１分散台帳に含まれるすべてのブロックの内容が、第２分散台帳に登録された後、前記移管ノードに保存された前記第２分散台帳を同期する通信部と、を備えるノードである。
【００１０】
本開示の分散台帳システムは、第１分散台帳を管理する第１分散台帳システムと、前記第１分散台帳システムの複数のノードから選択された複数の移管ノードにより生成される第２分散台帳を管理する第２分散台帳システムと、を備え、前記複数の移管ノードは、前記第１分散台帳に含まれる複数のブロックの内容を、ブロック高さの低い方から順番に、前記第２分散台帳のブロックとして合意形成を行って登録し、前記第１分散台帳に含まれるすべてのブロックの内容が、前記第２分散台帳に登録された後、前記第１分散台帳システムのノードのうち、前記移管ノード以外のノードである非移管ノードは、前記移管ノードに保存された前記第２分散台帳を同期する分散台帳システムである。
（【００１１】以降は省略されています）

関連特許