Due Diligence Guidlines

[raghavrmadya]

Issue Description

Based on ND labs comment regarding " synchronizing them in the form of a document within the notary public group" mentioned in this issue, this issue is aimed at getting consensus on community agreed set of guidelines that will be published in a separate issue to support notaries. Active notaries and community members are requested to post in this thread what should be considered "good due diligence" and if possible provide a reasonable justification for the same.

Impact

This will enable better adherence to the guidelines by the notaries.

Proposed Solution(s)

Crowdsourced guidelines on notary due diligence

Proposed Timeline

Discussion July 6 2023 - July 17 2023
Guideline published - July 18th T&T WG Call

[Chris00618]

Notaries are given too much power in the LDN construct. Nobody can know if they performed due diligence or not because it's not transparent. They should act as a supporting role to help the application move forward not an unstoppable decision maker.

I think the governance team needs to make a series of public DDs before trigger applications. Notary publics can refer to the public results and if they have any doubts they can make additional questions in public. This reduces the workload of honest notaries and eliminates fraud by colluded notaries.

[Chris00618]

For example, notaries due diligence proof in #1579 and #1580,

1. no question, direct sign
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)

2. direct sign after bad reports with CID sharing, deal duplication
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 2>  filecoin-plus-large-datasets#1580 (comment)

3. sign after retrieval proof, but not a single retrieval works when i do it in person with the same command.
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 1> filecoin-plus-large-datasets#1579 (comment)
   [DataCap Application] <RongYIn Open Data Project 2>  filecoin-plus-large-datasets#1580 (comment)
   I don't know if the notaries are in these sp's whitelist or if the client or sp provided the screenshot to them directly.

Filecoin will not last long when these people are decision makers.

[NDLABS-Leo]

@raghavrmadya
Thank you for adopting RG's suggestion and taking on this task. There is a Chinese saying that goes, "There can be no order without rules." Although fil+ currently has guiding documents, as the project continues to develop, features such as the CID Checker report and Retrieval report will trigger extensive discussions within the community. These discussions often involve debates and negative voices, which do not contribute to the unity of the fil+ project and the community. It is hoped that we can put an end to these unnecessary arguments and focus on the right matters, such as establishing a basic consensus on notary node signing standards. The following are the basic contents proposed by Hidde Hoogland in Slack, which I believe are relatively comprehensive. However, many details still require collective discussion, optimization, and reaching a conclusion.

~~

• The dataset should be public, open, and aligned with Filecoin and Filecoin Plus. It should be accessible to anyone in the network without any special permissions or access requirements.

• Stored data should be readily retrievable on the network and can be verified regularly through manual or automated verification. This includes retrieving data from various miners over the course of the DataCap allocation timeframe.

• During the application review period, there should be no open disputes in the Fil+ ecosystem against the client.

• Best practices for storing large datasets involve distributing them across three or more regions and engaging with four or more storage provider operators or owners, with at least five replicas of the dataset.

• To prevent abuse of the program's incentive structure, notaries should not sign their own applications. It is crucial for each stakeholder to act truthfully and fulfill their respective roles for the program to work effectively.

~~
On this basis, we also hope to refine the execution granularity further:

1. Firstly, open access to data and basic data quantity: Notary nodes need to conduct sampling surveys on the data they store and understand the approximate amount of original data. If there is a significant disparity, it should be addressed by leaving a message on GitHub and waiting for a response from the client or conducting a secondary review by other notary nodes.

2. Data retrievability: This aspect should be further refined. The current consensus within the community is that the overall retrieval rate should not be lower than 1%. It is suggested to set goals, for example, starting from August, the rate should reach 20%, from September, it should reach 40%, and from October, it should reach 60%. However, considering the practical circumstances such as SP hardware facilities, we need to consider the issue of not being able to achieve a 100% retrieval rate. Perhaps setting the highest target as 80% would be considered an excellent project. Additionally, regarding HTTP retrieval, it is encouraged to promote its adoption. While SPs can choose to provide either Graphsync, HTTP, or Bitswap, it is recommended that all eventually support HTTP retrieval, as it will facilitate the development of ecosystem projects. For example, starting from August, the HTTP retrieval rate should be greater than 1%, and so on.

3. Data distribution and backup: Client applications should ultimately store data in at least three or more regions to ensure data security. Additionally, data backup should involve no fewer than four nodes (backup details can be based on the display in each round of the bot), which is also essential for data security. Regarding the use of VPN, as it has been observed, the community should consider the circumstances under which VPN usage is acceptable. If VPN is used solely to enhance network efficiency without modifying the geographical location, I believe it can be acceptable from my perspective. It is hoped that community members will engage in further discussions on this matter. Additionally, tools to assist notary nodes in the review process are also desired.

4. Notary nodes should not sign LDNs related to themselves to prevent abuse of their authority.

5. CID sharing issues: If disputes arise regarding data sharing content, clients need to provide explanations, proof, and subsequent solutions to gain the support of notary nodes. Signing notary nodes need to observe whether the proposed solution is effective and to guard against clients encountering the same data sharing issues again.

The above content is provided for reference, and it is intended to consolidate the rules and regulations into a basic consensus, allowing the fil+ project to thrive. Additionally, it is hoped that discussions related to this proposal will focus only on relevant issues, and if there are related matters, they can be presented as separate proposals. @Chris00618

[ghost]

We've just submitted a proposal to change the Open, Public Dataset workflow which includes clear upfront requirements and clear due diligence steps asked of notaries after initial allocations.

This change will be more inline with @Chris00618 comments above and @NDLABS-Leo comments as well.

• Clearly require client to state onboarding and storage plan upfront.
• Clearly require client to include SPs who are part of an application that meet Fil+ distribution and retrieval guidelines
• Clearly check SP IDs match and retrievals are offered after initial allocations, and if not close

[herrehesse]

@Filplus-govteam Please improve and add the following rules/guidelines to your proposal:

• Fil+ distribution and retrieval guidelines (rules)

Those are the most misinterpreted of them all.

[Chris00618]

@NDLABS-Leo The example is the general status of community due diligence. I'm by no means targeting anyone, don't take it personally.

~~ On this basis, we also hope to refine the execution granularity further:

1. Firstly, open access to data and basic data quantity: Notary nodes need to conduct sampling surveys on the data they store and understand the approximate amount of original data. If there is a significant disparity, it should be addressed by leaving a message on GitHub and waiting for a response from the client or conducting a secondary review by other notary nodes.
2. Data retrievability: This aspect should be further refined. The current consensus within the community is that the overall retrieval rate should not be lower than 1%. It is suggested to set goals, for example, starting from August, the rate should reach 20%, from September, it should reach 40%, and from October, it should reach 60%. However, considering the practical circumstances such as SP hardware facilities, we need to consider the issue of not being able to achieve a 100% retrieval rate. Perhaps setting the highest target as 80% would be considered an excellent project. Additionally, regarding HTTP retrieval, it is encouraged to promote its adoption. While SPs can choose to provide either Graphsync, HTTP, or Bitswap, it is recommended that all eventually support HTTP retrieval, as it will facilitate the development of ecosystem projects. For example, starting from August, the HTTP retrieval rate should be greater than 1%, and so on.
3. Data distribution and backup: Client applications should ultimately store data in at least three or more regions to ensure data security. Additionally, data backup should involve no fewer than four nodes (backup details can be based on the display in each round of the bot), which is also essential for data security. Regarding the use of VPN, as it has been observed, the community should consider the circumstances under which VPN usage is acceptable. If VPN is used solely to enhance network efficiency without modifying the geographical location, I believe it can be acceptable from my perspective. It is hoped that community members will engage in further discussions on this matter. Additionally, tools to assist notary nodes in the review process are also desired.
4. Notary nodes should not sign LDNs related to themselves to prevent abuse of their authority.
5. CID sharing issues: If disputes arise regarding data sharing content, clients need to provide explanations, proof, and subsequent solutions to gain the support of notary nodes. Signing notary nodes need to observe whether the proposed solution is effective and to guard against clients encountering the same data sharing issues again.

Your suggestion only holds if the notary and the client do not tamper with each other. Without transparency all rules are just set for show. At present, clients are mostly on anonymous accounts. Notaries and SPs are almost the same group. Let's not fool ourselves into believing that most notaries are signing as their notary applications say they are.

Only by restricting the power of notaries can solve the current dilemma

• The governance group needs to confirm the genuineness of clients and the compliance of applications before setting trigger
• Notaries take on the supporting role of DC allocation

Again, irresponsible behavior by notaries will damage the entire program. We need do something about this before FIL drops to zero.