Filecoin Saturn Economics
Designing incentives for Filecoin’s Web3 CDN.
In this blog post, I discuss the incentive mechanisms my team at CryptoEconLab designed for the Saturn Network, a project started by Protocol Labs to bring fast and reliable access to content stored on Filecoin. But first, what is Saturn, and how does it work?
Saturn overview
Filecoin Saturn is a Web3 Content Delivery Network (CDN) that aims to accelerate the retrieval of media files from the Filecoin Network. It works as a secondary retrieval market where Retrieval Providers serve content that they are caching or that they will fetch on behalf of the end user. In this network, the Providers are not necessarily the same people that are storing the original data in the Filecoin Network, but they are a key part of the ecosystem.
There are three main stakeholders in this market:
- Content publishers — Saturn’s customers. They use the network to distribute their content and allow their users to access it around the globe.
- Retrieval providers — Saturn’s “workers”. They are servers distributed globally that get paid to serve content requested by Saturn.
- End-users — Saturn’s content recipients. They are normal web users that wish to access the content provided by the Content Publishers and distributed by Saturn.
Content publishers pay the network in FIL tokens (Filecoin’s native currency) to have some content pinned to Saturn’s CDN. When an end-user tries to access this content, they will make a retrieval request to Saturn, and Saturn will match that request to the Provider most adequate to serve it. This match is based on the geographical location and the Provider’s previous performance. Finally, the Retrieval provider serves the content requested and gets paid by the network for their contribution.
Thus, Saturn has an economic model where money flows from content publishers to operators, while data flows from operators to end-users.
How CryptoEconLab got involved
During the first iteration of the Saturn network, the team was focused on building a network of Providers that was capable of delivering a fast and reliable service. As such, they needed a mechanism to distribute rewards that was aligned with the performance expected of the network.
In addition, rewards were going to be distributed based on the information reported by the Providers and end-users, which opened an attack vector where Providers would create fake retrieval requests to collect a bigger share of the rewards being distributed. Thus, the team needed a way to detect these fraudulent logs and penalize the misbehaved Providers.
During two months, we worked together with the engineering team to answer these questions and design the main set of incentives for the network. Here’s an overview of these mechanisms and tradeoffs.
Reward distribution
Before designing the reward distribution mechanism, we had to define what behaviors we wish to reward and how to measure them. There were three main behaviors we thought to be important:
- High capacity — measured by the total bandwidth served
- Speed — measured by time-to-first-byte (TTFB) and total download time
- Reliability — measured by uptime
Now the question was how to distribute rewards based on these performance metrics. Here, we used scoring functions that map the performance metrics into a ratio of rewards to be given to the provider. We considered different options for these functions and found that there was a tradeoff between reward decentralization and performance incentives. More concretely, there is a choice between how evenly rewards are distributed among Providers, and how much we penalize Providers that underperform in our key metrics.
To estimate the impact of each scoring function on reward distribution, we simulated rewards for each function. This helped us find the best balance between decentralization and performance incentives, ensuring that rewards are distributed fairly while still incentivizing operators to provide high-quality service.
Simulation results for 9 different scoring functions. Each plot represents the payout by bandwidth for a single scoring function. The simulation used three different types of Providers — High, Normal, and Low performance.
You can learn more about the simulation and the design by checking our technical report.
Log detection and penalties
Another key mechanism that we implemented in the network was the log detection model. We started with a simple heuristics-based design that encoded behaviors that could be indicative of fake traffic and log manipulation.
We also estimated the performance of the model. Here, we considered the true positive rate (i.e., the probability of a cheater being detected) and the false positive rate (i.e. the probability that an honest node is flagged as a cheater).
With these two metrics, we defined rational bounds for the penalty that should be applied to a Provider that was flagged by the detection system. We derive these bounds, we used two assumptions:
- Lower bound assumption — the penalty should be large enough so that it is not economically advantageous to cheat. In other words, the expected reward of cheating (taking into account the probability of detection) needs to be negative.
- Upper bound assumption — the penalty should be small enough so that it does not hurt honest nodes considerably. In other words, the expected reward obtained by an honest Provider should be higher than a certain percentage of the total rewards.
Now we had a detection system in place and we had an optimal penalty value that balanced the need to meaningfully deter fraud while avoiding penalizing too much the honest Providers. You can check the full analysis in the log detection spec and our penalty simulation report.
To collateral or not to collateral?
Finally, we considered whether adding a collateral requirement could be an effective mechanism to prevent network takeover attacks and provide additional incentives for Provider retention and adherence to rules.
In its simplest design, we computed how much collateral would be needed to deter Providers from exiting the network before their pre-agreed service date. We then estimated the costs of a takeover attack on Saturn assuming a given network size and the calculated collateral requirement.
We concluded that adding a collateral requirement could be effective at reducing Provider churn. However, its efficacy at preventing takeover attacks was small, which resulted in the need to have additional protection besides collateral.
Because the added complexity of requiring collateral to participate outweighed the expected benefits, we decided to not implement a collateral mechanism. Even though the risk of churn was higher, we concluded that the ease of onboarding new Providers would lead to a higher supply of Providers and thus allow us to grow the network faster.
Looking forward
The Saturn Network launched in November 2022 and since then it has grown to more than 1000 Providers 🚀. At the same time, bandwidth served and earnings have followed our expectations and the main mechanisms have been working as expected.
Currently, the team is working hard to onboard more customers and to move some of the mechanisms we discussed here to smart contracts run on FVM, Filecoin’s Virtual Machine, which is expected to launch on March 2023. This move will make the process even more transparent and verifiable.
Want to know more?
You can read more about the economics of the Saturn Network and CryptoEconLab full analysis in our in-depth report.
If you want to read more about CryptoEconLab and our work, you can visit our website at cryptoeconlab.io and read our analysis in our HackMD Almanac.
