Open AuHau opened 1 month ago
markspanbroek
commented
1 month ago I'm not sure I understand you completely. If the collateral scales per byte, and the repair reward scales per byte, then it shouldn't matter whether you calculate it from the collateral:
total_repair_reward = total_collateral * repair_reward_percentage
or from the collater per byte:
total_repair_reward = number_of_bytes * collateral_per_byte * repair_reward_percentage
AuHau
commented
1 month ago Yeah, you are right I did not really make myself clear here 😅 Sorry.
Yes, you are correct. I am not suggesting changing the calculation of the reward, but changing the collateral semantics. Do we have issue about changing collateral to "per byte"? I don't think so, there is only one for availabilities, so maybe we could change that into general changing of that?
Also do I understand correctly that you are saying that it does not matter if we have collateral per byte or general collateral, because the calculation of the reward is the same? I mean for the "per byte" it needs to be multiplied by the number of the bytes...
emizzle
commented
1 month ago We have discussed this a few times in regards to Availability:
maxCollateralPerByte that specifies the maximum amount of collateral per byte a provider is willing to commit to a request. This can be used to prioritise slots in the slot queue.To me, this is very similar to our discussions regarding "price per byte per second" and "price per proof", and we concluded that we should attempt to align both the storage request parameters and the Availability parameters when possible to make it easier to reason about. For "collateral per byte", I think it would be fine for us to align it in both the request and Availability parameters. As Mark pointed out, we can update the calculation to total_repair_reward = number_of_bytes * collateral_per_byte * repair_reward_percentage, which in effect, would keep the repair reward the same (I think that's what he was trying to say). In the case of "price per proof", it was not clear on how to calculate the total price using "price per proof", so it's probably best to keep that as a parameter in Availabilities only. "Collateral per byte" doesn't have this issue, so it seems best to align the "semantics".
AuHau
commented
4 weeks ago Agree.
As Mark pointed out, we can update the calculation to total_repair_reward = number_of_bytes collateral_per_byte repair_reward_percentage, which in effect, would keep the repair reward the same (I think that's what he was trying to say).
Agree, for me the difference is the semantic here. If we would leave the collateral as we have now, then yes, most probably the user should calculate the size of the collateral using the size of the dataset and then yes, it will be "same", but honestly he as well might just choose some arbitrary number. If we change the semantic of collateral to "per byte", then this will scale automatically in our system.
markspanbroek
commented
4 weeks ago Thanks for the clarification. I'm ok with changing it to "collateral per byte" in the request.
As described in the design doc, the node that repairs a slot should be awarded additional reward as compensation for its extra work as it needs to download more data in order to reconstruct the original dataset. This reward should come from the collateral of the previous host. Currently, we are not awarding this reward.
Thinking about the size of the repair reward, it is not trivial to decide what it should be.
The current thinking coming from the design doc is that it should be a fraction of the collateral, which would be specified on contract constructor, hence same for the whole network. But as that section also states the reward should not be too small nor too big. I would argue that the "fraction of collateral" approach does not satisfy this requirement as the reward could easily become either too small or too big based on the user inputted
collateralparameter (he might not even realize it affects the repair reward).If we are targeting to compensate for the required work to reconstruct the lost slot's data, I would argue that the size of the reward is a function where the size of the slot plays a major role. I would hence suggest another approach which is linked to our general shift for pricing "per byte". If we would have collateral also scoped for "per byte" then the fraction of "per byte" payment would better reflects the final repair reward as it would scale with the size of the dataset. WDYT?