Modification: Aggregation and Compliance Bot

[ghost]

Aggregation and Compliance Bot

Context

We propose the deployment of an Aggregation and Compliance (AC) Bot designed to streamline the allocation and removal of datacap across LDN and E-Fil+ pathways. If you are a notary and you agree with the design of the AC Bot detailed in this proposal, please indicate your support in the comments section below.

The AC Bot aims to:

• Aggregate data from multiple data sources across multiple systems.
• Use the aggregated data to enforce compliance among clients receiving DataCap through the LDN and E-Fil+ pathways.

We believe that the implementation of this bot offers advantages over the existing Fil+ ecosystem in the following ways:

• Reduced bureaucracy: With less human intervention, the process of issuing DataCap becomes more streamlined, easing the workload on clients, as well as notaries.
• Enhanced neutrality: Allocation/removal of DataCap will be guided by well-defined rules that can be modified through proposals. Though not entirely objective due to the human involvement in rule-making, subjectivity is limited to this rule-setting phase rather than being present on a case-by-case basis as in the current system.
• More permissionless: Instead of relying on a human notary, this method defaults to a bot, enabling anyone to interact with it via GitHub at any time.

From a tooling perspective, this proposal is the most actionable direction for the Fil+ program. It does not require FVM smart contract or core-protocol adjustments, enabling a relatively swift implementation. While development on the bot has already begun, it is important to note that the parameters (weights and thresholds) in this initial configuration are not final, representing only opinions of the Fil+ governance team. If you have insights or suggestions for improving this proposal, we're open to feedback. Please feel free to directly add your comments to this proposal, or reach out to us on Slack in the Fil+ channel or via @Philippe Pangestu.

The following proposal is split into two sections:

• Proposed Design: Covers the AC bot's design and other technical aspects.
• Phases of Deployment: Details the timeline for this system's rollout.

Proposed Design

Here, we detail the bot's architecture and how it will impact the DataCap issuance process using the collected data. Conditional and threshold functions are designed to evaluate whether the client meets essential requirements, while the Client scoring function will be designed to determine whether to allocate a new tranche of DataCap.

Initially, the bot will focus only on removing DataCap from clients who fail to meet the basic conditions, while also providing recommendations for DataCap allocation through GitHub comments. In later phases, we plan to introduce functionality that enables the bot to directly allocate DataCap to eligible clients.

Conditional Functions

These detail the prerequisites a client must satisfy to comply to the LDN guidelines. Non-compliance with these conditions for a continuous one week period will lead to application closure and DataCap removal. Failure to comply with initial verification will result in the application not being triggered for notary review.

• Initial verification:

  • KYC requirements: The client must complete the Know Your Customer (KYC) process (currently we outsource this to a third party provider).
  • SP distribution: For the given application, the client must claim a set of 5 or more unique SP IDs that they are going to make storage deals with.

• Verifications at the fourth and subsequent allocations of DataCap:

  • SP verification: For the given application, the client must only make deals with SPs included in their original claimed set of SP IDs.
  • SP Minimum: For the given application, the client must have deals with a minimum of 4 SP IDs.
  • location distribution: The data that the client stores geographically spread across a minimum of 3 unique locations.
  • CID-sharing: The client's stored data must not feature CIDs that are duplicated across separate deals involving different clients.

Threshold Functions

Certain metrics are provided in percentage form by various data sources. These metrics have specific minimum and maximum threshold criteria that must be satisfied. In addition to the pre-requisites in the previous section, If a client fails to meet any of these requirements for a continuous one week period, their application will also be closed and the allocated DataCap will be removed.

• Retrieval score: The average retrievability score for the client's SPs as determined by the retrievability bot must be greater than 10%

• Deal Distribution scores: Multiple criteria must be met, based on metrics provided by the CID-checker

  • No individual Storage Provider (SP) utilized by the client should engage in deals that consume more than 40% of the client's allocated DataCap.
  • No individual SP associated with the client should be storing more than 25% of duplicate data.
  • The percentage of unique data stored with fewer than 4 SPs must not exceed 40%.

Client Scoring Function

This function will be used to "score" clients based on metrics that indicate responsible dealmaking behavior. If properly calibrated and supplemented with sufficient data sources, this scoring function could be leveraged to potentially auto-allocate DataCap to clients. During the initial phase of implementation, the function will primarily be used to give recommendations for notaries to allocate DataCap.

The function will take the form of a simple normalized weighted average across various metrics, such as:

• Existing metrics:
  • Retrievability score
  • CID-checker client score
• Metrics that could be added in the future:
  • Average Filecoin Green SP scores
  • Proof of inclusion
  • Additional data from the SP working group

The specific weights and thresholds for this scoring function will be determined during the bot's testing phase. Thresholds for this function should depend on:

• The volume of DataCap being allocated to the client through the LDN application
• The amount of DataCap the client has already received and utilized through the LDN application
• The cumulative DataCap allocation from the LDN program
• The rate at which the client is utilizing their DataCap

New DataCap issuance process

The AC Bot will primarily synchronize with the existing SSA Bot to determine if a client is in need of a new DataCap allocation. Mainly the AC Bot will be listening for applications where the most recent message is a "DataCap request". Once identified, the AC bot will have the capability to influence the DataCap issuance process for any client in three main ways:

• Closing the application and Removing Datacap: The bot will penalize the client by closing their application and removing their remaining DataCap when they fail any of the conditional/threshold functions. The AC Bot will act on behalf of two notary accounts to generate a "Datacap Removal Proposal," as outlined here, pending approval from the Root Key Holders. Should either notaries or clients object to the removal, they can voice their concerns in the comments section of the DataCap removal proposal.
• Offering Recommendations: The bot can also provide insights for DataCap removal or allocation based on its collected data. This serves to streamline the due-diligence procedures for notaries and offers a feedback mechanism for fine-tuning the bot's parameters. For example, if a notary disagrees with a recommendation, the specific reasons can be analyzed to decide whether the bot needs adjustments.
• Allocating New DataCap: If a client's score, derived from the client scoring function, surpasses a predetermined threshold, the bot will grant new DataCap. Here, the bot operates on behalf of two notary accounts to create and approve a DataCap allocation proposal. Notifications for both the proposal and approval will be displayed on the associated GitHub issue as usual.

Dispute process

We will always be open to amendments to the architecture and parameters of the bot. Post-deployment, the most effective channels for the community to offer their input and suggestions are as follows:

• Clients have the option to initiate disputes against the bot if they feel they have been unfairly impacted or have other contentions regarding the bot's decisions on their applications.
• Proposals to modify the parameters (including weights and thresholds) of the AC bot can be drafted within the LDN repository should there be a need to revise them.

Phases of deployment

• Internal testing and tweaking (already in progress): In this initial phase, the Fil+ gov team is focused on developing and trialing an internal prototype of the bot. Various parameters will be tested to identify an initial set of weights and thresholds. The parameters stated in this proposal can be discussed in the comment section and will be finalized in a subsequent proposal. In the same time, the Fil+ gov team will concentrate on integrating and validating the bot with all different data sources, GitHub, and blockchain nodes to guarantee a seamless and rapid deployment.

• Datacap Removal phase: Once deployed to the public, the bot will be able to execute the closure of applications and withdrawal of DataCap from clients per its recommendations. Any objections to these removals can be raised in the new issue generated by the bot as part of the removal process before the root key holders finalize the decision. Should the dispute be upheld, the gov team could override the bot and restore the affected application.

  For DataCap allocation, the bot will only be giving recommendations, and clients will still require two notaries to sign their applications for DataCap. Reactions to these suggestions will be monitored to facilitate ongoing refinement of the AC Bot.

• Auto-allocation bot full deployment: If confidence in the bot's suggestions is sufficiently high (evident by the frequency of notaries following its advice), the bot may be permitted to autonomously distribute DataCap for notaries. Before any allocation of DataCap there would be a grace period when the bot posts a warning comment that it will be allocating DataCap. During this grace period, notaries can negate the bots decision to allocate DataCap. This is a crucial step that would require much attention as overallocation of datacap might harm the Fil+ community.

• Feedback loop implementation: With a stable bot version in place, a feedback loop system can be incorporated, where disputes and other data sources help refine the bot's parameters.

• On-chain migration: In the future, we could leverage oracles to channel data to the FVM. Decisions could be made by a smart contract that holds and allocates DataCap to clients.

Call to action

If you are a notary and agree with the design choices in this proposal, please indicate your support in the comment section below. These are some questions you should consider:

• Do you agree with the overall design for a bot that aggregates the described pieces of information?
• Do you agree with the data sources we are utilizing for the bot to make decisions?
• Do you support the specified thresholds for this bot starting remove client DataCap proposals?

We're currently in the testing phase, integrating a variety of data sources. Receiving your feedback sooner will simplify the process of making adjustments to the AC Bot's design and parameters before everything is finalized.

[The-Wayvy]

I'm happy to see that some attention is being paid to the problems with Fil+

1

There is one big issue that isn't addressed here:

All Fil+ deals need to be auctioned off, in public, on-chain.

That is the only way for Fil+ to be fair and clean.

To attract new miners, we need a level-playing field.

https://docs.google.com/document/d/1KLR6nZ8ic4ARj3J46XsxSE_b1RpDP_z3JBKL4alHGGw/edit

This is a description from JV at PL.

As long as the break-even price for taking a deal is negative and the winning bid is burned, mandatory auctions work.

@Filplus-govteam

2

KYC should be removed.

The system must work without DOXing people.

(However if you do auctions then KYC is less of a big deal)

3

The utility of these subsidies is another subject that I'll leave for other PRs.

[Joss-Hua]

Is it not allowed to add or adjust the SP list? I don't quite understand why this restriction is imposed~

[kernelogic]

Retrieval bot needs to have the capability and bandwidth to test files located inside of Asia.

[liyunzhi-666]

Before each round of quota decentralization, the client has the obligation to reconfirm the location and organization of SPs, and at the same time, the client should also have the right to change the SPs participating in storage. Because participation in the FIL+ program is a long process, SPs may drop out at any time due to pledges, hardware purchases, and other reasons.

[herony-fil]

SP cannot be specified at the datacap stage, which encourages corruption. Any datacap should be acquired on a public auction basis.

[galen-mcandrew]

@herony-fil Not sure I understand or agree with your statements. The program is currently designed to have clients express an interest and intent to work with specific SPs as part of their application. Client choice and agency in choosing SP partners (which meet program guidelines of distribution) is still a core component of the Fil+ program. 'Auctions' and other deal-distribution mechanisms are outside scope of this proposal.

[galen-mcandrew]

@Joss-Hua The intent here is to give clients up to the fourth allocation to establish their set of distributed and performing SPs. If a client claims they will work with a certain set, this bot is meant to help enforce compliance with the client's initial claim.

I would be interested in hearing ways to make this parameter more flexible, while still holding a client accountable to meeting their own claimed deal-making intentions and also complying with the required distribution guidelines.

[The-Wayvy]

@galen-mcandrew

Mandatory auctions are within the scope of this discussion, since this proposal specifies rules for deal distribution.

If you don’t believe in equal opportunity for all miners then just say so.

Users are free to transact only with their preferred SPs on the permissionless part of the network.

[nicelove666]

It looks familiar, a bit like an early FIL-E. At the beginning, FIL-E also appointed a notary by kevin-z. Facts have proved that this approach is not ideal.

[nicelove666]

I agree with all the proposals to make FIL+ better, let's go one step further:

1. Let the robot check the LDN, close and delete the DC unreasonably.

2. Reasonable LDN, the robot signs directly, and the amount is credited directly to the account, no longer neededthe need for a notary. This could make Filecoin permissionless again.

[kevzak]

Regarding SP ID verification: Here is my feedback from an analysis that I completed last month regarding SP ID usage https://github.com/filecoin-project/notary-governance/discussions/966#discussioncomment-6862721

TL;DR: Current state - applicants list some SP IDs on their application to get approved, and then they actually do deal making with other IDs. This constant changing of SP IDs that we see today is an easy way to game the system and should be limited where possible.

IMO, applicants should not even be allowed to apply for DataCap (1st allocation) if they do not have a clear list of distributed SP partners in place upfront. So I think this verification step is a good way to enforce the Fil+ guidelines from the start. Let's limit applicants who are not serious about storing real data.

[kevzak]

I'm happy to see that some attention is being paid to the problems with Fil+

1

There is one big issue that isn't addressed here:

All Fil+ deals need to be auctioned off, in public, on-chain.

That is the only way for Fil+ to be fair and clean.

To attract new miners, we need a level-playing field.

https://docs.google.com/document/d/1KLR6nZ8ic4ARj3J46XsxSE_b1RpDP_z3JBKL4alHGGw/edit

This is a description from JV at PL.

As long as the break-even price for taking a deal is negative and the winning bid is burned, mandatory auctions work.

@Filplus-govteam

2

KYC should be removed.

The system must work without DOXing people.

3

The utility of these subsidies is another subject that I'll leave for other PRs.

@The-Wayvy - I think your comments here should be re-directed to a different permissionless pathway proposal.

The current LDN open, public dataset pathway is permissioned and does require social trust and therefore this bot's design and verification checks are directed toward the current system pathways and processes.

So for example, enforcing KYC does in fact aid in supporting a trust based system. Not to know the actual person behind the GitHub ID, that information is not available, but moreso to know there is an actual person behind the ID that completed a verification check and not a spam bot.

And also with these pieces of information, we can start to piece together:

• the client address
• with associated GitHub user names using each address
• with automated, objectively measurable outputs from the bot

Ultimately, we can start to utilize all of these pieces of on-chain information to build out reputation scores of clients.

[The-Wayvy]

@kevzak

Mandatory auctions do not conflict with any of the suggestions made in this proposal, including KYC.

And the tech is already in place (ex. BDE).

It's by far the best way to combat 'self-dealing', other than getting rid of subsidies and requiring that users .... pay for storage

[galen-mcandrew]

To reiterate, this proposal is not reliant on auctions. In the future, if a client chooses to utilize an auction or other deal-making third--party service (such as BDE or other data-clearinghouse), then those metrics could (and should) be incorporated into this bot. We are not gating this iterative implementation improvement on those technologies, and we welcome teams to continue developing other deal-making mechanisms.

The questions here for current notaries:

Do you agree with the overall design for a bot that aggregates the described pieces of information? Do you support the specified thresholds for this bot starting remove client DataCap proposals?

[panges2]

@The-Wayvy To those points you brought up.

1. "All Fil+ deals need to be auctioned off, in public, on-chain." is debatable. Rather, I'm of the opinion that "All Fil+ deals can be auctioned off, in public, on-chain." So there should be multiple pathways, either KYC or stake in an auction to prove value.
2. This system wont dox people. Togggle does KYC on our behalf and we will only store minimal information that we get from togggle (email and gh username and date of KYC) just for functional purposes. We only need a way to confirm that there is a person behind the client address.
3. Agree, utility is very debatable and outside the scope of this proposal

Overall, if you dont agree with these points above, we are also working on a separate pathway that seems to better suit the points you brought up here. I'm in the works on a separate proposal for a FVM trustless notary pathway based on JVs design. As you mentioned, most of the tech and design are there, we just need to tweak, implement, and test!. There are also many community participants that want to take part in this sort of pathway. Thank you for your interest, and stay tuned for an upcoming proposal!

[panges2]

@Joss-Hua I agree with @galen-mcandrew here. At least initially, we want to err on the side of stricter compliance. We understand that there will be legitimate cases where a client would want to change their SPs. We would be open in the future to having exception pathways that allow clients to modify their list of SPs.

[The-Wayvy]

@panges2 @galen-mcandrew

I assume that your primary goal is to end self-dealing.

Self-dealing is impossible if you mandate competitive auctions as long as the break even price is negative and the winning bid is burned.

It’s an extremely simple solution.

The client doesn’t need to put down collateral and can still go through KYC.

All the distribution requirements you mentioned can be respected.

Nothing is stopping us from adding mandatory auctions on to this proposal.

Only those who extract value from the deal distribution process are opposed.

[The-Wayvy]

@panges2

Mandate auctions for all Fil+ deals (including LDN / EFIL)

and self-dealing instantly disappears.

---

What are you trying to solve other than self-dealing?

[The-Wayvy]

@galen-mcandrew

To reiterate, this proposal is not reliant on auctions. In the future, if a client chooses to utilize an auction or other deal-making third--party service (such as BDE or other data-clearinghouse), then those metrics could (and should) be incorporated into this bot. We are not gating this iterative implementation improvement on those technologies, and we welcome teams to continue developing other deal-making mechanisms.

Without mandatory auctions, the community won't believe in the integrity of Filecoin Plus.

JV first proposed mandatory auctions 6 months ago.

So I'm asking that you mandate auctions as the distribution mechanism for all Fil+ deals as part of this proposal.

It's compatible with everything in your original post.

[panges2]

@nicelove666

I see your point. Alot of the requirements from the AC bot mentioned above are the same as the KYC requirements of E-FIL+. But what is proposed above is super set of the requirements that include CID-checker and retrieval bot requirements.

This proposal also adds on a few other things:

• actually having an automated way to execute based on requirements automatically
• creates a platform to aggregate different datasources and to enforce other requirements that may be added in the future.

I also do agree with you that we could one day automate datacap allocation, but as I mentioned in the timeline above, we want to test out the bot first to make sure that we can trust its decisions.

[panges2]

@kernelogic We have at least one instance of the retrieval bot operating in China. We're also in progress to add more instances soon!

[Wengeding]

Regarding SP ID verification: Here is my feedback from an analysis that I completed last month regarding SP ID usage #966 (comment)

TL;DR: Current state - applicants list some SP IDs on their application to get approved, and then they actually do deal making with other IDs. This constant changing of SP IDs that we see today is an easy way to game the system and should be limited where possible.

IMO, applicants should not even be allowed to apply for DataCap (1st allocation) if they do not have a clear list of distributed SP partners in place upfront. So I think this verification step is a good way to enforce the Fil+ guidelines from the start. Let's limit applicants who are not serious about storing real data.

Can you give me a couple of examples of applications about perfect implementation of this policy? @kevzak

[cryptowhizzard]

I would like to see the retrieval bot side of things expanded a bit. At least one full CID ( random selected by the retrieval bot ) must be made public available in unpacked state on a http link so notary’s can evaluate the data stored before a new tranche is allowed. In case that the data is not matching the data a client is storing the application should be closed by the governance team on recommendation of a notary and datacap removed.

I think 40% per service provider is to much. 25% maximum.

Given that there are “restrictions” in certain country’s I would still opt to one replica per Country. This avoids non - retrievability issues.

I am not supportive of the idea of Fei-yan to have a special bot in restrictive country’s. It is up to the data preparer / applicant to select it’s SP’s who support retrieval by everyone who wants without restrictions. Let the market do it’s job here.

[The-Wayvy]

Let the market do it’s job here.

• @cryptowhizzard

Good one !

[Kevin-FF-USA]

Will be discussing on the https://github.com/filecoin-project/notary-governance/issues/978

[spaceT9]

Is there a clear timeline to test AC bot?

[MegaFil]

It's a great idea, but it's hard to get off the ground. It is possible to simplify the rules of fil+ to the point where they can be executed by bots, which is a path that can be explored.

[willscott]

Is it possible to have a more technical definition of what is expected of providers versus the outcome of "The average retrievability score for the client's SPs as determined by the retrievability bot must be greater than 10%"

The retrievability bot may evolve, but the baseline expectation for SPs should be more constant - what should be expected is retrivability and bandwidth, and the measurements should attempt to reflect if those properties are met