概要

Fleek Network 是一个去中心化边缘平台，经过优化，可促进高性能 Web 服务（CDN、无服务器功能等）的部署和运行。Fleek Network的全球分布式、自主控制的边缘节点网络使开发者可以轻松创建和利用多种边缘服务。这些服务继承了加密且经济安全的基础设施，保障节点和地理范围覆盖、稳定且可预测的成本、以及网络上运行的所有服务的一致质量和性能。Fleek Network的目标是提供一个平台，所有Web3协议、中间件、服务和应用程序都可以从中受益，以进一步分散其堆栈，而无需牺牲成本、性能、复杂性或开发人员/终端用户体验。

背景：网络的演变

现代Web堆栈的演变

Web堆栈已经发生了巨大的发展，迁移到“云”很快就会被迁移到“边缘”所取代。虽然这种趋势确实具有安全性和成本优势，但迁移到边缘的主要原因是性能/延迟。延迟和加载时间对互联网用户及其服务/应用程序的使用产生巨大影响，因此也取决于构建它们的开发人员（以及构建为其提供支持的基础设施/中间件的开发人员）。Google的研究表明，当页面加载时间从1秒增加到3秒时，跳出的几率会增加32%；当页面加载时间从1秒增加到5秒，跳出的几率会增加90%。结合当前内容/流媒体导向的服务的使用/增长，在线游戏的逐年指数增长以及人工智能/增强现实/虚拟现实的兴起，对低延迟优化网络基础设施的需求只会增加。

边缘网络是内容交付网络 (CDN) 概念和成功的演进，内容交付网络根据最终用户的位置从多个地理位置提供内容。目标是通过尽可能靠近最终用户执行工作（例如提供内容）来减少延迟。这种模式现在被应用于其他类型的非常适合边缘的传统 Web 基础设施和服务，例如计算（例如无服务器函数、服务器端渲染）、数据库（例如 CRDT）、DNS、容器编排等

React、Next.js 等现代前端框架也加速了向边缘的迁移。这些框架通常称为 Jamstack，是一种将 Web 体验层与数据和业务逻辑分离的架构方法。体验和逻辑的解耦提高了灵活性、可扩展性、性能和可维护性，并为 Web 提供了可组合的架构，其中通过 API 使用自定义逻辑和第三方服务。

Web3 的模块化和可组合式演变

与现代 Web 的发展类似，Web3 也正在快速迈向模块化和可组合的未来。业界正在见证众多专门协议和中间件的出现，它们提供跨越整个基础设施堆栈的特定服务。以前的“巨石”架构现在被解耦并分解为更小的、可互操作的独立模块。

然而，Web3 的这一趋势仍处于起步阶段，整个领域仍然存在大量低效率和冗余的工作。由于缺乏 Web3 CDN/边缘网络，几乎所有 Web3 协议、中间件、服务和应用程序都必须在以下两条次优路径之间进行选择：

在其堆栈中利用公司控制的云基础设施（例如 AWS 或 Cloudflare）来实现“类似 web2”的性能（当今大多数开发人员和最终用户的要求），这通常会在其堆栈中产生中心故障点并显着削弱它们的去中心化、审查制度的抵制和未经许可的性；
尝试将所有这些性能优化构建到其网络/经济模型/节点/堆栈中（专业网络和 p2p、基于地理和声誉的路由、通过算法确定哪些节点应该执行哪些工作/提供哪些内容、负载平衡请求等）。对于每个尝试自行构建的项目来说，这是高度复杂、耗时且低效的。

将现代 Web 引入 Web3

将高性能的去中心化边缘网络作为共享基础设施、编排和性能层引入到 Web3 堆栈中，对于几乎每个 Web3 项目（协议、中间件、服务、应用程序）都是有用的。它可以帮助为 web3 带来类似于 Web 的集中式性能，而无需牺牲 web3 的价值。

共享边缘基础设施还可以帮助构建 web3 基础设施/中间件的开发人员降低进入门槛并加快上市时间，方法是将部分堆栈卸载到去中心化边缘，而不需要将该功能构建到自己的网络中。这将使他们能够将更多的时间/资源集中在他们独特的产品/服务方面，并将性能/延迟优化留给上面的边缘层，类似于现代网络。

Fleek Network：去中心化边缘平台

Fleek Network 的目标是提供一个高效、无需信任、去中心化的边缘网络，支持多种边缘服务。鉴于可以构建大量边缘服务，Fleek Network 核心的目的是成为一个基础层，允许任何人快速开发和提供新的边缘服务，而无需担心网络等重要方面、智能路由/工作分配、负载平衡或任何其他不是其服务核心特性/功能的层。 Fleek Network 通过使网络核心具有地理感知能力并优化速度来实现这一目标。

该网络的核心是最小的，专注于有效验证节点批处理并提交给协议的简洁的交付确认 SNARK（在协议部分进行扩展）。所有特定于服务的逻辑都是在核心协议之外处理的。 Fleek Network 相信这种架构可以成为 Web3 堆栈的强大补充，对于构建和/或高效优化去中心化 Web 基础设施/服务非常有用。随着 Fleek Network 的发展及其全球覆盖范围的扩大，基于网络构建的所有服务都会平等受益。

关键概念和性能优化

边缘网络的基础是高性能、低延迟和地理负载分布。这些是大多数去中心化系统在基础协议层难以应对的特征。以下部分描述了 Fleek Network 中的关键概念和值得注意的性能优化，使我们能够实现边缘网络的性能要求：

地理意识

虽然网络不具有特定的地理概念，但它通过收集节点之间的延迟和跳数数据获得对地理邻近性的隐式理解，这是信誉系统的一部分。有助于地理意识的三个关键方面是：

彼此之间表现出低延迟和跳数的节点被认为距离较近。
每个节点都会定期与其 k 个最接近的对等节点共享其所持有的最受欢迎（即请求最多）内容的一组近似值。
采用布谷鸟滤波器作为集合近似的概率数据结构来实现这一点。

这种方法与其他系统组件无缝集成，并有效地使 Fleek Network 节点能够在附近/最佳节点之间分配工作负载。

智能路由&工作分配

许多去中心化系统依赖于权益加权的工作分配和gossip 机制来促进广播和通信功能。这些网络的算法通常在不假设有关网络中其他节点的可靠性或地理位置的先验知识的情况下运行。即使有关可靠性的数据是在运行时收集的，它也经常被用作尽力而为的机制，而不是作为设置参数。

与大多数其他去中心化系统相比，Fleek Network 使用独特的设置：

网络的节点在每个epoch都保持固定，直到下一个epoch开始之前没有新节点加入（假定节点已完成加入）。
在所有节点都可以访问的应用程序状态中存储和复制了信誉统计数据。
所有节点的质押金额相同，工作分配严格基于地理位置和声誉（即质押金额对节点接收的工作量没有影响）。

利用这些额外的假设可以显着优化网络的gossip和广播层的性能，并通过将工作路由到距离请求的最终用户最近的节点来减少请求的延迟。

本质上，该协议利用这些信息并采用确定性算法为整个网络创建高效且容错的连接图。在每个新epoch开始时，网络中的节点可以汇聚到相同的整体网络连接图上。

无状态执行

默认情况下，Fleek Network 执行环境的状态本地绑定到运行服务的节点。这使得 Fleek Network 成为创建无状态计算和执行可以使最终用户受益的服务的最佳选择。

保持执行环境全局无状态（locally bounded 局部有界）有助于网络保持最大性能和低延迟，但它也允许我们在每个epoch跨节点洗牌服务以确保去中心化，并且显着降低节点串通或恶意行为的能力。这也有助于网络自主优化每个epoch哪些节点执行哪些服务的能力。

无虚拟机核心（VM-Less Core）

虽然开发人员可以在服务层构建/利用 VM（在服务部分中进行说明），但 Fleek Network 的核心协议不使用 VM。无虚拟机核心可以更有效地利用服务的节点资源，并减少构建服务的开发人员的限制。例如，有时非 EVM 协议将 EVM 作为在其协议上运行的智能合约/服务来实现，以实现“EVM 兼容性”。然而，这实际上需要两个虚拟机（EVM 在协议本机虚拟机中运行），从而导致效率低下。相比之下，在 Fleek Network 上情况并非如此，各种虚拟机可以构建为服务，可以直接消耗边缘节点资源，而无需任何不必要的开销。虽然这种架构确实引入了新的安全考虑因素，但 Fleek Network 遵循与现代容器化软件中使用的策略类似的策略，例如 cgroups、selinux/apparmor 和其他相关的内核级解决方案。沙箱系统的最终细节将单独发布，不属于本文的讨论范围。

内置（外部可扩展）文件系统

Fleek Network 拥有一个由多个外部去中心化存储协议（例如 Filecoin、Arweave、IPFS 等）提供支持的内置文件系统。通过采用模块化并利用现有的外部文件存储协议，而不是尝试在网络中构建存储，节点可以保持极其精简，使网络能够比节点需要承载的网络更专注于优化性能和低延迟。存储，并减少使用网络的开发人员在存储/数据层选择方面的锁定风险。

在 Fleek Network 上运行的服务可以利用 SDK 有效地访问共享内容检索组件。例如，服务构建者可以轻松实现数据计算服务，类似于在集中式设置中创建此类服务的方式。

Fleek Network 在网络中存储某些有限状态（请参阅简洁链状态部分），但任何其他数据存储要求服务都通过这些内置存储选项或服务想要使用的任何其他外部选项（例如任何其他 web3协议）。

内容可寻址核心

Fleek Network 使用 Blake3 哈希来实现高效的内容识别和流式验证。整个网络基于内容寻址运行。除了文件系统之外，Fleek Network 还采用了分布式哈希表 (DHT)，使网络能够存储从任何“不可变数据指针”或 IPLD（星际链接数据）到其相应的 Blake3 哈希的灵活映射。不可变数据指针是指对随时间保持一致的外部数据的引用。不可变数据指针是内容可寻址性的更广泛概念。例如，如果数据存储协议利用顺序 ID 来识别内容并禁止将来修改，则这些顺序 ID 可以充当不可变指针。用正式术语来说，不可变数据指针是永久对应于相同内容的字符串。

不可变数据指针是内容可寻址性的更广泛概念。例如，如果数据存储协议利用顺序 ID 来识别内容并禁止将来修改，则这些顺序 ID 可以充当不可变指针。用正式术语来说，不可变数据指针是永久对应于相同内容的字符串。

值得注意的是，任何可变指针（如常规 HTTP 链接）都可以通过将完整性哈希附加到 URI 来转换为不可变指针。这些类型的不可变指针将是短暂的，如果指针变得陈旧（即，源端在一段时间内一直用其他内容进行响应），它可能会从 DHT 中删除（缓存失效）。

Fleek Network 充当资源丰富的缓存层，缓解大多数 Web3 协议/中间件服务的数据检索性能有限。它考虑节点的地理分布以及特定区域中文件/数据的流行度。网络通过在附近节点之间复制缓存来确保高效的数据检索。

增量内容检索和验证

Blake3 的树结构允许有效利用可验证的内容流。虽然 Blake3 的作者已经实现了一个名为 Bao 的库，但 Fleek Network 的性能要求和定制需求促使我们开发了 Bao 的替代品，该库在本次开发中得到了广泛使用。

这种替换利用具有较大块大小的预先计算的数据树，并提供实用函数来有效地修剪这些树并在流式传输内容块时创建最小的子树。这种方法可以实现显着的性能优化，使得每个节点的增量验证成本几乎微不足道。

Fleek网络：协议

Fleek Network 是一个权益证明以太坊侧链，拥有自己的边缘节点网络，利用以太坊实现 FLK 代币 (ERC-20)、质押、支付、治理和协议的其他经济方面。节点运营商质押 FLK 代币（也可能通过 EigenLayer 质押 ETH）以便在网络上执行工作，开发人员、服务创建者和客户使用稳定币来支付使用网络上的资源和商品的费用。边缘节点向网络提供资源（带宽、CPU 等），这些资源被打包成商品，并在网络层面以美元定价。基于 Fleek Network 构建的服务消耗节点所需的任何底层资源/商品。客户端请求运行特定的服务，节点运行这些服务并执行工作来赚取费用（完整的经济细节超出了本文的范围）。 Fleek Network 利用 SNARK（简洁非交互式知识论证）、Narwhal 和 Bullshark 共识以及其他加密和经济激励和保证的组合来实现去信任、去中心化和长期可持续的环境。协议的核心尽可能简洁且不带偏见，以便任何给定的节点资源都可用于运行服务。本节详细阐述了如何实现这一点。

简洁链状态

在协议的核心，以下内容被保存在状态中：

代币余额（FLK代币和稳定币）
质押信息
节点信誉
有关节点在给定epoch内执行了多少工作的数据

对于去中心化系统，需要在网络中的所有节点上复制此状态。这是通过形成区块链并就转换此状态的交易达成共识来完成的。

Narwhal & Bullshark 共识

面临的最重要的问题之一是防止此过程（对交易进行排序和达成共识）成为性能边缘网络的瓶颈。在考虑了在节点之间有效分配交易以达成总顺序共识的复杂性的几个选项之后，得出的结论是，Meta 和 MystenLabs 对 Narwhal 所做的研究是一个独特且适合的解决方案。 Narwhal 是一个高效的基于 DAG 的内存池，Bullshark 允许网络在零网络开销的情况下就总排序达成共识。

网络中的每个节点不需要执行此排序，因此采用了基于委员会的方法。任何正确质押的节点都有资格加入共识委员会。在每个epoch（大约 24 小时）结束时，使用网络中已有的去中心化随机信标，由参与节点的子集组成一个新委员会。监督交易订购流程的委员会将其职责转移给新委员会。这种定期轮换减少了与受损委员会相关的风险，确保了共识机制的完整性。网络的其余部分专注于工作、批量交付确认并将其提交给委员会进行订购。

Delivery Acknowledgement SNARKs

Narwhal/Bullshark 订购的主要交易是一批交付确认。当节点正在服务请求时，它会收集传送确认，这些确认在提交后将在一个epoch结束时奖励该节点。

Delivery Acknowledgement是一个术语，用于描述客户端签名的消息，证明节点已成功将任务交付给客户端。这些确认会立即在本地完成，并且客户端无法恢复。

一旦节点收到包含有关其为客户端提供的资源信息的传递确认，它就可以将其添加到本地传递确认池中，并定期将这些消息发送到共识（以及每个其他节点）以收取费用。一旦收到确认，客户的预付费稳定币余额就会相应调整。在一个时期内从所有客户端扣除的金额将转移到支付池，根据节点在该时期执行的工作公平地分配给节点。

定期提交传送确认使我们能够利用递归 SNARK 证明来聚合许多传送确认，从而降低广播批次的网络成本，并显着降低单独验证所有传送确认所需的计算能力。基于性能的声誉 Fleek Network 实施了一个声誉系统，允许节点相互提供分数。这些分数随着时间的推移而收集，并且在每个时期结束时，运行聚合算法来计算网络中每个节点的总体分数（算法请参阅附录 A）。

基于绩效的声誉

Fleek Network 实施了一个信誉系统，允许节点互相提供分数。这些分数随着时间的推移而收集，并且在每个时期结束时，运行聚合算法来计算网络中每个节点的总体分数（算法请参阅附录 A）。

为了防止不诚实节点可能产生的影响，Fleek Network 借鉴了 EigenTrust 算法的见解，该算法对点对点系统中的声誉管理做出了开创性的贡献。

EigenTrust 算法的一个关键要素是传递信任的概念。节点将为与其有积极互动的节点分配更高的声誉分数。节点也更有可能信任其分配了高声誉分数的同级的意见。

在 EigenTrust 算法中，节点的全局信誉由其他对等点分配的本地信任值给出，并由这些对等点的全局信誉加权。

利用传递信任的概念，根据报告分数的节点的声誉为每个节点报告的分数分配权重。该网络还执行异常值删除，以进一步减轻虚假报告的影响。

使用节点的声誉来衡量报告的分数可以防止 Sybil 攻击，在 Sybil 攻击中，节点运营商创建许多额外的节点，其唯一目的是报告有利的分数。此外，高声誉只能随着时间的推移而建立。节点的信誉分数是在之前所有时期计算的分数的指数加权移动平均值。

信誉数据也可以通过节点之间在提供服务时的交互来获得。每个节点都会为每次服务交互分配一个评级。这些信息很有价值，可以在网络中复制，成为优化任务的可靠知识来源。一些示例包括优化网络流量和将服务分配给不同的节点。

Fleek Network: Services

Fleek Network 上的服务是边缘支持软件的模块化部分，在边缘节点上运行（并利用边缘节点的功能），为其最终用户提供独特的功能。这些服务可以被视为网络的用户界面。

第三方开发人员可以无需许可地将自己的支持边缘的去中心化 Web 服务部署到网络，该服务将在沙盒环境中运行（如 VM-Less Core 部分所述）。最初，核心服务将静态链接到节点二进制文件，但将来的计划是动态加载服务，并允许开发人员以任何系统级语言编写服务并在节点运行时部署。

从范围来看，服务只能访问通过 SDK 提供的资源。这些资源将包括文件存储、加密原语和指标报告 API 等。服务无法访问应用程序或进程的其他部分，也无法访问其他服务（因为它们将被隔离），并且它们也无法直接访问边缘节点的硬件或内核。鉴于系统的无需许可的性质，服务的代码将在各自的服务开发人员的存储库中进行管理（类似于智能合约）。

SDK

要创建 Fleek Network 服务，需要使用 SDK。 SDK 抽象了公开的核心协议功能，供服务构建者用来创建服务。它通过先进的进程间通信（IPC）系统促进与中间件的有效通信。一种解决方案可以构建在共享内存对象和环形缓冲区上，这是非常高性能的，但其他选项也是可行的。

本质上，任何系统级编程语言（如 Rust、C/C++ 或 Go）都可以用来与中间件建立这种通信通道。

SDK 为服务提供了多种功能，包括从中间件请求资源的能力。此外，它还为服务创建者提供各种加密承诺方案（例如不同商品的交付确认 SNARK 模板）。这些由节点生成的承诺被发送到客户端以证明工作完成（例如，提供的带宽、执行的计算等）。

这些加密原语的设计是为了:

确保客户端收到所请求的正确工作（内容、计算响应等）
防止恶意服务强迫节点做出虚假承诺。

与Service交互

Fleek Network 核心中的握手组件充当与节点进行外部通信的入口点，使客户端能够建立会话并与各种服务交互。握手组件通过安全传输层进行侦听，例如 TLS+TCP 或 QUIC，为与节点的所有通信提供加密。当节点收到来自客户端的新连接时，会交换公钥，并为会话协商通道。这个过程只需要几毫秒（与正常的 TLS 握手相同）。

一旦握手完成并建立了安全连接，客户端就可以自由地请求访问服务，该服务会意识到新会话并接管与客户端的后续交互。这涉及从客户端读取消息、执行必要的任务以及发回响应。当与服务的会话终止时，客户端可以自由地请求与另一个服务甚至同一服务的连接，同时保持现有连接处于活动状态。

节点分配&洗牌

服务创建者无需担心基础设施覆盖范围（地理分布、可扩展性等），也无需激励边缘节点运行其服务，因为网络代表所有服务抽象和处理该方面。每个时期网络都会使用各种图算法来分配每个地理区域的边缘节点来执行每个服务的工作。这些算法有助于确定网络中最有效的服务布局，以最大限度地提高资源利用率和整体网络性能，同时提供足够且可靠的信任、安全性、基础设施覆盖和性能保证。重要的是，当服务需求增加和规模扩大时，其他不再大量使用的服务会自动缩小规模。这种动态资源分配过程可以防止未使用的服务占用不必要的资源，并允许有效的垃圾收集。

资源&商品

服务作为沙盒进程在节点上本地运行。由于 Fleek Network 的核心占用空间较小，因此服务可以访问节点上的大部分硬件资源。服务执行所消耗的硬件资源被打包并作为商品进行计量。资源可以是但不限于带宽、CPU 和 GPU 及其各自的商品（GB/s、CPU 周期等）。交付确认包括节点在执行服务时消耗的商品。该信息用于根据网络对这些商品的当前定价来奖励节点。

服务示例：边缘计算

出于说明目的，边缘计算被用作一个类别来展示可以在 Fleek Network 上构建的不同类型的服务。边缘计算有多种形式，Fleek Network 几乎可以支持所有这些形式。例如：

简单 JavaScript 函数的廉价计算。构建/使用 Deno 或 Lambda 类型的服务，任何边缘节点都可以运行该函数并返回响应。
服务器端渲染。构建/使用基于容器引擎或无服务器服务（例如 JavaScript 函数）构建的 SSR 服务
基于共识的计算构建/使用一个服务，将请求发送到 N 个边缘节点，并就结果达成自己的共识（在许多情况下，这将实现类似的计算完整性，但比需要证明计算的成本要低得多）。
确定性计算。构建/使用确定性返回响应的服务，并删除撒谎的节点。
支持可根据要求指定的多个选项。构建/使用一项服务，其中 SDK 将根据所执行的工作向区块链报告统计数据，然后该数据将输入信誉引擎以改进服务路由。
零知识计算构建/使用任何 zkVM 作为服务，然后将某些 zkVM 计算卸载到边缘。
EVM 兼容计算构建/使用 EVM 作为服务，然后将某些 EVM 计算卸载到边缘。
网格计算。构建/使用一项服务，该服务可以在同一地理邻近的多个节点之间分解和并行计算。

与存储（内存+磁盘空间）和带宽是关键资源的 CDN 类型服务相比，这里 CPU 和内存的利用率更高，但存储和带宽仍然会根据 JavaScript 函数的逻辑进行收费被执行。对于此示例服务，网络还需要某种接口描述符语言，以便客户端可以组成 RPC 函数参数。此功能还需要管理 RPC 功能，以便客户端部署或销毁功能。

在Fleek Network建设: Who, What & Why

Fleek Network 应该帮助 Web3（协议、中间件、服务、应用程序等）与集中式解决方案一样高效，而无需复杂化（自己构建）或妥协（在堆栈中使用集中式基础设施）。即使对于更广泛的所有软件开发人员和服务（不仅仅是 web3）而言，Fleek Network 也应该成为一个可行的边缘平台，以高效地运行现代堆栈的不同部分，或优化其他地方的现有基础设施/服务/数据（例如其他 web3协议）。

Fleek Network 的成本和性能应与现有的集中式云/边缘平台保持一致，但具有额外的 Web3 优势（去中心化、无需许可、抗审查、可验证、加密/经济安全等）。

构建/使用服务的想法

Fleek Network 上可能构建多种边缘服务。以下是可以构建的传统 Web/边缘服务的一些示例，以及 web3（和所有 Web）开发人员如何使用这些服务，以及开发人员可以在 Fleek 上构建为服务的一些特定于 web3 的想法/用例网络。

网络/边缘服务

Hosting
CDN
Edge compute/Serverless
SSR/ISR (Incremental Static Regeneration)
Image Optimization
Load balancing
Grid computing
Naming Services
Databases (Document, KV, CRDT)
Container orchestration
Queues/Events
Step Functions
Analytics

Web 3 服务的特定用例

去中心化CDN

去中心化的 CDN 是 web3 基础设施堆栈中一个巨大的缺失部分。每个 web3 协议、中间件、服务和应用程序都需要和/或可以从内容加速中受益。虽然如今大多数项目在其堆栈前面使用 Cloudflare 来优化性能/延迟，但一旦 Fleek Network 启动，web3 项目就可以使用去中心化 CDN 服务作为直接替代品，在不牺牲性能或成本的情况下获得 web3 的优势。 CDN 服务根据使用情况在对基于地理的文件分发最有意义的节点（如传统 CDN）缓存内容。它跟踪所服务的请求并向客户端收费，并根据所服务的带宽奖励节点。信誉系统将跟踪良好的 CDN 服务，并据此确定路由。

去中心化网站/应用程序托管

虽然 web3 应用程序的后端更加分散，但前端仍然相当集中。 Fleek Network 提供了一个在这个问题/主题上向前迈出一大步的绝佳机会。例如，可以构建的服务是利用块存储和 IPFS 内容寻址来跟踪使用附加元数据部署的应用程序。它本质上是前端的存储层，类似于 S3 或 Netlify 等平台的工作方式。通过使用 CDN 和计算服务添加服务器端渲染功能，可以进一步扩展托管。托管或 SSR 的存储或处理可以分别向客户端收取所执行的工作费用，并将奖励分配给节点运营商。

去中心化 IPFS Pinning

鉴于 Fleek Network 的工作方式，网络上的所有文件/内容都是内容寻址的（给定 CID），并且 CID 到源的映射将永久存储。将其与允许直接访问去中心化存储协议（Filecoin、Arweave 等）的内置（外部供电）文件系统以及 CDN 服务相结合，可以构建提供完全相同服务的 IPFS 固定服务/体验当今集中式 IPFS 固定，但仅使用去中心化基础设施。不仅如此，这个版本的 IPFS 固定同样具有高性能、更便宜（在 web3 存储协议上存储通常比云平台更便宜），并且具有更好的数据安全性/可用性保证。即使文件从 IPFS 上脱落，Fleek Network 也能够检索它（只要它在至少 1 个源上仍然有效），因为网络永久存储 IPFS CID 到源的映射。

去中心化边缘计算（基于 Web3 协议）

计算即服务已在之前的“服务”部分中进行了更详细的讨论。大多数在以太坊或其他协议之上构建应用程序的项目都有额外的逻辑，例如帐户和团队管理/元数据或私有数据计算，或与第三方 API 的集成。目前，此逻辑在 AWS (lambda) 或 Google Cloud 等集中式平台上运行。在 Fleek Network 边缘计算服务上运行它们意味着这些流程的存储和执行是分散的、无需许可的和信任最小化的，不会牺牲性能，并且很可能节省成本（与使用集中式平台边缘计算相比）。

区块链快照即服务

为其他链同步完整节点是一个 CPU 密集型过程，可能需要数小时、数天或数周的时间，具体取决于链。 Fleek Network 的内部区块链使用内容可寻址性来存储链头的快照，并使用 CDN 将整个状态加速到节点以实现快速同步。可以构建一个服务来完成完全相同的事情，但适用于其他链。该服务可以自动存储快照，以始终保持最新状态，并将整个状态传递给请求它的节点，从而大大减少同步时间。

zkVM、EVM 和其他 VM 作为服务

部署 VM（例如许多 zkVM 之一或 EVM）的服务也是可能的。服务可以在 zkVM 中提供计算，并从证明响应正确性的节点提供 zkSnark。由于 zkVM 将在地理分布式、智能路由的边缘节点上运行，因此网络可以帮助确保 zkVM 计算在靠近客户端的地理位置进行，以进一步优化性能/延迟。

替代Rollup Sequencer

在 L2 时代，大多数使用集中排序器将交易发布到 L1 结算合约中。这些 L2 网络通过手动将交易发布到结算合约来提供围绕排序器的替代路线，从而应对这一层的集中化。问题是，用户在 L2 上习惯的块速度会降低，然后就会陷入 L1 的最终确定时间。在 Fleek Network 中，开发人员可以提供一项服务，为 L2s 排序器提供去中心化替代方案，将它们批量发送到 L1s 结算合约。这样就可以实现 L2 结算时间，同时仍然提供去中心化路径。该服务的另一个好处是它可以使最终用户不需要 L2 特定的 Gas 代币来提交这些交易。

临时Rollups

如果您想要 NFT 铸币事件或游戏/活动等短暂的汇总，您可以使用 Fleek Network 构建/利用一项服务，该服务允许您生成用户可以在一定时间内与之交互的临时汇总（例如薄荷窗口或游戏/事件持续时间），并且在该时间过去后，服务可以将结果汇总到您的智能合约中。这可以帮助用户避免天然气战争/高额费用，同时在活动期间提供即时最终结果。由于汇总将在分散的边缘上运行，因此它们具有抗故障性和高性能。

边缘证明生成

随着 SNARK/STARK 的兴起以及对高性能和成本效益证明生成的需求不断增长，以分散的方式在边缘（更接近最终用户）生成这些证明可能具有令人信服的优势。例如，假设的 Groth16 服务可以将设置参数读取为文件（使用文件系统），并根据用户指定的公共参数生成证明。对其他证明技术的支持可以作为单独的服务构建/使用。

验证随机性

Fleek 网络在整个过程中使用内部经过验证的随机性信标。通过服务公开这个信标对于许多 web3 应用程序来说可能很有价值。执行此操作的服务还可以支持将经过验证的随机性发布到其他区块链，以实现以前不可能实现的链上随机性。

Web3 查询/事件

可以轻松构建服务，为 Fleek Network 之外的其他区块链提供实用程序。例如，可以构建一个服务来索引从另一个链发出的事件并允许请求查询该数据。该服务同样可以为这些其他链提供一个通用接口来提供查询或提交交易。更进一步，服务可以通过根据先前请求是否成功提交一些多链请求来提供跨链的原子性级别（即桥接服务）。