特開 2023-83228 ブロックチェーントランザクションデータ格納方法、装置およびこれを用いた分散格納システム

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

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

(11)【公開番号】P2023083228

(43)【公開日】2023-06-15

(54)【発明の名称】ブロックチェーントランザクションデータ格納方法、装置およびこれを用いた分散格納システム

(51)【国際特許分類】

   G06F 16/182 20190101AFI20230608BHJP

   G06F 16/13 20190101ALI20230608BHJP

【ＦＩ】

G06F16/182

G06F16/13

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

(21)【出願番号】P 2022186857

(22)【出願日】2022-11-22

(31)【優先権主張番号】10-2021-0172413

(32)【優先日】2021-12-03

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2022-0145312

(32)【優先日】2022-11-03

(33)【優先権主張国・地域又は機関】KR

(71)【出願人】

【識別番号】596180076

【氏名又は名称】韓國電子通信研究院

【氏名又は名称原語表記】Ｅｌｅｃｔｒｏｎｉｃｓ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ

【住所又は居所原語表記】２１８，Ｇａｊｅｏｎｇ－ｒｏ Ｙｕｓｅｏｎｇ－ｇｕ Ｄａｅｊｅｏｎ ３４１２９，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ

(74)【代理人】

【識別番号】100120031

【弁理士】

【氏名又は名称】宮嶋 学

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100152205

【弁理士】

【氏名又は名称】吉田 昌司

(72)【発明者】

【氏名】イ、ミョン－チョル

(57)【要約】      （修正有）

【課題】ブロックチェーントランザクションデータを参加ノードに重複格納する場合に発生する格納空間の無駄使いおよびデータ所有の集中化問題を解決するブロックチェーントランザクションデータ格納方法、装置及びシステムを提供する。
【解決手段】ブロックチェーントランザクションデータ格納方法は、ブロックチェーントランザクションを格納する少なくとも１つのブロックファイルをエンコーディングブロックファイル対象として選択するステップと、エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成するステップと、エンコーディングされたチャンクの少なくとも１つと、エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させるステップと、を含む。
【選択図】図１０

【特許請求の範囲】

【請求項1】

ブロックチェーントランザクションデータ格納装置によって行われるブロックチェーントランザクションデータ格納方法において、
ブロックチェーントランザクションを格納する少なくとも１つのブロックファイル（ｂｌｏｃｋ ｆｉｌｅ）をエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）として選択するステップと、
前記エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成するステップと、
前記エンコーディングされたチャンクの少なくとも１つと、前記エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させるステップと
を含むことを特徴とするブロックチェーントランザクションデータ格納方法。

【請求項2】

前記パリティチャンクは、Ｍ（Ｍは自然数）個であり、前記ブロックチェーンノードは、３Ｍ＋１個であり、前記エンコーディングされたチャンクは、３Ｍ＋１個であり、前記エンコーディングされたチャンクと前記ブロックチェーンノードとは、１：１対応することを特徴とする請求項１に記載のブロックチェーントランザクションデータ格納方法。

【請求項3】

前記ブロックチェーンノードそれぞれは、
前記エンコーディングされたチャンクのうち相応する１個のためにはエンコーディングされたチャンクをそのまま格納し、前記１個を除いた残りのチャンクの少なくとも一部のためにはハッシュ値のみ格納することを特徴とする請求項２に記載のブロックチェーントランザクションデータ格納方法。

【請求項4】

前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応するか否かを判断するステップと、
前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応しない場合、前記エンコーディングブロックファイル対象に含まれたブロックおよび前記エンコーディングブロックファイル対象に含まれたブロックの一部である複製ブロックを用いて２Ｍ＋１個のエンコーディング対象ブロックを生成するステップと
をさらに含み、
前記エンコーディングされたチャンクは、前記エンコーディング対象ブロックを用いたエンコーディングを行って生成されることを特徴とする請求項３に記載のブロックチェーントランザクションデータ格納方法。

【請求項5】

前記複製ブロックは、
アクセス頻度に基づき、前記エンコーディングブロックファイル対象に含まれたブロックの中から選択されることを特徴とする請求項４に記載のブロックチェーントランザクションデータ格納方法。

【請求項6】

前記エンコーディングブロックファイル対象は、
２Ｍ＋１個を超えない個数のブロックを含むことを特徴とする請求項２に記載のブロックチェーントランザクションデータ格納方法。

【請求項7】

２Ｍ＋１個を超えない個数のブロックは、
サイズがすべて同一でなく、前記エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディングされることを特徴とする請求項６に記載のブロックチェーントランザクションデータ格納方法。

【請求項8】

前記エンコーディングブロックファイル対象は、
前記ブロックチェーントランザクションを格納するブロックファイルの中から、前記ブロックファイルまたは前記ブロックファイルが含むブロックに対するアクセス頻度を考慮して選択されることを特徴とする請求項１に記載のブロックチェーントランザクションデータ格納方法。

【請求項9】

前記ハッシュ値は、
他のノードから読込んだブロックを検証するのに用いられることを特徴とする請求項３に記載のブロックチェーントランザクションデータ格納方法。

【請求項10】

前記エンコーディングされたチャンクのうち２Ｍ＋１個以上は、
前記エンコーディング対象ブロックを復元するデコーディングに用いられることを特徴とする請求項４に記載のブロックチェーントランザクションデータ格納方法。

【請求項11】

１つ以上のプロセッサと、
前記１つ以上のプロセッサによって実行される少なくとも１つ以上のプログラムを格納する実行メモリとを含み、
前記少なくとも１つ以上のプログラムは、
ブロックチェーントランザクションを格納する少なくとも１つのブロックファイル（ｂｌｏｃｋ ｆｉｌｅ）をエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）として選択し、
前記エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成し、
前記エンコーディングされたチャンクの少なくとも１つと、前記エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させることを特徴とするブロックチェーントランザクションデータ格納装置。

【請求項12】

前記パリティチャンクは、Ｍ（Ｍは自然数）個であり、前記ブロックチェーンノードは、３Ｍ＋１個であり、前記エンコーディングされたチャンクは、３Ｍ＋１個であり、前記エンコーディングされたチャンクと前記ブロックチェーンノードとは、１：１対応することを特徴とする請求項１１に記載のブロックチェーントランザクションデータ格納装置。

【請求項13】

前記ブロックチェーンノードそれぞれは、
前記エンコーディングされたチャンクのうち相応する１個のためにはエンコーディングされたチャンクをそのまま格納し、前記１個を除いた残りのチャンクの少なくとも一部のためにはハッシュ値のみ格納することを特徴とする請求項１２に記載のブロックチェーントランザクションデータ格納装置。

【請求項14】

前記少なくとも１つ以上のプログラムは、
前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応するか否かを判断し、
前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応しない場合、前記エンコーディングブロックファイル対象に含まれたブロックおよび前記エンコーディングブロックファイル対象に含まれたブロックの一部である複製ブロックを用いて２Ｍ＋１個のエンコーディング対象ブロックを生成し、
前記エンコーディングされたチャンクは、前記エンコーディング対象ブロックを用いたエンコーディングを行って生成されることを特徴とする請求項１３に記載のブロックチェーントランザクションデータ格納装置。

【請求項15】

前記複製ブロックは、
アクセス頻度に基づき、前記エンコーディングブロックファイル対象に含まれたブロックの中から選択されることを特徴とする請求項１４に記載のブロックチェーントランザクションデータ格納装置。

【請求項16】

前記エンコーディングブロックファイル対象は、
サイズがすべて同一でないブロックを含み、
前記サイズがすべて同一でないブロックは、
前記エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディングされることを特徴とする請求項１２に記載のブロックチェーントランザクションデータ格納装置。

【請求項17】

前記エンコーディングブロックファイル対象は、
前記ブロックチェーントランザクションを格納するブロックファイルの中から、前記ブロックファイルまたは前記ブロックファイルが含むブロックに対するアクセス頻度を考慮して選択されることを特徴とする請求項１１に記載のブロックチェーントランザクションデータ格納装置。

【請求項18】

前記ハッシュ値は、
他のノードから読込んだブロックを検証するのに用いられることを特徴とする請求項１３に記載のブロックチェーントランザクションデータ格納装置。

【請求項19】

前記エンコーディングされたチャンクのうち２Ｍ＋１個以上は、
前記エンコーディング対象ブロックを復元するデコーディングに用いられることを特徴とする請求項１４に記載のブロックチェーントランザクションデータ格納装置。

【請求項20】

エンコーディングされたチャンクのうち第１チャンクをそのまま格納し、前記第１チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第１ブロックチェーンノードと、
前記第１チャンクと異なる第２チャンクをそのまま格納し、前記第２チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第２ブロックチェーンノードとを含み、
前記エンコーディングされたチャンクは、それぞれブロックチェーントランザクションを格納するブロックファイル（ｂｌｏｃｋ ｆｉｌｅｓ）の中から選択されたエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）を用いて行われたエンコーディングに基づいて生成されることを特徴とするブロックチェーントランザクションデータ分散格納システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ブロックチェーントランザクションデータ格納システムに関し、特に、ブロックチェーントランザクションデータをビザンチン障害耐性を保障（ｇｕａｒａｎｔｅｅｉｎｇ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）しながら多数の参加ノードに分散格納することにより、全体ブロックチェーンシステムのトランザクションデータ格納容量を拡張する技術に関する。

【背景技術】

【0002】

信頼できる第三者に対する個人データの所有集中化問題、そして信頼できる第三者に対する個人データの流出および操作などの問題を解決するために、相互信頼しない多数の参加者の間に分散した帳簿を保持し、これによりデータの無欠性および信頼性を確保するブロックチェーン技術が注目されている。

【0003】

最近、ビットコイン、イーサリアムなどの仮想通貨の価値が急騰するにつれて仮想通貨の取引も急増し、ブロックチェーン技術に対する関心も急激に増加している。ブロックチェーン技術は、既存の仮想通貨関連分野だけでなく、一般産業およびビジネスへとその活用領域の拡張を試みている。

【0004】

多様な産業分野でブロックチェーンを活用した応用サービスの開発および事業化を試みているが、合意、格納、分析などブロックチェーンが有する拡張性の限界によって多くの試みが失敗してきており、依然としてブロックチェーン技術は仮想通貨を中心に活用されている。

【0005】

ブロックチェーン格納階層の拡張性の問題としては、ブロックチェーンの活用性が増加すれば、結局、格納される元帳（ｌｅｄｇｅｒ；トランザクションデータと状態データとで構成）の大きさが急激に増加するということである。元帳の大きさが急激に増加すれば、一般水準の個人用コンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ；ＰＣ）やサーバではこれを格納または処理することが不可能になる。

【0006】

ビットコイン（Ｂｉｔｃｏｉｎ）、イーサリアム（Ｅｔｈｅｒｅｕｍ）およびハイパーレジャーファブリック（Ｈｙｐｅｒｌｅｇｅｒ Ｆａｂｒｉｃ）など大多数のブロックチェーンプラットフォームにおいて、元帳はデータまたは資産（ａｓｓｅｔ）の最新状態データを管理する状態データと、状態の変化を発生させるトランザクションの履歴を管理するトランザクションデータとで構成される。状態データは、通常、ＬｅｖｅｌＤＢ、ＲｏｃｋｓＤＢ、ＣｏｕｃｈＤＢなどのキー／バリューストアまたはドキュメントストアを用いて管理され、トランザクションデータは、ファイルシステム上のファイル（ビットコインまたはハイパーレジャーファブリックの場合）またはキー／バリューストア（イーサリアムの場合）を用いて管理される。

【0007】

特に、トランザクションデータは、予め設定された大きさを有するブロックで集められて、参加ノードの合意、検証などの過程を経て最終状態データに反映され、このように合意されたブロックは互いに連結されて多数の参加ノードに分散格納されて共有帳簿としての役割を果たす。これにより、データの無欠性および信頼性が確保できる。

【0008】

ところが、ブロックチェーンのトランザクションデータは、すべての参加ノードに重複して格納され、このため、過度なディスク／メモリ容量を要求することが問題である。

【0009】

ビットコイントランザクションデータは、２０１９年４月に約２１３ＧＢであり、２０２１年１０月ベースで約３６０ＧＢに達し、これは２０１９年に比べて約１５０ＧＢ程度増加した数値である。

【0010】

このようなブロックチェーントランザクションデータの急激な増加および重複格納方式によってブロックチェーンネットワークに新規参加するノードは、既存のトランザクションデータを受信するために、数日または数週間にわたって時間を消費しなければならず、非常に高い水準のコンピューティング資源および能力を保有したノードだけがフルノード（Ｆｕｌｌ Ｎｏｄｅ）としてブロックチェーンに参加できる。これは大規模マイニングプールのシェアが増加する結果につながり、結局、脱中央化に逆行して、再びデータ所有の中央化をもたらす問題が生じた。

【0011】

ブロックチェーントランザクションデータを参加ノードに重複格納せずに分散格納して、ストレージの容量問題と性能問題を解決するための目的で、最近、分散ハッシュテーブル（ＤＨＴ；Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）、シャーディング（ｓｈａｒｄｉｎｇ）およびイレイジャーコード（ＥＣ；Ｅｒａｓｕｒｅ Ｃｏｄｅ）などを活用した多様なブロックチェーントランザクション分散格納方法が提案されてきている。

【0012】

大規模データをネットワーク上の参加ノードに分散して格納し管理する技術である分散ハッシュテーブル（ＤＨＴ）ベース技術の場合、一部の研究機関が初期研究を行っているが、大多数の研究が実際の実現まで行かずに理論的な水準でのみ議論されており、一部実現された技術はビザンチン障害耐性を保障するか否かに対する検証が不十分であり、実際の使用には未だに多くのさらなる研究および検証が必要な状況である。

【0013】

データを複数の論理的なグループに分割格納する技術であるシャーディング（ｓｈａｒｄｉｎｇ）ベース技術は、トランザクションデータを主にアカウントベースで分割して当該シャード内でのみデータを重複格納し、これにより元帳の容量増加に対処する技術であるが、互いに異なるシャード間の取引時に処理が複雑であり、シャード内ではデータが依然として重複し、悪意ある攻撃に脆弱という問題などが指摘されている。

【0014】

通信システムとストレージシステムで主に活用されていたデータ可用性（ｄａｔａ ａｖａｉｌａｂｉｌｉｔｙ）保障手法であるＥＣＣ（Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ Ｃｏｄｅ）、ＥＣ（Ｅｒａｓｕｒｅ Ｃｏｄｅ）などエンコーディング技術に基づくブロックチェーントランザクションデータの分割および分散格納手法などが最近研究されているが、ビザンチン障害耐性の保障、エンコーディング／デコーディングオーバーヘッド、分割分散格納されたブロックの読込み性能、参加ノードの追加／削除時の再エンコーディングの必要性など解決すべき問題が少なくない。

【0015】

２０２０年に公開されたＩＥＥＥ論文「ＢＦＴ－Ｓｔｏｒｅ：Ｓｔｏｒａｇｅ Ｐａｒｔｉｔｉｏｎ ｆｏｒ Ｐｅｒｍｉｓｓｉｏｎｅｄ Ｂｌｏｃｋｃｈａｉｎ ｖｉａ Ｅｒａｓｕｒｅ Ｃｏｄｉｎｇ」は、多数のブロックを対象にイレイジャーコーディングを適用してエンコーディングされたブロックを生成し、これを複数のノードに分散格納する技術を提案しているが、実際にブロックがファイルなどに格納される環境を考慮していないので、既存のブロックチェーンシステムへの適用が難しく、アクセス頻度、計算負荷や格納空間の効率性を考慮していないので、効率性が低下する。

【0016】

韓国公開特許第１０－２０２１－００５８７４４号は、１つ以上のブロックにエンコーディングを適用し、エンコーディングされたブロックをブロックチェーンネットワークのすべての参加ノードに分割して格納する技術を提案しているが、エンコーディングされたデータへのアクセスが発生する場合には、毎回多数のノードからエンコーディングされたブロックを収集しデコーディングしなければデータへのアクセスが不可能という問題がある。

【0017】

したがって、実際にブロックのブロックチェーン格納状況を考慮して最適な性能を保障し、エンコーディングされたブロックへのアクセスの際、これをより効率的に処理できる新たなブロックチェーン分散格納技術の必要性が切実になっている。

【発明の概要】

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

【0018】

本発明の目的は、ブロック形態で表現されてファイル形態でファイルシステムに格納されるブロックチェーントランザクションデータをビザンチン障害耐性を保障しながら多数の参加ノードに分散格納して、トランザクションデータを参加ノードに重複格納する場合に発生する格納空間の無駄使いおよびデータ所有の集中化問題を解決することである。

【0019】

また、本発明の目的は、ブロックチェーンシステムの格納空間管理の効率性を向上させて、ブロックチェーン技術が多様な産業分野の大規模な格納／管理に活用できるようにすることである。

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

【0020】

上記の目的を達成するための、本発明によるブロックチェーントランザクションデータ格納装置によって行われるブロックチェーントランザクションデータ格納方法は、ブロックチェーントランザクションを格納する少なくとも１つのブロックファイル（ｂｌｏｃｋ ｆｉｌｅ）をエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）として選択するステップと、前記エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成するステップと、前記エンコーディングされたチャンクの少なくとも１つと、前記エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させるステップとを含む。

【0021】

この時、パリティチャンクは、Ｍ（Ｍは自然数）個であり、前記ブロックチェーンノードは、３Ｍ＋１個であり、前記エンコーディングされたチャンクは、３Ｍ＋１個であり、前記エンコーディングされたチャンクと前記ブロックチェーンノードとは、１：１対応できる。

【0022】

この時、ブロックチェーンノードそれぞれは、前記エンコーディングされたチャンクのうち相応する１個のためにはエンコーディングされたチャンクをそのまま格納し、前記１個を除いた残りのチャンクの少なくとも一部のためにはハッシュ値のみ格納することができる。

【0023】

この時、ブロックチェーントランザクションデータ格納方法は、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応するか否かを判断するステップと、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応しない場合、前記エンコーディングブロックファイル対象に含まれたブロックおよび前記エンコーディングブロックファイル対象に含まれたブロックの一部である複製ブロックを用いて２Ｍ＋１個のエンコーディング対象ブロックを生成するステップとをさらに含むことができる。この時、前記エンコーディングされたチャンクは、前記エンコーディング対象ブロックを用いたエンコーディングを行って生成される。

【0024】

この時、複製ブロックは、アクセス頻度に基づき、前記エンコーディングブロックファイル対象に含まれたブロックの中から選択される。

【0025】

この時、エンコーディングブロックファイル対象は、２Ｍ＋１個を超えない個数のブロックを含むことができる。

【0026】

この時、２Ｍ＋１個を超えない個数のブロックは、サイズがすべて同一でなく、前記エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディングされる。

【0027】

この時、エンコーディングブロックファイル対象は、前記ブロックチェーントランザクションを格納するブロックファイルの中から、前記ブロックファイルまたは前記ブロックファイルが含むブロックに対するアクセス頻度を考慮して選択される。

【0028】

この時、ハッシュ値は、他のノードから読込んだブロックを検証するのに用いられる。

【0029】

この時、エンコーディングされたチャンクのうち２Ｍ＋１個以上は、前記エンコーディング対象ブロックを復元するデコーディングに用いられる。

【0030】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納装置は、１つ以上のプロセッサと、前記１つ以上のプロセッサによって実行される少なくとも１つ以上のプログラムを格納する実行メモリとを含む。

【0031】

この時、前記少なくとも１つ以上のプログラムは、ブロックチェーントランザクションを格納する少なくとも１つのブロックファイル（ｂｌｏｃｋ ｆｉｌｅ）をエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）として選択し、前記エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成し、前記エンコーディングされたチャンクの少なくとも１つと、前記エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させることができる。

【0032】

この時、パリティチャンクは、Ｍ（Ｍは自然数）個であり、前記ブロックチェーンノードは、３Ｍ＋１個であり、前記エンコーディングされたチャンクは、３Ｍ＋１個であり、前記エンコーディングされたチャンクと前記ブロックチェーンノードとは、１：１対応できる。

【0033】

この時、ブロックチェーンノードそれぞれは、前記エンコーディングされたチャンクのうち相応する１個のためにはエンコーディングされたチャンクをそのまま格納し、前記１個を除いた残りのチャンクの少なくとも一部のためにはハッシュ値のみ格納することができる。

【0034】

この時、少なくとも１つ以上のプログラムは、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応するか否かを判断し、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応しない場合、前記エンコーディングブロックファイル対象に含まれたブロックおよび前記エンコーディングブロックファイル対象に含まれたブロックの一部である複製ブロックを用いて２Ｍ＋１個のエンコーディング対象ブロックを生成することができる。この時、前記エンコーディングされたチャンクは、前記エンコーディング対象ブロックを用いたエンコーディングを行って生成される。

【0035】

この時、複製ブロックは、アクセス頻度に基づき、前記エンコーディングブロックファイル対象に含まれたブロックの中から選択される。

【0036】

この時、エンコーディングブロックファイル対象は、サイズがすべて同一でないブロックを含み、前記サイズがすべて同一でないブロックは、前記エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディングされる。

【0037】

この時、エンコーディングブロックファイル対象は、前記ブロックチェーントランザクションを格納するブロックファイルの中から、前記ブロックファイルまたは前記ブロックファイルが含むブロックに対するアクセス頻度を考慮して選択される。

【0038】

この時、ハッシュ値は、他のノードから読込んだブロックを検証するのに用いられる。

【0039】

この時、エンコーディングされたチャンクのうち２Ｍ＋１個以上は、前記エンコーディング対象ブロックを復元するデコーディングに用いられる。

【0040】

また、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムは、エンコーディングされたチャンクのうち第１チャンクをそのまま格納し、前記第１チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第１ブロックチェーンノードと、前記第１チャンクと異なる第２チャンクをそのまま格納し、前記第２チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第２ブロックチェーンノードとを含む。

【0041】

この時、エンコーディングされたチャンクは、それぞれブロックチェーントランザクションを格納するブロックファイル（ｂｌｏｃｋ ｆｉｌｅｓ）の中から選択されたエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）を用いて行われたエンコーディングに基づいて生成される。

【発明の効果】

【0042】

本発明によれば、既存のブロックチェーンシステムにおいて、データの信頼性保障のためにブロックチェーンネットワーク参加ノードにトランザクションデータを重複格納することによって、ブロックチェーンネットワーク参加ノードを増加させても、トランザクションデータの格納空間容量および空間の効率性の面での拡張性が制限される問題を解決することができる。

【0043】

また、本発明によれば、ブロックチェーントランザクションデータをビザンチン障害耐性を保障しながら多数の参加ノードに分散格納して、格納空間の効率性を高め、各参加ノードの格納空間の使用を最小化することができる。

【0044】

さらに、本発明によれば、参加ノードの格納空間の効率性が向上し、各参加ノードの格納空間の使用を最小化して、結果的に全体ブロックチェーンシステムの格納容量が極大化できる。

【図面の簡単な説明】

【0045】

【図1】本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムを示すブロック図である。

【図2】本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムの構造を示すブロック図である。

【図3】図２に示されたブロックチェーンデータ管理器の一例を示すブロック図である。

【図4】本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムにおいてブロックチェーンデータの格納フローを示す図である。

【図5】ブロックファイル格納の概念を示すブロック図である。

【図6】ファイルシステムにブロックをブロックファイル形態で格納したブロックファイルリストの一例を示す図である。

【図7】ブロックファイル格納構造の一例を示す図である。

【図8】本発明の一実施例によるブロックファイル単位のエンコーディングが適用される場合の一例を示す図である。

【図9】本発明の一実施例によるブロックファイルエンコーディングに基づくブロックチェーントランザクションデータのエンコーディング方法の一例を示すブロック図である。

【図10】本発明の一実施例によるブロックチェーントランザクションデータ格納方法を示す動作フローチャートである。

【図11】多数のブロックファイルベースでブロックチェーントランザクションデータのエンコーディングが適用される一例を示す図である。

【図12】本発明の一実施例によるエンコーディング対象ブロックファイル選定方法を示す動作フローチャートである。

【図13】本発明の一実施例によるブロックアクセス方法の一例を示す動作フローチャートである。

【図14】本発明の一実施例によるブロックエラーを発見したノードの再エンコーディング方法の一例を示す動作フローチャートである。

【図15】本発明の一実施例による再エンコーディング要請を受信したノードの再エンコーディング方法の一例を示す動作フローチャートである。

【図16】本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムにおいて高頻度アクセスブロックチェーントランザクションデータの複製を示す図である。

【図17】本発明の一実施例によるコンピュータシステムの構成を示すブロック図である。

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

【0046】

本発明の利点および特徴、そしてそれらを達成する方法は添付した図面とともに詳細に後述する実施例を参照すれば明確になる。しかし、本発明は以下に開示される実施例に限定されるものではなく、互いに異なる多様な形態で実現され、単に本実施例は本発明の開示が完全となるようにし、本発明の属する技術分野における通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範疇によってのみ定義される。明細書全体にわたって同一の参照符号は同一の構成要素を指し示す。

【0047】

たとえ、「第１」または「第２」などが多様な構成要素を記述するために使われるが、このような構成要素は前記のような用語によって制限されない。前記のような用語は単に１つの構成要素を他の構成要素と区別するために使われる。したがって、以下に言及される第１構成要素は、本発明の技術的思想内で第２構成要素であってもよい。

【0048】

本明細書で使われた用語は実施例を説明するためのものであり、本発明を制限しようとするものではない。本明細書において、単数形は、文言で特に言及しない限り、複数形も含む。明細書で使われる「含む（ｃｏｍｐｒｉｓｅｓ）」または「含む（ｃｏｍｐｒｉｓｉｎｇ）」は、言及された構成要素またはステップが１つ以上の他の構成要素またはステップの存在または追加を排除しないという意味を含む。

【0049】

他に定義がなければ、本明細書で使われるすべての用語は、本発明の属する技術分野における通常の知識を有する者に共通して理解できる意味で解釈される。また、一般的に使われる辞書に定義されている用語は、明らかに特に定義されていない限り、理想的または過度に解釈されない。

【0050】

以下、添付した図面を参照して、本発明の実施例を詳細に説明し、図面を参照して説明する時、同一または対応する構成要素は同一の図面符号を付し、これに関する重複した説明は省略することとする。

【0051】

図１は、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムを示すブロック図である。

【0052】

図１を参照すれば、ブロックチェーントランザクションデータ分散格納システムにおいて、ブロックのチェーン（ブロックチェーン）の形態でトランザクションの履歴を管理するトランザクションデータが参加ノードに重複して格納されれば、過度なディスク／メモリ容量が必要になる問題が生じうる。

【0053】

図１に示されたブロックチェーンノードは、エンコーディングされたチャンクのうち第１チャンクをそのまま格納し、前記第１チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第１ブロックチェーンノードと、前記第１チャンクと異なる第２チャンクをそのまま格納し、前記第２チャンクを除いた残りのチャンクに相応するハッシュ値を格納する第２ブロックチェーンノードとを含むことができる。この時、前記エンコーディングされたチャンクは、それぞれブロックチェーントランザクションを格納するブロックファイル（ｂｌｏｃｋ ｆｉｌｅｓ）の中から選択されたエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）を用いて行われたエンコーディングに基づいて生成される。この時、エンコーディングブロックファイル対象は、１つ以上のブロックファイルに相応するものであってもよい。例えば、エンコーディングブロックファイル対象は、１つのブロックファイルに相応してもよく、エンコーディングブロックファイル対象は、２つのブロックファイルに相応してもよく、エンコーディングブロックファイル対象は、１０個のブロックファイルに相応してもよい。

【0054】

本発明の一実施例によるブロックチェーンデータ分散格納システムは、ブロックチェーントランザクションデータを格納するノードの少なくとも一部が、ブロックチェーントランザクションデータをブロックファイル単位でエンコーディングし、エンコーディングされたチャンクの一部のみをそのまま格納することにより、ブロックチェーントランザクションデータ格納システムの各ノードに要求されるディスク／メモリ空間を最小化することができる。

【0055】

図２は、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムの構造を示すブロック図である。

【0056】

図２を参照すれば、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムは、ブロックチェーンデータを共有する多数のブロックチェーンノード２１０、２２０、２３０、２４０で構成されたブロックチェーンネットワーク形態で構築できる。

【0057】

ブロックチェーンノード２１０は、データ信頼性保障のためのブロックチェーンデータ管理器と、応用プログラム開発のためのブロックチェーンコアインターフェースと、その他のベースおよび応用技術のためのモジュールとで構成される。

【0058】

この時、ブロックチェーンデータ管理器は、ストレージと、状態管理器と、トランザクション管理器とを含むことができる。

【0059】

この時、ブロックチェーンコアインターフェースは、管理インターフェースと、ソフトウェア開発ツールとを含むことができる。

【0060】

この時、その他のベースおよび応用技術のためのモジュールは、暗号モジュールと、セキュリティハードウェアと、プラットフォームアカウント管理器と、Ｐ２Ｐ／通信プロトコル部と、合意プロトコル部と、スマートコントラクト部とを含むことができる。

【0061】

図２に示された脱中央化アプリケーション（ＤＡｐｐ）は、ブロックチェーンプラットフォームおよびブロックチェーンネットワークが提供する機能およびインターフェースを用いて、信頼ベースのデータ格納／管理応用サービスをユーザに提供することができる。

【0062】

図３は、図２に示されたブロックチェーンデータ管理器の一例を示すブロック図である。

【0063】

図３を参照すれば、ブロックチェーンデータ管理器は、元帳管理器３１０と、状態管理器３２０と、複合状態管理器３３０と、単純状態管理器３４０と、複合状態データベース３４１と、単純状態データベース３４２と、トランザクション管理器３５０と、ファイルベースブロック管理器３６０と、ブロックファイル３７１、３７２とを含むことができる。

【0064】

図３に示されたブロックチェーンデータ管理器は、ブロックチェーン元帳（ｌｅｄｇｅｒ；状態データとトランザクションデータとで構成）の管理機能を提供する。

【0065】

脱中央化アプリケーション（ＤＡｐｐ）で発生したトランザクションは、元帳管理器３１０を介して状態管理器３２０およびトランザクション管理器３５０に伝達される。

【0066】

状態管理器３２０は、複合状態管理器３３０および単純状態管理器３４０で構成され、トランザクション管理器３５０は、ファイルベースブロック管理器３６０で構成される。

【0067】

ストレージは、状態を格納する複合状態データベース３４１と、単純状態データベース３４２と、トランザクションを格納するブロックファイル形態のブロックチェーンとで構成される。

【0068】

図３には明示しないが、ストレージ内のブロックファイルは、ブロックファイル単位でエンコーディングされてエンコーディングされたチャンクが生成可能であり、ブロックチェーンノードは、それぞれエンコーディングされたチャンクのうち１つのみそのまま格納し、残りはハッシュ値のみ格納することができる。

【0069】

図４は、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムにおいてブロックチェーンデータの格納フローを示す図である。

【0070】

図４を参照すれば、ブロックチェーン応用サービス（ＳＤＫ）は、トランザクションをブロックチェーンノードのうち署名ノード（Ｅｎｄｏｒｓｉｎｇ Ｎｏｄｅ）に伝達する（Ｓ４１０）。

【0071】

署名ノード（Ｅｎｄｏｒｓｉｎｇ Ｎｏｄｅ）は、伝達されたトランザクションをノードの内部でシミュレーションするためにスマートコントラクトを行い、シミュレーション結果を生成（Ｓ４２０）した後、生成されたシミュレーション結果を応用サービスに伝達する（Ｓ４３０）。

【0072】

応用サービスは、シミュレーション結果を含むトランザクションをブロック生成ノード（Ｏｒｄｅｒｉｎｇ Ｓｅｒｖｉｃｅ Ｎｏｄｅ）に提出する（Ｓ４４０）。

【0073】

ブロック生成ノード（Ｏｒｄｅｒｉｎｇ Ｓｅｒｖｉｃｅ Ｎｏｄｅ）は、提出されたトランザクションを集めてトランザクション間の順序を決めてブロックを構成する（Ｓ４５０）。

【0074】

ブロックが構成されると、これはすべてのブロック格納ノード（Ｃｏｍｍｉｔｔｉｎｇ Ｎｏｄｅｓ）に伝達される（Ｓ４６０）。

【0075】

それぞれのブロック格納ノード（Ｃｏｍｍｉｔｔｉｎｇ Ｎｏｄｅ）は、伝達されたブロック内のトランザクションそれぞれを検証し、ノード内のストレージに格納（ｃｏｍｍｉｔ）する（Ｓ４７０）。この時、ブロックチェーン（トランザクションデータの履歴）と状態データに変更が発生する。新しいトランザクションは、ブロック形態で既存のブロックチェーンの後ろ部分に記録され、既存の状態データは、新しい値に変更される。

【0076】

図４に示された例において、署名ノード（Ｅｎｄｏｒｓｉｎｇ Ｎｏｄｅ）は、署名ノードとしての役割のみならず、同時にブロック格納ノード（Ｃｏｍｍｉｔｔｉｎｇ Ｎｏｄｅ）の役割も果たすことができる。

【0077】

図５は、ブロックファイル格納の概念を示すブロック図である。

【0078】

図５を参照すれば、ブロック（トランザクションデータの束）が生成され、生成されたブロックは、各ノードに配布され、各ノードでファイルシステムベースのブロックファイル形態で格納されることが分かる。

【0079】

すなわち、図４に示されたブロックチェーンデータの格納フローにおいて、ブロック生成ノードによって新しいブロックが生成されれば、ブロック格納ノードに配布されてブロックファイル形態で格納される。これはブロックマイニング過程と考えられる。

【0080】

ブロック格納ノードは、伝達されたブロックを別のファイルに格納せず、一定サイズのブロックファイル形態で集めて格納する。したがって、１つのブロックファイルは、複数のブロックを含む。この時、ブロックチェーンデータの一貫性のために、各ブロック格納ノードが同一のブロックおよびブロックファイルを重複して管理することができるが、この場合、格納空間の不足問題が発生しうる。

【0081】

図６は、ファイルシステムにブロックをブロックファイル形態で格納したブロックファイルリストの一例を示す図である。

【0082】

図６を参照すれば、ビットコインのブロックは、すべてのノードにおいて～／．ｂｉｔｃｏｉｎ／ｂｌｏｃｋｓディレクトリにｂｌｋＮＮＮＮＮ．ｄａｔブロックファイルに格納されることが分かる。ブロックは、ｂｌｋ０００００．ｄａｔブロックファイルから始まって格納され、各ブロックファイルが最大サイズになると、次のファイルに格納される。例えば、ビットコインのブロックの大きさは平均１ＭＢであり、ブロックファイルの最大サイズはＭＡＸ＿ＢＬＯＣＫＦＩＬＥ＿ＳＩＺＥで定義され、基本値（ｄｅｆａｕｌｔ ｖａｌｕｅ）は１２８ＭｉＢ（１３４、２７１、７２８バイト）であってもよい。例えば、ハイパーレジャーファブリックは、ビットコインと類似して、１つのブロックファイルに複数のブロックを集めて格納する。この時、最大ブロックファイルサイズの基本値は６４ＭＢであってもよい。

【0083】

図７は、ブロックファイル格納構造の一例を示す図である。

【0084】

図７を参照すれば、ブロックがブロックファイル形態で格納されることが分かる。図７に示された例は、ビットコイン、ハイパーレジャーファブリックなどのブロックチェーンシステムにおいてブロックファイルおよびブロックファイルに格納されるブロックの格納構造を示したものであってもよい。

【0085】

イーサリアムは、ビットコインやハイパーレジャーファブリックとは異なり、トランザクションを記録したブロックをＴｒａｎｓａｃｔｉｏｎ Ｔｒｉｅに格納することができる。この時、Ｔｒａｎｓａｃｔｉｏｎ Ｔｒｉｅは、Ｍｏｄｉｆｉｅｄ ＭＰＴ（Ｍｅｒｋｌｅ Ｐａｔｒｉｃｉａ Ｔｒｉｅ）形態であってもよく、ＭＰＴは、永続性保障のために、ＬｅｖｅｌＤＢ ＲｏｃｋｓＤＢのようなキー／バリューストアを用いてデータを格納することができる。

【0086】

図８は、本発明の一実施例によるブロックファイル単位のエンコーディングが適用される場合の一例を示す図である。この時、ブロックファイル単位のエンコーディングが適用されてデータ可用性が保障できる。

【0087】

図８を参照すれば、テキスト形態の入力データ（ｉｎ．ｔｘｔ）は、Ｋ＋Ｍ（Ｋ＝４、Ｍ＝２）個のチャンクにエンコーディングされて管理される。

【0088】

入力データは、Ｋ（＝２）個の同一サイズを有するデータチャンクに分割されて格納される。この時、データ可用性保障のために、Ｍ（＝２）個の同一サイズを有するパリティチャンクが生成される。ここで、Ｋは、入力データに相当するデータチャンクの数であり、Ｍは、パリティに相当するデータチャンクの数であってもよい。

【0089】

このように、Ｋ＋Ｍ個のチャンクにエンコーディングされたデータは、Ｍ個までの障害が発生しても、原入力データ（ｉｎ．ｔｘｔ）をそのまま復元できる可用性を有する。

【0090】

【0091】

このように、ブロックファイル単位でエンコーディングされた６個のチャンクは、互いに異なるノードに格納される。この時、最大２個までのノードに障害またはビザンチン状況が発生しても（最小４個のチャンクが可用）、デコーディングにより原データ（ｉｎ．ｔｘｔ）のような出力データ（ｏｕｔ．ｔｘｔ）を復元することができる。もし、パリティチャンク（ｉｎ．ｔｘｔ．４、ｉｎ．ｔｘｔ．５）にのみ障害が発生し、原チャンク４個（ｉｎ．ｔｘｔ．０、ｉｎ．ｔｘｔ．１、ｉｎ．ｔｘｔ．２、ｉｎ．ｔｘｔ．３）がすべてアクセス可能であれば、デコーディング過程を省略し、単純に原チャンクをつなぎ合わせて原データ（ｉｎ．ｔｘｔ）を復元することにより、デコーディング時間を節約することもできる。

【0092】

図８の例のように、Ｋが４であり、Ｍが２である場合、下記表１のような格納空間の効率性を有する。この時、エンコーディング方式は、かつて可用性保障のために使用していた複製方式（原本の３倍の格納空間使用）に比べて高い格納空間の効用性（原本の１．５８倍の格納空間使用）を提供することが分かる。

【0093】

【表1】

【0094】

例えば、エンコーディングは、Ｒｅｅｄ－Ｓｏｌｏｍｏｎ、Ｃａｕｃｈｙ Ｒｅｅｄ－Ｓｏｌｏｍｏｎ、Ｖａｎｄｅｒｍｏｎｄｅ Ｒｅｅｄ－Ｓｏｌｏｍｏｎ、Ｆｏｕｎｔａｉｎ Ｃｏｄｅ、Ｌｏｃａｌ Ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ Ｃｏｄｅ（またはＬｏｃａｌ Ｒｅｐａｉｒａｂｌｅ Ｃｏｄｅ）などの原データ保持の有無、格納空間の効率性、可用性の程度、エンコーディング／デコーディング速度、再エンコーディング必要性の有無などの面で多様な互いに異なる特性を有する多様な方式で行われる。本発明のブロックファイルエンコーディングに基づくブロックチェーントランザクションデータ分散格納方法では、多様なエンコーディング方式の１つ以上が選択されて使用可能である。以下、本発明は、提案方法を理解しやすくするように、最も基本的なエンコーディング方式であるＲｅｅｄ－Ｓｏｌｏｍｏｎ方式を用いる例を中心に説明される。もし、ビザンチン障害耐性（Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）の条件であるＫ＞＝２Ｍ＋１を満足するようにデータをブロックファイル単位でエンコーディングして、全体チャンクの個数がＫ＋Ｍ＝３Ｍ＋１個となるようにして、各チャンクをＫ＋Ｍ＝３Ｍ＋１個のノードに分割して格納すれば、全体ノードの１／３までの物理ノード障害またはビザンチン行為が発生しても原データを復旧できる能力、すなわちビザンチン障害耐性（Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ、ＢＦＴ）を有する。

【0095】

これに対し、エンコーディングを適用して、原データのうち一部のチャンクのみを各ノードに格納すれば、当該ノードが持っていないチャンクにアクセスが必要な場合、他のノードからデータ送信を受けなければならないので、アクセス速度の遅延問題が発生する。したがって、エンコーディング方式をデータ格納システムに適用するには、読込み速度問題を考慮してエンコーディングを適用しなければならない。

【0096】

本発明は、このようなエンコーディング方法の高い格納空間の効率性を活用するために、ブロックファイルベースでブロックチェーントランザクションデータ格納のためのエンコーディングを適用して、ビザンチン障害耐性水準の高い可用性を保障しながらも各ブロックチェーンノードに要求される格納空間を最小化することができる。特に、本発明は、実際にブロックチェーンシステムのストレージ特性を考慮して、トランザクションまたはブロック単位ではない、ブロックファイル単位のエンコーディングを適用する。

【0097】

図９は、本発明の一実施例によるブロックファイルエンコーディングに基づくブロックチェーントランザクションデータのエンコーディング方法の一例を示すブロック図である。

【0098】

図９を参照すれば、１つのブロックがエンコーディングされるか、単純にエンコーディングされたブロックの個数とノードの個数を合わせるようにエンコーディングするのではなく、ブロックファイル単位でエンコーディングが適用されることが分かる。

【0099】

すなわち、本発明は、ブロックチェーントランザクションデータ分散格納のためにエンコーディングを適用しかつ、ビットコインやハイパーレジャーファブリックのように複数のブロックを１つのブロックファイルに格納するブロックチェーンシステムの普遍的なブロック格納構造を考慮してエンコーディングを適用する。

【0100】

図９に示された例において、ブロックは、ブロックファイル（ＢＬＯＣＫ ＦＩＬＥ０、．．．、ＢＬＯＣＫ ＦＩＬＥ１０、．．．）に格納され、１つのブロックファイルには多様な大きさを有する多数のブロックが格納される。例えば、ブロックファイル１０にはブロック１０１～１０７までのブロックが格納される。各ブロックファイルの大きさは、ブロックチェーンシステムに設定されたブロックファイルの最大サイズ値（例えば、６４ＭＢ）を超えない。ブロックチェーンシステムに設定されたブロックの最大サイズ、ブロック生成周期、ブロック生成時点のトランザクション発生量、ブロック生成時点で発生したトランザクションの大きさなどに応じて互いに異なる大きさを有するブロックが生成される。

【0101】

この時、それぞれのブロックチェーンノードは、エンコーディングされたチャンクのうち１つが割当てられる。

【0102】

図９の例において、１つのブロックチェーンノードは、割当てられたブロック（ブロック１０４）に対しては原データブロックを格納して管理し、割当てられていないブロック（ブロック１０１、１０２、１０３、１０５、１０６、１０７、パリティ１、２）に対しては当該ブロックのハッシュ値のみ格納して管理する。これにより、各ノードには元々配布されていたすべてのブロックに関する情報が格納されるが、エンコーディング時に割当てられなかったブロックに対しては格納空間を小さく占めるハッシュ値のみ格納するので、格納空間を節約することができる。この時、ハッシュ値は、後で当該ブロックへのアクセスが必要で他のノードからブロックが提供される時、提供されたブロックに対する操作が発生したか否かを確認するための目的で活用可能である。

【0103】

図９に示された例では、１つのブロックファイルに対してエンコーディングが適用される場合を例に挙げたが、本発明のブロックファイルエンコーディングに基づくブロックチェーントランザクションデータ分散格納方法は、ブロックの個数とノードの個数を考慮して多数のブロックファイルにエンコーディングを適用することができる。

【0104】

多数の予め格納されたブロックファイルの中から、エンコーディングを適用するブロックファイルを選定する基準は次の通りである。

【0105】

－最もよくアクセスされない（ｌｅａｓｔ ｆｒｅｑｕｅｎｔｌｙ ａｃｃｅｓｓｅｄ）ブロックやブロックファイルを選定する。

【0106】

－古いブロックやブロックファイルを選定する。

【0107】

－ノード数を考慮して、必要時、選定されたブロック（ブロックファイル）と隣接したブロックやブロックファイルを選定する。

【0108】

図１０は、本発明の一実施例によるブロックチェーントランザクションデータ格納方法を示す動作フローチャートである。

【0109】

図１０を参照すれば、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、ブロックチェーンノードの個数（３Ｍ＋１）を確認する（Ｓ１０１５）。

【0110】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、パリティチャンクの個数をＭに設定する（Ｓ１０１７）。

【0111】

この時、ブロックチェーンノードの個数は３Ｍ＋１に設定される。すなわち、ブロックチェーンノードの個数が決定されると、これによって適切なパリティチャンクの個数が決定されてもよく、逆に、パリティチャンクの個数が決定されると、これによって適切なブロックチェーンノードの個数が決定されるものであってもよい。

【0112】

ステップＳ１０１５において、ノードの個数がＮ個であれば、トランザクションデータのビザンチン障害保障のためには、Ｎ＝３Ｍ＋１の条件を満足するようにエンコーディングを適用しなければならず、エンコーディング時にＭ個のパリティチャンクを有するようにエンコーディングしなければならない。また、エンコーディング対象ブロックの個数（Ｋ）、すなわちエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）またはエンコーディングブロックファイルに含まれるブロックの個数は２Ｍ＋１個でなければならない。

【0113】

一方、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、まず、予め格納されたブロックファイルのうち１つをエンコーディング対象ブロックファイルとして選定し、パラメータ（Ｋ、ｐｒｅｖＫ）を初期化する（Ｓ１０１０）。

【0114】

この時、エンコーディング対象ブロックファイルは、ブロックチェーントランザクションを格納するブロックファイルの中から、ブロックファイルまたはブロックファイルが含まれるブロックに対するアクセス頻度を考慮して選択される。

【0115】

この時、パラメータＫは、エンコーディング対象ブロックの個数を示し、パラメータｐｒｅｖＫは、前のブロックファイルまでのエンコーディング対象ブロックの個数を示すことができる。

【0116】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、ブロックファイル内に含まれたブロックの個数（Ｂ）を確認する（Ｓ１０２０）。

【0117】

この時、ブロックファイルごとにそれぞれのブロックファイルに含まれたブロックの個数は異なっていてもよい。

【0118】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、エンコーディング対象ブロックの個数（Ｋ）を設定する（Ｓ１０３０）。

【0119】

すなわち、ステップＳ１０３０は、当該ブロックファイルに含まれたブロックの個数がエンコーディング対象ブロックに含まれるようにし、その個数をカウントする。

【0120】

この時、パラメータｐｒｅｖＫはＫに設定され、パラメータＫはＫ＋Ｂに設定される。この時、パラメータｐｒｅｖＫがＫに設定されるというのは、前のブロックファイルまで計算した符号化対象ブロックの個数（Ｋ）をパラメータｐｒｅｖＫに格納しておくことである。

【0121】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、エンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１（Ｍはパリティチャンクの個数）より少ないか否かを判断する（Ｓ１０４０）。

【0122】

もし、エンコーディング対象ブロックファイルに含まれるエンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１より少なければ、２Ｍ＋１個のブロックがエンコーディング対象となるように次のブロックファイルのブロックを符号化対象ブロックに追加されるようにして、符号化対象ブロックの個数（Ｋ）が２Ｍ＋１に近づくようにする（Ｓ１０４５）。

【0123】

ステップＳ１０４５が行われた後には、ステップＳ１０２０が再び行われる。

【0124】

もし、エンコーディング対象ブロックファイルに含まれるエンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１より大きいか、同一であれば、エンコーディング対象ブロックファイルに含まれるエンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１と同一であるか否かを判断する（Ｓ１０５０）。

【0125】

ステップＳ１０５０の判断結果、エンコーディング対象ブロックファイルに含まれるエンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１と同一であれば、Ｋ＝２Ｍ＋１個のエンコーディング対象ブロックをすべてエンコーディング対象として選定する（Ｓ１０５５）。

【0126】

ステップＳ１０５０の判断結果、エンコーディング対象ブロックファイルに含まれるエンコーディング対象ブロックの個数（Ｋ）が２Ｍ＋１と同一でなければ、Ｋ＞２Ｍ＋１の場合であるので、前のブロックファイルまでのみエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）となるようにする（Ｓ１０６０）。

【0127】

この時、エンコーディングブロックファイル対象は、１つ以上の整数個のエンコーディングファイルを示すものであってもよい。

【0128】

このように、前のブロックファイルまでのみエンコーディングブロックファイル対象になれば、エンコーディング対象ブロックの個数が２Ｍ＋１個より小さい場合であるので、不足したブロックの個数を満たすための複製対象ブロック（Ｒ）を選定する（Ｓ１０７０）。

【0129】

この時、選定される複製対象ブロック（Ｒ）の個数は、２Ｍ＋１－Ｋ個であってもよい。

【0130】

この時、複製対象ブロックは、アクセス頻度に基づき、エンコーディングブロック対象ファイルに含まれたブロックの中から選択される。例えば、複製対象ブロックは、当該ブロックファイル内のブロックのうちアクセス頻度が頻繁な順に選定されたブロックであってもよい。

【0131】

このように複製されたブロックは、複製されていないブロックに比べて読込み要請時に当該ブロックを持っているノードの個数が増加するので、当該ブロックに対する符号化が適用されてもアクセス遅延がより少なく発生し、結局、ブロックアクセス時間の増加が最小化される。

【0132】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、選定された複製対象ブロックを複製して、全体エンコーディング対象が２Ｍ＋１個となるようにする（Ｓ１０８０）。

【0133】

ステップＳ１０８０またはステップＳ１０５５により、エンコーディング対象ブロックが２Ｍ＋１個に決定されると、このエンコーディング対象ブロックに対するエンコーディングを行って、Ｍ個のパリティチャンクを含むエンコーディングされたチャンクを生成する（Ｓ１０９０）。

【0134】

この時、エンコーディング対象ブロックは、サイズがすべて同一でなくてもよい。この時、エンコーディング対象ブロックは、エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディング（ｐａｄｄｉｎｇ）される。

【0135】

また、本発明の一実施例によるブロックチェーントランザクションデータ格納方法は、エンコーディング結果に相当する３Ｍ＋１個のチャンクを、３Ｍ＋１個の全体ブロックチェーンノードに１：１マッピングさせる（Ｓ１０９５）。

【0136】

この時、ブロックチェーンノードは、それぞれマッピングされたチャンクのみそのまま格納し、他のチャンクはハッシュ値のみを格納することができる。

【0137】

結局、図１０に示された方法により２Ｍ＋１個のエンコーディング対象ブロックに対するエンコーディングが行われて、原ブロック（チャンク）２Ｍ＋１個とＭ個のパリティチャンクとを含む計３Ｍ＋１個のチャンクが生成され、これら３Ｍ＋１個のチャンクは、Ｎ＝３Ｍ＋１個のブロックチェーンノードに割当てられる。

【0138】

図１１は、多数のブロックファイルベースでブロックチェーントランザクションデータのエンコーディングが適用される一例を示す図である。

【0139】

図１１を参照すれば、複数のブロックファイル（ＢＬＯＣＫ ＦＩＬＥ１０、ＢＬＯＣＫ ＦＩＬＥ１１、ＢＬＯＣＫ ＦＩＬＥ１２、．．．）のうち２つのブロックファイル（ＢＬＯＣＫ ＦＩＬＥ１０、ＢＬＯＣＫ ＦＩＬＥ１１）にエンコーディングが適用されることが分かる。

【0140】

図１１にて、Ｋは原ブロックを示し、Ｒは複製ブロックを示し、Ｍはパリティチャンクを示す。

【0141】

図１１に示された例において、符号化対象ブロックファイル（ＢＬＯＣＫ ＦＩＬＥ１０、ＢＬＯＣＫ ＦＩＬＥ１１）に含まれたブロックの個数が２Ｍ＋１より小さく、Ｒ個の複製対象が選定され複製されて、計２Ｍ＋１個のエンコーディング対象ブロックが決定され、２Ｍ＋１個のエンコーディング対象ブロックに対するエンコーディングが行われて、Ｍ個のパリティチャンクが生成されることが分かる。このようにエンコーディング実行後、原データ（２Ｍ＋１個のデータチャンク）が保持されるようにするために、システマティックエンコーディング（ｓｙｓｔｅｍａｔｉｃ ｅｎｃｏｄｉｎｇ）が適用可能である。

【0142】

エンコーディングの結果、計２Ｍ＋１個の原データチャンクおよびＭ個のパリティチャンクを含む３Ｍ＋１個のエンコーディングされたチャンクが生成される。

【0143】

図１２は、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法を示す動作フローチャートである。

【0144】

本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、トランザクション、ブロックまたはブロックファイルが生成される時に直ちに適用されず、ブロックチェーンシステム内の全体格納空間の効率性（Ｅ）、ブロックチェーンノードの計算資源および格納空間などを考慮して適切なタイミングに適用可能である。

【0145】

また、すべてのブロックまたはブロックファイルにエンコーディングが適用されず、アクセス頻度が低下するブロックファイル（またはブロック）を選定し、ブロックチェーンシステムの計算資源負荷（Ｌ）が大きくない場合にのみ、選定されたブロックファイル（またはブロック）にエンコーディングを行うことができる。もし、ブロックチェーンシステムの計算資源負荷（Ｌ）が大きい状況でも、全体格納空間の効率性が大きく低下した状態であれば、格納空間確保のためにエンコーディングが実行（Ｓ１２９０）できる。

【0146】

図１２を参照すれば、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、ブロックチェーンシステム内の全体格納空間の効率性（Ｅ）を計算する（Ｓ１２１０）。

【0147】

また、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、計算された格納空間の効率性が予め設定された比較値（ｔｈｒｅｓｈｏｌｄ＿Ｅ）より小さいか否かを判断する（Ｓ１２２０）。

【0148】

ステップＳ１２２０の判断結果、格納空間の効率性が予め設定された比較値より小さくない場合には、格納空間の確保が不必要であるので、動作を終了する。

【0149】

ステップＳ１２２０の判断結果、格納空間の効率性が予め設定された比較値より小さい場合には、ブロックアクセス頻度（Ｂ）が収集される（Ｓ１２３０）。

【0150】

また、格納空間の効率性が予め設定された比較値より小さい場合には、ブロックファイルアクセス頻度（Ｆ）が計算される（Ｓ１２４０）。

【0151】

さらに、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、ブロックアクセス頻度（Ｂ）およびブロックファイルアクセス頻度（Ｆ）のうちの１つ以上を用いてブロックファイルをアクセス頻度の順に整列する（Ｓ１２５０）。

【0152】

また、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、整列されたブロックファイルを用いて低頻度アクセスブロックファイルを選定する（Ｓ１２６０）。

【0153】

この時、低頻度アクセスブロックファイルは、ブロックファイルに含まれたブロックに対するアクセス頻度が予め設定された基準値（ｔｈｒｅｓｈｏｌｄ＿Ｆ）より小さいか否かを用いて選定される。

【0154】

また、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、ブロックチェーンシステムの計算資源負荷（Ｌ）を計算する（Ｓ１２７０）。

【0155】

さらに、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、計算された計算資源負荷（Ｌ）が予め設定された基準値（ｔｈｒｅｓｈｏｌｄ＿Ｌ）より小さいか否かを判断する（Ｓ１２８０）。

【0156】

ステップＳ１２８０の判断結果、計算資源負荷が基準値（ｔｈｒｅｓｈｏｌｄ＿Ｌ）より小さければ、エンコーディングを行う（Ｓ１２９０）。

【0157】

ステップＳ１２８０の判断結果、計算資源負荷が基準値（ｔｈｒｅｓｈｏｌｄ＿Ｌ）より小さくなければ、全体格納空間の効率性を再び計算する（Ｓ１２８５）。

【0158】

また、本発明の一実施例によるエンコーディング対象ブロックファイル選定方法は、計算された全体格納空間の効率性が第２基準値（ｔｈｒｅｓｈｏｌｄ＿Ｓ）より小さいか否かを判断し（Ｓ１２８７）、全体格納空間の効率性が第２基準値より小さい場合にのみステップＳ１２９０へ進んで、エンコーディングを行い、全体格納空間の効率性が第２基準値より小さくない場合には、全体格納空間の効率性が大きく低下した状態ではないので、動作を終了する。

【0159】

本発明の一実施例によるブロックファイルエンコーディングに基づくブロックチェーントランザクションデータ分散格納方法が使用されると、分散格納されたブロックへのアクセスが必要な場合、一般的にデコーディング過程を必要とせず、当該ブロックをそのまま持っているノードを介して所望のブロックが提供可能である。

【0160】

図９により説明したように、すべてのブロックチェーンノードは、ブロックファイル符号化に基づくブロックチェーントランザクションデータのエンコーディングにより割当てられていないブロックに対してもハッシュ値を有しているため、他のノードが提供したブロックの操作の可否を確認することができる。ブロックによって、すべてのブロックの大きさを同一にするために、追加的に格納されたパディング部分は除去する過程が必要になりうる。

【0161】

図１３は、本発明の一実施例によるブロックアクセス方法の一例を示す動作フローチャートである。

【0162】

図１３を参照すれば、本発明の一実施例によるブロックアクセス方法は、要請されたブロック（チャンク）を当該ノードが保有しているか否かを確認する（Ｓ１３１０）。

【0163】

ステップＳ１３１０の確認結果、要請されたブロックを当該ノードが保有していれば、格納されたブロックから不必要なパディングを除去し（Ｓ１３２０）、要請されたブロックデータを要請者に提供する（Ｓ１３３０）。

【0164】

ステップＳ１３１０の確認結果、要請されたブロックを当該ノードが保有していなければ、要請されたブロックを保有したノードが確認される（Ｓ１３１１）。

【0165】

要請されたブロックを保有したノードが確認されれば、当該ノードに要請されたブロックを要請し（Ｓ１３１３）、ブロックが送信された後（Ｓ１３１５）、送信されたブロックのハッシュ値をチェックする（Ｓ１３１７）。すなわち、ステップＳ１３１７は、送信されたブロックのハッシュ値を求め、求められたハッシュ値と予め格納されたハッシュ値とを比較する。

【0166】

また、本発明の一実施例によるブロックアクセス方法は、送信されたブロックのハッシュ値に異常があるか否かをチェックして、異常がなければ、ステップＳ１３２０へ進んで、不必要なパディングを除去した後に、ブロックデータを提供し、異常があれば、予め設定された回数だけ再トライを行う（Ｓ１３１９）。

【0167】

すなわち、本発明の一実施例によるブロックアクセス方法は、他のノードから提供されたブロックのハッシュ値とノードが保有したハッシュ値とが同一でなければ、当該ブロックを保有した他のノードから再びブロックが提供される。もし、数回再トライをしてすべての保有ノードからブロックを受けたものの、すべてのノードから受けたブロックに基づいて計算されたハッシュ値にすべて異常があれば、動作を終了し、後述するデコーディングおよび再エンコーディング手順を経た後、ブロックアクセスを再び開始することができる。

【0168】

図１４は、本発明の一実施例によるブロックエラーを発見したノードの再エンコーディング方法の一例を示す動作フローチャートである。

【0169】

図１４を参照すれば、エンコーディングされたブロック（チャンク）の少なくとも１つに問題（格納ノード障害またはビザンチン行為実行）が発生する場合、デコーディング手順が行われることが分かる。

【0170】

すなわち、ブロックエラーが発見されれば（Ｓ１４１０）、すべてのノードに再エンコーディングが要請される（Ｓ１４２０）。

【0171】

もちろん、エンコーディングされたブロック（チャンク）の少なくとも１つに問題（格納ノード障害またはビザンチン行為）が発生しなければ、図１３に示された過程により、デコーディング過程なしに、所望のブロックを直ちに読込むことができる。

【0172】

しかし、データブロックに障害が発生すれば、再エンコーディング過程によりブロックを復元する必要がありうる。

【0173】

図１５は、本発明の一実施例による再エンコーディング要請を受信したノードの再エンコーディング方法の一例を示す動作フローチャートである。

【0174】

図１５を参照すれば、ブロックチェーンノードが再エンコーディング要請を受信する（Ｓ１５１０）。

【0175】

再エンコーディング要請を受信したブロックチェーンノードは、再エンコーディング合意を行い（Ｓ１５２０）、合意に失敗すれば、動作を終了する。

【0176】

合意に成功すれば、再エンコーディング要請を受信したブロックチェーンノードは、それぞれ異なるノードから未保有ブロック（チャンク）を受信し（Ｓ１５４０）、受信したブロックのハッシュ値を確認する（Ｓ１５５０）。

【0177】

ハッシュ値に異常がなければ、ブロックチェーンノードは、デコーディングを行い（Ｓ１５６０）、デコーディングにより得られたデータを再びエンコーディングして、エンコーディングされたチャンクを再び生成する（Ｓ１５７０）。

【0178】

既存のブロックチェーンノードのほか、新しいノードがブロックチェーンネットワークに参加すれば、ノード数（Ｎ）が異なり、これによって既存のエンコーディングされたチャンクが格納された状態ではＢＦＴの保障が不可能になりうる。本発明では、多様なエンコーディング方法を活用してブルロックファイルベースのブロックチェーントランザクションデータのエンコーディングが可能であり、活用されるエンコーディング方法によっては再エンコーディングを必要としないエンコーディング方法もあり、複製個数を追加してＢＦＴを保障しなければならないエンコーディング方法もある。場合によっては、図１５により説明された再エンコーディングを行ってこそ、ＢＦＴが保障されることも可能である。

【0179】

逆に、ブロックチェーンネットワークに参加中のノードが脱退したり、障害が発生すれば、当該ノードが格納および管理していたブロックへのアクセスが不可能になる問題が発生しうる。活用されるエンコーディング方法によって、そして当該ノードが管理していたブロックによって、このような場合にも依然としてＢＦＴを保障できるエンコーディング方法もあり、または関連ブロックを複製したり、図１５により説明された再エンコーディングを行ってこそ、ＢＦＴが保障されることも可能である。

【0180】

図１６は、本発明の一実施例によるブロックチェーントランザクションデータ分散格納システムにおいて高頻度アクセスブロックチェーントランザクションデータの複製を示す図である。

【0181】

図１６を参照すれば、ブロックチェーンネットワークからワークロードへの変化により、ノード数の変化なくよくアクセスされるブロックが変化すれば、当該ブロックの複製個数を増やして当該ブロックに対するアクセス遅延を最小化できることが分かる。

【0182】

これまで説明した本発明の構成および動作方式は、参加ノードの１／３まで障害保障のためのＢＦＴ保障方法のみならず、より可用性の保障が強いか弱い多様な保障水準のためにも活用および適用が可能である。

【0183】

このように、本発明のブロックファイルベースのエンコーディングが適用されれば、大規模ブロックチェーントランザクションデータを格納するブロックチェーンシステムにおいて各ノードに格納されるデータ容量を減らして全体ブロックチェーンネットワークの格納空間の効率性を向上させ、より少ないノードで大規模なブロックチェーントランザクションデータを格納管理することができる。

【0184】

また、本発明のブロックファイルベースのエンコーディングを用いたブロックチェーン分散格納技術は、ブロックチェーントランザクションデータをファイルシステム上に格納管理する一般的な形態のブロックチェーンプラットフォームに広く適用可能である。

【0185】

図１７は、本発明の一実施例によるコンピュータシステムの構成を示すブロック図である。

【0186】

実施例によるブロックチェーントランザクションデータ格納装置およびブロックチェーンを構成するノードは、コンピュータ可読記録媒体のようなコンピュータシステム１７００で実現できる。

【0187】

コンピュータシステム１７００は、バス１７２０を介して互いに通信する１つ以上のプロセッサ１７１０と、メモリ１７３０と、ユーザインターフェース入力装置１７４０と、ユーザインターフェース出力装置１７５０と、ストレージ１７６０とを含むことができる。また、コンピュータシステム１７００は、ネットワーク１７８０に連結されるネットワークインターフェース１７７０をさらに含むことができる。プロセッサ１７１０は、中央処理装置またはメモリ１７３０やストレージ１７６０に格納されたプログラムまたはプロセッシングインストラクションを実行する半導体装置であってもよい。メモリ１７３０およびストレージ１７６０は、揮発性媒体、不揮発性媒体、分離型媒体、非分離型媒体、通信媒体、または情報伝達媒体の少なくとも１つ以上を含む記憶媒体であってもよい。例えば、メモリ１７３０は、ＲＯＭ１７３１やＲＡＭ１７３２を含むことができる。

【0188】

この時、メモリ１７３０には少なくとも１つのプログラムが記録される。

【0189】

この時、プロセッサ１７１０は、前記プログラムを実行することができる。この時、前記プログラムは、ブロックチェーントランザクションを格納する少なくとも１つのブロックファイル（ｂｌｏｃｋ ｆｉｌｅ）をエンコーディングブロックファイル対象（ｅｎｃｏｄｉｎｇ ｂｌｏｃｋ ｆｉｌｅ ｔａｒｇｅｔ）として選択し、前記エンコーディングブロックファイル対象を用いてパリティチャンクを含むエンコーディングされたチャンクを生成し、前記エンコーディングされたチャンクの少なくとも１つと、前記エンコーディングされたチャンクの少なくとも１つを格納するブロックチェーンノードの少なくとも１つとを対応させることができる。

【0190】

この時、パリティチャンクは、Ｍ（Ｍは自然数）個であり、前記ブロックチェーンノードは、３Ｍ＋１個であり、前記エンコーディングされたチャンクは、３Ｍ＋１個であり、前記エンコーディングされたチャンクと前記ブロックチェーンノードとは、１：１対応できる。

【0191】

この時、ブロックチェーンノードそれぞれは、前記エンコーディングされたチャンクのうち相応する１個のためにはエンコーディングされたチャンクをそのまま格納し、前記１個を除いた残りのチャンクの少なくとも一部のためにはハッシュ値のみ格納することができる。

【0192】

この時、前記プログラムは、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応するか否かを判断し、前記エンコーディングブロックファイル対象に含まれたブロックの個数が２Ｍ＋１に相応しない場合、前記エンコーディングブロックファイル対象に含まれたブロックおよび前記エンコーディングブロックファイル対象に含まれたブロックの一部である複製ブロックを用いて２Ｍ＋１個のエンコーディング対象ブロックを生成することができる。この時、前記エンコーディングされたチャンクは、前記エンコーディング対象ブロックを用いたエンコーディングを行って生成される。

【0193】

この時、複製ブロックは、アクセス頻度に基づき、前記エンコーディングブロックファイル対象に含まれたブロックの中から選択される。

【0194】

この時、エンコーディングブロックファイル対象は、２Ｍ＋１個を超えない個数のブロックを含むことができる。

【0195】

この時、２Ｍ＋１個を超えない個数のブロックは、サイズがすべて同一でなく、前記エンコーディングされたチャンクを生成する前に、最大ブロックサイズを基準としてパディングされる。

【0196】

この時、エンコーディングブロックファイル対象は、前記ブロックチェーントランザクションを格納するブロックファイルの中から、前記ブロックファイルまたは前記ブロックファイルが含むブロックに対するアクセス頻度を考慮して選択される。

【0197】

この時、ハッシュ値は、他のノードから読込んだブロックを検証するのに用いられる。

【0198】

この時、エンコーディングされたチャンクのうち２Ｍ＋１個以上は、前記エンコーディング対象ブロックを復元するデコーディングに用いられる。

【0199】

以上、本発明によるブロックチェーントランザクションデータ格納方法、装置およびブロックチェーントランザクションデータ分散格納システムは、上記のように説明された実施例の構成と方法が限定されて適用できるのではなく、上記の実施例は多様な変形が行われるように各実施例の全部または一部が選択的に組み合わされて構成されてもよい。

【符号の説明】

【0200】

１７００：コンピュータシステム
１７１０：プロセッサ
１７２０：バス
１７３０：メモリ
１７３１：ＲＯＭ
１７３２：ＲＡＭ
１７４０：ユーザインターフェース入力装置
１７５０：ユーザインターフェース出力装置
１７６０：ストレージ
１７７０：ネットワークインターフェース
１７８０：ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】