Smart contracts and the inherent lack of security in trusting compiled byte code

Question

Smart contracts on the blockchain are compiled. Is there any system in place to verify all the public dapp contracts do what they propose to be doing?

i.e. this could be done by compiling open-source contracts and verifying contract hash signatures, or in the case of closed-source but public d-apps, potentially decompiling compiled byte code and verifying code paths/function calls, although this is much murkier territory.

See for example https://etherscan.io/address/0xf97e0a5b616dffc913e72455fde9ea8bbe946a2b#code which is the CryptoKitties "gene combination" algorithm. Whilst the rest of CryptoKitties is open-source, this particular code module is closed-source. It has however been reverse engineered - here's a blog post about it, https://medium.com/@sean.soria/cryptokitties-mixgenes-function-69207883fc80. Whilst this is a small code function, there appears to be the possibility that a dapp could launch, proposing and appearing at first glance to be open-source, but in fact containing a hidden time-bomb, e.g. to transfer the balance of Ether to a bad actor's account on a hardcoded future date.

Do we need some framework or service was set up by which all published smart contract code can be validated to some degree?

Answer 1

this could be done by compiling open-source contracts and verifying contract hash signatures

That's pretty much what Etherscan already does. Are you aware of Etherscan's capabilities here? Are you proposing something more than what Etherscan already does?

For smart contracts that don't have published source code, simply don't trust them. (Or trust them if you're capable of auditing the bytecode directly, which I would claim vanishingly few people can do.)

Answer 2

[T]his could be done by compiling open-source contracts and verifying contract hash signatures, or in the case of closed-source but public d-apps, potentially decompiling compiled byte code and verifying code paths/function calls, although this is much murkier territory.

If you use the compiler solc which compiles solidity code, you can compile the source code that the publisher of the contract claims represent a contract on the blockchain. You have to use the compiler with the flag --bin-runtime to get the code which will be placed on the blockchain if you compile and publish the source code in question. Take a look at this answer: solc bin vs. bin-runtime

You can then compare the binary code that solc returns with the code returned by the call in geth eth.getCode(contractaddress) (this call returns the binary which is stored on the address contractaddress. This is the EVM code of the contract placed on the blockchain). The binary code of these two operations should match.

Like you state, you can also get familiar with the virtual machine code that Ethereum contracts compile to which is called EVM. If you do that, you will be able to read the content of the contracts directly from the blockchain. The Yellow Paper is a good resource if you want to learn EVM.