empty bear
Is there a similar function to require_auth which does not panic but instead returns an Result of sorts?
This could be useful if the contract should handle different cases e.g. for an authenticated vs non-authenticated call of one function
or
MultiSig where only n of m signatures are required (auth1 OR auth2 OR ...)
lean condor
this is potentially planned, but I'm still not sure if that's a good idea. for the first case, you can just add a bool per address and only require auth when it's true. for the second case, just don't pass unauthorized addresses in the first place
require_auth refers to a transaction attribute. handling its failures gracefully is not dissimilar to handling e.g. running out of gas or a missing a ledger entry in the footprint gracefully (which isn't possible for obvious reasons). auth seems a bit more tricky than these two, but I've yet to see the case that is not a potential footgun or can't be worked around easily (while also making interface more expressive)
a use case I had in mind myself was about batching several unrelated authorized operations together and making the contract resilient to potential failures. so if that's a useful case we still could add the graceful mode... but I really would encourage not using it as most of the times it would really point at design flaws or (worse) potential disastrous bugs
hallow kernel
What about in the case of a multisig scenario where it’s a 1 of n where there are two valid signers but only one is required
empty bear
What about in the case of a multisig scenario where it’s a 1 of n where there ar...
This is what I actually meant with n of m. we have m accounts which could potentially sign the transaction but we only need n < m.
(not that it's signed by m of which we actually only need n which I think was understood in the response )
cinder fox
For n of m multisig, calling require_auth on multiple Address inputs seems odd, since it requires signature aggregation to occur off chain, and it feels pretty difficult to manage the m set of valid addresses.
n of m could be implemented the way Gnosis Safe does. They store approvals per tx hash per account -> https://github.com/safe-global/safe-contracts/blob/main/contracts/Safe.sol
lean condor
What about in the case of a multisig scenario where it’s a 1 of n where there are two valid signers but only one is required
how about passing the signers in the input? usability questions aside, the transaction sender must have the signatures in order to send the transaction, and hence they should be able pass the respective addresses in the call. I agree that's not the only way to implement that - with try_require_auth you could load the addresses from the storage and try authorizing every one of them. but that would be tricky to test and preflight. so I'm still not sure it's a good idea
lean condor
regarding multisig - in a lot of the cases it should happen on the account side. but what we probably need to add is a generalized way for delayed approvals (basically store ContractAuth-like ticket in the ledger instead of always require it to be present in the tx)
(and the same goes for the account side)
violet bone
is there no way to catch a panic in rust without std? i know there is panic::catch_unwind but I think it's part of std
lean condor
I don't think you can catch host-side panic (as your wasm shouldn't even get control back), but I could be wrong
violet bone
yeah it makes sense i was thinking about it and just looking how catch_unwind works, i think it'd require new error handling methodology. anyways was just a thought; thanks
lean condor
FWIW you already can kind of handle require_auth failures 'gracefully', but only when they happen in the sub-contracts you called. that would be the same as any other contract failure. so the case of safe batching is supported on a contract basis (like here https://github.com/stellar/soroban-examples/blob/v0.6.0/atomic_multiswap/src/lib.rs). this should be safer because you get full rollback on failure.