soroban-cli: Add Auth-next signing support

[paulbellamy]

Fixes #683

Adds support for SorobanAuthorizationEntry (i.e. auth-next) multi-party signing in the soroban-cli.

Usage

# Here, the local user account `alice` is used to sign the txn,
# but `bob` is the one who's value will be incremented.
#
# The contract method signature for this is:
#     pub fn increment(env: Env, user: Address, value: u32) -> u32 { ... }
$ soroban contract invoke \
    --source alice \
    --id $auth_example_contract \
    -- \
    increment \
    --user bob \
    --value 5

Notes

To get this to work, I've had to change the rpc simulateTransaction endpoint. Now, if the txn includes any SorobanAuthorizationEntries, the simulation runs in enforcing auth mode. This means that the nonce the user sent will be used, generating the correct footprint and fees.

Todo

• Try it out locally and check it actually works
• Write a system-test test for this
• update the RPC web docs for simulateTransaction update
• create a follow-up issue to support passing keys directly on the CLI in the S... format

[paulbellamy]

@dmkozh When I'm testing this, I keep getting TxInsufficientFee for any txn which involves auth-next signing...
For example, in this txn the only difference is the source-account (so one is Source credentials and the other is AddressNonce): https://gist.github.com/paulbellamy/5b30db0bb3046c145c921a39f4145e8b
Is there something else we need to do? We probably need to increase some fee for the size of the signatures right? IIRC there was some formula for that?

[dmkozh]

We probably need to increase some fee for the size of the signatures right?

Yes, as we don't support enforcing preflight yet, there are some gaps in terms of what we can meter in recording mode. Signature verification requires some additional instructions (though IIUC this didn't get to the stage where this is enforced). Also tx size will be increased a bit due to signatures. This should only need a small fee increase though and IIRC preflight already adds about 15% on top of the computed fee. So not sure what else could be missing.

[paulbellamy]

It could be that the transaction is quite small, so 15% is not enough for the extra signature in my case.

What is the formula for increasing the size due to the signatures? Is it just adding those bytes onto the extended_meta_data_size_bytes? or the refundable_fee? or the fee? or somewhere else?

[dmkozh]

What is the formula for increasing the size due to the signatures?

The increased tx size needs to be passed to the fee computation library. It will be reflected in the final non-refundable resource fee. To be more specific, it will be included in tx size fee and historical fee. But really if you want to compute fees outside of the rust library, you should rather port the whole library (https://github.com/stellar/rs-soroban-env/blob/main/soroban-env-host/src/fees.rs)