Research - include gas costs in allocation budget

[nieznanysprawiciel]

Why:

• Requestor sets budget for allocation, but finally he doesn't know how much he will pay, since fees are not included
• Protect Requestors from spending more money, than they want

What:

• Research what changes in payments driver needs to be made
• Propose solutions

[maaktweluit]

i think this is hard (if not impossible) in 3 parts:

• we dont know the amount of transactions to be made from this allocation
• we dont know the network gas price at the time of the transaction
• we dont know the gas token => GLM values at the time of the transaction

@cryptobench @filipgolem @Wiezzel @johny-b @tworec

[johny-b]

@maaktweluit I think it is indeed impossible to have a "correct" solution (i.e. always working), but maybe we could have some approximate solution that would be good enough for most of the cases?

Just an adhoc example:

1. Assume the gas token/GLM ratio from the allocation moment will not change
2. Assume there will be 2 transactions, but after one is done still expect 2 transactions to come (thus reducing the amount available as a payment for the computations)

Sorry if this is OT, but I have a strong feeling that some "good enough" solution should be available, where "good enough" is something like "budget is exceeded by more than 1% in less then 0.1% cases when budget is exhausted".

[nieznanysprawiciel]

For me semantic of allocation should be something like: "This is the biggest amount I want to pay for this task". So we don't need to estimate transactions costs when creating a task. SDKs should probably stop computing, when budget is reached.

But not knowing gas price and gas token => GLM values is still a problem. We express allocation in GLMs and we don't swap to gas token, so even having enough GLMs isn't enough. We would need second value in allocation for gas, what seems like horrible design :(

[Wiezzel]

Back when the payments team existed we had the following idea of a "good enough" solution:

1. Assume that 99% of transactions would be done with a gasless driver (zkSync) and don't care about having a separate token to pay tx fees. (Seems no longer valid.)
2. Introduce max_transactions parameter for allocations. For batch tasks it could be set to the number of subtasks. For services it's more tricky, but allocations themselves are tricky in case of services.
3. Allow to accept invoices up to amount X where X = allocated_amount - max_transactions * current_gas_price (this assumes gas prices don't change; if we want a safer solution we can add +20% or smth).

[etam]

I'm digging it out of the grave of oblivion.

@golemfactory/ya-sdk Maybe it's possible for ya*api to ask yagna for current gas price and estimate required gas before starting computation?

[johny-b]

I'm digging it out of the grave of oblivion.

@golemfactory/ya-sdk Maybe it's possible for ya*api to ask yagna for current gas price and estimate required gas before starting computation?

Maybe?

But I think we were heading into a different direction:

1. You pay for both gas and usage in GLMs
2. Golem has some contract that performs GLM <-> gas exchange

This solves the "conceptual" problem - there's only a single amount developer has to care about. There's another problem left - who handles the GLM <-> gas exchange rate volatility.

Topic was discussed around the "gaseless forwarder" thing (developed for miner and supposed to be included in yagna, I guess?).

[golmek]

Summary:

• Allocation (Yagna) - it defines only GLM for Provider Payments. Not include Fees
• Fees are taken independently for Matic/ETH.

Problem:

• Requestor does not know how much he will pay overall.

Closing this ticket as topic didn't move forward for the last 1.5 year. It is not within our current priorities in CORE. However, I will mark as part of the ideas to be discussed in the future.