search

hashgraph / hedera-json-rpc-relay

Implementation of Ethereum JSON-RPC APIs for Hedera
Apache License 2.0
71 stars 73 forks source link

Enhance Relay Logic to Prevent Forwarding of Transactions with Suboptimal Gas Prices #2162

Open mshakeg opened 9 months ago

mshakeg commented 9 months ago

Problem

Currently, it would seem that the Hedera JSON RPC Relay forwards all transactions to consensus nodes, regardless of the gas price specified by the transaction. This approach results in transactions being submitted and potentially failing if their gas price is below the latest, correct gas price. This not only leads to unnecessary transaction fees but also indicates an underlying issue where the relay does not accurately reflect or calculate the latest gas prices(since txs typically specify the gas price returned by the relay). Users, relying on the relay's provided gas price for transaction specifications, are inadvertently setting themselves up for failure, contributing to inefficiencies and user dissatisfaction.

Solution

I propose implementing logic within the Hedera JSON RPC Relay that checks the specified gas price of a transaction against the latest, accurate gas price before forwarding it to consensus nodes. If the transaction's gas price is found to be lower than the current gas price, the relay should reject the transaction and return a message indicating the reason for rejection. This approach would ensure that only transactions with a viable chance of success are processed, reducing unnecessary network load and user costs.

Furthermore, enhancing the relay's mechanism for calculating or retrieving the latest gas prices to ensure accuracy is crucial. This could involve more frequent updates or checks against a reliable source of current gas prices to ensure the data provided to users for transaction specifications is always up-to-date and reflective of real-time conditions. It may also be wise to slightly overestimate the gas price that is returned by methods such as eth_gasPrice by a known factor say 0.1%.

Alternatives

No response

mshakeg commented 8 months ago

Hey @Nana-EC would really appreciate if this request was implemented. I rectified the nonce issue on this account earlier today (by using the next nonce), but it broke again a few minutes ago and so I'll have to rectify it again. I suppose a better short term fix on my end would be to just overestimate the gas price(but hopefully I'm not actually charged this overestimated gas price, but the actual gas price at the time of execution).

Nana-EC commented 8 months ago

Hey @Nana-EC would really appreciate if this request was implemented. I rectified the nonce issue on this account earlier today (by using the next nonce), but it broke again a few minutes ago and so I'll have to rectify it again. I support a better short term fix on my end would be to just overestimate the gas price(but hopefully I'm not actually charged this overestimated gas price, but the actual gas price at the time of execution).

HI @mshakeg The fix for the nonce issue is in 0.47. The deployment of 0.47 is being worked on once it hits mainnet you will not observe this.

Regarding the insufficient gasPrice prevention we'll triage and see what the best course is here.

mshakeg commented 8 months ago

@Nana-EC thanks, so I'm overestimating the gas price by x1.3 and the issue hasn't resurfaced, also seems like I'm being charged the actual gas price at execution time and not the specified overestimate(as is common on most evm networks with auctions), so I think I've got a more permanent solution.

Nana-EC commented 7 months ago

Note, the relay itself caches the gasPrice to optimize on support. Should it block transaction we'll want to make sure the cache which could be up to 1 hr old is accurate. This might get tricky but we'll circle back and see if it makes sense to adopt this suggestion or if it's best to leave it as is