Standard for Smart Contracts To Allow Auditing.

[BenKurrek]

After discussions with @agileurbanite, we thought it would be an interesting idea to have a standard which made it easier for smart contracts to be audited and increase visibility for open source smart contracts.

I propose a set of optional metadata that contains information about the current version or commit hash that a smart contract is based off and a link to the repository. There is currently no standard for metadata across all types of smart contracts and if a person wanted to know more information about an arbitrary smart contract without knowing if it was an NFT or FT contract, for example, there is no way of doing this (as far as I know).

The struct could look as follows and could be updated using a restricted setter method.

type ContractMetadata = {
  version: string|null, // optional, commit hash being used for the currently deployed wasm. If contract is not open-sourced, this could also be a numbering system for internal organization / tracking such as "1.0.0" and "2.1.0".
  link: string|null, //optional,  link to open source code such as a Github repository.
}

This metadata could have a standard way of being queried across all smart contracts regardless of their types which could look as follows.

function contract_metadata(): ContractMetadata {}

Since contracts might change and the version might be bumped, a setter needs to be implemented as well, although this would be optional and up to the authors of the contract.

function set_contract_metadata(
  metadata: ContractMetadata,
): ContractMetadata {}

Let me know what y'all think and I can make a PR into the NEPs repo if there's any agreement. This would be completely optional and would live as an extension to smart contracts. I've heard from the community several times that having a way to view open source contracts in the explorer or somewhere would be awesome as currently, it's very difficult to know whether or not a smart contract is open sourced or not and where to find its code.

[agileurbanite]

I'm for this and the arbitrary string can also be a CID on IPFS or some other decentralized storage. Maybe consider changing to:

type ContractMetadata = {
  version: string|null, // optional, commit hash being used for the currently deployed wasm. If contract is not open-sourced, this could also be a numbering system for internal organization / tracking such as "1.0.0" and "2.1.0".
  link: string|null, //optional,  link to open source code such as a Github repository or a CID to somewhere on IPFS
}

[BenKurrek]

Following a lot of positive feedback I've received regarding this discussion, I've created a pull request into the NEPs repo. Feel free to comment, leave feedback, or approve the PR 🙂

#330

[10d9e]

The Draft of this standard has been accepted and marked for community Review. @BenKurrek et al, you can make any edits or clarifications at this point or just leave it as-is if you are satisfied with the content.

[Ekleog]

For what it's worth, a related idea I've been having is a compiler contract: one passes it the contract source code and enough tokens, and it builds the source code into a contract only it has the keys for, while remembering the source code. This way there is full auditability of the built contract with no fear that the source code metadata as listed here is actually a lie.

The biggest hurdle in actually doing this is that one compilation definitely doesn't fit into one transaction, so it'd need a way to pause/resume rustc mid-execution to allow for longer calls. And then, the costs may be expensive.

All that to say, what's proposed here is certainly a great middle ground that's actually technically doable right now. I just wanted to take advantage of this place to mention this other idea as a possible very-long-term goal :)

[10d9e]

@Ekleog I agree your idea is probably out of scope for this standard, however, I think it's worth asking the community about its feasibility. We know that creating a VM on top of NEAR is possible with Aurora. Exploring these ideas, however crazy they may seem at first, is the seed of innovation. I would suggest you post up on our Standards Discourse or discord to get some community feedback on the idea.

[willemneal]

@Ekleog, you need to start with supporting compiler compiled to wasm. This way it could deterministically produce the same wasm.

[TrevorJTClarke]

Jumping in SUPER late to the party here - sorry :)

A couple things I see:

1. knowing metadata is nice, but current NEP propsed is prone to poor implementation/dependability. So what is the purpose? What are the use cases?
2. RE: Version/commit hash - I dont like the idea of them being possibly setup as both/either for the same field. If you're doing that its better to split them out.

Here's how we're doing it for sputnik:

pub struct DaoContractMetadata {
    // version of the DAO contract code - Simple Semver: Major (requires data migration), Minor (code change only)
    // Example: [3,1]
    pub version: [u8; 3],
    // commit id of https://github.com/near-daos/sputnik-dao-contract
    // representing a snapshot of the code that generated the wasm
    // Example: "c2cf1553b070d04eed8f659571440b27d398c588"
    pub commit_id: String,
    // if available, url to the changelog to see the changes introduced in this version
    // Example: https://github.com/near-daos/sputnik-dao-contract/releases/tag/2.0.0
    pub changelog_url: Option<String>,
}

For 1 to be truly trusted - we need the issue #294 to be implemented and surfaced, so contracts can know if the code has changed at all before doing potentially malicious actions.
For 2, i think the above example could work nicely :)

[MaksymZavershynskyi]

A couple of thoughts.

• Version should allow custom semver suffixes for things like pre-releases, etc;
• I am not sure this should live on blockchain. AFAIU https://etherscan.io/ stores mapping of Solidity source code outside the chain and it works just fine. It is verifiable, given that anyone can pull the source code, compile it, and compare Wasm files, so I don't see what we are gaining by baking it into the contract. A potential use-case investigation could be done by a PM;
• I don't think there is a reason to make key-value strongly typed. We are going to have lots of ideas in the future of how to expand or modify the metadata. If we decide to have it baked-in into the contract, we can just have a map of key-values with blobs in them.

[swfsql]

On the topic of having the git commit hash information as a static information inside of the wasm binary, it's possible to automatically generate and grab that information, such as how it was done in https://github.com/PrimeLabDev/contract-version
This would be an example of using it: https://github.com/PrimeLabDev/contract-version-example/

Notes:

• The primary objective was to make it easier for maintainers to keep track of which contracts, and from which commit, were deployed.
  • I'm not sure if it's possible, but I think that if this information would be on-chain, then it would be even better if some information were accessible directly from the binary, without the need to be behind a function. Then we could also just download the contract and check the values directly.
• The Github Actions on the example could be optimized because I think some caches defined in there are unnecessary.

[10d9e]

@swfsql I like how this looks. @BenKurrek Do you think we could extract a more comprehensive interface/type based on something like this:

https://github.com/PrimeLabDev/contract-version/blob/main/src/lib.rs#L11

[BenKurrek]

I'll take a look at everything in-depth once I'm back in office.