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

記事の最初の部分では 、ブロックチェーンにアプリケーションデータを保存する際に問題が見つかりました。 第2部では、データウェアハウスの要件を説明し、既存の実装がこれらの要件を満たす方法を調べました。 結果は期待外れでした-満足のいく実装は見つかりませんでした。 このパートでは、要件を満たす分散型データウェアハウスの概念を提案します。 もちろん、何が起こっているかをより深く理解するために、 前の2つのパートを参照することをお勧めします。



そのため、1つまたは別のパラメーターの現在のストレージ実装は、ブロックチェーン上の分散型アプリケーションの幅広いクラスに適合するデータベースの要件を満たしていません。



速度のために、ブロックチェーンとの非剛体接続は受け入れられる（つまり、すべてのトランザクションがブロックチェーンを通過するわけではない）ことを考えると、他のデータベースノードの悪意のある動作に耐性があり、十分なレベルのレプリケーションを提供し、参加者がネットワークをサポートするように動機付けるメカニズムが必要です。 つまり、このようなベースには、スマートコントラクトによるブロックチェーンのサポートが必要になります。



そのようなデータベースを作成する場合、 Apache Cassandraなどの既存のnoSql実装に基づいて構築することをお勧めしますが、同時にデータベースに次のプロパティを付与します。

• データベースは公開されており、データベースのユーザー（クライアント）はその公開キー（ブロックチェーンと同じキー）で識別されます-これはユーザーIDです。
• 各ユーザーはトランザクションをデータベースに送信できます。各トランザクションはこのユーザーによって署名される必要があります。
• ユーザーが作成した新しいレコードは、その所有者であることを記憶しています。
• 所有者（またはブロックチェーン上のスマートコントラクトとして実装された許可メカニズムによって信頼が確立されているユーザー）のみが、作成後にレコードを変更できます。
• 誰でもすべてのメモを読むことができます。
• 異なるユーザー間でレコードのキーが競合するのを防ぐために、すべてのユーザーレコードキーにユーザーIDというプレフィックスが付けられます。
• ブロックチェーンのスマートコントラクト（たとえば、特定のユーザー間の信頼、テーブルを作成/削除する権限）などを使用して、より複雑なアクセス許可を設定できます。
• すべての権限は、トランザクション中とレプリケーション中の両方で必ずチェックされます。

各レコードの必須の暗号署名は、レコードの所有者の個人キーを知らずに悪意のある当事者がそれを変更または削除できないようにします。 つまり、このように構築されたデータストレージは、コンセンサスメカニズムがなくてもビザンチン問題に耐性があります。



これにより、このようなスキームの速度が、noSqlデータベースの既存の実装の速度とそれほど変わらないことが期待されます。 ただし、攻撃者はキーペアを生成し、データベースにガベージレコードを作成することにより、 Sybil攻撃を実行できます。 この問題は、動機の導入によって解決されます。

やる気

パブリックネットワークは、参加者が自由に参加できることを想定しており、コンピューティングパワー、ストレージ容量、およびネットワーク分散を強化する機器を提供します。 この行動を刺激するために、機器の所有者は、正直に働くよう動機づける報酬を受け取る必要があります。



これは、データベース操作がエンドユーザーによって支払われることを意味します。 これは、ブロックチェーンに精通していないが正当化されている人にとってはワイルドに聞こえるかもしれません。 実際、ブロックチェーンプロジェクトにはほとんどの場合、所有者がいません。 それらはコミュニティによって所有されています。 その結果、コミュニティ自体がプロジェクトの費用を支払う必要があります。 お金は非常に少ないですが、ゼロではありません。 この記事の前の部分で検討した既存の分散ファイルストレージも、ファイルの保存に対してユーザーに課金します。 そして、私たちがいなければ、どこでも、基本的なレベルでは、機器の機能はユーザーによって支払われるべきではありません。 原則として、これらのコストは他のソースから相殺できますが、このトピックはこの記事の範囲外です。



同様のEthereum Swarmアワードは次のとおりです。

• データ取得賞
• ストレージ賞

報酬は、データベースにクエリを実行するユーザーの資金から割り当てられます。 ブロックチェーンを介した支払いには非常に長い時間がかかるため、迅速な支払いには、 オフチェーントランザクションと「小切手帳」の2つの方法を使用できます。 オフチェーントランザクションの場合、ユーザーは各データベースノードでオフチェーンチャネルを作成する必要があります（またはノード間の中間チャネルを使用します）。 そのような各チャネルは、その上で資金を予約する必要があることを考えると、これは非常に高価になる可能性があります。 したがって、主なアプローチとして「小切手帳」アプローチを採用します。 それが何であるかを説明しましょう。



データベースにアクセスする前に、ユーザーは特別なスマート契約「小切手帳」に資金の一部を予約する必要があります。 さらに、データベースノードはこの契約のアドレスを使用して報酬を受け取ります-小切手帳契約は所有者のお金を保存し、第三者が所有者によって署名された小切手を現金化できるようにします。

• 契約は、接続中に各受信者に発行された合計金額を追跡します
• 小切手を送信するとき、所有者は送信された合計金額を覚えておく必要があります

小切手は次の場合に換金されます

• 契約の住所は小切手の住所に対応しています
• 所有者によって署名された小切手（ユーザーID-公開鍵）
• 小切手の合計金額が、この受取人の以前にキャンセルされた小切手よりも多い

次に、必要に応じて、データベースノードに報酬を与えます。ユーザーは単に小切手を送信します。 受信ノードは、各ユーザーから最後に受信した小切手のみを保存し、「小切手帳」を契約に送信することで定期的に現金化できます。

データ取得賞

データベースノード上のデータには特定のレベルのレプリケーションがあります。つまり、特定のキーを持つデータはノードの一部（たとえばN）にのみ保存されます。 それにもかかわらず、ユーザーはデータの任意のノードを使用できます。 ユーザーがアクセスしたノードは、「コーディネーター」として機能します。



データキーの値によって、これらのキーの保存を担当するN個のノードが計算され、リクエストが送信されます。 ノードから返されたデータは、コーディネーターによって電子署名に準拠しているかどうかがタイムスタンプで比較され、最新のレコードがユーザーに返されます。



支払いは、コーディネーターとデータを保存するレプリカの作業によるものです。 支払いの割合はより詳細な計算の対象となりますが、適切な行動を促すには、次の原則に従う必要があります。

• ノードがデータを返す速度が速いほど、支払いに値する部分が多くなります。
• ノードが古いデータを返した場合、支払いは減額されます
• データを返さないノードは何も受け取りません
• コーディネーターは固定された小部分を受け取ります

データとともに、コーディネーターは請求書を発行し、請求書はどのノードにいくらになるかを示します。 ユーザーは全員にチェックを書き込みます。 コーディネーターはチェックをノードに送信します。 ノードが何も返さなかった場合、または古いデータを返さなかった場合は、更新されたデータと同様に。



悪意のあるコーディネーターと支払いを行わないユーザーから保護するために、各ノードは支払いを期待するユーザーのリストを管理し、コーディネーターはこれらのユーザーからリクエストを送信します。 負債レベルが特定のしきい値を超えると、ノードは指定されたユーザーおよびコーディネーターからのリクエストの受け入れを停止する場合があります。 チェックを受信すると、リストが調整されます。

ストレージ報酬

検索報酬は間接的にストレージを刺激しますが、頻繁に要求される人気のあるデータに対してのみ機能します。 データの長期保存を促進するには、特にまれにしかリクエストされない場合、保存に対する報酬が必要です。



Ethereum Swarmの記事では、ストレージ報酬システムについて説明しています。 ノードはしばらくの間、情報所有者とデータストレージ契約を締結します。 データが実際に保存されている場合、保存料はデータ保存時（更新時）またはしばらくしてから発生する場合があります。 契約中にデータの損失が検出された場合、サイトに罰金を科すことができます。そのためには、各サイトで保証金の初期登録が必要です。



データを保存すると、ノードはレシートを返します。これは、ノードがストレージ用のファイルを受け入れたことの証明として機能します。 その後、このレシートにより、それらに対応するデータがまだ保存されているかどうかを確認し、保存されていない場合は、問題のあるノードを処罰できる司法スマート契約のトランザクションを開始できます。



私たちの場合、データは静的ではなく、同じキーを持つレコードが複数回上書きされる可能性があります。 この場合、元のレコードだけでなく、同じキーを持つ新しいレコードも、提示された領収書に対応できます。



ユーザーが開始したデータ削除操作中に、物理的な削除の代わりに、データは特別な「ゼロ」レコードに置き換えられます。 レコードは、ストレージ契約の有効期限が切れた後に物理的に削除できます。

全文検索、セカンダリインデックス

noSqlデータベースでは、少数のノードを使用したクイック検索は主キーでのみ可能です。 この点で私たちのデータベースはそれらと大差ありません。 一方、キーワードによるレコードの検索、およびいくつかの基準によるレコードのグループ化は、セカンダリインデックスと全文検索なしでは実現が困難です。 全文検索およびセカンダリインデックスの使用については、 Elassandraに類似したソリューションを使用することをお勧めします。 このソリューションは、分散noSql Cassandraデータベースの各ノード上のローカルElasticSearchフルテキストインデックスです。 フルテキストリクエストはコーディネーターによってすべてのノードに送信された後、混合されてクライアントに返されます。 追加のインデックスは各ノードでローカルに独立して作成されるため、ビザンチン将軍の問題をさらに防止する必要はありません。

まとめ

したがって、分散型アプリケーションで使用するための要件を満たす、ブロックチェーンに関連するパブリックデータベースの概念を提示しました。

• 配布
  
  データベースは無制限の数のレプリカをサポートします。各レプリカはコーディネーターにすることができます。 つまり、それらの1つを参照すると、ユーザーはすべてのデータにアクセスできます。
  
  
  
  
• 宣伝
  
  データベースは、公共の環境で動作するように設計されています。 新しいノードをネットワークに追加して、いつでも負荷の一部を取ることができます。
  
  
  
  
• ビザンチン将軍の問題および公共ネットワーク上の他のタイプの攻撃に対する抵抗
  
  データベースに配置されたすべてのデータは所有者によって署名されていることを考慮すると、ノードはその裁量でデータを置き換えることも、他のノードでのレプリケーション中にデータを台無しにすることもできません。 なりすましの試みは、電子署名メカニズムを使用してすぐに検出されます。 置換を試みた場合、違反ノードは登録デポジットを奪われ、ネットワークから除外される可能性があります。 デポジットを配置するには、アクセス権、ノード間の相互決済のメカニズム、外部（DB用）ブロックチェーンを使用します。これは、チューリング完全なスマートコントラクトをサポートする必要があります。
  
  
  
  
• シャーディングのサポート （各ノードでデータの一部のみを複製して、データの最大合計量を増やす機能）。
  
  各データベースノードは、格納するプライマリデータキーの特定の間隔を担当します。 レプリケーションレベル（同じプライマリキーを持つデータのコピーを格納するノードの数）は個別に設定され、ネットワークの成長に伴って成長する可能性があります。
  
  
  
  
• スピード
  
  データストレージの原則は、そのようなデータベースでのデータの書き込みと読み取りの速度は、Apache Cassandraなどのそのようなデータベースの現在の実装とそれほど変わらないことを示唆しています。
  
  
  
  
• 構造化データを保存する機能
  
  このようなデータベースのデータは、構造をサポートしています。 特定のアプリケーションに適した構造を持つJSONドキュメントにすることができます。
  
  
  
  
• データを削除する機能
  
  データ削除がサポートされています。 即時削除を保証することはできませんが、最終的には、ノードの適切な動作により、データが削除されます。 悪意のあるノードは、削除されたすべてのデータを意識的に保存できます。 ただし、リクエストは主キーの特定の間隔でのみ送信されるため、すべてのデータに対してこれを行うことはできません。
  
  
  
  
• 主キーだけでなく検索機能を備えたクエリ言語
  
  ElassandraプロジェクトのCassandraとの統合方法と同様に、 ElasticSearchを使用して、2次キーと全文検索でクエリ言語を拡張することができます。

このようなデータベースは、チューリング完全なスマートコントラクトをサポートするブロックチェーン上の分散アプリケーションで使用できます（ただし、他のブロックチェーンの場合、分散アプリケーションは作成されません）。 たとえば、 イーサリアム 、 RChain、およびその他のブロックチェーンの上にある分散アプリケーションのニーズに使用できます。



このようなデータベースの概念は、オープンソースプロジェクトSupermanの一部として開発されました。 まだ実装はありませんが（明らかに需要があります）、今日、この概念は一般に公開されています。 最初に提示されたパブリックな分散型noSqlデータベースの概念が、それについて議論したり、 開発に参加したりするのに十分な関心を引くことを願っています。 また、電報でチャンネルに参加して、開発者とチャットすることもできます（英語）。



→ 記事の最初の部分

→ 記事の後半