Research q: how do we deal with multiple SP accepting an “open proposal”?

💥 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

We need to have a policy to assign a bounty to a SP who is in the set of eligible ones

• Avoid SP to waste resources on bounty they don't end up accepting

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

scott.conner3 years ago

luca (OOO) irene giacomelli I've been thinking about problems PeSto will encounter and I think I found a tricky one that you might be able to help with. Today a client makes a deal with a specific SP. A major part of PeSto and others is that the deal is public and anyone can satisfy its terms before the replication factor is fullfilled. A problem with this is that SPs now have more risk involved when making a deal. Example: SP Alice and SP Bob both want to get paid by a PeSto contract with replication factor 1. Both Alice and Bob (1) transfer the data from some location to their sealing pipeline (2) prepare the data (3) send a PublishStorageDeal message committing to the deal. Bob sends their message first and gets to claim the deal and receive payment. Alice incurred the expense of (1) and (2) but receives no payment. Beyond PeSto and beyond the clientContract interface this is a general problem for any public contract incentivizing storage to an open group. There are a lot of ways you can imagine solving it (staking, lottery, restrict allowed providers, auction) and I think we should explore this thoroughly so we have a good idea what our options are. If we come up with good general patterns right now it will have a ton of leverage.

#fil-data-persistence