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
