AMA Fleek Network

Fleek Network is a decentralized content delivery network (CDN) that allow users to serve content and applications in a censorship-resistant and trustless manner. The Fleek Network is peer-to-peer (P2P), origin agnostic, and offers a low-cost service with blockchain and consensus algorithms. All content will be IPLD-based (InterPlanetary Linked Data) and content addressable, creating a public record of the world’s bandwidth and the content served, similar to how smart contracts bring transparency to financial transactions.

Harrison Hines, CEO, and Co-founder of Fleek Network, joined us for an AMA on December 19th.

vVv: Before we jump into the project, can you give our listeners a short introduction about yourself and how you got involved in Web3?

Harrison: Before entering the space in 2016, I worked with equity crowdfunding under the JOBS Act; I always thought crowdfunding was cool.

After observing the success of initial coin offerings (ICOs) and crowdfunding on Ethereum, they started a company called Token Foundry to bring best practices and standards from the crowdfunding space to the ICO space. Token Foundry conducted token sales for consensus and other projects in the space from 2017 to 2018. As ICOs were dying down in late 2018, I became more interested in the decentralized web narrative, specifically decentralizing web infrastructure, instead of decentralizing financial infrastructure. That’s when I left with some of Token Foundry’s founding team members to start Fleek Network and focus on helping to decentralize generic web infrastructure.

vVv: Fleek has been involved in Web2 space for a while now, why are you shifting focus to Web3?

Harrison: We’ve always focused on Web3 applications. Our first product was IPFS hosting, so we were always skewed towards the Web3 application side. However, Fleek and the legacy Fleek platform are very much a Web2.5 platform. It was built while we were running IPFS nodes on AWS and accelerating content via a Cloudflare CDN (content delivery network). We had always wanted to move to the more Web3 end of the spectrum, but we didn’t feel it was the right time or that we had the right approach within the last three years.

After seeing projects like The Graph successfully launching their decentralized indexing protocol and Pocket Network decentralizing the RPC side of the stack with performance that was as good or better, we were in an excellent position to tackle the Web3 infrastructure stack. In addition, there were many breakthroughs in scalability and modularity like rollups, which gave us more confidence. Additionally, we noticed that many protocols for storing files or data, such as IPFS, Filecoin, Arweave, and ICP, do not adequately address performance in their economic models, resulting in the need for a performance middleware or caching layer to provide a good user experience. Fleek aims to address this issue by focusing on the performance delivery aspect of Web3 infrastructure.

We saw great centralization in the industry, especially NFT projects, using Cloudflare, IPFS, or Arweave. Everyone is accelerating their content using Cloudflare because there are no other viable options other than direct queries from protocols, which is not performant and results in terrible UX. Thus, there currently needs to be a legitimate decentralized alternative for content delivery. 

vVv: Before diving into the Fleek Network’s architecture, we should take a step back and look at the content delivery network. Can you provide a brief summary of what a CDN is, and why it is essential in Web3?

Harrison: CDN stands for Content Delivery Network, and it was created to improve filing storing by caching the memory and storing it in multiple locations similar to nodes at different geographic locations. Every request can be filled by a node or the point of presence (PoP) as used in Web2. CDNs have extremely low latency, are computationally cheap, utilize cached memory, and are much more performant. Also, a large network allows proximity to the end user and decreases lapsed time in fulfilling requests. The proof of concept (POC) accelerated tremendously, CDN implementation and they now carry a considerable amount of the web traffic, especially video traffic. CDNs have been super useful for apps with large user bases and copious content such as video games, social platforms, streaming platforms, highly trafficked blogs and news sites consume a ton of bandwidth to ensure the videos and sites load quickly. Also, from a cost perspective, CDNs significantly reduce high bandwidth consumption costs. That’s how content delivery networks started. 

The trend is now moving to the edge because it’s way more performant. From a security standpoint, it’s much more cost-effective because there is not a single central point of failure. Fleek Network is essentially a decentralized edge network, but we are starting with content delivery because that is our bread and butter, and that is where the most significant need is in Web3.

Currently, there needs to be infrastructure in the Web3 stack specifically designed for performance delivery. This issue affects not only file storage protocols like IPFS, Filecoin, Arweave, and ICP but also smart contract platforms that rely on services like Alchemy Systems or Infura, which use CloudFlare to accelerate requests. When data availability protocols launch, they will likely face similar challenges in serving data in a performant manner. Every protocol will need some kind of acceleration layer to meet end users’ expectations in terms of latency, load times, and overall user experience. This is especially important for web and other apps that are used today.

vVv: How will you prevent harmful content without censorship? In decentralized systems, censorship is almost unstoppable, correct?

Harrison: To address censorship and malicious content issues, Fleek plans to adopt a similar approach to other decentralized storage networks by obscuring the content being served by nodes so that they do not know what they are serving. This also helps to prevent malicious versions of content from being served, such as injecting a phishing version of the uni-swap front end. Like IPFS, Fleek will handle potential issues with malicious or phishing content at the gateway layer. The network will be fully censorship-resistant, and anyone can run a gateway and allow others to fetch content from the network through these gateways.

Like IPFS, Fleek Network will have gateways that a variety of parties will operate. These gateways will handle potential issues with content policies and local laws and regulations. If a user’s preferred gateway decides not to serve specific content, they can switch to an alternative gateway that may have its own content policy or follow different rules. In the future, it is possible that decentralized gateways controlled by a DAO or similar entity could be run on networks like Akash Network. Fleek Network’s approach will be to keep the network as pure and censorship-resistant as possible while handling content policy and related issues at the layers above the network.

vVv: Can you give us an overview of the overall architecture and the different components in the Fleek Network system?

Harrison: In the Fleek Network, the main actors are Cache nodes and Gateway nodes, with some additional smaller roles. Gateway nodes function as air traffic controllers for the network, routing incoming requests and serving as the primary point of contact for users. Gateway nodes can be located in a variety of locations to allow for efficient routing of content. To determine the most performant route for serving content, gateway nodes keep track of cache nodes in their region, which is determined based on ping times to different gateway nodes. Cache nodes store and serve content, and gateway nodes are aware of all cache nodes and the content they have cached. In comparison to IPFS, our network can be slow if a node does not have a requested file. In this scenario, it will ask its peers until the file is found. This can lead to long wait times if the network is not properly peered, however over-peering can also cause performance issues due to unnecessary bandwidth usage.

In the Fleek Network, the goal is to avoid the issue of slow content retrieval by routing requests directly to the appropriate cache nodes. When a request is received, the gateway node routes it to one or several of the closest cache nodes to the user, which then serves the user’s content. Both the gateway and cache nodes receive payment for each request, and the DAO determines the distribution of these payments. The gateway node will likely receive a lower percentage of the payment than the cache node, as the gateway node is involved in more transactions. 

Cache nodes in the Fleek Network are differentiated from other storage network nodes because they do not permanently store anything, only caching data in memory. This allows for faster serving and retrieval of content and cost savings. Similar to a content delivery network (CDN), users can provide URLs to Fleek Network, which point to the location of the content (such as on AWS s3, IPFS, Filecoin, or Arweave). Fleek Network is agnostic to the origin of the content and does not need to guarantee its persistence. If a file is no longer requested, it will eventually be removed from the network, but if it is requested again, the cache node will retrieve it from the origin location and add it to the network. One advantage of the Fleek Network over traditional CDNs is the ability to accelerate content using a direct integration with Web3 protocols like Filecoin or Arweave, rather than relying on HTTP and DNS, which can be vulnerable to censorship. This allows for greater censorship resistance as there is no reliance on traditional web protocols to retrieve the content.

vVv: Do you have any plans to launch your own name service ?

Harrison: No, we do not. Everything is IPLD addressed in the Fleek Network so its content addressed. In our opinion, IPFS is the most powerful naming system in Web3. One of the benefits of IPFS is hash mapping to a unique piece of content. Similarly, we’re leveraging that part of the content addressability for Fleek Network. Could we integrate with things like ENS? Hypothetically, could you provide an ENS URL, subdomain, or file path and have Fleek natively resolve and accelerate it? Yes, that would be possible and is pretty straightforward. We have a lot of experience with such things with our ENS features on the Fleek Platform. 

vVv: Are your different nodes fully permissionless on each level, or are there limitations? 

Harrison: Cache nodes are fully permissionless, but Gateway node permissioning will require approval by the DAO proposal process. This is because we are taking a progressive path to decentralization and because gateway nodes have certain responsibilities, such as reporting the activity of cache nodes to the network and running DNS infrastructure, that require more time to be implemented in a fully decentralized manner. While becoming a gateway node requires permission from the DAO and token holders, indicating that the operator is legitimate, cache nodes do not have this requirement.

vVv: Is there an update on the current status of Fleek Network’s development, the progress made, and a future roadmap release?

Harrison: An official roadmap will be publicly released in the next few weeks. The network is live, but there’s a lot of work ahead. We’ll do a testnet or devnet in January. It will likely be without the token and consensus or communication to the L2 for the reward and payouts. A testnet will follow this in March, then an incentivized testnet in April or May, and then mainnet release in June.

The focus of Fleek Network’s v1 release will be content acceleration, with additional features and edge services under consideration for future implementation. These could include edge handlers or serverless functions for front-end focused tasks. Fleek Network does not plan to compete with more compute-intensive protocols and smart contract platforms, but may consider adding modules related to front-end compute tasks such as server-side rendering. The content delivery capabilities of Fleek Network will be available on the mainnet with the v1 release.

vVv: How difficult is it to provide dynamic content regarding smart contract information and interactions, and are there special considerations?

Harrison: V1 of Fleek Network will be more focused on static content, as delivering dynamic content requires additional work. However, it is feasible to accelerate all sorts of content using a CDN, including APIs and RPC requests for smart contract platforms. This is a well-adopted practice, with companies like Alchemy Systems and Infura using cache layers like Cloudflare to improve performance and reduce costs. Unless it’s a GET call, for the last block or two, most requests are served from a database. Protocols like Livepeer have expressed interest in using Fleek Network to accelerate their content instead of relying on Cloudflare. While Fleek Network’s initial focus will be on static content, it is possible that in the future, as more features are added, it could be used for a wider range of dynamic content and data structures. The use of CDNs for content acceleration is a proven concept, and while it may require additional work to ensure good performance, it is a viable option.

vVv:  Will you launch your own blockchain for this use case, or would you build on top of an existing Layer1?

Harrison: Similar to Livepeer and The Graph, we are considering deploying a token on Ethereum, but the DAO and reward payouts will be handled on a Layer 2. The team is still evaluating Layer 2 protocols and have been in discussions with a few. The inclusion of BLS signature verification in an upcoming Ethereum upgrade may influence the team’s decision.

Fleek Network is not a traditional rollup, but it does incorporate some of the same design principles. It has its own consensus mechanism for nodes within the network to agree on the data served, but the data is rolled up by a Layer 2. Rewards, governance, and the token are also all handled on the Layer 2, while Fleek Network focuses on the content and functioning of the edge network itself.

vVv: What is your opinion on next-generation monolithic chains like Aptos or Sui, and could they be an option for Fleek Network?

Harrison: We did not need them for Fleek governance, so it does not make sense to consider anything besides an EVM. Like other protocols, Chainlink and The Graph, we’ll deploy payment contracts on various smart contract platforms. The team is exploring Layer0 protocols such as Axelar, which allows for omnichain tokens and the acceptance of payments and easy usage from users or contracts on any chain. In the meantime, Fleek Network plans to deploy contracts on all EVM chains and will consider adding support for other chains as it progresses. The team believes that monolithic chains will not be able to compete with the scalability and specialization offered by rollups.

vVv: Can you elaborate on your token utility concerning governance and your DAO?

Harrison: There will only be one token, but we are looking into other avenues for node profitability and accounting perspectives.

 The main use case for our token is staking to become a Cache node or Gateway node operator. By staking the token, you can earn rewards for each successful request served. Cache nodes that provide the fastest content delivery will be paid the most for their services. Consumers of bandwidth, such as dApps using the CDN, can also prepurchase a certain amount of bandwidth, and then replenish it as needed. The token is used to facilitate these transactions and to incentivize high performance and low latency on the network.

We are considering the use of a soul-bound token or an NFT for governance in Fleek Network, but these are still in the early stages of development. We are working with our lawyers to ensure that our approach is safe and compliant with regulations, given the current uncertainty in the market. Ultimately, our goal is to find a solution that allows us to effectively govern the network while protecting it from potential risks effectively.

vVv: You announced that InterPlanetary Name System (IPNS) will soon become a service. Can you explain what IPNS is and when the beta is?

Harrison: Fleek Network is the underlying infrastructure for the Fleek Platform, a Web3 development platform that provides services to the network and other protocols. The new Fleek Platform, set to launch in early 2023, is currently rolling out betas for some of its features and services, including IPNS (Interplanetary Naming Service). IPNS allows users to connect any ENS name to their site by setting a content record pointing to its location. Instead of using an IPFS hash, which can change with each deployment or update, IPNS allows for a mutable hash or key that can be updated to always point to the most current version of the site’s IPFS hash. This eliminates the need for on-chain updates and the associated costs. Many projects need to use IPFS but need to be able to change the content pointed to. IPNS is a solution that allows for this by providing a mutable hash that can update to point to new IPFS hashes over time. The Fleek platform offers a standalone IPNS service that can be used by various projects in different circumstances and use cases. The new Fleek platform is designed to be very flexible, with each feature available as a standalone service that can be accessed and used in any way desired. The current Fleek platform is more rigid, with the IPNS service only available as part of hosting and ENS name setup.

vVv: What measures do you have in place to limit DDoS Attacks, especially at the Gateway node level?

Harrison: We’re doing a number of things that we touch upon in our white paper touches. Some unique measures due to our economic model are things like token leveraging or staking. We will borrow many measures from traditional CDNs, like bloom filters. We can also implement rules at the protocol level to protect against DDoS attacks. These rules can be established for all Gateway nodes to follow and can be configured to throttle certain IPs or apply to specific applications or URLs. The new Gateway node will have built-in logic to handle these rules and provide DDoS protection for the network.  We also have measures in place to protect against phishing attacks. One such measure is a slashing mechanism that can be applied to nodes that lie about the content they are caching or serving, as well as to accounts that are found to be involved in phishing activities. This slashing mechanism allows us to reduce the prepaid bandwidth of accounts that engage in phishing to deter such activities on the network.

vVv: Do you perceive any privacy risks like IP address leaking, especially at the Cache node level?

Harrison: Not at that level because that will be obfuscated.

vVv: How are fees calculated in the system, and which metrics are they based on?

Harrison: Initially, fees on Fleek Network will be based on the amount of bandwidth used, and the network’s DAO will set the price. The DAO will monitor the network and determine what fees make sense. Fleek Network is expected to be 3-5x cheaper than traditional cloud providers like Cloudflare or AWS, as decentralized networks like Fleek, Akash, and Filecoin do not incur the same high human labor costs to set up and manage infrastructure. Because of the high human cost, traditional cloud providers do not exceed 200-300 PoP locations, with edge networks like Netlify or Apply.io never exceeding 20 to 30 locations.

We are also exploring ways to add other modules and services that may require compute capabilities. By combining Fleek Network with underlying storage networks like Filecoin or Arweave, we can eliminate the need for centralized IPFS pinning. Currently, IPFS is not intended to be used as a storage layer, but Fleek Network can help link an IPFS hash to the underlying storage layer where a file is stored. This allows for gateways to be built on top of IPFS and for content to be fetched from the cache layer or origin as needed. In the future, we may offer additional options for users to pay for longer TTLs or greater persistence, although we would never guarantee complete persistence

vVv: Do you plan to offer developer grants for early adopters?

Harrison: That’ll definitely be a big focus of the foundation when it launches in early 2023. We will lean heavily on grants and partnerships depending on token distribution restrictions. People are already building on these existing storage platforms or building Web3 use cases. Whether it’s NFT, DeFi, or GameFi, they all require hosting and performance delivery. We’re origin agnostic and smart contract platform agnostic, a product and service that almost every Web2 and Web3 project needs and uses. There will be ample opportunity to not only be a consumer or replace Cloudflare with Fleek Network but definitely a big grant focus for devs who want to build cool things on top of, or integrate things for, Fleek Network.

Listen to the Spotify recording below for the full Fleek AMA.