# Reports on the RP Stochastic Simulation

###### tags: `Retrievability Pinning`

:::info
Up to date by September 2022
:::

## Descriptive Report

- Commit: https://github.com/BlockScience/filecoin-drc-research/commit/082ac8c19e56242b6bbac82db6e9000cccc4eb7b

**08/09**
--
**Commit:** https://github.com/gabriellefundes/filecoin-drc-research/commit/a8b4d7806276131a2881f726f509d87d6df6c830
#### Mechanism of slashing:

Right now, when the deal is created we decide if it will slash at some time with a probability $p_{\text{s}}$. If the deal is to be slashed, we decide the date of slashing with uniform probability.

#### Analysis:
We start with the following parameters:

- slash_penalty: -1000
- chance_slash: 0.01
- average_duration: 20
- average_new_deal: 1
- average_payment: average_duration * 0.1 * 0.5 = 1
- average_collateral: 50 * average_payment = 50

Then, we can estimate the average time for the payoff_1 return to normal after a slash to be ~ slash_penalty/average_collateral = 20. In fact, we can verify that in the following plots:

- Provider 1:
Note that there are three slashes: for the first two combined, it took ~65 days to recover; for the third one, it took ~ 10 days to recover, which means ~ 25 days in average.

- Provider 10:
There were two slashes: for the first one, it took ~25 days to recover; for the second one, it took ~15 days to recover. In average, ~20 days.
- Provider 103
Finally, for the provider 103, it took ~25 days to recover.

Now, let's see if this holds for different parameters. Since we want ~100 days to recover from a fall, let's guess we should have
- slash_penalty: 5000

To better analyse, let's reduce the chance of slashing to:
- chance_slash: 0.001

We can confirm that our expectation - it takes ~100 days to recover from a slash - is reasonable by looking at the following image


**09/09**
--
**Commit:** https://github.com/gabriellefundes/filecoin-drc-research/commit/3d4fd4669288d56896a3ab15f872f78a609cf478

#### slash_penalty estimate for payoff_2:

As before, we want to estimate slash_penalty from the other parameters given that we want a slash to be equivalent to 100 closed deals. So we want
$$
\sqrt{\text{slash_penalty}} = 100 * \sqrt{\frac{\text{average_collateral}}{\text{average_payment}}} = 100 * \sqrt{50}
$$
which implies $\text{slash_penalty} \approx 500000$.

Again, we can look at some plots and confirm that this should be more or less right.

### More systematic approach

Now, I modified the code for having a big chance of slashing and limited the slashes to 1 per provider. This way, we can focus on seeing how much time does it take to recover from a slash.

We will use the following parameters:
* chance_slash = 0.99 (limited to 1 slash per provider) (remember that slashes occur in a random date within the deal duration)
* slash_penalty_1 = 5000
* slash_penalty_2 = 500000
* new_deals = new_providers = poisson(1.0)
* payment = 0.05 $\times$ duration
* collateral = payment $\times$ uniform(1,101)
* deal_duration = random_integer(2,40)

Then, we can run the simulation with 200 days and get some plots as:

We have one such plot for each slashed deal. We use the following snippet to find the slash_dates for each provider with slashed deals:


Note that we are only looking at deals slashed in the first 20 days since we want to give time for the provider to recover. Now we find, for each provider, the total pay_off before slash and then search for the timestep in which the provider recover using the snippet:


Below the image, we see that it took, in average, (67 days, 50 deals) for the providers to recover the payoff_1 after being slashed and (98 days, 81 deals) to recover the payoff_2.

We can see that our initial guess was pretty close! Now, we can try to double the parameters and see if we get closer (following our reasoning, this should double the number of deals in payoff_1 and![Uploading file..._rcoi2tfwy]()
multiply the deals in payoff_2 by $\sqrt{2}$)

By running the simulation with these parameters some times, one can see that now the average number of deals in both cases fluctuates around 100, as we want! Below are the results of a 3-run simulation of this system:


An observation is the fact that since we are taking ongoing deals into account (with a 0.1 multiplier) only in the first payoff, it takes fewer days to recover from a slash. If we set this parameter to 0, we find that the recover times for the two payoffs are basically the same for our choice of parameters.

Therefore, I would make the recommendation

> $\text{slash_penalty_1} = 10000$
> $\text{slash_penalty_2} = 1000000$

### Going back

Now, we can go back to having only a few slashes (1% of deals) and allowing more than one slash by provider. With the parameters we chose, we have the following plot for the scores:


We note that it seems fair in the sente that late providers can get good ratings after some time and early providers not necessarily dominate. It would be interesting to have a measure of the characteristic time it would take for vanishing the advantages of early providers.

Also, note that the two plots are very similar. This happens because the main mechanism of reorganization in the raking is the slash, that occurs in the two plots simultaneously. Need to study better the differences between the two ratings.

## Observations (can ignore for now)
- Since we have two pay-off functions, the providers will have to choose what combination of the two they want. Depending on their choices, we have different incentives being prioritized. What is the behaviour we want? What is, for us, the perfect balance between the two incentives? If we have a clear answer, can we just give one rating for the providers encapsulating the two pay-offs?
- If past events do not have its influence decaying over time, it's very difficult for early adopters to have a good rating. **To see this is a problem, we can make the following analysys: take the average rating of each provider x (=20) timesteps after they entered the consortium and scatterplot with the time they entered the consortium.**
- My guess is that the last to enter will have consistently less pay-off, specially when there are only a few new providers entering the consortium
- Reputation is a resource to the Provider:
- Providers with more reputation can charge more for their services
- Providers with more reputation will receive more deals
- Since reputation is a valuable resource to the Provider, we need to be careful when adjusting the pay-offs
- a
- In the long run, there will be a bunch of "inactive" providers and all the remaining providers will be high rated.
- The penalty multiplier is the same for the two pay-off functions. This seems a bit strange, since it seems the second pay-off function penalizes slashed providers too much since:
- In the first function, we compare $\text{slash_penalty}$ with $\text{collateral}$
- In the second function, we compare $\text{slash_penalty}$ with $\frac{\text{collateral}}{\text{payment}}$
- In the simulation, we assume random collaterals. That seems overly simplistic, maybe we should try to improve the prior if we know what are the most likely values of the collateral. **What effects does this have? My guess is that it does not change much if the average is the same, but I have to think more.**
- I also find a bit strange that the first reputation has the sole goal of mitigate self-dealing, since self-dealing usual is a cheating strategy to increase rating. I think that we should think first about what we want to incentivize and then about what how we make sure the providers aren't cheating.
- I think a better approach to this goal is to not award so much the success and to penalize the failures (with decaying effects, of course) so that it's kinda useless to have one more success.
- **As to a measure of efficacy for the first reputation, we can see how much does it cost for a provider to significantly increase the rating by self-dealing. Question: is there any cost to self-deal whatsoever?**
- **It's easy to measure the efficiency of the second reputation, we can have random providers plus two different providers, one of which takes many small deals and other that takes some big deals and see which one has the better performance.**
- **Alternatively, we can take the average ticket (payment or collateral or both) of the top 10% and the top 20% and also the average number of deals for these two ranges. In another words, try to measure the correlation between rating and number of deals.**
- Vertical axis: rating, Horizontal axis: #deals, average payment (or collateral)
- Slash might be rare in the simulation. Plot #slashes per time. What are the effects of slashing? Can we compare similar deals with and without slashing? Or different amounts of slashing?
- What is the value of $\text{slash_penalty}$ for which 1 slash ~ 100-1000 finished deals? That is, if someone has a slash, what is the value of $\text{slash_penalty}$ such that it takes 100-1000 finished deals to get back the rating?