Provider Fees & 3rd party Providers

[alexcos20]

Now, if you are a publisher, you have two options:

• use OPF provider (with limited C2d resource)
• use your own provider (maybe costly, you have to maintain domains, internet connection, etc)

Provider security:

• allow anyone to publish (very unsecure, a malicious actor can publish a dataset using your provider, mint dt and start an unlimited C2D jobs, while you pay for it) (OPF case)
• have a fixed list of addresses allowed to publish (works for small amount of entities)

But what if I want to allow anyone to publish, as long as I'm getting paid for my resources. now, 3rd party Provider it won't work, because they are not paid

Introducing Provider Fee to publish/consume flow:

• as a 3rd party Provider, I want to allow everyone to publish using my own provider (and trust me), but I want to be paid accordingly -- have a rate for any downloadable service -- have a rate for compute services, depending on: timeout, #cpu, memory allocated, disk space, #gpu

Draft flow:

a. Publish flow

• when encrypting the URL, instead of just passing an array of url, we are going to send also the service parameters (type & if needed ddo.service.compute object. Provider will return an object:

  {
  "files": "0x2343434" ,  // encrypted urls
  "providerFeeToken: "0x1233",  // token used for consume fee  (Ocean, USDT, etc)
  "providerFeeAmount":"1.2"    // fee amount (in decimal)
  "providerFeeSignedMessage": "0x12344"        // web3.eth.sign(providerFeeToken+providerFeeAmount, providerPublicKey)
  }

this will be stored in the ddo.service (we already store files)

b. Consume

• at consume time, in startOrder we will pay that fee on top of existing fees (publishMarketFee, consumeMarketFee) (if providerFeeAmount>0 and providerFeeToken != address(0)
• Provider will read the ddo, use web3.eth.personal.ecRecover(providerFeeToken+providerFeeAmount, providerFeeSignedMessage) and see if the address used for signing is provider's address
• Provider will check the transfers from startOrder and make sure that the fee was transferred to provider account

Question :

• how to update fees? Maybe on publish, provider agrees with 1 usdt/1 cpu . After 6 months, he want to increase it to 2 usdt/cpu. Provider has no right to update the ddo, only publisher does (he needs to re-encrypt to urls, in order to get the updated object)
• how to reimburse ? If provider has a rate of 1 USDT/cpu/hour and my ddo says timeout = 24 hours, provider will charge me with 24 USDT. but if my algo fails after 1 minute, I will get the difference back? how can we enforce this?

Cons:

• an extra token to be approved for each consumption. If publishMarket wants fees in USDT, consumeMarket wants fees in Ocean and Provider wants fees in DAI, we need 3 approvals + startOrder confirmations => 4 MetaMask interaction for consume (assuming you already have 1 DT)

PS: Doable for V4

[trentmc]

Note: this idea was explored by the OceanDAO "Core Tech WG" on Nov 24, recorded in Traction Ideas Slides. For convenience, here it is:

Incentivize / easy payment for 3rd party Ocean Providers

• Building block: in v4 there are already fees on top of datatoken. (In addition to within datatoken)
• Building block: V4 DDO specifies compute resources needed for running a given algorithm script in a “pod”: # CPUs, amount of memory allocated to the pod, disk space, # GPUs, <and it’s extendible>.
• Problem: if you’re a publisher, you get all datatokens from download, or C2D job. But what if you want to have a 3rd party run Provider. How would you pay for it?
• Problem: lack of awareness of need to have non-OPF providers
• Candidate idea A: they get a share of DT of each consume. Relative ownership represented (a) as ERC721s (b) as ERC20s (c) other
• Candidate idea B: in v4 fees, also have provider fee too "on top"
• Candidate idea C: have a third datatoken to pay for compute (or more generally, provider fees). Provider specifies what resource it gives. E.g. 1.0 provider datatokens gives 3 CPU-hours on etc etc. Makes it clear to interface to EC2, iExec, Golem. Combined with V4 DDO, the provider can automatically calculate the cost
• Q: how do you charge for job A that takes 1 CPU-minute, versus 10 CPU-days?

(The proposal in the description is "candidate idea B")

[trentmc]

For current proposal (candidate idea B): the provider + fee is specified for each asset.

Problem: if provider's price changes, then every asset run by that provider needs updating.

Problem: provider doesn't have permissions to change fees on each asset (as Alex pointed out)

Idea:

• A {Provider, Specific provider service} registers separately, e.g. "Joe" + "2 CPUs, 100 MB memory, 1 GB disk, 0 GPUs <in Joe's system>". The service has a rate fee, e.g. "$1 per h".
• When an asset is published, it's linked to a registered {Provider, Specific provider service}.
• When an asset is consumed, publisher gets paid too. There are at least two variants here:
  • Variant: Pay in provider-specific tokens (candidate idea C). These can be purchased in the market side-by-side with "datasets" and "algorithms". Provider would typically choose fixed-price (vs pool).
  • Variant: pay "on top" in a provider-specified amount and denomination for that specific provider service, e.g. 1 USDT. Call this "candidate idea D".
  • In both cases, the data consumer would approve() an upper-bound amount to be paid; then the computation happens; then the provider is transferred just the amount based on the amount of actual computation done.

I see pros and cons for both idea C vs idea D. Both reuse existing mechanics inside Ocean Protocol & Ocean Market. C is more flexible, so it has more potential to unlock more use cases. D is slightly easier to understand.

[alexcos20]

Proposal flow:

a. Publish flow

• nothing changes, no fees are stored in the ddo b. Consume
• when calling initialize , based on did & serviceID (or serviceIndex), provider can compute the required fee (if any), and it's adding the following parameters to the reponse:

  {
  "providerFeeToken: "0x1233", 
  "providerFeeAmount":"1.2",
  "providerFeeAddress": "0xabc"
  }

  Consumer will use that variables when calling startOrder (which does a transfer), and provider can check for events. (Provider will grab the DDO, and based on serviceType, timeout, compute resources will do their math and compute the fee)

Perks:

• can be update anytime by the provider, it's based on ENVs (cost / cpu, cost / gpu, cost/mb for download services, etc)

Cons:

• what if you publish a dataset using a provider that charges 1 USDT/cpu and 2 month later the provider bumps it to 100 USDT/CPU ? Simple, you are going to republish the service (not the entire asset) using a different provider