Datacap Management
Closed this issue · 9 comments
**Note: this discussion is created based on the current state of the art of Filecoin plus program as of Nov 9, 2021. It is under the assumption of the high level principles and the mechanism of the program will stay unchanged for the next 4-6 months(to be more specific, I'm not factoring in how FVM may unlock more options and flexibility for the program).
Filecoin plus, introduced by FIP-0003 is a governance program aims to get valuable data verified and onboarded to the filecoin network.
As a part of the program mechanism, there are notaries as the verifiers to evaluate the clients and their data, then grant a certain amount of datacap to the qualified clients' filecoin wallet. Datacaps are like a client credit quote imho. Then clients can make verified deals using the datacaps and enjoy cheaper storage service offer. More details about the program can be found here
The current verifreg actor has the following functionalities:
- RKH to add/remove verifiers(notaries)
- verifiers add verified clients, as notaries grant datacap to clients after off-chain manual verifications
Proposal
I'd like to start a discussion about adding two more features:
- TransferDatacap
- RemoveVerifiedClient
TransferDatacap
A client may send a TransferDatacap message to transfer remaining datacap to a different wallet. One or more notaries* should approve the message before the datacap is transferred.
One of the use cases here would be a client with valuable data has been granted X datacap, however, then if they decided to use data broker like estuary/.storage for easier deal making experience, they should have the option to transfer the datacap to the wallet account that is registered or used by the data broker so the data broker may make the deals on their behalf.
Open question
- As the filecoin plus program is based on the verification then a trust relationship between notary, clients and network participants, do we need one or more notaries to approve the transfer if the client has been verified already?
RemoveVerifiedClient
According to filecoin plus statics shown here, only 9.53% of the total datacap and 0.5% of the total LDN datacap was actually used in verified deals. I think we should first try to figure out why the clients requested datacap but not onboarding data. But also, have an option to remove inactive verified clients would be nice to avoid potential future storage market manipulation with malicious usage of datacap.
Be able to remove malicious clients that were reported as a fraud or one cheating the system would be useful once the filecoin plus has fraud audit mechanism.
Open question
- Should there be an expiry on datacap? If so, how long should that period be?
- Should datacap get revoked from an inactive client gradually over a period of time or at once(remove the wallet from verified client client list)?
Instead of transfer “all remaining datacap”, would be good to also specify the amount to transfer.
For example if I want to give each textile and filswan 200TB datacap to broker my deals.
To answer why onboarding rate so low, from my personal experience, Number 1 reason is lack of collateral on small/medium providers (for example MinerX members).
Number 2 reason is slow data transfer between continents (especially sending data to to China) so I cannot reach to providers there.
Re: RemoveVerifiedClient, what happens if a verified client seals data with a storage provider, they are found to be fraudulent, and their status as a verified client is removed?
Does the storage provider who may have stored their data continue to receive their 10x verified client block reward?
Re: RemoveVerifiedClient, what happens if a verified client seals data with a storage provider, they are found to be fraudulent, and their status as a verified client is removed?
Does the storage provider who may have stored their data continue to receive their 10x verified client block reward?
Used datacap in verified deals won’t be impacted.
As the filecoin plus program is based on the verification then a trust relationship between notary, clients and network participants, do we need one or more notaries to approve the transfer if the client has been verified already?
I personally think one approval should be enough. Adding multiple approvals will just add overhead / additional work for the notaries.
Should there be an expiry on datacap? If so, how long should that period be?
Should datacap get revoked from an inactive client gradually over a period of time or at once(remove the wallet from verified client client list)?
Regarding the expiry period, might be helpful to get some feedback from clients. But in general I think most clients should be able to prepare and distribute their datacap in <1 year.
I think the datacap should be revoked all at once for inactive clients. The same tool can then be used for revoking datacaps from malicious client(s).
TransferDatacap is not supported.
Instead, supporting to receive DataCap that has been allocated to clients and has not been used by clients or community, if key loss, fraudulency, etc. There seems to be another issue for what has already been used.
#143
Agree to remove inactive verified clients' DataCap.
We can collect opinions in open channels (180 days, 360 days, 540 days, etc.) and specify the expiration date.
At the same time, we should be clear and solve the problem of slow onboarding.
For example,
Establish platforms for clients to connect with storage providers.
Provide technical support for verified data uplink for storage service providers.
@jennijuju thanks for kicking this off. We did get a chance to discuss this in the last set of governance calls and here are the main takeaways from the conversation (recording is here):
- we should divide this into 2 FIPs since the implications are pretty substantial and the response to support for each of the functions was different (1 each for TransferDatacap and RemoveVerifiedClient)
- "RemoveVerifiedClient" makes a lot of sense, both for inactivity and for fraud/abuse of the system, though the exact mechanisms for this are still up for discussion. Specifically, would the original notary + 1 more notary need to sign this? For inactivity, could it be automatic via a bot proposal to notaries or RKH?
- "TransferDatacap" is a little more controversial. General takeaway here is that we'd like to explore this further to see if there is a real use case that this supports. Transferring DataCap to a deal broker is not the ideal pattern, since deal brokers are already out getting DataCap for themselves, and in the past, we've talked about deal brokers potentially becoming notaries/able to hand out DataCap rather than the pattern suggested in the FIP.
Proposal (my opinion):
- let's divide the FIP into 2
- FIP on "RemoveVerifiedClient": we should discuss mechanism as well as implications for the client applying in the future + long term, if any impact on notary reputation and leverage
- FIP on "TransferDatacap": further discussion on aligning Fil+ system and DataCap flow to client UX and deal making usage patterns before pushing this through. Additionally, in the nearer term, TransferDatacap = RemoveVerifiedClient + new allocation, so there is still a path here.
It appears as if the client UX needs to be front and centre. Understand the root causes as to why onboarding is dramatically low following Datacap allocation.
Adoption of new tech always faces barriers, there is a narrow window of opportunity to surface the issues and turnaround the adoption curve and/ or 'retire' a client whose needs arent been served. A "customer success" analyst can facilitate this, it could be a short term contract for this stage, but ultimately some tech pre sales and post sales support is essential.
The second dimension - DataCap transfer could be an opt in upfront - in the application, and again, we can ask what and why they may intend to use any transfer feature in the future to understand what the client needs. For existing clients seeking transfer, as @dkkapur suggested, lets explore, but not guess, we can simply ask our users/ clients what they need and want and track the flow-on effects.
A function of the notary process is to perform the client "sanity check" post allocation, could we assist with onboarding by checking in with the client. Also @dkkapur a review (step guide) of the post datacap allocation, especially what are red flags would be useful, or even better, a new bot that indicates to the signing notaries the client is inactive/ looking fishy.
Initial FIP draft https://github.com/filecoin-project/FIPs/pull/226/files