[albertgoeswoof]

It says:

> When you fill in the details and click create, MetaMask will ask you to confirm the transaction

> Check if you're ok with the ethereum transaction fee and click submit.

In this case it's creating a new contract (I didn't notice the "new contract" logo in MM at first glance). I have to dig into the FAQs to find the source for that contract, and as you point out MetaMask can't guarantee that's the actual source. So this is an easy opportunity to stick a backdoor in that can hijack your created coins at any point.

A better approach would be to call an existing contract on the blockchain which creates a new contract from it's own source. Is there a reason not to do this?

[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.

[nebulous1]

Why would that be better though? How are you going to verify the contract that the deployed contract is deploying? How are you even going to verify what message you're sending to the already deployed contract (assuming the user isn't technically knowledgeable). You can have a third party (etherscan for instance) verify the contract after it's deployed. My main point here is that this is a complicated system, and there's only so much somebody who doesn't really understand the basics can be protected from it.

Even the web example you gave isn't as simple as it first appears. Just because you fill in a form with certain details doesn't meant that's what the page is actually sending to the server. Most of the time this isn't an issue, as you "trust" the page you're on not to fuck around.

[albertgoeswoof]

> Even the web example you gave isn't as simple as it first appears. Just because you fill in a form with certain details doesn't meant that's what the page is actually sending to the server. Most of the time this isn't an issue, as you "trust" the page you're on not to fuck around.

This is what blockchains bring, you don't have to trust the web page any more. With a dApp you know exactly where that form is going and what's going to happen, with the web you only know a POST request is outgoing somewhere and hopefully it'll be handled correctly. It's not something that's easy to understand yet, but one day it might be.

> How are you going to verify the contract that the deployed contract is deploying?

Go and look at it, compile + compare the source etc.