Add some way to ensure that third-party contract is trusted

[frol]

There is a use-case where some contract wants to ensure that some other contract is not an impostor. So far I don't have a complete solution in mind that would be secure in the context of async execution. We could have used code checksum and whitelist the known checksums, but I see flaws of it regarding races in async execution.

Use-case:

My contract wants to know that the other account has my trusted auxiliary contract deployed to it and there are no full-access keys.

Inspired by: https://github.com/galactic3/name_hub

Related to near/nearcore#5738

cc @matklad @evgenykuzyakov @mikedotexe @amgando @nearmax @bowenwang1996

[bowenwang1996]

There is a use-case where some contract wants to ensure that some other contract is not an impostor

Could you elaborate on this? Does this simply mean that the contract wants to check that the code hash of another contract is some pre-defined value?

[frol]

Does this simply mean that the contract wants to check that the code hash of another contract is some pre-defined value?

That seems to be the solution, but I have not put much thought into how that will work across the shards, which might introduce some race condition when someone re-deploys the contract right after the check is done (thus I am thinking about some check that would tell me "yes the contract hash is XXX and it cannot be re-deployed [no full-access keys]")

[mikedotexe]

Yes, I think it's a very good idea to allow a smart contract to determine the code hash of another account/contract. It's a very good point what Frol is saying, although since you execute the DeployContract Action inside the smart contract, we can't fully rely on there being no full-access keys in order to determine whether this contract is immutable. So I think to be sure, it will be a combination of indexers that are specifically looking for the DeployContract Action from certain accounts and sending that info on-chain, similar to an inbound oracle.

But I think we can grow into that, and it would still be quite useful to have access to the code hash of another contract.

I do want to mention that currently, our tooling is behind on getting a deterministic code hash. Just now, I pulled the latest code to the Rust Status Message example and deployed it using my personal Macbook and work Macbook. I build this using the typical command, cargo build…

We have different code hashes as shown here:

Austin and Kladov can explain this much better, but I can say it poorly: I believe part of the path to cargo (and something else) gets added to the Wasm binary. About 6 months ago I remember seeing a post from Kladov in a core Rust repo where he was discussing how it would be great to use Rust flags to strip out this kind of information, or something.

So what we do in the Rust SDK is to have the build for the examples done in Docker, so at least the paths to cargo and whatever else are deterministic.

https://github.com/near/near-sdk-rs/blob/b40b845b8400d3abe61ede6a9024669869b07184/examples/build_docker.sh

The common developer, however, doesn't generally know about this as it isn't built into our tooling or documentation at this point. I don't mean to sidetrack the conversation to be about this, but want to give breadth as to the various efforts needed before our code hash is reliable and developers can get consistent results just by using our tooling.