Provide a mechanic to determine if a contract has been upgraded

[kalepail]

Relevant Discord thread: https://discord.com/channels/897514728459468821/1317258800377630730

As I've been working on smart wallets and particularly policy signers it's become evident that it would be nice for security sake to be able to "pin" cross contract calls to a specific wasm hash rather than a contract id to ensure if that hash changed the cross contract call would fail.

The use case is that policy signers adds the ability for headless or automated wallet interactions where the user isn't around to review the transaction. At some point in the past they approved a contract to operate on their wallet with the understanding that they would behave according to their code at the time of approval. Given that contracts can be upgraded however this guarantee isn't very strong. Contract ids aren't very secure given the underlying code could change. WASM hashes on the other hand are perfectly secure in the fact that they are the objects doing the actual work.

Given this it would be quite nice to be able to return a contract's wasm hash and not just its address so that other contracts could opt to store those hashes for review later before making a cross contract call.

[earrietadev]

I think this will be good to have, I've had the same thinking for policy signers and the current "solution" that came to my mind was just checking balances before calling the contract method and checking later but this will require having a contract as a middleware and won't work for most cases so being able to cancel the call by just checking if the hash changed will be perfect

[dmkozh]

While this has a bit abstract title, I think the protocol change proposed is to add a host function that returns a Wasm hash given a contract id. Please let me if something else is necessary on the protocol side.

Also, just a reminder, that even if the implementation of the contract you trusted hasn't changed, its settings and dependencies might still change, so there is always a risk and some additional precautions. So while storing the trusted Wasm might improve the security in some cases, its important to also have more precautions in place, e.g. in case of a smart wallet, set the spend limits for the policy on the wallet side.

[kalepail]

Sounds correct to me. @leighmcculloch does this cover any cases you were thinking of?

[leighmcculloch]

As @dmkozh points out the protection is very narrow. Most tools that pin dependencies (think Cargo.lock or package-lock.json) do so in a complete sense covering all transitive dependencies. It provides a pretty weak guarantee to pin only the direct dependency.

In ecosystems like Ethereum where contract pinning happens by default because the system doesn't support upgrades, the pattern of proxy contracts have been employed to allow contract maintainers to upgrade contracts as needed. Will features like this risk creating a reason to build proxies on Stellar?

I like the simplicity of being able to ask for the hash of any contract. In theory someone could ask for the hash of transitive dependencies too. So maybe that's sufficient assuming folks use it correctly and do check all the transitive deps too?