2nd Community Diligence Review of ND-CLOUD Allocator

[NDLABS-Leo]

Community Diligence Review of ND-CLOUD Allocator

Allocator Report: https://compliance.allocator.tech/report/f03012741/1725495808/report.md

Allocator received 7.5PiBs additional allocation.
This round of review is the second round of 2PiBs allocations.

DataCap awarded to:
2PiBs：NDLABS-Leo/Allocator-Pathway-ND-CLOUD#15

In allocating the most recent 2P credits, here is a record of our review:

1. require customers to provide proof of kyb and disclose the
   

2.Retrieve test on the customer's node through self-research tool (because according to our understanding, the customer's node is compatible with SPARK if using BOOST, and some are not compatible if it is MARKET, so we use the self-research tool as an aid)

[filecoin-watchdog]

First Community Diligence Review #13

[filecoin-watchdog]

2nd round of DataCap awarded to one client:
2PiBs：NDLABS-Leo/Allocator-Pathway-ND-CLOUD#15

https://check.allocator.tech/report/NDLABS-Leo/Allocator-Pathway-ND-CLOUD/issues/15/1723729695836.md

6 Miner IDs added since first review - looks like 4-5 SPs

Distribution of deals seen across 10 IDs

[NDLABS-Leo]

@filecoin-watchdog
Thanks for checking it out!

[Kevin-FF-USA]

Bringing forward the discussion from issue #128 into this thread for single tracking.

[NDLABS-Leo]

@Kevin-FF-USA
Sorry, but what is the reason for putting the ND and opengate ones in a group? These are two different organisations altogether.

[galen-mcandrew]

I think there is some confusion here, since your opening issue read as "Community Diligence Review of Opengate Allocator". Additionally you linked to Allocator Report: https://compliance.allocator.tech/report/f03019921/1723594234/report.md which is the same address as the OpenGate team.

[galen-mcandrew]

@NDLABS-Leo my understanding is that ND labs has two allocator pathways:

1. 1025 Enterprise data - HK CyberPort pathway Open compliance report 109 Address: f03012747
2. 1026 ND CLOUD With this open compliance review, Address: f03012741

https://compliance.allocator.tech/report/f03012741/1725409564/report.md

[NDLABS-Leo]

I think there is some confusion here, since your opening issue read as "Community Diligence Review of Opengate Allocator". Additionally you linked to Allocator Report: https://compliance.allocator.tech/report/f03019921/1723594234/report.md which is the same address as the OpenGate team.

@galen-mcandrew @Kevin-FF-USA
Sorry, this is my problem as we submitted this ourselves, we were looking for a better template before we submitted it and copied the content of the ‘Opengate Allocator’, which I have reworked, apologies again for the problem.

[NDLABS-Leo]

@NDLABS-Leo my understanding is that ND labs has two allocator pathways:

1. 1025 Enterprise data - HK CyberPort pathway Open compliance report 109 Address: f03012747
2. 1026 ND CLOUD With this open compliance review, Address: f03012741

https://compliance.allocator.tech/report/f03012741/1725409564/report.md

@galen-mcandrew
Yes, you are absolutely right.

[galen-mcandrew]

Flagging and pausing this compliance review, given some confusing details that need to be addressed.

This pathway has worked exclusively with a single client since the previous review, AINN. There is some evidence of KYB verification through email correspondence, as well as allocator claims of independently retrieving and sampling the data. This client claims to have private encrypted unretrievable data, and according to the existing testing that data is indeed not able to be retrieved. There is no clear evidence of program compliance or quality data however. For example, if this is private encrypted enterprise data, there should be some additional evidence of on-chain deal pricing or other indicators of "high quality onboarding that benefits the network."

But even more concerning, this client is also duplicated across your other allocator pathway, with what appears to be an identical application. In addition to that, the client is not working with a compliant set of SPs, according to the allocator's Data Distribution requirements, especially in regards to regional distribution.

@NDLABS-Leo Given the issues uncovered in this investigation, we need to see a clear and concise explanation of the difference between these two allocator pathways, as well as some explanation of these non-compliant client interactions.

Please provide any additional evidence and diligence for our review regarding the above issues.

[NDLABS-Leo]

@galen-mcandrew @Kevin-FF-USA

Thank you for flagging this and giving us time to explain.

1. Regarding collaboration with individual clients:
   We have closed applications that do not fit our channel, which helps us manage our applications better. Additionally, because AINN has a large data volume, we had in-depth discussions about their project back in March. Our supplemental quota was only 2.5P, and after it was exhausted, we did not promote it externally. If we supplement the quota again, we will find ways to promote it, allowing more compliant clients to participate.
   
   

2. Proof of data quality:
   During the first round of the client’s quota distribution, we required them to undergo data storage testing. We downloaded and sampled the data, and after verifying that the data content matched the client’s description, we proceeded with the distribution.
   
   

3. Regarding the client's SP location requirements:
   The client is currently using 10 nodes, primarily distributed across HK/KR/CN Guangdong Shenzhen/CN Sichuan Chengdu. We believe this meets the requirements for different regions. We also reviewed the operators of the nodes; there are five types of operators. Additionally, the client plans to add more nodes in future projects.
   

4. Regarding differences between distributor pathways:
   NDCloud is a public cloud aggregation platform, and the clients we aggregate to the public cloud have real and substantial data storage needs. When clients use NDCloud’s public cloud aggregation platform, those with storage needs can apply through NDCloud. Typically, they are web2 and web3 enterprise data owners.

Enterprise data - HK Cyberport pathway is primarily an application channel for incubating, accelerating, and investing in web3.0 startups. Cyberport is an innovative digital community with nearly 900 digital technology companies, managed by the Hong Kong Cyberport Management Company Limited, which is wholly owned by the Government of the Hong Kong Special Administrative Region. This channel is mainly for clients that have passed Cyberport’s selection process.

[NDLABS-Leo]

@galen-mcandrew @Kevin-FF-USA

During the period when this review request was flagged and paused, we held a Zoom meeting with Galen. He described in detail some of his questions and concerns about our channel at the meeting, and we responded to his concerns. The online conversation not only did it help us to better understand the responsibilities of being an allocator and recognize areas where we had previously fallen short, but it also gave us a clear plan for future work. Therefore, in order to uphold the principles of openness and fairness, we disclose this publicly here.
Below is some content for the reviewers and community members, along with our records as an allocator:

1. The identity of the ND-CLOUD Allocator
NDCloud is a public cloud aggregation platform, and the clients we aggregate to the public cloud have real and substantial data storage needs. When clients use NDCloud’s public cloud aggregation platform, those with storage needs can apply through NDCloud. Typically, they are web2 and web3 enterprise data owners.
The image shows the introduction to ND-CLOUD’s product services and its partnered cloud services:

2. Source of Clients
Regarding obtaining real clients: NDCloud and NDLabs belong to the same group, but their departments and business lines do not overlap. NDLabs acts as a channel manager to connect NDCloud with their clients and match those clients with SPs. One of the promoting strategies for NDCloud is that they provide decentralized storage datacap to their clients as an incentive. We believe that this strategy not only gives ND CLOUD a competitive edge over other traditional cloud service providers but also helps filter clients with genuine storage needs, while offering them a free storage service incentive. It’s a win-win-win situation.
KYB process within this allocator: When clients have already purchased or are willing to purchase NDCloud services, they archive their information with ND CLOUD’s sales department. They also receive the path address for applying to the ND-CLOUD Allocator. We verify the application information against the archived client data in their sales department, and we also confirm with applicants via email, requesting them to provide their identity proof, typically in the form of a business license.

Clients applied through my pathway from NDCloud so far: AOLIGEI, HETPA, AINN, these clients are currently using cloud services recommended by NDCloud as an intermediary. Their service contract are not allowed to be public due to the Confidentiality Agreement. However, if there is a need for proof of their business cooperation, we will allow those clients and representatives from NDCloud to clarify.

3. SP Identity
Same SP nodes for two Allocators: The reason for this issue is that many storage clients may not fully understand or be familiar with the SP system. As members of the SP working group for the China region, we recommend SPs to clients, so it is possible that different clients may end up using the same SP nodes.
SP ownership: Regarding the issue of SP ownership, we are working on making node information and ownership more transparent. However, due to current policies and other factors, full transparency is not yet possible. We are actively discussing with official members from FF on how to advance this matter, and I will elaborate further in section five.
Geographic distribution of SP nodes: In terms of geographic distribution, our current review principle is that clients may start with fewer than four regions during the project’s initial phase. However, as the project progresses, clients must have more than four regions; otherwise, further allocation will not be allowed.
Investigation into VPN use by nodes: There is currently no robust tool for conducting such reviews. We mainly rely on IP checks and the geographic location disclosed by the nodes to verify if VPNs are being used to change virtual addresses.

Hepta：NDLABS-Leo/Allocator-Pathway-ND-CLOUD#13 During the review process, the allocation tranches were issued only when bot reports showed compliance, and allocation were not issued when bot reports were found to be faulty.

Aoligei：NDLABS-Leo/Allocator-Pathway-ND-CLOUD#11 The review process found that one of its ip unknowns was unclear and raised questions. No further allocations were issued when it was found that there was data sharing.

AINN：NDLABS-Leo/Allocator-Pathway-ND-CLOUD#15 The client's kyb was reviewed and the client was challenged when low retrieval rates were found, consideration was given to the use of ND's retrieval tool as an assisted review at the time when sp was generally not connected to spark, and no further allocation was issued until the client's adjustments were fully completed.

4. Allocation Review Process
In past allocation distributions, we have followed three key guidelines and will continue to do so in the future. We disclose them here:

Increase in the number of nodes: In the first round, we required clients to have at least 3–4 nodes, and in subsequent rounds, this must increase to 5+.
Compliance with retrieval rates: Initially, we allowed some flexibility because many nodes were not compatible with Spark. However, Spark now updates almost weekly, so we require clients using Boost sealing to have at least a 10% retrieval rate. For clients using Lotus sealing, ND's retrieval tool can be used as a supplementary review method.
Geographic distribution: In the first round, we required clients to have at least 2–3 regions, and in subsequent rounds, this must increase to 4 different regions.
Only when these conditions are met will we allocate quotas in the sequence of 50%, 100%, and 200% of the weekly request amount, with each round’s amount not exceeding 1P.

Supports the review process: #131 (comment)

5. Our Future Work
Promotion and open-sourcing of the retrieval tool for community use: The tool is accessible at http://storagestats.ndlabs.io/. We plan to create a separate project repository and add product documentation and other information. After community validation, we will also open-source the code.

Collaborative efforts to collect SP information: We will work with official members from FF and SPWG to take the lead in registering high-quality SPs to facilitate clients’ node selection and make community reviews easier.

Development of new review tools/smart contract-based tools: We will develop tools related to reviews and payment for storage using smart contracts.

[galen-mcandrew]

Thank you for the additional context and details. Given the above information, it sounds like this pathway is working with a broader set of clients, and the other pathway --Enterprise data HK Cyberport -- is working with only enterprise web3 clients that are also working with the HK Cyberport.

Enterprise data - HK Cyberport pathway is primarily an application channel for incubating, accelerating, and investing in web3.0 startups. Cyberport is an innovative digital community with nearly 900 digital technology companies, managed by the Hong Kong Cyberport Management Company Limited, which is wholly owned by the Government of the Hong Kong Special Administrative Region. This channel is mainly for clients that have passed Cyberport’s selection process.

We hope to see continued examples of diligence that can be audited, such as the KYC and KYB details. It will also be beneficial to see evidence of enterprise and paid-storage deals, such as on-chain deal-pricing. I will continue to caution you against awarding DataCap to the same client across both pathways. I will also caution you against working with clients that are partnering with other allocators (such as NDLABS-Leo/Allocator-Pathway-ND-CLOUD#13 & CockroachBoss/Allocator-MediaPlatformData#4).

From the above information, we would like to request an additional 5PiB of DataCap for this allocator pathway.

@NDLABS-Leo hopefully these additional diligence review details and advice can be helpful. We hope to see continued (and improved) transparency and program compliance going forwards!