Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Defining "reasonable" operating principles for multi-party entities (Notaries/Miners/Clients) #30

Closed
jnthnvctr opened this issue Nov 30, 2020 · 11 comments

Comments

@jnthnvctr
Copy link
Collaborator

As mentioned on the last governance call, there are a few areas where it seems useful to have some agreed upon guidelines for operation. Specifically, when it comes to an entity who plays multiple roles in this mechanism (a Notary/Miner, a Notary/Client, or Notary/Miner/Client) it's important that we agree on what sort of base actions are reasonable, such that folks can operate safely without worrying if they're crossing a line.

As always, the motivating guide are the principles - so proposals / constructions should be mapped to how we can best promote those ideals.

@jnthnvctr
Copy link
Collaborator Author

I think a good place to start here might be focusing on the Notary/Client relationship.

Notary/Client
I think there are two cases worth discussing here:

  1. A Notary who acts as a Client. In this case, you might imagine an example where the Internet Archive acting as a Notary and wants to allocate DataCap to themselves to onboard their own data.

For this case, I'd propose this should be acceptable - though the amount of their DataCap they intend to allocate to themselves should be disclosed in their initial application. I think for small amounts (e.g. under 10TiB) - perhaps this is unnecessary, unless it also happens to be a substantial portion of their overall DataCap (>10%).

Especially if in the early stages we have caps per geography, having Notaries who are simply onboarding their own data may hamper other areas of growth (other clients may have difficulty getting DataCap) - which in turn could hamper diversity on the Network.

I think it's reasonable for Notaries who act as Client's to also then be held to a high standard of ensuring the Data is stored following the recommendations here. Evidence that a Notary acting as a Client is failing to use DataCap responsibly should be filed as a dispute and discussed if worthy of some sort of further action.

  1. A Notary who has a strong relationship/affiliation with a Client. You could imagine an infrastructure provider (e.g. Infura) wanting to be a Notary to help provide a service to web3 clients. In this instance it's possible the client owns their own private keys, or that the Data is supplied by the client (but at a technical level Infura is actually running lotus as a client to store on behalf of the client).

For the case where the infrastructure provider is enabling a use case (providing a service to web3 clients) - and those clients control the private keys - I propose this should be considered like any other Notary allocation decision (i.e. same guidelines for vetting, etc).

For the case where the infrastructure provider also controls the private keys of the Client, I think the same strategy as (1) should be applied - and Notaries who intend to operate in this way would have a higher burden of proof in the initial application in showing they'd wield their power appropriately.

@jnthnvctr
Copy link
Collaborator Author

jnthnvctr commented Dec 7, 2020

Regarding the Notary / Miner (and Miner/Client) relationship - I propose the following:

  1. Miner applicants (or affiliates of miners) should be required to disclose relevant addresses when making their application

  2. 20% of a Notary's allocated DataCap should not be spent with the addresses listed in (1) (meaning of the DataCap spent at any given time, no more than 20% within a reasonable margin should be spent with a Notary's address)

  3. Notaries who are also Miner/Clients ARE NOT limited in requesting DataCap from Notaries in other geographies - if a Notary/Miner/Client needs substantial amounts of DataCap they should request it from a Notary external to their geography.

  4. Notaries found to be colluding with each other (i.e. two or more Notaries allocating DataCap to clients such that the clients substantially spend DataCap with the other Notaries) may be subject to removal.

While restrictive, I think this more restrictive mode of operation can help build trust in this process. A limited cap can help ensure decentralization and diversity. As trust builds in this mechanism, we can file a new issue / PR to reduce the constraints if these are too rigid and hamper growth. Additionally, setting base expectations should reasonably allow community members to provide scrutiny to Notaries and provide a framework for evaluating disputes / audit requests.

@jnthnvctr
Copy link
Collaborator Author

Note on reasonable margin above in (2) - perhaps its worth having this be the greater of some absolute number and/or some % of DataCap allocated?

@neogeweb3
Copy link

Regarding the Notary / Miner (and Miner/Client) relationship - I propose the following:

  1. Miner applicants (or affiliates of miners) should be required to disclose relevant addresses when making their application
  2. 20% of a Notary's allocated DataCap should not be spent with the addresses listed in (1) (meaning of the DataCap spent at any given time, no more than 20% within a reasonable margin should be spent with a Notary's address)
  3. Notaries who are also Miner/Clients ARE NOT limited in requesting DataCap from Notaries in other geographies - if a Notary/Miner/Client needs substantial amounts of DataCap they should request it from a Notary external to their geography.
  4. Notaries found to be colluding with each other (i.e. two or more Notaries allocating DataCap to clients such that the clients substantially spend DataCap with the other Notaries) may be subject to removal.

While restrictive, I think this more restrictive mode of operation can help build trust in this process. A limited cap can help ensure decentralization and diversity. As trust builds in this mechanism, we can file a new issue / PR to reduce the constraints if these are too rigid and hamper growth. Additionally, setting base expectations should reasonably allow community members to provide scrutiny to Notaries and provide a framework for evaluating disputes / audit requests.

Really great points regarding Notary/Miner relationship, I have some suggestions below:

  1. I think it's worth adding the word "ALL" to cover as many details as possible, so it would be "Miner applicants (or affiliates of miners) should be required to disclose ALL relevant addresses when making their application".
  2. 20% might be too much if the Notary has a total of 10 PB DataCap allocation. An absolute number (100TB for example, this could increase while Filecoin's growth) would help here.
  3. This could lead to misuses, for example, myself. I am currently living in NA, if I change my geography from Greater China to NA, then I will have the ability to break the rules. (For other folks reading my comments, please don't quote me on this, thanks. I am talking about possibilities, not the intention. Obviously, I am here to help, not abuse.)
  4. I think we would highly rely on complaints about this, so it might be worthy to find an efficient way to collect and track all the complaints. And how we are going to treat anonymous complaints, how the community governance handles each complaint, and all that would be worth considering to avoid a divided community in the near future.

I think generally it's very hard to design a 100% abuse-proof system, but defining operating principles and letting the community know what is right/wrong/reasonable is a great start.

@jnthnvctr
Copy link
Collaborator Author

Thanks @NeoGe-IPFSMain - I like the phrasing of (1).

For (2) - what if we were to say the lesser of 20% and 100TiB? I think reasonably so long as the Miner/Notary has the ability to request a third-party Notary to allocate the DataCap this shouldn't hamper their ability to operate on the network.

For (3) - do we think this still applies, if (2) would limit the amount of self dealing? Maybe the fix is to say Notary/Miners must apply from DataCap from a Notary outside of their geography AND unaffiliated with any of their addresses.

For (4) - I agree. I think to start, we can make complaints be issues - and ideally have a standard form and process that addresses this. I've opened a new issue for us to discuss.

@neogeweb3
Copy link

For (2) - what if we were to say the lesser of 20% and 100TiB? I think reasonably so long as the Miner/Notary has the ability to request a third-party Notary to allocate the DataCap this shouldn't hamper their ability to operate on the network.

Yes, the lesser of 20% and 100TiB would be ideal. And we are talking about cumulative total numbers here, not respectively to each allocation or to each relevant address.

For (3) - do we think this still applies, if (2) would limit the amount of self dealing? Maybe the fix is to say Notary/Miners must apply from DataCap from a Notary outside of their geography AND unaffiliated with any of their addresses.

Ah, you are referring to the Notary/Client/Miner 3-in-1 instances. But how do we know if Notary/Miners are Clients as well? It wouldn't be fair for them if they don't act as Clients but have to find DataCap outside of their regions. I guess it's hard to find a universal solution for everything, and it's hard to distinguish one from another as well.

@philippbanhardt
Copy link

I think from my perspective would be great if notaries are bound to (1) flag any client data cap requests they receive and have an affiliation with (economic interest but also strong social ties e.g. have worked together in the past) and (2) defer these requests to other notaries - regardless of any spending threshold. I think given the anticipated number of notaries I would not worry about too little supply / capacity elsewhere.

Fully with folks here on the notary / miner relationship and that transparency is critical.

@jnthnvctr
Copy link
Collaborator Author

jnthnvctr commented Dec 10, 2020

I think what Philipp is proposing might be the most straightforward, at least to start. I think in the future, we might be able to simplify the process with appropriate disclosures happening in the application itself.

So for Notary / Client:

  1. Notaries who also would like to be a client (i.e. Notary wants DataCap to spend as a Client), should get a third-party Notary to allocate DataCap to them.
  2. Notaries can/should be encouraged to allocate DataCap to legitimate clients they have affiliations with, though the relationship should be disclosed.

For Notary / Miners:

  1. Perhaps the safest route is to simply refer the request for an affiliated Client to another Notary to conduct the same due diligence to start.

All notaries should disclose:

  1. Addresses they control (for auditing purposes on chain)
  2. Any potential conflicts of interest (e.g. miners they have a financial stake in, etc)
  3. All Notaries should be making clients aware of best practices (Discussion: Orienting Clients to Filecoin Plus #9 ) - including storing data in a responsible way (i.e. being wary of Clients allocating all their DataCap with an individual miner).

jnthnvctr added a commit that referenced this issue Dec 11, 2020
Addressing: #30

In the future we may reduce the restrictions here, but for now the bias is towards avoiding any conflicts of interest. Notaries should expect other Notaries to require support to help onboard use cases to accommodate this early restrictive approach.
@jnthnvctr
Copy link
Collaborator Author

I've drafted an approach to this issue - please leave comments! One note - I simply said that this should be referred to a third party Notary (not requiring a separate geography). Thoughts?

cc @NeoGe-IPFSMain @philippbanhardt @zixuanzh @dkkapur

@s0nik42
Copy link

s0nik42 commented Dec 15, 2020

I think it’s going in the right direction
The next step for me should be more practical. To avoid frustration and being transparent with miners or other member of FC the ecosystem (but not as familiar as the notary with the process). I think we should have one place (at least at the beginning) to declare these affilations and allowing anyone to submit a complaint.

@flyworker
Copy link

flyworker commented Dec 16, 2020

We need a big data tool to do analysis about arm length deals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants