Separate Gas Price for ContractCallQuery Requests

[mshakeg]

Summary

This proposal suggests a separate gas price for the ContractCallQuery request that is relatively cheaper than the ContractExecuteTransaction gas price. The goal is to better reflect the resource availability and distribution across the network nodes when calculating the gas price for ContractCallQuery requests.

Motivation

Currently, the gas price for ContractCallQuery and ContractExecuteTransaction on Hedera is the same. However, these two types of requests have different resource requirements and processing characteristics. Introducing a separate gas price for ContractCallQuery requests can help better align the cost of these requests with the actual resource consumption and processing overhead.

Specification

The proposed gas price formula for ContractCallQuery requests is:

Gas price for ContractCallQuery requests = x * (1/N) * F

Where:

x is the gas price for ContractExecuteTransaction requests priced in USD/gas which is currently fixed at 0.000_000_0569 USD/gas.
N is the total number of consensus nodes in the network. Currently, Hedera has 28 consensus nodes run by council members, with a limit of 39. Since ContractCallQuery requests are processed by exactly 1 node, whereas ContractExecuteTransactions are usually processed by every single node, ContractCallQuery requests are computationally cheaper than ContractExecuteTransaction by a factor of 1/N.
F is a scaling factor accounting for the resource availability for ContractCallQuery requests.

Reasoning for F being 1/N

Setting F equal to 1/N is a reasonable approach when considering the following:

If all N nodes in the network are equally load balanced and have equal availability and capacity to process ContractCallQuery requests, then setting F equal to 1/N would account for the fact that each node is only responsible for processing a fraction of the total ContractCallQuery requests.

This gives a relative gas price for ContractCallQuery requests of x * (1/N) * (1/N) = x * (1/N^2)

At 28 nodes this translates to ContractCallQueryrequests having a gas price that is 784x cheaper than that of ContractExecuteTransaction or at 39 nodes 1521x cheaper. For simplicity and to meet in the middle the proposed relative gas price of ContractCallQuery requests should be rounded to 1000x cheaper or 0.000_000_000_0569 USD/gas. For example, a ContractCallQuery request with the gas set to the maximum of 15 million would cost:

ContractCallQuery total fee
= ContractCallLocal fee + ContractCallQuery gas price * gas + misc(input size & return size, etc)
~ $0.001 + $0.0008535 ~ $0.0018535

Backwards Compatibility

This proposal is expected to be backwards compatible, as it only introduces a separate and cheaper gas price for ContractCallQuery requests while maintaining the existing gas price for ContractExecuteTransaction requests.

References

1. Hedera Docs - Network Fees for Smart Contract Service
2. Hedera Docs - Gas and Fees

[shemnon]

I disagree that the cost should scale down with more nodes. The burden on a node doesn't get easier for a specific call because there are more nodes that could handle the call. The resource burden on the node is the same per call even if the aggregate amount of calls may change.

The costs to the node consist of time gossiping the event, CPU time computing the execution, resources spent reading state, and resources spent writing and committing state. A local execution still has to use the CPU time computing execution and spend resources reading the state. This is independent of the number of nodes in the network.

I would recommend a fixed value for (1/N) * F instead of a variable value. Perhaps 1/10. Making it lower than even makes sense, but we don't want to make it too low.

[mshakeg]

@shemnon thank you for the feedback.

I disagree that the cost should scale down with more nodes. The burden on a node doesn't get easier for a specific call because there are more nodes that could handle the call. The resource burden on the node is the same per call even if the aggregate amount of calls may change.

While I agree with this to an extent, the reason behind F being (1/N) was to account for the increased resource availability and processing capacity across the entire network as the number of nodes grows. If the ContractCallQuery request load can be distributed evenly between all N nodes then the effective supply is Nx. Since the effective supply is greater F should be less than 1 though maybe F = 1/N is a bit much.

---

Perhaps 1/10

I disagree with this, as the maximum number of council nodes is 39, so the relative gas price should at most be 1/39. Using the same formula (1/N) * F, where F is 0.5, gives (1/39)*0.5=1/78. I find rounding to 1/100 to be a fair relative gas price.

[shemnon]

The impact of querying state data is more than 1/100th of the cost. At full load this will prevent the system from maintaining 10kTPS. The cost also serves as in incentive to encourage users to run their own mirror node software and to simulate transactions off of the consensus nodes. 1/10 balances both needs.

[mshakeg]

@shemnon with HIP-584 the hedera json rpc relay will direct eth_call requests to the mirror node /api/v1/contracts/call POST endpoint, however, if that fails(for example due to rate limiting, downtime, etc) it will fallback to a ContractCallQuery request to a consensus node, I see 2 issues with this fallback:

1. ContractCallQuery requests have a gas limit of 15m gas, but /api/v1/contracts/call requests have a limit of 120m, so the fallback will not work for any eth_call that specifies a gas limit of >15m
2. if the relative gas price is 1/10 then even so the cost is still quite high; a 15m ContractCallQuery would cost at least:
   $0.001 + $0.08535 ~ $0.08635
   or if ContractCallQuery requests were in future to allow for a gas limit of 120m then it would cost at least:
   $0.001 + $0.6828 ~ $0.6838

I highly doubt the resource costs to execute ContractCallQuery requests are comparable to those prices, I would think there's a massive profit margin for consensus nodes to process such requests at those prices, otherwise wouldn't /api/v1/contracts/call requests be similarly priced?