filefilego
v1.4.3
FileFilegoプロトコルは、Incentiveメカニズム、フルテキスト検索、ストレージエンジンを備えたWeb3 ERA向けに設計されたピアツーピアストレージおよびデータ共有ネットワークです。その分散アーキテクチャにより、ユーザーは検閲または単一の失敗ポイントなしでデータを保存および共有できます。ゲーム理論の概念を活用することにより、FileFilegoは参加を奨励し、データの可用性を確保し、断層耐性とプライバシーを維持します。
FileFilegoはオープンソースのコミュニティプロジェクトであり、集中管理や所有権はありません。そのコイン分布は、24か月ごとに半分減少するブロックあたり40 FFGの放出で、公平になるように設計されています。プロトコルは、ICO/STO/IEOまたはPRE-MINEなしで開始され、より多くの利害関係者が参加できるようにするために、最終的に利害関係の証明に移行する権限コンセンサスアルゴリズムに依存します。
FileFilegoをサポートすることにより、ユーザーはデジタル権利、プライバシー、情報の自由、ネット中立性を促進するのに役立ちます。インターネットがオープンで分散化されたプラットフォームのままであることを保証するために、貢献と革新的なアイデアを奨励します。
node_1 、 node_2が所有するdata_xをダウンロードし、 node_2が必要とする料金を支払う必要があるとします。ビザンチンの断層ノードの場合はどうなりますか？成功したデータ転送を宛先ノードに確認し、次の悪意のあるケースを防止するにはどうすればよいですか。
node_1 、料金の支払いを避けるために、 data_x無効であると報告する不正なノードです。node_2 、 data_yをnode_1に提供し、それがdata_xであると主張する不正なノードです。 node_x値xをブロードキャスト（ピアツーピア）にし、以下を満たすことができる場合、ネットワークはビザンチン断層に抵抗できます。
node_xが正直なノードである場合、すべての正直なノードは値xに同意します。転送メカニズムの証明は、ネットワーク内の正直なノードがnode_2からnode_1へのdata_xの成功した転送を検証して到達できるようにすることにより、前述の問題に対処します。これは、参加ノードに挑戦する原因となる検証剤の使用によって達成されます。簡単なアプローチでは、必要なデータを検証剤に送信してから宛先ノードに転送することが含まれますが、この方法は帯域幅とストレージボトルネックにつながり、それによりネットワーク全体のスループットが削減される可能性があります。したがって、転送ソリューションの証明は、このプロセスに関連する帯域幅とストレージ/メモリの要件を最小限に抑えるように設計されています。
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
させて
ファイルのコンテンツを分割します
セグメントのマークルツリーハッシュを計算します
セグメントをシャッフル：レット
シャッフルされたセグメントの1％を暗号化します
暗号化されたセグメントの復号化：それぞれ
シャッフル順序の復元：暗号化プロセス中にセグメントがシャッフルされたため、逆順列を使用して元の注文に復元する必要があります
メルクルツリーハッシュ計算：復元された順序で復号化されたセグメントのメルクルツリーハッシュを再計算します。元の構造と同様にハッシュツリーを構築しますが、復号化されたセグメントを使用します
最後に、派生した元のマークルルートハッシュ
派生したマークルルートハッシュが元のマークルルートハッシュと一致する場合、コンセンサスが達成されます。
次のコンテンツを含むファイルを含むシナリオを検討してください。
FileFileGo_Network
ファイルをストレージプロバイダーにアップロードすると、ファイルのMerkleルートハッシュは、コンテンツのセグメンテーションを通じて個別のデータセグメントに計算されます。
次の図は、ストレージ媒体上のファイルの配置の簡略化された症状を示しています。図内の個々のボックスは、1バイトのデータを象徴しています。
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
このファイルのマークルルートハッシュを見つけるために、ファイルを小さな部分に分割します。たとえば、ファイルを9つのセクションに分割しましょう。各部分には2バイトしかありません。
0 1 2 3 4 5 6 7 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ F i │ l e │ F i │ l e │ G o │ _ N │ e t │ w o │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
次に、各セグメントのハッシュを取得します。
segment 0: hash("Fi"), denoted by h0
segment 1: hash("le"), denoted by h1
segment 2: hash("Fi"), denoted by h2
segment 3: hash("le"), denoted by h3
segment 4: hash("Go"), denoted by h4
segment 5: hash("_N"), denoted by h5
segment 6: hash("et"), denoted by h6
segment 7: hash("wo"), denoted by h7
segment 8: hash("rk"), denoted by h8
そして、アルゴリズムを適用して、ファイルのマークルルートハッシュを計算します。
このアルゴリズムがどのように動作するかの例は次のとおりです。
┌───┬───┬───┬───┬───┬───┬───┬───┐
Data Blocks:│ a │ b │ c │ d │ e │ f │ g │ h │
└───┴───┴───┴───┴───┴───┴───┴───┘
0 1 2 3 4 5 6 7
│ │ │ │ │ │ │ │
└───┘ └───┘ └───┘ └───┘
h01 h23 h45 h67
│ │ │ │
└───────┘ └───────┘
h(h01+h23) h(h45+h67)
│ │
│ │
└───────────────┘
Merkle root: h(h(h01+h23)+h(h45+h67))
これで、ファイルにはMT（F）として表されるファイル用のマークルルートハッシュを所有しています。これは、本質的に別のハッシュ値です。
データを取得するリクエストがストレージプロバイダーに到達すると、プロバイダーはデータセグメントをランダムな順序で再配置します。たとえば、データセグメントのシーケンスを考慮してください。
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] 、これは次の配置に変換されます。
1 5 2 4 7 6 3 0 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ G o │ w o │ e t │ l e │ F i │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
その後、プロバイダーは対称キーと初期化ベクトル（IV）を生成して、これらのセグメントの一部を暗号化します。この図では、2つのセグメントに相当するセグメントの25％を暗号化することを選択します。さらに、4つのセグメントごとに暗号化し、0番目と4番目のセグメントを暗号化することを意味します。
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
これで、前述のデータがデータリクエスターに提供されます。同時に、キー/IV、セグメントのランダム化された順序、およびセグメント0および4の内容は、 data verifierに送信されます。ファイル内のセグメントの順序と暗号化キー/IVの両方に関して、ダウンローダーがZero-Knowledgeを持っていることを強調することが重要です。
誰かがセグメントのさまざまな組み合わせを試みて元の順序を決定するためにスクリプトを作成する可能性を心配しているかもしれません。
さらなる洞察を提供するために、実際のシナリオでファイルが約1024のセグメント（またはわずかに少ない）に分割され、これらのセグメントがランダム化されることを考慮してください。攻撃者が元のセグメント順序を再構築するには、「繰り返しなく順列」を実行する必要があります。これらのファイルセグメントをアレンジする方法の合計カウントは、nによって与えられます！ （要因）、1024に相当します！この場合。 （https://coolconversion.com/math/factorial/what-is-factorial-of_1024_%3f）
攻撃者のその後のステップでは、2つのセグメントの暗号化に使用されるキーとIVの取得を試みます。ただし、このタスクは現在、フィールドの既存の脆弱性に基づいて不可能と見なされていることに注意してください。
これに続いて、ファイルダウンローダーは、ネットワーク内の指定されたdata verifierから暗号化キー/IVとファイルセグメントのランダム化順序を要求する必要があります。
データダウンローダーは、暗号化キー/IVとランダム化されたセグメントを求めて、データ検証者にリクエストを送信します。このリクエストには、ダウンロードされたファイルのセグメントハッシュが付属しています。これには次のように表示されます。
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
data verifier 、セグメント0および4の暗号化とハッシュを引き受け、次のハッシュ値をもたらします。
h1
h5
h2
h4
h7
h6
h3
h0
h8
最後に、 data verifierデータ転送中にファイルHosterによって生成されたランダム化された順序に従ってセグメントを再編成します。このプロセスにより、セグメントハッシュの元のシーケンスが得られます。
h0
h1
h2
h3
h4
h5
h6
h7
h8
最終的に、Merkle Root Hash計算の実行を通じて、データ検証剤は、ファイルコンテンツ全体に完全にローカルアクセスする必要なく、元のMerkle Root Hashを推測します。
派生したマークルルートハッシュが元のものと一致することを確認すると、データダウンローダーがすべての要求されたデータを所有しているという数学的証拠を効果的に確立しました。その後、データ検証剤は暗号化キー/IVを送信し、ランダム化されたセグメントはデータダウンローダーに注文し、ファイルHosterへの料金の自動リリースにつながります。
このセクションでは、データ転送検証の完全なライフサイクルが実証されています。
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Responseペイロードには、スマートコントラクトトランザクションを準備するために必要なすべての情報が含まれています。このトランザクションは、ネットワークにブロードキャストされ、検証剤によって選択されます。 ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ）は、参加しているノードと通信し、データをホストするノード（ node_2 ）の課題を生成します。課題は次の手順で構成されています。node_2 、最初にアップロードされたdata_xの元のマークルルートと一致するメルクルツリーを作成する必要があります。v1 、 node_2によってnode_1に送信されるブロック/データ範囲の順序と数を決定します。まだnode_1にブロックの順序を明らかにしたくありません。v1 、固定された範囲のデータをnode_2要求します。これは、ランダムキーk1をv1によってdata_encとして使用して暗号化され、 node_1に送信されます。この段階では、 node_1いくつかのdata_zとdata_encを所有していますが、それらを組み合わせて元のファイルを取得する方法の知識がありません。検証剤V1は、 node_1に送信されるデータの整合性を検証でき、元のMerkleツリーのIDと一致する場合、復号化キーK1がnode_1に提供されます。さらに、ブロック順序はnode_1に送信され、すべてのパーツの再組み立てが可能になって元のデータを形成します。このプロセスが完了すると、V1はnode_2に料金をリリースします。
このアルゴリズムを使用すると、転送の証明とデータの所有証明の同時に達成できます。
手順に従って、FileFilegoをコンパイルおよびインストールします
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilegoは、ブロックチェーン/暗号通貨、DHT、およびBitTorrentの革新的な技術の堅牢性を組み込んだ分散ネットワークであり、攻撃不可能なインフラストラクチャを形成します。
10秒のブロックタイムを達成するために、FileFilegoには、大量のトランザクションを処理し、処理能力を保全するのに効率的なコンセンサスアルゴリズムが必要です。初期段階では、コンセンサスアルゴリズムとして権威の証明（POA）を選択しました。将来的には、現在のアルゴリズムに置き換えられます。
新しいブロックチェーンにPOWベースのアルゴリズムを使用すると、51％の攻撃に使用できるコンピューティングパワーのかなりのプールがすでにあるため、リスクが発生します。したがって、POAを選択しました。POAは設計上安全であり、高いトランザクションボリューム要件をサポートするために必要な効率を提供します。
バリデーターのアイデンティティはブロックチェーンにハードコードされており、Genesis BlockのCoinbaseトランザクションを調べることで検証できます。参加しているノードは、ブロックの署名をチェックすることにより、これらのアイデンティティの信頼性を簡単に検証できます。
私たちが前進するにつれて、現在のPOAメカニズムは、複数の関係者がブロックマイニングプロセスに参加できるようにするために、証明の実証に置き換えられます。ブロックチェーンガバナンスの目標は、より多くのパーティーと開発者が関与し、利害関係者の関与を増やすことを奨励することです。この目標を達成するためのインセンティブの1つは、ステークの証明メカニズムです。
トランザクションと状態の突然変異を簡素化するために、FileFilegoはUTXOのような構造とは異なるアプローチを採用しています。このような構造を使用するのではなく、データベース内の元の形式で生のブロックを保持しながら、会計とメタデータを通常のデータベース行として保存します。このアプローチは、不必要な複雑さを排除するのに役立ちます。
このセクションでは、FileFilegoで使用される技術用語と概念の概要を説明します。
FileFilegoのチャネルにより、ユーザーはデータを整理して個別のバケットまたはフォルダーにグループ化できます。たとえば、ubuntu.comのすべてのコンテンツは、「Ubuntu Official」という名前のチャンネルに配置できます。チャネルを作成するユーザーは、更新やその他のチャネル関連操作に必要なすべてのアクセス許可を受信します。
チャネルはノードチェーン形式で構成されており、 ParentHashのノードとして識別できます。
サブチャネルの概念は、データをさらに分類できることです。たとえば、文書、写真、音楽。
FileFilegoでは、 Entry 、分類/注文ではなく、エントリ自体に関するより多くの情報を含む投稿またはデータを表します。 FileとDirectory Entryに配置できます。
Storage Engineは、ブロックチェーン内のハッシュポインターで使用されるバイナリデータを追跡するストレージレイヤーであり、データを参照します。 NodeItem構造には、バイナリハッシュを指すFileHashというフィールドがあり、 "{HASH_ALGORITHM}:>{DATA_HASH}"の形式です。ハッシュアルゴリズムのメタデータを将来役立つ可能性があるため、保持したいと思います。
FileFilegoでは、コアブロックチェーン機能と同様に、検索の精度と柔軟性も同様に重要です。特定のクエリ言語を使用して、ユーザーがバイナリ検索を含む複雑なクエリを構築できるようにすることを目指しています。たとえば、次のタイプのクエリを可能にする必要があります。
このような複雑なクエリをサポートするクエリ言語を開発することは、検索エンジンの精度を大幅に向上させることができる強力なツールです。
--search CLIフラグを使用して、ノードのフルテキストインデックス機能を有効にすることもできます。
ストレージレイヤーはバイナリファイルを追跡し、ハッシュを使用してブロックチェーン内の情報を表します。この機能は、次のフラグを使用してオンにすることができます。
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir 、適切な読み取り/書き込み許可を備えたディレクトリである必要があります。このメカニズムがなければ、完全なノードは機能しないことに注意してください。 storage_tokenは、HTTP APIを使用して他のトークンを作成できるため、管理者の権利をトークンに付与するトークンです。これは、Webアプリまたは個別のユーザーが必要とする場合に役立ちます。 --storage_fees_byte="10000"は、データのバイトごとに請求される料金です。
| ユニット | 価値 |
|---|---|
| ffgone | 1 |
| KFFG | 1.000 |
| MFFG | 1.000.000 |
| GFFG | 1.000.000.000 |
| Microffg | 1.000.000.000.000 |
| Miliffg | 1.000.000.000.000.000 |
| FFG （デフォルトユニット） | 1.000.000.000.000.000.000 |
| zffg | 1.000.000.000.000.000.000.000.000 |
総供給： 5億FFG検証/ステーク報酬：ブロックあたり40 FFG供給率の減少率： 24か月ごとに2で割る
