-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Community Diligence Review of ND Labs Enterprise Allocator #109
Comments
Because our Allocator has been buggy, we waited a long time in the middle of the process, and in the community need to carry out spark compatibility as soon as the results came out the first time we asked the customer to carry out the sprak retrieval rate enhancement. |
After the customer adjusted the packaging procedure, the nodes listed here have started to have the retrieval rate display one after another, as the project proceeds, I believe that the retrieval rate of these nodes will be gradually improved, and the number of retrievable nodes will also increase. |
Flagging and pausing this compliance review, given some confusing details that need to be addressed. This allocator has two pathways, which is reasonable and encouraged under the current program structure. However, there appears to be a lot of overlap between these pathways, without clear specialization. Specifically, this client has an almost identical application across both pathways for the same set of data. Additionally, this client has encrypted unretrievable data, with no evidence of paid enterprise deal-making to show program alignment. Their SP distribution is also noncompliant with the allocator's application, regarding number, region, and VPN usage. Other clients in this pathway are also not engaging in compliant SP deal making and distribution, such as here: https://check.allocator.tech/report/NDLABS-Leo/Allocator-Pathway-Enterprise-data/issues/8/1723003166749.md @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. Please provide any additional evidence and diligence for our review regarding the above issues. |
The client situation in the channel, and the review, is explained in the link, so hopefully some additional clarification can be made. |
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. In our allocator application form, apart from how we verify client information, the logic, and standards for reviewing data, sps, and sealing situations are essentially similar across both channels. For more details on our past review process and reasoning, please refer to this link: #131 (comment). Now, I’ll focus on explaining why the AINN client applied through both ND channels and the characteristics of all clients in this particular channel.
Additionally, the other two clients in this channel are:
To summarize, this outlines the client situation for this channel. To prevent any future misunderstandings regarding client statuses, we will archive KYB information and records of whether clients meet channel requirements here: https://github.com/NDLABS-Leo/Allocator-Pathway-Enterprise-data/blob/main/README.md. Thank you for your time and consideration. ND is making every effort to bring more genuine clients into the Filecoin network. Our future work plan is outlined in this comment #131 (comment), and we look forward to the community’s collaboration and guidance. |
Thank you for the additional details. It seems like one of the major components for this pathway is participation in the HK Cyberport program. Are there some additional documents or details that could be provided to show compliance and participation in this program? For example, is there a standard and official indication for these "900 digital technology companies, managed by the Hong Kong Cyberport Management Company Limited"? Additionally, given the nature of this enterprise pathway, we would love to see further evidence of paid storage deals. In the meantime, we are requesting an additional 5PiB for this allocator pathway, with the expectation that we can see increased evidence of specialization of this pathway. For example, I strongly advise your team to partition the clients and datasets that are working with this pathway compared to other ND Labs and other allocators in general. |
DataCap refreshed. |
Allocator Compliance Review: https://compliance.allocator.tech/report/f03012747/1721402091/report.md
Allocator Application: filecoin-project/notary-governance#1025
First example: NDLABS-Leo/Allocator-Pathway-Enterprise-data#3
KYB was asked for 3 months after the first DataCap allocation. NDLABS-Leo/Allocator-Pathway-Enterprise-data#3.
Client asking 10 copies at 10PiBs.
Gov Team needs to follow up proof of KYB and dataset size
Second example: NDLABS-Leo/Allocator-Pathway-Enterprise-data#8
Client asking 10 copies at 10PiBs. Yet only 3-4SPs?
Gov Team needs to follow up to confirm Dataset size and proof of KYB.
The text was updated successfully, but these errors were encountered: