search

filecoin-project / Allocator-Governance

7 stars 35 forks source link

Community Diligence Review of Blockchain World FIL+ DC Allocator #17

Closed filecoin-watchdog closed 4 months ago

filecoin-watchdog commented 6 months ago

Review of Blockchain World FIL+ DC Allocations from @psh0691 Allocator Application: https://github.com/filecoin-project/notary-governance/issues/1004

First example: DataCap was given to: https://github.com/Blockchain-World-News/FIL-DC-Allocator/issues/3

Public Open Dataset - key compliance requirement: Retrievability

1st point) Allocation schedule per allocator: First allocation: lesser of 5% of total DataCap requested or 50% of weekly allocation rate • Second allocation: lesser of 10% of total DataCap requested or 100% of weekly allocation rate • Third allocation: lesser of 20% of total DataCap request or 200% of weekly allocation rate • Fourth allocation: lesser of 40% of total DataCap requested or 400% of weekly allocation rate • Max per client overall: lesser of 80% of total DataCap request or 800% of weekly allocation rate

Actual allocation: 400Tib, 800TiB - this follows the guidelines

2nd point) SPs provided by client do not include any details of entity, no diligence from Allocator. f02853198, South America f01904546, South Korea f01697248, South Korea f02846602, USA f01945089, USA

https://check.allocator.tech/report/Blockchain-World-News/FIL-DC-Allocator/issues/3/1715952293948.md

Actual SPs taking deals

Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals f02846602 | Los Serranos, California, USFrontier Communications of America, Inc. | 60.16 TiB | 12.37% | 60.16 TiB | 0.00% f01697248 | Ansan-si, Gyeonggi-do, KRKorea Telecom | 214.07 TiB | 44.02% | 214.07 TiB | 0.00% f01904546 | Ansan-si, Gyeonggi-do, KRKorea Telecom | 212.13 TiB | 43.62% | 212.13 TiB | 0.00%

SP IDs match - Korean SPs sealing 90% of Data so far.

3rd point) Second allocation awarded to this client. However, per Spark dashboard, two Korean SPs are showing low retrievability. image 3rd SP not available.

The Allocator showed no sign of retrieval diligence after 1st allocation and gave the 2nd allocation of 800TiBs to the client.

filecoin-watchdog commented 6 months ago

Second Example: DataCap was given to: https://github.com/Blockchain-World-News/FIL-DC-Allocator/issues/5

Public Open Dataset - key compliance requirement: Retrievability

1st point) Allocation schedule per allocator: First allocation: lesser of 5% of total DataCap requested or 50% of weekly allocation rate • Second allocation: lesser of 10% of total DataCap requested or 100% of weekly allocation rate • Third allocation: lesser of 20% of total DataCap request or 200% of weekly allocation rate • Fourth allocation: lesser of 40% of total DataCap requested or 400% of weekly allocation rate • Max per client overall: lesser of 80% of total DataCap request or 800% of weekly allocation rate

Client requested 250TiB per week - Actual allocation: 50Tib, 250Tib, 500TiB, 1PiB, 1PiB, 1PiB - this follows the allocator guidelines

2nd point) SPs provided by client do not include any details of entity, no diligence from Allocator. f02951064, ZheJiang-JinHua f02984282, HeNan-ZhengZhou f0122215, ShanDong-QingDao f0427989, ShanDong-QingDao f02942808, GuangDong-ShenZhen f02894875, JiangXi-FuZhou

https://check.allocator.tech/report/Blockchain-World-News/FIL-DC-Allocator/issues/5/1715953230984.md

Actual SPs taking deals Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals f02824216 | Shanghai, Shanghai, CNChina Mobile communications corporation | 99.47 TiB | 5.88% | 99.47 TiB | 0.00% f02984282 | Zhengzhou, Henan, CNChina Mobile Communications Group Co., Ltd. | 9.38 TiB | 0.55% | 9.38 TiB | 0.00% f03035656 | Nanchang, Jiangxi, CNCHINA UNICOM China169 Backbone | 327.78 TiB | 19.36% | 327.78 TiB | 0.00% f02894875 | Nanchang, Jiangxi, CNCHINA UNICOM China169 Backbone | 265.34 TiB | 15.67% | 265.34 TiB | 0.00% f0427989 | Qingdao, Shandong, CNCHINA UNICOM China169 Backbone | 77.97 TiB | 4.61% | 77.97 TiB | 0.00% f02200472 | Chengdu, Sichuan, CNCHINANET SiChuan Telecom Internet Data Center | 93.56 TiB | 5.53% | 93.56 TiB | 0.00% f02942808 | Jiangmen, Guangdong, CNCHINANET-BACKBONE | 175.78 TiB | 10.38% | 175.78 TiB | 0.00% f02951064 | Hangzhou, Zhejiang, CNJINHUA, ZHEJIANG Province, P.R.China. | 17.84 TiB | 1.05% | 17.84 TiB | 0.00% f03068013new | Hong Kong, Hong Kong, HKPCCW Global, Inc. | 205.94 TiB | 12.16% | 205.94 TiB | 0.00% f01025366 | Qingdao, Shandong, CNQingdao, Shandong Province, P.R.China. | 62.47 TiB | 3.69% | 62.47 TiB | 0.00% f03074163 | Hong Kong, Hong Kong, HKSkyExchange Internet Access | 127.72 TiB | 7.54% | 127.72 TiB | 0.00% f02951213 | Singapore, Singapore, SGStarHub Ltd | 229.81 TiB | 13.57% | 229.81 TiB | 0.00%

3rd point) 5 allocations awarded to this client. However, per Spark dashboard, one SP shows low retrieval, all others are 0 or unavailable. image

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

Kevin-FF-USA commented 5 months ago

Hi @psh0691

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/17.

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

image

galen-mcandrew commented 5 months ago

Based on an additional compliance review, it appears this allocator is attempting to work with public open dataset clients.

However, the data associated with this pathway is not currently able to be retrieved at scale, and testing for retrieval is currently noncompliant.

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.

Before we will submit a request for more DataCap to this allocator, please verify that you will instruct, support, and require your clients to work with retrievable storage providers.

@psh0691 can you verify that you will enforce retrievability requirements, such as through Spark? Please reply here with acknowledgement and any additional details for our review.

psh0691 commented 5 months ago

@galen-mcandrew I'm sorry for the concern. Let me emphasize once again the compliance of the DC application client. I will ask the client to enable data retrieval. I will also direct, support, and require you to work with searchable storage providers.

amughal commented 5 months ago

Hello @psh0691 @galen-mcandrew

Please see below the actual SPs taking deals:

SP details: Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals Azher Mughal | azheramin@gmail.com | Mongo2Stor | CA, US | No | mongo

Contact name | SP Business Email | SP Organization Name | Region | Using VPN? | Slack handle Henry Moon | contact@simpleipfs.com | Simple IPFS Inc. | South Korea | No | hyunmoon

I was hoping that one in the SouthAmerica (Argentina) will start the deals since last few months, however that is still pending. I can provide you their Slack handles if you want to verify.

The two SPs in Korea have balanced deals across each of them.

I'm not sure why retrievals are showing low, but feel free to reach to out Henry for any clarification. Last I checked with him (today), he confirmed that retrievals are active on both SPs.

Please let me know what other questions you have?

Thank you.

hyunmoon commented 5 months ago

The Spark public stats page is providing limited information. Could you please check the error logs on the retrieval bot? Specifically, I would like to know which CIDs have been requested and how they failed.

amughal commented 4 months ago

Thank you for marking this as Completed.

hyunmoon commented 4 months ago

It turned out that the low retrieval score was due to the boost indexer being incorrectly set. I didn’t realize I needed to open a specific port for it to correctly announce to IPNI.

Details here: https://filecoinproject.slack.com/archives/C03CKDLEWG1/p1719418630838109

Additionally, I would like to point out that the Spark dashboard score measures the entire active deals of a miner. In my case, the deals received under the supervision of the current allocator (v5 notary) represent only a fraction of my total deals. Therefore, it is unfair to determine my retrieval performance for the allocator based solely on the Spark dashboard score.

More information here: https://filecoinproject.slack.com/archives/C015G3B5RQE/p1719400518953959?thread_ts=1718004264.967309&channel=C015G3B5RQE&message_ts=1719400518.953959