Overview
A Fleek Network Service is a modular application that runs on nodes and allows users to perform well-defined functions or some specific tasks. Services are scalable and performant due to edge computation and networking features provided by the core principles of the network.
As a permissionless system, services are built by developers who are free to build and deploy them to run on the decentralized edge platform. Applications can be of any kind but are generally described as web services. These are cryptographically secure and run within a fair economically incentivized model. The services are hosted in user-managed resources and are highly available to customers and end-users in exchange for rewards.
A Service Development Toolkit (SDK) facilitates access to core APIs and resources for developers. Services run in a sandboxed environment (unable to access the host's processes, hardware and kernel directly) and are restricted to specific features such as cryptography, networking and storage. The service implementation source code is fully managed by the author(s), owner(s) and development team(s).
At an early stage, core services are statically linked to the node's binary process (Lightning). In the future, the Fleek Network protocol aims to load services dynamically.
Service Development Toolkit (SDK)
The Service Development Toolkit (SDK) abstracts the core protocol features, including the communication with the middleware which is done through an Inter-Process Communication (IPC) system. Any system-level programming language, such as C/C++, Go or Rust can establish a communication channel with the middleware. By using the toolkit, a Service builder accelerates the development process e.g. effectively enables nodes to generate Delivery Acknowledgements (SNARKs) that prove work completion which is used to determine rewards, along with other cryptographic commitments.
As discussed in The Network section, Delivery Acknowledgements include metadata about the commodities consumed by a node while executing or running a service. It also contains cryptographically secured metadata that are tamper-proof and used to determine the reward attributed to a node.
A commitment ensures clients receive the correct work output that is being requested, such as content, a computed response, etc. In addition to preventing malicious services from coercing a node into making false commitments. Likewise, the commitments generated by a node determine the bandwidth and computation served, amongst other commodities.
Handshake
The Handshake component is the entry point to external communications with a node. It enables clients to establish an encrypted communication session with the node and interact with services over a secure transport layer (TLS+TCP or QUIC). On establishing a client and node connection, public keys are exchanged and a lane is negotiated for the session. A Handshake is required for a client to access and interact with a service.
Service geographic distribution
The network takes care of infrastructure coverage, scalability, and incentivizing edge nodes to run services. It employs a range of algorithms to assign edge nodes in each geographic region to handle the work for each service, guaranteeing the most efficient route. Additionally, when a service experiences a surge in demand and scales up, any unused services are automatically downscaled. By dynamically allocating resources, it eliminates unnecessary resource usage and allows efficient garbage collection. All of this is achieved while maintaining optimal levels of trust, security, infrastructure coverage, and performance guarantees.
Resources as commodities
The hardware resources used by a service are packaged and measured as commodities. Includes things like bandwidth and CPU, along with their respective commodities such as GB(s) and CPU cycles. Delivery Acknowledgements detail the commodities used by a node during service execution. The data is used to reward the node based on the current pricing of those commodities set by the network governance.
Use-cases
Building on Fleek Network's Decentralized Edge Infrastructure unlocks various opportunities and advantages for Service builders, that empower them to implement most of the following concepts.
Traditional Services
Edge Functions
Edge computing comes in many flavors, and Fleek Network can support many serverless or edge computing functions. For example, low-cost computation for JavaScript functions, Lambda, runtimes or Cloudflare Workers-like computing. Can also perform deterministic computation, consensus-based computation, ZK-computation, and EVM computation. The network is non-opinionated and enables developers to refine their computing service in great detail.
SSR/ISR
One applied edge compute use-case that can be built is Server-side Rendering (SSR) or Incremental Static Regeneration Service (ISR) on top of a container/serverless engine. Given the granularity of content verification within the core's hashing, streaming of particular pieces of data can be optimized and parallelized across multiple nodes. Such as chunking pages of static sites and regenerating only where needed.
Hosting
Web3 apps are generally composed of a backend and a frontend stack. The backends are considerably decentralized but often have the client-side facing interface hosted into a central cloud provider. Given the desirability of content delivery acceleration services for a snappy user experience, that end customers demand. The Fleek Network takes a big step forward on this topic, as services can leverage the block store and content addressability (IPFS) for an application host provider.
As we have today with user stories like S3 or Netlify, a service can use Fleek Network as a storage layer for static sites. Similarly, a CDN or SSR can complement static site hosting by accelerating and dynamically computing user needs. In consequence, the reward mechanism would distribute rewards fairly to every actor in the computation and fulfillment of paying customers for these requests, e.g. service builder, node operator, etc.
CDN
A decentralized CDN is a big missing piece in the Web3 infra stack. Every protocol, middleware, service, and app can benefit from content acceleration. Today most projects use popular CDNs in front of their stacks for optimization and performance improvement e.g. availability and latency. A decentralized CDN built on Fleek Network can gain great notoriety in the blockchain and Web3 development communities, due to its benefits and principles, without sacrificing performance and cost of integration.
The dCDN service can cache content based on the user request and popularity, and put it in the speediest location based on the network reputation system, computation and routing response timings. Conceptually similar to a traditional CDN, but abstracting the geo-location that is usually specified by user-selected zones.
While the network does not possess a specific concept of geography, it gains an implicit understanding of geographical proximity through the data it collects on latency and hop counts between nodes, which is a part of the reputation system.
Learn more about how Fleek Network behaves by reading the whitepaper.
Container Orchestration
A decentralized orchestration service built on a content-addressable edge network can bring benefits in performance and delivery. A service could utilize the native content-addressing and Blake3 hashing and verified data streaming to partition large container image files and serve them at scale in a multi-region environment.
Fleek Network can act as a p2p CDN, serving container chunks in a parallelized, verified, and performant way–without sacrificing decentralization. Similar to concepts that can be found in Docker image hosting, Docker Swarm clustering, etc.
CRDT Databases
Database services in a decentralized edge platform with a content addressable core can benefit from the network's data deduplication and integrity characteristics.
Particularly a CRDT database service could be built to converge data from multiple edge locations replicas. Given all data is content-addressed, unique content hashes allow for easy differentiation and verification as the data is replicated.
Web3 Services
Blockchain Snapshots
Interchain synchronization of a full-node history is CPU-intensive. Can take hours, days or weeks depending on blockchain technology. On Fleek Network's core, the internal blockchain is based on content addressability which stores snapshots of the state HEAD. It utilizes decentralized content acceleration for node entire-state synchronization for higher speed.
A service can be built that does a similar process for any chain. By automating snapshot storage timely and in-synchronization to the chain HEAD. It can deliver an entire state to a node rapidly.
Decentralized IPFS Pinning
All content on the Fleek Network is content addressed and referred to by the CID, which mapping of the CID to the origin is stored in perpetuity. Coupled with the built-in file system interlinked to decentralized storage protocols such as Arweave and Filecoin, an IPFS pinning service can be built. A pinning service for IPFS that provides the user experience we are accustomed to, but using decentralized infrastructure, which today's IPFS pinning services fail to offer.
Worth mentioning that an IPFS pinning service as such, would be cheaper and provide better availability, performance and security guarantees. For example, as the network stores the CID-to-origin mapping in perpetuity, even if an IPFS file is lost it can be easily retrieved if there's at least one origin.
VM's (EVM, zkVM's, etc.)
A service that deploys a virtual machine, such as many zk-VMs, or the EVM can be built and deployed to Fleek Network. It can provide compute in the zk-VM and provide the zk-SNARK from the node, proving the correctness of the response. In addition, the network routing can ensure that the zk-VM computation is happening in the closest proximity to the client based on latency and other network factors.
Ephemeral Rollups
The Fleek Network can be utilized as a short-term service platform for a variety of applications or side-chaining that compute state and roll it up to a smart contract. An NFT minting or game event that occurs during a short period, can roll up state to a smart contract after the event time elapses.
To help users mitigate gas costs and feeds while providing instant finality throughout an event. Consequently, roll-ups would run on a decentralized network, that is fault-resistant and highly performant.
Proof Generation
As a result of the rise of Zero-Knowledge proofs (SNARKs, STARKs) for performance and cost-efficient proof generation, there are benefits for computing them closer to end-users and in a decentralized manner which Fleek Network Edge Network entails.
For example, a hypothetical Groth16 service can read parameters from configuration files in a file system and generate a proof based on public user custom parameters.
Alternative Sequencers
As encountered by most sequencers that post transactions to Layer-1 settlement contracts (which are mostly done over centralized processes), Layer-2 networks bypass these by posting them manually. This causes long finalization times and a reduction in block speeds on Layer-1, which is contrary to what users are familiar with and find ordinary on Layer-2.
In Fleek Network, a service builder can offer an alternative to a Layer-2 sequencer, that is decentralized and more reliable by batching and posting to Layer-1 settlement contracts. With equivalent Layer-2 settlement times.
An additional benefit can be enabling end-user gasless transaction submissions by disregarding a Layer-2 gas token to submit transactions to Layer-1.
