Community Review of Caro Allocator

[filecoin-watchdog]

Allocator report: https://compliance.allocator.tech/report/f03018489/1723593794/report.md

First example:
Carohere/Caro-Allocator#1

• 1PiB given to a brand new Github ID on first allocation - no sign of KYC
• https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/1/1723735227529.md
• 586TiB given to one SP ID - Not available for retrievals
• sitting on 400TIB

Second example:

• [DataCap Application] NOAA Geostationary Operational Environmental Satellites Carohere/Caro-Allocator#3
• 500TiB given to brand new GitHuB ID - no sign of KYC
• https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/3/1723735337786.md
• 1.6TiB total given - sitting on 974TiBs

One SP f03089826 has 98% retrieval - all others unavailable or 0% on Spark Dashboard

Third Example:
Carohere/Caro-Allocator#6
https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/6/1723735303166.md
Given 200TiBs

Fourth Example:
Carohere/Caro-Allocator#8
Given 500TiBs
https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/8/1723735306874.md
Same SPs used on 3rd and 4th example - retrieval varies

Fifth Example:
Carohere/Caro-Allocator#14
Given 1.5PiBs over two allocations
https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/14/1723735362095.md
retrieval varies

[filecoin-watchdog]

Allocator claims to serve Europe - but all clients and SPs are US or Asia based.

SPs used are not the same as originals provided in applications (flag)

KYC is questionable vs what allocator said they would do and for amount of Datacap given to brand new IDs

allocation amounts not followed per allocator guidelines. Currently many clients sitting on large amounts of DataCap.

Retrievals are low.

I'd ask gov team to review the above observations.

Also, there is no clear explanations on data preparation - I'd advise this allocator to gain better information from clients regarding newly proposed questions that should be standard for all public open data clients. #125

[Carohere]

Hello @filecoin-watchdog, I would like to give an explanation of above.

• Indeed, in my application, I described the region(s) of operation as follows. I welcome applicants from all locations.

5. Region(s) of operation:
   Europe, Africa , Asia minus GCR, Greater China, Oceania, Japan, North America, South America, Other

• About SPs are not the same as their list

I asked them for the latest sp list in the application & I saw that they have already updated it.
Carohere/Caro-Allocator#14 (comment)
Carohere/Caro-Allocator#8 (comment)
Carohere/Caro-Allocator#6 (comment)
Carohere/Caro-Allocator#3 (comment)

• For reviewing client, I use DM and Q&A on the application.

• Regarding retrieval, I have made requests to clients and communicated with the spark team to make an active contribution to successful retrieval.

As clients said that some SPs have stoped their cooperation so that some nodes do not support retrieval any more. It may influence the results of the report this time.

• On data preparation, the client briefly described how the data was prepared in the application, and I think their answers are reasonable.

For the next step I'm willing to be more meticulous about each part of the review to make the datacap allocations more suitable.

[filecoin-watchdog]

Thank you for replying @Carohere. The gov team can take all the information into consideration.

And just for clarity regarding where you are and where you serve: I was referring to the top section of your application filecoin-project/notary-governance#1064

What region will you serve? Europe

The question further down stating regions of operations and listing all regions of the world is a default answer for all applications.

There are already 60+ APAC manual allocators, but you are free to serve any areas you wish.

[Carohere]

@filecoin-watchdog Thank you.

[galen-mcandrew]

Reviewing the above details, we are seeing compliance issues. Specifically:

• Low and inconsistent retrieval of public open datasets
• High usage of VPNs without enforcing stated requirements from allocator application (question 28 "detailed KYB check reports on those SP"
• Noncompliant SP distribution (Data Distribution section of application, question 23), with continued subsequent allocations (such as https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/14/1723735362095.md)
• Noncompliant DataCap tranche allocations (1PiB to new client address)
• Mixed KYC diligence into client claims, such as clients making conflicting region claims and lacking KYC checks in GitHub (especially these two NOAA data preparers [DataCap Application] National Blend of Models Carohere/Caro-Allocator#1 & [DataCap Application] NOAA Geostationary Operational Environmental Satellites Carohere/Caro-Allocator#3)

As a reminder, the allocator team is responsible for verifying, supporting, and intervening with their clients. If a client is NOT providing accurate deal-making info (such as incomplete or inaccurate SP details) or making deals with noncompliant unretrievable SPs, then the allocator needs to intervene and require client updates before more DataCap should be awarded.

Given this mixed review, we are requesting that the allocator verify that they will uphold all aspects & requirements of their initial application. If so, we will request an additional 2.5PiB of DataCap from RKH, to allow this allocator to show increased diligence and alignment.

Please verify that you will instruct, support, and require your clients to work with retrievable storage providers. @Carohere can you verify that you will enforce retrieval requirements, such as through Spark?

[Carohere]

@galen-mcandrew Thanks for your review.

• We have been working on asking clients to improve successful retrieval rate and communicating with the spark team about it. Because

As clients said that some SPs have stoped their cooperation so that some nodes do not support retrieval any more. It may influence the results of the report this time.

This should be a reason for the low success rate of some sp retrievals. I've noticed, however, that the rate of successful retrieval of SPs that clients work with has been improving since then. I will ask my clients to improve the rate of successful retrieval or change the sps in time for future work.

• By doing my check on the sps' ip addresses, I didn't find that the sps are using VPN, can you please tell me how to recognize that they are using VPN?

• In your example

(such as https://check.allocator.tech/report/Carohere/Caro-Allocator/issues/14/1723735362095.md)

I see that the client has distributed to 6 sps, which is matching the requirement in my notary application that the client should distribute at least 3 sps. Please verify this.

• The reason for the one-time allocation of 1p to the first client who requested it from me was that I saw one copy of client's data was more than 1p. I thought it was necessary to allocate at least 1p to this client to enable him to store at least one copy of the dataset first. This is also due to my lack of experience and I will think carefully in my future allocations.

• [DataCap Application] National Blend of Models Carohere/Caro-Allocator#1 & [DataCap Application] NOAA Geostationary Operational Environmental Satellites Carohere/Caro-Allocator#3
  KYC of the two applications have been updated on their applications.

Carohere/Caro-Allocator#1 (comment)
Carohere/Caro-Allocator#3 (comment)

• It was me who did not show KYC records on github in time, but only kept it in slack DM, which stems from my lack of experience. For other following applications I have kept communicating records with clients on the github. I'll keep updating these information on github in more timely way in the future.

Given my explanation, can I be granted 5PiB datacap this time?

I will instruct, support, and require your clients to work with retrievable sps. And I will enforce clients to meet spark retrieval requirements further.

[galen-mcandrew]

Regarding VPNs, we are still working on tooling and investigation methods, so we would love to collaborate.

For my investigations at this time, I utilize the information in the CID checker report for a client, which shows the SP location and ISP (such as the screenshot below). I then search that ISP (some of which I know and recognize by name, so that's easier). A web search of the ISP can indicate if they are providing VPN or VPS services, but it is not always fully accurate.

Where are you finding the IP4 address for each minerID? Is that information provided to you directly by the client, or publicly from another report/dashboard/explorer?

It could be great to improve the CID checker bot to have an assessment rating or likelihood for VPN usage next to each SP.

Regarding distribution, such as here, this report is showing data distribution to only a small set of regions within HK and CN, but not across 3 geopolitical regions.

@Carohere looking forward to your reply about these two questions, and the Governance team can review this allocation request.

[Carohere]

Thank you @galen-mcandrew . Your reply was very helpful to me.

I'm using Filfox to check the ip of the sp. As an example, f03157879, I was able to find the ip address of the sp on the website.

Then I checked the geolocation of this ip at https://www.ip-score.com/ and learned that this node is located in the US.

I compared the ip addresses I found with the sp list provided by the client.

After the comparison is consistent, I'll reconfirm with the client that the sp has a machine in this IDC. Having gotten an positive answer, I thought that this sp could be considered as not using VPN.

My expectation for the client is to provide at least 5 replicas, distributed in at least 3 regions. I feel that this client meets the basic demands of my allocator pathway.

I will, however, check the client's distribution meticulously and ask the client to be able to provide a more diversified data distribution to match Fil+ goals in the next step.

Expect the response from Governance team!

[Carohere]

@galen-mcandrew Hi Galen, waiting for your reply.

[galen-mcandrew]

Thank you for the additional details, and info about how you are looking up SP IP addresses. Given additional review, we are requesting 5PiB of DataCap from RKH.

[Carohere]

@galen-mcandrew Thank you for your reply!