Irene
Luca 💥 Bounty: What's New?
Deals are currently a 1:1 process between a Client and a Storage Provider which is identified a priori.
If we introduce a Bounty contract, this 1:1 relation does not exist anymore, given that bounty (by design) means to generalize the concept of deal by making eligible for acceptance a set of SP (which can span from one to many) over which the SP who accepts the bounty is selected.
⚠️ Problems
The flexibility granted by bounty comes with issues that does not affects current deals on Filecoin.
When an open bounty is out, in principle anyone (who is eligible) can accept it.
Thus, it can happen that different SP are willing to accept the same bounty (eventually without knowing that they are not the only ones). This opens the door to (at least) two open points that need to be addressed:
- Bounty assignment/management
- Avoid SP to waste resources on bounty they don't end up accepting
We need to have a policy to assign a bounty to a SP who is in the set of eligible ones
When multiple SP are willing to accept a bounty, it means that there is at least one of them who is actually wasting resources (like checking data consistency he is not ending up storing).
Note that none of the above affect the current deal protocol, given that the SP willing to store the file is selected by the client a priori.
🎯 Goal
The aim here is to analyze different alternatives for bounty management and SP resource waste prevention in the context of bounty. Note that the way we address the former potentially influence the latter.
In particular, the focal point is that deal management should prevent SPs to allocate (much) resources to a bounty they won't end up accepting, because somebody else ends up accepting it before. This includes, as we said above, checking data consistency for data they are not ending up storing.
🤝 Bounty Management and SP Resource Waste Mitigations
Some ideas in order to address Bounty management and mitigate SP resource waste are listed below:
Idea 1: Specify in the bounty who are the SPs that can accept it
Pros:
- Mitigates the problem of assigning a bounty by selecting a priory who can accept it
Cons:
- Bounty is not “open” anymore
Idea 2: Assign the bounty to the first SP accepting it
Pros:
- Bounty can be kept open
Cons:
- SPs who are not assigned a bounty they were willing to accept are likely to waste resources
Idea 3: Introduce Soft Acceptance
Inspired by Layer 2 solutions, we could introduce a soft acceptance phase (which would not require checking data consistency) in order for SP to know if they are gonna be assigned a bounty before spending any resource on it. The idea is really simple
- SP are monitoring the chain looking for bounties
- When an SP sees a bounty he is interested in which is not soft-accepted yet, he sends a soft acceptance message for that bounty
- First SP soft accepting the bounty gets the right of accepting it.
Pros:
- Soft acceptance removes SP overhead in checking data consistency before accepting a bounty
Cons:
- Additional gas needed in order to send soft acceptance messages onchain
- Potential waste of resources due to soft acceptance messages that got sent by SP that do not end up accepting the bounty (because there is a former soft acceptance message they did not see before sending theirs)
Open questions
- Are bounties that are soft-accepted automatically accepted, or should they need to be "officially” accepted?
- On one hand, we want to give SPs the possibility of checking the bounty (i.e. consistency) before actually committing to it
- On the other hand, the above would imply to set up a way to manage bounties which gets soft accepted but not accepted by an SP (see idea 4)
Idea 4: Introduce Timeouts
In order to deal with bounties that got soft accepted but not accepted, we could introduce timeouts, meaning that after soft acceptance, acceptance should happen within X epochs of time (X TBD). If a bounty is not accepted by X epochs after soft acceptance, then soft acceptance expires and anyone can soft accept it again.
Pros:
- We solve the problem of bounty assignement even in case of soft accepted bounties that do not get accepted later on
Cons:
- Having timeouts can lead to the whole process to be slow
- We should handle (potential) "old soft acceptance” message for that bounty.
- Possibility 1: old soft acceptance messages still hold (in order) when a former soft acceptance "expires” [potentially complicated to handle, but could mitigate a bit gas waste]
- Possibility 2: old soft acceptance messages do not hold, and a new soft acceptance round is done every time a soft acceptance expires
Idea 5: Introduce Pool Contract
This would be an extension of Idea 1: the bounty is done with a pool of SPs, who internally organize themselves wrt actual internal bounty assignment and payment distribution.
Basically a pool would have its own governance which would lead both bounty assignment and prevention of SP resource waste. The hope here is that bounty market will encourage pools to be set up with their own governance, in order to satisfy clients needs
Pros:
- Once we restrict to pools we can "outsource” both the problem of bounty management and SP resource waste
Cons:
- In a way, bounty would not be "fully” open anymore
Overall Recommendation (To de discussed)
We think a combination of Idea 3 and Idea 4 can represent a good compromise to preserve bounty main feature (i.e. being open to anyone) while mitigating resource waste.
======
Notes
reference message from zenground0
