Pay-as-you-use in Golem

Ever since Golem’s inception, our focus has always been on distributed computations and decentralized economies. When these two are combined, there are many factors to consider in order to deliver a product that can satisfy users from all sides of the spectrum while preventing misuse and bad actors, and reducing risks to the bare minimum.

Pay as you Use is meant as a trustless solution for decentralized marketplaces. It is an innovative proposal and a step forward towards the building of decentralized economies for dApps - an ambitious and difficult goal only achievable through substantial R&D efforts.

With these premises in mind, Golem is in constant research to find the fairest formula and the most balanced combination between economics and technology. This new post on Pay as you Use is part of the series of posts on gWASM (Golem’s WASM use-case blog post - coming in the next few weeks), explaining how Golem proceeds and launches our meta use-case from research to mainnet.

So far, the Golem tasks have been billed based on the timeouts set by the requestor. These timeouts are not directly related to the actual computation efforts. This scheme works fine when the tasks are similar, and requestors are able to estimate appropriate timeouts. However, the introduction of new use cases such as gWasm computing revealed the need for a new billing model. Hence, after extensive research, we decided to introduce Pay as You Use as a new additional billing model in Golem, in which the providers charge for resource usage.

When thinking about pricing, picture a familiar situation: you want to hire someone or get hired to perform some task like writing a program or designing a webpage. How should the price be set?  There are two common models: fixed price for the whole job or an hourly rate (aka Time & Materials).

Fixed Price means the service provider takes the risk, so it's safe for requestors. But, is this model really the best alternative for requestors?

On the other hand, T&M is risky for requestors, especially if there is no way of monitoring the work. And if fixed price would be the best alternative for requestors, why is Time & Materials even used?

As it turns out there are several challenges we need to consider in the fixed price model: requestors need to estimate the task size beforehand - poor estimation is always a risk factor.  Moreover, providers need to bid on a task without knowing its size, which is a big risk that needs to be accounted for in the offered price. As we can see, the fixed price model is a risky proposition unless both sides have a way of estimating the task in question.

Let’s then take a look at the Time & Materials model, which is generally considered a good choice if the job size is not known.  It is also fair to both sides if they are honest. However, the requestors face overcharge risks by dishonest contractors, especially when there are no means of monitoring work progress. However, on the positive side, if the requestor is dissatisfied with the price or quality, it has the option to not pay. In the decentralized world, the main risk with not paying is that the provider will not work for this requestor again, which is not a problem if the provider in question is dishonest.

The main challenge of Time & Materials model is: how can a requestor prevent being cheated on the usage bill?  What happens if a provider inflates resource usage? One common way of mitigating this risk is setting budget limits (also known as the “Time & Materials Not to Exceed” model), but this doesn’t resolve the problem completely, as malicious providers may always claim the whole budget.

Our main goal is to ensure the sustainability of the Golem economy in the long term. In order to achieve that, we need to eliminate cheaters from the market, or at least marginalize them by throttling their revenue streams. But rather than securing single transactions, we focus on costs in the longer term. The main question is: how do we even know when we are being cheated?

So it seems we are back to the central question: how much is a job worth? The estimation of this value can be done before or after the job.

Before the execution, we can use human input or some form of algorithmic estimation; then we can use the fixed price model.

After the execution, we have more information, but of course, we need more than just one data point. If many similar or identical tasks are executed in parallel - which is what happens in Golem - we can compare resource usage reports from various providers.

Before going into fraud protection details, let us think for a while about comparing offers: if A offers a unit price of 50 and B offers 60, should we always choose A? Not really - we need to take their efficiency into account. This is done by means of usage factor R (the relation between provider and requestor resource usage for this task) which can be thought of as measuring the amount of resources needed to compute a reference task (more precisely the relation between provider and requestor resource usage for this task). Initially, this can be set by benchmarking, analyzing provider’s hardware, or even setting it to 1 for every new provider. Most importantly, this factor gets adjusted and refined as requestor gets more information about the performance of this provider.

In our example, let us say A has R₁=1.25 and B has R₂=0.8. To compare offers we estimate execution costs for the reference task mentioned above: the estimation for A is 1.25*50=62.5 and for B is 0.8*60=48. Thus by choosing B we can expect the overall cost to be about 25% lower than in the case of A.

When the verification by redundancy (a bit of (another) spoiler alert here - this will be the topic of the next blog post in the gWasm series) is used, one task is executed by two or more providers, which gives us the opportunity to cross-check not only their results but also their reported usages. Continuing our example, let’s say A reports usage u₁=5 and B reports u₂=8 for the same task. Based on this data, we reevaluate their R-factors so that they reflect their reported usage, i.e. so that u₁/R₁=u₂/R₂. To this end, after update A has  R₁=0.79 while B has R₂ 1.265.  Next time we compare offers, we will take this updated factors into account. Next time we compare offers, we will take this updated factors into account.

Ensuring that efficiency factors reflect real resource usage is a big step towards eliminating cheaters but is not enough by itself. Malicious actors might try to game the system, e.g. by inflating their usage by an increasing, rather than constant factor, or perhaps always offering an attractive price at the first appearance, but after the job, claiming to have used all (or almost all) of the budget.

We have analyzed many possible attack scenarios and ensured the system is ready to defend against them and marginalize cheaters quickly and efficiently. Through this analysis and the implementation of Pay as You Use, we expect that the Golem Network economy will improve substantially. More improvements will come along the way, as this is only our first implemented model, and we are constantly looking into other approaches, for instance with game theoretical angles.

In conclusion, Pay as you Use lowers the risk regarding tasks size assessment for both requestors and providers (workers). In the way that it removes from users the need to have the skills and effort to assess tasks. Thus using Golem becomes easier and more intuitive.

Web3 technologies ought to reach better quality and reliability levels than the Web2 technologies, with the added and very necessary values of fairness, transparency, trustlessness, and robustness.

Only when such a product is achieved, end users will feel confident to adopt web3 technologies in their daily life, knowing their experience will be satisfactory and they will be utilizing quality, well-thought software, in a fairer scheme than with web2 technologies.

We hope you enjoyed this new article - and watch this space for more, soon!

Questions, comments, feedback? head over to our chatroom.

To learn more about Golem, click here.