Skip to content

Pricing specifications

Jump to bottom
Joanna Rutkowska edited this page Oct 26, 2018 · 1 revision

Pricing specification models

Notes from meeting on 2018-10-26

Main topic/problem: Tariff specification and comparison

  1. There is a set of generic resource counters. Likely specified via Golem-published RFC. E.g.:
  • time (of running the service) [sec]
  • network traffic [GiB]
  • amount of computations performed (kWh?)
  1. There will likely by some app/service-specific resource counters, which are to be specified by the service integrator. E.g.:
  • amount of VM's RAM
  • number of messages sent (for messaging service on Golem)
  1. Providers can define a pricing function from the domain of arguments discussed above. Golem protocol will provide a scheme(s) for describing the function, e.g:
  • some arithmetic expression
  • other forms? Marek suggested expressing the function by specifying N points and some way of turning them into a function, e.g. via a spline interpolation. Another idea: points determine linear functions on specific intervals.

  1. Requestors gets the pricing function inside the offers sent back by each provider.

  2. Requestors know (or can assume) the probability distribution of the resource counters for the tasks they're willing to deploy. E.g. the Poisson distribution of time of incoming call requests. They could then use this to distribution to generate N points for which they will evaluate the returned pricing function. Subsequently they can calculate:

  • the expected value E[price]
  • the variation
  • more params?

Now they can compare the offerings (tariffs) from different provider much easier.

The above scheme gives only probabilistic assurance that 1) we choose the best offer, and 2) that the tariff will be "reasonably honest", i.e. won't suddenly surprise the requestor with some unexpected high price for some specific condition (ala the unexpected high price one king was supposed to pay to the Chess inventor).

Clone this wiki locally