feat: Add Contract Metadata Standard

[BenKurrek]

This is based on the discussion held outlining a way for auditing and viewing source code for a deployed smart contract.

There is no trivial way of finding the source code or author of a deployed smart contract. By having a standard that outlines how to view the source code of an arbitrary smart contract, an environment of openness and collaboration is created.

[render]

Your Render PR Server URL is https://nomicon-pr-330.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-c8ghgfp0gd0aro0p9b70.

[agileurbanite]

👍

[agileurbanite]

@BenKurrek @austinabell @MaximusHaximus what are your thoughts of adding a system field so we can get some info on what system helped generate the wasm as well. This way we can try to rebuild the wasm and compare the hashes for auditing purposes.

[agileurbanite]

system: "local"|string,

[austinabell]

I mean, you would need architecture and toolchain version at least. Would the purpose of this be human-readable so someone could try to replicate it? You would also need some commit or version since the link doesn't specify repo links to commit that it was built with

[agileurbanite]

yeah ideally i want to be able to reference the source code and source dependencies to help with auditing the contract. Here's what polygon does which is pretty cool: https://polygonscan.com/address/0x217cF04C783818E5b15Ae0723b22Ee2415Ab5fe3#code

[BenKurrek]

I was assuming that the toolchain version would be kept in the Github repo. I don't really see the need to add a system field but would love other people's opinions

[agileurbanite]

Reading up on how others handle this can we also add:

linkReference: deployed address of address of other smart contracts on which the current smart contract has a dependency.
object: Current smart contract bytecode
opcodes: Operation codes that are human-readable low-level instructions.
sourceMap: source map is to match each contract instruction to the section of the source code from which it was generated.

[austinabell]

Reading up on how others handle this can we also add:

linkReference: deployed address of address of other smart contracts on which the current smart contract has a dependency.
object: Current smart contract bytecode
opcodes: Operation codes that are human-readable low-level instructions.
sourceMap: source map is to match each contract instruction to the section of the source code from which it was generated.

address and contract code can all be pulled without this. (This method is suggesting as part of the contract). This would only be needed if this info was stored externally

opcodes doesn't apply. Assume you're comparing with solidity, but the wasm instructions aren't important and the imported functions can just be pulled from the wasm blob, so this is redundant.

source map there is no use for this currently, because they can be linked through just analyzing the wasm binary. Doesn't seem that useful in our case to add bloat to the standard

[agileurbanite]

Reading up on how others handle this can we also add:

linkReference: deployed address of address of other smart contracts on which the current smart contract has a dependency.
object: Current smart contract bytecode
opcodes: Operation codes that are human-readable low-level instructions.
sourceMap: source map is to match each contract instruction to the section of the source code from which it was generated.

address and contract code can all be pulled without this. (This method is suggesting as part of the contract). This would only be needed if this info was stored externally

opcodes doesn't apply. Assume you're comparing with solidity, but the wasm instructions aren't important and the imported functions can just be pulled from the wasm blob, so this is redundant.

source map there is no use for this currently, because they can be linked through just analyzing the wasm binary. Doesn't seem that useful in our case to add bloat to the standard

I'm mainly looking at this from an auditing and reference standpoint. Also having a sourceMap would be useful for debugging imo but can be wrong.

[austinabell]

I'm mainly looking at this from an auditing and reference standpoint. Also having a sourceMap would be useful for debugging imo but can be wrong.

You can get this information from the wasm binary by just following the function export, so I don't see how any format would be more useful than this. Esp since if auditing the compiled code one would convert the wasm file into wat or use some tool that does this mapping for you

[mfornet]

What about adding some sort of organization contact link as well that points to the website of the application, or the developers; potentially with more contact information!

The difference between it and link is that one is to discover the source code, and the other is to discover what is the preferred way to reach developers/community behind this smart contract.

[BenKurrek]

I think this information could be found by utilizing the link since you can open issues or PRs on Github and follow or view the developers' public profiles. The case where I think this might be useful, is if the link is a CID to somewhere on IPFS since you don't have the same ability to reach out or view the developers as you do using Github.

thoughts? @austinabell @agileurbanite

[mfornet]

I would actually go even further and provide three different fields (similar to crates.io): Homepage, Documentation and Repository + version (to pin the exact version and allow reproducing the exact same binary).

Some services like npm only have Homepage and Repository. (Maybe documentation is a bit too much).

[mfornet]

One of the main use cases of having this standard, is if we are able to reproduce the same binary after we have access to the source code. I'm wondering if as part of it we should add a proposal or advise about how we can achieve byte for byte reproducibility.

Having a standard for reproducibility can be useful for external tools to automatically verify the code.

This is hard in general, mostly because there is more than one stack that can be used to generate the contract binary (i.e today we support rust and assembly script). Relevant discussion on how to make this possible on rust: rust-lang/cargo#9506

[willemneal]

A link to a docker image could be sufficient.

[10d9e]

Great reviews here - it looks like it's conceptually ready for Draft. @BenKurrek see below...

[10d9e]

@BenKurrek This is nice work. We now also need a formatted standard document as part of the new process. In this case, the standard would be neps/nep-0330.md. See process, template and nep success criteria for more details.

[agileurbanite]

@BenKurrek mind taking a look at @jlogelin comments above?

[BenKurrek]

Hey @jlogelin @agileurbanite been crazy busy - i'll take a look. Thanks so much!

[BenKurrek]

@jlogelin @agileurbanite @austinabell I just pushed the changes to adhere to the new process for adding new NEPs as per Jay's suggestions. Take a look and let me know what you think.