Allow resource fees exceeding u32::MAX

[dmkozh]

What problem does your feature solve?

Currently CLI returns an error if the resource fee exceeds u32::MAX. However, since protocol 23 resource fees up to i64::MAX are allowed by the protocol, so this error is no longer correct to return.

What would you like to see?

Instead of returning an error when the sum resource fee and inclusion fee exceeds u32:MAX we should do the following:

• Leave the resource fee as is
• Set the fee field of transaction envelope to 0
• Sign the envelope
• Wrap the envelope into fee bump envelope, with the same source account as for the original transaction source account
• Set the fee of fee bump envelope to resource_fee + 2 * inclusion_fee
• Sign the fee bump envelope

What alternatives are there?

Potentially CLI could just inform users that they should use the fee bump envelope, but that's not a great UX. At the very least, there should be a way for building a fee bump transaction via CLI, but ideally this should be done automatically, as described above.

[mootz12]

u32::MAX represents a fee of 429 XLM. Given how large it is, I think it's likely good UX that it fails. Tbh, we might want to consider a lower threshold, given if fees are this high is likely something is wrong in the first place and the user might want to be aware.

Given there are cases on testnet where this might be needed, the following might be a first step:

Add a --fee-bump flag to contract deploy/install/invoke. If present, the tx will get wrapped in a fee bump envelope transaction with the full amount if the expected fee is over u32::MAX.

if not present and a fee of over u32::MAX is hit, the warning message will include instructions to re-run the TX with --fee-bump and the expected total fee.

[leighmcculloch]

I think the --fee-bump flag is likely to not be very discoverable. And I think it would be fine if it automatically fee bumped in this case. This is very much an implementation detail of the network that users shouldn't really have to think about.

I think the point about really large values, maybe the CLI should have some threshold where it fails with an error if a command would spend more than N native asset on fees, with an error message saying that if you want to go ahead retry the command and add a --max-fee Y with a value of Y that is larger than N. Maybe allow Y=0 to mean unlimited max, and the default max fee would be 10 native or something.

[leighmcculloch]

Want to call out that in general the Stellar CLI needs to get much better at handling fee bumps. None of the commands that accept transaction XDR work with fee bumps today.

So this task has a few steps. We would first need to make sure that all the commands for modifying transactions, adding operations, signing transactions, simulating transactions, sending transaction would all need to support accepting a fee bump XDR before any command is outputs a fee bump XDR.

And then the actual change that proposed at the top of this issue is pretty simple.

[dmkozh]

u32::MAX represents a fee of 429 XLM. Given how large it is, I think it's likely good UX that it fails. Tbh, we might want to consider a lower threshold, given if fees are this high is likely something is wrong in the first place and the user might want to be aware.

With the way the protocol works, the cost of uploads and rent extensions of very large Wasms during the storage surge pricing may exceed 429 XLM. This has already happened on testnet. If we're concerned about the fee transparency, we probably should do something about that separately, but that is not a good enough justification for CLI to not support the features allowed by the protocol.

Also, it's pretty hard to waste the resources in Soroban. Even if there is some weird simulation glitch that causes you to set unreasonably high resource fee, it will be refunded during on-chain execution (in case if it wasn't what is actually required).

[leighmcculloch]

We would first need to make sure that all the commands for modifying transactions, adding operations, signing transactions, simulating transactions, sending transaction would all need to support accepting a fee bump XDR before any command is outputs a fee bump XDR.

I think we can shortcut what I posted above if we introduce the fee bump logic in the simulation step and the simulation and send commands. We can then work our way backwards adding fee bump support to other commands as needed, but if we do those two first then that's enough to address the issues of this PR.

[dmkozh]

I think we can shortcut what I posted above if we introduce the fee bump logic in the simulation step and the simulation and send commands.

This needs to be specified better. Do you suggest to wrap the input transaction into a fee bump envelope automatically, as in this issue? Wouldn't that be surprising to the clients, given that may not expect the fee bump envelope as output and/or may not now that they would need to sign two nested envelopes. I guess we could make the fee-based fee bump wrapping an explicit argument (false by default), then at least the client needs to acknowledge that they know what to do with the output.

[leighmcculloch]

I suggest we have all the commands that build transactions not fee bump until simulation and only if simulation identifies the need. That means any commands passed with --build-only wont output a fee bump. So only commands that will output a fee bump tx would be stellar tx simulate. The stellar tx sign and stellar tx send commands would need to be able to read a fee bump. Other commands can send a fee bump, but wouldn't output one when --build-only.

Then we can slowly add fee bump support to the other stellar tx commands.

That should give us a way to implement what you proposed in the top issue comment, without having to add support to fee bumps everywhere in the cli upfront.

[dmkozh]

That makes sense, sorry, I misunderstood the previous comment and got an impression that the suggestion is to do fee bump wrapping at the simulation step in RPC, not in CLI.