SP Geo Distribution Analysis - July/August 2023 - review and discussion toward iteration

[kevzak]

Background: I've recently completed an analysis, looking at the most recent LDN applications from July 10 - August 10, 2023 as a follow-up to a recent process change #922 , which is focused on addressing the issue of proper data geo-distribution with multiple SP entities.

I thought it was worth reviewing after one month to better understand what is happening and potentially iterate as needed on the process based on community feedback.

Overall application statistics:

• 63 LDN applications submitted
• 70% are in the open dataset category with applicants as Data Preparer or Data Owner
• 80+% of those applicants are from China, 99% overall are from Asia
• Also a note: the majority of application are GitHub users using new, different names

Step 1: Requirement of SP information upfront
As part of #922, we implemented a registration form in an effort to require applicants to clearly list the different SP entities they were choosing to work with as part of their application. Applicants were asked to confirm SP IDs, locations and contacts (email at a minimum) in an effort to confirm different entities and locations.

Of those 63 applications:

• 23 (36%) are still on hold waiting for SP information to be submitted or contact from SPs listed
• 11 (17%) were closed, either by applicant or by the bot for no response (likely because they could not meet requirements)
• 29 (46%) have submitted 'required' SP information and have been triggered for notary review (all open datasets)

While I think there is some improvement here at requiring more detail and making applicants document SP distribution (Even showing 11 closed applications is improvement against previous attempts to combat abuse). The reality is that it is still essentially impossible to ensure geo distribution of deal making (by confirming SP entity and locations) using this process.

Step 2: Showing SPs matching the plan
The hope here was that the added action would drive applicants to share a clear distribution plan and, after allocation and deal making, show progress toward the the deals matching the plan.

So far, of the 29 applications triggered for notary review:

• 18 have received 1st allocation of DataCap by notaries.
• And of the 18, so far there are six that have made deals that can be monitored.

You can be the judge if any of these six meet guidelines and good deal making practices

filecoin-project/filecoin-plus-large-datasets#2062 (comment)
filecoin-project/filecoin-plus-large-datasets#2067 (comment)
filecoin-project/filecoin-plus-large-datasets#2060 (comment)
filecoin-project/filecoin-plus-large-datasets#2078 (comment)
filecoin-project/filecoin-plus-large-datasets#2082 (comment)
filecoin-project/filecoin-plus-large-datasets#2084

It is either:

• unknown distribution (no way to know IDs or locations)
• distribution in just one country
• miner IDs taking deals that do not match the miner IDs they said they would use

I do realize that SPs can change, leave or need to be added to an application and I also do believe it takes more than 1-2 allocations to start to see better distribution across SPs.

But in the end, based on the data presented:

• The majority of applicants are unknown (no client reputation)
• The majority of SP IDs are unknown (no SP reputation)
• Most of these SPs are under VPN so we do not know the actual locations. And even if they aren't, most are concentrated in Asia region and there is definitely no geo-distribution of SPs across 3 regions as recommended in the Fil+ guidelines
• Most of the miner IDs used do not match what was listed in their application

Where can we go from here?
For now, we can continue to require applicants to share their plan, we can vet their planned SPs as much as possible upfront and we can ask notaries to perform proper due diligence. But because nothing is actually measurable, this is not sustainable nor scalable and will become the latest way to game the system.

IMO, we need to drive some major changes toward rewarding those applicants with good deal making processes only.

Next Steps
I hope others in the community can review, add ideas and perhaps we can develop a solid collective proposal toward change.

Questions to prompt further discussion:

• Should we focus on clearer requirements for Geo-Distribution instead of the current guidelines? And look toward tooling to help confirm requirements are met? How?
• Should we better vet public open dataset Fil+ applicants (Require KYC)? Start to build client reputations?
• Should we better vet Fil+ eligible SPs (location check, business check)? Make it a requirement for applicants to match with only SPs in a vetted program? Monitor Fil+ SP reputations?
• Should we build tooling to require SP miner IDs to match after 1st/2nd allocation and if not, close the application?
• Or should we not worry about any of this and instead double down on retrievals as a measure of success?

[herrehesse]

Highly appreciated analysis. Any repercussion for clients who say A but then do B?

[kevzak]

Currently no. Would need to be an automated tool/bot to track because notaries would likely continue to sign regardless.

[herrehesse]

That is correct.

[herrehesse]

• Should we focus on clearer requirements for Geo-Distribution instead of the current guidelines? And look toward tooling to help confirm requirements are met?
  Yes. Clearly.

• Should we better vet public open dataset Fil+ applicants (Require KYC)?
  Yes

• Should we better vet SPs? Make it a requirement to match with SPs in a vetted program?
  Yes, but only for FIL+, the rest of the network remains anonymous.

• Should we build tooling to require SP miner IDs to match after 1st/2nd allocation and if not, close the application?
  Yes 100%.

• Should we not worry about any of this and instead double down on retrievals as a measure of success?
  No, retrievals themselves can be faked on all 3 methods. Trusting on them solely would be a mistake.

Adding: Requiring open dataset applicants to provide indexing --> so we can actually check and download the files.

[kernelogic]

Historically (even now) the SPs are centralized in China and the regulations are not friendly towards crypto business. That's why we are seeing this much of secrecy.

[kevzak]

@kernelogic yes, I think you've exposed the core of what we need to consider as part of any change.

Unfortunately, Chinese use cases are not meeting the general best practices of Fil+ and certainly will not meet any of the new requirements we are discussing above.

Then what can be done? What options are there?

[kernelogic]

The strong demand to grow is in there, but no available program that fits the reality. Everything else except Fil+ equals to losing money.

I understand anonymity and permissionless might not be something Fil+ was designed with. But if filecoin wants continuous growth in that region, a (new) program needs to be anonymous, permissionless and importantly, profitable.

[kevzak]

Is there a separate program that could be designed for Chinese market? Like a new tool or pathway?

[herrehesse]

@kernelogic Why isn't anyone discussing the concept of "stagnation"? The ongoing (abusive) growth contributes to the worldwide decrease in revenue and plays a role in the bankruptcy of many SP's globally. It's important to remember that we're currently in a bear market, and persistently pursuing growth whatever the cost, isn't advisable.

[Chris00618]

Admit it or not, filecoin is far from being product-level, and due to a miscalculation of strategy, members were led to believe that the time had come to store high-quality data by the fil+ program. As a result, a large number of SPs had to passively meet this unrealistic expectation, which led to a lot of community friction and problems.

Frankly speaking, filecoin is still in the stage of verifying the ability of storing (not high-quality dataset), If the fil+ program could continue, highly recommended to focus the energy on this real situation ,instead of validating the quality of the datasets and all sorts of stupid KYC.

[kevzak]

Thanks for the input @Chris00618. What is a high-quality dataset exactly? BTW, I don't think I mentioned the word quality once above.

I feel like we are focused on the real situation at hand - how to best ensure applicants who receive DataCap can take any open public dataset, prepare it, store it distributed across regions, and ensure SP make data retrievable.

[kevzak]

The community wants to address abuse, especially the situations where:

• Client = SP = Notary
• Data is being stored with 1 entity in 1 location under VPN,
• Client not storing what they said,
• Client storing different versions of the same CIDs already created
• Data not retrievable

[kevzak]

Fil+ should be a reward to applicants for good deal making. Just because you apply for DataCap doesn't mean you deserve it and not every use case will meet the requirements of Fil+, nor should it.

We need the community to come to some agreements about what requirements we can and should implement. If China needs to have different considerations, what are they?

[raghavrmadya]

Thanks for starting this discussion @kevzak and for the holistic analysis. I think the most important thing we can do in the immediate term is descoping the direct application of LDN by a client and primarily leverage data onboarding tools and programs such as Slingshot and singularity for new clients, moonlanding for SPs etc. and encourage the community to build more open source tools for clients and SPs.

Applying for an LDN as a pathway to get DataCap must stop. Rather, Fil+ should be an underlying machinery on which tools are built to address the many valid challenges you mention above.

If we are going to keep saying that FIL+ is a governance layer and FIL is a governance token, then be it. Until 774 results in a protocol-level change, we should focus on:

1. Slow down onboarding by driving a proposal as a community to cut direct and unlimited access to DataCap. This, in my humble opinion, is not centralization as I think many will claim but a reaction to your analysis above. Only data onboarded through existing tools much be considered eligible for DC. If the community isn't satisfied or willing to use existing tools, PL must support the development of these tools.

2. We, as governance team, should not be doing KYC on SPs.

3. Agree that good deal-making should be a core tenant but not of Fil+ but of the tools built on top of Fil+. I strongly believe that coming up with a broad set of rules that define good deal-making for Fil+ is an ideal, not a reality. But when a program like Slingshot comes with a set of rules that define good deal-making, it narrows the scope and makes defining eligibility and compliance easier to track.

[kernelogic]

I think we can use this opportunity to realign the qualification of Fil+. It was once advised LDN should not be granted to pure ecosystem tools like Singularity, FilSwan or Venus, rather than focusing on useful datasets.

But things always change. While we are anxiously waiting the outcome of 774, it is a good idea to reevaluate the scope of Fil+ and whether to turn it back to include support useful tools and developments.

[raghavrmadya]

Thanks for sharing @kernelogic. I wasn't aware.

[raghavrmadya]

For anyone that might argue that might perceive the above as a proposition for more intermediaries:

In a governance system, we have lobby groups that represent the interest of a diverse set of stakeholders to get a subsidy. We see some of it in Fil+. when we see Web3.storage and Slingshot applying as a "group" representing the interest of its stakeholders.

In web3 systems, DAOs and open-source tools must satisfy this function of a lobby group.

One of the core problems exists at the top of the funnel where the "guardians" (notaries) of the FIL+ subsidy i.e. DC have to deal directly with everyone and anyone coming through the door. The governance team should not be investing in being that filter but rather supporting notaries, human or non-human, to be better guardians. This also means advocating on their behalf for compensation from FF and getting PL to build or fund the aforementioned tools (read lobby groups)

[Chris00618]

@raghavrmadya Glad to see the changes you've made recently, it's a step in the right direction. With some certainty that if Fil+ continues to exist after the voting of 774, this is pretty much the only possible direction Fil+ will land: Low permission + Low and limited triggle volume + More SPs. #928

I hope you can talk to Deep and KevinZ more about your new perceptions. Judging from KevinZ's recent comments and actions, he appears to be moving in the opposite direction: opening up the funnel and calling them quit in the middle is not a smart way and will only create more friction.

Feel free to DM me if you need assistance.

[kevzak]

@Chris00618 what 'recent comments and actions' of mine show I'm moving in opposite direction here?

BTW, I'm the one that created the proposal #922 for new process flow and also opened this discussion after completing the analysis. I'm bringing clear examples of abuse to light here, am I not?

Next Steps:
I hope others in the community can review, add ideas and perhaps we can develop a solid collective proposal toward change.

[Chris00618]

You can correct me, if the person behind @Filplus-govteam wouldn't be you.
Given the discussion(#965) you shut down, I don't see much value or point in having a follow-up discussion with you.

Thanks.

[kevzak]

Following up on this discussion, I have continued to review the most recent 100 open dataset applications and continue to find that even with SP information being manually vetted upfront to ensure clients are meeting deal making requirements:

• the CID report shows that the SPs taking deals do not match the list of SPs provided and that in majority of cases the clients are not meeting Deal Distribution requirements

In an effort to automate this process and also ensure SP Entity, Location and Deal distribution eligibility requirements are met, I am recommending the following upfront application requirements of open dataset clients moving forward:

• All applications to complete a third party KYC check (to confirm they are not a spam bot)
• All applications are required a minimum of 5 SP miner IDs from different SP entities in different locations with the SP miner IDs, Entity names, locations (city, country) required to be disclosed upfront.
• A bot will automatically review the application details, and without all required checks and information, applications will be rejected (not triggered) until information requirements are met.

After, if an application does meet upfront approval requirements and is allocated DataCap, the next check will be:

• If the SP (IDs, entities, locations) provided, do not match the SP (IDs, entities, locations) taking deals per the CID Checker Bot report, the application will be automatically flagged to be closed with DataCap revoked.

It should become clear for clients the importance to realize that they need to better plan and manage partnerships with SPs upfront, confirming the SPs can and will meet the Fil+ storage requirements. Incomplete applications will not be accepted, and SPs that do not match what was claimed will be shutdown.

[mjroddy]

I think a simpler iteration would be to close the LDN until we have better control on how the DC is allocated and how it is currently aligning to the FIL+ rules.

If there is a great need for these datsets to be stored, I'm sure the client would pay for it.

Should we focus on clearer requirements for Geo-Distribution instead of the current guidelines? And look toward tooling to help confirm requirements are met? How?

or potentially automate the deal making so that SP's are not chosen by what looks like other SP's or the same SP (seld-dealing).

Should we better vet public open dataset Fil+ applicants (Require KYC)? Start to build client reputations?

I think this is part the issue. there is no clients here. KYCing a decentralised storage network imo is going in the wrong direction.

Should we better vet Fil+ eligible SPs (location check, business check)? Make it a requirement for applicants to match with only SPs in a vetted program? Monitor Fil+ SP reputations?

This would make sense - this is akin to SP's meeting a certain SLA. Layer 2......

Should we build tooling to require SP miner IDs to match after 1st/2nd allocation and if not, close the application?

if the rule is to match, I imagine you'll find that miraculously they'll start to match. the incentive is driving the outcome.

Or should we not worry about any of this and instead double down on retrievals as a measure of success?

Retrievals are incredbly important. we have to evolve the network and make it 'useful'... I'm too far from saturn to understand the needs for this.

Thanks for the analysis on above