パート2.ブロックチェーン上の分散アプリケーションのデータをどこに保存しますか？

記事の最初の部分では、アプリケーションデータをブロックチェーンに保存する問題の概要を説明しました。 何が起こっているかの本質を理解するために、 それを読むことをお勧めします。 記事のこのパートでは、理想的なデータウェアハウスの特性に対する要望を概説し、この問題を解決するための既存のアプローチも検討します。



では、分散アプリケーションがある場合、データウェアハウスのどのような要件を提示する必要がありますか？ 次の要件を提供します

• 配布 -ブロックチェーンのインフラストラクチャ全体とその上のアプリケーションが配布されるため、データウェアハウスも配布および分散化する必要があります。
• 宣伝 -ブロックチェーンにより、誰もが自分の機器をネットワークに追加できます。 データウェアハウスから同じことを期待するのは論理的です。
• ビザンチン将軍の問題に対する抵抗と、パブリックネットワークにおける他のタイプの攻撃 -これがまったくないパブリック分散ネットワークにおいて。
• シャーディングのサポート -アプリケーションが人気があり、大量のデータを保存することが予想される場合、ネットワークのパワーを使用して最大ストレージボリュームを増やすとよいでしょう。 もちろん、各ノードでデータを完全に複製すると、個々のノードに問題が発生した場合にデータが失われる可能性が低くなります。 ただし、たとえば数百または数千のサーバーなどの大きなネットワーク容量の場合、すべてのサーバーですべてのデータを複製することは非常に冗長であり、データの最大合計量を増やすことを優先してレプリケーションのレベルを下げることができます。 つまり、 N台のサーバーがある場合、各レコードはそのうちのm台（m < N ）にのみ複製される必要があります。 これにより、サーバーを追加することで保存されるデータの総量が直線的に増加します。
• 速度 -一般的なアプリケーションの場合、1秒あたりのデータの保存または読み取りに数百万のトランザクションではなくても数十万のトランザクションが必要になる場合があります
• 構造性 -アプリケーションが個々のレコードを相互にリンクできるように、リポジトリは内部データ構造を保持できる必要があります
• データの削除 -ストレージは、アプリケーションがスペースを解放するのに不要になったデータの削除をサポートする必要があります
• 二次キー
  
  全文検索、クエリ言語 -アプリケーションは、内部構造を考慮して、保存されたデータをすばやく検索できる必要があります

既存のテクノロジーがこれらの要件を満たす方法を見てみましょう。

IPFS

IPFS （InterPlanetary File System）-DHT（Distributed Hash Table）およびBitTorrentプロトコルに基づく分散ファイルシステムテクノロジー。 コンテンツアドレッシングを使用して、さまざまなデバイス上のファイルシステムを1つに結合できます。



利点 ：

• 各デバイスは、必要なファイルのみに加えて、他のデバイス上のファイルの場所に関するメタ情報を保存します。 したがって、追加は必要ありません。 ファイルを保存する動機。
• ファイルのアドレス指定はコンテンツによって行われるため、ピアを信頼する必要はありません。
• ファイルが自分のデバイスにのみ配置されるため、フラッドへの抵抗（不要なファイルをネットワークにアップロードする）。
• 高帯域幅（BitTorrentのおかげ）

欠点 ：

• ストレージのみのファイル（非構造化情報）。
• ファイルを配置した後、ネットワーク全体に分散するまでネットワークを離れることはできません。
• 他のデバイスによるデータストレージは保証されていません。他のデバイスへのファイルの提供を保証するには、オンラインである必要があります
• ファイルは静的（不変）です
• ファイルの削除は原則として提供されていません。

IPFSを使用して、AKASHAソーシャルネットワーク（Ethereum + IPFS）とOpenBazaarマーケットプレイスが構築されています。 IPFSの上記の不利な点を完全に継承しています。その主な理由は、ネットワークに情報を投稿して、ピアに広がるまでオフラインにできないことです。

分散ファイルストレージ

このようなストレージを使用すると、個々のデバイスを共通のクラウドストレージに結合できます。 その結果、ユーザーはDropboxなどの従来の集中型ストレージに保存できるのと同じ方法でファイルを保存できますが、安価です。 他の人のファイルを保存する場所を提供するデバイスの所有者（「ファーマー」）は、その貢献に応じてユーザーからこのためのお金を受け取ります。 貢献度を測定し、ストレージの信頼性を確保し、悪用を阻止するために、さまざまなチェックが使用されます。たとえば、暗号化に基づいたストレージの証明（ファイルの受け入れの証明）、検索可能性の証明（ファイルが利用可能で抽出できることの証明）です。 ユーザーは検証の成功に対して支払いを行い、農家は暗号通貨の一定額を受け取ります。



このようなプロジェクトは、主にDHTテクノロジーとコンテンツアドレス指定を使用して構築されます（ファイルからのハッシュがその識別子である場合）。 さらに、スマートコントラクトを使用するものもあります。



Sia 、 Storj 、 Ethereum Swarm 、 MadeSAFEなど、そのようなプロジェクトは現在市場に非常に多くあります。 それらはすべて同様の原則に基づいています。 さらに、dAppに便利なファイルストレージを提供するなど、Ethereum Swarmが考案されました。



利点 ：

• ファイルはクラウドに保存され、所有者の可用性に関係なく使用できます。
• 高スループット。
• 経済的な動機により、ファイルの保存と取得の信頼性が確保されます。
• 不要なファイルを削除することは可能です

欠点 ：

• ファイルのみを保存する（構造化された情報は保存しない）
• ファイルは静的です
• ストレージは無料ではありません

ファイルストレージについては、分散ファイルストレージが魅力的に見えます。 ただし、ソーシャルネットワークのユーザーデータなどの構造化された動的情報を保存する場合、静的ファイルにデータを保存することは重大な問題です。 実際、ファイルストレージはファイルの内容について何も知らないため、アプリケーションはファイルの識別子（または名前）だけでなく、その内容によっても情報を検索する必要がある場合があります。 たとえば、blockchainキーワードを持つすべてのユーザーを検索します。 または特定の都市に位置しています。 または、出版物を完全に検索することもできます。 したがって、私たちはより良い実装を探し続けています。

分散データベース

残念ながら、 CAP定理により、一貫性、アクセス可能性、分離抵抗を同時に保証する完全に分散したデータベースを取得することは不可能です（後者は、一部のノードがネットワークから切断されたり、メッセージが届かない場合でもデータベースが機能し続けることを意味します）。



私たちのニーズには、もちろん、パーティション分割に耐性があり、アクセス可能な分散データベースが必要です。最新ではないかもしれませんが、すぐに回答を得る必要があります。 ACID SQL DBMSは主に一貫性を提供するため、これによりNoSQLデータベースへの選択が制限されます。



分散NoSQLデータベースには多くの実装があります。 たとえば、 MongoDB 、 Cassandra 、 RethinkDB 。 それらはすべて、一緒にクラスター化された多数のレプリカと連携できます。 クライアントはレプリカの1つと連携し、データは自動的に残りのレプリカと同期されます。 データの一部がレプリカの一部にのみ保存される場合、シャーディングを使用して負荷を分散できます。 新しいレプリカをクラスターに追加すると、クラスターがほぼ直線的にスケーリングされ、一部の実装（Cassandraなど）により、レプリカがクラスターの作業の一部を自動的に引き継ぐことができます。



NoSQLデータベースは「結果整合性」を提供します。つまり、個々のレプリカが同期されると、しばらくしてデータが整合します。 この点で、それらはブロックチェーンに似ています-時間が経過するほどトランザクションの確認が行われる可能性が高くなります。



NoSQLデータベースは、単純なKey-Valueを保存し、値の内部構造と追加のインデックスの両方を保持できます。 最も高度なものには、基本的なトランザクションサポートとSQLのようなクエリ言語（Cassandraなど）もあります。



上記のすべてにおいて、このデータベースクラスはブロックチェーンでの使用に理想的と思われるかもしれません。 しかし、問題があります。 誰かがそのようなデータベースの適切に調整されたクラスターに悪意のあるレプリカを追加し、クラスター内の他のレプリカにすべてのデータを削除する必要があることを伝え始めると想像してください！ 他のすべてのレプリカは素直にすべてのデータを削除し、データベースは絶望的に破損します。 つまり、レプリカのこのような調整された作業は、信頼できる環境でのみ可能になりました（そのようなデータベースのクラスターは、ビザンチン将軍の問題に対して不安定です）。 悪意を持って動作するレプリカがクラスターに配置されると、クラスター全体のデータが破壊される可能性があります。



利点 ：

• 高速
• ストレージの速度とサイズの線形スケーリング
• 個々のレプリカにアクセスできないことに対する耐性
• 成熟した実装

欠点 ：

• ごちそうを信頼する必要性は、 ビザンチン将軍の問題に対する不安定さです。

Bigchaindb

BigChainDBまたはIPDB（InterPlanetary DataBase）とも呼ばれるブロックチェーン実装があり、これはデータウェアハウスのすべての問題の解決策と呼ばれることがよくあります。 著者は、非常に高いトランザクション速度（100万/秒）、巨大なストレージ容量（部分レプリケーションを備えた分散ストレージのため）を主張しています。 BigChainDBは、ブロックを構築する際の簡素化されたコンセンサス、およびすべてのブロックとトランザクションを既存のnoSqlデータベース実装RethinkDBまたはMongoDBに保存することにより、これらの利点を獲得します。



残念ながら、このようなアーキテクチャには重大な欠点があります。各ノードには共通のデータウェアハウスへの完全な書き込み権限があるため、システム全体がビザンチン将軍の問題に対して不安定です。 このプロジェクトの作者はこのことを認識しており 、後でそれについて考えることを約束しています。 ただし、製品のリリース後に基本アーキテクチャの基本的な問題を修正するのは非常に時間がかかり、ほとんどの場合不可能です。これは、アーキテクチャが異なる大幅に異なる製品につながる可能性があるためです。 BFT（ビザンチンフォールトトレランス）がない場合のBigChainDBの高速性とボリューム特性は、noSqlデータベースRethinkDBおよびMongoDBで最初に示される特性とそれほど変わらないため、このような基本的な問題に対する簡単なアプローチは、コミュニティからのプロジェクトに対する批判を引き起こしますデータを保存します。 しかし、ノード間の完全な信頼が依然として必要なので、指定されたデータベースを直接使用しないのはなぜですか？



したがって、BigChainDBの実際の使用はプライベートネットワークに限定されます。 人々を誤解させないために、BigChainDBはBigPrivateBlockChainと呼ばれるべきです。そうすれば、疑問は生じません。 パブリックネットワークの場合、これはまったく不適切です。



利点 ：

• 分散noSqlデータベースに匹敵する速度とストレージ

欠点 ：

• 実際、これは通常のnoSqlデータベースであり、ブロックチェーンの欠点によって補完されます
• 不変（法的にデータを削除することはできませんが、悪意がある可能性があります）
• ビザンチン将軍の問題に対する不安定性、したがって、公共ネットワークを使用できない

したがって、BigChainDBは、パブリックネットワーク上の分散アプリケーションからのデータを保存するのにはまったく適していません。

結論

分散アプリケーションで使用できるパブリックネットワークのデータストレージを整理するためのいくつかのアプローチを検討しました。 それらはほとんどありませんでしたが、現時点ではもうありません。 残念ながら、いずれのアプローチも、記事の冒頭で策定したすべての要件を満たしていません。



現在の状況は、プログラムがファイルにのみデータを保存できるコンピューターの形成段階に似ており、これは不便でした。 したがって、彼らはコンピューター用のDBMSを実装し、 一部のコンピューターはその上に状態を作りました。



その結果、既存の分散アプリケーションは、ブロックチェーン上または石器時代のような分散ファイルシステムにデータを直接保存することにより中断されます。 ファイルにインデックスを個別に実装することを余儀なくされ、独自のデータ形式を考案し、一般的に分散型ではあるが自転車の発明に多くの時間を費やします。



しかし、分散アプリケーションの世界は、便利なデータウェアハウスなしでは存続できません。 したがって、記事の次の部分では、上記のすべての要件を満たしていると主張するリポジトリの概念を裁判所に提示します。



→ 記事の第三部

→ 記事の最初の部分