3rd Community Diligence Review of ByteBase (Destore) Allocator

[Destore2023]

This ronud we have allocated to four clients.
Destore2023/MetaPathways-Bookkeeping#16
Destore2023/MetaPathways-Bookkeeping#18 (New client)
Destore2023/MetaPathways-Bookkeeping#21 (New client)
Destore2023/MetaPathways-Bookkeeping#24 (New client)

These clients are currently in process. Before allocation, we did due diligence on them - using a self-designed questionnaire to collect clients' information.
Destore2023/MetaPathways-Bookkeeping#18 (comment)

Destore2023/MetaPathways-Bookkeeping#21 (comment)

Destore2023/MetaPathways-Bookkeeping#24 (comment)

Clients provide their latest SP list regularly.

1. SP list
   [DataCap Application] Public dataset GEFS Destore2023/MetaPathways-Bookkeeping#16 (comment)
   Retrieval
   https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/16/1727346611052.md

2. SP list
   [DataCap Application] End-Use Load Profiles for the U.S. Building Stock Destore2023/MetaPathways-Bookkeeping#18 (comment)
   Retrieval
   https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/18/1730354139198.md

3. SP list
   [DataCap Application] <cryptoland><End-Use Load Profiles for the U.S. Building Stock> Destore2023/MetaPathways-Bookkeeping#21 (comment)
   Retrieval
   https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/21/1730800520859.md

4. SP list
   [DataCap Application] <NCBI> - <Sequence Read Archive> Destore2023/MetaPathways-Bookkeeping#24 (comment)
   Retrieval (no report)
   

We actively check the success rate of retrieval for our clients. Client had asked me for help about retrieval and I helped them talk with spark team.
filecoin-station/spark#100

We will keep our process up-to-date and provide feedback on github repo. We will make our work more detailed and better.
Hope to get a new round of 20P DataCap for further work. Thanks!

[filecoin-watchdog]

@Destore2023
Allocator Application
Compliance Report
1st Review
2nd Review
1st Review score: 5PiB
2nd Review score: 10PiB

7.75 PiB granted to existing clients:

Client Name	DC	status
NationalRenewable Energy Laboratory	2.25PiB	New
NationalRenewable Energy Laboratory	1.5PiB	New
NationalLibrary of Medicine	1.5PiB	New
SpaceTelescope Science Institute.	0.5PiB	New
NOAA	2PiB	Existing

NationalRenewable Energy Laboratory

• This dataset was already stored on filecoin several times
• According to the allocation schedule, each allocation should be 512TiB, yet allocations were 256/512/512/1024, which also extended the requested amount by 256TiB. Could you explain?
• The client used all the DC they got, but there are only 9 replicas instead of the declared 10.
• 1 of SPs has a retrieval rate of 0%.
• Most SPs match provided list (this address wasn’t used for deals: f01084941, and this one wasn’t updated in the issue yet was used for deals: f01975299)

NationalRenewable Energy Laboratory

• Not only this dataset was stored before on the filecoin but it was also stored with the help of your allocator just a week earlier. How did this happen?
  Those two clients even had the same issues: issue 18 comment vs. issue 21 comment
  Didn’t the allocator notice the similarities between those two issues? The name of the institution matches, the time of applying is similar (a week apart), there are similar issues, and the dataset is the same.
  6 out of 8 SPs matches issue 18 SPs list.
• 2SPs have a retrieval rate of 0%.
• According to allocation schedule each allocation should be 512TiB, yet allocations were 512TiB and 1PiB.

NationalLibrary of Medicine

• The allocator correctly noted that the data prepared by the client was already stored on the filecoin. However, the client should have specified more precisely what data he plans to store, providing a narrowed scope of data.

• SPs list provided and updated by the client:
  f03216485/Sichuan
  f03214920/HongKong
  f03228358/Zhejiang
  f01975299/Guangdong
  f01084941/Hong Kong
  f01084413 Hunan
  f03100009 Guangdong
  f03233966 Zhejiang

• SPs list used for deals:
  f01084413
  f03100009
  f03100004
  f03231666
  f03228358
  f03233966

• 2SPs don’t match the provided list.

• 2SPs have retrieval of 0%.

SpaceTelescope Science Institute.

• The allocator did ask for further explanation on data being stored before on filecoin.
• According to the allocation schedule, each allocation should be 768TiB, while the first should be 512TiB.
• so far, all SPs match the provided list of SPs
• 2SPs have very low retrieval rates.

NOAA

• This client declared 10 replicas, and there are already 13.
• According to allocation schedule each allocation should be 1PiB, why did the allocator granted 2PiB in the second allocation?

[Destore2023]

Hello @filecoin-watchdog, thanks for the review.

Destore2023/MetaPathways-Bookkeeping#18

Since the client's weekly allocation of datacap requested is 256TiB, this issue is allocated according to the way of LDN in the past.

As we prepared to sign for the second round of approvals, we found that something may go wrong with the program. We did the signing action in ledger and didn't see anything to show us that the allocation had been successful. We think we've got a bug. So we were searching the channel https://github.com/fidlabs/allocator-tooling/ and found that someone had experienced the same problem that time.

This should be an bug generated by program updating.
It wasn't until we went to check later that we realized datacap had been successfully allocated without notice on application and allocator.tech. Since this client's first round of package was good, we didn't take back the extra allocated datacap.

The client used all the DC they got, but there are only 9 replicas instead of the declared 10.

I see from the report that this client distributed to 10 sps. Please have a check.
https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/18/1732126166582.md

About retrieval, we have asked this client and made an issue for them. filecoin-station/spark#100

Most SPs match provided list (this address wasn’t used for deals: f01084941, and this one wasn’t updated in the issue yet was used for deals: f01975299)

Confirmed with this client, who had just worked with this sp.

Destore2023/MetaPathways-Bookkeeping#21
Thanks for your tips.
We had gone to confirm and found that only one client seems to have successfully completed the storage of this dataset in the past. And we noticed that this dataset is updating, so we accept clients to store this dataset.

Those two clients even had the same issues: Destore2023/MetaPathways-Bookkeeping#18 (comment) vs. Destore2023/MetaPathways-Bookkeeping#21 (comment)

I think it's because the sp they are having problems with is the same one.
We think that clients have different abilities and are limited in the number of sp that can be contacted. Clients are able to find qualified partners for cooperation from a limited number of active sps, which we support.

The client gave me feedback on the progress made in the retrieval.

Also feedback on the problems they are facing.

That's why we've doubled the distribution.

Destore2023/MetaPathways-Bookkeeping#24

The allocator correctly noted that the data prepared by the client was already stored on the filecoin. However, the client should have specified more precisely what data he plans to store, providing a narrowed scope of data.

Thanks for your tips.

2SPs don’t match the provided list.

I will push my clients to update their sp lists as soon.

Destore2023/MetaPathways-Bookkeeping#29
Considering the varied capabilities of our clients, we currently allocate our clients according to their weekly allocation requirements as the way of LDN.

Destore2023/MetaPathways-Bookkeeping#16

Clients said that they had replaced sp due to cost. This is the reason why the number of sps is higher than the planned number.

Thanks again for the review, it makes us realize that there are some aspects of our review that need to be improved. We will try our best to do better!