Explorer: display Move source code

[bwann52]

trafficstars

Verified smart contracts provide more credibility

[todd-mystenlabs]

@bwann52 - what does it mean for the source code to be verified? Including @sblackshear, @tnowacki, @awelc -- sounds like this implies some kind of backend/API that would need to provide said verification status or some kind of signing check.

(I'm guessing this means something like whatever is the source of real source code -- as opposed to a decompiled version when source is not available or desired -- we've got some signature that validates we're looking at the source that was uploaded?)

[tnowacki]

Is this talking about the Move prover? (not the bytecode verifier or anything)

[awelc]

Is this talking about the Move prover? (not the bytecode verifier or anything)

I would assume so (@bwann52?)

[bwann52]

Currently Etherscan allows contracts verification 3 ways:

1. Manually via smart contracts page https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327
2. Manually thru submission https://etherscan.io/verifyContract
3. Programmatically https://docs.etherscan.io/tutorials/verifying-contracts-programmatically

[tnowacki]

I still have no idea what "verification" means in this context, even after clicking on those links lol. It looks like you can show that it was compiled with a given compiler? Or something?

This doesn't really apply I don't think in Move since our bytecode is strongly typed, and the source language provides secure compilation down to the bytecode already (this means that the bytecdoe-level APIs for a module are not more expressive than those at the source level)

[stella3d]

@tnowacki does this mean the entire idea of source verification as you would have on Solana or Ethereum is moot, in your view ?

[tnowacki]

Maybe? But I really don't understand what they are doing on the Solana or Eth side.

More Move related things that could be helpful:

• Link to source code that produced this package
• Compiler version/rev/branch/something that the package was compiled with

[stella3d]

@tnowacki all that happens on solana / eth side is:

There is some way to verify that a given source code folder produces the exact bytecode that is on-chain for a given contract. This usually includes the exact compiler version used, everything needed for a deterministic build.

This allows mapping from on-chain bytecode to real source code no matter who uploads the source

[bwann52]

@tnowacki fyi main reasons why eth/sol does verification:

1. It lets you (and others) interact with the contract directly in the blockchain explorer.
2. Anyone is able to view the code of the contract.
3. Transparency
4. More trust

Here's an example from solana where the contract is Anchor: Verified

When you say link to source code, how do folks trust that the linked code is what is on-chain?

[awelc]

OK, now I have a better idea of what this is about. We have discussed it in the past and it's captured as one of Move devex tasks (https://github.com/MystenLabs/sui/issues/1109).

The idea is to reliably connect source code (off chain) with the bytecode corresponding to this source code (on chain). One possible solution to this is to store source code hash in the on-chain package object.

This way, if we had a source code repository somewhere that our object explorer can access, we could verify source code to bytecode correspondence pretty easily on a package object query.

[tnowacki]

There is some way to verify that a given source code folder produces the exact bytecode that is on-chain for a given contract.

AH, yeah that is a very different form of verification. And definitely a tricky one. I think @awelc already answered this well, but it will be the added wrinkle of the compiler version

[daweth]

@tnowacki just to confirm as of now there is no way to verify the contract function bytecode without already having a local copy of the .move source?