Currently try_call host function safely recovers from any host error, including such errors as running out of budget or accessing an entry that doesn't belong to the footprint. While I don't see a straightforward way to abuse this, it doesn't seem right (e.g .in the new case for storage panics due to unrecovered evicted entries). should we promote some host errors to be non-recoverable even with try_call, so that it's guaranteed that the whole transaction will fail if something is truly broken?
#Non-recoverable host errors and `try_call`
steep hinge
cc @rigid garnet @stiff patio @narrow quiver
rigid garnet
I expect footprint and eviction errors are a good candidate, but we should keep this list pretty short.
We should discuss what happens with a footprint or eviction error in a little more detail. Because in the meeting this morning I think someone (@wheat bolt? sorry if I name the wrong person) said that if a transaction was submitted, failed an eviction lookup, that after adding the proof to chain, that the same tx could be submitted and succeed.
For the same tx to be submittable, that means it has to fail without consuming the transaction source account sequence number.
That also means the transaction has to be free.
That seems suspicious.
However, if that was true, and those txs are free, a good test for try_call might be that it fails the whole tx if no fee would be charged. But I suspect the above is incorrect and eviction failures shouldn't be free txs.
steep hinge
That also means the transaction has to be free.
we don't allow free transactions. to be more precise, we don't refund most of resources, no matter what tx does. i.e. if you say you consume 40M instructions, but your tx fails at apply time immediately, you still will be charged for 40M instructions
rigid garnet
Then the tx cannot be resubmitted.
steep hinge
if tx gets to apply phase it will always consume the source account seq num, which is unfortunate, but really it's not clear how to make this work otherwise
wheat bolt
I didn't think about the sequence number, so the tx can't be submitted
steep hinge
that's correct, yeah
only soroban auth can be reused basically
there was an issue from Nico regarding this, but I'm not sure we had any ideas on how this can be improved without compromising the DOS protection that fees provide
rigid garnet
So this is something important for us to consider then. This tx may be the only chance ever to execute, making try_call critical to catch failures (except gas clearly). I think with classic Stellar we would say such an expectation was reasonable. But maybe such a tx is unreasonable in Soroban world since an app that needs that guarantee can use Auth Next sigs inside a Tx.
wheat bolt
All evection related errors should be fatal even within try_call, I outlined some problematic designs in the has thread that are possible if you all eviction related errors to be handled by the contract
steep hinge
to be clear, try_call calls another contract, so the storage 'abuse' scenario seems too expensive to be feasible (you'd need to instantiate a VM to just get a bool flag). that said, it still will be better if it just made the tx fail - also better for the sake of reusing the signatures
rigid garnet
it still will be better if it just made the tx fail - also better for the sake of reusing the signatures
Only auth signatures, not tx signatures, to be clear.