Fil+ design exploration

[dkkapur]

There are several ongoing threads at the moment on ways in which Fil+ can evolve to become more effective. This is a discussion topic that aims to consolidate tracking for these open threads, create a space for sharing new ideas where we can follow-up together without losing context, and propose a set of shared goals and constraints/requirements on which ideas can be evaluated.

Over the last 6-9mo, Fil+ has seen tremendous growth. Every aspect of the program has scaled up - driven both by successful innovation and maturation of services on Filecoin that are driving end-user value (including SP driven business development), and SPs trying to maximize ROI by onboarding sectors with verified deals in them to benefit from QAP. As we come off this high growth period with many lessons learned, tools built, and more community members than ever before - we have an opportunity to push new designs that are more effective and can help prioritize quality of work served by DataCap in the Filecoin network.

I'd like to begin by proposing the following as a framework:

Goals for Fil+ processes

• DataCap allocation should commensurate with earned trust
• Minimize false positives for “trustworthy” clients
• Attempt to maximize case coverage for current types of applicants → for most types of applications we have seen today, there should be a path for applying for DataCap / or an explicit descoping
• Decentralization, minimized bias, scale

(what else should be flagged here?)

Please share your thoughts/ideas here so we can follow-up as a community together and track the latest on various threads that are opening up across GitHub, Slack, email, etc. I'll keep adding ones I've come across as well.

[dkkapur]

filecoin-project/FIPs#636 (comment), specifically this from JV

[dkkapur]

Casey's process proposal in Slack: https://filecoinproject.slack.com/archives/C01DLAPKDGX/p1677177752104429

[dkkapur]

Ongoing threads around introducing tiers within Fil+ QAP -> some types of data may be more obviously/provably useful for Filecoin than others

[dkkapur]

cc @mjroddy from last 2 gov calls

[PHABRIC77]

Look forward to this discussion.

[Aaron01230]

The visualization of the entire Fil+ process should be taken into consideration

[dkkapur]

Hey folks - been thinking about this problem space quite a bit over the last month. Here's a thread that I will use to track the notion of "building trust" more generally.

Info about applicant
What can a DataCap applicant provide to the community/notaries to establish trustworthiness?

• who they are
  • social media - twitter, linkedin, etc.
  • KYB, KYC
  • local legal docs (business license, driving license, etc.)
  • proof of employment
  • relationship to data owner - if relevant
• what they have done
  • past allocation data - verified deals from owned client addresses, unverified deals on chain
• what they want to do
  • what type of data is being onboarded?
    • public
    • private
  • what sort of use case?
    • useful for the world
    • useful only for them
  • is there a data storage plan? who are they working with?
    • SP ID list
    • No list but clear selection logic
    • offloading decision to a service
      • biased service (picks based on something, i.e., reputation, private knowledge, etc.)
      • open auction (BDE, trustless notary, etc.)
    • replication target
      • min or max
    • replication constraints
      • set by external forces (i.e., geopolitical)
      • set by data owner, client
      • constrained by tech, physics
  • data onboarding rate
    • blockers, timeline
    • max data onboarded

“Trust” and trustworthiness
How do applicants earn trust based on the above?

• the more that they share about them
• the more “compliant” their deal making behavior is in the past, e.g., clear replica distribution patterns as observed by CID tracker
• the more flexible the data storage plan is: from a default trust earning standpoint without any additional data, it is interesting to note that running an open auction > going to a tool > pre-selected SPs (and SP IDs) from an earning trust standpoint
• stake / skin in the game (client collateral, etc. and similar proxies for indicating financial incentive alignment)

[dkkapur]

What else can we add to this?

[mjroddy]

Hey Deep - sorry it took so long but some thoughts below. I do see how what you have here still applies just in a different context, I've taken a higher level view on this

[The-Wayvy]

This is just going further in the wrong direction. @mjroddy is correct. Manual human inspection of transactions is not a solution.

[The-Wayvy]

Building trust via KYC < a trustless system with incentives built into the protocol.

[The-Wayvy]

Notaries will be bribed . If it hasn’t already happened it will eventually.

[mjroddy]

Thanks @dkkapur and apologies for me taking so long to respond here and help you drive this conversation.

Firstly, I'll say that I do believe the FIL+ program has been successful to date. It has incentivized the earliest onboarding of real data on to the network and helped spur coordination between SP's globally, that of which I believe would have taken significantly longer without the incentive mechanisms that exist. There has been a lot of work done by the team particularly recently with the tooling to make the UX much better for client/notary and SP's. My comments below are regarding how I believe FIL+ should move ahead, given some of the issues I see and I don't want to diminish any work done by many to date.

Base (Flawed) Assumptions:

Data storage is free.
Intentional or not there seems to be an underlying assumption that data storage on Filecoin via FIL+ makes storage free. It does not. There is a subsidy that masks the cost and that same subsidy is an effective tax on other SP's who compete for those rewards. When the price of FIL is high, the subsidy will mask this tax, as the price falls or the subsidy falls that tax is exposed. We are seeing this today with the fraudulent behavior by SP's and Notaries to game the system to earn greater rewards which is making all honest SP's less profitable then they should be.

Filecoin+ is sustainable.
Because of said subsidy it creates an incentive for Data Preparers (DP's) to apply for FIL+ deals, and again, game the system by ensuring that their datasets meet the requirements of FIL+. I use the word 'requirements' loosely there, as it's clear that requirements aren't well defined and thus it falls to the notary to decide what datasets fit and what do not (i.e. it’s subjective). However, the bigger concern here is that the large majority of datasets that I see are not being requested by a client. We are skipping them in the value chain altogether. Datasets are often scrapped from the internet and/or are currently being stored on a traditional cloud provider already for free. There is rarely value being created for a client here, value is being extracted via the rewards by the DP's and SP's and very likely once the subsidies deteriorate no-one will be willing to pay for said dataset to be stored. The datasets that do come from companies are largely the same…… the question is would they be willing to pay for the data to be stored on Filecoin. I think the answer is largely no, which makes for an unsustainable project/program in a few years. There is an argument that the utility of Filecoin will increase and thus these datasets become more valuable to users but this is a long bow and as a community we should be incentivising and driving real utility to real clients today. Data Preparers can be important – they can help prepare the files and/or drive real sales – today they provide a questionable value proposition for the client because the client isn't really engaged.

FIL+ will scale.
To be clear, we could scale FIL+ but I believe it would create more issues for the network along the way. The issues here have been well documented related to fraud etc. and the general view seems to be that we can combat the fraudulent activity with the right tooling. However, I think this is a losing battle. E-FIL+ for example is opening a pathway for encrypted data, it is going to be extremely difficult (impossible) to mitigate fraud that occurs there. And if the economics create the incentive, it will occur. Dragging clients through KYC/Onboarding processes through potentially a system they don’t understand isn’t a good UX, it’s awful. We know the onboarding process needs to be seamless for Filecoin to gain real adoption.

FIL+ is Decentralized.

You can’t have ‘trustworthy client’ or ‘datacap allocation commensurate with earned trust’ at the same time as Decentralization. Great Notaries will be bias, bad notaries will be malicious. Adding more Notaries to FIL+ just creates a larger attack vector, again I think we are seeing this play out in real time. I don’t think it’s a coincidence that we have seen an influx of notary applications as the FIL price has declined. Further, the Notary engagement is very low, the large majority of new applicants aren’t here to drive long term value, they are here to sign off Data Caps. All of this starts to move us to the real question of…. What is the point? What are we trying to achieve with FIL+

A faster, more effective and more value aligned FIL+ Program

So below I propose a potential path forward for FIL+, I don’t think it’s the only way forward and I’m sure It can be improved but I do think there is an important role for FIL+ to play in the ecosystem.

• FIL+ should become a centralized program.
• FIL+ should be thought of as an R&D type grant.
• FIL+ should incentivise real adoption by real clients.
• Datacap is dynamic with pricing, limited, regional and reviewed annually.

FIL+ should orientate into a program that drives real research, development, and client adoption. For example;

• An SP is building a use case for a particular vertical and want to build a POC with the intention of onboarding a paying client, the Datacap could help subsidies some of their cost. The application may include learnings/documentation/tooling for the broader network to learn from and adopt.
• A Software provider is building an application on Filecoin Network and want to include a discount period for new clients as to help attract them across. The data cap could be utilised to incentivise SP’s who support that application.
• A Data Preparer is in a negotiation with a potential client for archival storage for a large dataset for 10 years. The data cap could be used to help subsidies some costs and therefore allow the SP’s to price more competitively.
• A charity is looking to store data on Filecoin and wish to apply for discounted pricing, they apply for a data cap making it much cheaper for SP’s to store.
• A researcher is capturing data for a climate study and believes that the data will be useful to researchers more broadly, they apply for a grant by the government for funding to store the data for 10 years on Filecoin/FVM and utilizing datacap to minimize costs

There are likely many more examples, the point is that we can shift FIL+ to something that will provide more value to real clients and to the broader network, it can be dynamic, bias and still provide value to all. Note that the above examples do not assume that data storage is free, it comes at a cost which the client must (eventually) pay for. The new program would provide an incentive to help spur adoption and real value flowing from the end client through Filecoin and to the SP.

The FIL+ program today has a binary outcome; you get approved, and you earn 10x the rewards or you don’t. It’s not dynamic whereby a specific dataset or use case receives a datacap relative to the potential value that is driven into the network. The above program could function in this way, it is more flexible. (Granted there are technical specs that would need to be discussed here).

The centralized program could still have notaries, but I would suggest that the size is severely reduced, that they are incentivised via a reasonable salary to participate and that their performance is reviewed by the broader community yearly. The Notaries could even be voted in from various regions. A smaller size would make the program much more efficient and enable the team to make decisions more rapidly. If there was a need to increase this could be done so at the regional level, with coordination at the global level. The amount of Datacap should be limited, a scarce resource becomes more valuable. It should also be increased/reduced based on FIL price and community acceptance of the program. This provides a pathway for the program to expand IF the value being driven by FIL+ is being reflected in the network.

Transitioning the program should be considered. I believe that all datacap to date should be grandfathered, that is, they should remain indefinitely. Moving forward Datacap would be harder to receive and so this initial period should be thought of as a way FIL+ incentivised the earliest real datasets onto the network and moving forward it is about the quality of those datasets (which should largely be determined by the client).

TLDR

Filecoin+ should be centralized and bias because it inherently will be, the program should be treated somewhat like and R&D grant whereby ANYONE can apply for datacap but the approval is based on the decision on a smaller notary group that represents stakeholders regionally. The focus of FIL+ should be on driving REAL adoption and Development and thus value to the network. Datacaps should not automatically be 10x but much more nuanced, a function of the value being driven by the data being onboarded. The ‘budget’ of such a program should be reviewed annually and scaled up and down based on the community’s view of whether it is successful (driving value to Filecoin) or not.

I hop[e this is a good start and happy to intake any Feedback. If there is support for this we could move to a working group and scope out more practical and technical details.

[dd45e640b42e6da7da96faee3996ef7c]

"fee paying" ? clients are free to negatively price their deals.

SPs have no business of "owning" datacap by FIP003 design.

[PHABRIC77]

My suggestion is that a fee threshold could be set and a requirement (one of many) to qualify for datacap. The fee threshold would clearly need to be positive to be value accretive for the network (another stipulation above). I know you dislike FIL+ adamantly but I am aware of the issues you and others have expressed and I am trying to help find constructive compromises. I am sure there are a million concerns and reservations about this suggestion so I don’t think you need to work so hard to find one.

[dd45e640b42e6da7da96faee3996ef7c]

i am no friend of it's current implementation - yes. i am not completely against it. it can and should be a useful tool to drive the network forward.

[mjroddy]

As an additional point that I think is worth noting on the above.

The scaling of FIL+ today means the network is increasingly going to be dependent on FIL+ to onboard data, not technically but by the 10x reward incentive.

We are building a system in which it will orientate more and more around FIL+ and the notaries..... is that how we want to build a distributed and 'open' storage platform?

The lack of traction on this discussion is probably more concerning here though.

[The-Wayvy]

I appreciate you putting my thoughts into words so eloquently. And as you say, the lack of traction on this discussion is equally concerning. Is this really not being hotly debated somewhere? Or was there a big debate before Filecoin Plus went live?

[Fatman13]

I propose this for future f+ direction.

[mjroddy]

@dkkapur It's been a busy period for you no doubt. Are we considering redesigning this at all here?

Or does this require a new FIP to change the principles of FIL+?

[The-Wayvy]

Bump

[dkkapur]

Thanks for the bump @The-Wayvy - missed the notif on this.

@mjroddy yes - I think there's an ongoing design to continue evolving the program and ensure it continues to add value to the Filecoin network. Generally speaking proposal changes that impact programs / pathways to getting DataCap, adjustments to notaries/selection process, etc. can be driven though discussions such as this followed by proposals made via issues in this repo. Changes to the definition of the program, the DataCap construct, the notary construct, how it fits into the L1 - all require FIPs.

[dkkapur]

i.e., your suggestion above on

The FIL+ program today has a binary outcome; you get approved, and you earn 10x the rewards or you don’t. It’s not dynamic whereby a specific dataset or use case receives a datacap relative to the potential value that is driven into the network. The above program could function in this way, it is more flexible. (Granted there are technical specs that would need to be discussed here).

which I buy into, could be executed without a FIP by changing the volume of DataCap given (i.e. you only get half of what you requested for lower "value" work), or with a FIP by adding a new multiplier (e.g., proof of retrieval for 1.2x) / or modifying the existing multiplier (e.g., scaling DataCap from 5-20x instead of flat 10x).