特開 2025-149668 ノード、方法、プログラム及び分散台帳システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025149668

(43)【公開日】2025-10-08

(54)【発明の名称】ノード、方法、プログラム及び分散台帳システム

(51)【国際特許分類】

   H04L 9/08 20060101AFI20251001BHJP

   H04L 9/32 20060101ALI20251001BHJP

【ＦＩ】

H04L9/08 A

H04L9/32 200Z

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2024050444

(22)【出願日】2024-03-26

(71)【出願人】

【識別番号】000006633

【氏名又は名称】京セラ株式会社

(74)【代理人】

【識別番号】110001106

【氏名又は名称】弁理士法人キュリーズ

(72)【発明者】

【氏名】山下 裕之

(72)【発明者】

【氏名】藤澤 將

(72)【発明者】

【氏名】小山 亮

(72)【発明者】

【氏名】須藤 大貴

(72)【発明者】

【氏名】▲高▼橋 良浩

(57)【要約】

【課題】セキュリティを確保しつつ、より利便性を高めたノードを提供する。
【解決手段】分散台帳システムのノードは、自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について秘密共有を行う制御部と、秘密共有を行った自ノード秘密鍵及び他ノード秘密鍵から生成された全体公開鍵を含む、分散台帳システムで発行されたブロックの少なくとも一部について保存する記憶部と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

分散台帳システムのノードであって、
自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う制御部と、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含む、前記分散台帳システムで発行されたブロックの少なくとも一部について保存する記憶部と、を備えるノード。

【請求項2】

前記全体公開鍵は、前記ブロックのブロックヘッダ部又はトランザクションデータ部に含まれる、請求項１に記載のノード。

【請求項3】

自己の公開鍵である自ノード公開鍵について、前記他の複数のノードの一つに対して合意形成のための署名を要求する通信部を更に備え、
前記記憶部は、前記合意形成がなされた前記公開鍵を公開証明書として利用するために保存する、請求項１に記載のノード。

【請求項4】

前記分散台帳システムのシードノードからの前記秘密共有の要求を受信する通信部を更に備える、請求項１に記載のノード。

【請求項5】

前記ブロックの少なくとも一部は、ブロックヘッダ部であり、
前記他の複数のノードの一つに最新の前記ブロックヘッダ部と署名部を要求して、最新の前記ブロックヘッダ部を受信する通信部を更に備え、
前記記憶部は、前記全体公開鍵に基づいて前記署名部を検証し、前記分散台帳システムの正当なノードであると判定した場合に、最新の前記ブロックヘッダ部を保存する、請求項１に記載のノード。

【請求項6】

分散台帳システムの複数のノードのそれぞれに対応する複数の秘密鍵について秘密共有された後に抽出された前記複数の秘密鍵に基づいて生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含む、発行されたブロックを保存する記憶部を備える、ノード。

【請求項7】

自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行い、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する、方法。

【請求項8】

自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う工程と、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する工程と、をコンピュータに実行させるプログラム。

【請求項9】

複数のノードを備え、
前記複数のノードのそれぞれは、
自己の秘密鍵としての自ノード秘密鍵について前記複数のノードにおいて秘密共有を行い、
前記秘密共有を行った前記複数のノードのすべての前記自ノード秘密鍵から全体公開鍵を生成し、
前記全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックを発行する、分散台帳システム。

【請求項10】

前記複数のノードのうちの一つのノードは、自己の公開鍵である自ノード公開鍵について、前記複数のノードの他の一つのノードに対して合意形成のための署名を要求し、
前記一つのノードは、前記合意形成がなされた前記自ノード公開鍵を公開証明書として保存する、請求項９に記載の分散台帳システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ノード、方法、プログラム及び分散台帳システムに関する。

【背景技術】

【0002】

近年、様々な分野で、分散台帳技術の一種としてのブロックチェーンが活用されている。ブロックチェーンでは、ブロックと呼ばれるデータの単位を生成し、各ブロックのハッシュ値を次のブロックが含むように構成することにより、ブロックを鎖のようにつなげた分散台帳としている。このような分散台帳は、原則として各ノードがそれぞれ保管・管理するため、データの改ざんが難しいと共に、取引の透明性がある台帳となっている。

【0003】

特許文献１は、各ノードの保有データ量を少なくすることができ、取引履歴の肥大化によるノードの容量逼迫の問題を解消または軽減することができる取引記録システムについて開示している。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１８－６７１０８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

分散台帳システムは、分散台帳システムに参加しているノードの一部がシステムダウンしている場合でも他のノードによりシステムを継続することができ、可用性が高いという面での利便性がある。しかしながら、例えばノードの公開証明書の認証機関として、第三者の認証機関を利用している場合等には、第三者の認証機関のサーバダウンや認証機関の公開鍵が改ざん等により、分散台帳システムの処理が継続できなくなり、利便性が損なわれる恐れがあった。

【0006】

また、分散台帳システムを構成するノードのうち、ハードウェアリソースが十分でないノードにおいては、例えばすべての台帳を保持せずに、最新のブロックヘッダのみ保持するライトクライアントノード等とすることができる。しかしながら、最新のブロックヘッダの検証においてデータに不整合があった場合等には、データの検証のために、ライトクライアントノードに対して処理能力超える処理負荷が要求される恐れがあり、処理時間の遅延やタイムアウト等により、分散台帳システムの利便性が損なわれる恐れがあった。

【0007】

本開示では上述の事情に鑑みてなされたものであり、セキュリティを確保しつつ、より利便性を高めたノード、方法、プログラム及び分散台帳システムについて開示するものである。

【課題を解決するための手段】

【0008】

本開示のノードは、分散台帳システムのノードであって、自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う制御部と、前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含む、前記分散台帳システムで発行されたブロックの少なくとも一部について保存する記憶部と、を備えるノードである。

【0009】

本開示のノードは、分散台帳システムの複数のノードのそれぞれに対応する複数の秘密鍵について秘密共有された後に抽出された前記複数の秘密鍵に基づいて生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含む、発行されたブロックを保存する記憶部を備えるノードである。

【0010】

本開示の方法は、自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行い、前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する方法である。

【0011】

本開示のプログラムは、自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う工程と、前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する工程と、をコンピュータに実行させるプログラムである。

【0012】

本開示の方法は、自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行い、前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する方法である。

【0013】

本開示の分散台帳システムは、複数のノードを備え、前記複数のノードのそれぞれは、自己の秘密鍵としての自ノード秘密鍵について前記複数のノードにおいて秘密共有を行い、前記秘密共有を行った前記複数のノードのすべての前記自ノード秘密鍵から全体公開鍵を生成し、前記全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックを発行する分散台帳システムである。

【発明の効果】

【0014】

本開示のノード、方法、プログラム及び分散台帳システムによれば、セキュリティを確保しつつ、より利便性を高めることができる。

【図面の簡単な説明】

【0015】

【図1】本開示の一実施形態に係る分散台帳システムの構成例について説明するための図である。

【図2】ノードのハードウェア構成の一例について示す図である。

【図3】各ノードの秘密鍵に対応する全体公開鍵に関する分散台帳のブロックの発行処理について示すシーケンス図である。

【図4】ノードが追加された際の、各ノードの秘密鍵に対応する全体公開鍵に関する分散台帳のブロックの発行処理について示すシーケンス図である。

【図5】公開証明書を発行する証明書発行処理について示す図である。

【図6】分散台帳に登録されたブロックを用いてブロックヘッダ部の検証を行う処理について示す図である。

【図7】ライトクライアントにおける、従来のなりすまし対策処理について示すシーケンス図である。

【発明を実施するための形態】

【0016】

本開示の形態に係るノード、方法、プログラム及び分散台帳システムについて図面を参照して説明する。説明において同様の要素には同一の符号を付して、重複する説明を適宜省略する。

【0017】

図１は、本開示の一実施形態に係る分散台帳システム１の構成例について説明するための図である。図１に示されるように、分散台帳システム１は、ノード２Ａ～２Ｅ及び通信ネットワーク３を有している。ノード２Ａ～２Ｅは、それぞれいわゆる情報処理装置として構成され、本実施形態において、各ノード２Ａ～２Ｅについて共通の事柄、又は各ノード２Ａ～２Ｅのいずれかを特定しない事柄について言及する場合には、ノード２Ａ～２Ｅを区別せずに単にノード２として参照する場合がある。

【0018】

図２は、ノード２のハードウェア構成の一例について示す図である。この図に示されるように、ノード２は、制御部２１、通信部２２及び記憶部２３を有し、主に半導体回路素子を用いた電子回路で構成された、いわゆる情報処理装置とすることができる。例えば、制御部２１は、主にＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）等の揮発性記憶部等から構成される。通信部２２は、通信ネットワーク３に接続して通信を行なう。記憶部２３は、主にフラッシュメモリやハードディスク等の不揮発性記憶部を有し、データやプログラムを保存する。なお、制御部２１、通信部２２及び記憶部２３は、それぞれＣＰＵ、揮発性記憶部や不揮発性記憶部を有する構成であってもよい。なお、制御部２１により実行される通信を含む情報処理は、図２に示されるハードウェアが、記憶部２３に保存されたプログラムやデータと連関して動作することにより実現されるものとすることができる。分散台帳システム１の各ノード２の記憶部２３には、分散台帳システム１を構成させるためのプログラムが保存されている。また、以下で用いる「秘密共有」の語は、通信部２２による通信ネットワーク３を介した他のノード２と通信を伴う処理を含んでいてもよい。また、以下において「署名」と記載されている処理は、電子署名を意味する。

【0019】

図１に戻り、通信ネットワーク３は、所謂インターネット等の公衆通信ネットワークや構内通信ネットワーク等を用いた通信ネットワークとすることができる。各ノード２Ａ～２Ｅは、例えばピアツーピア通信（Ｐ２Ｐ：Peer to Peer）で参照されるような、一対一での秘匿性のある通信を行うことを可能としている。ここで、図１においては、ノード２の数はノード２Ａ～２Ｅの５つとしているが、ノード２の数は複数であればいくつであっても構わない。

【0020】

ここで分散台帳システム１は、例えばブロックチェーンとすることができる。分散台帳システム１では、参加する複数のノード２で一元的な分散台帳を構築及び管理する。データをブロックと呼ばれる小さな単位で保存し、前のブロックとハッシュ値で結びつけて連鎖させ、複数のノード２で各ブロックを保存することにより、データの改ざんを困難とし、安全性及び信頼性を確保している。また、各ブロックにはトランザクション（取引）情報等の情報を含むことができ、トランザクション情報を追加するには、分散台帳システム１において合意形成がなされることを必要とする。合意形成には、分散台帳システム１に参加する全ノード２による署名、５１％のノード２による署名、２／３以上のノード２による署名等のルールが適用される。ここで全ノードは、後述するフルノード及び／又はバリデータノード等の全ノードとしてもよい。

【0021】

また、図１のノード２は、すべて同一の役割のノード２であってもよいし、異なる役割のノード２を含んでいてもよい。異なる役割とは、例えばシードノード、フルノード、バリデータノード、ライトクライアント及びクライアント等のノードとすることができる。ここで、シードノードは、分散台帳の所属するノードとその役割を管理するノードである。また、フルノードは、分散台帳すべてを保持し、個々のブロックの検証を行うノードである。またバリデータノードは、分散台帳すべてを保持し、生成、検証、および、署名を行うノードである。ライトクライアントは、分散台帳の一部を保持し、分散台帳の参照、および、状態の確認を行うノードである。クライアントは、分散台帳上にデータを保管するアカウントの操作を行うノードである。

【0022】

分散台帳の各ブロックはブロックヘッダ部、トランザクションデータ部、署名部から構成されるものとしてもよい。ここで、ブロックヘッダ部は、直前のブロックのアキュームレータ、トランザクションデータ部のアキュームレータ、分散台帳チェーン識別子、分散台帳番号、タイムスタンプ、及び分散台帳に対応付けられた公開鍵を含むものとすることができる。

【0023】

図３は、各ノード２Ａ～２Ｅの秘密鍵に対応する全体公開鍵に関する分散台帳のブロックの発行処理Ｓ１００について示すシーケンス図である。この図に示されるように、発行処理Ｓ１００では、まずノード２Ａにおいて自身のノードの秘密鍵である自ノード秘密鍵を生成し（ステップＳ１１）、ノード２Ａは、他のノード２Ｂ～２Ｅに秘密共有を要請し、他のノード２Ｂ～２Ｅのそれぞれと秘密共有を行う（ステップＳ１２）。ここで秘密共有は、秘密情報を複数の参加者に分散させ、それらの一部または全体を結合することで元の秘密を再構築できる仕組みである。秘密共有には、例えば既知のFeldman方式やPedersen方式等を利用することができる。本実施形態において、ノード２が秘密共有を行う場合、ノード２は自ノード秘密鍵を複数の参加者に分散させる。当該分散された自ノード秘密鍵を取得した他のノード２は、取得した情報を記憶部に記憶するものとする。ここでノード２による自ノード秘密鍵の「分散」とは、ノード２が自ノード秘密鍵を分割し、自身を含む複数の参加者に当該分割された自ノード秘密鍵を送信することを意味する。

【0024】

また、ノード２Ａから秘密共有の要請を受けたノード２Ｂ～２Ｅは、それぞれ自身のノードの秘密鍵である自ノード秘密鍵を生成し（ステップＳ１３）、各ノード２Ｂ～２Ｅは、他のノード２に秘密共有を要請し、要請先のノード２のそれぞれと秘密共有を行う（ステップＳ１４）。ここで、ステップＳ１１～Ｓ１４までの各ノード２Ａ～２Ｅの秘密鍵生成の処理及び秘密共有の処理をまとめて秘密共有処理Ｓ１０と呼ぶこととする。

【0025】

ここで、秘密共有は、Feldman方式を用いる場合、各ノード２は、例えば以下の式（１）を独立に選択することができる。

【数1】

ここで、gは、例えばed25519など離散対数問題に対して十分な強度が確保された生成元とし、mod pとして巡回群をなす十分大きな素数を選択する。z_iはi番目の秘密鍵に該当し、多項式の係数［a_ij］から以下の式（２）を共有する。

【数2】

ここで、i番目の公開鍵は、式（３）のようになる。

【数3】

各ノードは、式（４）の計算を行い計算した値を共有する。

【数4】

【0026】

ステップＳ２１において、各ノード２Ａ～２Ｅにおいて秘密共有されたデータから全体秘密鍵を抽出し、この全体秘密鍵から全体公開鍵である全体公開鍵を生成する。全体秘密鍵の抽出は、いずれのノード２が行ってもよく、例えばノード２Ａ～２Ｅのうち任意に選択された一のノードが全体秘密鍵の抽出を行ってもよい。

【0027】

秘密鍵は、例えば以下の式で抽出できる。

【数5】

また、公開鍵は、例えば以下の式で生成できる。

【数6】

この時点で全てのノード２Ａ～２Ｅが、全体公開鍵を保持していてもよい。ステップＳ２２において、任意に選択された一のノード（ここではノード２Ｅ）が、全体公開鍵をブロックヘッダ部及び／又はトランザクションデータ部に含むブロックを提案する。

【0028】

ステップＳ２３において、通常のブロック発行と同様に、提案されたノード２Ｅの署名を検証し、自ノード秘密鍵により署名を行う。ここで、各ノード２Ａ～２Ｅは、それぞれ自ノード秘密鍵により、ブロックヘッダ部及び／又はトランザクションデータ部に自ノードの公開鍵が含まれていることを検証することとしてもよい。署名を行った後、ステップＳ２４において、未だ署名を行っていない他のノードに署名を要請する。合意形成がなされたと判断された場合（ステップＳ２５）、ステップＳ２６において、分散台帳に登録するためのブロックを発行する。合意形成の条件は、上述の通り、例えば５１％のノード２による署名等とすることができる。発行されたブロックは各ノード２Ａ～２Ｅの記憶部２３に分散台帳を構成するブロックとして保存されることとしてもよい（ステップＳ２７）。

【0029】

なお、図３のシーケンス図において、ノード２Ａは、シードノードとすることができる。またノード２Ｂ～２Ｅはバリデータノードとすることができる。また、ノード２Ａ～２Ｅが、バリデータノード又はフルノードのいずれかであることとしてもよいし、それぞれその他の役割のノードであってもよい。

【0030】

上述の各ノード２Ａ～２Ｅの秘密鍵に対応する全体公開鍵に関する分散台帳のブロックの発行処理Ｓ１００において、各ノード２Ａ～２Ｅのうちの一つのノード２の処理では、例えばノード２Ａの制御部２１は、自己の秘密鍵である自ノード秘密鍵について他の複数のノード２と秘密共有を行うと共に、他の複数のノード２のそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について秘密共有を行うことができる。また、記憶部２３は、秘密共有を行った自ノード２秘密鍵及び他ノード２秘密鍵から生成された全体公開鍵を含む、分散台帳システム１で発行されたブロックの少なくとも一部について保存することができる。

【0031】

これにより、合意形成と同様の署名がされたデータについて、全体公開鍵を用いることにより、分散台帳システム１により合意形成されたものであることを確認（検証）することができ、分散台帳システム１の利便性を高めることができる。また、各ノード２は、自ノード公開鍵について、分散台帳システム１の合意形成を行うための署名を得た場合には、分散台帳システム１により認証された公開証明書として利用することができる。これにより、分散台帳システム１は、第三者による認証機関を利用せずに、分散台帳システム１により認証可能な公開証明書を発行することができ、分散台帳システム１の利便性を高めることができる。したがって、発行処理Ｓ１００により得られるブロックを利用することにより、分散台帳システム１のセキュリティを維持しつつ、分散台帳システム１及び分散台帳システム１に含まれるノード２の利便性を高めることができる。

【0032】

例えば、ノード２Ａをシードノードとし、ノード２Ｂ～２Ｅの通信部２２は、分散台帳システム１のシードノード２Ａからの秘密共有の要求を受信することとしてもよい。これにより、シードノード２Ａの秘密共有の要求をきっかけとして、各ノード２は、分散型システムのプログラムを実行し、各ノード２は自己の公開鍵を含むブロックについて分散台帳に登録させることができる。

【0033】

また、ノード２の記憶部２３は、秘密共有を行った秘密鍵である自ノード秘密鍵に基づく全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックを分散台帳のブロックとして保存するものとすることができる。これにより、各ノード２又はノード以外の情報処理装置においても、ブロックヘッダ部又はトランザクションデータ部に含まれる全体公開鍵により、集積された署名が分散台帳システム１における合意形成を示すものであるかを検証することができる。したがって、分散台帳システム１のセキュリティを維持しつつ、分散台帳システム１及び分散台帳システム１に含まれるノード２の利便性を高めることができる。

【0034】

また、上述のように、分散台帳システム１は、複数のノード２を備えることができる。また、複数のノード２のそれぞれは、自己の秘密鍵としての自ノード秘密鍵を生成し、生成されたそれぞれの自ノード秘密鍵を複数のノード２において秘密共有を行い、秘密共有を行った複数のノード２のすべての秘密鍵から全体公開鍵を生成することとしてもよい。また、全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックに対して、複数のノード２それぞれの自ノード秘密鍵による署名を行い、ブロックを分散台帳における一つのブロックとして保存するものとすることができる。これにより、集積された署名が分散台帳システム１における合意形成を示すものであるかについて、全体公開鍵を用いることにより、検証することができる。したがって、分散台帳システム１のセキュリティを維持しつつ、分散台帳システム１及び分散台帳システム１に含まれるノード２の利便性を高めることができる。

【0035】

図４は、各ノード２Ａ～２Ｅに更にノード２Ｘが追加された際の、各ノードの秘密鍵に対応する全体公開鍵に関する分散台帳のブロックの発行処理Ｓ１１０について示すシーケンス図である。このシーケンス図に示されるように、ノード２Ｘが分散台帳システム１に追加された場合であっても、各ノード２Ａ～２Ｅ及び２Ｘについて、図３のシーケンス図と同様の処理が行われる。図３のシーケンス図と同様であるため、重複する説明を省略する。

【0036】

ここで、分散台帳システム１等において使用される公開証明書においては、公的機関など、分散台帳システム１外の第三者による信頼源を用いた公開証明書が利用されることがある。このため、分散台帳システム１が参加ノードのみによる堅牢な閉じたシステムとして成立しているにも関わらず、第三者による信頼源に頼ることにより、第三者である認証局のサーバがダウンした場合や、公開鍵の改ざんが発生した場合等には、分散台帳システム１の一部又は全体が機能不全となる恐れがある。上述の秘密共有した秘密鍵を利用したブロックが登録された分散台帳を使用することにより、第三者による信頼源を用いることなく公開証明書を発行することができる。以下に、秘密共有した秘密鍵を利用したブロックが登録された分散台帳を使用したシーケンスについて説明する。

【0037】

図５は、公開証明書を発行する証明書発行処理Ｓ２００について示す図である。この図に示されるように、ノード２Ａは、ステップＳ２０１において、自ノード秘密鍵とペアになる公開鍵を記憶部２３等から読み出して、制御部２１のメモリ等に保存する。引き続き、ステップＳ２０２において、自ノードの公開鍵が含まれているブロックを生成し、図３又は４で生成した自ノード秘密鍵により署名を行い、ステップＳ２０３において未署名のノード２Ｂに署名を要請する。このステップＳ２０２及びＳ２０３をノード２Ｂ～２Ｅで繰り返し、合意形成と判断された場合には（ステップＳ２０４）、署名済の公開鍵について署名済ブロックとして発行する（ステップＳ２０５）。なお、自ノード公開鍵に署名を要請したノード２Ａは、発行されたブロックの内容を公開証明書として利用することができる。ここで各ノードの署名を集積して公開証明書に記録することで、全体公開鍵を用いて公開証明書が真であることを検証することができる。集積された署名は以下の式（７）で表される。

【数7】

また、検証式は以下の式（８）で表される。

【数8】

ステップＳ２０７において、ノード２Ａの記憶部２３は、公開証明書を保存する。ここで、合意形成の条件は、上述の通り、例えば５１％のノード２による署名等とすることができる。上述の証明書発行処理Ｓ２００により、秘密共有した秘密鍵に基づいた全体公開鍵により検証することができる公開証明書を作成できるため、第三者による信頼源を用いることなく、分散台帳システム１内で認証可能な公開証明書を発行することができる。

【0038】

このようにノード２Ａの通信部２２は、自己の公開鍵である自ノード公開鍵について、他の複数のノード２の一つに対して合意形成のための署名を要求することができる。また、記憶部２３は、合意形成がなされた公開鍵を公開証明書として利用するために保存することができる。これにより、各ノード２は、分散台帳システム１により合意形成され、全体公開鍵により（分散台帳システム１により合意形成されたことが）認証可能な公開証明書を作成することができる。

【0039】

ところで、分散台帳システム１を構成するライトクライアントノード等においては、ハードウェアリソースが限られたノードである場合がある。このため、すべての分散台帳を保存せずに、他のノードに保存された分散台帳と部分的に同期することでアカウント状態の検証、トランザクションの検証、及びイベントの監視等が行えるものとしている場合がある。この場合にライトクライアントノードは、例えば、直前のブロックのハッシュ、タイムスタンプ、及びブロック本体のハッシュ等を含んだ情報が集約されたブロックヘッダ部を構成して保存する。このブロックヘッダ部を使用して、フルノードやバリデータから入手したブロックヘッダ部に関して検証や監視を行うことができる。

【0040】

このように、ライトクライアントは分散台帳の部分的なブロックしか保存していないことから、分散台帳をすべて保持しているフルノード、もしくは、バリデータノードになりすましが発生した場合、確認のためのシーケンスが必要となる。

【0041】

図７は、従来のライトクライアントにおける、フルノード又はバリデータノードになりすましがあった場合のなりすまし対策処理Ｓ９００について示すシーケンス図である。このシーケンス図に示されるように、例えば、クライアント４が、分散台帳システム１にアカウントの状態、ブロックの状態やイベント情報を取得する場合に、ステップＳ９０１において、ライトクライアントであるノード２Ａにブロック要請を送信する。ブロック要請を受信したノード２Ａが、例えばなりすましノードである偽ノード５にブロックヘッダ部や検証データを要求した場合に（ステップＳ９０２）、偽ノード５は正当でないブロックヘッダ部や検証データを送信する（ステップＳ９０３）。ここで、ノード２Ａは、予め保存されたブロックヘッダ部等と受信したブロックヘッダ部等とを比較して検証を行うため、検証ＮＧとなる（ステップＳ９０４）。

【0042】

この場合には、ノード２Ａは、他のフルノード又はバリデータノードであるノード２Ｂ～２Ｅに対して、順次ブロックヘッダ部や検証データを要求し（ステップＳ９０５）、ブロックヘッダ部や検証データを受信する（ステップＳ９０６）。そして、例えばブロックヘッダ部や検証データが、分散台帳システム１に参加するフルノードやバリデータノードの例えば５１％の評価があることを確認する等により（ステップＳ９０７）、最新のブロックヘッダ部を正当なブロックヘッダ部として保存することができる（ステップＳ９０８）。ここで、評価は、５１％でなくても、例えば他のすべてのフルノードやバリデータノードの評価や２／３以上のフルノードやバリデータノードの評価とすることができる。その後、ノード２Ａは、ステップＳ９０９において、アカウントの状態、ブロックの状態やイベント情報についてブロック応答として、クライアント４に通知する。

【0043】

このように、他のフルノード又はバリデータノードであるノード２Ｂ～２Ｅから、順次ブロックヘッダ部や検証データを受信して評価するような処理は、リソースが限られているライトクライアントであるノード２Ａの処理としては、負荷が多き過ぎる恐れがある。このため、処理に多くの時間がかかることによる、クライアント４のタイムアウト発生等により、処理が行えなくなる等の恐れがあった。上述の秘密共有した秘密鍵を利用したブロックが登録された分散台帳を使用することにより、過半数のノード２Ｂ～２Ｅから、ブロックヘッダ部や検証データを受信するような処理を行うことなく、ライトクライアントのようなリソースに制限のあるノード２Ａであっても、負荷を軽減して効率的に検証を行うことができる。以下に、秘密共有した秘密鍵を利用したブロックが登録された分散台帳を使用したシーケンスについて説明する。

【0044】

図６は、図３で生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部を有する、分散台帳に登録されたブロックを用いてブロックヘッダ部の検証を行う処理Ｓ４００について示す図である。この図に示されるように、例えば、クライアント４が、分散台帳システム１にアカウントの状態、ブロックの状態やイベント情報を取得する場合に、ステップＳ４０１において、ライトクライアントであるノード２Ａにブロック要請を行う。ブロック要請を受信したノード２Ａが、例えばなりすましノードである偽ノード５に最新のブロックヘッダ部を要求した場合に（ステップＳ４０２）、偽ノード５は正当でない最新のブロックヘッダ部や署名部を送信する（ステップＳ４０３）。ここで、ノード２Ａは、自ノードの公開鍵と受信した最新のブロックヘッダ部及び署名部のグループ署名を検証することで、最新のブロックヘッダ部が正当なものであるかどうかの検証を行い、ここではなりすまされたノード５から受信したブロックヘッダ部であるため、検証ＮＧとなる（ステップＳ４０４）。

【0045】

この場合には、ノード２Ａは、他のフルノード又はバリデータノードである、例えばノード２Ｅに対して、最新のブロックヘッダ部を要求し（ステップＳ４０５）、最新のブロックヘッダ部及び署名部を受信する（ステップＳ４０６）。ここで、ノード２Ａは、全体公開鍵と受信した最新のブロックヘッダ部及び署名部のグループ署名を検証することで、最新のブロックヘッダ部が、分散台帳システム１により合意形成された正当なものであるかどうかの検証を行い、検証ＯＫの場合に（ステップＳ４０７）、最新のブロックヘッダ部を保存する（ステップＳ４０８）。ノード２Ａは、ステップＳ４０９において、最新のブロックから得られるアカウントの状態、ブロックの状態やイベント情報についてブロック応答として、クライアント４に通知する。

【0046】

したがって、秘密共有した秘密鍵から生成した全体公開鍵が保存されたブロックが登録された分散台帳を使用することにより、フルノード又はバリデータノードに繰り返しアクセスすることによる５１％等の評価を必要とせず、一回で正当なブロックヘッダ部又はブロックであるかどうかを検証することができる。

【0047】

また、通信部２２は、他の複数のノードの一つに最新のブロックヘッダ部と署名部を要求して、最新の前記ブロックヘッダ部を受信することができる。また、記憶部２３は、全体公開鍵に基づいて署名部を検証し、分散台帳システム１の正当なノードであると判定した場合に、最新の前記ブロックヘッダ部を保存することとしてもよい。これにより、ノード２Ａは、例えライトクライアント等の一部の情報しか保持しないノード２であっても、ブロックが、自身が参加する分散台帳システム１で合意形成された最新のブロックヘッダ部を保存することができる。

【0048】

また、例えばフルノードやバリデータノードであるノード２Ｅにおいては、他のノード２Ａの秘密鍵を秘密共有し、ノード２Ｅの記憶部２３は、秘密鍵に基づいて生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックを分散台帳のブロックとして保存することができる。これにより、ノード２Ｅは、ライトクライアント等の一部の情報しか保持しないノード２Ａに対して、ブロックやブロックヘッダ部が、分散台帳システム１で合意形成されたものかどうかを判定させることができる。

【0049】

また、分散台帳システム１を構成する複数のノード２Ａ～２Ｅの少なくとも一つのノード２Ａは、秘密鍵について秘密共有を行い、秘密共有を行った秘密鍵に基づいて生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックのうち、少なくともブロックヘッダ部を保存することができる。これにより、秘密鍵を発行したノード２Ａは、例えライトクライアント等の一部の情報しか保持しないノード２Ａであっても、分散台帳システム１に参加している正当なノード２Ａであることを示すことができると共に、ブロック又はブロックヘッダ部が、自己が参加する分散台帳システム１により合意形成されたものであるかどうかを検証することができる。

【0050】

上述の実施形態における動作フロー及び動作例は、必ずしもフロー図又はシーケンス図に記載された順序に沿って時系列に実行されなくてよい。例えば、動作におけるステップは、フロー図又はシーケンス図として記載した順序と異なる順序で実行されても、並列的に実行されてもよい。また、動作におけるステップの一部が削除されてもよく、さらなるステップが処理に追加されてもよい。また、上述の実施形態における動作フロー及び動作例は、別個独立に実施してもよいし、２以上の動作フロー及び動作例を組み合わせて実施してもよい。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよいし、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。

【0051】

上述の実施形態に係る動作をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

【0052】

本開示で使用する「に基づいて」、「に応じて」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。

【0053】

以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

【0054】

上述の実施形態に関する特徴について付記する。

【0055】

（付記１）
分散台帳システムのノードであって、
自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う制御部と、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含む、前記分散台帳システムで発行されたブロックの少なくとも一部について保存する記憶部と、を備えるノード。

【0056】

（付記２）
前記全体公開鍵は、前記ブロックのブロックヘッダ部又はトランザクションデータ部に含まれる、付記１に記載のノード。

【0057】

（付記３）
自己の公開鍵である自ノード公開鍵について、前記他の複数のノードの一つに対して合意形成のための署名を要求する通信部を更に備え、
前記記憶部は、前記合意形成がなされた前記公開鍵を公開証明書として利用するために保存する、付記１又は２に記載のノード。

【0058】

（付記４）
前記分散台帳システムのシードノードからの前記秘密共有の要求を受信する通信部を更に備える、付記１乃至３のいずれか一項に記載のノード。

【0059】

（付記５）
前記ブロックの少なくとも一部は、ブロックヘッダ部であり、
前記他の複数のノードの一つに最新の前記ブロックヘッダ部と署名部を要求して、最新の前記ブロックヘッダ部を受信する通信部を更に備え、
前記記憶部は、前記全体公開鍵に基づいて前記署名部を検証し、前記分散台帳システムの正当なノードであると判定した場合に、最新の前記ブロックヘッダ部を保存する、付記１乃至４のいずれか一項に記載のノード。

【0060】

（付記６）
分散台帳システムの複数のノードのそれぞれに対応する複数の秘密鍵について秘密共有された後に抽出された前記複数の秘密鍵に基づいて生成された全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含む、発行されたブロックを保存する記憶部を備える、ノード。

【0061】

（付記７）
自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行い、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する、方法。

【0062】

（付記８）
自己の秘密鍵である自ノード秘密鍵について他の複数のノードと秘密共有を行うと共に、前記他の複数のノードのそれぞれに対応する複数の秘密鍵である他ノード秘密鍵について前記秘密共有を行う工程と、
前記秘密共有を行った前記自ノード秘密鍵及び前記他ノード秘密鍵から生成された全体公開鍵を含み、分散台帳システムで発行されたブロックの少なくとも一部について保存する工程と、をコンピュータに実行させるプログラム。

【0063】

（付記９）
複数のノードを備え、
前記複数のノードのそれぞれは、
自己の秘密鍵としての自ノード秘密鍵について前記複数のノードにおいて秘密共有を行い、
前記秘密共有を行った前記複数のノードのすべての前記自ノード秘密鍵から全体公開鍵を生成し、
前記全体公開鍵をブロックヘッダ部又はトランザクションデータ部に含むブロックを発行する、分散台帳システム。

【0064】

（付記１０）
前記複数のノードのうちの一つのノードは、自己の公開鍵である自ノード公開鍵について、前記複数のノードの他の一つのノードに対して合意形成のための署名を要求し、
前記一つのノードは、前記合意形成がなされた前記自ノード公開鍵を公開証明書として保存する、付記９に記載の分散台帳システム。

【符号の説明】

【0065】

１ 分散台帳システム
２，２Ａ～２Ｅ，２Ｘ ノード
２１ 制御部
２２ 通信部
２３ 記憶部
３ 通信ネットワーク
４ クライアント
５ 偽ノード

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】