feat: add MAX_GAS_ALLOWANCE_HBAR configuration

[Neurone]

Description:

Some providers need to fully subsidise their users' transactions. This option is already available on the network and in the SDK by setting the max_gas_allowance parameter accordingly.

This PR enables this parameter to be set via the JSON-RPC Relay configuration as well.

Related issue(s):

closes #3880

Notes for reviewer:

Now both the brand new MAX_GAS_ALLOWANCE_HBAR and the existing GAS_PRICE_TINY_BAR_BUFFER env variables are loaded dynamically via ConfigService.

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[lfdt-bot]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

[natanasow]

LGTM, one question.

[codecov]

Codecov Report

Attention: Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
packages/relay/src/lib/precheck.ts	33.33%	2 Missing ⚠️

❌ Your patch check has failed because the patch coverage (50.00%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

@@           Coverage Diff           @@
##             main    #3865   +/-   ##
=======================================
  Coverage        ?   46.06%           
=======================================
  Files           ?       83           
  Lines           ?     4821           
  Branches        ?      988           
=======================================
  Hits            ?     2221           
  Misses          ?     2262           
  Partials        ?      338           

Files with missing lines	Coverage Δ
...ckages/config-service/src/services/globalConfig.ts	100.00% <ø> (ø)
packages/relay/src/lib/clients/sdkClient.ts	39.59% <100.00%> (ø)
packages/relay/src/lib/precheck.ts	48.27% <33.33%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[acuarica]

Thanks @Neurone for sending this. It looks good so far. Have a couple of questions (we can tackle them in following PRs if needed)

• Should we include a tool example (in the tools/ folder) showcasing this feature?
• What happens when the sender account does not exist? Before this feature, this wasn't possible because the sender need to have HBARs. Now that's not the case anymore. We should add a test for this scenario.

[acuarica]

I'm not sure about setting GAS_PRICE_TINY_BAR_BUFFER in a fully subsidized JSON-RPC Relay. It seems GAS_PRICE_TINY_BAR_BUFFER has a different purpose. We might need to change the precheck to account for the MAX_GAS_ALLOWANCE_HBAR variable.

[Neurone]

The MAX_GAS_ALLOWANCE_HBAR is set by the operator, so I'm not sure it needs a dedicated pre-check.

About GAS_PRICE_TINY_BAR_BUFFER, you are right, that serve a different purpose, and that's fine.

That parameter is mentioned here only as a reference, because in case the user set gasPrice=0, a low buffer value (that is probably what you want in a classic JSON-RPC relay configuration) will block those transactions during the pre-check.

So, in case an operator want to support gasPrice=0 transactions, it must update the GAS_PRICE_TINY_BAR_BUFFER parameter also accordingly.

[acuarica]

So, in case an operator want to support gasPrice=0 transactions, it must update the GAS_PRICE_TINY_BAR_BUFFER parameter also accordingly.

Exactly. I believe this is not the best UX for operators, as we are requiring them to update the unrelated GAS_PRICE_TINY_BAR_BUFFER variable.

[Neurone]

We can think about improving the operators UX in general, but probably just providing a preset of config values for the different use cases they want to achieve is enough.

The GAS_PRICE_TINY_BAR_BUFFER is mentioned in the comments because it's involved in the process, but it's not a constraint to set it to a specific value. Operators can still decide to keep that value small as they prefer, and pay only for txs which costs is in that specific cost range.

BTW, the scope of this PR is very limited: it's just enable operators setting the MAX_GAS_ALLOWANCE_HBAR value as they prefer, like they do for other parameters, so I would suggest to postpone further improvements for another PR.

[Neurone]

• Should we include a tool example (in the tools/ folder) showcasing this feature?

I prefer to merge this and then thinking about specific tools, but at least the new test cases already show how you can play with this parameter and obtain a fully subsidised transaction.

• What happens when the sender account does not exist? Before this feature, this wasn't possible because the sender need to have HBARs. Now that's not the case anymore. We should add a test for this scenario.

I'm not sure I get the question. This parameter does not introduce a new feature, it just give the relay operators the ability to set that value as they prefer. In case they set a big enough value, and the sender set gasPrice to 0, the total cost of the transaction (network fees and gas consumption) will be on the operator, and nothing will be charged to the sender (here an example).

There's no other change in the transaction, the sender (the transaction's signer) is still there, untouched as usual.