3rd Community Review of TOPPOOL

[TOPPOOL-LEE]

Review of TOPPOOL Allocator from @TOPPOOL-LEE
Allocator Application: filecoin-project/notary-governance#1046
First Community Diligence: #16
Second Community Diligence: #150
Allocator Compliance Report: https://compliance.allocator.tech/report/f03004870/1726704098/report.md

Nice to see that duplicate data bug can be fixed. We determined that there was a bug with duplicate data through research by the technical team, testimonials from cilents, observations from others, etc. We raised the issue on 73 and sought a faster solution on Slack.After the bot was repaired, it turned out that all cilents were compliant .

Thanks to everyone for their hard work.

Five LDNs from four cilents：

Cilent 1:
TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#42
Cilent 2:
TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#46
Cilent 3:
TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#55
Cilent 4:
TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#53 and TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#40

We received a total of 5+10+10=25PiB. We are grateful. Overall, our allocations are healthy、decentralized and rule-compliant.We are diligent and honest.

[filecoin-watchdog]

@TOPPOOL-LEE
Allocator Application
Compliance Report
1st Review
2nd Review
1st Review score: 10PiB
2nd Review score: 10PiB

8.6 PiB granted to clients:

Client Name	DC	status
PangeoCommunity	0.7PiB	New
SloanDigital Sky Survey	0.7PiB	New
PangeoCommunity	0.7PiB	New
BroadInstitute	2.75PiB	New
StanfordUniversity	3.75PiB	New

PangeoCommunity and PangeoCommunity

• This is the same client who applied twice using the same dataset. They believed the bad CID report was caused by technical issues, which explains why they submitted another application.
• This dataset has been stored several times, with the most recent instance being last year (not in 2021): GitHub Issue.
• The client has received two allocations so far. A friendly reminder to the allocator: you mentioned, “We require SP distribution across three different continents and five different countries.”

Sloan Digital Sky Survey

• The application form did not provide enough information about data preparation. The allocator requested additional details on this.
• This dataset has been stored twice on Filecoin: GitHub Search.
• All SPs involved have a retrieval rate of less than 1%.
• The client has received two allocations so far. While SPs are distributed across three continents, they are only located in four countries. The allocator should monitor this to ensure compliance with the stated requirements.

Broad Institute

• This dataset has been stored multiple times: GitHub Search.
• SP f02984331 was listed as an Australian SP, but it is actually based in Singapore.
• All SPs are located on two continents and in only four countries. The allocator should ensure this aligns with their application requirements.
• All SPs match the provided list.
• One SP has a retrieval rate of less than 2%.

Stanford University

• All SPs match the provided list.
• The client declared four replicas, but there are already seven replicas in storage.
• All SPs are located on two continents and in only three countries. The allocator should monitor this to remain compliant with the application requirements.

Has the allocator performed KYB/KYC checks on their clients?

[galen-mcandrew]

Given this is the 3rd review, was looking for better results overall. It's helpful to see the allocator working with clients and devs/GovTeam to resolve issues, and appreciate the information provided.

That said, these specific areas need improvement:

• Accurate and updated SP lists
• Accurate regional distribution, with VPNs accounted for and explained
• Accurate and updated number of replicas
• Minimize duplicate and redundant datasets already existing on network
• Additional details regarding dataset preparation, especially when redundant datasets

The biggest area for improvement though would be the overall retrievability of datasets. We have seen many clients, allocators, and SPs find success and demonstrate high SPARK retrieval scores by now. Given these flags, we are requesting an additional 5PiB of DataCap from RKH.

@TOPPOOL-LEE please note the flags above and work to support successful clients and SPs.

[TOPPOOL-LEE]

@galen-mcandrew Sorry for the late response as we were waiting for the client's search rate to increase, but we have written the rest of the content.

[TOPPOOL-LEE]

@filecoin-watchdog Dear, thank you for your thorough inspection.
Yes, as you can see, the bot duplicate data report has troubled us for a long time. We raised the issue at fidlabs/allocator-tooling#73 and sought help on slack many times.
Here, please allow me to elaborate on the relevant facts, which are based on these facts for our allocation in this round:
Around September 18 (the time of 73 was September 18), some LDNs began to report duplicate data errors. At that time, our LDN did not appear.
On October 17, all the LDNs we cooperated with had bot bugs.
We asked the official team for help on the corresponding Github and #73 of LDN.

On October 28, the official team kacperzuk-neti informed the progress:
"The root cause has been determined, but it is not easy to fix."

"As an allocator, you should look at possible disputes more rigorously and comprehensively."
Adhering to this idea, in this round of allocation, we rejected old customers who reported duplicate data from bot.
However, we promised them that as long as the bot is updated, duplicate data is a bug, and we will continue to support them.
Before that, we can only look for more new customers (each customer has a different technical solution) to verify whether it is a problem with spark or a vulnerability in a customer's technical solution. So, this is also the reason why we are looking for new customers this round.
At the beginning, we found three customers, TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#53 #42 , and #46.
However, this round of new customers continued to report duplicate data. At this time, who should we trust? Should we trust the bot or the customer?
In order to solve this problem, we invited NonEntropy to apply for us. As the first distributor of the community to develop a search robot, they have relatively strong technical strength. Therefore, if NonEntropy comes to us to apply and they also have duplicate data problems, it can be more certain that it is a bot bug.
If NonEntropy's LDN does not have a bot error, but other customers do, then we may have to reject all customers in this batch, because their technical solutions should have loopholes.
Later, we found that all customers had duplicate data problems. So, this is definitely because of a bug in the bot.
At the same time, we observed the situation of other allocators, and some of them were also affected by duplicate data, but not many.
The report from the bot is of great guiding significance for whether we continue to support customers. Therefore, we hope that the problem of the bot can be solved quickly.
So, we have to continue to seek help on slack.

Thanks to the efforts of the official team, all the customers we cooperated with in this round have solved the problem of duplicate data. Although the customers in the previous round have not been solved yet, we have contacted kacperzuk-neti on #73.

Of course, we have encountered a new problem, that is, the retrieval rates of our two customers are slowly recovering, we have been assisting them to improve them in the past few days. so we hope to reply after their retrieval has recovered, so our reply is a bit late, sorry.

[TOPPOOL-LEE]

PangeoCommunity and PangeoCommunity
As we mentioned earlier, the first application of PangeoCommunity TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#40 had a problem with bot reporting duplicate data. The customer found it strange, so they closed the LDN themselves and reapplied.

When we approved the customer, all retrieval rates were maintained at around 50%, but because the data center was relocated last week, so the retrieval rate has decreased. Now, the customer's retrieval rate has returned to 20%. We are waiting for them to get to 50%

Broad Institute
The customer promised to save all CARs, but the support rate of spark has been very low. The spark team has been contacted, and now sp has increased to 27%.We are waiting for them to get to 60%

Stanford University
Regarding the storage replica, we have communicated with the customer that we will pay more attention to the difference between the filled-in replica and the actual replica in the next round.

[TOPPOOL-LEE]

@galen-mcandrew we are sorry for the late reply as we want to wait for the retrieval rate of sp to increase.We want to prove that all SPs we cooperate with support retrieval.
If the SP does not support retrieval, we will not allocate them.
Therefore, when the SP's retrieval rate drops due to network upgrades and other reasons, we hope to help them improve their retrieval
TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#46 (comment)

[TOPPOOL-LEE]

Sorry, we responded within 96 hours (4 days) after filecoin-watchdog's comment because we need to wait for the spark system to update the retrieval rate. We will respond within 48 hours (2 days) in the future. Now all customers have a higher retrieval rate.Next, they will continue to improve.
We are appreciate to see more updates, thank you

[TOPPOOL-LEE]

The retrieval rate of all SPs has been improved.

[Kevin-FF-USA]

Hi @TOPPOOL-LEE ,

Glad to hear the retrieval rates for all the SPs is improving. Excellent news!

This application is now awaiting RKH approval and signing for the next 5Pib of DC. Should see that occur sometime this week.

Looking forward to seeing 75% spark in this round! And again, key role for this manual pathway is to keep up with your clients - be sure they understand and follow the requirements.

Hope to see you on the next Community call on Dec 17, should you have questions or wish to go over anything in detail.

Warmly.
-Kevin

[TOPPOOL-LEE]

We understand and respect the decision of the governance team, and we will continue to follow the advice of the governance team:
Accurate and updated SP lists
Accurate regional distribution, with VPNs accounted for and explained
Accurate and updated number of replicas
Minimize duplicate and redundant datasets already existing on network
Additional details regarding dataset preparation, especially when redundant datasets
We will work hard to allocate the next round of 5P.
We plan to attend the meeting after the 5P allocation.
thank you.