JP7491470B2 - ゾーンベースのブロックチェーンシステム、及びゾーンベースのブロックチェーンシステムを運用するための方法 - Google Patents

Description

本開示は、ゾーンベースのブロックチェーンシステム、及びゾーンベースのブロックチェーンシステムを運用するための方法に関する。

ブロックチェーンは、継続的に増加するデータを取りまとめる分散型データベースである。これらのデータは、１つのファイルではなく、複数のファイルをまとめたブロック単位で保存される。ブロックチェーン技術は、すべてのノードが暗号化されたチャンネルで同一のデータを保存及び送信するピアツーピアのネットワークを用いて市場に革命をもたらした。ブロックチェーンは、お互いに信頼できるビジネスモデルを構築する為の現代ビジネスのインフラと考えられている。

これまで車両データは個々の車両に保存され、その後、コンピューターやネットワークなどに転送されていた。しかし、このような従来の車両データシステムでは、データの保護に懸念があった。例えば、人間がデータを転送する場合、データ転送の過程で意図をせずに間違いを起こすことがある。また、転送後にはデータはデータベースに保存されることが多く、そこで再びデータの破損や不正な操作が行われる可能性がある。

そのため、ブロックチェーン技術を利用して、破損や不正な操作なく、安全に車両データを保存することが求められている。

以下の各項では、本開示の一般的な概要を説明するものであり、本開示の全範囲又は全特徴を包括的に開示するものではない。

本開示の第１側面は、第１マスターノード及び第２マスターノードを含むゾーンベースのブロックチェーンシステムである。第１マスターノードは、第１物理ゾーンに関連する第１ブロックチェーンを保存する。第１マスターノードは、第１物理ゾーン内の車両の車両ノードを追加し、且つ、第１物理ゾーン外の車両の車両ノードを削除することによって、第１ブロックチェーンのノードリストを維持するようにプログラムされている。第１ブロックチェーンは、第１物理ゾーンの内にいる車両によって感知されたセンサデータを含むようにマイニングされた複数のブロックを含む。第２マスターノードは、第２物理ゾーンに関連する第２ブロックチェーンを保存する。第２マスターノードは、第２物理ゾーン内の車両の車両ノードを追加し、且つ、第２物理ゾーン外の車両の車両ノードを削除することによって、第２ブロックチェーンのノードリストを維持するようにプログラムされており、第２ブロックチェーンは、第２物理ゾーン内にいる車両によって感知されたセンサデータを含むようにマイニングされた複数のブロックを含んでいる。第１物理ゾーンと第２物理ゾーンは異なるゾーンである。第１ブロックチェーンと第２ブロックチェーンは、互いに異なるスペックを有する。

本開示の第２側面は、ゾーンベースのブロックチェーンシステムを運用するための方法である。本方法は、第１マスターノードが、第１物理ゾーン内の車両の車両ノードを追加し且つ第１物理ゾーン外の車両の車両ノードを削除することによって、第１物理ゾーンに関連する第１ブロックチェーンのノードリストを維持することを含む。本方法は、第１マスターノードが、第１物理ゾーンの内部にいる車両によって感知されたセンサデータを含むようにマイニングされた複数のブロックを含む第１ブロックチェーンを格納することを含む。本方法は、第２マスターノードが、第２物理ゾーン内の車両の車両ノードを追加し且つ第２物理ゾーン外の車両の車両ノードを削除することによって、第２物理ゾーンに関連する第２ブロックチェーンのノードリストを維持することと、第２マスターノードにおいて、第２物理ゾーン内にいる車両によって感知されたセンサデータを含むようにマイニングされた複数のブロックを含む第２ブロックチェーンを格納することを更に含む。第１物理ゾーンと第２物理ゾーンは異なるゾーンである。第１ブロックチェーンと第２ブロックチェーンは、互いに異なるスペックを有する。

実施形態に係るゾーンベースブロックチェーンシステムを模式的に示す図である。 車両ノードを模式的に示す図である。 コンパクトブロック中継プロトコルと、レガシープロトコルを示す図である。 第１マスターノードと第２マスターノードとを模式的に示す図である。 ブロックチェーン詳細を概念的に示した図である。 ブロックチェーンに新しいノードが参加する際の処理を示す図である。 新規ノード参加処理のフローチャートである。 車両ノードにおけるマイニング処理を示すフローチャートである。 第１マスターノードと第２マスターノードとの間のブロック共有処理を示すフローチャートである。

ここでは本開示の１つの実施形態について説明する。以下に開示の実施形態は単なる例示であり、他の実施形態として様々な代替形態をとることができるものと解されてよい。図は必ずしも縮尺通りではなく、特定の部品の詳細を示すために、いくつかの特徴を誇張又は最小化されていることがある。そのため、本明細書に開示された特定の構造的及び機能的な詳細は、限定的に解釈されるものではなく、単に、当業者が本実施形態を様々に採用することを教えるための代表的な根拠として解釈されてよい。当業者であれば理解できるように、いずれか１つの図を参照して図示及び説明した様々な特徴は、明示的に図示又は説明されていない実施形態を生成するように、１つ又は複数の他の図に図示した特徴と組み合わせられて良い。図示された特徴の組み合わせは、典型的な用途のための代表的な実施形態を提供する。一方で、本開示の教示と一致する特徴の様々な組み合わせ及び改変が、特定の用途又は実装のために要求されうる。

図１は、本実施形態に係るゾーンベースのブロックチェーンシステム１０（以降、システム１０とも記載）を概念的に示す図である。当該システムでは、複数の物理ゾーンが定義されている。後述するように、各種データを安全に保存するために、各物理ゾーンに対応するブロックチェーンが作成及び維持される（すなわち、ゾーンベースのブロックチェーンが作成される）。システム１０は、例えば、都市全体又は都市を互いに接続する高速道路を含む複数の都市など、広い地理的領域を包含して良い。物理ゾーンは、任意の適切な基準に基づいて、物理ゾーンごとに異なる形状や大きさで配置されてよい。例えば、物理ゾーンは、利便性と実装の容易さのために、既存の携帯電話の基地局およびそのカバーエリアに対応してもよい。物理ゾーンの境界は、任意の適切な方法で設定されてよい。以下の説明では、理解を容易にするために、互いに隣接する２つの任意の物理ゾーンについて詳細な説明が行われることになる。当該２つの物理ゾーンは、システム１０内の任意の２つの隣接する物理ゾーンであってよい。

本実施形態のシステム１０は、第１マスターサーバ１６、第２マスターサーバ１８、第１路側機２０、第２路側機２２、及び複数の車両１２を備える。第１及び第２マスターサーバ１６、１８は、後述するように、それぞれのブロックチェーンを運用及び維持するように構成されている。第１及び第２路側機２０、２２は、無線通信及び有線通信を支援する通信基盤装置である。物理ゾーンは、第１及び第２路側機２０、２２によって定義される。例えば、物理ゾーンが既存の携帯電話基地局およびそのカバーエリアに対応するように指定されている場合、第１路側機２０及び第２路側機２２は、隣接する２つの携帯電話基地局およびそのカバーエリアであってもよい。

第１及び第２マスターサーバ１６、１８は、マスターノードとして作動し、それぞれのブロックチェーンを運用及び維持する。このように、第１マスターサーバ１６は、適宜、第１マスターノード１６と称されてよい。同様に、第２マスターサーバ１８は、適宜、第２マスターノード１８と称されてよい。また、複数の車両１２は、後述するように、第１及び第２マスターサーバ１６、１８のそれぞれが管理するブロックチェーンにも参加する。この場合、車両１２は、ブロックチェーンの通常のノードとして作動する。このように、車両１２は、適宜、車両ノード１２と称されてよい。

（物理ゾーン）
本実施形態では、第１及び第２路側機２０、２２によって２つの物理ゾーン（以下、第１ゾーン及び第２ゾーンと記載する。）が定義されている。第１路側機２０及び第２路側機２２は、任意の市町村等を通る道路２４に沿って配置されている。第１ゾーン及び第２ゾーンは、それぞれ、第１路側機２０及び第２路側機２２によって定義される。好ましくは、第１ゾーン及び第２ゾーンは、それぞれ、第１路側機２０及び第２路側機２２を中心とするように形成されている。したがって、第１ゾーンと第２ゾーンは、道路２４に沿って互いに隣接している。第１及び第２路側機２０、２２は、第１ゾーン又は第２ゾーン内の車両１２に対して無線車両通信システムを提供する。第１及び第２路側機２０、２２は、それぞれ第１マスターサーバ１６及び第２マスターサーバ１８に接続されている。

本実施形態において、第１及び第２路側機２０、２２は、車両とインフラ（Ｖ２Ｉ）との間の安全で直接的な通信を可能にするＤＳＲＣ（Dedicated Short-Range Communications）装置である。第１路側機２０は、第１ゾーンを半径約１０００ｍを有する通信エリアと定義する。同様に、第２路側機２２は、第２ゾーンを半径約１０００ｍを有する通信エリアと定義する。なお、第１及び第２路側機２０、２２の実際の通信範囲は、一般に、第１ゾーン及び第２ゾーンの大きさよりも長く、ほとんどの場合、互いに重なっている。そのため、第１ゾーンと第２ゾーンの具体的な境界線は、適宜指定されてよい。また、物理ゾーンは円形の領域であることに限定されない。例えば、第１ゾーン及び第２ゾーンのそれぞれは、一辺の長さが１０００ｍ程度の正方形状であってもよいし、六角形などの他の形状でもよい。代替的な実装では、第１及び第２路側機２０、２２は、５Ｇ／ＬＴＥなどの通信プロトコル又は他の安全な無線プロトコルを介してＶ２Ｉ通信を可能にする装置であって良い。

前述したように、第１及び第２マスターサーバ１６、１８は、対応する物理ゾーンのためのそれぞれのブロックチェーンを維持する。本実施形態においては、第１マスターサーバ１６は、第１ゾーンに対応する第１ブロックチェーン１４ａを維持し、第２マスターサーバ１８は、第２ゾーンに対応する第２ブロックチェーン１４ｂを維持する。第１及び第２ブロックチェーン１４ａ、１４ｂのブロックには、第１ゾーン及び第２ゾーンに関連する様々なデータが格納され得る。本実施形態では、第１及び第２ブロックチェーン１４ａ、１４ｂは、複数の車両１２からの車両センサデータを格納することに関して説明される。

（車両ノード）
前述したように、道路２４を走行し、第１ゾーン及び第２ゾーンを通過する複数の車両１２は、車両ノード１２として機能する。車両ノード１２は、自律走行車両、半自律走行車両、又は手動運転車両であってもよい。図２に示すように、各車両ノード１２は、電子制御ユニット（以下、車両ＥＣＵ３０）と、複数のセンサ３２と、無線通信用の車載器３４と、を備える。センサ３２は、カメラ、レーダーセンサ、ライダーユニットなど、車両ノードの周囲の環境における物体、シーン、条件、気候などを検出又は識別するための様々なセンサであってよい。また、センサ３２は、車両ノードの動作状態を監視又は検出するための、車速センサ、ヨーレートセンサ、マスエアフローセンサ、エンジン回転数センサ、酸素センサ等を含んでよい。なお、本実施形態では、車載器３４は、信号機やゲートウェイステーションといった路側インフラ（不図示）から交通情報を受信するセンサ３２として機能してよい。

本実施形態において、センサデータ２６は、カメラ、ライダーセンサ、又はレーダーセンサによって感知された、動物、歩行者、道路上の障害物などの物体のデータを含む。また、センサデータ２６は、車載器３４が路側インフラから受信した交通情報を含む。さらに、センサデータ２６は、車速センサ、ヨーレートセンサ、エンジン回転数センサなどによって感知される車両の運転状態に関する情報を含む。センサ３２は、車両ＥＣＵ３０に接続されており、センサ３２が感知したセンサデータ２６は、車両ＥＣＵ３０に送信される。

車載器３４は、車両間（Ｖ２Ｖ）の無線通信、及び、車両とインフラ（Ｖ２Ｉ）との無線通信を行うためのものである。各車両ノード１２は、車載器３４を介して、近くにある他の車両ノード１２と通信することが可能である。また、各車両ノード１２は、車載器３４を介して、第１及び第２路側機２０、２２を含む近くの路側インフラと通信することが可能である。したがって、車両ノード１２は、Ｖ２Ｖ通信を通じて、互いにデータ（例えば、後述するセンサデータ２６又はブロックチェーンのブロック２８）を共有することができる。さらに、車両ノード１２は、第１及び第２路側機２０、２２の近くにいるとき、第１及び第２マスターノード１６、１８と通信することができる。したがって、第１ゾーン内の車両ノード１２は、第１路側機２０を介したＶ２Ｉ通信により、センサデータ２６及びブロック２８を第１マスターノード１６に送信することができる。第２ゾーン内の車両ノード１２は、第２路側機２２を介したＶ２Ｉ通信により、センサデータ２６及びブロック２８を第２マスターノード１８へ送信することができる。同様に、第１ゾーン内の車両ノード１２は、車載器３４を介して第１マスターノード１６から情報を受信することができる。第２ゾーン内の車両ノード１２は、車載器３４を介して、第２マスターノード１８から情報を受信することができる。

車両ＥＣＵ３０は、少なくとも１つのプロセッサ３０ａと少なくとも１つのメモリ３０ｂとで実現されている。車両ＥＣＵ３０は、後述するように、ゾーンベースのブロックチェーン１４ごとに設計されたスペック３６に従って、センサ３２によって感知されたセンサデータ２６をマイニングするようにプログラムされている。また、車両ＥＣＵ３０は、対応するブロックチェーンのスペック３６に従ってマイニングされたブロック２８を、メモリ３０ｂに格納するようにプログラムされている。車両ＥＣＵ３０は、センサ３２からセンサデータ２６を受信すると、センサデータ２６をその優先順位に基づいて分類するようにプログラムされている。本実施形態では、車両ＥＣＵ３０は、センサデータ２６の優先度を「最高優先度」、「中間優先度」、又は「低優先度」に分類するように構成されている。例えば、センサ３２が道路上の動物、歩行者、事故車などの突発的な障害物を検出した場合、車両ＥＣＵ３０は、センサデータ２６を「最高優先度」に分類するようにプログラムされている。一方、センサデータ２６が車速やエンジン回転数のような運転状態に関連する情報である場合、車両ＥＣＵ３０は、センサデータ２６を「低優先度」に分類するようにプログラムされている。さらに、センサ３２が雨や雪のような気候条件を検出した場合、車両ＥＣＵ３０は、センサデータ２６を「中間優先度」に分類するようプログラムされている。このように、車両ＥＣＵ３０は、自分自身（以下、適宜「自車両１２」又は「自車両ノード１２」と記載する）又は他車両１２に対する危険性又は安全性の強さに応じて、センサデータ２６を「最高優先度」、「中間優先度」、又は「低優先度」に分類するようプログラムされている。

すなわち、センサデータ２６が自車両１２及び同一ゾーン内の他車両１２に対する差し迫った危険を示しており、その情報を他車両１２と共有すべき場合には、車両ＥＣＵ３０は、センサデータ２６を「最高優先度」に分類するようにプログラムされている。一方、センサデータ２６が自車両１２及び同一ゾーン内の他車両１２に対する危険性又は安全性を示していない場合、車両ＥＣＵ３０は、センサデータ２６を「低優先度」に分類するようプログラムされている。車両ＥＣＵ３０は、「最高優先度」及び「低優先度」のどちらにも該当しない他の全てのセンサデータ２６を、「中間優先度」に分類するようプログラムされている。

車両ＥＣＵ３０がセンサデータ２６を「最高優先度」に分類した場合、車両ＥＣＵ３０は、センサデータ２６をマイニングする前に、同一ゾーン内の他の車両ノード１２とセンサデータ２６を共有（ブロードキャスト）するようプログラムされている。また、車両ＥＣＵ３０は、車両ノード１２が走行している物理ゾーンに対応するマスターノード１６、１８に対して、最高優先度に分類されたセンサデータ２６をブロードキャストする。その後、車両ＥＣＵ３０は、センサデータ２６をマイニングし、マイニングしたブロック２８を、同一ゾーン内の他の車両ノード１２と、車両ノード１２が走行している物理ゾーンに対応するマスターノード１６、１８とにブロードキャストする。このとき、車両ＥＣＵ３０は、スペック３６で規定されているＰｏＷ（Proof - of - Work）プロトコルを用いて、最高優先度のセンサデータ２６を含むブロック２８をマイニングしてもよい。

一方、車両ＥＣＵ３０は、センサデータ２６を「中間優先度」又は「低優先度」に分類した場合、まずセンサデータ２６をマイニングし、マイニングしたブロック２８を同一ゾーン内の他の車両ノード１２及び車両ノード１２が走行する物理ゾーンに対応するマスターノード１６、１８へブロードキャストする。センサデータ２６が「中間優先度」に分類される場合、車両ＥＣＵ３０は、スペック３６で規定されているＰｏＳ（Proof - of - Stake）プロトコルにより、中間優先度のセンサデータ２６を含むブロック２８をマイニングして良い。逆に、センサデータ２６が「低優先度」に分類される場合、車両ＥＣＵ３０は、最高優先度のセンサデータ２６と同様に、スペック３６で規定されているＰｏＷプロトコルを用いて、低優先度のセンサデータ２６を含むブロック２８をマイニングしてもよい。

センサデータ２６が「最高優先度」に分類される場合、最高優先度のセンサデータ２６が他のノード１２及びマスターノード１６、１８と共有された後、最高優先度のセンサデータ２６を含むブロック２８は、レガシープロトコル（図３参照）を用いてマスターノード１６、１８及び他の車両ノード１２にブロードキャストされる。同様に、センサデータ２６が「低優先度」に分類される場合、低優先度のセンサデータ２６を含むブロック２８は、レガシープロトコルを用いてマスターノード１６、１８及び他の車両ノード１２にブロードキャストされる。逆に、センサデータ２６が「中間優先度」に分類される場合、車両ＥＣＵ３０は、図３に示すように、中間優先度のセンサデータ２６を含むブロック２８を、コンパクトブロック中継プロトコルによりマスターノード１６、１８及び他の車両ノード１２にブロードキャストするようにプログラムされている。図３に示されるように、コンパクトブロック中継プロトコルには低帯域中継と高帯域中継とが存在し、車両ＥＣＵ３０は、利用可能な帯域に応じて低帯域中継と高帯域中継のいずれかを選択するようにプログラムされている。コンパクトブロック中継プロトコルを使用することで、各車両ノードの帯域幅を節約することが可能となる。Ryunosuke Nagayama、Ryohei Banno、Kazuyuki Shudoが執筆している“Identifying Impacts of Protocol and Internet Development on the Bitcoin Network”では、コンパクトブロック中継プロトコルを開示しており、この内容は参照により本特許内にも組み込まれる。

各車両ノード１２の車両ＥＣＵ３０は、通常のブロックチェーン技術に従い、自車両ノード１２がマイニングしたブロック２８と、同一物理ゾーン内の他車両ノード１２から受信したブロック２８とを、対応するスペック３６に従ってブロックチェーンに格納するようプログラムされている。言い換えれば、各車両ＥＣＵ３０は、通過する物理ゾーンごとに個別のブロックチェーンを作成及び維持し、少なくとも１つのブロックをマイニング又は受信することになる。しかし、実際には、車両ノード１２が通過するの物理ゾーンごとの完全なブロックチェーン全体を保存することは、記憶容量の観点から現実的ではない。したがって、車両ＥＣＵ３０における記憶容量を節約するために、車両ＥＣＵ３０は、様々なブロックチェーンの記憶域削減の仕組みを用いて複数のブロック２８を保存してもよい。例えば、車両ＥＣＵ３０は、古いブロックを切り捨てることで、ブロックチェーンの記憶容量を削減してよい。また、車両ＥＣＵ３０は、スナップショットブロックを作成することにより、ブロックチェーンの記憶容量を削減してよい。2019年に第18回IEEE International Conference On Trust, Security and Privacy（Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering内）で発表された“Tackling Data Inefficiency: Compressing the Bitcoin Blockchain”では、スナップショットブロックの技術を開示しており、参照により本特許内に組み込まれる。さらに、車両ＥＣＵ３０は、ハッシュアドレスを記憶することで、ブロックチェーンの記憶容量を削減してよい。

（マスターノード）
図４に示すように、第１マスターノード１６は、少なくとも１つのプロセッサ１６ａと少なくとも１つのメモリ１６ｂとを用いて実現されている。第１マスターノード１６は、第１ゾーンに関連する第１ブロックチェーン１４ａを格納するサーバとして機能してよい。第１マスターノード１６は、第１ゾーン内の車両ノード１２によって感知され、そこから送信されたセンサデータ２６をマイニングするためのマイニングノードとしても機能してよい。さらに、第１マスターノード１６は、第１ブロックチェーン１４ａの車両ノード１２を管理する管理者として機能してよい。

第１マスターノード１６と同様に、第２マスターノード１８は、少なくとも１つのプロセッサ１８ａ及び少なくとも１つのメモリ１８ｂを用いて実現されている。第２マスターノード１８は、第２ゾーンに関連する第２ブロックチェーン１４ｂを格納するサーバとして機能してよい。第２マスターノード１８は、第２ゾーン内の車両１２によって感知されたセンサデータ２６をマイニングするためのマイニングノードとしても機能してよい。第２マスターノード１８は、第２ブロックチェーン１４ｂにおいて、車両ノード１２を管理する管理者として機能してよい。

第１マスターノード１６が記憶する第１ブロックチェーン１４ａ、及び第２マスターノード１８が記憶する第２ブロックチェーン１４ｂは、センサデータ２６を含むようにマイニングされた複数のブロック２８で形成されている。第１ブロックチェーン１４ａのブロック２８に含まれるセンサデータ２６のほとんどは、車両１２が第１ゾーン内にいる間（例えば、車両１２が第１ゾーン内で走行している間、又は車両１２が第１ゾーン内で駐車されている間）において、車両１２によって感知されたものである。第２ブロックチェーン１４ｂのブロック２８に含まれるセンサデータ２６のほとんどは、車両１２が第２ゾーン内にいる間（例えば、車両１２が第２ゾーン内で走行中又は車両１２が第２ゾーン内で駐車中）において、車両１２によって感知されたものである。

（第１及び第２スペック）
第１ゾーン内の車両ノード１２が感知したセンサデータ２６は、第１ブロックチェーン１４ａのための第１スペック３６ａに従って、第１マスターノード１６又は第１ゾーン内の車両ノード１２によってマイニングされる。第２ゾーン内の車両が感知したセンサデータ２６は、第２ブロックチェーン１４ｂのための第２スペック３６ｂに従って、第２マスターノード１８又は第２ゾーン内の車両ノード１２によってマイニングされる。第１マスターノード１６及び第２マスターノード１８は、それぞれ、第１スペック３６ａ及び第２スペック３６ｂをそれらのメモリ１６ｂ、１８ｂに格納している。第１マスターノード１６が自らブロック２８をマイニングする場合、第１マスターノード１６は、第１スペック３６ａにしたがってブロック２８をマイニングする。第２マスターノード１８が自らブロック２８をマイニングする場合、第２マスターノード１８は、第２スペック３６ｂにしたがってブロック２８をマイニングする。

さらに、第１マスターノード１６は、或る車両１２が第１ゾーンに進入すると、第１路側機２０を介して当該車両１２に第１スペック３６ａを送信するようにプログラムされている。車両１２は第１スペック３６ａを受信すると、車両ＥＣＵ３０は、第１スペック３６ａをメモリ３０ｂに記憶し、且つ、車両１２が第１ゾーン内にある間は第１スペック３６ａに従ってブロック２８をマイニングする。同様に、第２マスターノード１８は、或る車両１２が第２ゾーンに進入した場合に、第２路側機２２を介して当該車両１２に第２スペック３６ｂを送信するようプログラムされている。車両１２は第２スペック３６ｂを受信すると、車両ＥＣＵ３０は、第２スペック３６ｂをメモリ３０ｂに記憶し、且つ、車両１２が第２ゾーン内にある間は、第２スペック３６ｂに従ってブロック２８をマイニングする。

第１スペック３６ａ及び第２スペック３６ｂの各々は、各物理ゾーンと関連付けて定義されるブロックチェーンの詳細（ＢＣ詳細）を構成する。より具体的には、第１ブロックチェーン１４ａのためのＢＣ詳細は、第１ゾーンの状況や、事情、特性、要件、規制等に従って第１ブロックチェーン１４ａをカスタマイズするように定義されている。同様に、第２ブロックチェーン１４ｂのためのＢＣ詳細は、第２ゾーンの状況や、事情、特性、要件、規制等に従って第２ブロックチェーン１４ｂをカスタマイズするように定義されている。すなわち、第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂは、ローカル要件に応じたＢＣ詳細を設定することにより、柔軟にカスタマイズ可能となる。図５に示すように、ＢＣ詳細には、主に、第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂを一意に定義するジェネシスファイル４０及びコンセンサスアルゴリズム４２が含まれる。

ジェネシスファイル４０は、第１及び第２ブロックチェーン１４ａ、１４ｂの第１ブロックを定義するファイル（例えば、ＪＳＯＮファイル）である。すなわち、ジェネシスファイル４０には、第１及び第２ブロックチェーン１４ａ、１４ｂの設定が含まれている。ジェネシスファイル４０には、チェーンＩＤ４０ａ、ガスリミット４０ｂ、難易度４０ｃ、及びナンス、ハッシュ４０ｄといった、主に４つの必須項目が含まれている。チェーンＩＤ４０ａは、第１及び第２ブロックチェーン１４ａ、１４ｂの各々に固有のＩＤであり、トランザクション署名処理において使用される。このように、ジェネシスファイル４０にてチェーンＩＤ４０ａを指定することで、第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂをリプレイ攻撃から防ぐことができる。ガスリミット４０ｂは、１ブロックあたりのトランザクション承認手数料の限界値である。ガスリミット４０ｂは、トランザクション又は機能がユーザに課金又は徴収可能な金額の最大値を定義する。このように、ガスリミット４０ｂは、第１及び第２ブロックチェーン１４ａ、１４ｂにおけるスマートコントラクトのバグやエラーによって、高額な料金が誤って請求されることを防止するセキュリティ機構として機能する。難易度４０ｃは、マイナーが第１及び第２ブロックチェーン１４ａ、１４ｂに新しい取引ブロックを追加するのにかかる時間を規制するマイニングの難易度を定義している。難易度４０ｃの数が増えるほど、ブロックのインターバル時間も長くなる。ナンスとハッシュ４０ｄは、組み合わせることで、ブロックが暗号的にマイニングされたことを確認可能とする値である。

次に、各スペック３６のコンセンサスアルゴリズム４２について説明する。一般的に、コンセンサスアルゴリズムとは、ブロックチェーンネットワークのすべてのノードが、分散型台帳（例えば、第１ブロックチェーン１４ａ又は第２ブロックチェーン１４ｂ）の現在の状態について共通の合意に達する手順である。このように、コンセンサスアルゴリズムは、ブロックチェーンネットワークにおける信頼性を実現し、分散コンピューティング環境における未知のノード間の信頼性を確立する。基本的に、コンセンサスプロトコルは、ブロックチェーンに追加されるすべての新しいブロックが、ブロックチェーン内のすべてのノードによって合意された真実の唯一無二のバージョンであることを確認するものである。本実施形態のシステムで利用可能なコンセンサスアルゴリズムは多数あり、各アルゴリズムは、ブロックチェーンの取引スループットやブロックチェーンにおけるブロックの確定時間の向上を目的としている。例えば、第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂで利用可能なコンセンサスアルゴリズム４２として、ＰｏＷ（Proof of Work）、ＰＢＦＴ（Practical Byzantine Fault Tolerance）、ＰｏＳ（Proof of Stake）、ＰｏＢ（Proof of Burn）、Proof of Capacity、Proof of Elapsed Time、ＢＡＢＥ（Blind Assignment for Blockchain Extension）、COSMOS Tendermint等が使用されてよい。

（各物理ゾーンに向けたブロックチェーンの変更）
ここで、第１及び第２スペック３６ａ、３６ｂを設定することによる、各ブロックチェーンのカスタマイズの実例について説明する。
＜事例１：賑やかなエリア対静かなエリア＞
仮に第１ゾーンが都市の繁華街のような賑やかな地域（すなわち、車や歩行者が多い地域）に設定され、第２ゾーンが町の郊外のような静かな地域（すなわち、車や歩行者が少ない地域）に設定されている場合、第１ブロックチェーン１４ａ（すなわち、第１スペック３６ａ）は、第２ブロックチェーン１４ｂ（すなわち、第２スペック３６ｂ）に比べて、ジェネシスファイル４０の難易度４０ｃが低い数値に設定される。第１スペック３６ａにおいて難易度４０ｃの数値を低く設定することにより、マイナー（すなわち、車両ノード１２及び第１マスターノード１６）は、ビジー状態において、より短い所要時間でブロック２８をマイニング可能となる。さらに、交差点が多いことに由来して第１ゾーンが第２ゾーンよりも混雑している場合、第１スペック３６ａには、より低い確定時間を有するコンセンサスアルゴリズム４２が設定される。
＜事例２：危険なエリア対安全なエリア＞
仮に第１ゾーンが都市内の危険なエリア（事故が頻発する地域）に設定され、第２ゾーンが同一都市内において第１ゾーンよりも安全なエリアに設定されている場合、第１スペック３６ａには、ＢＡＢＥのように高い総スループットを有するコンセンサスアルゴリズム４２が設定される。総スループットが高められたコンセンサスアルゴリズム４２を設定することにより、第１ブロックチェーン１４ａにおいてより高速なブロック生成が実現され、情報共有のためのセキュリティが向上することになる。一方、第１ゾーンよりも安全な第２ゾーンのための第２スペック３６ｂには、ＰｏＡやＰｏＷといった標準的なコンセンサスアルゴリズム４２が設定されている。
＜事例３：安全が要求されるエリアと通常のエリア＞
第１ゾーンが学校、病院などを有する地域のように、安全が要求されるエリアに設定され、第２ゾーンが通常のエリアに設定される場合、第１ゾーン用の第１スペック３６ａには、IOTA、ハッシュグラフ、COSMOS Tendermintなどといった、何らかの高度なコンセンサスアルゴリズム４２が設定される。これらのタイプでは、ブロックの確定時間が短いため、情報共有が高速に行われる。

（相互運用性）
第１マスターノード１６と第２マスターノード１８は、無線又は有線で接続されている。本実施形態では、図４に示すように、第１マスターノード１６と第２マスターノード１８とは、光ファイバ４４によって物理的に接続されている。光ファイバ接続により、第１マスターノード１６と第２マスターノード１８は、互いにデータ２６又はブロック２８を転送することが可能である。すなわち、第１及び第２マスターノード１６、１８は、情報を交換することができ、交換された情報を利用することができる（すなわち、相互運用性が実現されている）。

第１マスターノード１６は、第１ゾーン内の車両ノード１２からブロック２８を受信すると、そのブロック２８を第２マスターノード１８と共有すべきかどうかを決定するようにプログラムされている。同様に、第２マスターノード１８は、第２ゾーン内の車両ノード１２からブロック２８を受信すると、そのブロック２８を第１マスターノード１６と共有すべきかどうかを決定するようにプログラムされている。第１及び第２マスターノード１６、１８による上記の決定は、ブロック２８に含まれるセンサデータ２６の特徴に基づいて行われる。より具体的には、第１及び第２マスターノード１６、１８は、ブロック２８に含まれるセンサデータ２６が他のゾーンに関連する場合、その情報を互いに共有すべきと判断するようにプログラムされている。例えば、ブロックが交通シナリオ又は緊急の自然災害の情報に関するセンサデータ２６を含む場合、第１及び第２マスターノード１６、１８は、そのセンサデータ２６を含むブロック２８を互いに共有すべきと決定するようにプログラムされている。一方、ブロック２８が車両ノード１２の運転状態に関するセンサデータ２６を含む場合、第１及び第２マスターノード１６、１８は、センサデータ２６を含むブロック２８を互いに共有すべきではないと判断するようにプログラムされている。第１マスターノード１６は、ブロック２８ａ（特定のブロックという場合もある）を第２マスターノード１８と共有すべきと判断した場合、光ファイバ４４を介してブロック２８ａを第２マスターノード１８に送信（ユニキャスト）する。同様に、第２マスターノード１８は、ブロック２８ａを第１マスターノード１６と共有すべきと判断した場合、光ファイバ４４を介してブロック２８ａを第１マスターノード１６に送信（ユニキャスト）する。

そして、図４に示すように、第２マスターノード１８は、第１マスターノード１６からブロック２８ａを受信すると、第２スペック３６ｂに従って、ブロック２８ａに含まれるセンサデータ２６をマイニングするようプログラムされている。また、第２マスターノード１８は、受信したブロック２８ａから作成した新しいブロック２８ｂを第２ブロックチェーン１４ｂに追加し、新たに作成したブロック２８ｂを、第２路側機２２を介して第２ゾーン内の車両ノード１２にブロードキャストする。すなわち、新たに作成されたブロック２８ｂは、第２ブロックチェーン１４ｂのシステム内に存在するすべてのノードに共通に配布される第２ブロックチェーン１４ｂに追加される。その結果、特定のブロック２８ｂに含まれるセンサデータ２６は、第２ゾーン内の第２マスターノード１８及び車両ノード１２に利用可能になる。この後、各車両ノード１２は、この情報を用いて、様々な種類の処理を自由に行うことができる。例えば、受信した情報が第１ゾーンの大渋滞に関連している場合、第２ゾーンの車両ノード１２は、第１ゾーンの大渋滞を迂回するように推奨経路を変更することができる。

システム１０において、各マスターノードは、独立した個別のブロックチェーンを維持する。すなわち、全ノードで共通かつ同一の分散台帳を維持する一般的なブロックチェーンシステムとは逆に、本システム１０は、マスターノードごとに異なるブロックチェーンを意図的に割り当てている。これにより、システム１０は、物理ゾーンごとに特化又はカスタマイズされたスペック３６を有するブロックチェーンを維持し、且つ、ストレージ容量を削減することができる。システム１０では、局所的なデータは原則的に、対応する物理ゾーンのブロックチェーンへと格納されるためである。しかし、このような分配は、個々のブロックチェーンが破損したり、不正にデータを修正されたりする可能性があることを意味する。これに対処するため、第２マスターノード１８は、第１マスターノード１６から受信したブロック２８ａから第２マスターノード１８がマイニングした、新たに作成されたブロック２８ｂに基づいて、第１ブロックチェーン１４ａの真正性を検証可能にプログラムされている。この種の相互認証は、第１マスターノード１６及び第２マスターノード１８の両方と通信する第三者サーバなどの信頼できる第三者を活用することによって実行されてもよい。この場合、第２マスターノード１８は、信頼できる第三者を活用して、新たに作成されたブロック２８ｂに基づいて第１ブロックチェーン１４ａの真正性を検証してよい。これは、信頼できる第三者の存在を必要とする公証制度とも呼ばれる。

他の態様として、第１マスターノード１６と第２マスターノード１８とが直接通信して、互いのブロックチェーンの真正性を積極的に検証するリレー方式が用いられてもよい。例えば、第１ブロックチェーンに存在するスマートコントラクトは、第２ブロックチェーンからブロックを受信したことを受けて、読み込み、検証、作動が可能であってよい。このように、第三者によるインターフェースを必要とせず、第１及び第２ブロックチェーン１４ａ、１４ｂが直接的に互いに検証可能であってよい。

さらに別の方法として、第１及び第２マスターノード１６、１８間の真正性を検証するために、ハッシュロック方式が使用されてよい。例えば、ブロックには、共有されるべきセンサデータに加えて、相互運用性を実現し且つ第１ブロックチェーン１４ａと第２ブロックチェーン１４ｂとの間で相互認証を許可するための暗号証明としてハッシュが付加されてよい。他のタイプの相互認証は、上述した方法に加えて、又はその代わりに実行されてよい。

以上の説明は、システム１０内の任意のマスターノードの組に適用可能である。例えば、第１マスターノード１６が第２マスターノード１８からブロックを受信した場合、第１マスターノード１６は、そのブロックに含まれるセンサデータを第１スペック３６ａに従ってマイニングするようプログラムされている。そして、第１マスターノード１６は、受信したブロックから作成した新たなブロックを第１ブロックチェーン１４ａに追加し、第１路側機２０を介して第１ゾーン内の車両ノード１２に向けて新たに作成したブロックをブロードキャストする。この場合も、第１マスターノード１６は、新たに作成されたブロックに基づいて第２ブロックチェーン１４ｂの真正性を検証可能にプログラムされている。

（各物理ゾーンの車両ノードの管理）
第１マスターノード１６及び第２マスターノード１８は、それぞれ第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂに対する車両ノード１２の入退場も管理するようにプログラムされている。第１マスターノード１６は、第１ブロックチェーン１４ａのノードについてのノードリスト５０を管理する。また、第２マスターノード１８は、第２ブロックチェーン１４ｂのノードについてのノードリスト５０を管理する。第１マスターノード１６及び第２マスターノード１８の各々は、ノードリスト５０をメモリ１６ｂ、１８ｂに格納する。そして、第１マスターノード１６は、第１ゾーンに入る（又は第１ゾーン内にある）車両ノード１２を追加し、且つ、第１ゾーンから出る（又は第１ゾーン外にある）車両ノード１２を削除することにより、第１ブロックチェーン１４ａのノードリスト５０を維持する。同様に、第２マスターノード１８は、第２ゾーン内の車両ノード１２を追加し、且つ、第２ゾーン外の車両ノード１２を削除することにより、第２ブロックチェーン１４ｂのノードリスト５０を維持する。第１マスターノード１６のノードリスト５０は、現在第１ゾーン内にいる車両ノード１２のＩＤのリストである。第２マスターノード１８のノードリスト５０は、現在第２ゾーン内にいる車両ノード１２のＩＤのリストである。具体的には、第１マスターノード１６は、図４に示すように、車両１２が第１ゾーンに入ったときにその車両識別番号（ＶＩＮ）をノードリスト５０に追加し、車両１２が第１ゾーンから出たときにそのＩＤをノードリスト５０から削除するようにプログラムされている。同様に、第２マスターノード１８は、車両１２が第２ゾーンに入ったときにノードリスト５０にそのＶＩＮを追加し、車両１２が第２ゾーンから出たときにノードリスト５０からそのＩＤを削除するようにプログラムされている。

さらに、第１マスターノード１６及び第２マスターノード１８の各々は、そのメモリ１６ｂ、１８ｂにグローバル許可リスト４６を格納している。各グローバル許可リスト４６は、ゾーンベースのブロックチェーンシステム１０への参加を予め許可された車両ノード１２の複数のＩＤを有するリストである。本実施形態では、グローバル許可リスト４６は、システム１０への参加が許可された車両ノード１２を識別する複数のＶＩＮで形成されている。

そして、第１マスターノード１６は、或る車両１２が第１ゾーンに進入する際、当該車両１２のＶＩＮがグローバル許可リスト４６に記載されているか否かを確認するようにプログラムされている。より具体的には、或る車両ノード１２が第１ゾーンに進入すると、図６に示すように、その車両ＥＣＵ３０は、第１路側機２０を介して第１マスターノード１６に通信要求を送信するようプログラムされている。第１マスターノード１６は、車両ノード１２から通信要求を受信すると、グローバル許可リスト４６を確認する。そして、グローバル許可リスト４６にその車両ノード１２のＶＩＮが記載されている場合、第１マスターノード１６は、ノードリスト５０にそのＶＩＮを加える。この方法では、第１マスターノード１６は、新しい車両１２をノードリスト５０に追加する前に、最初にグローバル許可リスト４６をチェックする。そして、第１マスターノード１６は、公開鍵（以下、マスター公開鍵という）を生成し、マスター公開鍵によってＢＣ詳細（すなわち、第１スペック３６ａ）を暗号化する。その後、第１マスターノード１６は、マスター公開鍵で暗号化したＢＣ詳細を、第１路側機２０を介して車両ノード１２に送信する。車両ノード１２の車両ＥＣＵ３０は、暗号化されたＢＣ詳細を受信すると、車両ノード１２が有する秘密鍵を用いてＢＣ詳細を復号し、車両ＥＣＵ３０のメモリ３０ｂに第１スペック３６ａを格納する。そして、車両ノード１２は、第１路側機２０を介して、第１マスターノード１６に別の公開鍵（以下、ノード公開鍵）を送信する。第１マスターノード１６は、車両ノード１２からノード公開鍵を受信すると、当該車両ノード１２のノード公開鍵を第１ゾーン内の他の車両ノード１２へブロードキャストする。

このようにして、車両１２のＶＩＮがグローバル許可リスト４６に記載されている場合、第１マスターノード１６は、車両１２を第１ブロックチェーン１４ａのための新しい車両ノード１２として追加するようにプログラムされている。逆に、第１マスターノード１６は、或る車両１２が第１ゾーンから退出する際には、ノードリスト５０からその車両ノードのＶＩＮを削除することにより、第１ブロックチェーン１４ａの車両ノード１２として車両１２を削除するようにプログラムされている。第１マスターノード１６は、車両ノード１２を追加及び削除することにより、第１ブロックチェーン１４ａの車両ノード１２を管理し、第１マスターノード１６が受信したブロック２８が、本当にシステム１０への参加が許可された車両ノード１２から作成及び送信されたか否かを検証する。

第１マスターノード１６と同様に、第２マスターノード１８は、或る車両が第２ゾーンに進入する際に、その車両１２のＶＩＮがグローバル許可リスト４６に記載されているかどうかをチェックするようにプログラムされている。より具体的には、車両ノード１２が第２ゾーンに入ると、車両ノード１２は、第２マスターノード１８に通信要求を送信する。そして、第２マスターノード１８は、その車両ノード１２のＶＩＮを確認する。車両ノード１２のＶＩＮがグローバル許可リスト４６に記載されている場合、第２マスターノード１８は、車両ノード１２のＶＩＮをノードリスト５０に追加する。そして、第２マスターノード１８は、マスター公開鍵を生成し、マスター公開鍵で暗号化したＢＣ詳細（すなわち、第２スペック３６ｂ）を、第２路側機２２を介して車両ノード１２に送信する。車両ノード１２は、暗号化されたＢＣ詳細を受信すると、車両ノード１２が有する秘密鍵でＢＣ詳細を復号し、第２スペック３６ｂを車両ＥＣＵ３０のメモリ３０ｂに格納する。そして、車両ノード１２は、第２路側機２２を介して第２マスターノード１８にノード公開鍵を送信し、第２マスターノード１８は、その車両ノード１２のノード公開鍵を第２ゾーン内の他の車両ノード１２にブロードキャストする。このようにして、第２マスターノード１８は、車両１２を第２ブロックチェーン１４ｂのための新たな車両ノード１２として追加する。

逆に、第２マスターノード１８は、車両１２が第２ゾーンから退出する際、車両ノード１２のＶＩＮをノードリスト５０から削除することにより、第２ブロックチェーン１４ｂの車両ノード１２としての車両１２を削除するようにプログラムされている。第２マスターノード１８は、車両ノード１２を追加及び削除することにより、第２ブロックチェーン１４ｂの車両ノード１２を管理し、第２マスターノード１８が受信したブロック２８が、本当にシステム１０への参加が許可された車両ノード１２から作成及び送信されたか否かを検証する。

したがって、或る車両１２が第１ゾーンと第２ゾーンとの間を走行している場合、車両１２は、第１ゾーンの内部にいるときは、第１ブロックチェーン１４ａの第１スペック３６ａに従ってセンサデータ２６をマイニングすることにより、第１ブロックチェーン１４ａの車両ノード１２として動作する。そして、車両１２は、第２ゾーン内にいるときは、第２ブロックチェーン１４ｂの第２スペック３６ｂに従ってセンサデータ２６をマイニングすることにより、第２ブロックチェーン１４ｂの車両ノード１２として機能する。

（作動）
次に、本実施形態に係るシステム１０が実行する複数の処理について、以下に説明する。

＜新規ノード参加処理＞
第１マスターノード１６及び第２マスターノード１８は、車両ノード１２が各ゾーンに進入した際に、新規ノード参加処理を実行するようにプログラムされている。以下の説明では、第１及び第２マスターノード１６、１８が実行する処理は互いに同様であるため、第１マスターノード１６が実行する処理のみを図７を参照しながら説明する。第１マスターノード１６は、図７のフローチャートに示す新規ノード参加処理を繰り返し実行する。

ステップＳ１０において、第１マスターノード１６は、新規の車両ノード１２から通信要求を受信したか否かを判定する。第１マスターノード１６が通信要求を受信した場合（Ｓ１０：ＹＥＳ）、第１マスターノード１６は、ステップＳ２０において、グローバル許可リスト４６を確認する。ステップＳ３０において、第１マスターノード１６は、新規の車両ノード１２のＶＩＮがグローバル許可リスト４６に記載されているか否かを判定する。当該ＶＩＮがグローバル許可リスト４６に記載されていない場合（Ｓ３０：ＮＯ）、第１マスターノード１６は、処理を終了する。当該ＶＩＮがグローバル許可リスト４６に記載されている場合（Ｓ３０：ＹＥＳ）、ステップＳ４０において、第１マスターノード１６は、ノードリスト５０にそのＶＩＮを追加し、ステップＳ５０において、第１マスターノード１６は、マスター公開鍵を生成する。そして、第１マスターノード１６は、ステップＳ６０において、ＢＣ詳細（第１スペック３６ａ）をマスター公開鍵で暗号化する。

第１マスターノード１６は、ステップＳ７０において、暗号化されたＢＣ詳細を、第１路側機２０を介して新規の車両ノード１２に送信する。ＢＣ詳細を受信した新規の車両ノード１２の車両ＥＣＵ３０は、ステップＳ８０で、秘密鍵を用いてＢＣ詳細を復号する。そして、車両ＥＣＵ３０は、ステップＳ９０において、ノード公開鍵を、第１路側機２０を介して第１マスターノード１６に送信する。第１マスターノード１６は、新規の車両ノード１２からノード公開鍵を受信すると、ステップＳ９５において第１路側機２０を介して他の車両ノード１２にノード公開鍵をブロードキャストする。

したがって、車両１２が第１ゾーンに入ると、第１マスターノード１６は、グローバル許可リスト４６を確認することによって、車両１２がゾーンベースのブロックチェーンシステム１０に参加することを許可されているか否かを判定することができる。このようにして、第１マスターノード１６は、ノードリスト５０において、システム１０に参加することが既に許可されている車両１２のみを追加することができる。換言すれば、第１マスターノード１６は、ノードリスト５０を維持することで、第１ブロックチェーン１４ａの作成にかかる第１ゾーン内の車両ノード１２を制御することができる。さらに、第１マスターノード１６は、グローバル許可リスト４６にＶＩＮが記載されている場合、新規の車両ノード１２にＢＣ詳細を送信する。それ故、新規の車両ノード１２の車両ＥＣＵ３０は、第１ブロックチェーン１４ａ用にカスタマイズされた第１スペック３６ａに従って、センサデータ２６をマイニングできる。その結果、第１ゾーンの特性に特化してカスタマイズされた第１ブロックチェーン１４ａが作成されうる。さらに、第１マスターノード１６はマスター公開鍵によりＢＣ詳細を暗号化し、且つ、新たな車両ノード１２は秘密鍵によりＢＣ詳細を復号化するので、ＢＣ詳細は、新規の車両ノード１２に向けて確実に送信可能となる。

＜マイニング処理＞
次に、車両ノード１２が実行するマイニング処理について、図８を参照しながら説明する。図８に示すフローチャートに示すマイニング処理は、第１ゾーンを走行している車両ノード１２によって繰り返し実行される。

車両ＥＣＵ３０は、まず、車両ノード１２のセンサ３２がセンサデータ２６を取得したか否かを判定する。車両ＥＣＵ３０は、センサデータ２６を取得した場合（ステップＳ１００：ＹＥＳ）、ステップＳ１１０において、当該センサデータ２６の優先度を決定する。センサデータ２６は高優先度と判断された場合（ステップＳ１２０：ＹＥＳ）、処理はステップＳ１３０に進む。逆に、センサデータ２６は高優先度と判断されない場合、処理はステップＳ１４０に進む。ステップＳ１３０において、車両ＥＣＵ３０は、センサデータ２６を暗号化し、暗号化したセンサデータ２６を第１ゾーン内の他の車両ノード１２へブロードキャストする。すなわち、車両ＥＣＵ３０は、センサデータ２６をマイニングする前に、高優先度のセンサデータ２６を他の車両ノード１２と共有する。従って、最高優先度のセンサデータ２６は、第１ゾーン内の他の車両ノード１２と迅速に共有されうる。また、他の車両ノード１２は、危険な状況を回避又は対処するために、共有されたセンサデータ２６を利用可能となる。その後、車両ＥＣＵ３０は、ステップＳ１５０において、第１スペック３６ａに従って、センサデータ２６をマイニングする。このとき、車両ＥＣＵ３０は、第１スペック３６ａに従い、ＰｏＷプロトコルを用いてセンサデータ２６をマイニングしてよい。そして、車両ＥＣＵ３０は、ステップ１６０において、高優先度のセンサデータ２６を含むブロック２８を、第１路側機２０を介してレガシープロトコルを用いて第１マスターノード１６に送信する。高優先度のセンサデータ２６は既に他の車両ノード１２と共有されているため、高優先度のセンサデータ２６を含むブロック２８は、必ずしも第１マスターノード１６に迅速に送信される必要はない。このように、高優先度のセンサデータ２６を含むブロック２８は、レガシープロトコルを用いて車両ノード１２から第１マスターノード１６に転送される。

ステップＳ１２０でセンサデータ２６は高優先度に判定されなかった場合（ステップＳ１２０：ＮＯ）、車両ＥＣＵ３０は、ステップＳ１４０でセンサデータ２６が中間優先度であるか否かを判定する。センサデータ２６が中間優先度であると判断された場合（ステップＳ１４０：ＹＥＳ）、処理はステップＳ１７０に進む。逆に、センサデータ２６は中間優先度であると判定されない場合（ステップＳ１４０：ＮＯ）、処理はステップＳ１８０に進む。ステップＳ１７０において、車両ＥＣＵ３０は、第１スペック３６ａに従ってセンサデータ２６をマイニングし、ブロック２８を作成する。このとき、車両ＥＣＵ３０は、第１スペック３６ａに従って、ＰｏＡプロトコルを用いてセンサデータ２６をマイニングしてもよい。そして、車両ＥＣＵ３０は、ステップＳ１９０において、中間優先度のセンサデータ２６を含むブロック２８を、コンパクト中継プロトコルを用いて、第１ゾーン内の他の車両ノード１２へブロードキャストする。さらに、車両ＥＣＵ３０は、ステップＳ１９０において、コンパクト中継プロトコルを用いて、中間優先度のセンサデータ２６を含むブロック２８を、第１路側機２０を介して第１マスターノード１６に送信する。このように、センサデータ２６が中間優先度であると判定された場合、当該センサデータ２６はマイニングされた後、他の車両ノード１２と共有される。しかし、中間優先度のセンサデータ２６を含むブロック２８を第１マスターノード１６及び他のノード１２にブロードキャストする際には、帯域を削減するように、当該ブロックはコンパクトブロック中継プロトコルを用いて転送される。

センサデータ２６が中間優先度のデータであると判定されない場合（ステップＳ１４０：ＮＯ）、車両ＥＣＵ３０は、ステップＳ１８０にてセンサデータ２６が低優先度のデータであると判定する。そして、車両ＥＣＵ３０は、Ｓ２００において、第１スペック３６ａに従ってセンサデータ２６をマイニングし、低優先度のセンサデータ２６を含むブロック２８を作成する。このとき、車両ＥＣＵ３０は、第１スペック３６ａに従い、ＰｏＷプロトコルを用いてセンサデータ２６をマイニングしてよい。車両ＥＣＵ３０は、ステップＳ２１０において、レガシープロトコルを用いて、そのブロック２８を第１ゾーン内の他の車両ノード１２にブロードキャストする。さらに、車両ＥＣＵ３０は、ステップＳ２１０において、レガシープロトコルを用いて、低優先度のセンサデータを含むブロック２８を、第１路側機２０を介して第１マスターノード１６に送信する。このように、センサデータ２６が低優先度のデータである場合、センサデータ２６をマイニングした後、第１マスターノード１６と他の車両ノード１２とでセンサデータ２６を共有する。さらに、センサデータ２６は低優先度である場合には、迅速に共有する必要がないため、当該センサデータ２６を含むブロック２８はレガシープロトコルで転送される。

＜ブロック共有処理＞
次に、第１マスターノード１６と第２マスターノード１８との間で実行されるブロック共有処理について、図９を参照しながら以下に説明する。以下では、第１ゾーンで作成されたブロック２８が、第１マスターノード１６から第２マスターノード１８に共有される場合について説明する。

ステップＳ３００において、第１マスターノード１６は、第１ゾーン内の車両ノード１２からブロック２８を取得したか否かを判定する。第１マスターノード１６が車両ノード１２からブロック２８を取得した場合（ステップＳ３００：ＹＥＳ）、第１マスターノード１６は、ステップＳ３１０において、ブロック２８に含まれるセンサデータ２６の特徴を決定する。そして、第１マスターノード１６は、ステップＳ３２０において、センサデータ２６の特徴に基づいて、センサデータ２６が共有されるべきか否かを判定する。第１マスターノード１６は、センサデータ２６を共有すべきでないと判断した場合（Ｓ３２０：ＮＯ）、その処理を終了する。逆に、第１マスターノード１６は、特定のブロック２８ａに関し、センサデータ２６を第２マスターノード１８と共有すべきと判断した場合（Ｓ３２０：ＹＥＳ）、ステップＳ３３０において、光ファイバ４４を介して第２マスターノード１８にブロック２８ａ（図４参照）を送信する。

第２マスターノード１８は、第１マスターノード１６からブロック２８ａを受信すると、ステップＳ３４０において、第１マスターノード１６から受信したブロック２８ａに含まれるセンサデータ２６をマイニングして、新たなブロック２８ｂを作成する。このとき、第２マスターノード１８は、第２スペック３６ｂに従って、センサデータ２６をマイニングする。そして、第２マスターノード１８は、ステップＳ３５０において、共有されたセンサデータ２６を含む新たなブロック２８ｂを、第２ブロックチェーン１４ｂに追加する。さらに、第２マスターノード１８は、ステップＳ３６０において、第１マスターノード１６から共有されたセンサデータ２６を、第２ゾーン内の車両ノード１２にブロードキャストする。代替的な実装では、ステップＳ３５０で新しいブロック２８ｂを第２ブロックチェーン１４ｂに追加することによって、この新しいブロック２８ｂは、第２ブロックチェーン１４ｂと同じ分散システム内の他のすべてのノード、すなわち第２ゾーンのすべての車両ノード１２と共有されることになるので、ステップＳ３６０はスキップされてよい。

このように、第１マスターノード１６は、センサデータ２６は共有されるべきと判定した場合、当該センサデータ２６を含むブロック２８ａを第２マスターノード１８に送信する。そして、第２マスターノード１８は、第１マスターノード１６から受信したセンサデータ２６を第２ゾーン内の車両ノード１２にブロードキャストする。したがって、第１及び第２マスターノード１６、１８の間でブロック２８ａが交換されることにより、第２ゾーンの車両ノード１２は第１ゾーンで感知された関連情報を得ることができる。さらに、第２マスターノード１８は、第１マスターノード１６がマイニングしたブロック２８ａを取得するので、第２マスターノード１８が作成した新たなブロック２８ｂと第１マスターノード１６から受け取ったブロック２８ａとを比較することにより、第１ブロックチェーン１４ａの真偽を検証することができる。

以上のように、本実施形態によるゾーンベースのブロックチェーンシステム１０は、第１ゾーン及び第２ゾーンにそれぞれ関連付けられた第１ブロックチェーン１４ａ及び第２ブロックチェーン１４ｂを作成及び保存することができる。すなわち、第１ゾーン内の車両ノード１２及び第１マスターノード１６は、第１ゾーンが設定されているエリアの特性に鑑みてカスタマイズされた第１スペック３６ａに従って、ブロック２８を作成する。同様に、第２ゾーン内の車両ノード１２及び第２マスターノード１８は、第２ゾーンが設定されているエリアの特性を考慮してカスタマイズされた第２スペック３６ｂに従って、ブロック２８を作成する。したがって、システムは、対応するゾーンの条件や、状況、事情などが反映されたブロックチェーン１４を作成し、保存することができる。その結果、ゾーンベースのブロックチェーンシステム１０は、安全に保存され、且つ、各ゾーンの特性にカスタマイズされたブロックチェーン１４に関する情報を、例えば保険会社に提供可能となる。すなわち、ブロックチェーン１４を各ゾーンに合わせて適切にカスタマイズすることで、ブロックチェーン１４に含まれる情報の価値を向上させることができる。

本明細書で使用される言葉は、限定ではなく説明の言葉であり、本開示の精神及び範囲から逸脱することなく、様々な変更がなされ得ることが理解される。先に説明したように、様々な実施形態の特徴を組み合わせて、明示的に説明又は図示されていないさらなる実施形態を形成することができる。様々な実施形態が１つ又は複数の所望の特性に関して、他の実施形態又は先行技術の実装に対し、利点を有する又は好適であると説明された。一方、特定の用途及び実装に依存する所望の全体的なシステム属性を達成するために、１つ又は複数の特徴又は特性が妥協されて良いことは当業者であれば認識可能である。このように、１つ以上の特性に関して他の実施形態又は先行技術の実装よりも望ましくないとして説明される実施形態は、本開示の範囲外ではなく、特定の用途に望ましい場合がある。

Claims (16)

1. 第１物理ゾーンに関連する第１ブロックチェーン（１４ａ）を格納する第１マスターノード（１６）と、
   第２物理ゾーンに関連する第２ブロックチェーン（１４ｂ）を格納する第２マスターノード（１８）と、を含むゾーンベースのブロックチェーンシステムであって、
   第１マスターノード（１６）は、前記第１物理ゾーンの内部に存在する車両の車両ノード（１２）を追加し、且つ、前記第１物理ゾーンの外にある車両の車両ノード（１２）を削除することによって、前記第１ブロックチェーン（１４ａ）内に存在するノードのリスト（５０）を維持するようにプログラムされており、
   前記第１ブロックチェーン（１４ａ）は、前記第１物理ゾーン内に存在する複数の車両によって感知されたセンサデータ（２６）を有するようにマイニングされた複数のブロック（２８）を含み、
   前記第２マスターノード（１８）は、前記第２物理ゾーンの内部に存在する車両の車両ノード（１２）を追加し、且つ、前記第１物理ゾーンの外にある車両の車両ノード（１２）を削除することによって、前記第２ブロックチェーン（１４ｂ）内に存在するノードのリスト（５０）を維持するようにプログラムされており、
   前記第２ブロックチェーン（１４ｂ）は、前記第２物理ゾーン内に存在する複数の車両によって感知されたセンサデータ（２６）を有するようにマイニングされた複数のブロック（２８）を含み、
   前記第１物理ゾーンは、前記第２物理ゾーンとは異なるゾーンであり、
   前記第１ブロックチェーンと前記第２ブロックチェーンは、互いに異なるスペックを有する、ゾーンベースのブロックチェーンシステム。
2. 前記第１マスターノード（１６）は、前記第１ブロックチェーン（１４ａ）において特定のブロック（２８ａ）がマイニングされたことを受けて、
   前記特定のブロック（２８ａ）に含まれる前記センサデータ（２６）の特徴に基づいて、前記特定のブロック（２８ａ）が共有されるべきかどうかを決定することと、
   前記特定のブロック（２８ａ）が共有されるべきであると決定したことを受けて、前記特定のブロック（２８ａ）を前記第２マスターノード（１８）に送信することと、
   を実行するようにプログラムされており、
   前記第２マスターノードは、前記第１マスターノードから前記特定のブロックを受信したことを受けて、前記特定のブロック（２８ａ）に含まれる前記センサデータ（２６）に基づき、前記第２ブロックチェーン（１４ｂ）のための新しいブロック（２８ｂ）をマイニングするようにプログラムされている、請求項１に記載のゾーンベースのブロックチェーンシステム。
3. 前記第２マスターノードは、前記第２ブロックチェーン（１４ｂ）における前記新しいブロック（２８ｂ）と第１ブロックチェーン（１４ａ）の前記特定のブロック（２８ａ）とを比較することによって、第１ブロックチェーン（１４ａ）の真正性を検証するようにプログラムされている、請求項２に記載のゾーンベースのブロックチェーンシステム。
4. 車両ＥＣＵ（３０）を備える特定の車両を更に備え、
   前記特定の車両が前記第１物理ゾーンに入った場合に、前記車両ＥＣＵ（３０）は、
   前記第１ブロックチェーン（１４ａ）に参加するための通信要求を前記第１マスターノード（１６）に送信することと、
   前記第１マスターノード（１６）から前記第１ブロックチェーン（１４ａ）のスペック（３６）を受信することと、
   前記第１ブロックチェーン（１４ａ）のスペック（３６）に従って、センサデータ（２６）をマイニングすることと、
   を実施するようにプログラムされている、請求項１から３のいずれか１項に記載のゾーンベースのブロックチェーンシステム。
5. 前記第１マスターノード（１６）は、前記特定の車両から前記通信要求を受信したことを受けて、前記第１ブロックチェーン（１４ａ）の前記スペック（３６）を前記特定の車両に送信する前に、前記特定の車両を検証するための許可リスト（４６）を確認するようにプログラムされている、請求項４に記載のゾーンベースのブロックチェーンシステム。
6. 前記車両ＥＣＵは、
   前記センサデータ（２６）をマイニングすることにより、前記第１ブロックチェーン（１４ａ）のためのブロック（２８）を生成することと、
   前記第１物理ゾーンを通信エリアとして定義する路側機（２０）を介して、前記ブロック（２８）を前記第１マスターノード（１６）にアップロードすることと、
   を実行するようにプログラムされている、請求項４又は５に記載のゾーンベースのブロックチェーンシステム。
7. 前記第１物理ゾーンは、前記第２物理ゾーンに隣接している、請求項１から６のいずれか１項に記載のゾーンベースのブロックチェーンシステム。
8. 前記第１物理ゾーンと前記第２物理ゾーンとの間を移動するように構成された特定の車両を更に備え、
   前記特定の車両は、
   前記第１物理ゾーン内にあるときは、前記第１ブロックチェーン（１４ａ）の前記スペック（３６）に従ってセンサデータ（２６）をマイニングすることにより前記第１ブロックチェーン（１４ａ）における車両ノード（１２）として作動し、
   前記第２物理ゾーン内にあるときは、前記第２ブロックチェーン（１４ｂ）の前記スペック（３６）に従ってセンサデータ（２６）をマイニングすることにより前記第２ブロックチェーン（１４ｂ）における車両ノード（１２）として作動するように構成されている請求項１から７のいずれか１項に記載のゾーンベースのブロックチェーンシステム。
9. ゾーンベースのブロックチェーンシステムを運用するための方法であって、
   第１マスターノード（１６）が、第１物理ゾーンの内部に存在する車両の車両ノード（１２）を追加し、且つ、前記第１物理ゾーン外の車両の車両ノード（１２）を削除することにより、前記第１物理ゾーンに関連付けられた第１ブロックチェーン（１４ａ）のためのノードのリスト（５０）を維持することと、
   前記第１マスターノード（１６）が、前記第１物理ゾーンの内部にいる複数の車両によって感知されたセンサデータ（２６）を有するようにマイニングされた複数のブロック（２８）を含む前記第１ブロックチェーン（１４ａ）を保存することと、
   第２マスターノード（１８）が、第２物理ゾーンの内部に存在する車両の車両ノード（１２）を追加し、且つ、前記第２物理ゾーン外の車両の車両ノード（１２）を削除することによって、前記第２物理ゾーンに関連する第２ブロックチェーン（１４ｂ）のノードのリスト（５０）を維持することと、
   前記第２マスターノード（１８）が、前記第２物理ゾーンの内部にいる複数の車両によって感知されたセンサデータ（２６）を有するようにマイニングされた複数のブロック（２８）を含む前記第２ブロックチェーン（１４ｂ）を保存することと、を含み、
   前記第１物理ゾーンは、前記第２物理ゾーンとは異なっており、
   前記第１ブロックチェーンと前記第２ブロックチェーンは、互いに異なるスペックを有する、方法。
10. 前記第１ブロックチェーン（１４ａ）において特定のブロック（２８ａ）がマイニングされたことを受けて、前記第１マスターノード（１６）が、前記特定のブロック（２８ａ）における前記センサデータ（２６）の特徴に基づき、前記特定のブロック（２８）が共有されるべきかどうかを決定することと、
    前記特定のブロック（２８ａ）が共有されるべきであると決定したことを受けて、前記第１マスターノード（１６）が、前記特定のブロック（２８ａ）を前記第２マスターノード（１８）に送信することと、
    前記第１マスターノード（１６）から前記特定のブロック（２８ａ）を受信したことを受けて、前記第２マスターノード（１８）が、前記特定のブロック（２８ａ）に含まれる前記センサデータ（２６）に基づき、前記第２ブロックチェーン（１４ｂ）のための新しいブロック（２８ｂ）をマイニングすることと、をさらに含む、請求項９に記載の方法。
11. 前記第２マスターノード（１８）が、前記第２ブロックチェーン（１４ｂ）の前記新しいブロック（２８ｂ）と、前記第１ブロックチェーン（１４ａ）の前記特定のブロック（２８ａ）と、を比較することによって、前記第１ブロックチェーン（１４ａ）の真正性を検証することをさらに含む、請求項１０に記載の方法。
12. 車両ＥＣＵ（３０）を有する特定の車両が前記第１物理ゾーンに進入した場合に、前記車両ＥＣＵ（３０）が、前記第１ブロックチェーン（１４ａ）に参加するための通信要求を前記第１マスターノード（１６）へ送信することと、
    前記車両ＥＣＵ（３０）が、前記第１マスターノード（１６）から前記第１ブロックチェーン（１４ａ）の前記スペック（３６）を受信することと、
    前記車両ＥＣＵ（３０）が、前記第１ブロックチェーン（１４ａ）の前記スペック（３６）に従ってセンサデータ（２６）をマイニングすることと、を含む、請求項９から１１のいずれか１項に記載の方法。
13. 前記第１マスターノード（１６）が、前記特定の車両からの前記通信要求を受信したことを受けて、前記第１ブロックチェーン（１４ａ）の前記スペック（３６）を前記特定の車両に送信する前に、前記特定の車両を検証するための許可リスト（４６）を確認することをさらに含む、請求項１２に記載の方法。
14. 前記車両ＥＣＵ（３０）が、前記センサデータ（２６）をマイニングすることにより、前記第１ブロックチェーン（１４ａ）のためのブロック（２８）を生成することと、
    前記車両ＥＣＵ（３０）が、前記第１物理ゾーンを通信エリアとして定義する路側機（２０）を介して、前記ブロック（２８）を前記第１マスターノード（１６）にアップロードすることと、を含む、請求項１２又は１３に記載の方法。
15. 前記第１物理ゾーンは、前記第２物理ゾーンに隣接している、請求項９から１４のいずれか１項に記載の方法。
16. 前記第１物理ゾーンと前記第２物理ゾーンとの間を移動するように構成された特定の車両を含み、
    前記特定の車両が前記第１物理ゾーン内にある場合、前記特定の車両が、前記第１ブロックチェーン（１４ａ）の前記車両ノード（１２）として、前記第１ブロックチェーン（１４ａ）の前記スペック（３６）に従ってセンサデータ（２６）をマイニングすることと、
    前記特定の車両が前記第２物理ゾーン内にある場合、前記特定の車両が、前記第２ブロックチェーン（１４ｂ）の車両ノード（１２）として、前記第２ブロックチェーン（１４ｂ）の前記スペック（３６）に従ってセンサデータ（２６）をマイニングすることと、を含む請求項１５に記載の方法。

Images