 Before starting to talk about the incentives, I wanted to give a quick introduction on Saturn. So Saturn is a project that is being built within protocol labs that is aiming to create a content delivery network or CDN for Falcon. So they are designing a network that aims to provide fast retrievals of content store on Filecoin, which is something we are thoroughly missing, right? It is decentralized, so this means that anyone can download Saturn code and contribute their resources to the network, and by doing that, they will earn some Filecoin. And so I want to stress that this is one of the teams working on this problem, is definitely not the only one, but for the context of this talk, I'll focus on this project. So in terms of roadmap, I just want to highlight that we hope to launch a first version before a field release when, so end of October, and then after that first launch, we will continue to iterate on it throughout 2022 and beginning of 2023. So it will be a work in progress, it's not something that we'll launch, and that's the final network and the final design, okay? So now moving on to the value flow within Saturn, so we start with the content publishers. So content publishers are websites and services that wish to deliver content that is stored on Filecoin. So examples could be NFT.storage, Internet Archive, or in the future Metaverse apps, gaming apps, so any sort of service that is trying to deliver content that could be stored on the Filecoin network. And these services will engage Saturn and buy the service of CDN, okay? So they will pay some Filecoin to Saturn to have their content accelerated. On the other hand, we have the end users. So the end users will be regular people coming into these services and using their service. So they would engage with Saturn through requests. So they would visit the website. The website would have to load some content, and so they would send a request to Saturn, and Saturn will give that content back. And they may have some financial relationships with the content publisher, so they could have sort of a subscription model or ad revenue or whatever, but this is independent of Saturn, okay? So this is would be a financial relationship that is sort of parallel to Saturn. And then finally, we have the node operators. So the node operators are the people or the computers that are committing resources to Saturn, and so the way it works is every time there's a request to Saturn, that request would be routed to the node operators, node operators would give back that content and then receive some Filecoin in return for doing or for fulfilling those requests. And so the money flow is sort of moving from the content publishers to the node operators through Saturn, okay? One thing I want to highlight here is that nodes are paid based on the logs that they are submitting to Saturn, okay? And the reason for this is there's no cryptographic proof or efficient proof of retrievals, so it's like you cannot prove that you made this retrieval without trusting the log you are receiving. And so these guides guide the design of what we call the Saturn Treasury, so it's the system that is sort of defining how nodes get paid, and the design includes a log detection system. So because we have to base the rewards on the logs that are being submitted, there's a tag vector here where nodes can game the system and do doctored logs or fake retrievals to try to get more rewards without actually giving out during like real retrievals to users. And so we have to have this sort of log detection system in place trying to flag these sort of behaviors, okay? And then we have the reward calculator which is the module responsible for taking all the performance metrics and all the logs and all the flag entities and then defining how each node will be paid. So they will be defining the payout. And finally we have the monitoring. So the monitoring here is really important because as I was telling you before, this will be an interactive development. So we will launch a first version and then we'll collect data on how the network is being used to improve the whole system. So improve both the log detection and the reward calculator. And so we have this monitoring here to store all the payouts, all the flags and everything so we can improve the system, okay? So now moving on to the incentives. So when we are designing incentives for any system, a first step is always to align on what behaviors we want to see. So what good looks like, okay? And in this case we have these two types of behaviors. So we want behaviors we want to see more of. So behaviors we want to incent and behaviors we want to avoid. On the side of the good behaviors, the first one is a high bandwidth service. So bandwidth is just essentially how much content you are serving in a certain time interval. And so the more bandwidth Saturn has, the more users it can serve, then the more content publishers it can serve. And so this is the top behavior we want. We want a really high bandwidth service, okay? But then this is a CDN, right? So we need fast retrieval. So speed is another behavior we want to incent and finally reliability. So we don't want nodes going offline out of the blue and users not getting their content. So we want nodes to be reliable. And within these behaviors then comes two questions that we need to answer. So first is how do we measure performance? So how do we transform these high level behaviors into actual metrics that we can compute? And then how can we use those metrics to redistribute rewards among nodes that are participating, okay? On the side of the bad behaviors, they essentially are focused on the sort of doctored logs and fake retrievals I was telling you earlier. So we want to avoid this sort of behavior of nodes trying to game the system. And questions here are first, how can we detect this? And then once we detect them, what should be the penalties? So we want to apply penalties to not have an incent for nodes to do this sort of behavior, okay? So on the log detection module, we started so our design choice was to start simple. So we start with the simplest model just catching the most basic behaviors we expect to see. And then after launch, we'll start collecting data on the actual users and use that data to improve the system. So in terms of the detection methods, we start with heuristics. So heuristics are essentially rules in coding simple behaviors. So an example could be we'll flag all nodes that have a bandwidth that is impossibly high. So we can find this threshold, right? Like we can think about what would be like the maximum upload speed that a network provider will give you. And so if we're reporting a bandwidth that goes above this, it's impossible, right? So we can flag those types of nodes. And so we start with these heuristics, simple rules. And then as we collect more data, we can use more data-driven methods. So we can use anomaly detection, which here is essentially flagging nodes that are very different from the normal data distribution. So you kind of learn what is the normal distribution and what usually nodes do. And you'll flag anything that is very far, very different from this. So this will be kind of finding anomalies or outliers. But then we can also use machine learning models such as supervised learning, semi-supervised active learning. But again, this would require data. So at the moment, we cannot build these methods. But then as we collect data, we can actually try out these and improve the whole system. Now moving on to the rewards. So the first question we needed to answer regarding rewards was how to measure performance. So for a bandwidth, it's quite straightforward. So we are just using how many bytes are served by giving node in a certain payout window. For speed, we have to use two metrics. So we are using time to first byte and total download time. And then for reliability, it's straightforward as well. So we are just using uptime. Now the second question was after having these metrics, how do you distribute rewards based on those metrics? And here we are using what we call service scoring functions. So these are essentially functions that map a service metric into a ratio of rewards. And the reason why we are using here ratio of rewards, it's because at each payout window, rewards are bounded. So we have a fixed pool of rewards that will be distributing for that payout window. And so we have to compute what will be the share of rewards of each node that participated during that window. And we came up with this sort of general function that is an adjusted share of performance. It's adjusted because it has that exponent k that is controlling how much we incentivize over-performance in relationship with under-performance. So for instance, if we were to use a k equal to 1, so a linear function, this will be just a proportional distribution of rewards. So an example, a node with a ratio of bandwidth of 40% would receive 40% of rewards. So it's linear and proportional. This is option 1. Option 2 is going for an exponent that is higher than 1. And this essentially means that over-performers are more incentivized. So an example here with a k equal to 2, a node that would be serving 40% of the bandwidth would receive almost 90% of rewards. So you are kind of pushing more over-performers and not as much the under-performers. The third option is to have a k less than 1. And so this means that the over-performers are incentivized less and you end up distributing more evenly the rewards. So an example here will be with a k equal to 0.5, so a square root. And a node that is committing 60% of the bandwidth will receive around 15% of rewards. So you are kind of not rewarding as much over-performers and you are kind of distributing everything more evenly. And this is a design choice. Okay. Okay, now moving on to the penalties. So when we were thinking about penalties, we thought about how can we define some theoretical upper bounds and lower bounds. And for that, we used two assumptions. So the first assumption led to a lower bound. And this assumption is essentially saying that the penalty should be large enough so that it is not economically advantageous to cheat. Okay. And what does this mean? This means essentially that if a node decides to consistently cheat, on average on the long run, their reward will be negative. So they will be losing money. Okay. And how do we actually encode this? So we know that the detection system won't be perfect. That's impossible. There's no detection system that will catch everything. And so sometimes it will catch the cheating node and other times it won't. So this concept of sometimes catching a cheating node is called the true positive rate. Or you can think of it as the probability of a cheating node being flagged. Okay. So we can use that probability and the expected reward in case of the node being flagged versus not being flagged to get that equation there. So you are saying it's like as we add up every payout time, on average, the total reward will be negative. That's the equation you see there. And then if you solve that equation for P, which is a penalty, you get a nice lower bound that depends on the average reward before penalties, which is that sum of the hours over n. And then one over the true positive rate. Okay. Now, for the upper bound, the assumption is that penalties should be small enough so it doesn't hurt too much honest nodes. Okay. And again, what we mean by this, we mean that on the long run, an honest node would receive enough rewards to not to continue operations and be sustainable. Okay. And once again, the log detection system won't be perfect. So sometimes an honest node will be flagged. It's just the nature of the game. And we can include that on the false positive rate. So this is essentially the probability of an honest node being flagged. And what we are saying here is that the rewards after penalties on the long run should be bigger than a certain percentage of the rewards before penalties. That's what that tau is doing there, is that ratio of rewards. And if we'll solve for that, then we have a upper bound that depends again on the average reward before penalties and depends on the tau and the false positive rate of the log detection system. So the nice thing about it is that if you plug in the values for different performances of the log detection system and tau, you get a really tight interval for the penalty parameter. So that this means that there's not a lot of values that actually fit and work. And so we already get a pretty good idea of what the penalty should be. But also, we get bounds for the performance of the log detection system. So we kind of get the goal of what is good enough because some values won't lead to intervals that you can intersect. So for very bad models, there's no penalty that would be higher, low enough or big enough. So it already gives us a goal of what the detection system should look like. For next steps, so before launch, we still want to run a Monte Carlo simulation of the whole treasury economy to fine-tune the final parameters. And after launch, we want to explore more detection system methodology, as I explained before. So as we collect data, we can explore these things. But there's still a lot of open questions. So one of them is how to leverage logs from clients and node operators to improve our fraud detection system. So at the moment, we are only collecting logs from the node operators. But as we onboard the content publishers into Saturn, we will be able to start collecting data from their side as well. And these two profiles, they are not incentivized to collude because one is paying for the service and the other is being paid. So if you use the logs of these two sites and they match, then you are fairly certain that there's no cheating going there. This is one of them. The other is how to open the log detection system. What I mean by this is, if you were to show everything, so if you show the rules, the thresholds, the models, everything, is the detection system not obsolete? Because if you show everything, usually, it's very easy to game, right? But can we design a smarter way of doing this that allows us to show everything and still be good enough? Okay. Cool. If you want to know more about this Saturn and Saturn incentives, I left a bunch of links here. Check out later. And I'm not sure how we are with time, but if you still have time, open for questions. And thank you for your attention. Yeah. I think we have time for a couple of questions. Thanks for the talk. You said there's a pretty tight bound between panel upper and lower bounds. What sort of assumption were you using for like false positive rate? Yeah. So for the, let me see if I can recall, so for the false positive, I think I was looking at around one or two percent, because it's like, it's, as I was saying, it's, we will be kind of moving towards not flagging as much at least in the beginning. And then for the true positive rate, it will be around like 60%, something like that. So you're kind of a bit more loose on the true positive than on the false positive. Okay. Awesome. And sorry, just, I may have missed this. What K value did you go with ultimately? So that's one of the parameters that are still fine tuning. So it's really a question of how much do you want to incent over performance versus being a bit more equalitarian and having reward distributed more. So it's still something we are fine tuning. Yeah. Thanks. Hi. It's really cool. Like how you, there's a tight bound. And I'm wondering like as, as the economy grows, and will the parameters change over time and will you like find, retune it again? And if that's the case, then you're like, it might go obsolete or like they can game it and things like that. Right. Yeah. Sure. So I think in the first stage for sure, I'm sure like after lunch will update it a lot. But I think the end goal should be that you have a stable enough detection system that doesn't lead to a lot of changes on the penalty side. But it's true. Like the performance of the detection system will change as time goes on. And we'll have to keep balancing that. But yeah, let's hope like, let's hope that as we start launching and iterating on it, we get to a performance that is stable enough for this to work.