search

filecoin-project / Allocator-Governance

7 stars 34 forks source link

Community Diligence Review of EF Allocator #12

Closed filecoin-watchdog closed 4 months ago

filecoin-watchdog commented 5 months ago

Review of Top Value Allocations from @Lind111 Allocator Application: https://github.com/filecoin-project/notary-governance/issues/1056

First example: DataCap was given to: https://github.com/Lind111/EF/issues/4

1st point) 1PiB of datacap was given to the client. The allocator stated in their application they would give 50% of weekly reqeusted as a first allocation. The allocator claimed it was a mistake and asked for DataCap to be removed. tbd @galen-mcandrew can determine further.

Looks like over 300TiBs was used in deals: https://check.allocator.tech/report/Lind111/EF/issues/4/1715341620822.md

Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals f02237006 | Singapore, Singapore, SGAlibaba (US) Technology Co., Ltd. | 194.25 TiB | 51.83% | 194.25 TiB | 0.00% f02816666 | Beijing, Beijing, CNHangzhou Alibaba Advertising Co.,Ltd. | 64.00 GiB | 0.02% | 64.00 GiB | 0.00% f01128206 | Hong Kong, Hong Kong, HKHK Kwaifong Group Limited | 17.78 TiB | 4.74% | 17.78 TiB | 0.00% f03034045new | Tokyo, Tokyo, JPMULTACOM CORPORATION | 448.00 GiB | 0.12% | 448.00 GiB | 0.00% f02215209 | Los Angeles, California, USNetLab Global | 161.84 TiB | 43.18% | 161.84 TiB | 0.00% f02519100new | Hong Kong, Hong Kong, HKOneAsia Network Limited | 448.00 GiB | 0.12% | 448.00 GiB | 0.00%

filecoin-watchdog commented 5 months ago

Second example: DataCap was given to: https://github.com/Lind111/EF/issues/9

1st point) Allocation schedule distribution stated according to existing rules: 5% of the first DataCap total, or 50% of the weekly allocation rate, whichever is lower Second 10% of total DataCap or 100% of weekly allocation rate, whichever is less Third 20% of total DataCap or 200% of the weekly allocation rate, whichever is less Fourth 40% of total DataCap or 400% of the weekly allocation rate, whichever is less Overall cap of 8P for a single client for a single application

The allocations were: 400TiB, 800TiB, 1600TiB

2nd point) The allocator appears to have completed KYC or KYB of client or dataset via email screen shots in the application.

3rd point) Client said these were the SPs to be used. f02770938 guan South Korea f02820008 zhangx Hong Kong f02237010 Li Tokyo f02093396 Lingchao Xu Singapore f02259777 Lingchao Xu Singapore f01888808 郑建林 Romania

Actual data storage report: https://check.allocator.tech/report/Lind111/EF/issues/9/1715343692720.md

Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals f02814682new | Shenzhen, Guangdong, CNCHINANET-BACKBONE | 352.00 GiB | 0.22% | 352.00 GiB | 0.00% f02816666 | Beijing, Beijing, CNHangzhou Alibaba Advertising Co.,Ltd. | 288.00 GiB | 0.18% | 288.00 GiB | 0.00% f02820008 | Hong Kong, Hong Kong, HKHUAWEI CLOUDS | 448.00 GiB | 0.28% | 448.00 GiB | 0.00% f02237010 | Tokyo, Tokyo, JPNearoute Limited | 192.00 GiB | 0.12% | 192.00 GiB | 0.00% f02215209 | Los Angeles, California, USNetLab Global | 108.25 TiB | 68.26% | 108.25 TiB | 0.00% f02062851 | Los Angeles, California, USNetLab Global | 48.59 TiB | 30.64% | 48.59 TiB | 0.00% f02770938 | Hong Kong, Hong Kong, HKOneAsia Network Limited | 512.00 GiB | 0.32% | 512.00 GiB | 0.00%

Two SP IDs taking deals matches per report. One had a different location listed. All others were not reported and with unknown details. More diligence is needed to confirm entity and location

3rd point) 5 allocations awarded to this client. However, per Spark dashboard, all SPs are either not available or have 0% retrievability.

The Allocator showed no sign of diligence after 1st allocation and gave the 2nd, 3rd, 4th , 5th allocation of 2800 TiB to the client.

filecoin-watchdog commented 5 months ago

Interesting notes: Many SPs are the same across the different allocator applications. All without retrievability.

Lind111 commented 5 months ago

Some SPs were recommended to them from my side, but due to the arrest of the STFIL organization to the Chinese police, it may have caused irreparable losses

Kevin-FF-USA commented 4 months ago

Hi @Lind111

On the next Fil+ Allocator meeting we will be going over each refill application. Wanted to ensure you were tracking the review discussion taking place in https://github.com/filecoin-project/Allocator-Governance/issues/12.

If your schedule allows, recommend coming to the May 28th meeting to answer/discuss the issues raised in the recent distributions. This will allow you to faster address - or, the issue in Allocator Governance for ongoing written discussion.

Warmly, -Kevin https://calendar.google.com/calendar/embed?src=c_k1gkfoom17g0j8c6bam6uf43j0%40group.calendar.google.com&ctz=America%2FLos_Angeles

Lind111 commented 4 months ago

Allow me to borrow Mike's comment here, my situation is similar to his

The problem of 0% retrieval is due to the STFIL team SP no one to maintain, resulting in data loss, there is another reason is that the Spark team currently no clear documentation, resulting in a lot of SP do not understand how to configure and adapted to Spark, I have already seen a team to work with Spark to deal with this, I believe there will soon be a result! https://filecoinproject.slack.com/archives/C06MTBZ44P2/p1717139259611159 https://filecoinproject.slack.com/archives/C06MTBZ44P2/p1717149275892449

The Allocator showed no sign of diligence after 1st allocation and gave the 2nd, 3rd, 4th , 5th allocation of 2800 TiB to the client.

Regarding this issue, before each signature, I review part of the information content, please check the following comments Second https://github.com/Lind111/EF/issues/9#issuecomment-2031169041 https://github.com/Lind111/EF/issues/9#issuecomment-2031211929 Third https://github.com/Lind111/EF/issues/9#issuecomment-2041116693 https://github.com/Lind111/EF/issues/9#issuecomment-2041280325

And I only assigned it three times, not a fourth and fifth time

galen-mcandrew commented 4 months ago

Based on a further diligence review, this allocator pathway is partially in compliance with their application.

Specifically:

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.

@Lind111 can you verify that you will enforce program and allocator requirements? (for example: public diligence, tranche schedules, and public scale retrievability like Spark). Please reply here with acknowledgement and any additional details for our review.

Lind111 commented 4 months ago

@Lind111 can you verify that you will enforce program and allocator requirements? (for example: public diligence, tranche schedules, and public scale retrievability like Spark). Please reply here with acknowledgement and any additional details for our review.

Please check the previous comment This is my newest client, please review and point out any problems, thanks! https://github.com/Lind111/EF/issues/14

Thank you. @galen-mcandrew

Lind111 commented 3 months ago

The datacap of 2.5PiB issued last time has been used for more than 2PiB, please review again and leave a comment if more questions, thanks! @galen-mcandrew @Kevin-FF-USA