filefilego
v1.4.3
FileFilego協議是一個針對Web3時代設計的對等存儲和數據共享網絡，具有激勵機制，全文搜索和存儲引擎。它的分散體系結構使用戶能夠在沒有審查或單點失敗的情況下存儲和共享數據。通過利用遊戲理論的概念，FileFilego激勵參與並確保數據可用性，同時實現易於故障並保留隱私。
FileFilego是一個開源社區項目，沒有集中控製或所有權。它的硬幣分佈設計為公平，每塊排放40 ffg，每24個月減少一半。該協議是在沒有ICO/sto/ieo或預礦的情況下啟動的，依靠權限證明共識算法的證明，最終將過渡到股份證明，以允許更多的利益相關者參與。
通過支持FileFilego，用戶可以幫助促進數字權利，隱私，信息自由和網絡中立性。我們鼓勵貢獻和創新思想，以確保互聯網仍然是一個開放和分散的平台。
讓我們假設node_1需要下載一些data_x ，該data_x由node_2擁有，並支付node_2所需的費用。對於拜占庭故障節點，會發生什麼？我們如何驗證成功的數據傳輸到目的地節點並防止以下惡意案件：
node_1是一個不誠實的節點，可將data_x報告為無效，以避免支付費用。node_2是一個不誠實的節點，可將data_y提供給node_1並聲稱其是data_x 。 如果node_x可以廣播（點對點）值x，則網絡可以抵抗拜占庭的故障，並滿足以下內容：
node_x是一個誠實的節點，則所有誠實的節點都同意x。轉移機制的證明通過啟用網絡中的誠實節點來驗證並達成有關data_x從node_2到node_1成功傳輸的共識，從而解決了上述問題。這是通過使用驗證器來實現的，驗證者負責挑戰參與節點。雖然一種直接的方法將涉及將所需的數據發送到驗證器，然後將其轉發到目標節點，但此方法可以導致帶寬和存儲瓶頸，從而減少整個網絡吞吐量。因此，已設計轉移解決方案的證明是為了最大程度地減少與此過程相關的帶寬和存儲/內存要求。
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
讓
劃分文件的內容
計算細分市場的默克樹哈希：讓
洗個細分市場：讓
加密1％的洗牌片段：讓
加密段的解密：對於每個
恢復洗牌順序：由於段在加密過程中被洗牌，因此需要使用倒數置換將它們恢復為原始順序
默克樹哈希計算：重新計算恢復順序解密段的默克爾樹哈希。與原始結構類似，構造哈希樹，但使用解密的片段
最後，派生的原始默克爾根哈希
如果派生的merkle root哈希匹配原始默克爾根哈希，則達成共識。
考慮一個涉及包含後續內容的文件的方案：
FileFileGo_Network
將文件上傳到存儲提供商後，通過將其內容分割為不同的數據段來計算文件的默克爾根哈希。
隨後的圖表描述了文件在存儲介質上的簡化表現。圖插圖中的每個單獨的框都像徵了1個數據字節。
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
為了找到該文件的默克爾根哈希，我們將文件分解為較小的部分。例如，讓我們將文件分為九個部分，每個部分只有兩個字節。
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
然後，我們通過應用算法來計算文件的merkle根哈希。
這是該算法如何運行的一個示例：
┌───┬───┬───┬───┬───┬───┬───┬───┐
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）的文件的merkle root哈希，這實際上是另一個哈希值。
當檢索數據的請求到達存儲提供商時，提供商以隨機順序重新安排數據段。例如，考慮數據段的順序：
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）來加密這些部分的一部分。在此說明中，我們將選擇對25％的細分市場進行加密，這相當於2個段。此外，我們將加密每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/factororial/what-is-the-factorial-factorial-of_1024_%3F）
攻擊者隨後的步驟涉及嘗試獲取用於加密這兩個段的密鑰和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根據文件寄養者在數據傳輸到請求者期間生成的隨機訂單對細分進行重新組織。該過程產生了片段哈希的原始序列：
h0
h1
h2
h3
h4
h5
h6
h7
h8
最終，通過執行Merkle root Hash計算，數據驗證者可以推論原始的Merkle root Hash，而無需完全對整個文件內容的本地訪問。
在確認派生的默克爾根哈希匹配原始的哈希後，我們有效地建立了數據下載器擁有所有請求的數據的數學證明。隨後，數據驗證者將加密密鑰/IV和隨機段訂單傳輸到數據下載器，從而自動將費用釋放到文件寄養者。
在本節中，展示了數據傳輸驗證的完整生命週期。
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數據的完整性，如果它們匹配原始的默克爾樹的身份，則將解密密鑰K1提供給node_1 。此外，塊順序將發送到node_1 ，使所有零件的重新組裝形成原始數據。此過程完成後，V1將向node_2釋放費用。
該算法的使用可以同時獲得傳輸證明和數據擁有證明。
按照說明進行編譯並安裝FileFilego
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego是一個分散的網絡，它結合了區塊鏈/加密貨幣，DHT和Bittorrent的創新技術的魯棒性，以形成不可避免的基礎架構。
為了達到10秒的阻滯時間，FileFilego需要一種共識算法，既可以有效地處理大量交易，又可以保守處理能力。在初始階段，我們選擇了權威證明（POA）作為我們的共識算法。將來，股權證明（POS）機制將取代當前的算法。
使用基於POW的新算法進行新區塊鏈會帶來風險，因為已經有大量的計算能力池可用於51％的攻擊。因此，我們選擇了POA，這是根據設計安全的，並提供了支持我們高交易量要求的必要效率。
驗證器的身份被硬編碼到區塊鏈中，可以通過檢查Genesis Block的共同事務來驗證。參與的節點可以通過檢查塊的簽名來輕鬆驗證這些身份的真實性。
隨著我們的前進，當前的POA機制將被驗證證明代替，以使多方能夠參與塊挖掘過程。我們的區塊鏈治理的目標是鼓勵更多的政黨和開發商參與其中並增加利益相關者的參與。實現這一目標的激勵措施之一是證明機制。
為了簡化交易和狀態突變，FileFilego採用了與UTXO樣結構不同的方法。我們沒有使用此類結構，而是將會計和元數據作為常規數據庫行存儲，同時在數據庫中保留其原始格式的原始塊。這種方法有助於消除不必要的複雜性。
在本節中，我們將概述FileFilego中使用的技術術語和概念。
FileFilego中的頻道使用戶能夠將數據組織和將數據分組為不同的存儲桶或文件夾。例如，Ubuntu.com上的所有內容都可以放置在名為“ Ubuntu官員”的頻道中。創建頻道的用戶將獲得更新和其他與渠道相關操作所需的所有權限。
通道以節點鍊格式結構，可以識別為沒有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 |
| 米利夫 | 1.000.000.000.000.000 |
| FFG （默認單元） | 1.000.000.000.000.000.000 |
| ZFFG | 1.000.000.000.000.000.000.000 |
總供應： 5億FFG驗證/利益獎勵：每塊40 FFG供應降低率：每24個月除以2
