Community Diligence Review of DCENT - NC Allocator

[filecoin-watchdog]

Review of DCENT - NC Allocations from @cryptowizzard Allocator Application: https://github.com/filecoin-project/notary-governance/issues/1058

First example: DataCap was given to: https://github.com/cryptowhizzard/Fil-A-2/issues/1

Public Open Dataset - key compliance requirement: Retrievability

1st point) Allocation schedule per allocator: • First: 10% • Second: 20% • Third: 35% • Fourth: 35% • Max per client overall: 100%.

Actual allocation: 250TiBTib, 500TiB, 1PiB - this follows the guidelines

2nd point) SPs provided by client do not include any details of miner IDs. Dcent, The Netherlands 1 replica , Sealed + Unsealed / Hotcopy. Holon Australia, Melbourne 2 replica's , One only sealed and one with Unsealed / Hotcopy, starting after summer 2024. DSS Australis, Sydney 2 replicas ( Just sealed ). RMM Global, China, 2 replica ( Just sealed ).

Allocator made an updated comment about storage plan: https://github.com/cryptowhizzard/Fil-A-2/issues/1#issuecomment-2111756576 Until now focus has been on lead SP ( Bits and bytes ) to store the unsealed and sealed copy of first replica and have everything retrievable. RMM is only storing the sealed replica for security and backup.

https://check.allocator.tech/report/cryptowhizzard/Fil-A-2/issues/1/1715954303706.md

Actual SPs taking deals Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals f03063130new | Portland, Oregon, USFlexential Colorado Corp. | 556.94 TiB | 31.62% | 555.97 TiB | 0.17% f03079759new | Portland, Oregon, USFlexential Colorado Corp. | 345.19 TiB | 19.60% | 345.19 TiB | 0.00% f03064136new | Heerhugowaard, North Holland, NLWijnand Schouten | 556.41 TiB | 31.59% | 554.22 TiB | 0.39% f02982293 | Heerhugowaard, North Holland, NLWijnand Schouten | 211.03 TiB | 11.98% | 210.50 TiB | 0.25% f02366527 | Heerhugowaard, North Holland, NLWijnand Schouten | 91.88 TiB | 5.22% | 90.47 TiB | 1.53%

3rd point) Second, third allocations awarded to this client. However, per Spark dashboard, one SP is showing acceptable level of retrieval

The other SPs are not available

The allocator mentions "Yes, we will require preliminary SP distribution plans and equal distribution" in their application but they are only storing copies with themselves? Overall, it's currently unclear who is storing what (miner IDs, entities) to confirm the plan matches the action. It looks like Allocator to Client to SP all the same. We'd ask the allocator to clarify the plan and SPs involved

[cryptowhizzard]

Hello,

Point 1: correct

Point 2: correct. Should miners/SP’s be grouped per organisation in the github? If so, that is not a problem.

point3: this is not correct. For example All dcent machines are retrievable. Spark is behind and has not learned new machines as it seems. Secondly we have also allocated to other orgs ( Twinquasar / Trtion ). Partners mentioned like Holon and DSS will start soon. There are contract agreements with them and we can provide them for due diligence if needed.

[filecoin-watchdog]

Thank you for clarifying.

Yes, listing miner IDs, entities, locations has become standard practice for applications. It will help with confirmation that you are distributing the DataCap as you said.

[Kevin-FF-USA]

Hi @cryptowizzard

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

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

[cryptowhizzard]

Hi @Kevin-FF-USA @filecoin-watchdog

That's OK.

I have updated the applications as requested with MinerID's. The retrieval issue's are tracked with the SPARK team and should be resolved soon. The screenshot on the cause / resolving of the retrieval issue has been posted on Slack.

[galen-mcandrew]

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

We are requesting 10PiB of DataCap from RKH for this pathway to increase runway and scale.

@cryptowhizzard: Please reply if there are any issues, concerns, or updates while we initiate the request to the RKH.