特許ウォッチ

公開番号2025155201
公報種別公開特許公報(A)
公開日2025-10-14
出願番号2024058875
出願日2024-04-01
発明の名称ノード、分散台帳管理方法、分散台帳プログラム及び分散台帳システム
出願人京セラ株式会社
代理人弁理士法人キュリーズ
主分類H04L 9/32 20060101AFI20251006BHJP(電気通信技術)
要約【課題】分散台帳のデータサイズの増加を抑制する、ノードを提供する。
【解決手段】ノードは、分散台帳を管理する分散台帳システムのノードであって、保持している分散台帳のブロックの一つである削除対象ブロックについて、他のノードにおける保持の状況を確認し、削除対象ブロックがブロック削除条件を満たす場合にブロックを削除し、分散台帳において各ブロックを保持しているノードについて示すブロック保持ノードリストを作成又は更新する制御部と、他のノードに対して削除対象ブロックを削除した旨の報告であるブロック削除報告を通知する通信部と、を備える。
【選択図】図1
特許請求の範囲【請求項１】
分散台帳を管理する分散台帳システムのノードであって、
保持している前記分散台帳のブロックの一つである削除対象ブロックについて、他のノードにおける保持の状況を確認し、前記削除対象ブロックがブロック削除条件を満たす場合にブロックを削除し、前記分散台帳において各ブロックを保持しているノードについて示すブロック保持ノードリストを作成又は更新する制御部と、
前記他のノードに対して前記削除対象ブロックを削除した旨の報告であるブロック削除報告を通知する通信部と、を備えるノード。
続きを表示（約 1,600 文字）【請求項２】
前記ブロック削除条件は、前記削除対象ブロックを保持する他のノードの数が、一のブロックについて保持するノードの最低数である最低保持ノード数以上である、請求項１に記載のノード。
【請求項３】
前記削除対象ブロックについての前記保持の状況の確認は、前記通信部が、前記分散台帳システムの各ノードに対して、前記削除対象ブロックを保持しているかどうかの問合せを送信することにより行う、請求項１に記載のノード。
【請求項４】
前記ブロック保持ノードリストは、自身が保持しているブロック及び保持していないブロックの両方について記載され、
前記削除対象ブロックについての前記保持の状況の確認は、前記ブロック保持ノードリストの確認により行う、請求項１に記載のノード。
【請求項５】
前記通信部は、前記保持の状況を確認する際に、前記削除対象ブロックを保持する前記他のノードから前記削除対象ブロックを受信し、
前記制御部は、受信した前記削除対象ブロックが、保持している前記削除対象ブロックと一致するかどうかを検証する、請求項１に記載のノード。
【請求項６】
前記制御部は、前記ブロック削除報告を受信したときに、前記ブロック削除報告の内容に基づいて前記ブロック保持ノードリストを更新する、請求項１に記載のノード。
【請求項７】
前記通信部は、
自身が保持していないブロックである不保持ブロックよりブロック高さが１大きいブロックに保存された前記不保持ブロックのハッシュ値を、前記不保持ブロックを保持するノードである保持ノードに対してブロック検証要求として送信し、
前記不保持ブロックにハッシュ関数を適用したハッシュ値の検証結果、及び前記不保持ブロックよりブロック高さが１小さいブロックのハッシュ値を、前記保持ノードからブロック検証応答として受信する、請求項１に記載のノード。
【請求項８】
前記通信部は、
自身が保持していない連続する複数のブロックである連続不保持ブロックよりもブロック高さが１大きいブロックに保存された、前記連続不保持ブロックのうち、最もブロック高さの高いブロックのハッシュ値を、前記連続不保持ブロックを保持するノードである保持ノードに対してブロック検証要求として送信し、
前記連続不保持ブロックのハッシュ値の検証結果、及び前記連続不保持ブロックのうち、最もブロック高さの低いブロックよりブロック高さが１小さいブロックのハッシュ値を前記保持ノードからブロック検証応答として受信する、請求項１に記載のノード。
【請求項９】
検証対象ブロックについてのブロック検証要求をハッシュ値と共に受信した場合に、前記制御部は、
前記検証対象ブロックにハッシュ関数を適用することによりハッシュ値を算出し、受信したハッシュ値と比較して検証結果が肯定的な場合には、前記検証対象ブロックに保存され、前記検証対象ブロックよりブロック高さが１小さいブロックである次ブロックのハッシュ値を取得し、
前記検証対象ブロックが複数である場合には、前記制御部は、前記次ブロックのハッシュ値を算出し、取得した前記次ブロックのハッシュ値と比較して検証し、検証結果が肯定的な場合には、更にブロック高さが１小さい前記次ブロックのハッシュ値を取得することを、ブロック高さが最も小さい前記検証対象ブロックまで繰り返し、
前記通信部は、前記検証対象ブロックの検証結果がすべて肯定的な場合に、前記次ブロックのハッシュ値と共に、肯定的なブロック検証応答を送信する、請求項１に記載のノード。
【請求項１０】
前記制御部は、予め定められた、保存する前記分散台帳の最大サイズに基づいて、前記削除対象ブロックを選択するかどうかを決定する、請求項１に記載のノード。
（【請求項１１】以降は省略されています）
発明の詳細な説明【技術分野】
【０００１】
本発明は、ノード、分散台帳管理方法、分散台帳プログラム及び分散台帳システムに関する。
続きを表示（約 1,600 文字）【背景技術】
【０００２】
近年、様々な分野で、分散台帳技術の一種としてのブロックチェーンが活用されている。ブロックチェーンでは、ブロックと呼ばれるデータの単位を生成し、各ブロックのハッシュ値を次のブロックが含むように構成することにより、ブロックを鎖のようにつなげた分散台帳としている。このような分散台帳においては、新規のブロックは、複数のノードによる合意形成により登録され、各ノードによりそれぞれ保管・管理されるため、データの改ざんが難しいと共に、取引の透明性がある台帳となっている。
【０００３】
特許文献１は、ブロックチェーンのうち特定したブロック群以外のブロックを削除するノードを有する分散台帳システムについて開示している。
【０００４】
特許文献２は、下位ブロックチェーンにおいて、所定時間を経過した場合、又は第１ブロックデータの数が所定の上限数に達した場合、第１ブロックデータを削除することについて開示している。
【先行技術文献】
【特許文献】
【０００５】
特開２０２１－１７４１７０号公報
特開２０２０－１７８２４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
分散台帳システムでは、各ノードが、ブロックを鎖のようにつなげた分散台帳を保存する。しかしながら、ブロックが増え続けた場合には、分散台帳のデータサイズは肥大化し、ノードのストレージ容量をひっ迫する恐れがある。また、ＩｏＴ（Internet Of Things）デバイス等のストレージ容量がそもそも少ないデバイスを分散台帳システムのノードとして利用したい場合等には、保存するデータサイズを抑えたい場合もある。
【０００７】
本発明は上記事情に鑑みてなされたものであり、分散台帳のデータサイズの増加を抑制する、ノード、分散台帳管理方法、分散台帳プログラム及び分散台帳システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本開示のノードは、分散台帳を管理する分散台帳システムのノードであって、保持している前記分散台帳のブロックの一つである削除対象ブロックについて、他のノードにおける保持の状況を確認し、前記削除対象ブロックがブロック削除条件を満たす場合にブロックを削除し、前記分散台帳において各ブロックを保持しているノードについて示すブロック保持ノードリストを作成又は更新する制御部と、前記他のノードに対して前記削除対象ブロックを削除した旨の報告であるブロック削除報告を通知する通信部と、を備えるノードである。
【０００９】
本開示の分散台帳管理方法は、保持している分散台帳のブロックの一つである削除対象ブロックについて、他のノードにおける保持の状況を確認し、前記削除対象ブロックがブロック削除条件を満たす場合にブロックを削除し、前記分散台帳において各ブロックを保持しているノードについて示すブロック保持ノードリストを作成又は更新し、前記他のノードに対して前記削除対象ブロックを削除した旨の報告であるブロック削除報告を通知する分散台帳管理方法である。
【００１０】
本開示の分散台帳プログラムは、保持している分散台帳のブロックの一つである削除対象ブロックについて、他のノードにおける保持の状況を確認する工程と、前記削除対象ブロックがブロック削除条件を満たす場合にブロックを削除する工程と、前記分散台帳において各ブロックを保持しているノードについて示すブロック保持ノードリストを作成又は更新する工程と、前記他のノードに対して前記削除対象ブロックを削除した旨の報告であるブロック削除報告を通知する工程と、をコンピュータに実行させる分散台帳プログラムである。
（【００１１】以降は省略されています）

関連特許