Announcements
Author:

Fleek Network Testnet Phase {1}: Preview

The Fleek Foundation is excited to release the official details for the upcoming Fleek Network Testnet Phase {1}, which aims to demonstrate the real-world performance of the network for the first time. 

After the successful initial proof of concept and correctness found in Phase {0}, this next Phase {1} seeks to showcase a more realistic environment that favors accurate data and the true capabilities and effectiveness of the decentralized edge network – meaning the results will be reflective of the raw performance of the network itself, and not skewed or assisted by any third-party infrastructure or middleware.

Similar to Phase {0}, Testnet Phase {1} is expected to run for about one (1) week, from the official start on Thursday October 19th at 2pm EST until around October 26th. Below is a high level schedule:

Phase {1} Schedule:

Thursday October 19th

  • Testnet Phase {1} starts, 2pm EST
  • Node Office Hours available, 2-4pm EST in Discord

Thursday October 26th

  • Node Operator Open Call, 2pm EST in Discord
  • Tentative Phase {1} shutdown

Tuesday October 31st

  • Publish initial Phase {1} data and results
  • Share next steps

Phase {1}: Important Considerations

The Fleek Network team takes user feedback seriously to help decision-making throughout the development cycle of the protocol. Thus, empirical evidence supports the needs through the different test phases in the Road to Mainnet. Cyclically, the team has to spend more time than anticipated to ensure the resolution and revision of any feedback encountered before any additional progress.

The feedback gathered from the Phase {0} Node operator's experience and the tests conducted by the core team led to identifying areas for further research, development, and improvement before committing to any additional features.

One significant requirement was in the consensus mechanism. Operating as expected, messaging from consensus to non-committee nodes could have been more efficient. Thus, the network Broadcaster and Synchronizer have enhancements to improve the messaging flow. Also the Fleek Network broadcasting protocol, which gets messages from the consensus pool to edge nodes, and the synchronizing procedure for node coordination with desynchronized peers, were enhanced to facilitate smoother communication between peers to mitigate the experience in Phase {0}.

Furthermore, the core development team had to address 60+ reports attentively from the Community and Node operations. Amongst others:

  • Synchronizer committee selection randomness
  • Broadcaster persistent cache
  • Consensus disaster recovery
  • Indexer and resolver slashing handling
  • Blockstore garbage collection
  • Topology enhancements
  • Canonical DB for checkpointing
  • Fetcher download request queue
  • Onboarding experience

The complete list of fixes and improvements is available here and in the repository here.

Phase {1}: Goals

The primary goal of Testnet Phase {1} is to demonstrate the performance of the edge network for the first time, and test the very first edge services deployed to the network as a proof-of-concept. After proving correctness in Phase {0}, it's crucial to demonstrate the network capabilities to meet or exceed typical cloud services performance in a decentralized environment.

As discussed in the early Phase {1} briefing, the goals fit into three groups:

  • Node
    • Optimize node operation
    • Service throughput, quality and reliability
    • Node request distribution tracking
    • Collection of node operation costs
  • Protocol
    • Reputation, slashing and reward mechanism evaluation
    • Broadcaster and Sequencer refinements testing
    • Connection pool peer-to-peer networking toolkit
    • Blake3 Client-side libraries
    • Revamp the command line interface experience
  • Service
    • Service testing and optimization
    • Service performance evaluation
    • Service and resource cost-competitiveness assessment

The Fleek Network core team will gather valuable information with the Node, Protocol and Service experience feedback described above to make further enhancements to the next Phase {2}.

Phase {1}: Performance Assessment

Fleek Network Testnet Phase {1} represents a crucial milestone in the Fleek Network's Road to Mainnet. We'll test diverse scenarios while showcasing some edge services running on the network as proof-of-concept. On top of it, we'll track key metrics across different geographies –which will be influenced by the node distribution of those node operators participating in the Phase {1} testnet –for each of the services being tested. Geographic distribution of nodes is ignored for this Phase {1} on purpose, as ideally free market economics would take care of this in a mainnet setting (especially given all work is allocated based on latency/location and reputation), however if geographic coverage ever becomes something worth addressing directly, ideas similar to Gnosis’ Geographic Diversity Program might be explored.

The key metrics being tracked have response times that are broken down into the following metrics:

  • Time to First Byte (TTFB)
  • Time to Full Load (TTFL)
  • Service specific metrics

The above metrics will be collected in varying scenarios:

  • Number of Nodes
  • Node and Request distribution (geographic locations)
  • Number of requests (stress testing)
  • Node Reputation system
  • Node Slashing conditions (misbehavior)

In which the initial proof-of-concept services being showcased will be:

  • Content Retrieval (IPFS)
  • Video Streamer

For Testnet Phase {1}, we'll stress-test the system with as many nodes as possible to simulate a real-world environment, as expressed in the team's empirical development approach, for optimization and refinement of the protocol. This approach will help measure how well it scores different nodes, unlike a controlled whitelisting network that would showcase better overall performance but limit the evaluation from an empirical viewpoint. Therefore, if a node has the minimum recommended specifications to operate successfully, it can participate in the Testnet Phase {1}.

Content Retrieval (IPFS)

With Content Retrieval, we have a simple use case where clients can specify an IPFS origin for the content they want to accelerate in the network. In contrast, given the high demand for video on the internet today, video streaming is an excellent way to showcase the system's capabilities.

Video Streamer

Typical video streaming services use a client-server approach, where the client receives content directly from a designated server behind a content delivery network to accelerate delivery and avoid stressing the origin server, which can lead to bottlenecks in the system when client demand spikes. The origin server is generally a centralized location and a single point of failure, an independent service from the content delivery provider, with its own costs and terms of usage. In contrast, decentralized video streaming works on a distributed network. For instance, to access video streaming on Fleek Network, a client application accesses nodes that have the video streaming service (the services are statically linked currently but, in the future, should be dynamically loaded by service demand and node setup preference). The nodes act as infrastructure for the peer-to-peer network, which compute, store and broadcast the data per client request. After the Delivery Acknowledgement (SNARK) is generated, the node service is evaluated and rewards are given per epoch based on the rating and other factors. Since the node account owners have staked tokens on the platform, this discourages malicious actors from misbehaving, as it would harm their reputation and result in the slashing of their tokens. Therefore, showcasing a proof-of-concept for video streaming is a great way to exhibit the network's service capabilities and client flow.

Testnet Phase {1}: FAQ

What should I do as a Node Operator interested in participating in Phase {1}?

Once Testnet Phase {1} officially launches, every Node Operator should install or update the binary to the latest version of Lightning CLI provided by the core team. You’ll also need to stake, by visiting the faucet website provided (URL will be provided before the official Phase 1 start), and you'll also need MetaMask as a browser extension to complete the minting/staking flow provided on the faucet website.

The Fleek team cares about user experience and provides documentation and tools (whichever's your preference) to onboard easily and quickly. However, the Node operator's server should have the minimum requirements to set up and run a Fleek Network node.

Everyone's free to join the Testnet Phase {1}, regardless of whether they have participated in any prior testnet phase or filled any forms.

What will the Node Operator onboarding flow look like in Phase {1}?

The Node Operator onboarding flow should be straightforward for most users, and it should be similar to the following steps:

  1. Install the Fleek Network Lightning CLI latest version

  2. Visit the Fleek Network Testnet Phase {1} faucet website

  3. Set the custom network in MetaMask (custom network RPC URL will be provided before official Phase 1 start)

  4. Use the Faucet mint button to get FLK

  5. Use the Faucet to stake FLK for your node

  6. Run node

The Lightning CLI Phase {1} version, faucet website, and custom network RPC, will be made available prior to the official start of Testnet Phase {1}.

Are there any incentives for Phase {1}?

Refer to this blog for further information regarding testnet participation initiatives. In short, for now, there are no direct incentives during any of the specific testnet phases. Still, there are several overall initiatives (outlined in the Testnet Participation section of the blog linked above).

Will Phase {1} be a permanent testnet or shut down after a certain time (if so, how long)?

Phase {1} will not be a permanent testnet. The initial plan is to run this phase for one (1) week, but depending on how things go this timeline might be extended. If it is extended, it will be communicated ahead of time.

As a developer interested in testing services, what should I do?

There will be a simple UI where developers will be able to test the initial services included in Phase {1}, but for developers interested in building services (not just using them) expect things to escalate in the next Testnet Phase {2}, when the Service Development Kit will be released.

Still have questions? Feel free to reach out in Discord.