[joosters]

It still wouldn't solve the problem of viewing the source. You can't easily view the source code of a deployed contract. The only way to verify a contract is to find the source code from somewhere, then try compiling it and check if the bytecode matches the blockchain data. But details like compiler version and compiler flags may lead to the bytecode not matching.

In short, there's no good way of verifying an ethereum contract.

[albertgoeswoof]

But that can be automated though, right? You could post the source on IPFS or some hosted provider, put the hash inside the source code on chain, and have MetaMask or whatever is calling the contract download, compile and compare the code?

[gnarcoregrizz]

metamask could peek at etherscan and see if a contract has 'verified code' or not. often times, contract creators upload the source code to etherscan itself to get the verified badge https://etherscan.io/address/0xd22f97bcec8e029e109412763b889...

however, that would require trusting etherscan, but metamask already relies on it pretty heavily, so...

if the user didn't want to rely on etherscan, it's possible to have metamask verify contracts itself - the dapp publisher would need to provide the source with the dapp, metamask could compile it, and make sure it matches the on-chain bytecode. i believe solc is written in javascript so it would be possible to ship it with metamask.

i'm not sure how this would work with contracts with dependencies. at that point, the sources of all the dependencies would need to be verified. this would require larger infrastructure (e.g. etherscan, but again, a single point of failure).

in that case, it would almost make sense for another data section in the EVM to hold the contract source. in this case:

* 1. contract source code is all stored on chain, in a decentralized manner

* 2. clients can verify the byte code

* 3. it's more expensive to publish a contract since it needs the extra space to store the source

[albertgoeswoof]

On #3, I suppose that's the difference between OSS and closed source software today.

But why not just store an IPFS / Swarm hash linking to the source on chain? That requires almost no cost overhead per contract.

[gnarcoregrizz]

I was under the impression that there is no guarantee that the data will actually be there with ipfs? Not sure about swarm. It's possible that it could be somehow paid for when launching the contract. Anyway, the idea makes sense

However, in my experience, contracts don't usually have a lot of source code. I think storing them on chain wouldn't be much of a problem. Unfortunately though, that might incentivize minification and other self defeating measures.