Announcements
Author:

Fleek Network Testnet Phase {1}: Preview

Following the successful completion of Fleek Network Testnet Phase {0}, the core development team has been actively implementing the next set of core protocol functionalities which include services, the rewards system, the broadcaster/synchronizer, as well as all identified improvements and fixes found during that phase.

With that, the road to Phase {1} begins, scheduled to begin the first or second week of October. Alongside a smoother overall experience, Phase {1} comes with a shift in focus, from the initial proof of concept and correctness of Phase {0} to a new milestone: proving performance.

Not every detail regarding  Phase {1} is decided as of now, but it is important to start sharing some early info so that all interested node operators can be prepared and can start submitting node applications when they open on Wednesday, September 20th at 12pm EST  (applications will open on Discord). Expect to see more info released in the leadup to the official start of Phase {1}.

TLDR:

  • The official start of Phase {1} will be the first or second week of October; the exact start date to be announced in the next week or two.
  • Primary objective of Phase {1} is to prove performance and test the first few proof-of-concept edge services deployed to the network.
  • Node Operators interested in participating will be able to apply on Discord as of Wednesday 20th at 12pm EST.
  • More details will be published throughout the lead-up to the start of Phase {1}

Let’s get into some details:

Phase {1}: High-Level Overview.

As mentioned, Phase {1} will primarily be about proving performance. After proving correctness in Phase {0}, the next most critical thing to prove is that Fleek Network can meet (or exceed) traditional CDN/edge-level performance in a decentralized setting.

To get a true feel for real-world performance, this phase will test the network under various scenarios, and track the following key metrics across different geographies for the different services being tested:

Key Metrics Being Tracked:

Response times, broken down into:

  • Time to First Byte (TTFB)
  • Time to Full Load (TTFL)
  • Service Specific Metrics

Scenarios Being Tested:

  • Node Count
  • Request Count (Stress Test)
  • Geographic Distribution of Nodes
  • Geographic Distribution of Requests
  • Node Slashing/Misbehavior

Services Being Tested:

  • IPFS content retrieval (CDN/bandwidth)
  • IPFS upload (bandwidth)
  • Image Resizing/Optimization (compute)*
  • Turborepo Cache Server (compute/bandwidth)*

The above are still being decided and subject to change.

Phase {1} Goals: Nodes, Protocol, Services.

Like Phase {0}, the goals for this phase are pretty straightforward. While the overall goal pivots from proving concept/correctness to proving performance of the network, the specific goals for this phase can still be broken down into 3 groups:

Node Level:

  • Further understand and optimize node operation from a performance perspective
  • Test throughput, quality, and reliability of services being tested
  • Track request distribution amongst nodes (based on geography and reputation score) to better inform how the economic model could be optimized
  • Collect cost data from node operators to better understand how resources might be priced initially at the network level
  • Gather valuable insights to make further enhancements for the next phase

Protocol Level

  • Evaluate the reputation/slashing/reward system
  • Improved Sequencer/Broadcaster testing
  • Finalize NetKit, p2p network between nodes
  • Introduce Blake3 browser support
  • Revamp the CLI experience

Service Level

  • Initial testing of services to understand and optimize from a performance perspective
  • Evaluate service performance based on different geographies, node count/requirements, service type (bandwidth, compute), stress testing, etc.
  • Use the cost data collected from node operators to help ensure service/resource pricing is cost-competitive for developers (bandwidth, compute)
  • Collect valuable insights to help finalize the external-facing SDK to release as part of the next phase

Testnet Phase {1}: FAQ

As a Node Operator interested in participating in Phase {1}, what should I do?

Applications for node operators will open on Fleek’s Discord Wednesday 20th at 12pm EST. This is a rolling application form in preparation for the release of Phase {1} in October.

  1. Follow the instructions in the #access-guide channel and submit your application.
  2. The team will provide updates in Discord to all applicants and might reach out for further information.
  3. Stay tuned to updates in the #node-announcements channel regarding node hardware requirements, or preparations for Phase {1}.

Are there any incentives for Phase {1}?

You can 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, but there are several overall initiatives (outlined in the Testnet Participation section of the blog linked above).

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

Phase {1} will not be a permanent testnet. The initial plan is to run this phase for 1 week, and if the tests being conducted perform well, this timeline might be extended.

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 Phase {2}, when the Service Development Kit will be released.

Will node operator onboarding be a 'free for all' again? Or will it be different?

It will be different in the sense that we will introduce a testnet faucet and staking of test FLK tokens as the way for nodes to onboard to the network, which means there will be no onboarding queue/delay like last time. But at the moment whether it’s a ‘free for all’ again or not is still undecided, because there are potential benefits to both approaches. For example, not restricting nodes allows us to test performance with the highest potential node count, whereas whitelisting nodes gives us better guarantees that we have a more mainnet realistic environment to test performance with. So just in case we do decide to whitelist nodes this phase (or future phases), doing the application form now still makes sense.

What's new about Phase {1} compared to Phase {0}?

In this phase, several new core functionalities will be added to the network, which nodes will execute automatically:

  • Service deployment and running.
  • Transaction Synchronizer and Broadcaster.
  • Reputation/slashing/reward system
  • NetKit, p2p network between nodes
  • Blake3 browser support
  • Revamped CLI experience
  • Integrating Fleek Network services to external stacks for testing.
  • For all new additions prioritized for this phase, visit here.

Why did you pick these specific services to test?

These services have been picked specifically because they  allow for direct benchmarking against existing production metrics from third-party application mirrored services (ex. Fleek.co and other partners the Foundation is collaborating with).

If I participated in Phase {0} as a node operator, do I need to re-apply?

Initially, yes. All existing Node Operators will have their role transitioned to Node Operator {0}, determining their participation in Phase {0}. We will receive new applications for Phase {1}, and approved operators (if there ends up being any approval process) will be identified for this phase and further phases with a specific role.

Follow along with each phase of the testnet on X, and join the community of node operators in our Discord Server– see you all soon with more information surrounding Phase {1} ⚡

The Fleek Foundation ⚡